My University Game Development Class

Background

Tim Cain taught this class at the University of California, Irvine in spring 1999, shortly after shipping Fallout and while working on Arcanum at Troika Games. The course was ICS 180G, a project class for third and fourth-year students, co-taught with professor Dan Frost. Frost taught Tuesdays, Cain taught Thursdays. The class had roughly 60–80 students.

Critically, the course was open to non-CS students — which turned out to be invaluable because artists, musicians, and writers were in high demand when students formed teams.

Week-by-Week Breakdown

Week 1: How the Industry Works

Cain introduced himself and lectured on the structure of the game industry:

• Publishers vs. developers — internal vs. external development, subcontractors
• Game genres and their sales patterns — RPGs have long sales tails (selling for years), while flight sims do 90% of sales in the first six months
• The "mythical 18-month development cycle" — Cain laughed at this even then, noting cycles were already stretching to 3, 5, even 8 years
• Milestones: what alpha, beta, and going gold mean
• Business models: how to get a contract, start a company, self-publish. He showed how many units you'd need to sell to make a million dollars via direct sales vs. self-publishing vs. going through a publisher — "people were quite shocked" at the difference
• Retail realities: getting shelf space, end caps, poster placement, box sizes

Week 2: Teams

• How teams are assigned in the industry (usually top-down, but not always)
• How he attracted people to work on Fallout
• Matching assignments to team members: interest first, ability second — controversial among producers at the time, but Cain stood by it
• Keeping motivation up on long projects
• Handling problem team members
• The difficulty of being a manager, programmer, and designer simultaneously
• The importance of meetings — "To this day people deny that meetings are important, and to this day I repeatedly tell them how wrong they are." Too many meetings is bad, but "someone who says meetings are dumb and we should never have them — that's not a person I want to work with"

Week 3: Design Documents

• Separating engine specifications from game specifications (publishers often want this split)
• Writing the background story so the team understands the world
• Design specs for story, locations, levels, missions, quests, NPCs, and player-created characters
• Artwork: game art vs. UI art — often wildly different styles, done by different artists
• Making and maintaining schedules
• Estimating costs — Cain admitted he wasn't good at this, warned students they wouldn't be either, and told them to stay flexible: "Be ready to drop features. Be ready to do extra work to get something in if you really want it."

Week 4: Technical Programming

The most technical lecture, aimed at the programmers:

• Algorithm selection — "best" isn't always possible due to memory, time, or the lack of a known good algorithm
• Texture mapping in open 3D worlds, multiple texture maps for level-of-detail at distance
• Pathfinding in large worlds (having done it for Fallout and currently writing it for Arcanum)
• Sprite management — 2D vs. 3D sprites, finding the hot spot (root point) for animation and collision detection. "This predates having an engine that did this for you"
• Asset caching — 99% of the time, available memory was far less than what the game needed
• Memory management — malloc, realloc, free, exit vs. cleanup, null returns vs. failures
• Inventory systems — as a programmer problem, a UI problem, and a player expectation problem. "Bin packing is NP-complete, so keep that in mind when you make an algorithm to compress someone's inventory" (which they did in Arcanum)
• C vs. C++ — Cain was using C for Arcanum but leaning toward C++, which Troika adopted fully by Vampire (2001). He didn't learn C# until 2005.

Week 5: Student Pitches

Instead of lecturing, Cain had teams pitch their projects as if he were a publisher. He gave two types of feedback:

1. What a publisher would likely say
2. His personal recommendation

Common advice: reduce scope, clarify unclear mechanics, and plan the demo carefully — they needed a playable demo by the end of the course.

Week 6: Artists and Programmers

• Artists and programmers tend to think differently ("one side of the brain vs. the other")
• Designers sit somewhere in the middle
• Jason Anderson (Troika co-founder) was the best person Cain had met at bridging the artist-programmer gap — hence his title "technical artist" on Fallout
• How ideas flow between groups
• When final decisions should fall to the lead programmer, lead artist, or project lead
• Technical skills artists should have
• A list of things artists hate about working with programmers — "Programmers, listen to me, because most of the artists in this room probably think this about you"

Week 7: Interface Design

• Interface is one of the biggest time sinks in game development
• Cain personally dislikes coding interfaces but recognizes their critical importance
• Too little interface can be non-intuitive; too much overwhelms. "Less is more" is usually the right direction
• Keyboard vs. mouse vs. controller mapping — some actions work better with one input method, and making the same interface work well for both is hard
• Think about multiplayer early — not just lobbies, but in-game UI: distinguishing players from NPCs, party management, group interfaces. "If people learn how to play single player, they don't want the multiplayer version to be dramatically different in terms of interface"

Week 8: Industry Jobs and How to Get Hired

Cain mapped out every role in game development:

• Programmers: scripter, junior, senior, lead
• Producers: assistant, associate, senior
• Directors: division, technical, art, QA, music
• Artists: junior, senior, lead
• QA: junior, staff, lead
• Musicians: sound effects, music (MIDI vs. digital)
• Non-development roles: marketing, sales, PR, production, admin — "these are the people that make all those players be able to play your game"

His job-hunting advice, even in 1999: make a demo. "Now that there's game engines out, I pretty much say make a demo."

Week 9: Project Presentations

Students presented their demos a week early so there was time to fix critical issues before final grading.

Week 10: Creating Games for the World Market

The final lecture covered internationalization:

• Content restrictions by country: violence, blood, bone, whether you can kill children — regulations varied wildly
• Translation challenges:
  • Never embed text in code; always use string tables
  • Text length — fitting translated strings on screen ties back to UI design
  • Procedural string generation — inserting character names, gendered references
  • Gendered words in other languages (not just for player characters)
  • Character encoding: extended ASCII vs. multi-byte Unicode, especially for Asian languages ("people tended to just use ASCII, which was 8-bit, and then they would have a lot of pain")

Cain framed this as: "These are things you don't need to know for this class, but once you get a job, you're going to be thinking about what you have to do because your game is going to go out to the entire world."

References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=RY_tqjx_iFc