Ok, so here we are, at the final week of development. Give’s me butterflies just typing it. “Little Soul”, our little roomba game has been in development for two weeks now not including the first week of designing and documentation. I have to say it’s been a great time so far, I can easily say this is the best group I’ve been with in any group project so far in this course. Whilst we are all different in ideas we have all been very professional from the start about the production process and how we work with each other. But now that the project is in it’s final week, with all of the core features implemented it’s too easy to become complacent and drop the ball in the final stage. As a result of this, I have been reading numerous postmortems written by established studios to refresh my memory of some of the things that may happen and maybe, just maybe I might be able to prevent them from happening. At the very least I can prepare for them. Like the wise old man said, “Hope for the best, prepare for the worst”.
My first concern is with the groups communication and collaboration. Up until last week we have been communicating with each other really well, but as the project is becoming more complete and team members tasks are reduced there is definitely less interaction with some members of the team. This brings me to the first postmortem that was about the development of Amnesia: A machine for Pigs. Amnesia was created by two separate studios operating in different parts of the globe. One of their strengths during the project was communication and in the article Peter Howell states:
“Having a singular vision for a game is important regardless of what game is being discussed” – Peter Howell
This is where I believe the issue maybe coming from. As the trimester is drawing to a close some of our members maybe distracted from the game and diverting their focus to individual Learning Outcomes. This is something I can’t stop them from doing but what I can do is get them to thoroughly test the game, thereby allowing them to continue working on their LO’s but still improve the game greatly.
This leads me to my second concern, testing. Much of our game revolves around getting the player emotionally invested in the roomba and their place within the game world and that without them this world would fall apart. From a mechanic point of view there isn’t much, it’s mainly about effective audio feedback and how the player responds to it. Out of all the games I’ve made thus far Little Soul will require the most testing so we can accurately refine it. In The Binding of Isaac, Edmund McMillen writes:
“Binding of Isaac had 100 items and five playable characters. 70 percent of the items in Isaac stack, and all the item abilities will affect Isaac in some way. There were so many variables to keep track of that all the testing in the world couldn’t have prepared us for launch.” – Edmund McMillan
Even though our scope is certainly not this large, we have numerous sentimental items in our game that are all designed to affect the player in a certain way. If one of them is off then it could ruin the design intent of the entire game. To help combat this, our development team will be using feedback from the play testing to specifically fine-tune our design intent instead of being sidetracked by unnecessary tasks. Making the game prettier and more efficient is obviously important, but insignificant in the grand scheme of things and that is what I’ve found all projects focusing on in the last week of development instead of the critical ‘essential experience’.
Lastly, and this is what I’m most afraid of is the ‘do, do, do mode’. Like I just said, the last week of a project in my experiences so far has all been about the crunch in trying to make the game prettier and feel right. Spending lots of hours pumping out the work without taking the time to ask if it’s the ‘right’ work. Gaijin Games Alex Neuse published a postmortem on the game BIT.TRIPBEAT which said:
“Basically, you have to keep doing things and keep moving because if you stop to think for even a moment, you can sometimes throw your entire groove off. In the heat of the moment it’s easy to lose track of the gray area between right and wrong — because there is one. The “right” way is not always the right way to do something. And sometimes the “wrong” way can be more right than we would ever think.” – Alex Neuse
I’ve been thinking how best to prevent the ‘do,do,do mode’ with as little stress as possible. It’s not easy in the final week of development to simply stop what your doing and reassess if its the right thing to do. Even harder to change what your doing if it is indeed wrong. What I’m implementing tomorrow is something called a ‘Burndown chart’. Basically I’m going to do setup a Google Drive excel sheet for my team that will allocate each team member small daily tasks for the entire week with the game’s completion being the milestone for Friday afternoon. Each day at midday or before class we will have a short recap on everyone’s progress so we can accurately see how the final week of development is going. By reducing the workload on everyone’s plates into fewer but more focused tasks I’m hoping we’ll achieve a higher quality game with less stress and workload.