Getting Started with Game Development?

Knight2K writes "Recent articles about casual gaming have given me the itch to try my hand at writing some games. I haven't written any since my college projects, and they never followed any formal game design practice or patterns (unless it was unconsciously). I'd like to start just by writing simple board games and card games that my family liked to play that have no digital counterparts as far as I know. Eventually I might want to branch out and do 3D work. I mostly work in Java right now, but I'd re-learn C++, if needed. My question: what books would you recommend to a beginning game developer? Good introductions to game theory would be welcome, but also language or platform-specific suggestions are useful as well: OpenGL, Symbian, C++, Java, J2ME, etc."

Comments

Not a book, but...

[Dial-Up]

Well, this isn't a book, but just as good. The Game Programming Wiki is a great resource for game programming in several major languages. There's also a very active message board that is extremely helpful.

Screw books

[RootsLINUX]

I have never been a fan of learning how to do something by reading about it. The only way to learn good game programming, IMO, is to actually try doing it. That's how I started with the game in my sig and its been working so far. While not a book, may I recommend you take a look at the Simple DirectMedia Layer (SDL) library? It's free, cross-platform, and is really easy to learn to use. It's written in C, but there are extensions to it in other languages. Good luck!

Just Do It (tm)

[BigZaphod]

I toyed with this myself. In my experience, it isn't the technology that's hard. Simple games like you're talking about aren't much different from any other apps out there, so just dive in and do it in whatever language you want to use. It doesn't take some kind of special training to code a card game if you already know how to do GUI programming.

The hard part, IMO, is the extra stuff like graphics and sounds. Unless you're talented in such things, making a game look and sound good is a real problem. It is especially troublesome if you don't know anyone who can do the artwork and is willing to just toy around with you for free. Good artists are expensive and games need to look good or most people will pass right over them.

The only technology that is really hard is the 3D stuff due to all of the math and such. However, there are so many libraries and engines out there (many free and open source) that most of that isn't an issue anymore and once again you're back to the art and gameplay being the hard part.

Just do it. If you run into problems, there's always Google. The best way to learn what you will need to know is to get started now and discover it on your own - that way you will not only know what doesn't work, but you'll also know *why* and that's an important element that can often go missing if you try to do it the "right way" from the beginning.

SDL & C/C++ on Linux may be a good start

[green pizza]

What is your target? Do you want to write a game for a Windows PC? If so, then maybe you should look into C# and Direct3D. If you want a cross-platform game that you can compile on Windows, Linux, BSD, and Mac OS X, then look into SDL and OpenGL.

You might want to start here if you're going the cross-platform route:
http://www.libsdl.org
http://andrew.textux.com/tutorials/tut1/tutorial1. html
http://www.kekkai.org/roger/sdl/

Re:SDL & C/C++ on Linux may be a good start

[theoddbot]

There's also pygame which is a python interface to the SDL/OpenGL stack.

Makes it easy to write some cool little games :)

Start Easy and Produce something.

[xMonkey]

My #1 suggestion would to get yourself a copy of Flass MX or something simular.

You number one roadblock will be graphics.

Flash is an excellent way to quickly prototype game ideas. And the more you use it the faster you can prototype ideas.

I think game design NEEDS to be fluid. You need to get something working play it, find out whats fun about it and whats not fun. Determine what works and doesn't work.

Prototype everything first. Then when you have a solid design of the game play and mechanics, you can start something a bit more serious.

And more than likely your prototypes will be acceptable flash versions, and you might actually have a finished product in Flash.

For OpenGL..

[BigZaphod]

Possibly the best way to get started with OpenGL is the NeHe Tutorials. The articles are often written in a C or C++ style but most of them have been ported to tons of other languages and platforms. Check the ends of the articles for links to source for whatever platform you want to work with.

Game Production vs Game Design

[dacaffinator]

Programming a game and designing a game are two quite seperate disciplines. If you are interested in making a small game you'll probably be doing both.

Typically a game is designed on paper before any coding starts. Once the game design document is fairly complete a technical design document outlining the games implementation is written. Even for a small game, defining what your game is before you try to code it is an important step. That said there is nothing wrong with doing quick prototypes of gameplay ideas before you commit to something.

You game design document might list what platforms you intened to target and your technolgy choice should be influenced by that.

DirectX limits you to Windows only, SDL is great but not hardware accelerated (I think there are work arounds) but that might not matter for your target audience and platforms.

For some sample game design documents and a list of good books on the subject try http://www.ihfsoft.com/index.htm

Out of the books listed there I highly recommend Game Architecture & Design.

SDL and patience :^)

[swerk]

I've written a small game that some folks find addictive:
http://www.nongnu.org/tong

It's from an old idea I had and was looking for an excuse to teach myself SDL, which some buddies and I had chosen for a much more ambitious game we're still working on.

We chose SDL primarily because it is cross-platform. I use and develop under GNU/Linux myself, but I want all my windows-running buddies to be able to play my games. OSX and even DreamCast porting is trivial, as SDL happily runs on those platforms and many more.
http://www.libsdl.org/
SDL is very well documented and very slick to use, even to a newcomer (so long as you do have some programming experience). I'm a C and C++ guy, and SDL works with those natively, but if you wish to stick with Java or any other such language there are appropriate bindings. I highly recommend the libraries SDL_image and SDL_mixer as well, for boosting image and sound loading support. (I love being able to have my game just load up .png and .ogg files directly... it just feels all warm and fuzzy :^)

I subscribe to master Miyamoto's game design theories, which basically amount to making your game into its own little playground, running on its own rules and rewarding the player for being clever. Keep the controls simple; a person should be able to pick up and play. Now, my game Tong is pretty rough at first, so I maybe don't follow this thinking very well in practice, but the philosophy is an implementation of the old "Keep It Simple, Stupid" that you've heard so often and I think it's very sensible. Especially for budding game developers.

Even with a well-documented API and a clear idea of what you want your game to be, it's going to take a while. Get a demo of "stuff happening on-screen" with mock-up graphics to get a feel for how you're going to render things, then trash the whole thing and start building up all the pieces you need. If your strengths are with object-oriented design, figure out all your game entities in terms of objects that all inherit things like how to draw themselves. If you're more of a procedural programmer, and even if not, figure out your main game loop, what needs to happen every cycle and what can be called out in special cases.

Take your time, let it be a pet project. The last thing you'd want is to extinguish your interest by making it a serious commitment. Starting small and building up is an obvious and good approach.

Best wishes! Long live the independant game developer!

Good introduction to game theory!

[MrDomino]

[...] Good introductions to game theory would be welcome, [...]

You and a partner commit a crime, and are arrested. In the interrogation room, you learn that the two of you will each go to jail for 2 years if neither of you says anything; however, if you testify against your partner, you'll get off free while he ends up with 6 years. If both of you confess, you both go to jail for 4 years. What do you do?

You are playing a game where you are given $50, and then asked whether you would like to take it as is, or flip a fair coin. If you make the latter choice and turn up heads, then your total amount will be doubled to $100; if you turn up tails, then the amount will be halved. Do you take the $50, or take your chance with the coin?

You appear on a game show where, at some point, you are told to pick one of three doors. Behind one of these doors is a prize; behind the other two, nothing. You pick a door. The host then declares that he will open one of the empty doors. Having done this, he offers you a chance to switch to the other, single remaining door. Do you switch, or do you stay?

Re:Good introduction to game theory!

[spectral]

of course then I go and screw up #3. I should have said always switch, since you had a 1/3rd chance of being right when you chose your original guess, leaving a 2/3rds chance that you were wrong. Now the problem is reduced to two choices.. so you'd think that you'd have 1/2 chance of being right, but you don't.. the 2/3rds never went away, it just compressed down on to one door, so you should pick that.

this site explains it better than I can.

Re:Good introduction to game theory!

[JavaRob]

1) Prisoner's dilemma: It's not really probability (since the other guy isn't deciding randomly) but... Don't confess. If you do, and your buddy *doesn't*, you are out of jail immediately but you probably have only 6 years left to live. You're risking 6 years if he confesses, but you can hope the same fear will shut him up too.

2) Easy one -- flip! Half the time your total drops $25, the other half it goes UP $50. If you keep playing you'll make out better than just sticking every time.

3) Don't go on this game show. If you pick the right door, sure, you get a prize, but you'll also get a lot of publicity, your relatives and old friends will pop up out of the woodwork asking for money, and you may pick up a stalker or two. If you pick the wrong one you will be forever haunted by it. You'll wake up in the night covered in sweat, shouting "No, I said DON'T change, DON'T change!!"

How about Flash?

[breon.halling]

I know much of Slashdot's audience can't stand Flash, but I've had quite a bit of experience with it over the past five years -- I was a Flash game developer -- and I've got to say, ActionScript has become o very powerful language. Don't be fooled by its name: It's not a scripting language. It's an entirely object-oriented similar to Java and C#. You should feel right at home with it.

The upside is a very rapid development phase: you could bang out a prototype in a couple of hours, depending on complexity. It's also an almost-ubiquitous platform: With the exception of *nix (of which I know very little, and as such refrain from commenting), the player is reportedly installed in 90% of all browsers.

The does-side is that you have little-to-no control over lower-level functions, such as memory-management; no direct disk access outside of 'Flash cookies'; and absolutely no access to a user's video card. It's also quite an expensive application -- it starts at $499.00 USD for the standard version.

Quite a number of amazing games have been developed using Flash, most notably (IMHO) Alien Hominid, which, ironically, has been turned into a full-fledged console game.

That's just my two cents, at any rate.

Best advice: Don't!

[AtariEric]

Hire an already existing and out of work game programmer to program your game. We need the money!

Torque 2D

[startled]

If you're not already used to programming in 3D, it can take way too much time to ramp up, find an engine that works how you want, understand it, and so on and so forth. Writing a 3D engine is also a massive task, and will probably kill your interest before you get around to actually writing a game.

2D is a nice way to go: it's a lot more fun getting so much more bang for your buck, without nearly as many content hassles either.

One cheaply available 2D engine that comes with source is from the good people at garage games, called Torque 2D. It's got a decent scripting language, and nice enough C++ code. If you don't want to re-learn C++ right away, you can accomplish quite a bit with only the scripting language.

There are probably some other nice 2D engines out there as well, so you can look before you buy. However, I'd recommend picking one and starting from there: it'll save you a ton of work, and you're much more likely to actually get something done.

One other possibility: I made a funnish GBA game in my spare time a while back. It just took a few weekends (and a flash linker from Lik-Sang), and the help of a couple friends. I never finished it, but it was a reasonable demo. GBA dev is slightly tougher than 2D dev with an existing engine, but the libraries out there make it really not too much worse.

Don't for Allegro!

[slapout]

Many people have mentioned SDL. You should also check out Allegro. It's a multiplatform game programming library.

http://www.talula.demon.co.uk/allegro

Typical Slashdot Advice

[SteevR]

Very few responses have actually answered this guy's first question: "What books would you recommend to a beginning game developer?"

Core Techniques and Algorithms in Game Programming. I own many game development tomes, and this one replaced 3 1/2 shelf feet of my reference material. This book contains everything the beginning competent programmer needs to get a quick start at programming any sort of game imaginable, and it covers topics from *useful* design patterns and data structures to shader programming.

Game Architecture and Design is another good book, but is a survey of information from design patterns, architecture, game design/ludology, project management, and business practices in games. Probably up your alley but not exactly what you asked for.

As for an introduction to game theory, none is better than Rules of Play. This book is the first extensive critique of the entire field of game theory as it is applied to game design that I have read. Lengthy, and it reads like a textbook (it was designed as one), but engaging.