This is a post-mortem for the game OP Command, it will analyse techniques and methodologies used throughout the development of the game. The game is available online through Itch.io. Overall, the project went fairly well and the project was able to be delivered on time by the deadline, achieving the main goals being that it was a game that is inspired by Missile Command and the artist Bridget Riley.
Programming
Doing a programming focused degree it would be odd not to discuss how the coding went on the first project of Studio. The programming in the game went extremely well with little to no major roadblocks when it came to coding the game and having it behave in the way that I wanted it to. This can be attributed to a number of reasons:
- Documentation – Early and thorough documentation of the game through feature and technical specification documents helped with the direction of the project, and the technical specification document assisted specifically with the implementation of the project.
- Simplicity – The project that was scoped was simply an adaptation of the game missile command, which is an extremely simple game. This meant that there were less complicated code blocks that needed to be implemented and there was less chance of the code blocks breaking.
- Testing – All implementations of code were tested through rigorous playtesting and ensuring that most code blocks only did one thing at a time. This meant that testing code meant testing that the function ran correctly and completed it’s one task.
For future projects I will aim to do the following:
- Early Documentation – To reproduce the success of the coding aspect of the project early documentation should be a key priority when it comes to the project. Specifically, the technical design documentation as this document describes how to implement features in the game relevant to the feature spec. In the next project, I will aim to go more in depth when writing the technical design document to further improve the quality of the document.
- Rigorous Testing – Continually testing the features that were implemented is an important aspect to the success of programming the game. This will be done through playing through the game and checking the specific features implemented. Additionally, research will be done into Unity’s Testing Tools, into the possibility of implementing unit testing into the development process, depending on the size of the game and time it would take to implement the testing process.
Game Design
The game design and intended game feel is another important aspect of the game which creates the experience that the game intends. The final edition of the game was able to create the experience that I wanted it, this was realised through responses from the two playtests, the initial prototype playtests and the final delivered product playtest. This succinct delivery was possible due to the following reasons:
- Early Planning and Research – The early planning and research on Missile Command and Bridget Riley gave me a clear idea of the source material in which the project was based on. Additionally, having a short deadline for the delivery of the pitch forced me to create an idea and an understanding of how the game was going to work. This combined with the creation of a feature specification document allowed me to create the idea for the game and specify it out onto a document to construct a clear vision for the game throughout development.
- Playtests – The only clear way to discern the actual response of the game was to playtest it with other people and measure their reaction and responses. This was done on the initial prototype of the game and received a response that was very much aligned with my vision of the game. I was then able to reinforce the game mechanic and lean into these mechanics in the next phase of improvements and features added to the game.
For future projects I will aim to do the following:
- Early Planning and Documentation – Conduct research on the game and possible game mechanics early. Have a deadline for when the game should be pitched/documented to ensure that an idea is formulated quickly and concisely. Document the game with rules, mechanics and other game specifications to ensure a clear vision of the game has been detailed out early in the development process.
- Playtests – Have playtests fairly early into production in order to enforce a deadline where the game can be played at it’s minimum viable state. Additionally this will allow me as a developer to identify whether the game mechanics described in the feature specification document work and allow for adjustments early.
Time Management
Time management in this project was better than it has been than any previous project that I’ve worked on. Although the schedule was extremely short for production, creating a working game in a little over 3 weeks, all the milestones and schedules were hit. This was due to the following reasons:
- HackNPlan – Tasking to do items up in HackNPlan allowed me to identify what needed to be done during the week and assess whether I was ahead of work or behind on my work. I was then able to adjust my schedule appropriately to keep up with the work.
- Deadlines and Keeping Accountable – Having bi-weekly deadlines was both extremely stressful and useful to have in a project, it speeds up the development process and quickens the decision making process. There is a large difference with having a week to decide and having a day to decide on the mechanics of the game. Another aspect that helped with time management was being held accountable for doing our work by Tony and Steve.
For future projects I will aim to do the following:
- Continue Tasking up – HackNPlan allowed me to complete work efficiently and know exactly what I need to do when I sit down and do work. I will continue to task work up on HackNPlan with more and more detail.
- Meeting Deadlines – Will continue to create and complete deadlines assigned to me in order to stay on track with work that needed to be completed.
Leave a comment