[Discussion] Presentation, Simulation and Networking

[crazyfox55]

I would like to point out an important concept, I think PP should be strongly focused on. The concept is focused on obvious and careful separation of the simulation and the presentation to facilitate a multiplayer experience. I believe these concepts would also apply in a single player environment and might even help with further development.

I know I don't have the knowledge/skill to fully explain the concept in a short paragraph so I'll reference this YouTube video https://www.youtube.com/watch?v=-_0TtPY5LCc (only the first 30 minutes are valuable).

[koosemose]

Sorry, not watching a 50 minute video, or even 30 minutes of one with no clear idea of what is even being suggested. Please try to summarise, even if badly. Just something to give people a reason why they should dedicate 30-50 minutes of their day watching something they may not otherwise be interested in. Particularly why/how you think it would apply to a single player experience (since at this time PP has no plans to be multiplayer as no plans proposed in the past have been able to suggest what multiplayer in PP would be like in a way that has interested people enough to justify the potentially massive amount of effort to implement)

[UnknownDude1]

So, I made a few projects that use UNET already, therefore I have some sort of idea how all of that would work. So, what most people are concerned about, like @koosemose for example, is that the networking would be way too hard to implement. But UNET actually does a lot of stuff in the background and you could do some automated synchronization that would automatically be compatible with new content, like synchronizing the tiles, where you would essentially only need a "has this tile changed? yep, sync the position and id of the tile" thingy on the server. That would do everything automatically and people who add new tiles wouldn't even have to bother testing via networking.

[crazyfox55]

Below is my best summary, watch the video if your looking for a more detailed description.

There are two layers simulation and presentation. The presentation layer watches the state of the simulation layer. The user interacts with the presentation layer which then issues commands to the simulation. Those commands are then sent over the network to all simulation instances.

There are a lot of important points to make this system function properly.

1. The simulation layer must be deterministic. Meaning all simulation changes are done through commands, i.e simulation state is read-only.
2. The simulation should run at a fixed update rate for keeping network instances synced up.
3. All simulation variables need to be consistent across platforms, meaning no floats (there inconsistent between simulations). Causes simulation to loose sync across the network.
4. No Unity in the simulation because it uses floats all over. (We need strict control over the simulation)

Obviously the presentation layer is where unity is used.

A closer look at how this would be implemented (Commands in, State out):

1. User input generates commands
2. Commands buffered for each simulation tick
3. Sim tick executes commands and updates game state
4. Game state snapshot queued for presentation
5. Presentation interpolates and updates display

How they implemented it "suggestions":

1. Separate code with two different "solutions" something in Visual Studio its like different folders in a way. Namespaces is similar. This is not a must just a suggestion for clean code.
2. Use internal keyword to prevent presentation layer direct access to simulation layer.
3. Run the simulation on a different thread from presentation.
4. Use checksums and state dumps to diagnose desyncs. This is for networking.

Below are more details on the specific considerations that need to be made. Fixing float numbers to be deterministic with Fixed Point Math:

1. Uses integers
2. Enables cross-platform play
3. Straightforward, but rather slow

With Fixed Point Math decisions need to be made about edge cases (infinity, NaN, ect.) and where fixed point is (int with 16.16 bits, long with 32.32 bits)

The presentation layer can add additional functionality outside of simulation that don't pertain directly to game play. Example would be if PP was a single 2D layer but the Presentation layer could render 3D cubes. The presentation layer could also allow the ship to fly around in 3D.

Adopting this structure makes it easier to port to multi-player. It provides a base for implementing undo functionality i.e inverse commands. It makes saving of replays easy and small, just save the list of commands that went through the game and the seed of the random number generator.

Replay quite in depth you can skip to it with this link https://youtu.be/-_0TtPY5LCc?t=17m2s

I hope this summary explains the concept faster than the video and is slightly tailored to PP.

[koosemose]

Thanks for that.

I, personally, don't consider undo functionality a needed feature, between the fact that things don't happen immediately (crew required to perform command issued), and autosave functionality, we have all the "safety net" a player needs (with the exception of dev mode of course, but it's also relatively easy to redo what has been accidentally undone, and it would be relatively easy to implement just that portion, such that commands are saved in a way that they can be undone and replayed, in comparison to the full system).

As for a replay system, that would be interesting, but also I don't think it would be a heavily used feature, due to the long play times typical in a base-building game (with the assumption of quill as an average player, his most recent full play of Rimworld (as in not a super hard setup that dies off very early) ran for 21 episodes, with a rough average of 30 minutes an episode (in reality it is almost certainly higher, but I prefer to underestimate when being too lazy to do the math), that's 10 and a half hours of gameplay, and further assuming that a play cycle of PP would be roughly similar to Rimworld (it's the closest in style of play to what we're building). If we were to also assume that the entire play through is at 1x speed (it isn't) and the replay played at max speed (ours is x8) that would still be a 78 minute replay, even if we cranked the speed up past normal play's standard maximum, that's still 39 minutes of replay, at a speed I suspect wouldn't be that useful to watch.

The most problematic portion of this is the fixed point math, if, as your summary says it is slower than floating point, that is very bad for us, as we tend to run into performance issues as is. And that's leaving aside the difficulty of keeping a group of random programmers with many dropping in and out (we've had 109 contributors, with perhaps 3, maybe 4, waves of dedicated developers in our relatively short lifespan already).

I'm not opposed to the "commands" portion, which I think could be separately implemented from the rest, and would allow replay if anybody really wanted that feature, and maybe undo/redo, but I don't see any way undo/redo could be implemented in a reasonable fashion in a game that should have hard consequences for mistakes (even if autosaves make those consequences only the loss of a few minutes time).

The Fixed point math seems like it would be actively detrimental to performance, and only seems needed to support multiplayer, and the actual fully separate layers seems like it primarily is only needed for multiplayer as well, while adding a degree of difficulty in the implementation of anything.

[bjubes]

In a way we already have this type of seperation between simulation (models and data) and presentation (sprites/monobehaviors). Even just looking at the file structure of PP shows a clear divide between the two that has been present since the beginning, Controllers and UI sit in different base folders than Models and Pathfinding, and have almost no interaction except in abstracted and well managed way (well in theory at least). While PP doesn't quite go to the same lengths to literally split the data layer into a seperate solution or API, its worth noting that PP is very unlike most unity-native games, which contain monobehaviors for almost every function. Quill even said from the beginning that PP is more data driven and is more akin to web design with abstracted models, views and controllers than the usual Unity way of attaching everything to a gameobject.

for example, look at the paralells to our project: User input generates commands - Unity is used to originally capture the keys. Commands buffered for each simulation tick - Keyboard manager pushes events to subscribers Sim tick executes commands and updates game state - In character and furniure models, unity passes deltaTime and they caculate their own commands agnostic to unity. Game state snapshot queued for presentation, Presentation interpolates and updates display - Models fire events when they change, and SpriteControllers update the screen the Unity way to represent those changes.

In terms of a concept, simulation-presentation seems to be closely related if not identical to model view controller, a paradigm that this project has kept. As for the specifics like fixed math and checksums, as @koosemose mentioned, these are slow. There's a reason Unity standardizes on floats, their speed is a priority over precision, and PP is no exception.

[crazyfox55]

I agree PP has strong separation between presentation and simulation. I wanted to bring up that these concepts have been used to create a large scale multi-player game and as a push/incentive to keep multi-player in the back of our minds.

[koosemose]

Since, as bjubes says, there is at least similarity between PPs setup and the simulation-presentation idea I am closing this.

Also as a side note on multiplayer, there have been a couple suggestions about it in the past, but never anything concrete enough to actual work in the base-building style of gameplay PP is focused on or catch people's interest to really even be so much as a "back of the mind" sort of idea. If you have some ideas on those routes that you think may have potential, feel free to pitch them (though perhaps do a search in closed issues for multiplayer for a look at the previous issues that have been presented, just be aware even if it does catch interest it is still likely to be very far future as we are still very early in development.