breathe – a postmortem

The Good


Paper Drafting

Most of the systems, code and design in Breathe was drafted or sketched out on paper prior to implementation in Unity Engine. By outlining the desired goals and then drafting how the breathing system or level design would function enabled helped clarify the steps required to complete each task and also made implementation of code and engine work faster than usual as there was less task switching. This prior planning also assisted in identifying knowledge gaps so that any learning could be done in advance. This practice proved infinitely useful and revealed more about my personal style of workflow.



The system for breathing was designed and scripted successfully, to the original specifications in my planning. As well as the input meeting the design intent, it also allowed for tweaking an additions later on due to the way variables and functions had been setup. This became particularly useful when the physical input was altered from the initial design. Overall the system was both functional and practical but given more time  could have been optimized further.


Visual Aesthetic

The visual aesthetic choices for this project based on feedback were deemed effective in relation the subject matter and design intent. Specifically the camera and lighting effects were mostly effected in their implementation and representation of the emotions and experience outlined in the artists statement. By testing various combinations of effects as well as different levels of intensity, applying effective and relevant aesthetics to the project became an easier task.


Early testing – Input System

Early versions of the input system were tested by a few external testers. The information gleaned from these tests lead to a complete change in the physical input system (scroll wheel to mouse click) as it was found that users interpreted the input differently than the design intended and with consistency. By demoing an unusual input system early in an early prototype the success of the design could be gauged more easily and major adjustments made before other dependent decisions are made.


The Bad

UI Feedback

Although the game was a prototype the visual feedback in relation to the UI elements were not clear enough and detracted from the play experience for some users. The anxiety slider bar was often misinterpreted, with some players thinking that the bar needed to be full for success, the opposite of the design intent. The UI was created with a desire to minimize the use of any text and overly obtuse representations to allow for a more subtle approach and removing overtly ‘gamey’ elements. However in future projects it will be a safer process to start with a UI layout that is obvious and then iterate new versions to reach a balance between immersion and clarity.


Audio and SFX polish

The audio and SFX used to provide feedback for the breathing input were functional but required further editing/polish to provide accurate feedback for the player. The duration of the sound effects needed to be edited to match the breathing pattern the player was required to input as the current mismatch made it difficult for some players to sync up. In addition Audio SFX/feedback for higher anxiety states was not present and would have increased the clarity of the game state to the player. Tutorial screen was missing audio triggers which may have detracted from its value


Play testing and difficulty

Play testing prior to the exhibition of this project was all but non-existent. Multiple full play tests of builds through out the prototype process would have highlighted many of the issues outlined above, enabled a more polish build to be shown on the presentation day. Some issues were known but the extent to which they affected players and the overall experience was not clear.

The input system although functional was too difficult for first time users to adopt due to it being unusual and the current tuning of variables in that build. This lead to a second build being generated for the latter half of the  exhibition to address the difficulty issues identified during the first hours of testing. After this second build was tested feedback was more positive however this could have been vastly improved if not avoided. In future play testing needs to be scheduled in relation to project milestones to ensure that major design flaws do not make it into final builds.





Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s