This week I have accomplished a couple of things.
I changed what the Object-Manager stores. Previously it stored GameObjects but now it stores pointers to GameObjects. This prevents the object you want to store inside the Object-Manager from being destroyed when it gets copied over to the map container. Due to this change I also managed to fix a couple of memory leaks concerning the objects sprites and colliders not getting destroyed. Another thing I did was making the game scale according to what resolution you have. This change prevents the users who plays the game at higher resolution from having an advantage due to the increased field of view. But the main thing I did this week was the revamp of the State-Manager.
Previously we had no way of pausing the game. If you wanted to take a break from the game you’d have to restart from the beginning again in-case you lost while you were gone. And that’s not acceptable. So now instead I have changed the way states are handled and gave each state a couple of new functions and member variables.
This week we’ve been working hard on getting an alpha product done for the presentation that will be held in from of the class.
I’ve made some finishing touches on the light engine so that it e.g. no longer have transparent shadows. This was accomplished by using blend modes. I’m quite familiar with using blend-modes because of my previous projects when I used to program a lot inside the game engine Game Maker. But I’ve gotten more and more used to how SFML works now and it feels great!
But enough of that. Today I’m going to write about how Haunted Light handles all it’s different objects.
This week and the previous one have been great! We’ve managed to fix most of the game engine’s core features. In the forthcoming days we’ll start working on some simple gameplay implementations.
The development library we use for Haunted Light is SFML (Simple and Fast Multimedia Library). Well the name speaks for itself but it’s a simple-to-use framework to communicate with all the Input and Output devices of the computer. Without a development library you’d have to write code that directly sends instructions to e.g. the Processor or Graphics Card.
Onto the main topic of this post. I’m going to write about the structure of the “sprite-manager”. The sprite-manager takes care of loading all the images to the game, which in turn gets made into sprites. Sprites consists of a texture (i.e. image) and a rectangle shape which determines what part of the texture to show when in-game. The reason you’d have a sprite-manager is to make sure that the same textures isn’t loaded multiple times and take up an unnecessary amount of RAM.
I’ll go through what the functions and arguments are and then explain the details of how everything works. So that you easier can follow the next paragraph. Continue reading