Exploring Asteroid Panic

I have couple of questions regarding the game.

First, wouldn’t it be more consistent to implement, say, Movement component that would contain both velocity and acceleration than have only Velocity as a component? Considering there’s actually acceleration in game.

Second, where the initial set of entities is populated? Starting from Main I see new ModelState(new RetroPanicModelFactory()), then (as was in my previous code version) I would expect in ModelState.initialize() something like createTenRandomEntities() but i see only RootNode creation and getters. So i’m confused where exactly should I initialize my scene?
Update: disregard 2nd question, found them in SinglePlayerState. Just got stuck with the Factory and ModelState somehow, sorry. Probably not the best day to code for me(

The simple answer is that objects can have velocity without acceleration… in fact, in this game all but one object has velocity without acceleration.

The more complicate answer is that it should make you uncomfortable in an ES based game to have a system that simply loops over components replacing them with different versions of the component every frame. For example, if Velocity and Acceleration were in the same “movement” object then every frame you’d have to loop through all entities with a Movement object and replace it with another Movement object with a different velocity. A system like that that reads and writes to the same component type is a sign of something wrong.

And as to your second question, it’s important to remember that things try to be as decoupled as possible. The ModelState only exists to give visual models to entities that require them. That’s it. It’s not meant to manage game state or anything else. Creating asteroids or ships or ufos or whatever is a game state issue and should be handled by something else. Otherwise every time you’d need to add a new game element you’d have to go and modify some code that had nothing to do with managing game elements.

Thanks, Paul!

Actually I was simplifying (to make it even more transparent for me) things by taking only those systems that would be absolutely necessary - from your code - and so I was looking into Main at first, and SinglePlayerState wasn’t there so I missed it looping between the factory and ModelState seeking where everything comes from. My bad. Thanks for clarifications, now I see that having generic Movement would result too much overhead. Yep, now it’s looking closer to the idea of refactoring - to have more small objects with fewer short methods. Thanks a lot.