Jeff On Games

My good friend and educator Bill Crosbie is asking some tough questions on Twitter, specifically about what to teach fledgling game programmers to make them the most marketable to game companies when they graduate. Now, you might not be able to tell from the Twitter conversations, but Bill is actually very concerned about giving his students a good, foundations based, computer science education, while also giving them the opportunity to make games, and giving them skills that they can immediately transfer into the workplace, all in less than the two years he happens to have them. And what he's asking are actually really hard questions, and got me thinking: What would I want out of programmers coming out of two year and four year programs, both those that are focused on game development, and those that aren't? What can I tell Bill to do to make sure that I would at least consider hiring his better students?

The Never Ending Conflict

This comes down to a never ending conflict that educators are well aware of: the conflict between giving a student marketable skills, teaching them the tools and technologies that are relevant "right now" that they can put on a resume and will immediately generate hits on job search websites, and giving them an actual solid education in computer science and software engineering. Ask most programmers in the game industry (at least the ones I know) and they will tell you the later is more important, but look at who actually gets hired and the former plays a very obvious role. The problem is that when I'm hiring a programmer, I want someone who's smart and gets things done, but I also don't want to take the time to teach them all of the skills that they're going to use on a daily basis. It's a tough balance, and getting programmers that don't understand things about your core technologies, or at least their underlying principles, can be dangerous.

In addition, technologies go out of date so fast that teaching one specifically can be counterproductive. C++ has been the de facto standard in the game industry almost since inception, as we've needed the control and power that C++ provides, but the technology that we're working with under the hood can dictate exactly how we can use C++. Students taught to think about single threads of execution on x86 processors, using primitives that would be perfectly fine in other industries (like stl vectors and strings) would be screwed in today's game industry, an industry which is (now) all about squeezing as much performance as possible out of multiprocessor, multicore systems on x86, x64, PPC and Cell chipsets. And interestingly, this is exactly what's happened. Students taught to think ONLY in an object oriented paradigm have trouble parallelizing their code and thinking in terms of small executable chunks that don't suffer from things like race conditions and cache misses, if they even know what those are.

But what's academia to do? Most game developers won't even look at a programmer unless they have C++ experience, understand OO concepts, have done at least some work in DirectX, OpenGL, or Win32 programming, and has as a significant portfolio of work. This leaves professors looking to help game industry hopefuls little time to discuss things that are essential to computer scientists, like the benefits and pitfalls of functional languages, strong and weak typing, lazy evaluation, early and late binding, combinatorics, state machines and automata theory, synchronization patterns (semaphores versus critical sections), common concurrency issues and how to avoid them, and even compiler and virtual machine theory. Even if they get through all that theory, how many schools will be able to talk about the inner workings of modern chipsets, cache coherency, synchronization primitives, compiler intrinsics, and virtual memory? If you're a recent college graduate that can actually give me a definition on all of those terms, explain how they're relevant to modern computer software and game programming, and has a fundamental understanding of any modern game API, you're way better than I was when I graduated, and maybe better than I am now because I'm not sure even I could do it. And I can't tell you how much of it is important to know when you graduate, and how much you can learn either on the job, or on your own. Even the IGDA curriculum framework lists so much stuff that it would be almost impossible to push through in a 2 or even 4 year program. You have to pick and choose.

So if I can't figure it out, what's an educator supposed to do? Take a best guess I suppose. Fundamentally, though, I think they need to teach what colleges and universities have said they're teaching for years.

Teaching How To Think, How To Learn, and How To Work With The Tools

Most liberal arts colleges and universities still say they teach their students how to think. They're not necessarily teaching skills, and I like that. That's what I want from my programmers: I want them to know how to think, and, more importantly, how to learn. But there's nothing that says that this must all be done with theory, or that it should be done purely with theory. In my mind, the problem is that Computer Science and Computer Game Programming programs come out of science and math programs, and follow their pattern for how to structure classes: either 3 credit classes with focused homework assignments with little to no cross class application, or 4 credit labs where a single lab is considered enough to create a program that demonstrates theory. This is not only not enough time, but it doesn't encourage long examinations of hard topics, it doesn't encourage learning by failure, and it doesn't encourage learning why it all works the way it does.

How many schools actually look to the art world for inspiration? In most art schools, you have 3 credit studio classes, which last actually 6 to 10 hours per week, have only 2 to 3 projects per semester, and are combined with classes on fundamentals that can help improve project work. I don't think I ever had a class structured this way during my computer science education. The closest I ever got was a Software Engineering class, which wasn't really about software engineering as much as software planning, which is completely different. But, for programmers, these project classes should not necessarily be introducing new technology. At least at the start, students should work from the base competencies of whatever the school was teaching the previous semester, and early project classes should expect failure (though not say this out right), and encourage students to spend several days at the end of projects to examine their work for flaws in their design and flaws in their process, not flaws in the final product. This is where we teach students how to learn, and how to find the problems in their own work: by screwing it up royally.

In addition, I feel that early theory classes should be kept separate from those that are teaching applications of programming, especially those that are focused on programming in specific languages. However, the two classes should be linked together and move in conjunction. Each class on algorithms and data structures should be paired with the class that teaches its specific application to the language they're working in, thereby teaching both programming and theory. This I think is the major failing of most CS programs. They teach programming, usually in a specific language, and expect the students to pick up theory on the way. In the worse cases, the students return later to have classes specifically on theory, which is sometimes a repeat of what they already learned, just presented as theory instead of a feature of the specific language. By making that clear separation of learning theory and learning practice in two separate but joined classes, your students should progress faster in both. It also creates a flow in teaching and a reason to move to languages as you progress. When theory classes are ready to introduce things like how memory works, caches, cache coherency, pointers, and the like, that's when you can move your classes on programming into teaching C++. As you learn concepts in functional languages, you can start teaching ML in programming classes. As they learn the theory, they can see how it was applied in the language they're learning.

Finally, by the end of any given program, students should be spending a majority of time in studio classes, working on projects that utilize everything they've learned with frequent review of architecture and progress from their professor. However, this should be supplemented with theory classes that go beyond what they'll need to use on simple projects, like topics in programming languages, lexer / parsers, and the ability to prove algorithms correct, and include seminars in currently relevant technology and concepts (guest speaker series are great for this).

Doesn't Answer The Question

Interestingly, I'm not sure if this actually answer's Bill's questions, but it gets a lot of thoughts off of my head. I actually had an entire set of semester plans that went with this post, but scrapped it when I realized I have absolutely no experience in that regard. I can tell you what I want, which is basically separate theory and practice classes joined at the hip in early stages, followed by advanced topics in CS and software engineering paired with Studio classes. But, for me to tell you exactly how those classes should be structured doesn't make any sense.

So hopefully, without answering the question, I've been at least a little helpful.