Blockchains should be designed like massively multiplayer games
In my previous article I made a case about why general purpose blockchains shouldn’t use the UTXO transaction model. Now I will make the case that blockchains should not store state in transactions and I will do so by borrowing lessons learned from massively multiplayer online games.
If you think about it, every multiplayer online game is a consensus engine. All players need to reach consensus on the state of the game world. Game designers determined long ago that the game state is too large to synchronize to all players efficiently. Instead, what game developers do is generate a deterministic engine and then communicate player inputs. Assuming all players agree on the order of events, everyone knows exactly who won and who lost. With this log of events it is possible to make a complete and accurate replay of the entire game.
Imagine playing Star Craft on a blockchain. Users would generate transactions for every command they issue to their units. These transactions would get aggregated by a server which would determine the global order, then this block of actions would be distributed to all players which would then have their state synchronized.
Obviously 3 second block times would impact the game play, but in theory block times could be reduced to 20ms if there was only a single block producer.
Small Actions can create Large State Changes
A single user action that directs all units to attack an enemy base can result in endless state changes as the units move, attack, and kill each other. Assuming there are 1000’s of units, each moving 30 times per second, we are talking about tens of megabytes of state changes all triggered by a single user action requiring less than 1KB.
From a system architecture perspective, it just isn’t practical to directly synchronize state as doing so would dramatically hinder overall framerates and potentially render the game unplayable on low bandwidth connections.
Whether the game is Star Craft or a financial system, the software design patterns and architecture are largely the same. In both cases you need to prevent cheating and ensure that all players see the same state of the world. The only extra step required by blockchains is that every user action be cryptographically signed so that independent 3rd parties can audit the game and ensure the server isn’t cheating. This extra step of signature verification is completely independent of the game rules (business logic) and can also be performed in parallel.
Predictive Rendering
Games like to give users an experience that is smooth and free of latency. To do this they predict the state based upon the inputs they have received directly from other players. Eventually the client gets an official update from the server. When this happens the predicted state is replaced with the actual state plus any new predicted state.
This is exactly what happens when you view the blockchain state inclusive of unconfirmed transactions. The next time a block comes in, the unconfirmed state is reverted, the official actions are applied, and any remaining unconfirmed actions are applied on top of that.
Conclusion
The blockchain industry is largely deluded into thinking they are solving new problems, when in reality almost everything a blockchain needs to do has been known for decades by game developers. The only thing new in a blockchain is that all user actions are signed and that there are multiple servers that take turns including actions into the official log. Most of the blockchain-specific technology and consensus systems (whether POS, DPOS, POW, or something else) is completely independent of the already established designed patterns that have been proven to scale for massively multiplayer online games.
Blockchains should be designed as a log of user actions combined with deterministic logic for generating state, not a log of state changes.
So in engineering terms:
This sounds pretty much like your "plasma" idea. Am I missing something?
It's great to see that you have not abandoned the platform in its entirety.
reminds me of 1st blockchain game ive played HUC - HYC coin stil ltrades on Poloniex but game doesnt work anymore
Hey @dantheman, so great to have these explanations from you, so clear and simply put !! Your vision must be headed and i am sure it is !! Consensus is All !! great to have you posting more than ever here now ) steem On )
@dantheman
I love it when you type words into the computar and say stuff. Really it tends to be quite epic.
Do you have any thoughts on this lil fella here?
https://github.com/metacurrency/holochain
And..... Any chance we can get a diagram on the type of MMORPG config you are describing.
May the chain be with you.
BTW-- I intend to reflect on:
Blockchains should be designed as a log of user actions combined with deterministic logic for generating state, not a log of state changes.
And when you don't have enough nodes processing your blockchain you're hear a booming voice demand 'You must construct additional pylons!'
I'm not sure if any game developer replied here, but the conclusion in this post seems questionable.
Actually, in most MMO games, critical computing is done on server side, especially when there are randomnesses involved, for example what items will drop out when a monster dies. Basically clients send "operations" to the server, then the server validate the operations, and returns "results" aka current state as main output, and returns the "operations" as references/logs. Only most recent state is stored and get synced when necessary. The server is trusted.
It's true that StarCraft is more like a blockchain. It is a multi-player game, but its core is not a "massive" multi-player game. One player create a battlefield, up to 16 players can join and play (change current game state). Quantity of state changes is relatively small. The math in the game is all deterministic (no randomness, or with pseudo-randomness). Network communication is P2P, while playing a game, one node is elected as the main validating node, other nodes sync. Whether to sync current state, depends on user experience, there are trade offs. For StarCraft, log of operations is synced, because the data need to sync is relatively small. After a game ended, all players can save a replay. When it comes to another game "heroes of the storm", since it's running on the same game engine, only log of operations is synced, but when a player disconnected, it takes several minutes to sync up after reconnected, people often see a "game over" screen after finished syncing up, thus get bad user experience.
Blockchains can learn from MMO games. For one special business, it's best that only the data it has interest gets synced and can be validated alone (maybe requires some trust), while it's still able to sync and validate the full data (less trust). Perhaps one implementation is Ethereum's state tree. Another potential implementation is the multi-chain feature described in Steemit 2017 roadmap.
Starcraft is an RTS rather than an MMO as you described. Furthermore, it has a very limited number of players. To keep the input and visuals synched it does use similar techniques, but not quite the same as an mmo. What you described is pretty accurate. I am a game developer, though I haven't worked on an MMO. I have studied the technology. I am an Independent Game Developer (indie intentionally) and I also have a full time job as a Senior Network Engineer.
Typically whichever system is chosen to be the server (even in a P2P) mode will be the one that is considered authoritative. It is the one with the authority to dictate what actually happens. It is the one which will either send updates to the clients, or is the one that will validate input from clients such as in a Peer to Peer environment.
The validation is important. As you increase the responsibilities/abilities of the client/peer on the communication side beyond simple input you also open windows for cheating/exploitation. You'll see this more on First Person Shooters where the input has to be VERY fast and network latency can be a problem. This then opens the doors for things like aim bots, and other things. Some people can get skilled enough that the anti-cheating that is supposed to detect bots can false flag people. I've seen this happen. It is much like the problems with trying to detect bots vs. people on steemit.
In Real Time Strategy games the input of the client is sent to the server (or authoritative peer) who validates it and relays it to the other clients/peers. This is a chance to prevent invalid input. In some cases it may even send it back to the client/peer it received it from and some game developers may make a game only respond to clicks that have been verified by the server/authoritative peer. Really there is no SILVER BULLET of "this is how all game developers do it" These days the cost to enter the game development arena is at an unprecedented low. It is almost as available as a pencil and paper. This means a lot of people are jumping in with "I have a game idea" and have not learned how to actually do that. Some of them are marketing their idea (sometimes with great success) without actual experience in delivering what they are promising. This means the market is being flooded with some pretty poor quality projects, and it still has a lot of good ones too (more than ever) it just requires the consumers be a little more aware than they have in the past. There are a lot of ways to make a game.
The MMO space does tend to be very specific though. Network latency tolerant designs supporting a lot of people usually means input processing needs to be a little less frequent per player. So it does interpolate/simulate/predict on the client the motion and results of input. Occasionally the server will synchronize to update the clients. When there is a problem either due to the game or network lag you'll see the results of this in the form of what people sometimes call "rubber banding"... where a player was one place and then suddenly is in another as they receive an update from the server saying "you should be here". This is primarily required due to the quantity of players.
This is why MMOs are largely target, and then click a power bar that cools down, etc. This is a good gateway for limiting how fast a player fires off actual important input. Rotating your camera, zooming, and all of that stuff the server doesn't particularly need to be aware of. So it is your movement and the UI commands you click on that it cares about. This simplifies the size of the network transmissions a lot and let's the clients handle the rest.
Anyway... I don't think I've done much more than ramble here. I think what you said combined with what Dan said are pretty accurate. Though nothing in game development is set into stone these days. :) (perhaps never was)
If you have the inputs and the deterministic code, then you have synced the state. Everything else is a light client optimization.
Which blockchains do you think do this best apart from Graphene based blockchains?
Most things that are not UTXO based are closer to this model than those that are UTXO based. Still, they all attempt to overly define state by including the hash of the state in the block headers and making changes to state representation consensus-breaking.
It's nice to see you again.
Do you think there is a real world RTS that could be better with a blockchain?
I mean it all works now (more or less), and the problems there are (lags of all sorts) are not going away with a chain, more increasing.
But I think maybe turn based games would be a nice case. (Chess and Go already use thinks like that on paper - you write down what happened, but not the overall state.)
No, I do not think a blockchain would help with real world RTS because every game is a fresh start and there is little lasting value to the output of the game.
That said, if someone want to issue a currency based upon winners of a game then you could do that. The problem is, that most RTS games depend upon keeping parts of the other player's state secret. With a blockchain that is not possible unless you trust a 3rd party to manage and reveal the state to you as you gain permission.