I had a similar experience as you, these can surely be used for so many things! But then realised they were basically built for the renderer and that's it. The 'off screen' worlds is a good example.
So, my case is. I want to run a game as a client (render), a host (render+logic) and headless server (only logic). Plan is to run Logic with MinimalPlugins always and graphic interface with DefaultPlugins. 2 kinds of queues, between logic and client, channels for local and UDP for remote clients. I found it easier to implement with regular threads and channels than with subapps. To be honest I was not able to launch subapp even once 🙂
You can also create two separate "front-end" binaries (one for client and one for headless server), that both depend on a "back-end" shared library. The backend contains all the game logic and a connection/network manager. The headless server then just bootstraps this back-end. The client can then either connect to a headless server using the network facilities, or run the back-end itself (all within the same ECS world, so you don't have to pass around data to and from the back-end).
I went looking around and found some interesting by using the sub app for network for server and client testing. But knowing there limited examples for sub app that need to know more which is lacking how set up some simple thing is not easy.
Good video. Subapps will also be helpful for netcoded projects working with rollback worlds.
I had a similar experience as you, these can surely be used for so many things! But then realised they were basically built for the renderer and that's it. The 'off screen' worlds is a good example.
So, my case is. I want to run a game as a client (render), a host (render+logic) and headless server (only logic). Plan is to run Logic with MinimalPlugins always and graphic interface with DefaultPlugins. 2 kinds of queues, between logic and client, channels for local and UDP for remote clients. I found it easier to implement with regular threads and channels than with subapps. To be honest I was not able to launch subapp even once 🙂
You can also create two separate "front-end" binaries (one for client and one for headless server), that both depend on a "back-end" shared library. The backend contains all the game logic and a connection/network manager. The headless server then just bootstraps this back-end. The client can then either connect to a headless server using the network facilities, or run the back-end itself (all within the same ECS world, so you don't have to pass around data to and from the back-end).
I went looking around and found some interesting by using the sub app for network for server and client testing. But knowing there limited examples for sub app that need to know more which is lacking how set up some simple thing is not easy.
Oh testing multiplayer would be a good use for sub apps since they work as self contained app and the main app could work as the network layer