This week my main objective has been focusing of managing how our game handles entities (basically objects of the game like: obstacles, powerups and background objects). The way our game works now is that in the beginning the entire level structure is imported from a couple of text files and straight after that we create new instances (copies) of the objects and places those instances at the spots specified in the text file.
This might sound all good and great but it’s really not. With this system our game engine will have to make calculations with and between several hundreds of instances. So my work this week is to solve this problem by making a system that actually builds the level in front of the bat and deletes the level behind it. The tricky part is also that instead of deleting unused entities completely, the engine will actually just mark them as “unused” and place them in a pool. This pool is then available to the level creation code so before a new instance of an object is created the pool is checked. If an unused object is found in the pool it is reset and placed to act as the upcoming object.
Now let‘s make this concept a little more clear with an example.
The bat eats a lot of fireflies in a level, these acts kind of like the coins in a Super Mario game. Throughout a level there might be anywhere between 50 to 200 fireflies that the bat is able to pick up. With the dynamic level creation tool the fireflies will appear into the gameworld when they are just outside of the right border of the screen. If they are eaten by the bat or leaves the left part of the screen they will be placed in the pool. Since there’s never more than maybe six to eight fireflies on the screen at any given time the game will only have to create about ten fireflies that are used and reused throughout the level.
Hopefully this will result in some noticeable improvements in the performance of our games but most likely it will just be behind the scenes glory of a more agile game engine. It will also enable us to make huge (or infinite) levels if that is wanted.
Korv makes games 
The text tells very clearly what you have done. However, it is a bit weak in the how and why. Maybe you didn’t want the text to get to technical, but as it stands, the only explanation is that you did do it. I do believe that this post would have more value to readers if it taught them, at least in passing, how you did it on a technical level.
As for the why, you didn’t really tell us directly what prompted the decision to make it in the first place. You did tell us that it would improve the performance of the game, but unless that was a problem it would have been a waste of time. If it is so that you can create huge or infinite levels, then say so, and not just a non committed ”if we wanted to”.
The text as written is very engaging, and fine read, but suffers from the lack of visual representation. The first and only image is poorly cropped, but I assume this is an oversight. You could however do a more visual representation of what you did very simply in paint or photoshop, simply by making a three or so picture explanation.
I did however like this text alot, as I said above.
GillaGilla