Ghabry
commented
3 years ago I would actually prefer the IPC approach. This would solve the "Multiple instances" problem and a crashing Player can't tear down the Editor (I see this happening alot when users start to modify stuff in Debugging mode ;)).
Even with a IPC protocol you can still achieve alot (even event debugging/single-stepping will still work)
Question is how the IPC protocol is supposed to look like. Insane idea (but would be totally state-of-the-art): The Player could launch a "http server" and you interact with it through a REST API (return value are JSON or LCF "octet-stream"). Advantage: Lots of tooling, you could IPC via curl.
For comparison. What CMake uses: https://cmake.org/cmake/help/latest/manual/cmake-server.7.html?highlight=s
The new CMake mode which looks much more ugly, it works by putting files on the Filesystem and then CMake uses file system watches to detet when a file appeared (so kind file-based REST)
https://cmake.org/cmake/help/v3.18/manual/cmake-file-api.7.html
fmatthew5876
By fmatthew:
There's a few use cases I see really
For this, what we can and should do is isolate the interfaces we want to reuse from global state using dependency injection. This also helps with making Player itself unit testable. More refactors like the
Algolibrary for this.To be able to start and stop player within editor itself, yes I agree we need a very clean creation and destruction sequence that doesn't leak any global state between runs. We need this anyway for load game and player unit tests.
That being said, I wonder if IPC is also the way to go here. Then you could run a separate player binary and attach the interpreter debugger and other tools to it. We also again don't need to worry about player global state at all. Each player run starts and exits a new process for 100% guaranteed cleanliness.
The IPC approach would require us to add stuff to player to pipe the necessary data back and forth, as well as a protocol for the game strate (enhanced LSD?). That can be a lot of work but it would enforce a clean separation. If we did this though, it also opens the door to additional capabilities for regtesting and other introspection tools.
The biggest amount of work with doing IPC / networking is the serialization code, but we already have liblcf giving us a fast binary protocol.
If we don't go the IPC route, I would want to still see a very clean separation. Let's not pollute Player with random
// needed for editorhacks.Not going to IPC route would allow a much tighter and easier integration with edtior, and allow live editing while playing, which could be a big productivity booster for developers.
To run multiple editor instances for different games at the same time with their own embedded players, I would only do it by spawning multiple processes. Then we don't need to worry about player globals, ui globals, renderer state, audio state, etc.. etc... If needed a parent UI process can manage all the child ui instances. Trying to manage all the global state ourselves, especially for all the backend third party libraries I'm 99% sure will end up in frustration and failure, not to mention massive complexity. This also completely shields us to state cleanup bugs from multiple editor/player instances.
If we embed a running player directly into editor widget, we'll need this.
Options are:
Regardless of editor, this is in my near term future plans. I want to make sure new game / load game bugs are impossible.
We're very close to being able to stand up and tear down player game instances. Once the character PR goes in I'll be unlocked to refactor the player global state to achieve this.