Evaluation
Presentation
Figure 1 - Final project presentation
A presentation demonstrating and evaluating my game to an audience was held, seen in Figure 1, alongside assessing the process of development. (See the slides utilised during the presentation in Figure 2). The presentation clearly demonstrates my clear design process, adaptation to time management and what I’ve learned throughout the project. However, more technical language could’ve been used to further clarify my understanding of more complex topics, alongside more proof of the research that went into forming my ideas and adapting based on feedback.
Figure 2 - project presentation
comparison
Comparing the game's original vision and sketches with the final build demonstrates the amazing execution of most ideas (Fig 3, Fig 4). Even places that were largely changed during development, such as UI and HUD elements (Fig 5, Fig 6, Fig 7), turned out extraordinary and perfectly served the game's overall theming and design. -
Figure 3 - Early sketch of a level room (Left) and the final design of said room (Right)
Figure 4 - General level design concept (left) and a similar room seen in game (right)
Figure 5 - Early sketch of menu design (left) and the final menu design (right)
Figure 6 - Early HUD design (left) and final HUD design (right)
Figure 7 - Archive concept sketch (left) and final archive design (right)
- However, some elements were excluded from the final project. Whilst none of them hinder the final project by being left out, they would’ve brought considerably more personality to the project. Such as the previously discussed lacklustre level decoration, the menu character changing poses depending on the current UI element selected (Fig 8) or further expansion of audio elements with player sounds and more diverse enemy audio. Whilst it would’ve brought more life to the game and helped perfectly align the outcome to the early sketches, the game is already a monumental achievement and doesn’t diminish the accomplishments of the final product in any sizable way.
Figure 8 - Early sketches for character poses on title screen
Sticking to the plan
Comparing the click-up board at the start of development to the end can provide some great insight into the success of planning. In past projects, planning boards (previously Trello) would fluctuate in scale, adding more features or expanding ones that were left as vague tasks in the original plans. This project proved different, whether through past experience informing how this planning board was set up or the move to click-up providing improved planning features, the board remained mostly static, with all the planned features laid out with a reasonable scale for ambition. And by the end, excluding features that were cut due to lack of time and not being of high priority, most of the click-up board had been cleared (Fig 9). The change to using Click-Up over Trello was a refreshing and needed one, allowing for further clarification and organisation of features and their prioritizations, helping with the overall production of the project.
Figure 9 - Design section of Click-Up board, At the beginning (Left) and End (Right) of development
Moreover, the plan still had some areas that fell short. Leaving the second round of testing so late in development meant that the feedback gained wasn’t nearly as helpful as it could’ve been, although the balance changes that came as a result of the playtest should hopefully help the project thrive in an exhibition setting. Alongside this, a heavy emphasis on design meant that a few major bugs, such as collision issues and clipping out of bounds, had to be ignored in favour of ensuring a more complete project in line with the original goal and vision for the project.
During planning, Tuesday was marked down as a break day, in which development on the game or blog would be avoided. Ensuring that overworking and eventual burnout wouldn’t become an issue and guaranteeing a consistent high standard of development. Whilst this plan was upheld for a week, I quickly succumbed to my own pressure to constantly be working. Even though I did take days dedicated just to drawing or mood boards to help balance it, those tasks quickly became synonymous with the project and began to cement the burnout. Leading to the project consuming my every thought, the very thing I wished to avoid by taking breaks. Luckily, I had outside support that eventually convinced me to take a week break for not only the project, but my own health. Whilst I can’t shake the feeling that the break led to a less complete outcome, I wouldn’t be nearly as happy and proud at the end of this project had it not been for that break.
personal goals
As mentioned at the beginning, a large part of every project I do is to further personal development and design skills to assist me in future education and careers. Which is displayed in abundance throughout this whole project, such as developing more advanced coding techniques in Object Oriented Programming or concepting and planning code before putting it into practice. However, there are still some more advanced aspects of OOP I’ve yet to learn, such as polymorphism, which I can incorporate into future projects to further my skills as a developer. On top of this, I also want to further develop the game world's story and characters, and given more time in the project, I would’ve further written and expanded on this. For the time being, these ambitious ideas remain in my head, and will be saved for projects yet to come.
conclusion
In conclusion, while the project is missing areas that could’ve provided more personality or gameplay, judging the project on what it lacks undermines the incredibly vast talent, ability and love that went into the games production. The project serves as a monumental display of skills, such as technical, design, planning and overall project management. “Match Made in Heaven: HALO WARS” serves as an incredible showcase of ability and a replayable fun and engaging first-person shooter.