Game Creation

Ever since my tiny bout with LittleCoder, I've been thinking very hard about getting more into game creation. It doesn't hurt that Javier seems to be going in the same direction with PDPANIC, and I've been slipping back into WarCraft III and Pokemon Ruby.

Wanting to be able to make games used to be one of my biggest motivations to become a better programmer. A lot of my earliest projects in QBASIC revolved around just that. But graphics programming was too hard, and though I read endlessly on the topic, it didn't sink in. As a matter of fact, I've gone through the book Game Coding Complete, Second Edition at least four times at various speeds, with various languages, graphics libraries, and projects. Each time, I felt like I was extremely close to understanding and being able to produce the code myself (though some of that was due to an unfortunately misplaced sentence in chapter 6). I could just never produce.

That's where LittleCoder came in. It took the chapters upon chapters of Game Coding Complete about the event pump, view separation, resource management—and hid them away in the background. The only hooks you get are calls to four functions: keyboard, update, left_mouse_down, and left_mouse_up.

So when I started porting my LittleCoder Tetris clone to the D programming language (courtesy the SDL graphics library, courtesy the Derelict bindings), the first thing I did was find a sample project—every starter SDL project is basically the same—and create two files.

main.d
main.d was the sample project with the functions you would expect: functions like main and init and render. The main event loop lived here. I hate looking at this file.
game.d
game.d became the equivalent of main.rb. It had our friends update and keyboard, but also init, which I also added to the LC version for clarity, and render, because blitting sprites to the screen isn't handled for me with this library.

It was an enlightening experience, laying the code out like that. I must have started from that same SDL sample several times before now, but this time things started clicking. With all my SDL_Inits and SDL_MUSTLOCKs hidden safely away, I was back in the zone.

I started by drawing a PNG graphic to act as the background for the game grid. But I realized that it was tied a little too closely to nearly every entry point of my file, so I decided to abstract it to its own class: BasicSprite. I decided that BasicSprite would be for LittleCoder-style sprites: static images that you always want displayed at certain (changeable) coordinates. Sweet. I had the game board and a sample L-shaped piece on the screen in no time.

'Course, pieces aren't BasicSprites. They have meaning to the game; their on-screen coordinates are relevant to their display, but to the game, all that matters is where they are on the grid. This mini realization led to creating the Piece, GameGridSprite, and PieceSprite classes. They were mostly stubs, but had enough of an interface so that the PieceSprite could tell where it should be on screen based on its associated Piece's position, and the position of the GameGridSprite, which became a sub-class of BasicSprite.

And then I thought, "Whoa. This is familiar." And it was. The classes I was creating mirrored rather closely the sprite-related classes in the book. So I stepped back and looked at my code and thought: "You know, if I wrapped this file in a pair of braces and factored these functions into separate classes, I'd have a GameView. And that pleased me.

Let's see how it goes from here. I have a strong feeling that I've finally gotten my head around that freakin' book. And already I've learned a great lesson:

Break things down so that you can work in tiny iterations.

Related Articles

Posted May 26, 2007, in the late, late night.

Comments

Click here to view the comments on this post.