Getting Started

I am archiving older pieces I have written on other sites, making this the definitive home for all my work. This is one of several I am porting over from my GameDev.Net user journal. Enjoy!

Anyone who's been around GameDev, or, indeed, any online game development or programming resource for any significant length of time is familiar with the frequency of beginners asking, where do I start? They sometimes have grand ambitions (insert MMO joke), and sometimes they have a better understanding of how accretive skills acquisition is, but they all want to get started and progress as quickly as possible. Here on GameDev, it is universally agreed that our Start Here page is woefully out of date, so much so that there are projects to overhaul it (again!)

Here's the thing: I wonder if the fundamental method employed by that resource and similar articles/tutorials across the internet isn't wholly inadequate. We start by asking them to make decisions - by trying to guide them in making selections such as what language to choose, etc - as if those things matter. They Don't (My Opinion(TM), which I will be dispensing liberally without caveat or condition since this is, after all, my journal [smile]). There is a growing acceptance within the community that which language you start with doesn't really matter, so long as you stick with it enough to learn the basic concepts of programming. Concurrently, there is a rough consensus that tools that help the beginner make a game quicklyare more valuable and preferable because they stave of frustration. So a good foundational programmer's resource is one that familiarizes the student with core concepts more quickly and thoroughly.

Another common question is what engine to use, to which jpetrie's essay Write games, not engines is quickly becoming a handy and comprehensive corrective, in much the same way that questions about how to use multiple C++ files invariably elicit a post of Kylotan's Organizing Code Files in C and C++. We've seen hobbyist after hobbyist slave away for months and years to create an engine, and then not be able to use that engine to create any games. So a good foundational programmer's resource focuses on making games, not bits of technology in isolation.

Software engineering formalisms are beginning to percolate widely through the game industry and indie/amateur/hobbyist community. More individuals are using revision control to manage their source and assets. More developers are writing unit tests, and some are even employing test-driven methodologies to validate their design and code as it is written. I'm not a fan of buzzwords, and I hate secular religions/cultisms, so I'll stay out of any debate involving any idea that was articulated in a manifesto. Nevertheless, I think introducing these formal tools and practices earlier rather than later is a huge boon - I've argued that proper use of the debugger (and preferably of a modern, capable, graphical debugger) should be a university computer science prerequisite. In any case, our third maxim is that a good foundational programmer's resource teaches good use of tools and good development habits from the onset.

I'm working on an experiment. I'm writing a new foundational resource for game programmers, and I'm trying to embody all of the above guidelines. I'm writing a complete game, a non-trivial game, and providing the complete sources. I'm starting with a simplistic prototype, building it up gradually, and refactoring to improve code quality and add features. I'm placing all the code into source control, and I'll make the repository publicly available when the resource is published.

I can't do everything in one resource, so I'm actually planning to write multiple - at least three. The first covers the construction of a Tennis game by prototyping as Pong and refactoring into the final product. The second will work from a formal design document to create a multi-directional shooter, while the third may be a small RTS. I haven't decided yet. My hope is that the resources will be useful not just to absolute beginners, but also to people with some programming knowledge but questions about how to actually go about making a game.

I'm writing it in Python. Not because Python is "better," but because anybody can read Python syntax. It also lets me focus more on the programming concepts rather than language constraints and/or workarounds. Also, the basic Python toolchain required is simple and universal (and free).

I've already started. The Pong game is almost feature complete; I just need to add player-directed serves, frame rate independence and menus (a one-night job, if I can find one night this week... day job is hectic!). After that I'll do replacement of crude rectangles with sprite graphics, then we're a few steps away from a very basic Tennis game.

I won't release until it's complete, because there's nothing worse than adding to the plethora of unfinished "tutorial series" on the intertubes. I'm projecting submitting the whole mess to GDNet editorial (read: Drew) by mid- or late November, then I'll take a vacation before getting started on Resource 2.

Thoughts, requests, comments, criticisms. Fire away!