Introduction

Over the last five years, I have worked as a faculty member in Cal Poly Pomona’s Computer Science (CS) department. Having formerly worked as a game programmer for Kronos Digital Entertainment, I frequently assign programming projects with a slant towards solving game development problems. Our students especially appreciate the opportunity to program applications that interest them. About a year ago, students finally persuaded me to offer a one-term game development course.

I created a 10-week course that would allow senior-level CS students the opportunity to conceive, design, and implement a 3D PC game. This course, Intro to Game Development, was offered for the first time in Spring 2006. Each game was required to have three different levels, each with increasing difficulty. I selected OpenGL for the graphics pipeline, GLUT for event handling and models, OpenAL for sound effects, Microsoft’s MCI API to play back CD audio tracks, and Lua to script game-state information. C and C++ were used to implement the game engine and to put it all together.

Although offered as a senior-level course, students had differing strengths. Some had taken the 2D/3D computer graphics course (where we teach OpenGL), some had taken the AI course, some had taken the operating systems course, and so on. Consequently, students selected their teammates not simply based upon who they knew, but also based on their perception of student skill bases. The prerequisite I required for all students was completion of the C++ programming course we offer.

Student Storyboard for Level 1

Milestones

To help ensure that students would be successful in the ten-week period of time, I created a milestone chart that included deliverables due at the end of each of the ten weeks. I typically lectured once per week presenting theory and examples while students utilized the rest of their time to work within their groups. For the final (week 11), each team presented their game and performed a critical stage analysis.

Development

Students assembled themselves into 14 four-person teams (two teams had five students) and assigned themselves a studio name. Each team developed a story for their game and three storyboards, one for each level of their game. Students were given the latitude to implement their storyboards in any format they wanted—Flash, a paint program, by hand—some did a mix of all of these.

The software architecture of each game was accomplished via a software modeling language frequently used in software engineering called Unified Modeling Language (UML). There are 13 different types of UML diagrams that can be constructed. Due to time constraints, I had each team construct one UML class diagram. This diagram served as the foundation for each team’s software architecture.

Student UML Class Diagram

At this point, each team began work assembling the software modules that would eventually become their game. The milestone chart helped direct the order of construction of the modules as deliverables were due each week. For example, after the UML class diagram was due, the next week the memory manager needed to be completed, and so on. It took about four weeks before most teams could begin to see what their own unique virtual worlds looked like.

Simultaneously, students worked on the visual and aural elements of their games. Although I encouraged students to construct very simple models (and to not try to duplicate their favorite game characters), some took the opportunity to learn about Maya, Milkshape 3D, 3D Studio Max, Blender, and so on, and tried to build and import models from these software packages into their games. Many groups recorded their own sound effects, while a couple of groups recorded their own sound tracks.

The game state was set via Lua scripts. Collision detection and handling was eventually implemented as was Non-Player Character (NPC) AI and physics. I required that all parameters for these items be set via Lua scripts.

The final deliverable was an Auto-Run CD that students placed in a computer in our Software Engineering Laboratory. This CD started up in kiosk-mode demonstrating all screens, levels, models, sound effects, and songs for the game. Once interrupted, the game exited kiosk-mode and the main game screen came up for the player to make a selection.

While each team’s game was demonstrated in kiosk-mode, each team member described their experience and contribution. The last task was for each team to present a critical stage analysis (something that would normally occur at each stage of the game’s development). In this case, I had each team present five items that went right, five things that went wrong, and five things they would change if they were to continue their development. Students’ comments serve as a basis for the remainder of this postmortem.