Oxygen is a survival horror investigation game for PC being developed by a student team at the University of Advancing Technology. This is a postmortem of our first 15 weeks of development.
Oxygen is a survival horror investigation game for PC being developed by a student team at the University of Advancing Technology. We began development of the game this May and this is a postmortem of our first release build of the game. The game is still in development at this time working on the next planned release.
Distributed Work Environment. We integrated remote workers onto our team, and the integration accelerated our development tremendously. We recruited online students from all over the country and they put in twice as much work as our on-ground team in two thirds of the time! Some of our distributed team members have reached out to us asking if they could continue working on the project without being enrolled in the course next semester.
Technology. We were able to set up our team with the tools that they needed to succeed. We set up a couple private channels on our game studio Slack and the channel enabled us to work with our distributed team. We also set up a slack channel specifically for our junior programmers to ask programming questions and they made good use of the channel to solve programming problems quickly. We had minimal version control issues since only team leads and programmers had permission to make commits to the subversion repository.
Unity 5 UI Tools. Unity's new user interface tools made developing a good UI for the game a breeze. I was able to throw together a rough prototype health/oxygen script with a good looking UI after 5 minutes of work. This rough prototype served as our UI for most of the builds of the semester until the designers and artists could begin tweaking the pacing of oxygen loss and the look of the interface.
The Greenlight Celebration. This semester's greenlight celebration was the largest and most useful I've seen yet. It was so good that I dedicated an entire blog post to the greenlight pitches and celebration. We were able to get an early build of our game in front of an audience and see how people played our game. We were surprised to discover that our game was interesting to younger children and received some great feedback we intend to incorporate in our next release.
A Slow Start. We got off to a slow start at the beginning of the semester. We didn't have a working prototype yet when we got started, we lost our first week of work to a holiday and our second week of development was mostly focused on getting the new recruits up to speed, so development of the game didn't truly get underway until we were three weeks into the semester. Our remote team members also got off to a slow start because they spent their first week of work getting up to speed on the project.
Communication. We lost some time due to a couple of miscommunications between our on-ground team and our remote workers. A few tickets were poorly described and we had remote workers work on the wrong task as a result. The other communication problem we ran into is that on ground students aren't as responsive as our remote students. We had a couple of our remote developers go two or three days without getting an important question they needed answered so they could continue their work and we lost some velocity as a result.
Last Minute Builds. Unlike on my last project, just about every build we presented at a build review came together at the absolute last possible moment and not every feature that had been worked on had time to be tested and implemented into the build for the week. For our next semester of development we've decided to set aside a day of the week that everyone must submit their work to be reviewed and implemented into a build to be presented at the next build review.
Team Make Up. We were starved for artists this semester. We had two artists in the on ground team, an art contractor here, and one remote artist. Our on ground team was still early in their degree program and hadn't yet learned how to unwrap and texture models. On the flipside, we had more programmers than we needed and we started running out of work for them to do at the end of the semester. Having too many of one discipline can be almost as bad as not having enough because we had to keep generating new tasks for them to work on that were outside of the scope of our release for the semester.
This semester was an experiment in integrating remote accelerated game development students on an on-ground development project. Overall the results were spectacular. We learned a lot about communication and the integration of remote team members this semester. When our remote team members had everything they needed they could accomplish two to three times as much work as our local team members! On the flip side, any delays in communication or miscommunications were two to three times as painful because of how much more work was lost.
We also learned that having a larger team contributes to scope creep, but the only reason it contributed to scope creep is that we were running out of planned programming tasks for the programmers to work on for this release! Although we didn't achieve all of our goals for this release, we achieved our highest priority goals for this release and the feedback we've received may take us in a slightly different direction than we had originally planned as we integrate new technology into the game.
We now have a better idea of the resources we need for the project to succeed and for the game to be great and we’ll be using what we’ve learned in this postmortem as we continue forward on the project and develop the next release plan for the game.
You May Also Like
