RE: Blockchains should be designed like massively multiplayer games
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.