Project Grudge is a side scrolling shoot-em up game developed by a team of nine students during Game Studio 1, a three month long intensive team project class where we go through full production on a game. The player assumes the role of a UFO taking over Earth using alien technology to interact with the world. Our focus with the game was to create a uniquely inspired audio/visual experience with some kind of hook in gameplay. We decided to structure the gameplay as a three-tiered system utilizing a feature we dubbed multi-channel gameplay. The term was derived from the RGB channels in digital images. Gameplay was meant to mimic this by having each objective have a respective color and button to highlight it in a manner similar to sonar.
The visuals in the game were greatly influenced by Tron and combined with street art and light graffiti. We focused on creating visuals that highlighted contour lines in contrast to a pitch-black background of the game. Our audio direction drew inspiration from Rez and the Bit.Trip series of games. Both of these games try to simulate the effect of synesthesia by syncing audio and visuals to each other. We wanted to emulate this effect as much as possible. The goal was to sync audio effects with player actions and have them seamlessly mix into the background loop, ideally through the use of timers controlling all actions.
Although our final result was unable to complete some of the lofty goals we set forward, we were able to hit the core ideas we wanted.
WHAT WENT RIGHT
1) Design tailored to strengths
Our team was composed three programmers, three designers, a single artist, and two producers. Because of this our team knew we needed to focus on creating a game that gave us a technical challenge yet was light on the art. The idea of taking a Tron like approach, focusing only on outlines or at least going with a hyper-stylized approach to the game was proposed early on in the process, and the team immediately took it up.
This ended up playing out well because there was also a concern with our artist’s work ethic. The final art style required very little work on his part to bring it into the game, and left us doing very little with animations. This significantly cut down on the number of assets required.
By sticking with this direction we were able to complete our art goals on time, and expand upon the art direction in the late stages.
2) Top-down visually oriented design
In a top-down visually oriented design, developers focus on the overall experiences that they want the player to feel, and then generate the content and gameplay to create those experiences. This is opposed to an action oriented design, in which the interaction is created, and the theme and level design is structured around that. In our case, we did the former. Our brainstorming sessions resulted in vague ideas of concepts, rather than what we wanted the player to do. These concept meetings resulted in determining our theme, and once determined, we started to figure out how the player would play the game. This allowed us to create quick asset lists and initial projects schedules, which was useful with such a short pre-production phase. However, this ended up limiting our features because we constantly had to make attempts at fitting a feature within the initial vision of the game.
This may not be the best manner to approach game development, but it does make initial planning easier, and it’s understandable why larger projects often take this approach. It provides quick scheduling of a project and much clearer expectations from the onset.
3) Building code from ground up
We were lucky to have two programmers with over a year of experience between them in C languages (not exactly a lot by traditional standards, but more than nothing). Because of this we decided to write from scratch within XNA. This doesn’t mean our engine is built from the ground up, but it did provide us an opportunity to create all the features we wanted in our own manner. This meant our programmers knew exactly what the code was doing and how it worked.
An added benefit to this was the experience it gave our programmers. Starting from scratch is a daunting task, especially with a team that was unorganized technical documentation for the game. After realizing mid-way through development the necessity of technical documentation, it became apparent how necessary it is to prepare for features that need to be implemented during pre-production. By doing this early in the process it likely would have greatly helped us schedule more accurately.
4) Team Dynamics
We were blessed enough to be a team that meshed extremely well together. Throughout production we were devoid of any serious issues regarding personnel, and everyone was light hearted and open with their opinions. This made meetings fun for everyone and maintained morale through the course of the project.
At the start of the project my assistant producer and I thought there would be a challenge of getting a group of nine people who didn’t know each other, and their respective skill sets, to work together and become friends. To ease this process we put up a front for them and pushed them to complete their work immediately on time. The very first thing was ask for two things from each person: to CC me on the e-mail to Erik with their ‘resume’, and e-mail me their schedule. The very next day we checked in with the whole team and read off who sent those items, told them nice job, and asked that anyone else who hasn’t sent their materials to do so immediately. This accomplished two things: it showed them that we were paying attention to their work, and it set an expectation that we were going to be tough on them. Although we had no intention of remaining strict through the entire process, unless needed, we found it unified the team on the offset by having a shared experience by everyone.
5) Facebook Groups are fantastic for communication
From the very beginning our philosophy had been that the more difficult you make something for an individual to get done, the less likely they are to do it. Because of this, Facebook was the perfect platform to handle our lines of communication.
Within our age group you see an attach rate of >95% on Facebook and over half of those people are on the site daily. If we were to compare those stats to those of traditional e-mail, it’s likely we would see Facebook completely dominate. Because of this, we knew our team would be constantly checking Facebook regardless of the project or not, and by tapping into their news feed and notification system we were almost guaranteed to have our team respond to anything posted.
With this in mind, we immediately set up a Facebook group for the team. This small action ended up being an unbelievable tool for keeping our team in touch and willing to communicate. On top of that, the group page became a portal to the production of the game. Any important information was posted to it immediately and links to our Google Docs were easily accessible through it. We actually found the Facebook group to be more reliable than e-mail when giving out information to team members. Part of the reason for this is that the group essentially acts as a large e-mail chain with everyone attached to it. This allows team members to keep a constant beat on all aspects of production and we feel places peer pressure on members of the team motivating them, akin to a burn charts function in team motivation.
An unexpected benefit of the group was it bringing our team closer together. Often times during classes our whole team would be on the group discussing random things usually related to class, but sometimes not. It became our source of information when we couldn’t ask a teacher and allowed us to work as a group from home. Multiple times during the course of production we would find the programmers and I online late at night doing coding binges and answering support on the code.
Though Facebook Groups worked well for us in this situation, it may not scale well to large teams. Chats can become bogged down and information may be lost if the team goes over 15 people. This might become even more of an issue during long production times. However, on a small team for short development periods (< 6 months), I think we would definitely use Facebook Groups again.
WHAT WENT WRONG
1) Poor time estimates
This problem is directly associated to our lack of experience, but it is worth noting how important time estimates become in planning out a game project. Despite our programmers having some level of experience prior to coming on board here, none of them had worked with a game project or XNA. This meant our team had very little basis for how long certain features of the game would take.
Ideally when planning a schedule the producer would create a list of things that need to be done to complete the game and consult with the leads on that list as well as how long each would take. In our case we could neither estimate all the parts necessary to complete the game, nor the amount of time each one would take. This meant we were going in completely blind with a schedule that had almost no bearing. Because of this, we knew some milestones would be missed, and we tried to plan for that. The thing we didn’t realize was that we had no way to judge how important certain features were over others. On top of that, our design process limited how we could handle missed deadlines. We built no room for cutting or redesigns, and were stuck forcing in the content we wanted.
If I were to put a number on the amount of times an estimate was missed, it would be somewhere around 90-95% of the time. When they were hit, it was often a half completed job that still needed another day or two of work.
There’s absolutely no person to blame for this happening. It was a direct result of the methodology behind Game Studio 1. We are meant to go into this not knowing what to do, make some mistakes, and come out in the end understanding a lot more based on those errors. This problem ended up becoming one of the largest learning experiences in this project. It absolutely proved how important accurate scheduling can be to a project, as well as giving our programmers and producers a better understanding of what certain features will take to implement.
2) Lack of oversight and review
For about four or five weeks on the project, Bross and I were not reviewing code or art assets. This was a major error on our part, and prevented me from being able to directly assess situations. I had realized during this time that my programmers were inconsistent in their estimates and I was not giving the structure needed to our artist to make sure art was being completed on time. Had we been on top of our team at all moments making sure content was coming in on time and to the quality we expected, we would have had better assessments on how much work was being completed by the team members.
Another benefit can be gained by doing this oversight and review that I didn’t consider initially. If we had been doing this from the beginning we could have monitored the quality much closer. Of course, this would have meant planning for more time in the schedule to have additional redo’s on assets, which was already an issue on such a short time frame.
3) Delegation of tasks did not happen enough
A large portion of the work on the game was done by the few and not the many. To say that this game could be made in less time by a team smaller than ours is an understatement. With only four people (not counting audio) we could have done this game in the same amount of time at a similar standard of quality. This can easily be explained by a lack of delegation.
One of the first things I did was set up an initial team structure. Bross and I were positioned at the top of the team, with our three sections each headed by leads. Those leads were decided at a different time. Unfortunately, I didn’t take advantage of this structure as much as I should have. The leads were never fully taken advantage of when it came to scheduling the requirements. On top of that, meetings were almost never held with just one portion of the team because I felt that with a team this small it was unnecessary. I found this to be woefully wrong about mid-way through the project when we started to become disorganized and it became apparent that the majority of decisions and work were being placed on top of me to coordinate.
What should have happened were small team meetings with individual disciplines (despite the size) to determine what needed to be done and make any decisions that were needed. On top of that, I should have utilized the time on Monday evening that I set aside for a lead meeting. The two times I took advantage of that spot it was extremely helpful in setting up direction of the project and assessing our current situation.
4) Half implemented scrum processes became a waterfall
The goal with initial scheduling of the project was to set up weekly milestone “sprints” that would enable us to keep track of overall progress easily. So we started off by doing that and setting up weekly check-ins with the team regarding progress of milestones. This didn’t work out so well for us. We quickly were falling behind on milestones, and because our poor time estimations, we had no idea when to expect features being up.
What this ended up causing was a huge bottleneck on our tech development, on top of large crunches on major milestones, especially the end of the project. Features were two to three weeks behind schedule with no indication when they would be done. Despite having room in the schedule to help deal with this, as scrum development prepares you to miss feature deadlines at times, it does not handle the kind of delays we were seeing. Our design team was stuck sitting back not having any work to do because they couldn’t test a game, and due to our features already being set, we were unsure if any new features would even have time to get into the game.
Our implementation of scrum didn’t allow the ‘sprints’ enough time for development to happen. We found tracking development progress is very hard on such a small scale, and it ended up diminishing the effect of these sprints for our team. Each one had less weight than it should have. One way we could have increased the importance of our sprints would be to extend them to a two-week length, rather than the one-week length we used. This might have alleviated some of our delegation issue and removed strain at the end of the project.
5) Code Overhaul
Four weeks before the project ‘ship’ date I got a text from my lead programmer that said to not touch the code for the meantime because it is undergoing a major overhaul. At this point in the project we were slightly behind, and had just implemented a major feature into the game, and were finally on track to have designers start designing and testing within a week. There was no notification before this decision. My immediate response was to ask him if he had used the newest build with a large feature that had finally been implemented. He told me he didn’t grab it and we were using a three day old build. This meant we would have to completely rewrite this feature within the new coding scheme. On top of that, it set our bug testing document back, as several bug fixes had been implemented since his build, and those bugs now had to be reassessed.
This event was immediately after a discussion between him and me regarding work estimations, and so I checked with him when this overhaul would be complete. He told me by the next day before class it would be back to where the build was at previously. That didn’t happen. It took us a week to get back to the normal state it was in before the overhaul. We also needed time within the framework to relearn the code and understand how it worked. This ended up causing a delay for our designers as well, pushing back their ability to work even further.
Though I made it apparent that I did not disagree with the code rewrite, as ideally we would have, it was almost too late into the project to make it a priority issue. Our priority at that point had shifted from getting code clean to focusing on getting features in the game. What I felt occurred was a lack of big-picture understanding from my lead and more importantly, a lack of communication. There was no discussion before this happened, and no time to consider the options. There is no doubt that this set our code back at least two weeks, and as a side effect, killed the productivity of the coder who had implemented the major feature that got pulled out because of the code rewrite on old code.
Conclusion
It was never expected of the teams in Game Studio 1 to come out perfect, and we knew that going forward. Because of this my best hope was to hit our initial predictions and features without anything extra. Although it’s hard to say right now because we aren’t finished with the project, we’re on track to have a game with the features we initially planned on. The structure and overall design I had hoped for with level progression and difficulty curves is unlikely to happen with only a week and a half left. If we had another week or so for testing we could implement some of that in a more complete manner.
Right now the synesthetic elements aren’t implemented in game, the assets are being finalized and I’ve made sure the game is ready to support the structure, so we should see that before final. Unfortunately a concession was made on the intuitive gameplay. Given a few more weeks we could have focused on creating a gradual tutorial for the game, but instead we had to cut back and do a more traditional method of teaching the player. It’s unfortunate, but necessary, and was a cause of scheduling problems near the end of the project.
Finally, it’s also good to stress that this post mortem is strictly from a producer’s point of view. I’m positive some of my team will have comments regarding their specific area, yet despite that, I still feel like the project was a failure on my end with producing. There are excuses that could be made, but those don’t fix anything afterwards, nor do they make up for it. Instead I feel it’s best to focus on how I can fix issues going forward. In this case, I know I need to utilize my team structure more, and do far less micro-management. That’s a hard thing for me because I like to be as involved as possible. At the end of all of this, there’s a lot to take away, including a project that can be shown. I’d like to spend an extra two weeks in post to touch up some elements and spice the game up to create a better showing game, but we’ll see if that’s possible. However I still feel at the end of it all that our team had higher potential then what they achieved.
Addendum –
This post-mortem was written approximately a week before the project fully wrapped, and there were a few issues identified after the project wrap that I would like to address. The largest thing that was noted was our lack of pipelines for design and art. We never took the time to set up processes for moving levels in game for testing, or for art to get from concept to finalized asset. On the art side this was especially apparent because of the need to review the methods for finalizing an asset with our artist multiple times. Had we prepared a formalized pipeline for him we could have easily moved content and it would have allowed for less overhead in preparing assets. In regards to design we failed to implement level loading at an early stage of development, preventing our designers from play testing and gaining feedback in the early stages of development. This meant our iterative cycles on design were not implemented until very late into production which may have contributed to a weaker design response.
Next time it is apparent we need to take the time in pre-production to set up art and design pipelines in order to set up iterative processes early on. Without this we fall into production backups where groups are stuck waiting for another to continue work. Obviously this doesn’t automatically solve this problem, but it can alleviate many issues.
