Production Analysis: Conclusion

To conclude, I am pleased with Dead Time in its current state; I feel that from the beginning of the production of my graduate project I have learnt valuable lessons regarding, amongst others, project organisation, optimisation techniques, research methodologies, planning, idea generation and market awareness. I have also learnt that I can be too ambitious, and the vision I had of Dead Time at the start of production has not necessarily been realised with the final product. The predictions I had envisioned in my head of the realisation of features being a certain level of difficulty and needing a certain time to complete were usually incorrect; I found myself still tweaking and working on features I had expected to finish long before. I am glad however that I decided to restructure my idea as if I had followed through my my original idea of Chronorush I would have likely ended up with a weaker project.

Along with producing a game I feel as though I have become comfortable with the fundamentals of the C# programming language and wish to advance my skills further in this field as at several points in the project I remembered how little I knew of the language before and felt impressed at the functionality I had achieved, but also felt that I wanted to learn more. Saying that, it is producing art for games that I want to become the most proficient at, but while I felt like I had learned a lot and progressed on the programming side, I feel as though I didnt perform to my fullest on the art side; I speculate that this is due to me needing to spend more time on the programming side as I was learning as I went, whilst with the art I was short on time and couldn’t challenge myself in quite the same fashion. If I was equally skilled and experienced in both fields, then I would have likely been able to make much more accurate estimations on workload and time required for completion of tasks, resulting in a project closer to my aims or perhaps even more ambitious.

Looking to the future, I believe that all I need when it comes to meeting my expectations and ambitions in the future is greater experience and skill; by completing more projects I will obtain a greater understanding of the sorts of timeframes certain tasks require as well as increasing my efficiency and speed so that the tasks can be completed with less difficulty. I will likely continue production on Dead Time after the deadline in order to meet my standards and gain the experience I am striving for.

 

 

Collaborators

For the production of Dead Time I drew on the creative skills of two of my coursemates; as making an entire game is usually a difficult task, I recruited the help of two other experienced game developers that have been using the Unity engine as long as I have.

Name: Ben Conway

Role: UI Programmer

Ben aided me in linking the functionality of my game to the user interface in order to deliver important information to the player; as I did not have any GUI programming experience, I greatly valued Ben’s help with the project. Ben linked the numerical value of the heat level of the player to the onscreen GUI and used concantination to add descriptive text achieving further clarity with the UI. Additionally he used several fundamental mathematical functions including Mathf.Round to round the value to be more manageable (i.e. 56% rather than 56.789%) as well as programming the “overheating” and “entered dead time” warnings to be enabled when the heat level rises too high and to be disabled when it falls under an acceptable threshold. Overall Ben was very helpful with providing the functionality behind my UI.

Rating: 5/5

Name: Andy Joyce

Role: Unity Consultant

Andy aided me at many points throughout my project with various bug crunching and troubleshooting, his expertise being valuable due to him having knowledge of different aspects of unity than I do. In an area where my knowledge was lacking I was able to rely on Andy to inform. Andy was most helpful with getting my quaternion based turning system working, as I was having trouble joining the smoothed movement of the character on the x and z axes with the gravity and jumping based movement on the y axis; an issue I was being stalled by was solved in due course and with minimal difficulty thanks to Andy.

Rating: 5/5

Production Analysis: Planning

Ensuring that I went about planning the production of Dead Time was essential if I wanted to complete a realistic amount of work in a predictable and reliable fashion. Back when my graduate idea was Chronorush, I created a Gantt chart (shown below) that mapped out in 2 week segments how I would spend the months ahead of me;

After making the decision to restructure my idea and ending up with the concept of Dead Time, I thought again about planning my project and looked at the Gantt chart I had created for producing Chronorush and reckoned that it was far too rigid a planning model for my tastes. I moved ahead with the production of Dead Time but came across Trello, an organisational web app for single developers or entire teams; tasks are represented as cards, which are stored under lists – tags can be used to quickly colour code tasks and give them context, to do lists can be created inside cards, developers can be assigned to specific cards by dragging their profile picture onto them, and many more features.

I found Trello to be extremely helpful in organising the production of my graduate project, as new tasks could be added and sorted on the fly, and I could view and estimate my workload at a glance as well as set due dates for certain tasks to plan out both the short term and long term production of my game. In hindsight, cards representing large development tasks for the game had the same visual presence as ordinary small tasks, so whilst Trello was great for small scale tasks, when it came to moving onto larger parts of the game, cards representing large areas of development such as ‘start on the art’ ballooned into smaller cards such as ‘create models for player’ and ‘create models for security door.’ In this regard I feel that I might have been misled by the rate at which I could complete tasks on cards seeing as there was no way to tell which cards held more relevance/were more difficult/took more time to complete leading to a disparity of understanding the greater scheme of things from the smaller. Nevertheless, I feel that Trello greatly aided the organisation of my project on a smaller scale.

Production Analysis: Development

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.

Character Visualisation

In the process of visualising my idea, in terms of my character, I was very confident that my character would be a humanoid type, so I used a downloaded biped character as a placeholder.

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

Level Visualisation

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.

Production Analysis: User Testing

The user testing that took place during the making of Dead Time occured at two distinct stages of the production; the first round of testing took place before the final production of the main level of Dead Time, but after the core movement systems for the player character were in place. In this informal user testing session I took feedback in note form from several people on my course and who I know personally who played the game in its early stages; I recieved feedback that significantly influenced the functionality of my game, which was recorded and is shown below.

• “It should be easier to turn in the air” – to start with, I had reduced the speed at which players were allowed to turn when jumping and in mid air to introduce some realism, as in real life it is impossible to change direction once is airborne and your trajectory is decided. However, players were confused with the system and repeatedly missed platforms or their intended target for landing due to how certain players needed to be of their direction and speed before initiating their jump. Due to this, I decided to remove the limits on turning in mid air, so that players could have a much greater level of control over how they manouvered mid-air, sacrificing realism for a greater gameplay experience.
• “It’s hard to turn around in a small space” – I had decided to use quaternions to “smooth” the player character as they turned, instead of instantly snapping them as they rotated, with the intention of making the turning less jarring; however this seemingly impacted upon the gameplay, as one of my testers noticed that small adjustments to the player’s direction were not possible without turning in a larger “turning circle” than was anticipated; I ended up solving this by having the player character change rotation instantly only when the speed of the character was under a certain value. This way, the player character still turned smoothly when running or sprinting, but would also have finer movement when at a standstill or moving very slowly for exact positioning.
• “Holding the time control button is tiring after a while” – At this stage in production I had not yet added the heat meter and functionality which stopped the player from endlessly using time control, meaning the player could activate it as long as they wanted; the activation was triggered by holding down a button and deactivated by letting go. After a while, the player got tired of holding the button down to activate the mechanic, so I decided to opt for a toggleable control instead, so that with one press time control could be turned on or off rather than having to hold the button for the duration of usage.

The second round of user testing took place towards the end of the production, at which point the player character’s model and the level were nearing completion. I was able to act upon the majority of the feedback at this stage, but some I was not able to follow up on and implement; I will likely take into account the remaining feedback if I pursue further development past the deadline.

Feedback that affected the production of the game

• “There should be a button to drop from ledges” – Implementing a ledge drop button was straightforward; whilst pressing the jump button whilst ledge grabbing made the character let go of the ledge and launch upwards, the drop button simply made the character let go without jumping, causing them to descend and go into the falling animation. Before this implementation, the only way players could move downwards from having been latched onto a ledge was to jump, forcing them to move upwards before being able to move down.
• I observed some players failing to jump on occasion due to having pressed the jump button very shortly before fully landing and the player character registering itself as being grounded; to rectify this, I made the jump button valid for 0.2 seconds after being pressed, so even if the player pressed the button too early it would still be a valid input for the next 0.2 seconds in case the character were to land in that time.
• “There should be a walk button” – at the stage of this feedback there were two speeds of movement in the game, either running (the default move speed) or sprinting (facilitated by the use of the shift button) so on request I added a third speed enabled by another button and added the framework in the animation system to blend from running or sprinting movement into a walking one.

Feedback which I was not able to respond to before the deadline

• “there should be more of a visual change when the time control activates” – If I implement this change I would likely use some sort of colour-shifting effect to emphasise the ability being activated; right now the rods on the character’s back depress and a subtle depth of field blur effect can be seen on objects in the distance, but if objects in the distance can’t be seen as well as the rods, there is no way to tell that the player is activating time control aside from the heat meter increasing. A colour shift would be the clearest signifier that time control has been activated.
• “you should be able to move left and right on ledges” – currently the player detects where ledges are vertically in order to determine whether to grab them or not, but introducing the functionality for moving along grabbed ledges to the left and right would involve a different type of horizontally aligned detection system that ensured that there would still be more ledge to move onto when moving, but the main reason I was not able to implement this functionality was due to a lack of animations that would make the ledge movement look convincing. If I decide to develop past the deadline and produce a character from scratch, I would be able to create custom animations suited for such a purpose.

 

 

Production Analysis: Exposition

From the start of production, my project has been shaped by the factors previously discussed in my earlier posts; when developing my idea, my understanding of ‘high concept’ ideas greately influenced the methods with which I formulated and crafted my core idea, drawing upon inspiration in the same topical areas as I was heading for in my game in order to gain ideas and understand how others approached similar themes in the past. This methodology ultimately guided me towards producing a game based around the notion of controlling time.

When it came to putting the systems and mechanics for the game in place, research methodologies in the form of user testing came into play; my understanding was that I needed to guage my audience’s expectations in order to make the right decisions regarding gameplay. The first round of testing occured early, when I was utilising a simple testing level constuting of basic cubes and structures to jump and climb on and manouvre around to test the controls and the movement speed and intuitiveness. Using a feedback-based model of user testing, I found a handful of aspects about my control system were not problematic, but not to the taste of my playtesters, who disliked features such as not being able to turn in mid air. The original intention behind limiting turn control for the player in mid air was to introduce some semblance of realism to the mechanics, however knowing that players were not used to this feature, I opted to remove it and allow full directional control in mid air, sacrificing realism for the accessibility of gameplay and ultimately the enjoyment of the player. The changes made whilst user testing will be detailed further in a later dedicated blog post.

Returning to the pre-production stage, I chose to adopt Frayling’s ‘research through design’ method (http://folksonomy.co/?permalink=589) to justify my game in a research context, but also took a look at the current climate for games hosted online in order to get a solid reading on how others approach the hosting and deployment of their games, and realised that whilst web hosting for direct browser-play is an option, standalone would be the preferential choice due to the increase in performance of playing a game independent from the browser.

Another aspect of production that shaped my project were my technical considerations; I had to make sure that both the programming and art production sides of my project were done in the correct manner to result in a game that was acceptable visually and based on performance. On the art side, I needed to ensure that whilst creating my models in my modelling program I built each model out of a minimum number of polygons, as more polygons used means more work for the processor and graphics card to do whilst rendering them. On the programming side I needed to ensure that my methods and functions operated in an efficient manner, reducing the performance impact and again making sure that the game was not too processor-intensive.

Overall, my understanding of the aspects of creating my game in every stage of production of my project has worked to shape it and align it towards my end goals and interests.