International Game Developers Association

Games Education
Course

Contents 1 Teachers 1.1 Instructors 2 Course Background Information 2.1 Location 2.2 Time periods 2.3 Recommended Text 3 Course Structure 3.1 Course description 3.2 Course Objectives 3.3 Student Learning Outcomes 3.4 Content 3.5 Scope of the Project 3.6 Outside of Class 3.7 Grading 3.8 Attendance 3.9 In Class 3.10 Academic Dishonesty

Teachers

Instructors

• Ian Schreiber

Course Background Information

Location

Ohio University

Time periods

• This class was taught in Winter 2006
• Class met two hours per session, twice per week, for ten weeks.

Recommended Text

Introduction to Game Development by Steve Rabin (ISBN 15845-03777). This book covers every aspect and discipline of game development in depth, with references to other sources when needed. If you have a question about some aspect of development, the answer is almost certainly in there somewhere; it’s a great resource that no game development student should be without.

Course Structure

Course description

Intensive study of special topics in the field of telecommunications.

Course Objectives

Over the course of this class and its successor (Capstone II in the Spring), students will work together as a team on a medium-sized game project. The project will be conceived, designed and implemented entirely by the students taking this course, with guidance from the instructor as needed.

Student Learning Outcomes

At the end of this course, you will have some practical game development experience working in a team on an actual game project. While this is no substitute for experience working on a commercial product at a game company, it is as close as you’re likely to get in a classroom.

This is not a course where you will learn new material. Rather, you will get practice applying all of the material that you’ve learned in all of your other courses to date… and you’ll have a cool game in your portfolio to show for it.

Content

Due to the nature of software development, this course is largely unplanned. While most classes have specific topics to cover on specific dates in lecture, there is no lecture in this class and no specific material will be covered. There will be a set of “milestones” (deadlines where certain parts of the project are due), but those will be defined during class after the nature of the project itself is defined and agreed to by the development team.

Class time will serve two primary functions:

Team Meetings
Class time is an excuse to get the entire project team together in one place. This allows everyone to know what everyone else is working on, what everyone’s status is, and whether there are any obstacles that are preventing anyone from working on their part of the project. It also allows anyone to express an idea or a concern that affects the project or the team.

If you have an issue you would like to raise but you are uncomfortable bringing it up in front of the team, contact the instructor. If you have an issue with the instructor, follow the guidelines in the Student Handbook.

Studio Time
When we aren’t meeting as a team, you should spent class time working on your part of the project. Working in an environment where everyone else is also working can help you be more productive, and will help you clear obstacles quickly if someone else on the team has something that you need.

Class days are:
Th 1/4
Tu 1/9   Th 1/11
Tu 1/16   Th 1/18
Tu 1/23   Th 1/25
Tu 1/30   Th 2/1
Tu 2/6   Th 2/8
Tu 2/13   Th 2/15
Tu 2/20   Th 2/22
Tu 2/27   Th 3/1
Tu 3/6   Th 3/8 – Week of GDC, instructor (and several students) are out of town.

We will meet one last time during the scheduled final exam period as an “interim Post-Mortem” to discuss where the project is, what has gone well and poorly, and what needs to be changed for the project to be ultimately successful by the end of Spring quarter.

Scope of the Project

With 6 to 8 students working part-time (10 to 12 hours per week) over the course of 20 weeks, we have roughly 1,500 man-hours to work with. This is larger than any game that a typical student has worked on during their own personal free time.

On the other hand, a typical AAA game might have 50 people working full-time (40+ hours per week) over the course of 3 to 5 years: somewhere in the neighborhood of 400,000 man-hours – more than 2000 times the size of this class. So, the scope of this project will be much smaller (by necessity) than God of War, or Gears of War, World of Warcraft, or any other Something of War-something.

There are two ways to approach the issue of scope, while still having a complete project by the end of spring:

• Make a complete game with a small scope. At DigiPen, students work in teams similar to this to create a complete game every semester – eight such projects over the course of a four-year degree; look at some of their student projects (available on their website, and you can also see some of the better ones as IGF finalists) to get an idea of what can be done in that time.
• Make a complete game demo of a more complicated game. The demo should include one playable level (or equivalent) that showcases all of the major mechanics, art and sound styles that would be found in the (theoretical) final game.

Both game and game demo have advantages and disadvantages relative to one another, to be discussed in class. The development team will decide on the ultimate direction, along with everything else about the game (genre, theme, style, etc.).

There will be some kind of final deliverable at the end of Winter quarter, as a midway point towards completion of the final project in Spring. The nature and scope of this deliverable will be negotiated during the Winter quarter.

Outside of Class

You are expected to work on your part of the project outside of class. Ideally, you will be so excited about the project that you will put all of your waking hours into the project. Realistically, you should spend a minimum of 6 to 8 hours per week on the project outside of class. (And this is 6 to 8 hours of productive time, mind you; if your idea of “working” involves checking email, then sending an IM, then checking your email again, then spending five minutes on the project, then seeing what’s on TV, then checking email, then posting on your blog… then double or triple the amount of time outside of class since you’re not actually working on it.)

It is understood and even expected that there will be occasional times where outside life will interfere with classwork, and you will make no progress on the project between two class periods. This happens at game companies, too.

It is not okay, however, to have long stretches of unproductive time. It is not okay for you to procrastinate in the hopes of “making up the work later in the quarter”… especially if someone else is relying on your work in order to do theirs, as you can then put the entire team behind schedule.

Grading

In the game industry, you are “graded” on the sales of the final product. If the game doesn’t sell, then it doesn’t matter how many hours you worked or how skilled you are; if the studio closes, you will get laid off along with everyone else on the team. If the project does well, you are “graded” on the quality and quantity of your work, and your ability to work with the rest of the team (which includes communication skills, adaptability, and being a catalyst or facilitator, not just getting along with others).

The quality and quantity of your work is judged differently depending on your job role. The questions often answered during a performance review include:

Programming

• How much functionality did you add to the game? This goes beyond “lines of code”; a master programmer can often do more in fewer lines.
• Does your code work? How many bugs are there? Sometimes this is measured by the known bug count, maintained by QA.
• How modular is your code? Is it easy to change or restructure? Games often go through major gameplay changes during development; writing code that can easily be adapted or changed makes for a better game.
• How easy is your code to read? At some point in the future, another programmer will probably have to change or maintain your code (or, you will have to go back to it months after you’ve forgotten it all). If it’s easy to tell what’s going on because your code is self-evident, this will make everyone’s life easier in the long run.

Game Design

• Is the game fun? This is really the acid test for any game. If anyone can sit down, play it and have a good time, then we say it’s a good game and the designers get credit. If it’s a dull experience, then all the expert programmers and master artists in the world will not help, and the designers will get the blame.
• Is the game easy to implement? Often there will be two very similar designs for a game, but one can be written by a programmer in five minutes and the other will have them pulling their hair out for weeks. Being able to work with programmers and artists to adapt your designs can free up more time for other tasks, which means more time to add bonus features (or more polish).
• Is the game balanced? If it is too easy, then players will find it boring. If it’s too hard, players find it frustrating. You will be expected to play the game yourself, but you will soon become so much of an expert at it that you will be a poor judge of a new player’s experience; thus, you will also need to watch others playtest your game and make observations based on their reactions.

Art

• Does the game look nice? Consider the irreverent overly-polygonized style of Katamari Damacy, the mostly-2D Japanese-watercolor style of Okami, the minimalist colors and shapes of Tetris. Your art does not need to be photorealistic, but it should have a strong, consistent, original and appealing style.
• Is the art consistent with the gameplay and the storyline? If all of the game’s characters are drawn in a goofy, superdeformed-anime style but the storyline is along the lines of a gritty detective novel, it won’t feel right. If the characters are always smiling, even when they just lost a loved one, players will notice (and not in a good way).
• Can you solicit and respond to feedback? Most game players (and game reviewers / journalists) are not professional artists, but they will be judging your art and it is they who you must please. Just as a designer must observe reactions to the game, you must observe reactions to the game’s art, and modify individual pieces (or your entire style) accordingly.

Game Audio

• Does the game sound good? Is the background music done in a consistent style, and is that style consistent with the art, gameplay and storyline?
• Do the sound effects sound like they’re supposed to? Can you tell what they are in the context of the game, or are they confusing?
• For looping background music and sound effects alike, do they retain their appeal after hours of play? Some sounds never seem to get old (Mario’s jump and coin-collection effects are two examples), while others somehow become grating after hearing them for the hundredth time. Telling the difference requires listening to your sounds lots of times, and also having other people do so and watching their reactions. This also means it’s important for you to get your sounds in the game as early as possible, to give you lots of time to tell the good from the bad… which means convincing programmers that your sounds are a priority, when everyone else is telling them the opposite.

Production

• Did the game ship on time? In the game industry, if the project slips past its deadline, the development team must renegotiate terms with the publisher; possible results range from getting an extension (with or without extra pay) to having the entire project canceled. In this class, the final exam date in Spring quarter is the final deadline, and “slip” is not an option.
• Did the game ship on budget? Admittedly, the operating budget for this class is zero. If it’s discovered that the team needs additional software, tools or other resources from Ohio University, it is far better to find this out as early as possible in the development cycle so that arrangements can be made. If we find we suddenly need a new tool a week before the final deadline, that’s Bad.
• Were all of the promised features delivered? The trick here is to keep your promises low and your deliverables high, rather than the other way around. You will need to make promises, but it is up to you to work with the team to make sure that they will be able to build what they say the can in the specified amount of time.
• Was the team efficiently using their time? If one person was waiting a long time because they required someone else’s work to be done first, and there was nothing else to do in the meantime, that’s a result of bad scheduling. If someone is ineffective because some obstacle is preventing them from getting work done (including laziness), it is the producer who must identify and remove that obstacle. If two people on the team are having a disagreement, it often falls to the producer to act as a mediator.

Game development is extremely interdisciplinary in nature. Everyone is depending on everyone else, especially in a small team such as this. Developers who can apply their skills in several areas should feel free to do so if they have time available, as long as they also complete their own assigned tasks. This is reflected in the grading, as everyone’s grade is at least partly dependent on everyone else’s:

Discipline:	Programming	Design	Art	Audio	Production
Does it work?	40%	15%	5%	10%	15%
Is it fun?	5%	40%	10%	5%	10%
Does it look good?	10%	5%	40%	10%	10%
Does it sound good?	10%	5%	10%	40%	5%
Was it on time/budget?	15%	15%	15%	15%	40%
Attendance / Participation	20%	20%	20%	20%	20%

A full 40% of your grade comes from the rest of your team, in proportion to how much you would typically be interacting with them on a professional project and how much influence you have over areas outside of your discipline. Some disciplines get the short end of the stick on this more than others; such is the nature of game development.

Attendance

Class attendance is mandatory.

This class is practical in nature. Your teammates will be relying on you to contribute. If you absolutely must miss class, contact the instructor (and your team) in advance as soon as you know. Make arrangements to pass on any knowledge (or hand off any work you’ve done) that others may need. Advance notice of excused absences will prevent a drop in your Attendance grade.

In Class

If you have a cell phone or similar device, please turn it off before class. Receiving a call or text message in the middle of class will distract others who may be concentrating intently.

If you have a laptop, feel free to bring it to class and use it. We should have access to development computers, but you will probably be more comfortable working on your own laptop (plus it’s easier to take your work with you). However, please mute the volume so that it is not disruptive to those who may be working intently (use headphones if your work involves listening to sound), and avoid using precious class time to just surf the Web for fun.

Academic Dishonesty

The Ohio University Student Code of Conduct prohibits all forms of academic dishonesty (cheating, plagiarism, forgery, etc.). Of course, this class involves purely creative work of a type that you would be unable to copy anyway, so cheating will be effectively impossible. If you try to cheat anyway, you’ll receive a zero in the class.