What is the right way to get data _out_ of a sub_app?

[bcolloran]

I'm working on a networked game with client prediction+rollback, and as the project grows I'm getting tied in knots. For cleanliness and encapsulation, I'd like to try to break the state and logic responsible for simulation out into it's own world. I'll be following the proposal by @djeedai in #7893, but for now a SubApp seems to be the way to go.

There is a clear path for getting data from the main app world into a subapp: as described in the SubApp docs and issue #7290, SubApps can be created with an extract function that is called before the sub app schedule is run, and that is intended to "extract" data from the main app world into the sub app world.

There does not seem to be a best practice for the reverse direction--what is the recommended way of getting data from the subapp back out to the main world? I see that @recatek asked that question in the discussion on a recent PR, but it looks like it was not answered there. The desired behavior would be:

• "extract" data from main app to subapp (local+network user inputs)
• run subapp schedule some number of times (determined by main app)
• immediately "reverse extract" a little data from subapp to main app (for rendering and UI)

For bonus points: In the architecture what I'm describing, would it be possible to additionally extract data from the simulation sub app directly into the render subapp? Any pointers on how that might be done?

Thanks!

[bcolloran]

@james7132, I see you have done a lot on this topic -- I wonder if you have any recommendations or might be able to suggest where to look?

[djeedai]

Maybe someone from @bevyengine/ecs-team can provide guidance? It feels like some kind of reverse extract (or extract from sub app) would be valuable in general. Although it does raise the question of sync points and parallelism (since extract requires World write access), though not sure there's a good workaround here.

[ruffnext]

I also encountered the same problem. I did some calculations using compute pipeline, but i did not know how to get the data back to main world excepting using global variables...... :(

[djeedai]

Making a separate "answer" because although the ask about reverse extract is definitely valuable, I'm curious why you need it for network prediction and rollback, if you don't mind sharing @bcolloran ? I have a bit of experience in that domain, and it feels like if I had to do it for Bevy I'd write a few exclusive systems running at very specific points in the main World to gather and apply updates, rather than moving all into a separate world. Is the issue that the main world contains a mix of things you care and things you don't care about? Don't you already tag with a component the entities you want synchronized over network? Or is the issue related to rollback and the separate world used as snapshot? Thanks ☺️

[bcolloran]

Is the issue that the main world contains a mix of things you care and things you don't care about?
Don't you already tag with a component the entities you want synchronized over network?

@djeedai, I was trying a strategy that is similar to how I believe Photon Quantum works: deterministic ECS for core simulation, and only syncing inputs across the network rather than needing to sync entity+component states across the network.

For this strategy to work, deterministic simulation is required, but that's not natively supported in Bevy, so it involve a bit of overhead (both engineering+cognitive overhead as well as runtime overhead). I therefore I wanted to keep only the core of bits of state and logic required for this deterministic sim in one lightweight sub_app with minimal plugins, and keep things that are outside of the simulation and don't need to be deterministic (rendering, input collection, menus+ui, network handling, etc) in the main app to avoid that overhead for those non-sim parts. This also avoids the extra bookkeeping needed to mark and track which components and entities are eligible for snapshot+rollback: I know that everything in the sim sub_app is eligible for snapshot+rollback, and anything in the parent app is not, so things like extra tag components are not needed.

I really like this architecture -- it just makes sense to me and feels clean and organized compared to other approaches I've seen, and I wanted to give it a try -- but I can't necessarily recommend this approach for Bevy currently. I've definitely ended up swimming against the current quite a lot.

I think the team working on Jumpy also uses this architecture. As I understand their story, they started trying to get this architecture working in Bevy and decided that it would be easier to write their own deterministic ECS for simulation logic and use Bevy only for rendering. I'm not quite ready to do that, but I can understand why they did.

[djeedai]

Ok that makes sense, thanks for sharing!

[ElliottjPierce]

I've been struggling with something very similar in terms of syncing worlds for multiplayer. I recently put out a PR to hopefully make this a little easier: #17198. If ya'll want to weigh in on it since you all seem to have a similar use case, I'm all ears.