The first idea for my graduate project manifested as ‘Chronorush,’ a high octane sci fi racing game set in the far future, where mankind irresponsively utilises the manipulation of time and space to drive antigravity vehicles for sport around the most dangerous locales available in the universe. It was not until I pitched my idea that I realised the ambition of the concept outweighed the core strength of the idea – I had already created a basic prototype of the physics system in Unity but realised I was heading into the idea generation process ‘gameplay first’, so I reinvented my idea from the ground up as an exploration into the concept of what would happen if man attempted to control time and failed. From this core structure I moved on to develop the mechanics and story so that they aligned with my aspirations for the idea; I chose the platformer genre to keep the gameplay simplistic at a fundamental level and included some light puzzle elements with the time control as a ‘modifier’ to be able to increase the game’s complexity through the puzzles.
The placeholder character
During user testing, my testers actually showed interest in a robotic main character seeing as the placeholder looked quite artificial already; following this feedback I decided to opt for a mechanical android type character, as I felt that doing so would also add an interesting dynamic to the story of the game – the idea of a robotic entity gaining morality and compassion for its masters and deciding to aid them was far more interesting to me than having a human predictably strive to save their own kind. To put this idea into visual form, I used a modelling package to replace to give the character a robotic appearance; because I did not have time to create an entire ‘rig’ (model, skeletal structure and animation) I instead modelled each limb seperately and replaced the placeholder limbs, leaving the black sphere joints intact, meaning the animations I had already set up worked with the new models off the bat. Despite not being able to produce a character completely from scratch, I feel that with the time I had I managed to achieve an acceptable look for the character.
The final character
During the production of my level, I decided to start blocking out without yet defining the setting of the location; instead I wanted to ensure that the gaming experience and flow through the level were optimal without worrying too much about how what the objects and rooms were going to look like at such an early stage. I used the Unity plugins Pro Builder 2 to quickly place collision enabled meshes that the player character could interact with, and Pro Grids to enable snapping within the Unity editor, allowing the rapid and accurate placement of the blocking meshes and later, the finished models and art. After several of the rooms had been blocked out, I decided on a scientific facility type setting and set about replacing the blocked out rooms with textures and details that would suggest such a setting.
A blocked out and final version of one of the rooms
Admittedly I did not get the opportunity to produce further iterations of the level, but I feel that the early movement testing of the character and watching my testers move around the level, and on occasion offering suggestions for what would make good level design, gave me guidance for how to ease the player into the game and provide a puzzle based challenge later on. The rapid idea testing and iteration that took place when blocking the level also aided me in producing an adequately challenging level. I feel that the realisation of my level design as a introduction to the controls/platforming type challenge at the start, moving on to a light puzzle type challenge in the middle and finally a combination of the two with the water puzzle, was close to what I was aiming to achieve in terms of gameplay.
Overall Visualisation – Meeting Ambitions
I feel that the overall end visualisation of my game was close to what I was envisioning with my idea. I fell behind in some regards however; much like my second year game project, I was too ambitious, but due to increased experience since then I feel like the gap between the realisation of my idea and my inital ambitions has grown smaller. There are some parts of Dead Time which I wish I had improved before the deadline, such as having a fully modelled and rigged player character model with custom made animations rather than a placeholder character converted one using Unity’s own raw motion capped animations; but given enough time I would have been able to achieve such a result. Another feature of the game which is quite noticably absent is the audio; during production I possessed the audio that could be used in-game and the knowledge for how to import and set up the audio sources and audio listeners (which represent the locations from which sound can be heard by the player) but was inexperienced with how to trigger the playing of the audio in code for actions such as footsteps or doors slamming shut. I left the inclusion of sound too late in the production process and was forced to forgoe its inclusion if I wanted to fully complete other aspects of the game. Another aspect which was not fully realised to my expectations was the heads up display; despite being aided in its production by Collaborator Ben Conway, it ultimately ended up as a simple text based counter in the corner which showed the current “heat level” in percent, and red warning text that showed on screen whenever the player heated up too much and needed to cool down. I feel that if I had more experience with 2D design and User Interface methodology and functionality of Unity I would have been able to produce a more visually pleasing UI to completement Ben’s work on the functionality, but the HUD is still functional as it stands thanks to him.