This blog will cover my experience with the Technical Games Development module over the whole year, what I learnt from making the games and what I could improve upon. I will go over the 5 games I had a part in making and discuss what I felt I did well and what I could learn from.
TDEMO has let me experience the most hands-on module in the course, and gave me valuable practice with making games for a wide array of genres both individually and in a team, which also helped improve my teamworking skills and develop a sense of what is needed in a game development team.
Cubism
The prompt for Cubism was "Make a one-button game" with a hypercasual theme. A hypercasual game is supposed to be intuitive, quick to play and simple (Karnes, 2020). As my first game, I had no prior experience with Unity, not to mention I also needed to learn C# from scratch as TOGA was teaching C++. Coupled with needing to juggle work from the rest of the courses and the deadline being in 1 week and time was tight for making this game.
Reflection on Cubism:
The main challenge for me was not the time constraints or the theme, but rather learning to use Unity and code in C# from scratch. I used online tutorials and videos like Brackeys (Brackeys, 2017) to help me get a grasp of how to develop simple levels and game controls, which gave me the idea for a 3D Flappy Bird-inspired game.
Cubism ranked 26th out of 78 entries, which for my very first game I felt was a good first achievement. What I took away from this game's development was knowledge of how to use Unity's tools, create a basic menu system with scenes, and also what to put in a devlog as I was updating my log while developing the game. The game itself was, in my opinion, fairly bland - only having one button limited what I was able to do, and my lack of experience in level design meant I was not able to put much creativity into the game, something I felt would improve as I gained more experience with designing and working with Unity.
Terrible Electronic Arts
The prompt for Terrible Electronic Arts was "Make a incremental style game" like Cookie Clicker and Universal Paperclips. Incremental style games like Cookie Clicker "play themselves", only requiring a small amount of user input to get the game automated (Crecente, 2013). As it was the first time I was to develop a game in a group, I lacked one crucial bit of information: Source control. This was crucial because it meant that I mistakenly assumed that one person would have to do all the coding and then send it to another person to complete the game, and was caused due to my inexperience with developing games with Unity and in general. Nevertheless, we were able to complete and submit the game to the Game Jam in time.
Reflection on Terrible Electronic Arts:
By far the biggest issue while developing this game was the lack of source control. This meant that we were unable to check each other's work for mistakes and only one person was able to put the game's pieces together at a time. I ended up both coding and creating the UI and game mechanics, which caused both to suffer in quality as a result - bugs in the final build and a less-than-satisfactory visual UI design.
Terrible Electronic Arts ranked 11th out of 18 entries which reflected the mistakes listed above. I learned a very important lesson to do with source control, but also gained an understanding of how game development works as a group - reliant on every member completing their tasks for a finished game. For my end, I had no art skills whatsoever, so I needed the other group members to contribute on the artistic front, like drawing the symbols and the splash art.
Bane's Terror
The prompt for Bane's Terror was "a platformer style game with a fantasy theme". After having developed Terrible Electronic Arts, I now understood the importance of source control and used it to full effect in developing Bane's Terror in conjunction with my group.
For this project I wanted to step back and take a more passive role of design, compared to the task of both coding the game and designing the UI, which had the side effect of me not contributing as much as I could have to the game's development as expected.
Reflection on Bane's Terror:
As mentioned above, me taking the design role for the UI and menus caused me to contribute less to the game than I expected/would have liked, due to the game being more simplistic than I thought, and therefore there was less to do in terms of UI and menus. On the positive side, I fully understood the benefits of source control, including but not limited to saving changes to files while retaining previous versions and allowing members to work on the same bit of code without fear of impacting others (Levit, 2018).
Bane's Terror ranked 3rd out of 18 entries, a very good result which I attribute mainly to our group communicating well and working hard, as well as having planned aspects of the game well before development. Our group divided ourselves up into groups of coders, artists and designers, which I believe made a big difference as we could work in smaller groups and not interfere with anything the others were doing. However, there was still room for improvement - we spent much of the time before submission rushing to fix final issues and smooth out the game, which indicated our time management could have been handled better, perhaps with a timetable denoting when parts of the game should be completed.
Jet Panic
The prompt for Jet Panic was "A game inspired by Star Fox". By that definition, it meant "Limiting the player to moving around the screen while following a specific route ('Star Fox', 2021). We ran into a major issue during the development of this game; apart from me and two others, no one else contributed much to the development, leaving only 3 people to take on 7 people's workload. This massively impacted the way the game design was taken, owing to a severe lack of time.
Reflection on Jet Panic:
As mentioned above and in the dev log, our progress was hindered by the lack of manpower that worked on the game. I am very grateful for the two members that worked with me on Jet Panic, who were able to put together models for the game and design the singular level. This did give me the opportunity to work on multiple aspects of the game, including the rail scroller section which was fascinating to work on, as I learned how to manually adjust hitboxes of objects in the game, as well as expand my knowledge of designing menus and UIs. I also learned to build versions of the game that would run on a web page, which can be found on our submission for the game jam.
Jet Panic ranked 7th out of 13 entries, but notably ranked 2nd on Best Gameplay which I am very proud of, given the circumstances. I believe that given time and a proper group, we could have taken the game to a high level of completion.
S.T.U
S.T.U was Razorwing's submission for the coursework assessment of TDEMO, with the group picking the prompt "Dungeon crawler with one resource". "Dungeon crawling" is a type of scenario in video games where a group of players explore areas (dungeons) while battling enemies and looting treasure ('Dungeon Crawl', 2021), with the first known game of this genre being pedit5 on the PLATO system (Brewer, 2016).
This game was worked on by a group of 6 people, with 2 members later being added after Razorwing's creation, for approximately 5 months. However, both members who were added contributed nothing to the game's development, which required some originally planned aspects of the game to be cut from the final build due to lack of time.
Reflection on S.T.U:
S.T.U was a great experience for me as I was able to work on a game with people I knew for an extended period of time. For me, I found it enjoyable to develop a larger game that had more levels and mechanics compared to the previous Game Jams where we had a limited amount of time and a random group of people, which potentially caused issues with development.
Working on S.T.U alongside the other members of Razorwing taught me about the importance of teamwork and communication, which was essential for a game this size. Some parts of the game needed to be completed before work could start on the next parts, for example the art of the characters needed to be drawn before the animation could start, which meant that communication between the designers and the artists needed to be clear and concise. Fortunately, our group had no major issues on that front as we met up frequently to discuss and solve any problems.
In the end, however, we were forced to cut some originally planned features of the game from the final build due to several factors; the foremost of them being the previously mentioned 2 members not turning up. Our plan for development revolved around dividing the workload between 8 members, but we ended up having to cover for the missing 2. This meant that we had less time than was desirable to work on parts of the game, leaving some bugs in the final build and unimplemented features.
If I had the chance to work on the game again with the original members of Razorwing, I would reconsider the scale of the game given that we would have 6 people working on development, and implement features that were cut from the final build, like the upgrade menu and voiced dialogue.
Conclusions
TDEMO as a module has been a fruitful one for me as it has given me the opportunity to develop games for a wide range of genres and allowed me to build up my experience doing so. Throughout the 5 games I have worked on I have found aspects that I can improve upon and parts where I felt I did well. I reflected on what needed to be improved on in my dev logs and often did so in the next Game Jam, and I feel that I have definitely become a better game developer after this module.
Cubism taught me the basics of Unity and game development, and made me realize that a game's development isn't just about the gameplay mechanics, but also how you build the game's levels, artwork and how you present the finished game to your audience (in this example, the Game Jam and how I did not have any splash art for the submission).
Terrible Electronic Arts taught me the importance of having a team for development, wherein each group needs to have at least one individual coder, designer and artist contributing towards the finished product. Lacking any one piece causes the game's quality to deteriorate as a result, and emphasizes the need for good teamwork in development.
Bane's Terror taught me that every game should have source control, and that proper prior planning before development as a group pays dividends. Splitting up tasks between members allows for higher efficiency when developing, similar to the extreme development (XP) methodology where pair programming is prioritized (Raman, 2014).
Jet Panic taught me to compromise and adapt when time was running short and focus on the things that were crucial for the game to run. It further tested my ability to cooperate well and work with members of the group under a strict time limit, and forced me to multitask on aspects of the game I did not plan to work on originally.
S.T.U brought all my previous experiences and lessons together for one final project, which pushed me to the limit of my capabilities while simultaneously having to juggle other courseworks for other modules. It taught me to manage my time properly, collaborate with other members of Razorwing like an actual game development team would, tested my creative capabilities in terms of level design, UI layout, and level mechanics. But most importantly, S.T.U made me understand how an actual game is brought together over the course of its development cycle, thanks to the effort of each individual.
Bibliography
Brackeys. (2017, January 23). How to make a Video Game—Getting Started. https://www.youtube.com/watch?v=j48LtUkZRjU
Brewer, N. (2016, July 7). GOING ROGUE: A BRIEF HISTORY OF THE COMPUTERIZED DUNGEON CRAWL. https://insight.ieeeusa.org/articles/going-rogue-a-brief-history-of-the-computerized-dungeon-crawl/
Crecente, B. (2013, September 30). The cult of the cookie clicker: When is a game not a game? https://www.polygon.com/2013/9/30/4786780/the-cult-of-the-cookie-clicker-when-is-a-game-not-a-game
Dungeon Crawl. (2021). In Wikipedia. https://en.wikipedia.org/wiki/Dungeon_crawl
Karnes, K. (2020, July 12). Hyper-Casual Games: Mobile Gaming’s Greatest Genre. https://clevertap.com/blog/hyper-casual-games/
Levit, M. (2018, May 22). Importance of Version Control and Why You Need It [Servian]. https://medium.com/weareservian/importance-of-version-control-and-why-you-need-it-aae53dac208a
Raman, S. (2014, April 2). EXtreme Programming The Methodology. InfoQ. https://www.infoq.com/articles/implementing-xp-methodology/
Star Fox. (2021). In Wikipedia. https://en.wikipedia.org/w/index.php?title=Star_Fox&oldid=1019587969