search

Apian-Framework / BeamGameCode

Engine-independent C# core game code for Beam
0 stars 0 forks source link

Each command application must be treated atomically #9

Closed jimkberry closed 4 years ago

jimkberry commented 4 years ago

Currently, party as a result of the code's history, major game objects (bikes, places, etc) that get destroyed during play are not actually removed until the end of a "frame loop" - this prevents a bike, for instance, from being deleted while a list of bikes is being iterated.

Now, under Apian, these objects can only be created and destroyed when incoming commands are applied. In fact, the CoreState can only be changed at all by commands. The CoreState "frame loop" still exists, but it's main purpose is to see if time-dependent Observations need to be broadcast, and maybe to set some non-CoreState values that are helpful to the frontend.

In general, during operation a couple of commands will get applied, and then the frame loop will get called and then the frontend will do what the frontend does, and then it all repeats. All of the peers will apply all of the commands in the same order, but the Loop() calls won't necessarily happen between the same commands on all peers.

Short version: since the objects aren't getting removed until the Loop() is called, different peers can see different states while applying the same command.

This is no good.

jimkberry commented 4 years ago

Object removal should still happen at a "frame end". But the "frame" involved should be the application of a single command, as opposed to the clock-based CoreState loop.

jimkberry commented 4 years ago

That made a huge difference - I probably should put peer removal in there as well, since places, bikes, and peers are the 3 thins CoreState cares about.

jimkberry commented 4 years ago

Done. Tho division of responsibility between CoreState and AppCore - with respect to CoreState data management - are inconsistent.