Sunday, April 27, 2008

Semester 2 - Post Mortem

Semester two has come to a close and a big congratulation belongs to team Zephyr. Their vertical slice dominated the vertical slice presentation. That's not to say that my own team, team M.E.A.T. did not meet expectations, simply that we got beat out. After talking it over with others on my team we've decided that we could either lick our wounds or we fight harder to raise the bar. We elected the latter.

This semester has been a whirlwind of excitement. From the beginning more has been asked of us than ever before. While some management decisions resulted in about a month of lost programming hours on our team, it did result in a well thought-out programming architecture and heavily researched approach. It also exposed us to new ways to think as a result to the classes of FIEA. While some of the programmers think it was a month lost, I can't help but wonder if our architecture (which has resulted in much praise on our own behalf and amazing results later in the game) would have been as well planned out. I dare say it would not have been, and our development time would have been littered with game-stopping delays.

I owe it to Sean McVey to say that he's done a wonderful job modding the scene designer to work with the terrain manager which was designed for the game. Although in retrospect we have identified this decision as one of the bigger mistakes of our team. We invested a huge amount of time into the terrain system on all ends, and we have been receiving feedback that “the artists could have done it better”. While this is usually the case, and probably is the case in this particular instance we wanted to free the artists of the level design burden and give that to the producers where it belongs. Doing the terrain programmatically also allowed us more control of terrain at the programming level and simplified our path-finding algorithms. I suspect that our post mortem at the end of the project will rip to shreds the time spent on the terrain manager, and in a future project of this scale it might elect to have the artists work more closely with the designers to generate levels. Although with our current solution if we decide to have more than the proposed two maps our producers will be in a good position to crank out a ton of them.

I'd also like to do a shout out to the other programmers on my team (Paul Watkins and our Lead Billy Bramer). It has been an incredibly stressful semester and it helps to have a support line of like-minded individuals. It is even better when you've developed what will prove to be lifelong friendships with the guys you've spent a year of your life "In the trenches" with. Stressful or not I'd like to believe we've all grown, and that in the end the semester was successful and well worth the effort expended. If even one of us dropped the ball, I would be writing a very different post mortem.

As a team, as a whole, the necessary comraderie has been missing to produce the best possible game. A lot of blame was flying around at the end of the presentation and I think we all owe it to ourselves to take a step back and ask the question if we are treating the other team members the way they should be treated. I know that I have managed to subconsciously treat some individuals less than they deserve, and I intend on working on that over the next semester.

I also think we as a team need to reflect on ourselves and verify that we gave everything we could to our project, our team and retrospectively to our education. Speaking for myself, I can happily (although somewhat wearily) state that I have given it my all.

Lastly, just because I have to give a warning to all other future FIEA programming students; Dr. Gourlay is not half as scary as he appears to be, but his assignments are ten times as vicious. Stick to it, don't fall behind, and by the end you'll be proud of what you accomplished.

Friday, April 18, 2008

Astonishing April

I got a big surprise this week. The powers that be here at n-Space elevated me to the position of lead designer. I'm now in operational control of my entire design team and in creative control of the game. For those of you not keeping count, this happened about a year and a month since my first day at the company.

Making video games for a living at a great company with great people is about as close as you can get to "the dream." Actually being in charge of the whole operation is that much closer. It's a real thrill -- and a real change from my usual duties -- but I'm confident that I'll be able to get the job done.

All of my superiors were incredibly supportive and encouraging when I was given the position. But the greatest compliment is from everyone else -- my day-to-day coworkers. Upon receiving the news, they immediately started treating me as though I'd been lead designer all along. There were no jokes, or jabs, or smart remarks, or expressions of disbelief. It was simply business as normal. I felt really appreciative of that.

Exciting times!

Thursday, February 28, 2008

Tree-based far-field interactions

I added tree-based far-field interactions.



I provided two movies: pretty and nifty.



This diagram tries to explain how the influence algorithm works. Obviously I need to throw more words at that, which of course I will do in the near future. Stay tuned!

Thursday, February 21, 2008

A Difference a Day of Production Can Make

Team Awesome is almost halfway through the Pre-Production phase of our final game project. I am going to share some insider knowledge on our progress for the Cardinal of Zephyr , an airship battle game. Every Thursday, Team Awesome presents a status report to Executive Producer. The EP is the gatekeeper for keeping a project online. The moment he or she feels like your project is a waste of time or money, then the house of cards built by your development team will come crumbling down to fall into the fiery pits of hell.

Rule 1: Keep your Executive Producer confident in your ability to complete your game project. It may sound rudimentary, but you will be surprised how many games crash and burn because the EP has no confidence in the project.

Thus far, we have been able to successfully relay our vision of the game to the EP. Without fail, week after week, Team Awesome moves forward on Cardinal of Zephyr. Here are few more rules that I've learned by working on the best game development team this side and the other side of the Mississippi River.

Rule 2: Construct a rigid flexible schedule. Yeah, I know that sounds like an oxymoron. But, you want to make sure that your team can adhere to realistic deadlines, but flexible enough to shift dates around if necessary.

Rule 3: Trust your teammates to do what they are good at and encourage them to perfect their passions. This is quite tricky because some of your teammates may not know what they perform well. They may also assume they're distinguished at doing a task, but they are not that proficient at it. Even worse, their assumption may be their passion. This can be detrimental to the team's overall performance if this person's ability to complete the task is the weakest link. In order to avoid such misjudged mishaps, the leaders need to do a skill assessment and skill utilization management. While assigning tasks, the leaders need to zealously encourage their teammates to be passionate about what they are good at and build new passions around their strong skills. Sure, feelings may get hurt and egos may get bruised, so reiterate how important they are to the team and their skills are detrimental to the teams overall performance.

Those are enough rules for today. I'll give you some new ones in later posts.