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.

Production Analysis: Technical Considerations

During the production of Dead Time, I had to take into account multiple technical considerations and encountered numerous challenges during the production process; one of the largest challenges was making sure the game worked on a variety of user’s machines, and as such I had to make a compromise between visual quality and optimization. Thankfully, Unity provides plenty of guidance in their online manual, but I am aware of many techniques to maximise compatibility and performance, which I will provide an overview of below. The two most significant areas for optimisation were the graphics and the programming behind the game.

 

Graphics

The general aim when it comes to graphics is to set a target for what kind of visual style and fidelity you want to achieve, then get as close to that target as you can whilst being as efficient with texture resolution, polygon count (the number of ‘surfaces’ or ‘faces’ that make up the 3D shape of each object) and the methods with which you light your levels, amongst other aspects; again, unity provides valuable documentation on this subject, and game artists should be aware of the performance thresholds and commonly held methodology behind the art of different types of games – for example, when 3D modelling one should minimise the number of polygons on background objects (saving performance) as they are less likely to be seen in detail, while adding enough polygons to more significant objects such as characters. As my game’s target platform is the web, I must keep file sizes down so that my game can be loaded in a reasonable amount of time, but also provide graphical settings (practically an expectation nowadays) so that people with less powerful machines can tone down the visual detail and achieve a desirable framerate. Thankfully, even the mid-range computers nowadays are powerful enough to display many thousands of polygons and handle intensive post-processing effects, making my job as an artist more forgiving, but in turn provides more artistic freedom.

 

Programming

As with graphics, ensuring that one’s programming is optimised comes with experience and the knowledge of how to build as efficient a system as possible – that is, ensuring that the purpose of one’s programming is met as fast as possible and with the smallest possible memory footprint – instead of art, with which one must compromise, the aim of programming is to instead solve a problem with the simplest solution. Following this mindset, I have used fundamental methods such as ‘caching’ – when you store data, for example a reference to another object’s variables, in a new variable to then use, instead of retrieving that data every time you want to use it, forcing the need to have to find the object every time to access its variables. Other methods include coroutines – in comparison to the update method which runs every frame (conventionally 30-60 times a second) coroutines can be made to run as frequently or infrequently as is needed, making them much less impactful upon performance. There are many solutions to one problem, but the aim of programming is to provide the most efficient solution, which is a consideration I have taken into account when programming my game.

Production Analysis: Market

When producing a game, it’s often expected within the industry that one should design for a particular audience (rather than for yourself or just for people like you) and of course this is the case if you are working for a client and the game is a product to be sold. The market and audience for a work is determined by the intention of the work, and my intention is to simply produce a game that showcases my skill set and creativity that can be displayed on my portfolio – but in this case the target audience would change, likely from the conventional game playing audience to prospective employers. In this case, the problem is how do I research effectively to deliver a project that achieves my intentions?

Unlike in the design field, when working in the creative sense, one is not necessarily seeking the ‘solution’ to a ‘problem’ – to a designer, the problem would be the unidentified market and the solution to conduct research; to a creative, the “Problem Centric Approach” may not in fact be the optimal mindset according to Barker (http://folksonomy.co/?permalink=1365) who argues that in fact “confusion, contradiction and incompatibility can be celebrated” if we take on the act of continuous self-reflection and make ourselves open to the unfamiliar, we can become “connoisseurs of our own emotion and experience” by not regarding these difficulties as problems to be solved, as “an obsession with ends tends to create a projective knowing or longing for outcomes and results” which can negatively impact the creative mindset. In short, we must instead accept that encountering problems and difficulties is part of the reflexive process and must be embraced in order to move forward and expand.

Building on this, I adopt Christopher Frayling’s model of ‘research through design’ (http://folksonomy.co/?permalink=589) to serve as my production ethic – using the production of my game as a vehicle for exposing ideas and possibilities which I might otherwise not have had the ability to engage with, if for example I used a conventional, research-driven production strategy, which would likely constrain the potential of the project. The game therefore provides me with an opportunity to explore contemporary ideas which characterise current games; thus the most logical way of addressing market awareness is to describe how my game would be located in relation to games within the existing market.

As I have chosen the Unity engine to build my game with, the option of online game hosting is available to me (allowing people to play the game inside their browser, rather than as a downloadable standalone) – many unity games are already hosted online, on websites such as Newgrounds or Kongregate, both which have a considerable user base, and enough games that they need to be organised into categories and subcategories. I will likely opt for a standalone download however, for performance reasons. As I am heading towards a game based on overcoming obstacles with the utilisation of specific tools available to the player, my game would likely reside in the ‘puzzle’ category as I would consider it a puzzle platformer.

Production Analysis: Methodologies

Using the correct methodologies when researching is important during in the production process, helping to orient and guide the project in the early stages as well as midway through the process. I hope to utilise various research techniques in order to inform my project direction.

In the games industry, play testing is a common and simple first hand qualitative research method that functions by putting the game in front of individuals and letting them play it in order to give their feedback. This can be used in a Quality Control fashion with more dedicated play testers with the purpose of identifying game bugs, however more focus group based play testing can also occur in order to gauge and study the public’s reactions in relation to the expectations of the producers, potentially leading to beneficial changes that can occur early in the production process when changing things is easier. This is the primary type of research methodology I will take – focus groups that will inform me of how I should tailor my game to its audience’s expectations at a stage when I can integrate my findings into the process alongside production – if the research takes place too late, I may have to change or even redo things to remain on track, which would be obviously detrimental to progress.

That said, I believe games are a personal creation and in researching how to better appeal to your core audience you must be wary of changing the game’s direction at the cost of the original idea’s sake – that is, if people are unfamiliar with the concepts a game presents, that might just be because these concepts are original and have never been explored before rather than ‘wrong’ in some way, or that they just need to be explained better. In the past, there has been the occasional ruckus regarding how play testing has been approached – one example is when an executive director of Arkane, the developer of Dishonored, revealed in an interview how play testers reacted to one of the in-game characters (in this case, a guard) telling the player that they couldn’t go upstairs – so the playtesters didn’t, thinking that there were no other options, even though they were playing as a master assassin. The top comment on the page from user MasterFnarg reads: “They didn’t go upstairs because someone told them they couldn’t? Have these people ever played a video game?” But what exactly was the perceived problem here – did Arkane choose the wrong testers? Did they not brief the testers correctly before they started playing? Another user TheVGamer comments: “I think Gabe said this but unexperienced playtesters (ie. non-gamers) are the best type of playtesters because they have no previous experience to taint how they view the game they’re testing.” In this case he is referring to Gabe Newell, founder of Valve, and makes an interesting point – the type of tester chosen to test the game likely impacts the research – do you choose testers from your core target audience, or the general public? In the end it probably depends on who you want your game to appeal to – I feel that my testers will be made up from gamers with at least some experience in order to get the most knowledgeable feedback; I’d like the game to appeal to people like me, rather than dilute it so that it appeals to everyone but in a weaker way.

Other research methodologies include questionnaires, a relatively easy way to gain insight into various aspects of planned features and concepts by setting up questions based on them, and then collecting the opinions of many in order to inspect the results and respond accordingly. There can be drawbacks to this – multiple choice questions are hardly personal and don’t allow people to speak their mind (unless optional text boxes are included with questions) but still serve as a solid way to gain a general overview of the opinions of many; as long as the questions are constructed correctly as well as in an unbiased way.

In the end, there are a few research methodologies that can be utilized, each one serves a different purpose and can aid the production process in different ways.

Inspiration

In my previous post, I stated how all ideas are an amalgamation of our own experiences and understanding of the world, or inspiration from having experienced media – my project idea is no different, having been constructed as a new amalgamation of previously explored concepts in an attempt to explore new concepts. Below I list and state my explanation for being inspired by some of the media I have experienced that influenced how I crafted my project idea.

The Matrix (Film and Game Franchise)

The excellent 1999 film ‘The Matrix’ by the Wachowskis and the resulting movie and game franchise that came afterwards explore the concept of a reality in which humans are enslaved and subjected to a  simulated ‘pseudo-reality’ by machines and used as power sources in their comatose state. The key feature of the matrix films which has influenced my idea however is some of the characters ability to increase their perception and movement to a heightened state and observe slowed down time as well as move faster, an effect known as “bullet time,” popularized by the first movie. In the games this technique is known as ‘focus’ and goes beyond mere slowing down time, in that it enables the player to also increase their speed to a degree that allows the dodging of bullets (which can also be perceived as time slowing down while the player retains the ‘same speed’). I like this mechanic since it allows more precise movement and aiming, giving a direct advantage over enemies and allowing the player to avoid damage and escape dangerous situations when they would normally not be able to.

Prince of Persia (Game and Movie Franchise)

Here I am referring to the first reboot of the ‘Prince of Persia’ series, known as the ‘sands of time’ series of games, published by Ubisoft. In the game, players can rewind and slow down as well as speed up time to achieve different effects in order to complete puzzles or gain an advantage in combat; an interesting utilization of the rewind mechanic is that when a makes a mistake, they may rewind time in order to undo whatever may have happened, even if the player had already died for example. I find these kind of time manipulation abilities to be highly interesting and well implemented, particularly their use in solving puzzles, forcing the player to consider the different ways they can manipulate time and what effect doing so has in order to solve tasks. The rewind mechanic is shown below:

Thief of Time (Novel)

Thief of Time, by Terry Pratchett, explores the concept of time as a physical quantity, able to be stored and used almost like electricity; in the plot, Auditors (supernatural celestial bureaucrats of reality) decide that mankind is far too unpredictable to document effectively (which is their job) and convince a young clockmaker to build the ‘perfect’ glass clock, which, unknown to all but the Auditors, will imprison the anthropomorphic personification of time and effectively freeze time so that humanity is much easier to manage. A young History Monk called Lobsang Ludd learns of the clock’s construction and attempts to stop it starting. As he is smashing through the window of the room where the clock is, the clock starts; however, he is still able to move thanks to his ‘Time-storer’, a sort of backpack supply of personal time, and in the end is able to save the day.

The History Monks’ task in the Discworld involves ensuring ‘anything happens at all.’ To achieve this, they have methods for moving and storing time by means of spinning cylinders called Procrastinators; it is established in another book that people’s perception of time effects it’s flow on the Discworld, so the monks ensure that this does not become a problem by, for example, taking time from the middle of the ocean (“How much time does a codfish need?”) and transferring it to a busy workshop with a deadline to meet. Overall I feel that Thief of Time is where I will draw the majority of my inspiration from, at least for the lore of the game, since time as a ‘quantity’ able to be stored, a secretive organisation that controls this time, and moving within ‘frozen time’ are all concepts that have been appealing to my imagination since I read the book.

SUPERHOT (Unity Game)

With the central premise of “Time moves when you move,” this FPS game, created in 7 days by Blue Brick studios, would be a pretty standard shooter if not for its innovative time based mechanic – if you stand still, time moves at less than a snail’s pace, and when you move, time returns to it’s normal flow. This allows the player to plan ahead, taking as much time as they want, or to dance in a hail of bullets placing key shots on enemies. Ammunition is limited, adding a strategic dimension to gameplay, forcing the player to deal with threats in an intelligent way to avoid running out of bullets and getting cornered. The aspects of this game that I enjoy include the player’s control over time being the sole deciding element that earns them superiority over their enemies (aside from intelligence) – the player, like the enemies, is just as dangerous yet vulnerable, and will succumb to death in just one shot. I like how adding this one simple mechanic adds a surprising degree of depth to the game – in one level, a player is running down a corridor towards three enemies with handguns – ordinarily, this would be an impossible task, but thanks to the time manipulation it becomes achievable. Additionally, unlike Prince of Persia in which a button is pressed to instigate the time manipulation, movement itself and the translation through space is what causes time to become unstuck, raising some interesting theoretical questions such as how time’s relation to space affects the game world.

Simple gameplay with the addition of a key gameplay element that adds considerable depth will likely be the aim to achieve with my game, and seeing as I am planning to create the game with Unity as well, this game shows that time manipulation within the engine is possible.

You can play SUPERHOT here: http://superhotgame.com/

Quantum Break (Unreleased Game)

Quantum Break is an upcoming third person shooter videogame, being developed by Remedy Entertainment. The game was revealed in a teaser trailer (shown below) during the Xbox One reveal event on 21st May 2013. The game is based on time having been broken, creating time anomaly zones where time freezes or violently skips forward and backward. The main characters are present during the experiment which breaks time, and gain powers to manipulate time – in the trailer, one of the main characters is shown ‘pulling’ another character out of a frozen time anomaly. The game’s director also talks about how great action set-pieces can be created in the game by freezing time in an entire location right the pinnacle of an action filled moment occurs, such as a boat skipping time and hitting a bridge, creating an arena of twisted metal and precarious footing.

I find the way time is conveyed in the game’s media to be engaging, particularly how time is conveyed as violent and barely controllable, straining against the influence of the experiment. Again I find that the key element that makes this game engaging is its use of time to create unique set-pieces, something that I may consider as part of my game.

A Short Cartoon About Time

This flash animation by David Firth explores what would happen if Time was a commodity, bought and sold by a company (time™) just like any other product, and what the repercussions would be when the public acts outside the original intentions of the company due to their own greed. In A Short Cartoon About Time, time is conveyed as carrying the memories of humans – selling time causes one to age and lose memories (though the memory of having those memories is retained), while buying time returns one’s youth. It’s a depressing cartoon but sends a strong message about human’s lack of respect for their own time, auctioning it off for comparatively pitiful sums and then regretting having lost the time afterwards. I especially value the political and ideological angles explored in the cartoon, and hope to perhaps investigate similar views in my own work.