A possible workaround for the "global state problem": Distributed States

So I have seen a several questions in the Discord about a global game state. It’s also something I’ve been very interested in. I thought I’d just throw an idea out here I’ve been playing with in my head.

The idea is to basically create a distributed game state. You’d store game state to the new players, evolve it while they play. Then when other players appear you’d grab the most recent variables from the world state, from the players currently in the game, and propagate it to the other players. Think of it as a distributed CVS like Git.

Of course, distributed is never global and would mean you’d end up with several split distributed states. Once players with those different states meet you’d have to merge those states, which requires some smart and specific conflict resolution.

It would require some form of versioning, and would take some clever coding to get to work properly, but might be a solution for specific cases until Unit 2 implements a global state in their APIs.

To reduce the amount of “split” global states you could, on a regular basis, collect different distributions using the Analytics API, and then update your game to contain a new “base” state to propagate to all players.

I hope this has inspired someone. I love thinking about creative solutions like this. Please let me hear your thoughts, and feel free to poke holes in my theory so we can fill those holes with solutions!

6 Likes

Hah, I know I’m some of those questions. Whenever I get my hands on new tech, I’m always curious how far I can push it.

That’s actually a neat idea for managing state, but I’m not sure how one could actually negotiate state like that. When I think of repo systems, divergence can be put back together because the changes are in different areas. If you could enforce some form of divergence, like sending the players to different levels, then they could come back and share states that way. Another solid use case would be combining progress towards something together. Anything that can mathematically combine into the same data point could work that way. Something like “raise money for the town” or “kill enough baddies to bring peace to the land”.

It made me think of blockchain tech. In blockchain work, each person has a verifiable signature to perform data exchanges in a verifiable way, and everyone shares the history of that exchange. Ownership of in game assets could be tracked through something like that. The great part about Stadia is that you can actually implicitly trust all the users to not be attacking the network! No one could insert malicious code into the game binaries or anything, so you can act like blockchain without having ANY of that crazy crypto math. You could just keep logs with user names. Point Stadia.

I had a few ideas I’ve been kicking around for similar problems. The first thing I realized was that you could make a number of interactions different for each player. If you look at the tumbleweed ranch, each player could have their own crops in the same place. They would see their crops, whose state is saved in their player data, and everyone else sees their own crops in the same location. It might be a little funny, seeing someone harvest where you see barren dirt, but it’s basically parallel states of existence. You’d still have the same world, same interaction points, and a communal experience.The client / server separation in Crayta can do some funny things I bet.

Another idea for global game state to me is the idea of having multiple game worlds that are different states. Let’s say you have tumbleweed ranch with seasons. It’s July, but you’re a Southern Hemisphere kind of person, so you set the game to early winter. That gets saved into your character. When you want to launch tumbleweed, instead of joining the tumbleweed_summer game, your hub world / portal script would instead see that you’re set to winter, and you’d get sent to a tumbleweed_winter game. So long as the level selection happens without active steps for the user, you could overlay different states onto the same map seamlessly. You’d only group up with people who are in the same state. The same principal could apply to a town during a quest line, changing as you progress through the story, entering different versions of the town instead of the same version with a state. The downside to this is that you’d probably only want to use this for major state changes, since you’d have to actually make each permutation of state.

I’ve been really curious if there was a way to rig the scripting to create new game states dynamically, but even if that was possible, it would absolutely fracture the player base. Having a thousand versions of the same town would mean never meeting new people in game, which is lame. I definitely want games I work on to encourage meeting new people. A game like Crayta is built on community.

4 Likes

I know right? :smile: It’s the classic example of restrictions inspiring creativity. :smiley:

Yeah, that’s what I was initially going for. Global data that can easily be merged and were conflicts can be resolved with some sort of state engine.

Ah yes! Blockchains are a perfect example. They are distributed and designed to proof ones ownership of things rather than having a global state. That would be perfect blueprint for shared inventories and trading systems. And like you pointed out, there is no need for crypto. :ok_hand:t2:

Actually that’s very close to what they do in Crayta Cooking in regards to level progress. The person with the highest progress determines what levels are available. But of course you could easily adjust this logic to restrict people to certain worlds.

Thanks for all these great ideas. Now I know I’m just going to think all they long about how to create a distributed inventory/trading system… :laughing:

1 Like