Pitfalls of my current component implementation

So I sat down today with the intention of adding some sort of component to handle sprite animations. After deciding that I should probably make an AnimatedSprite component that inherited from Sprite I started to think about how to add it to my GameScreen class with the rest of my components.

For those who haven’t been keeping up with my blogs, I keep all my components together in memory in arrays – one array for each type of component. So now I needed to make a new array for my new AnimatedSprite component type.

I have GameObjects which then store references to the relevant component instances in an array. I have Player, Enemy and Bullet classes which all inherit from the GameObject class, and it was looking likely that I’ll need an Explosion class that does the same.

At the moment all my GameObjects are created in my GameScreen class. However this new Explosion needs to be created due to logic in the Player and Enemy classes. Should I then create some sort of ExplosionManager like I have the BulletManager so that I can have a finite number of Explosions that can be active at any one time?

The idea doesn’t appeal to me. I’d really like to be able to create GameObjects during the Update loop instead of having to make sure they’re all created during the GameScreen setup.

Surely there must be a better way? Perhaps I should try to emulate Unity even more and aim for some kind of “Prefab” GameObject that can be instantiated from anywhere within my code? How do I do that and maintain cache coherence? Do I reserve space for X number of each possible Component type and grab one when I need it? How do Unity do this? They have so many component types, as well as the “custom” script components.

I’m also not happy with how each of my GameObjects must be set up – there seem to be too many steps to adding a Component to a GameObject. This could easily lead to errors if you forget a step (which will happen). Perhaps some implementation of the Factory Pattern could help here?

Hmm, I have a feeling I’m heading towards implementing some actual Object Pooling system, with a pool for each component type as suggested by Cameron earlier this year. Then perhaps a Factory for each type of GameObject that encapsulates the setup a bit more? (I guess a Prefab is kind of a Factory) Someone, please stop me if I’m heading down the completely wrong path here.

If you’d like to have a look at the code for my current setup for a better idea of my dilemma then please have a look here. It is a bit messy because some of the old code from my pre-component version is still hanging around as reference for myself, but it hopefully should be readable.

(PS – I am reading more and more that OOP is hell and design patterns are the devil, but I cannot understand how to solve some of the problems I’m having without them. Do I need to go through some phase of better understanding how to solve these problems with OOP before I can properly understand how to solve them better with DOD or some other method?)

 

 

2 thoughts on “Pitfalls of my current component implementation

  1. Im not sure who is saying that design patterns are the devil. They definitely make my life a lot easier.
    However, using the wrong pattern to achieve something or implementing it incorrectly can leave people with a bad taste in their mouth.
    Maybe you could have a look at some existing code bases for engines (id tech 3 or something ) and compare it with your implementation?

    Like

  2. The simple way you are doing it now should be perfectly fine for most games but I agree it is less elegant, though you could test for the correct size of the different sets of components after your game was done so that there is less waste. If you do write your own memory allocator and are worried about cache cohesion I would allocate in large sets but at this point the simple way’s wasted space doesn’t look as bad.

    Like

Leave a comment