Loading and Reloading the Game

David LeGare edited this page Jan 11, 2019 · 4 revisions

We need to be able to run the game within the editor somehow, and there are two main approaches to doing this.

  • Compile the game as a dylib and have the editor host it and access the game's state directly
  • Run the game in separate process from the editor and communicate the game's state over ICP.

Requirements

  • Editor must be able to access game state.
    • This includes things like entities, components, resources, State objects, information about systems, loaded game assets, and anything else the developer might want to see about their game when running.
    • Access must be performant even for large games. If the game has 100,000 entities, we need to be able to efficiently query and display state information for all of them.
  • Hot-reloading of game code. Ideally, a developer should be able to modify some code, recompile, and then test their changes without needing to restart their game.

Dylib Loading

The biggest advantage here is that it is relatively low overhead: The editor gains direct access to the game's state, and therefore doesn't need to keep track of the game's state separately. This is a big win in terms of memory usage and CPU usage.

The biggest disadvantage has to do with robustness, in that an error in the game code that causes the game to crash can also cause the editor to crash. If the game simply panics, we can likely allow the editor to catch the panic and recover smoothly, but if the game segfaults or e.g. call std::process::abort, then the game could cause the entire editor to crash. In order for the dylib approach to be viable, we must have a solution that allows the editor process to remain running in the face of any kind of errors in the game code.

Multi-Process Architecture

This is almost the exact opposite of the dylib approach: It trades greater runtime overhead for guaranteed robustness in the face of any errors in game code.

The two biggest costs here are in latency and memory overhead:

  • There's a delay in sending the updated state data from the game to the editor. The actually latency here is likely minimal (so small that a user likely can't perceive it), however we do need to rate limit how often the data is sent. This rate limiting does result in a noticeable stutter in the editor.
  • The editor needs to maintain a copy of all the state data for the game, updating that data as the game process streams updates to the data. This process is costly in terms of memory, and is likely not going to be viable for medium to large sized games.

One potential improvement here would be to not maintain a copy of the game's state, but to instead have the editor directly query game state over ICP. This would likely mean that the game would end up keeping some internal state that's relevant to the editor, e.g. if the player selects an entity, the editor would then request that the game stream all the data for that entity and its components, and the game would need to internally track which entity is currently selected in the editor.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.