BLOG

 

Some considerations regarding:

Why simple blockchain games are worth making.

Or more specifically, what can be made in a week?

And why that specifically may yet be something really worth making.

We talk about design using inherent recursion and constraint propagation. An exercise in higher order cybernetics.

 

      Word count: 1.250 ~ 5 PAGES   |   Revised: 2018.11.14

 

 

— 〈  1  〉—

DESIGN

 

Think about a digital card game. Plenty of competition in that space. Many such games. But that's not issue. We're not discussing making a digital card game. Rather think about a particular category, in which one also finds digital card games, rather than gameplay type itself.

I'm priming you to think about that category. What are the characteristics of that category? Why? To think about what else happens to be in there.

Which category is that?

It's the category of games that (i) easily scaled and improved over time, (ii) are better if built and run on a computing machine, (iii) are more fun to play with more players actually playing, (iv) cost relatively little to make, (v) are made easily.

* * *

And actually I was thinking about something that costs even less to make than a digital card game. But has features absent in a typical card game.

* * *

Consider a game with items and "positions" and many players all operating in one connected world.

But a game which is as simple to build or play as a card game, equally simple to explain to players, but that ultimately plays like something more complex, like a MMORPG.

* * *

Done thinking?

QUESTION: How do we do that?

ANSWER: Inherent recursion. Constraint propagation.

We can design using that.

Let's imagine a concrete game.

(1) Items spawn characters ... which can "die" off. Characters have some virtual autonomous behavior, and can be positioned in places. And moved. Characters can be themselves equipped with items, and themselves spawn characters ... all the way down. But characters that "die" with items can drop the items ... reasoning would be open and encourage experimenting and fun.

(2) Various win conditions by constraint propagation. For example, each is a cellular automaton. Processes associated with different win conditions compute where they "are" or "move" in the world and set the win conditions by being "there" or not.

(3) Worldlets with a few positions with properties and exceptions that are procedurally generated around characters belonging to each individual player. Exists an atlas which glues these worldlets: It consists of complete rules which associate properly some tiles in one with some tiles in another.

* * *

Observe the following theme.

Tiles there but not matched are natural obstacles.

Notice they are not coded in. We didn't code obstacles in; they are inherent. Just carefully selected mechanics. Most features just emerge from the rules.

Likewise something like pathfinding around obstacles requires little work to make. It requires a lot of work ... or you define it exclusively on the atlas algorithm. Not on worldlet constructors.

Careful mathematics, carefully deciding what goes in which class, means less work. But more results than more work. This is a theme.

Likewise averaging rules may define the properties of linear combinations of tiles. Don't bother with carefully writing atlas. It can be random. Remember what we said about building a large, full space without much coding, using recursion.

Carefully build not very carefully to get more with less.

Likewise don't tie the game to a dimensionality. Can be pseudo three dimensional. Or two dimensional. Graphics will depend on resources; if more resources, upgrade the graphics. Same underlying calculations.

* * *

Was actually thinking about something whose mechanics that can be made starting with a working blockchain in a week. Sunk cost low enough for a team to easily cover the time put in via spawning some items for themselves if the game gets even moderate use.

 

— 〈  2  〉—

WHY USE A BLOCKCHAIN IN THIS MARKET

 

(i) The approach is picking an underlying game whose mechanics themselves are simple and operate recursively, but whose skill based reasoning rapidly grows in complexity and replayability if varying some simple aspect. Possibly something as simple as how difficultly increase in BTC. For example, inherently becomes more or less complex, interesting, depending on absolute number of concurrent players. Especially due to the recursion. Capture a network effect.

(ii) Low competition with other games, because the underlying logic is extremely nontrivial. Predicting. Balancing. Would need a research scientist ... hint hint wink wink. Or depend on a several critical team members. But game development itself would be easy and low cost: Relatively little code and art assets involved if what needs to be done is known and correct.

(iii) Blockchains are good for enabling social aspects and letting players mostly entertain themselves.

Herbert Simon argued [SIM87], discussing industrial revolutions, that the real impact of a technology is not always its first intended use case.

The financial aspects of chains may be far less important than the fact that, so long as tokens are not worth absolutely nothing, developers get boilerplate, free, reliable networking. Who owns what and who is where from a blockchain hosted by others to store common world positions of players and properties.

(iv) Would use an existing blockchain (1) because properly creating another blockchain enough other people will want to use is yet another time consuming task, (2) because which chain used should not matter. And should not matter. One of the reasons to make a game rather than some other decentralized application is, while the market for the blockchain space is down and declining, game items price and value can be largely separated in value from the price of tokens. Lower risk.

 

— 〈  3  〉—

ILLUSTRATION

 

For example, here's a set of rules.

You know how in a MMORPG players characters that die can drop some of their items?

(1) Suppose you have tradeable items that spawn characters in the hands of characters. (Not cards of characters.) Once a day, each item can spawn a character from a small set per item. Randomly or not.

(2) Players each have one default, immortal character. It cannot move far.

(3) But all characters can be equipped with items. Therefore can spawn more characters. And this all the way down. Meanwhile coding only involves one class. More characters more to do, easier to win.

(4) There is a risk. Characters can die in the game; once dead they are gone.

(5) And when characters dies they have a chance of dropping items where they stood. A nice prisoner's dilemma, several skilled ways to play. For teams and side payments between teams using the social media of the blockchain. (Not something that has to be made. It's already there. Very nice.)

ABOUT ME

I'm a scientist who writes science fiction under various names.

The magazines that I most recommend: Magazine of fantasy and science fiction, Compelling science fiction, Writers of the future, . . .

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