Friday, November 12, 2010

Grad School: Are We There Yet?

Short answer -- very nearly, yes.

The long answer: For the past couple of months, assignments in the class that I was most excited to take, CS529: Introduction to Game Development (this is what I'm at DigiPen for, right?), have been overly simplified "fill-in-the-blanks" affairs. Even for our most recent project, which involved developing a platformer (e.g. Mario, Sonic, and the like), wasn't sufficient to motivate me. Most of the functionality was already there and the biggest challenge was simply figuring out how best to avoid having the player fall into the floor. Granted, I could have taken the project much farther than I did, but the difficulty (or lack thereof) of the project combined with the fact that we had two weeks to finish it, which was far more than we needed, just wasn't doing it for me. Up until a week or so ago, I was still questioning whether it was even worth having come here.

However, there is light at the end of the tunnel. Recently, Chris Peters, the game programming guru of game programming gurus at DigiPen, took over the class. Having already been treated to his genius through sitting in on his lectures for the undergraduate game project classes, I was more than pleased with this development. Even better, though, was the assignment of our final project. We've been tasked with developing a simple game engine with a component-based design (more on that in a bit) completely from scratch... Okay, that's not completely true -- we have access to a sample game engine that would score roughly average on the project rubric. Still, I'm taking pains to make sure that I don't reuse any code without understanding exactly what it does and why it's necessary. Sure, this means I won't get the project done quite as fast as if I just copy-pasted, but what would I be getting out of it? I'd learn a little bit about it through trying to extend its functionality, but to really understand it, you have to take it apart and see what makes it tick. I should note that this is a solo effort, like our previous projects.

WARNING: Technical mumbo jumbo below. If it seems like I'm talking in Greek, skip ahead.
A big flaw with inheritance-based software design is that, when overused or used improperly (these are essentially one and the same), it creates tight coupling (i.e. interdependency) between the different parts of the program. This has a high potential of creating major problems when you need to extend or modify the functionality of the program. Changes to one part of the program cause a cascade of possibly unintended and/or unwanted changes in the rest of it. This results in a lot of headaches and extra work for everyone who worked on the new or modified feature and any other things that happened to be affected by its implementation.

The simplest solution to this is to prefer aggregation and composition ("has-a" relationships, i.e. "the game object has a physics component") over inheritance ("is-a" relationships, e.g. "the game object is a physical object"). By coding each major part or system of a project, such as a game engine, as if no other systems exist, and constructing objects so that they have components that utilize individual systems, we can vastly reduce the amount of interdependency. The resulting program is much easier to extend and modify, given that changes to one system do not directly affect the other systems.