4 ms·
Conceptually, I think it is harder and kind of a pain to code for at first. But one of the advantages I've found using it is the ability to completely decouple
by drblast 13y ago
Conceptually, I think it is harder and kind of a pain to code for at first. But one of the advantages I've found using it is the ability to completely decouple the state of game objects from the code that manipulates them. This gives you the following (rarely mentioned) benefits:
1. Saving game state is trivial (as is replaying it, like in a rewind or time-travel)
2. For garbage-collected environments, it's easy to completely avoid GC pauses by re-using old game state objects.
3. Adding existing functionality to any object is trivial.
#2 was the biggest win for me. I made some small bullet-hell style shoot-em-ups in C# that would pause for GC until I reworked the game into a component system where all game objects were stored in a table, and each row in the table contained all columns for all possible objects properties.
So when a bullet went offscreen, the row its state was stored in became available for the next game object (bullet, alien, etc.) The only step necessary was to wire that row to the various components that would control the game object. The GC pauses disappeared, and this made changing the game and prototyping extremely easy. I'd imagine this would simplify memory management in C++ in the same manner.
I also really enjoyed have things like "AffectedByGravity" as a component and the ability add objects arbitrarily into it, instead of some hackish inheritance chain.
- interpol_p 13y agoI mostly agree with you, I just found that trivial things — like drawing sprites — became cumbersome. In my case it involved adding the transform component, the sprite render component, any movement components (usually custom subclasses for the specific game) and then adding that node into the graph. When I wanted to hack away quickly on ideas I found I avoided my own engine because of all the typing it took just to get something up on the screen and moving. Or I found myself creating simple wrappers on top of the component system that killed the flexibility for the sake of brevity and readability. In my personal experience coding with components did something to stop the creative, messy part of my brain that just wanted to see things on the screen and moving as soon as possible.
- drblast 13y agoYeah, I see that. The reason I think what I did became so easy is that I took the component model to the absolute extreme. There were no objects at all, just a table of state data and a collection of functions you could add to an "entity." I think most implementations mix and match some sort of OO and that would get messy quick. What I did worked great for the particular bullet-hell style shmup I was making. I don't know how well it would work with other types of games, particularly those with game entities that had a ton of state that wasn't shared. With the bullet-hell game, an enemy shared a lot of state with the main character and bullets. An RPG might be a different story.