Some practical thoughts regarding simple decentralized open world game design on a blockchain.

 

      Word count: 2.500 ~ 10 PAGES   |   Revised: 2018.6.22

 

— 〈  1  〉—

INTRODUCTION

 
A little bit of history.

Decentralized blockchain is democracy software.

Most governments and existing organizations dislike real democracy. They dislike democracy with its referendum consensuses.

So truly positive regulations are highly unlikely to be forthcoming in countries with established vested interests. Decentralized blockchain makes these vested interests, with established lobbies, irrelevant and obsolete. And it, like a new technology, eats the demand pie for their services.

It's also neutral.

There's a conflict of interest. And if it's not decentralized, it's not a new technology, but simply surveillance. Which is per se harmful to science and innovation.

Yet science and innovation is most all that which accumulates: — of all that which binds time. In contrast to this most plant and work surfaces depreciate and are replaced rapidly.

I refer to David Landes's thesis regarding why Europe had an industrial revolution and China did not. People simply walked two miles into another country when regulations due to vested interests prohibited this or that new technology. This or that new industry. Meanwhile the Chinese were unified for thousands of years. Neither area had better governments [LAN69, LAN98].

The same reason that in the 13th century made Europe weak to outside invaders made them technologically advanced world travelers and colonizers in the 16th century and the technologically dominant powers by the 18th century [CIP65].

... ... ...

Well this is interesting and @firedream had an idea for some resources based strategy games right on this blockchain.

There are technologies. And trading.

And why not? How can large games be made so that they are simple and fast and provide rich novelty without requiring the hundreds of developers that games typically require? In other words: if we are building proper games on the chain: what are some principles according to which they can be made?

 

— 〈  2  〉—

PRELIMINARIES

 
Suppose we have motion in a grid of hexagons spreading from the extreme north west.

There are no diagonals with tiled hexagons and contiguous tiles that share an edge allow the player to move from one to the other with some broadcast transaction.

@firedream suggested resources are involved. They allow the player to producer other more valuable resources. And so on ... steel ... oil ... computers ... there is variety.

One principle of design is that you wants intermediate novelty [SME73].

This grabs attention with tension and surprise while still providing distance and not being so disorienting that any discomfort is caused. The result is pleasure.

We can take the base two logarithm of the number of qualitatively different ways the player can interact with objects, including themselves, in the game, as the measure of complexity. Novelty.

 

— 〈  3  〉—

OpenWorld

 
Let's imagine DWorld-io. There are a lot of apps called X-io.

Presumably because they need their own site.

Great. So there's that.

We have a name. Now what?

Do we want a fixed world size, say a matrix 1024 x 1024?

Or transition functions that bring players together often enough ... while generating a world ad hoc, so that tile state is not stored for tiles not visited or viewed by any player and we really only have a graph that gets fleshed out as players use it.

This means we define local movement operations, starting tiles, initial areas for players, transition functions, and functions for intersections of areas ... it won't look like it, but players take their "world" with them when they move on the back end.

A fixed size world is easier to design for, but more to calculate ... The procedural world is less to design and less to calculate, and easier to display on the front end. Quite paradoxically.

(The world not visited simply does not exist, hasn't be created yet. And world departed from is mostly discarded, with only information users learned about it by interacting with it retained in a post. It will look like it changed, with history of interactions consistent, but really random and procedural for the most part when revisited. John Wheeler would be proud of this model of the universe.)

This is a network. And there are many bots behind the scenes on the network.

Players login to the front end and authorize bots to broadcast to the chain specific types of transactions.

In this case one might require player to make specific staking posts. And interact sometimes with upvotes. (I know ... I know ... that can turn out fun ... right?)

Or as @firedream suggests players can upvote specific posts to mine for resources. These can be traded or gifted in the usual way. Players can pay a fee to generate resources in the sense of mines and factories and such things.

Remember ... this is a competitive production simulation game with transactions let's say.

All is performed by player accounts.

What about the back end?

Something simple is quite sufficient. This is a network. Only a few design decisions are really appropriate, unless you have hundreds of developers and want to create exponentially increasing work for yourself as your team adds in features. And they will be adding in features. Very likely.

All the back end does for each player's action is drop or not drop a message into the right drop box, which bots periodically check.

Bots can post and add to stats of player, and players can perform actions. Some bots "wait" by checking a drop box ... and if empty ... continue checking ... if something there ... do that until done ... then go back to checking ... and drop boxes are just several categories into which transactions posted fall into. We define these.

The player position is its own transaction.

Each player with some resources has a position. Perhaps several players can occupy one position. Or perhaps not.

A new post when that changes. Same with resources changes.

Databases can be compiled and then posted to the chain. And then the post is read while the database is emptied.

History of transactions is public and immutable. Archived.

The idea behind drop boxes is to break large complex problems into many many simpler problems ... into atomic units ... where the ready and waiting actors are linked together depending on what's initially in drop boxes, and independent.

We find that the probability of hitting the center of the board a million times consecutively with a throwing hatchet from one foot away is larger than hitting it once from a hundred feet away.

You can work on one problem or edit one part of the whole without having to rewrite or modify the remainder of the whole if that remainder does not do anything different.

 

— 〈  4  〉—

Life in the OpenWorld

 
So no player ever needs to look at the whole state of the world to display whatever we decide to show them on the front end.

The logged in player does not require the front end to sniff and process or parse the whole state of the game.

Who knows that that is? And who cares?

That's faster. And that's simpler. Very good.

So most messages (transactions) will have to just tell a bot X: if in drop box V there's a message Y from player Z then B(Y) and send to drop box W.

Order is by the time stamp. That's provided by the chain. It's a decentralized blockchain game.

The other messages change position or change resources. Suppose there are only three types of operations.

We initially specify the "World" by dropping into boxes, at the start, messages for most situations. As players play, they drop in messages, and some of our messages are used up. World changes.

There are however only 6 MOVEMENT operations being calculated: 1, 2, 3, 4, 5, 6. And there are 3 basic RESOURCES operations, and 3 basic MARKET operations. For example.

Then exist 2 integer parameters for tiles a player was ever on or could ever in past history move to. The rest should be implementable as messages going into drop boxes and several bots. One bot is special: it checks all drop boxes. And the other bots, when beginning to wait drop messages: READY into respective drop boxes. Our special bot reads those and gives errors to players on the front end, tells them to wait if they must wait, when needed.

Visuals can end up very light weight in this way, but look rich. Should be fast. Each action typically costs some resources ... so it won't be too spammy with transactions, I suggest.

Just add more bots, more drop boxes, and write initial messages and start with these in the right drop boxes.

The more complex the initial communications patterns the more complex the game.

Now some ideas. Some possibilities:

Position X(A,B) is tile x^A_B. If a fixed world, bottom row would have A = 1024. Then, for example: X(2,3).5 = 5 (X(2,3)) = X(2,2). And then, X(2,2).E = (N,M) = (5,2). Let's say these are favorable. User had 100 steel and 50 oil. That means, let's say, movement X(2,2).6 from this spot doesn't exist, and X(2,2).5 is performed. X(2,2).1, X(2,2).2, X(2,2).3, X(2,2).4, X(2,2).5 do exist as usual.

But the 2 means 100 is treated when sending messages 200 and the 50 as 100.

But it takes 2 movements, with associated costs, to get off this tile ... models "sunk cost" of "large scale production" or something.

So if a player puts down a computer factory on this tile, this sends a message. The bot knows from which tile and who is the player. Output of the factory is whatever 200 steel and 100 oil produces. Suppose this is 125 output units. R(125) = (random, random, random, random) summing to 125. More "computers" than "machines" as these are considered better ... R(125) = (18, 20, 25, 62) rather than say (28, 30, 35, 32). Bot posts transaction. Player resources updates ... They can also move ... Something like that ... If we have fixed world X(1024,1024) is extreme southeast. Otherwise we just define a 32 x 32 grid and a transition function: X(32,32).P_4663234 = X(18,13).P_539. Then a function defined on possible n-fold intersections of worlds. Based on what transactions by their header fall into the category of current player positions. This is written such that players have a high probability of meeting. Marks and a bot that detects history errors keeps things approximately consistent.

We can do a kind of pseudo 3D perspective in JS if we use transitions functions.

Imagine one sheet of paper displayed from a perspective slightly above another such sheet of paper. Except they are grids of hexagons. If they were laid flat parts would overlap.

A player symbol would be displayed somewhere on each grid. Only two or three such near sheets displayed at a time, when the player is logged into the front end.

It looks 3D, but it's not: 2.5D. Rather it's 2D skewed.

The player character is just a line projected from the plane replacing matrix components with hexagons, when the plane is skewed, onto a transparent plane parallel with the screen. And then centering on that line a small icon that is not skewed.

At this point other options open up. Having players logged in and active and this together with all the broadcasting to the blockchain means the front end can double as a place to host a social media profile. Players can interact with each other and use the platform for social media well. Just another bot to build a profile from their images, if they are allowed to post in general from a page on the site. Why not?

... ... ...

What is important is that types of bots can be added without having to modify existing bots. One can build complexity from primitives. It also allows clear thinking about concurrency.

There is a kind of science to design centered around strictly more or less complicated ways to scale these kinds of systems.

Design must be atomic but coherent. The two are not in fact mutually exclusive.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License  . . .   . . .   . . .    Text and images: ©tibra. @communicate on minds.com