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.

Our previous projects in CS529 had NOT been component based and, thus, were painful to modify. However, the final project must be component based and we are required to add "extra" features. If we do the minimum, we get a 70% on the project and, seeing as the project is 40% of our grade, probably not much higher than a C in the class. This is exactly how I feel assignments should be formatted -- all the time. What does an A even mean anymore if mostly all I've been getting in my educational career is As and Bs? Usually what it means is the following: I got away with putting forth a minimal amount of effort while still fulfilling all of the assignment's requirements (or at least enough to get an A or a reasonably high B, depending on my current level of motivation). And now, for this project and hopefully the more difficult classes that await as well, it means I tried to achieve perfection, to go above and beyond.

I still have far too much free time, but that will undoubtedly change starting next semester when we have our first Game Project class. Together with 2-4 other programmers, I will be working on developing a real, honest-to-goodness game. The great thing is, I've already found a team and we've begun having meetings to discuss what kind of game we'd like to do and who will be responsible for what. We are all programmers, so we will be doing a significant amount of coding, but on top of that, we also have to fill, between the four of us, three other positions. They are:
  • Producer - organizes team meetings, tracks overall progress, plans and prioritizes tasks, tracks bugs
  • Technical Director - in charge of technical oversight of the project, designs core architecture for the game engine, writes the technical design document, manages source control
  • Game Designer - oversees overall design of the game itself, both gameplay mechanics and level design, ensuring that it is fun and easy to play; writes the game design document; creates focus groups for playtesting and reacts to user feedback
Each of these jobs is non-trivial. For better or for worse, I've chosen to take up the coat of arms of the game designer, and I'm attempting to come up with a number of possible game ideas before our next team meeting. 

And for those of you who keep asking, no, I don't have anything concrete to show you right now, but you can be sure I'll make a post here the moment I do! At the very latest, I will have something to display by the end of the semester.


Sincerely as ever,
--Jeremy Kings

No comments:

Post a Comment