It was a shame actually, because it was an awesome talk. I might have to harass him to put his slides on Slideshare.

Let’s face it, almost anyone starting out with coding, wants to be a games programmer, not a tool-smith. Just like nobody becomes a blacksmith because they like the idea of making gutter brackets. That’s a joy that comes later, when people reach the stage you have, and take joy in the craft itself.

Like many starting games programmers, I was scared off from programming graphics and UIs for a very long time exactly because all the pedagogical resources treated it as something hard, to be dealt with only in advanced courses, at the end of the book, and so on.

It’s not. Graphics coding is almost trivial, and students need to know that. It needs to be part of the first thing they write: “hello world” should be in graphics, not text!

But most courses teach text programming. Which means, you can do a whole lot of stuff with text by the time you’re done, but you are not one step closer to making a PacMan clone than you were when you started your course!

If someone is asking “What do I do next?” then that means they have completed the whole course without feeling that they have the skills to accomplish the task they wanted to accomplish when they started the course. That’s a TRAGEDY!

Text I/O is an entirely different paradigm from graphics: it needs no fast sync loop, blocking calls are OK, and there’s no realtime input. For *games programming*, those concepts need to be there from day one.

Text I/O is also a different paradigm from windowing: there are no event listeners, no exception handlers, there’s no need for understanding a display hierarchy, or how events bubble through them. For *UI programming*, those concepts need to be there from day one.

Even “hello world” contains a game loop, though people porting it to other languages forget the importance of “20 GOTO 10″.

Imagine if kids were given the following hello world script:
10 REM Animate a HelloWorld object.
20 LOAD OBJECT “HelloWorld.x”, 1
30 LOOP OBJECT 1
40 DO
50 SYNC
60 LOOP

Bingo. Trivial. And so very, very empowering compared to having the text output on the console. A few more lines inside that sync loop, and you’ve got yourself a “shoot the HelloWorld” game.

Someone who has even that minimal level of knowledge will not be asking “what do I do next?” – they will be asking “how do I make the wasd keys work? OK, now how do I make it so that the player auto-crouches as they move below the helloWorld? How do I shoot? How do I detect a bullet hit? How do I add another monster object? How do I add more monsters? I need to store them in a what? Another loop? An array? Oh, that’s easier!”

Algorithms are great. They are fantastic, time-saving tools. But I think it does students a disservice to make them the core of what they do, as if a fast sort algorithm is meaningful because you want to shave a few microseconds off the accountant’s progress bar while he sips his latte, and not because you need your AI to prioritize its targets in a single frame so it doesn’t get it’s butt shot off.

You can’t learn about quaternions by reading: you learn by writing a flight sim with pitch, roll and yaw, and suddenly understanding that Euler angles are not good enough, because they’re subject to gimbal lock which sends your plane crashing into the ground when you try to bank.

As a programmer, you will never need to write a sort(), fast fourier transform(), hash(), compression algorithms, encryption algorithms, or any of that, unless you are writing a library. Other people have done the heavy lifting there for you and put them into the standard libraries of most languages, so that you can focus on making code that accomplishes the task you want to accomplish: make that guy fall over when you shoot him.