Brief / Overview
InStability was a solo project made in 3 weeks for a University brief. The brief required us to create an interactive autobiographical experience based on a chosen aspect of our lives. I chose to peruse the internal struggle of finding balance and how it affects the world around me. After going through a handful of iterations, I began to take inspiration from “The Beginner’s Guide” by Davey Wreden. The player is tasked with interacting with objects in the environment which alters a stability level, directly controlling the narrative’s direction.
I would consider this project a failure as it did not live up to the expectations I had for it. However, I learned a valuable lesson about project scope and the importance of understanding the core of an experience. Through this self-proclaimed failure, I have been able to walk away with a greater understanding of my own capabilities and where I need to improve.
Main Learning Outcomes
Over-scoping and Focus Shift
The original concept was over ambitious for a handful of reasons. There was supposed to be two different environments that featured upwards of 40 unique furniture assets, a time date system and, a range of audiovisual effects. The plan was to source all models, however, I underestimated how long it would take to find and import each model. This combined with the plethora of systems and documentation proved to be an impossible feat for a 1 person team in 3 weeks.
In the last week of development I realised that I would not be able to finish everything in time. After consulting my facilitators, I had better understood the core of the experience and the project underwent a focus shift. Instead of fleshing out all of the desired effects and changing environments, I decided to create a narrative, outlining my thoughts on over-indulging and overworking.
I’ve learnt that a solid understanding of what the core of the project is has a direct correlation to its success. It’s important to create multiple milestones for the project that encompass a differing level of complexity and importance. An example of this can be seen in the diagram below.
Another extremely important lesson I learnt is understanding and factoring the team’s capabilities and limitations into the project scope. Originally I would look at scope as only the final output of the project, however, the team working on the project should be considered and factored in as they are the input. For example you can’t expect an artist with some programming experience to output a complex AI behaviour with over 30 unique animations in one week. Of course this example is extreme, however, as humans we can only do so much work and it’s important to understand this.
The importance of asking for help
As someone who is mostly self-taught, I have found it particularly difficult to swallow my pride and ask for help. This became painfully obvious in this project as I spent a lot of time debugging back end systems and tools for the player activities. I am a hard working person who is very determined and therefore did not want to bother my ‘higher ups.’ I let my ego get in the way of progress and the project suffered because of it.
This experience has humbled me and I learnt the value of taking advantage of the opportunities afforded to me. I learnt how to ask for help and that it is important to do so when I become stuck for both my own sanity and the credibility of the project.
I’ve found that I can do a handful of things when I get stuck in order to progress. First I can recognise that I am stuck and take a break, most of the time a solution can be found in a cup of coffee. Secondly I can move onto another task to continue making progress on the project to give myself time to subconsciously come up with solutions. Finally, I can ask for help. I believe that finding solutions on your own is a great way to learn and feel accomplished, however, if the task is time sensitive or the first two steps didn’t work, I need to request assistance.
Callum Nottage 