Monday, June 13, 2011

What went wrong?

It's been over three weeks since my team and I took third place in Stony Brook's game competition. I have to say that after everything is said and done that I don't think any of my group-mates or myself could have put any more effort into the project without taking unhealthy amounts of sleep out of our schedule. Still, this only got us the title of "second runner-up." We have no plaque, no photos and no stories of our triumph posted on local news web sites. It almost seems as if all the extra effort was a waste of time.

So, where did we go wrong? With a solid concept and a talented artist, it seems that the problem must have come down to lack of skill and experience. But, in my opinion, this wasn't the true reason we failed to take the crown.

We were a terrible team. As individuals, we were average. With enough effort we would be able to strive above the rest. I have to be completely honest and say that I stole the reigns on this one and nearly steered us into the ground. We managed to salvage what we were good at and beat most, but not all.



What I would do differently next time and things I recommend anyone working in a group on moderate/large project:
  1. Define a clear list of steps that need to be taken and assign everything a priority level. It's important to realize the amount of work remaining on the full project so you have the opportunity to do a little less "pre-polishing" or make necessary cuts early on.
  2. Meet often and make meetings worth while. Don't show up to a meeting with nothing or little to say and try to find something to talk about. Come prepared. Make sure your team comes prepared. Send out an e-mail and tell your team what you would like to discuss and invite them to raise their own topics.
  3. If your team needs any piece of your code, explain it to them before they work on it. If you get stuck on a certain problem, make sure your teammate understands what you understand before they begin working. This will minimalism the doubling up of work on a particular problem.
  4. Comment your code. All of your code. There should be more lines of comments than there are code. It doesn't take very much time to explain what you're writing as you're writing it, and will save you and your team time when it needs to be revised.
  5. If you have an issue with how someone else is working, bring it up to them as politely and early as you can. If you don't agree that your team is doing enough or could be doing things better, let them know that you're in it together and that you're counting on them. Tell them the reasons you would do things a certain way. Bottling up aggression and saving it until the project is near due can cause a complete failure.
Here's a few things we did well and are the reasons we placed in the competition
  1. Focus on your strengths. Your team must have some sort of assets. Seek them out and put them in the spotlight. In our case, we made sure to use our artist to her full potential. When our artist told us something wasn't good enough, I did my best to accommodate.
  2. Keep in close contact with the client. In our case; our professor. People are understanding. Even professional projects are pushed back (more often in the video game industry.) Explain yourself when you run into issues and it may soften the blow.
  3. Have a plan. Look at the big picture early on. Plan to get everything done, but be ready to fall short.


Now that the pressure of deadlines is behind us on this project; I think a portion of the team may regroup and take a new start on Tempus. With less pressure, we may be able to make a higher standard for this and create a valuable entry into the gaming industry. We could only hope.