Teach Yourself Game Programming in 21 Days - Day 7

There's been something quite obvious missing from our game programming so far. Every time we've handled input, we've been using C's kbhit() and getch() functions. If you've messed around with the demos, you'll have noticed that they suck. That is, holding down a key will result in keypresses based on your OS settings, so input will merrily be processed for some time after you release the key. Also, getch() is quite difficult to use with things like the arrow keys. The reason for that is simple: keyboards are weird.

Every time you hit a key, it sends what's called a scan code to the PC. This is one or more bytes. Another, similar code is sent when you release the key. The keyboard driver's job is to transform these random-looking series of bytes into something that software can sensibly use. Of course, we're programming for DOS, so... you have to write the keyboard driver. I previously did this when I was messing about with OS programming. Typing all those scan codes in was so fun, and I got to do it again!

However, there's more to video games than keyboards. At the time, joysticks ruled the gaming world thanks to their use with Atari and Commodore machines, so naturally some people decided to release them for PCs, too. Coding for them isn't as tedious as for the keyboard, but there is an additional stickler in that every joystick's range of movement is somewhat different. This lead to the universal 'joystick calibration' screen in DOS games where you would be required to waggle it around so it knows what extents to scale your joystick input by. André dutifully gives code for this, presented to you in the joytst demo.

The last input device that the author considers is the mouse; an extremely important tool for strategy games which happily has the easiest driver code of all. mousetst presents what is possibly the simplest paint program of all time. As with many of the demos, it's ripe for improvement. The most galling thing is that it paints one 2×2 block of pixels at a time, but doesn't update fast enough to smoothly draw lines.

This ends the first week of the course. It has covered sprite graphics, vector graphics, loading images from disk, screen transitions, tile-based game worlds, scrolling and input devices. That's enough for a very low-tech game, but we're clearly missing things like sound, AI, physics and special effects; perhaps even multiplayer or networking. There are also more nebulous topics like good game design and playtesting. Still lots to go, and I'm not sure two more weeks are enough to cover it.