Insane Purple Space Monkeys
About the game
You are a scientist aboard a secret research station in space when disaster strikes: All the monkey test subjects have escaped their cells! Move your way through the station and tranquilize the escaped subjects before they can cause irreparable damage to the ship in this top-down shooter. Can you keep the situation contained, or will you be helpless to stop those insane purple space monkeys?
​
Insane Purple Space Monkeys was my first real experience working with a team to create a game at DigiPen Institute of Technology. The game ran on the Alpha Engine (a C-based DigiPen in-house engine) and the team consisted of 4 programmers, myself included. Through this project, I learned a lot about not just programming, but also how to make a game in a collaborative environment. My role on this team was as a generalist programmer, where the major systems I created were our projectile system, the sprite rendering system, and the UI.
Sprite Rendering System
The sprite rendering system was the first that I implemented for the project. The system allowed the team to easily create and manage various sprite objects as well as draw them on screen. This was my very first attempt at creating something that would be used by other members of the team and as a result, I had to think about how to make it as easily accessible as possible for someone who didn't know the system like I did. I accomplished this by creating a SpriteInfo struct that held all the aspects of a sprite you could edit (position, rotation, UV offset, scale, alpha, and texture) and created the sprite system around that. The constructor would return a SpriteInfo object that could then be modified as desired before being passed into the draw function which would apply those changes and draw the sprite on screen. This abstraction made it much easier for the team to utilize the system and get objects on-screen.
Projectile System
The next system I created was our projectile system. Bullets would be instantiated by the player and managed themselves, meaning the player just needed a direction and an angle (in our case, the mouse position relative to the player) and the bullet would handle the rest. In my previous classes, whenever we would create something similar, the player object would always manage their own projectiles so this was my first experience creating a projectile system entirely separated from the player. The implementation was not all that different, however. Upon creation, projectiles would add themselves to an array that would iterate through each projectile and call their update functions in each update loop. These individual update functions handled events like collisions, physics updates, and expiration timers. Bullets would travel a predefined direction upon spawning and would destroy upon contact with a wall or an enemy, or after a certain time elapses in order to keep from having too many projectiles instantiated.
UI System
Lastly, I created the UI system. This allowed for different HUD elements to be displayed on-screen such as an in-game timer, a life counter, and an enemy counter. While working on this, I ended up using a lot of the sprite system I had previously worked on which helped me get a better sense of how to improve that system. For example, the sprite system didn't have support for sprite text until after I began working on the UI. Before then, we had just been using pre-made text assets in our game which had been working fine for things such as our title and the menu buttons, but I knew if we wanted to have a HUD, we would need a sprite text system. At the time of this project, none of us had any real game design experience so we wondered how to communicate to the player that they had beaten the level. Our solution was to create the enemy counter in the UI so that players would know when they had defeated all the enemies in a particular level and that they were ready to move on to the next one. We also included a timer because we thought it would encourage people to play the game again in order to get a faster time. The desire for both of these features was the main reason I developed the UI system.
Takeaways
While I did get to practice many new programming techniques and implementations, I also gained much experience with the more interpersonal aspect of development. We used Trello as our task-tracking software and it was entirely new to me at the time. At first, I wasn't much of a fan because I had just used my own method for keeping track of my tasks and didn't really want to switch over but eventually, I saw the value of the practice. I realized that it wasn't just about keeping myself on track, but also seeing what the rest of the team was working on and seeing the overall progress of the project. We also held weekly progress meetings where we would discuss what we had done that week and what we were planning on for the following week. I found these meetings valuable for much the same reasons as Trello. They were a great opportunity to see how the game was progressing as a whole and to show off what each of us had been contributing.