Spin Doctor - Post Mortem
Over the second year of our Diploma into game development, students studying at Futureworks School of Media in Manchester, England, were assigned the brief to create a short beta demo, based on a game concept which would be designed throughout the year. Our class comprised of 8 diverse students each with their own different history and talents when it comes to game development. The majority of the class have some form of background in their chosen specialism (through hobbies and general interest), however there is little formal education from the combined group into the field of game design and development, other than the first year of our course. The brief assigned presented the class with a very difficult challenge to not only create a game (as well as an engine to run it), but to learn and develop their skills along the way. Specific lessons were tought in each of the 3 specialisms, which were lead by 3 tutors with their own field of expertise. The lessons would provide theory and education into each subject, whilst the tutors were also there to guide the progress of the class and help where possible.
Programming, Art and Design were all done in house and from scratch, by students whom were still learning and improving their craft. Initially the class worked separately in groups in order to come up with initial concepts that would form the basis of our demo. From these short concepts, "Space Game" was selected which simply used the core mechanic of rotation and gravity to overcome puzzles. This game would later become the steam punk Victorian world of "Spin Doctor" and form the basis of our year long project. Programmers were tasked with creating both an engine and editor to run the game and help the designers create levels in them. Artists then, were in charge the entirety of the visual content for the game including asset creation and animation.
The result was a short 30- 40 minute 2D gameplay demo released in August 2012. The core concept of the game was the use of a rotation mechanic, allowing users to shift the orientation of the levels and therefore change their route through it in order to avoid obstacles and hazards. Story elements were added into the game giving it more depth and playability, following main protagonist Harland Shears on his journey through a hellish maze of underground hazards and traps as he seeks to find answers to his strange surroundings and ultimately, freedom.
5 good things:
Solid core mechanic
One thing that had been maintained throughout the whole project was the use of the "rotation mechanic" as the main gameplay tool. Story elements, setting and characters were changed frequently during development, but the concept of gameplay remained essentially the same. Having this strong vision for the rules and mechanics early on in the pre-production phase allowed the class to stay focused and work cooperatively to a shared ideal and goal. Ideas flowed more organically since the concept was something everyone had already agreed on and felt comfortable with. This bled into our designs of levels and elaboration of additional mechanics, all of which complemented the main idea for the game.
Abundance of Content
From the early development brainstorming and idea creation phase, it's fair to say the class had too many ideas for the final vision of the game. This down the road would help us out infinitely. When ideas didn't work or something needed to be changed, there was an ocean of concepts for new characters, mechanics and levels talked about and documented early in the development cycle. Again, this allowed the team to naturally and organically bounce ideas from one and other, with all ideas falling back and facilitating our main mechanic, from our story implementation and characters, to the location and setting of the final game.
Every aspect of the game was planned out in the pre-production phase of development. The team spoke endlessly about ideas and brainstorms were frequent. Everything was documented down into what would become our Concept and Games Design Documents. The GDD acted as our blueprint for the game and kept the class up to date and on the same page with development. Whenever team members had conflicting ideas or misunderstood elements of the game, we could easily reference the GDD and work from it as we progressed.
Only having limited class time, it was important that members were dedicated to the cause outside of college hours and needed to provide a steady income of work for the game. Lessons were limited to only 6 hours per-week with each class divided between Design, Art, Programming and Production, on a monthly cycle. Through the dedication of the class we were able to push through some difficult times and problems we faced through development. The majority of these problems came from technical and work load issues and could have potentially crippled the entire project. Problems with programming and lack of content in the art side of the project were rectified by long working hours and enthusiasm from those involved, to simply finish the project.
The project allowed each of the members on the team a chance to flourish in their chosen specialisms as well as adapt and improve other areas of their development careers. Thanks to the necessity of work the project demanded, the class was forced to learn new skills and improve on old ones to deliver the final project. Naturally working on the game has made everyone better developers overall, however the format of "learning whilst you work" is something that was really pushed and created a better learning environment. Everyone would regularly chip into areas outside of their specialisms which created an overall stronger connection between the classes and helped refine our ideas down.
5 bad things:
Lack of communication
This became a problem almost from day one when starting this project. The group tried many methods of establishing strong lines of communication such as weekly meet ups both in person and on Skype, group emails and finally a Facebook group, which would act as our private social link to everyone in the class. Using Facebook worked the best and ensured we could be in constant communication. However, the laid back nature in which this was approached meant people would frequently be kept out of the loop on important areas of the project, which lead to confusion and overall decrease in moral and productivity. Work was forever being chased and deadlines missed, pushing back the workload of the class and creating stress and tension.
No working procedure or format
Once we hit production phase, without any methods of work submission there was much confusion into where documents were and just who was working on them. At times we even lost digital copies of important documents like the Proposal Doc. A shared group Dropbox account became our primary way to distribute work through the class. During asset creation the Artists had a difficult time advertising new versions of their work and sending them over to the programmers, which brought more problems through image formats and sizing issues. The closing months of the projects saw new builds of the engine and editor being completed almost daily. Keeping up with this steady stream of updates meant members of the team were using back dated version to complete levels. This confusion hindered progress and made the production process for convoluted and confusing.
From the outset we know the goal of the project was to complete a simple but effective 2D game. During the idea creation and pre-production phase work flowed smoothly and kept to a relatively good standard. Once production rolled round however and the class fully realized the scope of what we had planned and how much work needed doing (specifically from a programming side) we started to struggle with work load. Poor attempts at rationing tasks across the class lead to more confusion and slowed development even further.
Prioritized work incorrectly
At times during development the 3 areas of our project, design, art and programming, would progress at different levels based on the classes opinion of importance. Initially, design was focused on more than any other area which left the programming and art creation during the concept phases lagging. Eventually these areas would catch up, but not at steady rates. There was times when designers needed to use parts of the editor to craft levels for deadlines, when the editor was unusable through programming issues. Likewise at times when art was expected, artists were bogged down helping in design areas.
Lack of a project lead / manager
Whilst planning was something that worked perfectly, the ability to maintain strong lines of communication and risk assessment fell short. Implementing a project lead who could act as a buffer for all 3 areas of design and keep track of workload and deadlines, would have ensured a more structured path through development. Without this, the confusion that arose in all areas became worse and with no-one to look for in times of management needs (or indeed blame when things went wrong) the team suffered.
Overall the class worked on the game for roughly 7/8 months (with other class orientated assignments throughout the year). The result is a pretty satisfying game that far exceeded our goals at the beginning of the year. Spin Doctor perfectly showcases how hard work can pay off and has become something we`re rather proud of; more so for a team of inexperienced designers. It wont be winning any awards, but we are more than happy to showcase Spin Doctor as our first game ever created as a class. Lessons learnt will be carried over with us to the 3rd year of our education, where we will hopefully go onto making something pretty special. Watch this space!
Title: Spin Doctor
Release Date: 31/08/12
Development time: Academic year
Engine built in XNA (C#)