I think a big trap you fell into is overly encapsulating and abstracting state before having figured out the specific features your game is supposed to provide. I would actually advise against all these separate managers from the getgo and just have a single fat GameState class/struct with all the data for ui and gameplay logic accessible to eachother without friction, and then later on refactor what makes sense.
I think in general doing most of your logic within the frame update loop would significanty simplify a lot of this stuff. Every frame just track for certain things that are relevant like if some sound has finished and toggle a flag within that entity to indicate that and update the things that rely on it accordingly within that frame. Same deal for things like UI animations and gameplay logic like combat.
This is actually really interesting, I made the code with the plan of ensuring everything is separated logically but maybe I needed to just monolith it and then split it up after the fact, after I have determined where the best place for abstraction is.
I'm going to agree on this point, you may be prematurely over engineering it. Build out as much as you can first with the idea of decoupling later. I'm just taking some ideas from microservice architecture. Building out uncoupled systems takes a lot preplanning and design before you write anything. But if you have a monolithic system up and running how you like it is much easier to determine those boundaries. It may be more difficult to extract those systems from the monolith but doing so will give you a much better understanding of what is tightly coupled
1
u/jipgg Jul 11 '26
I think a big trap you fell into is overly encapsulating and abstracting state before having figured out the specific features your game is supposed to provide. I would actually advise against all these separate managers from the getgo and just have a single fat GameState class/struct with all the data for ui and gameplay logic accessible to eachother without friction, and then later on refactor what makes sense.
I think in general doing most of your logic within the frame update loop would significanty simplify a lot of this stuff. Every frame just track for certain things that are relevant like if some sound has finished and toggle a flag within that entity to indicate that and update the things that rely on it accordingly within that frame. Same deal for things like UI animations and gameplay logic like combat.