Archive for November, 2016

Further thoughts regarding Unity project

November 19, 2016

It turns out that there are two key ideas that should prove useful in my investigations: text based scene files, and the asset database in Unity 5.4+.  Every time that one modifies something, one would like to take note if it was a scene change (an asset addition or reposition), or actual modification of an asset.  Since terrain is an asset, this is an important thing to take note of.

Consequently, when building the architecture, I am roughly interested in the following.  One, a set of Photon Bolt Clients talking to a Photon Zeus Server running on Amazon EC2; secondly, each client to either be tagged as a ‘Dungeon Master’ or as a ‘Player’.

Then, for a Player, the experience is essentially a multiplayer game with signals synchronised with other clients in the ‘Active World View’.

For a Dungeon Master, they have the Active World View, but also a World Modification View on another tab.  Both of these as a source of truth have the game state, which is stored as metadata (text based scene files) and binary files for relevant assets (uploaded by the database API) sitting on the Zeus server.

So the Zeus server in EC2 has the game state.  Every <interval>, say five seconds, this is broadcast to every client (pushed).  Each client then has a new game state.  This state is then loaded into the Active World View (the game).

For the Dungeon Master, they have the option to modify things in the World Modification View.  Changes here update the scene in their viewpoint (the dm game state) which is then pushed by a polling mechanism to the Amazon EC2 server, for distribution as the new game state to each client (including the Dungeon Master’s Active World View).

Say as a scenario then that the DM adds an asset.  This is then reflected as a change to the text based scene file, which is pushed up to Amazon as a fairly small payload, then pushed down to all the clients again.

Alternatively, suppose that the DM edits an asset (eg the terrain).  This is then reflected in a change to that asset in game, which then needs to be transmitted as binary data to the server (a slightly larger payload), which is then pushed down to all clients again.

Persistence

It should be possible to persist a map ideally, as then things would not need to otherwise be reworked.  To do this, the DM could have a local database store for their World Modification View state, which could store the scene text file for the state when they click ‘save’, and the binary files for any assets that have been created and/or modified while in situ.  These should evidently be tagged in some easy to find way (either by player naming or timestamping).

Multiple DMs

If multiple players have edit privileges, evidently things are also a bit more complicated.  The server truely does have to own to the game state, and one needs to be able to handle race conditions / queues in terms of work being done to alter the game state.

In this model, the server broadcasts the game state to each DM client.  Then the Active World View naturally reflects this new game state.  For the World Modification View, it should theoretically be possible to update this too, but the view should not change while a DM/player is actively altering something (when they click ‘edit’).  When the player clicks ‘commit’, the changes then should be pushed to the server, and any local changes pushed by the server should then be loaded in as a pending queue of alterations.

Scenario: Say that P1 adds a tree and a house.  Then P2 add a horse and a goat.  Meanwhile P3 is altering the terrain.  P1 commits first, then P2 does.  P1’s data reaches the server after P2’s data, but the server notes that P1 made a request first and queues the requests accordingly.  The server pushes to P1, P2, and P3.  P1 and P2 then see the changes in their World Modification View.  However P3 sees no change.  P3 commits, finally happy with the terrain change.  P3 then sees P1’s change.  A moment later, they see P2’s change.  Of course, meanwhile P3’s change has been pushed to P1 and P2.

(This model is best viewed in terms of ‘git checkout -b P1/tree_house’, ‘git add tree’, ‘git add house’, ‘git commit -m ‘I added a tree and a house”, ‘git push origin P1/tree_house’, ‘git pull’).  ie analogous to source control – in fact, it is the same sort of philosophy.  In that way, multiple ‘branches’ could be spun off, before merging back into ‘master’.  But of course, that leads to:

Merge Conflicts

Say two DMs have alterations that conflict with one another.  Which gets applied?  In this case, I take the philosophy that ‘the last is always right’.  So the last becomes the new master.