Following my previous posts about the development of the New Intelligence serious app (here, here and here), this is now the post mortem. Hooray, I hope you’re excited. I’m excited.

With that introduction, lets just get cracking right into it then.

What Went Right

Splitting the Group

While it’s industry standard, during the course of our degree the designers and programmers haven’t really been split apart during game development. We’ve always been in the same “roles” during the short projects, usually lasting only a few weeks. With the New Intelligence App, we had far longer to create this app, (10 weeks or so) which meant that our roles were more specialised, and we weren’t doing a few weeks of “EVERYONE DOES A BIT OF EVERYTHING”. This meant that the programmers did programmery things, and the designers did designery things, much like how the industry actually works. This was an excellent learning experience for everyone involved, as it forced people to be consistent with their communication and their design. One of the designers, Josh, was a liaison between the programmers and designers, which was great for keeping the communication consistent and direct.

XML Data Handling

The manner in which we constructed the data being read into the game made the development of the app very easy. While using the XML in the first place made the project scope incredibly large, once it was implemented, it was a very easy to grab the necessary data and implement it where necessary.

What Went Wrong

Project Scope

While the game itself was relatively simple, the back end in the code we created was not. Rather than manually making individual activities as their own scenes, we (the programmers) made the decision to make a dynamic XML reading system that would allow the designers to only update a CSV file to create the game content. While this allowed for the project to scale upwards in a very large way, this came at the expense of development time and bloated the work we needed to do.

While I believe this was a correct decision if we had extra development time, we might have been better suited to hand crafting the game elements instead of dynamically creating them. This would have allowed us to create more content with more polish, which I feel would have impressed the client more than what we presented.

Documentation

Surprisingly, not the Technical documentation on our end, but the Design Doc. During development the programmers and designers split off, each working on their own sections. As a result, us programmers relied more heavily on the documentation created to base our systems off. This would have been fine, except there was a few instances where the designers had made a change in design as a group, but failed to update the documentation. As you can imagine, intrepid reader, this created problems when certain designs weren’t implemented, or designs weren’t made to specification.

To prevent this happening in the future, I have started making it clear that I will be basing structure and design off of their documentation, and that it doesn’t exist unless its on paper form.

Programming Team Management

While the designers had very defined roles in their part of the New Intelligence App development, the programmers, not so much. We never fully set any roles for any of the 5 programmers, and this resulted in a few instances where people didn’t know what they were doing. I ended up taking a “programmer lead” role, just because I would step up and organise ourselves to allocate tasks and plan the systems.

However, as this was ever an official role, I could have done more planning and allocation of tasks earlier. There was a week or so period where only 2/5 programmers were working on the project (myself and Phil at this time), just because we thought we were implementing a core system that needed to be made before other systems.  However, we ended up not needing to rely entirely on this core system, meaning there was a massive loss of potential work that could have been completed  during this time.

To remedy this in the future, I’ll be insistent on what roles everyone (including programmers) has from the start of the project, so that individuals know what they’re supposed to be working on. In addition, as I am again being put into a programming lead role for final project, I’m going to be more on board with task allocation and making sure everyone has something to do at all stages of the project. I will also ensure I do a lot less “taking over” of programming tasks. While I knew all of the tasks that needed to be done during the project development, I needed to spread my work out to others so that more people were working, and I could do more managing.