Since the age of 4, when my father first introduced me to video games as a medium, my passion for games, and in more recent years, game development has continued to grow. Therefore, I was thrilled when the opportunity came to develop a game in my final year at University. My dissertation title was “Tower Defence game in a Linux environment” and, given that the majority of my game programming experience lay in Python until this point, I opted to work on my proof of concepts in this language, at least initially.
During the various stages of pre-production and research, I recalled my 1st year Games lecturer mentioning a graphical library for Python called ‘Pygame’, which I’d looked at briefly. However, I was promptly forced to forget about this resource at that time as we were using the CodeSkulptor environment, which could only support its own, proprietary, libraries.
As I continued, however, I slowly learnt of the versatility of the Pygame library and found the documentation for it much less intimidating than that of many of the alternatives. Furthermore, I discovered a very active community of people constructing new and interesting ways of using the tools, generating helpful tutorials as they went.
One of the first challenges I faced was how to implement some form of a menu, such that the user could navigate the various options within the game. To help with this issue, I created and then consistently re-worked a button class, through which I passed a function’s name and any required parameters, as parameters of the object itself.
I was quite proud of myself as this acted as a rather effective workaround for having numerous buttons that each enact their own respective behaviours, even if not the most elegant solution.
Furthermore, every element of the menus and the user interface in-game, were all created utilising only the Pygame library, hence the complexity. In retrospect, further research and the discovery of alternative graphics libraries for such tasks, such as ALBOW, would have saved me a great deal of time.
Here we can see a component of the game that was never previously planned for. This Map Editor was an impromptu idea which I was able to work on and implement in a short period of time. Beyond this, there were only two elements that were not totally completed. The first being the writing to & reading from files system, which remained somewhat temperamental for a few more days. The second feature being the functionality that allowed for the user writing the name of their map on-screen, which I only learnt how to implement a day or two prior to the final submission date. Upon completing the path, a quick test is run to guarantee that all tiles are connected appropriately, at which point the player is allowed to name their creation, and promptly play it upon return to the main menu.
The Map Editor worked better than I initially anticipated, and still does to this day, with the screen warning the player of any points at which the path does not connect or has multiple connections, something which I was not able to execute in the time permitted.
The final and most crucial component of this project was the game itself, which consists of a wide choice of maps, of which the player can play up to 20 rounds on each. The player begins with an initial budget of 20, which can be spent on various different types of towers. Once purchased, the towers can then be placed anywhere in the level (excluding tiles on which a path occupies) in order to best prevent the enemies (or “creeps”) from advancing. The goal for the player is to prevent the creeps from reaching the other end of the level, and taking the players health down to 0. With each round, the number and variety of enemies increase exponentially, but with that, so too does the funds given to the player. This is because, as the player successfully eliminates enemy creeps, they are awarded funds to their budget, which they can then use to buy bigger and better towers.
At any point, the player can opt to save their progress on said map, and continue on from that point at a later time. This also means that, if such progress is saved, some key statistics from the saved data will be displayed on the level select screen to signify this. Further, more in-depth statistics are displayed in the window once the game is opened. Similarly, one additional feature that was added to the UI rather late into the game’s development was the ability to select any tower or creep on the screen at that time. Once this is done, all of the selected entity’s information is displayed alongside the game, such as, how much the tower costs, what variation of creep the selected enemy is, or even how much health they have currently, and out of what total amount.
Overall, I am incredibly proud of this project, especially given quite how much time and energy was invested into it, as no previous projects of mine required nearly the same level of attention as this. This was my first attempt at taking all of the lessons that I had learnt in my previous three years at University, specifically in regards to Object-Oriented Programming, and implementing them, single-handedly, into a game.
If I was given the opportunity to further develop this project, I most likely would have spent more time refining the graphics and the amount of variation in the gameplay. This is predominantly due to neither of these elements being hugely focussed on during development, given that these were not elements that were being assessed. However, in spite of this, I think I adequately displayed a wide range of talents in this project, skills that I have only increased my proficiency in since. You can find a clone of the original private repo here: [Git Repository].