Student Postmortem: Postmortem pt.1

Original Author: Tyler Coleman

Hello everyone! My name is Tyler Coleman, and this is my first post on #AltDevBlogADay!

Rather exciting, isn’t it?

For my maiden post, I reviewed the Ara Shirinian’s Gamasutra post on the Game Developer Magazine postmortems over the past two years. Seeing the data for AAA and professional budget projects piqued my curiosity, so I set out to determine if there is any correlation to student projects.

In the first part of my analysis, I will cover team size, development time, and tools. This analysis will cover the general information about these projects. In my second part, I will cover What went right/What went wrong, as well as Lessons learned.

 Team Size


Student Postmortem Team Size

Student Postmortem Team Size

The average team consists of 9 people, with the majority of teams having 4. There are also a few reports of teams also consisting of contractors or part time workers. These averaged at around 5. A few outliers, such as Master Plan, had a team size well over 25. There was a broad range of team data, which will be further analyzed in my next post. The majority of members held more than one hat on the team, which is to be expected at the team sizes shown.


Development Time

Student Project Development Time

Student Project Development Time

The average development time is 8 months. The majority of projects last 7 months. I expect this is linked to the fact that most of these took place over the course of two semesters, or one semester and the summer break. There are a few that took over a year, with Gemini Rue coming in as the longest, with 3 years. There was also many projects that did not directly state their development time, so they were not included in this data.

I also did a scatter plot of team size & development time. There is no correlation between the size of team and the time of development.




Student Project Technology Chart

Student Project Technology Chart

The technology used in these games is very broad. The majority listed using an internal engine, or one that was unique to their project. This includes games such as citizenMOB, a game utilizing the J2ME SDK for an ARG. The fact that many student projects built their own engines is very interesting, as well as those that did not list any technology. One interesting aspect of this data is the change over time. Out of the most recent 10 games, almost all of them use some form of game engine or library. The games in the beginning of the data rely almost solely on internally developed engines (or otherwise didn’t list one).


I expected far more projects to be using externally-developed engines. The fact that so many projects used DirectX and OGRE is a surprise for me. I expect that there may be more of a shift towards external engines, as more colleges are now aiming at developing design and art degrees. The concern here is that many newer students may not learn the core architecture behind the game engine, but perhaps this is no longer necessary?

I also found the team size to be quite interesting. It seems that there is a broad range of team sizes, as well as game scopes. Many of the projects I have participated in were either solo or teams of around 8-12. The fact that some of these projects broke the 20 person mark really took me off guard. It is certainly a valuable lesson for the students involved, and gave the opportunity for students to assume leadership roles in a large team.

There isn’t too much to say about the development times. They are significantly shorter then the average professional product, but there were no illusions otherwise.


Part 2

On my next post, I will be covering the What went right/wrong and breaking it down into discipline, as well as subjects important to student developers. Thanks for reading!