Playground Panic #4 – Hierarchy, optimization and control

After some discussing with our SCRUM-master Simon Wulf, we agreed on having to change our code-structure. Due to reasons (mainly time-pressure and lack of experience), we handled sprites in our GameState together with the rest of the code. It’s pretty simple to do with SFML’s built in things, but for overall optimization and to avoid clusterfuckyness in the code, it’s much better to let the objects themselves handle these kinds of things and let the GameState stay in the unknown about what a sprite is (even though it comes automatically with the SFML-library anyhow).

This is a basic example of how our code-structure worked (aka. the spaghetti). We had some sort of dictatorship with GameStateA deciding most things that happens in the code, even things it normally shouldn’t have to do (like creating sprites and deleting things). It isn’t really the most effective way of doing things, so I started rewriting how our sprites were handled and made big changes in things like the GameObject and other super-classes.

This is a more healthy relationship between different classes. GameObject holds only the most necessary info and functions while it inherits from sf::Sprite. From there on, all the objects is in a hierarchy with the GameObject with the GameStateA only creating things like the PlayerObject and ProjectileObject. This is a more…classical system where the more “noble” classes handles the “farmers” and “workers”.

So instead of creating sprites and similar in big map/vectors before the creation of the objects, we only got textures loaded in that we send into objects upon creation, while creating the sprites used inside the classes themselves. We had some problems with the “special” kids (our GPS-system that tracks when kids are going to be picked up by their parents) that all got solved, simply by letting the objects handle it themselves. Since we do it this way, we got a lot more control over what object that we’re currently doing things to.

The deletion of objects are also handled this way, although we still got some issues with it at the moment. We’re most likely going to change so that collisions are also handled in the same as the sprites, but at the moment it works just fine the way we have it since there’s a lot of different objects involved the collision-checks. Later on when we add collisions with the actual level (like the house and hedge), we’re going to discuss if it is worth changing how it works right now.

@wulf The host was on maintenance when I remembered this, so it’s a day late now.