Postmortem: Pie-Parazzi

Pie-Parazzi was developed over two weeks in June 2008 by Derby Games Studio for BBC Blast. The game design concept was produced by pupils of Swanwick Hall School during a competition organised by our client. We had previously spent three days implementing two prototypes of the strongest candidates in Game Maker.

The prototype phase gave us a good idea of how the games would work in practice. The runner up (by Chellaston School) was a scrolling platformer called ‘Eco Warrior’, in which two teams of two competed against each other above and below ground to collect tokens and powerups. As such it would have been a much easier game to implement, but it was felt that it lacked depth and had not been pitched particularly well. Therefore Swanwick Hall’s ‘Celebrity Game’ was chosen for full development, despite the prototype itself being less polished than its competitor.

The game was to run on a Windows platform, but it would have to be shown and played on the Derby city centre big screen (rather large but also rather low resolution). It had to support four players so we decided that Xbox360 controllers were the way forward rather than crowding the keyboard.

This post-mortem is from my point of view as Project Manager and Programmer.

What went right

1. Development Process
   From the start we employed an iterative development process. In the prototype phase we required the teams to produce something complete at the end of each day. In main production we set three milestones over the two week period with clearly defined requirements.

   At the start of production the main difficulty was that the game design was not nailed down, so we had to be very careful not to spend all our time designing and no time implementing. We did this by giving one team member responsibility for the design elements while the others implemented common systems which we knew would be required whatever happened. The design changed rapidly at first but by the second milestone it was completely nailed down.

   Because of the very tight timescale I had to make some decisions about what made it into the final game. While not always popular, I think the desired effect was achieved. For example, I declared the game mechanics unchangeable after the second milestone, allowing only presentation work. I also rejected a number of design proposals from management which we could not have implemented in the time allowed.

   By doing this I made sure we had enough time at the end of the project to complete the essential visual polish (e.g. title screens, menus, tutorial, credits, etc.) without which even the best game would have seemed poorly made.

   Our technical manager, Adam Russell, commented that the trajectory of the project was similar to that of a much larger one if it were compressed into two weeks.
   
   

2. Considering the Platform
   We paid close attention to the target platform – the Derby big screen. We were given technical specifications by the BBC but took the precaution of visiting the screen twice for testing purposes during development. This enabled us to tweak elements of the game (e.g. font size) and identify some technical issues, namely our lack of appropriate connectors and the significant latency between the screen and the control room that made it nearly impossible to play the game in real time on the screen. We were then able to solve these issues well in advance of the launch day.

   The platform also dictated the audience. The game would have to be ‘pick-up-and-play’ which caused us many problems bearing in mind that the winning game was selected due to its depth of gameplay. We constantly had to balance these two goals during development.
   
   

3. Choice of Tools
   The original plan had been to develop the prototypes in Game Maker and then the final version with XNA. However, once the winner was chosen it became apparent that we would not have time to implement it fully in XNA so we chose to continue using Game Maker.

   I believe this choice was the right one, although there were pros and cons. On the positive side, we ended up with a much better game. Had we used XNA we would have had to essentially re-write at least half of Game Maker before we could start actually designing the game. We simply did not have that kind of time and it is likely that, even if we had, the result would have been buggy and still visually no better than Game Maker output.

   However, it was not all plain sailing. Game Maker was never designed for team development. It is possible to import scripts and whole project files but this was only really useful for complete subsystems. Especially towards the end of the project we found that project-wide changes were necessary. However, we learned a lot about how to use Game Maker collaboratively:

1. • We used Subversion for source control, although this had to be over the whole project file (which grew to about 12MB by the end) resulting in long commit times.
   • After the first week we used a physical ‘build-token’ (a Lucozade bottle) to show who was currently making modifications to the active build. After the changes were committed the token was passed to the next team member who needed it, essentially locking the project file.
   • Wherever possible we developed subsystems independently before importing them into the project (e.g. the game timer, the player and shop state systems, the particle effect systems, the gamepad wrapper).

There was also some initial opposition within the team to the idea of using Game Maker for development, but this snobbery mostly disappeared by the second week. However, the team consistently underestimated the API and in some cases wrote features that were already available.

1. Game Design
   As mentioned above, we started main production without a clear idea of how the game would actually work. The prototype had a number of design flaws and the final game turned out to be quite different.

   The original pitch was for a game about four celebrities who each had to buy four items from a mall. If they bought the most expensive items they got a golden ticket and entered a maze to go to an awards ceremony. At certain points there were paparazzi who would photograph them and slow them down. Therefore there were elements of racing, item collection, and puzzle solving involved.

   In the prototype phase the main question which kept popping up was ‘how do I win’? The mechanic was so complex that in many cases the victory condition was undefined. At this stage it was also taking about 15 minutes to explain how the game worked.

   However, we had a breakthrough after the first milestone. We realised that the unifying principle was fame. By ditching item collection entirely and basing victory on fame we made the game a lot simpler to understand and more fun to play. We also hit on the idea of representing current fame by the size of the player’s head (instead of a separate fame-o-meter), saving valuable screen real estate. After this breakthrough we were quickly able to come up with a simple system of player states (good/bad/neutral) and transitions and soon afterwards nailed down the gameplay.

   The only remaining problem was picked up in playtesting – namely how to tell who is currently in the lead (as only the leader is able to throw other players out of the limo – the player in the limo at the end of the game is the winner). At the time we agreed on a racing game style place number indicator, but after implementing this we realised that there could be a usability problem if the player in first place did not win at the end of the game (because they were not in the limo). We didn’t want to lose the limo as running after it had proved to be a fun mechanic in playtesting. We therefore hit on the idea of using a crown to denote the current leader. Only if a player wore the crown could they displace another player from the limo.

   The game design could have gone very badly wrong, but in the end I think the final product is readily comprehensible, has some depth and more importantly is fun to play.
   
   

2. Art
   We were very pleased with the character art and environment art produced by our team of artists (two of whom were unpaid volunteers). In particular, the inspired character art and animation of Ash Barnard was right on target in terms of the feel we were aiming for. All the art produced by the team fits in well with the farcical theme of the game and significantly adds to the game experience.

   Collaboration between the artists and programmers was good, for example on issues such as alpha channels, visual style, tile-set implementation, etc. The programmers made sure the artists knew the technical requirements of the platform. The artists took direction well and provided the art in a format we could use.

What went wrong

1. Team Selection
   The team size and composition was based on incorrect assumptions, namely that we would be developing the game in XNA. Because I had serious concerns about our ability to do this within two weeks, I pushed for more programmers than artists initially. However, once we decided to use Game Maker we no longer needed as many programmers and found ourselves lacking in artists (having only one). We therefore reached the second milestone without very much in the way of environment art, which caused a lot of concern. Once we were aware of the problem we petitioned Andreas, the studio manager, for an extra artist. We were also lucky enough to have two unpaid volunteer artists working with us in the final week of the project who contributed greatly to the environmental art.

   In general I was very happy with the quality of the team. However, we did have one team member who turned out to be a subscriber to what Julian Gold calls the ‘Hacker’s Charter’. Despite being arguably the best programmer and a very intelligent and likeable individual, he suffered from…
   
   

“…the tendency of team members (programmers in particular) to ‘go off on one’ and spend disproportionately large amounts of time on non-critical tasks”.
[Gold, J. 2004 – Object-oriented Game Development, Addison Wesley, Harlow]

Sadly this habit (especially undesirable in a two week project) meant that a lot of my time was spent curbing his worst excesses (e.g. advanced AI, unnecessary movement modes, premature optimization) and I had to ‘stamp’ on him quite hard on more than one occasion when he disagreed with decisions I had to make for the sake of pragmatism.

1. Arguably the Choice of Winner
   We could have saved ourselves a lot of time and effort by backing the easier and more well prototyped of the two designs. If this had been a purely commercial project then we would have done so, but we had to bear in mind that there were also academic goals for our client and in the end it was felt that the winning school should be rewarded for their superior pitch. It was also felt that the team (composed entirely of undergraduate students) would benefit more from the more complex and challenging option. In the end, however, the choice of project was vindicated, but I am sure we could have made just as good a job of the other design and had more time to make it really sparkle.
   
   
2. Perhaps Too Many Cooks Management-wise
   Within the studio itself we had several layers of management. First me, as project manager, then the studio manager, then two academics in the technical and art management roles, as well as a number of other academics involved in the design and playtesting process whose opinions carried far more weight than the average playtester due to their positions.

   Things worked out well in the end but at times there were so many people giving (conflicting) input to the project that it was hard to know what to do.
   
   

3. Unfixed Bugs
   Because of the very short timescale there were some known issues which we had to decide not to fix. One of my more unpopular decisions was stopping bug fixing on the ‘double bad pose’ bug, where the negative pose animation always plays twice instead of once. However, as I had already lost one team member for the entire morning trying to track it down, and it did not seriously affect gameplay, I decided it was not worth wasting any more time on. There are one or two other obscure bugs that occur under certain rather rare conditions which I also decided we did not have any more time to spend on fixing.
   
   
4. Communication with our Client
   There were layers of management within our client which made things more difficult. For example, our client department had no connection to the big screen department who had to approve content and supervise our testing visits, who in turn had no technical staff on-site. It was also unclear how much priority was being given to the project, as in the end it was only displayed on the big screen for 30 minutes during the day.

Conclusion

The team is rather proud of the finished game, and the client is very happy. The game met all the requirements laid out by the client and was considered fun and ‘awesome’ by the players on the day. It also has some depth to it without confusing the casual player too much (everyone who played it got to grips with it fully by their second turn).

I think we worked well as a team, learned some important lessons, and turned out a great product considering we only had two weeks.

Data Box

Number of full-time developers: 1 project manager/programmer, 3 programmers, 2 paid artists, 2 volunteer artists.

The budget of the game: £10,000

The length of time the game was under development: 13 working days

The actual length of the game (i.e. number of lines of code).: Approx 4000 lines

The release date of the game : 25 June 2008

The platform(s) the game runs on. : Windows

Hardware used in the development of the game: Standard University of Derby workstations

Software used in the development of the game: Game Maker 7.0 Pro, Photoshop

Notable technologies or technical underpinnings that were used/licensed for the game : SINAZxInput v1.0 – An XInput wrapper for Game Maker, Assembla.com for SVN hosting and team management