To lead on from this, if Zer0 Fr1ction were to have a full production schedule in order to be launched as a AAA title, there would be various games we'd have to compete with, and some more than others. Franchises like Mario Kart, whilst similar, aren't direct competitors since that series goes for a more casual and family-friendly vibe, however the Sonic and Sega Racing games will be compared to us a lot. This is because those haves have various similarities to ours, like having a 7+ age rating, being fast-paced and utilising a randomised item system. However our game will be able to differentiate itself in the market due to its unique anti-gravity mechanic, allowing players to drive up vertical walls leading to a lot more varied and interesting track design.
Our group overall collaborated very efficiently, and like every team we went from various different stages, to norming, storming, performing, etc. Fortunately, though we did have various instances of storming throughout development as noticed in the group meetings, in the last few weeks we were placed mostly in the performing stage, where we were able to consistently churn out quality content with a good overhead into time management, allowing us to also make up for the lost time of any group members.
Throughout the duration of the project I found myself having to stand in for team members who were lacking and/or behind on their time management, and took roles I wasn't planning on doing quite so extensively. This collaboration from me affected me and my own sprint plans in a number of ways, as well as those of others. For example a 3d modeller giving me some models late had the effect that I had to redesign and rebuild the lighting in all of the maps, meaning I was delayed in sending the levels off to the programmers for testing, which had a knock-on impact on them too. Fortunately to mitigate this to the best of our abilities we made the most of our varied Belbin and Tuckman roles, and as plant/ protagonist I could inspire and motivate others to work during tough times while being able to act as a productive role-model to the rest of the group.
I finished the project on-target and on-time, as referenced by the musts and shoulds in the task board and sprint plan. This was greatly assisted by our group's time management, as also supported by our weekly sprint meetings where we could update everyone with our progress. The task board in particular was very useful as a visually appealing indicator of where everyone in the group was at at all times, with it being very easy to change on the fly and tick off when individual tasks are completed, with individual percentage bars for each sprint to boot. This enforced our group's very effective collaboration, for example allowing a 3d modeller who was slightly ahead to assist another one who was behind, ensuring our group as a whole was never a week or more behind as a result. These time management materials meant that I could also use them myself to manage my own tasks for each week as I just focused on the game design and level design panels, as I planned out days where I'd tackle certain objectives and then mark them off for all to see afterwards when done, allowing me to record my own progress for my blog and keep track of where I am at all times as to ensure I don't fall behind.
 |
| An example from our Trello board showcasing the individual tasks making up one of my level design sprints, and how now they're all ticked off the progress bar shows 100% completion in an easily digestible manner |
For the group's risk management a huge factor of this and ensuring no substantial loss of work was keeping regular backups of project files, especially before a merge. As you can see from the picture below of some of my personal backups, I ensured I created a copy before and after every working session to minimise any losses, and if I didn't backup my files before a project merge with the programmers in particular during lessons, it could be catastrophic if some errors were to occur and we potentially lose weeks worth of progress. The group Google Drive and GitHub were also other professional resources we could use to minimise any risks, as we could upload any updated script or map files to be directly merged into someone else's project file online without having to wait until the three days a week we're in uni together to do so. Likewise all of my produced assets followed our strict risk management guidelines outlined at the start of the project, such as certain 3d models being constrained to certain poly-budgets and texture sizes, as without these our game could become too bloated over time and begin to have severe performance issues as more and more unoptimised assets get added to the game.
 |
| A selection of some of our project file backups, which are all individually dated allowing us to view which is the latest one and how old previous editions are |
The Windows 10 Creators Update majorly halted my progress with Unreal Engine 4 within the last few weeks of the project, which is a massive risk which struck during the project's crunchtime. As it's a universally known error that affects version 12.5 of Unreal as seen by research online, which prevents the user from opening up any of the toolbars or right click menu prompts quickly, forcing the user to wait anywhere from 15 seconds to a minute each time. And it also affected other members of our group such as Gus, since this Unreal version is the one installed onto the university computers and we must follow professional working practises by using that specific edition. This plagued us for around a couple of weeks, majorly hindering our effective time management. Fortunately due to effective group collaboration and communication we managed to finally find an online fix, involving putting '-opengl' inside the properties of the Unreal shortcut, allowing the software to thus work properly again. This setback costed us some time, but we were at least able to continue production and it wasn't halted entirely, it was just a risk we had to make note of in our Trello task board and sprint management plan.
Research was another important factor which came into play for the duration of the project to support our development. As previously mentioned we conducted research into similar racing games as a form of market research, but I also browsed a plethora of Unreal 4 tutorials and documentation online in order to assist me in my engine-work. I wouldn't have been able to produce the quality work that I did without these tutorials, as I'd hardly ever created materials in Unreal before this project, and never touched the particle system before. I was able to gain a lot of new experiences and knowledge from it to take forward, and this research very much helped increase the graphical fidelity of our game.
 |
| A screenshot showing some of the particle effects in one of the levels, with things like the hex bubble effect being impossible for me to create without developer research! |
Early plans and designs were yet another crucial element during the early stages of production! For example, as shown in one of the very first development log entries, I drafted out 3 different potential track designs for the first track, and we as a group held a vote to see what the general consensus was on the best layout. Afterward I laid out the track in-engine using BSP to determine the scale of everything and where models would go once finished and imported, and then created a draft anti-gravity version in 3ds Max using the same scale. The reason the track went through all these stages of development and I didn't just instantly start making the final piece, is because many smaller changes were made throughout each iteration, as more time and care is put into the track's overall design. It allows for the track to end up being of a much higher quality meeting the standards set in the quality plan, as without all this precise planning it would have ended up as a much less enjoyable experience to play through since there would be much lest testing and thought involved in the development process overall.
Likewise testing plays into this very well, with all sorts of different types and methods used throughout the creation of our game, all changing depending on what's best on the situation. White box testing was very useful from a developer standpoint, block box testing greatly assisted from a gameplay perspective and user testing near the end of development was a great resource coming from people who don't know much about our game and what it even is, giving us a fresh outlook on things we as developers may have missed. All of these and their applied scenarios allowed us to perform certain stress-tests to determine whether or not our game meets certain outcomes, and from the perspective of a game and level designer this comes a lot from the design of the track. From seeing if there are any bugs or glitches that tie into the programmers' code (like falling through the floor), to determining if the level contains as many game design techniques as possible (such as semiotics with the track standing out from the environment, and the endogenous value with the placement of pickups within it). All of this comes together to create a cohesive and fun experience that just wouldn't be possible without the small but various tweaks testing provides.
We were overall very successful at meeting the group project's success criteria as a whole, managing to reach all of the musts and vast majority of the shoulds, even dipping into the coulds here and there (with us managing to make four tracks for example!) However we managed to meet as many outcomes as we could, we have functioning mechanics with anti-gravity, items and AI, we have four working and highly-polished tracks, and we also have a huge assortment of 3d models and graphics developed for them too. We also met the target audience requirements to great success, and I feel the theme of the game and its visual style really nail down that PEGI 7+ target audience, with the cartoon violence and gritty realism being the two main factors which secure that rating which we were aiming for all along.
I applied a lot of the feedback from previous units into this final project, especially in regards to the Game Design and Environment Design modules, with those being my specialist subjects. In regards to the level design unit I tried to make the maps feel a lot more cohesive, as if they're one big living space, rather than disjointed areas which don't transition well to each other in order for the player to truly be able to get immersed in the world. Likewise for game design, as main game designer I tried to ensure as many game design techniques got implemented as possible: endogenous value with your player's position and the item pickups, semiotics in order to make the HUD and environment understandable (you can't go through red barriers for example), having a good flow channel with the game's track design using an avatar-based interaction model, etc. All of these different elements I previously researched all come together to form a substantial package, and the inclusion of these different elements is evidence that I've taken what I've learned from the first year of uni and applied it this year into my work.
Our prototype game will as be professionally presented at our end of year exhibition, with an entire cornered section of the room dedicated to Zero Fr1ction. How this is going to be presented is the work will be mounted up onto white cards on the wall. We plan to also mount the best art assets and 3d models around the two set-up PCs to show-off the best work of our game in a professional manner, as it will allow our work to be spaced-out and not too cluttered, while still exhibiting the skills and techniques we've learned from our time on the course with the evidence of us applying them being our exhibited exhibition work.
Overall though to conclude things, I'm very happy with how the project turned out and feel it went very well. We ended up producing a very fun and solid game, as evidenced by the positive user testing results and us hitting all of the points on the quality plan. If we were given a few more months to work on Zer0 Fr1ction the concept could have been taken even further with more maps, vehicles and polished gameplay mechanics. But as it stands I'm very proud of myself and everyone who worked on this game, and it makes for a fine exhibition and portfolio peace as physical evidence of how much we've grown over the two years on this course.
No comments:
Post a Comment