The ZGXP (Part 3 - A Busy Weekend)

The internship at ZeeGee Games has been going well. My team sent off a preview of our ZeeGee Reader iPhone app to the client last Friday and got a lot of positive feedback about that, so that's cool. We got new art assets from the client at 5:00 Friday to incorporate. Normally this wouldn't have been a problem, but we had planned to close up shop at 5:30, an hour and a half early, on Friday. It was a longtime employee's last day and we had a party planned to see him. Max, our Producer, had left earlier that afternoon for a conference, so I was holding the reigns. I checked in with Dustin Clingman, our CEO, to apprise him of the situation. Putting the assets in would require myself and the project's artist and programmer to stay later than we had intended, but not putting them in would be noticeable to the client testing the app all weekend. Dustin left the decision to me. I chose to put the assets in, which ended up making us about 45 minutes late to the party.

Immediately after the party, I headed back to ZeeGee's office where we were hosting the Orlando game jam for the Healthy Games Challenge. Got the team together Friday night and worked until Sunday evening on a game. Once again, a lack of solid programmers kind of hurt our game, but I do enjoy the game jams I've participated in. They're definitely good learning experiences. Lessons learned at game jams:

• Severely limit your scope when your time is severely limited.
• Planning is important: If you're starting development on Friday for a weekend game jam, you're probably going to be in trouble come Sunday.
• Clear organization of assets and team member roles saves a lot of time, especially when crunch happens Sunday afternoon.
• Early on, the entire team should be involved in design so everyone has a chance for input and a clue on what direction the they are heading.
• Design docs are damn near worthless if they aren't clearly communicated to everyone on the team. As soon as a design doc is written it should be shared with the team so they have a single point of design reference.
• Rapid prototyping is very helpful in creating a clear design goal and motivating the team.
• Team conflicts need to be addressed early and resolved quickly before they slow the team down.
• Need moar programmarz!!1! I'm beginning to think programmers avoid game jams because if they wanted to make a game in a weekend, they'd sit down and do it. I shall resort to bribing and/or kidnapping programmers next time...

Really, they're all pretty basic producer concepts, but in the hustle and bustle of game jams, these golden rules tend to get forgotten. Game jams are a good opportunity to spend a weekend learning these lessons instead of four years and millions of dollars. That's been my main takeaway from the game jams. Both games I've worked on definitely have potential, but are sort of stuck in development limbo. The experience and lessons learned are more useful to me right now.

I think that's about all I've got for now. My ZeeGee Reader project will be in the Apple Store approval process by the end of the week, so I'll have my name in the credits of something you can buy in the next 6-8 weeks. And that'll be cool. Also, I'll have a critique on Red Dead Redemption up this week. And that'll be cool too.