Entity spawning and Level creating
|
The big problem we faced this week is related to spawning enemies, and the lag that follows when improperly handled. So, the pre-beta testing happened. We had no level, no challenge, no goal. We had enemies that spawned at the end of the screen in an infinitely repeating fixed pattern, and the ability to interact with them. Not very impressive. What we needed was a way to build a level, and none of us had any idea of how to do it properly. Another problem facing us was the fact that we also have two gamestates, one for the gamespace outside of the train, and one for the inside. The reason this is problematic is that when we switch between the states, we also need to clear the screen of all enemies, projectiles etc, since the gamestates share the respective enemymanager and projectilemanager, and they have no knowledge of what state they are currently serving. The easy solution, to load all enemies as we start, and have them idle until close enough to be relevant to the player was as such made impossible, as they also would be cleared away from our container of active enemies. Since we dont want to touch the container of inactive enemies for reasons other than grabbing them out, should we create a third container for enemies waiting to be activated along with the position needed to trigger them? It could have been reasonable, except for the fact that it would remove the benefit of pooling our objects. We want to be able to use the same three entities of each class for all occurrences of that class in the game. Taking an idea from the previous solution, we realised keeping track of an trigger-position is very helpful, since this allows us to spawn multiple enemies upon the player crossing a single threshold. This lets us spawn them in formations, rather than having the entities closer to the player activate first, and if the player then stops moving, the rest of the pack not moving to engage together. We figured what we would make would need to handle spawning using nodes containing: Trigger position, the type of the object to be spawned, and its position. However, hard-coding single class to create these nodes, and creating them internally upon startup felt like a really bad way to do it. One of the issues is that it would be hard to read and modify by the non-programmers in our team, and even for the programmers doing that kind of work inside the executable code doesn’t sound like the best of ideas. And so I made a class which at startup reads a file containing five numbers, representing the different values in a node (Trigger position, what type of object (enemy, other obstacle, powerup etc), what kind of object in that type, and finally x and y position). Every such node is then stored in an container ordered so that first events to be encountered are at the top of the container. A benefit of ordering the nodes is that when checking for spawns only the top node needs to be checked, instead of looking at every single node. One issue with this though is that creating the level is real busywork.
There you have it, our game now has a way to build a level, and soon (I hope) we also will have a full playable level! Time to get some well deserved rest!
Until next time
 |
