Good Game Programming Books

I want recommended books that teach you from zero (well maybe not exactly from zero) about game programming. I don't want the book to say "I assume you studied C++ language in college" or any other related stuff. I may know a bit of the basics but still I want to get a great picture about game development (programming/designing) starting from scratch, so please inform me any good recommended books for this.

Cheers

I wouldn't mind a good recommendation either. I tried downloading Python and seeing how I went and it just seems like so much gibberish. //_-

Put bluntly, what you're asking is pretty silly. If you want to program games then you need to be able to program first. Before you can do something as complicated as program a game you need to learn the basics: it's not really reasonable to imagine you can just leap into something that complicated without even understanding fundamentals, like what a loop is, or a variable, or a function. As with many other skills, you need to build up in stages.

Spend some time learning a programming language first. Python is a good choice for learning programming, C++ isn't. Something like Python The Hard Way might be a good starting resource.

fraggle said:

Put bluntly, what you're asking is pretty silly. If you want to program games then you need to be able to program first. Before you can do something as complicated as program a game you need to learn the basics: it's not really reasonable to imagine you can just leap into something that complicated without even understanding fundamentals, like what a loop is, or a variable, or a function. As with many other skills, you need to build up in stages.

To be fair, many of the BASIC tutorials for 80s home computers did just that: they taught you the fundamentals of programming by having you make "games", even if as simple as playing "guess the number" on a command prompt, but eventually they moved on to having graphics, music, animation, and even real-time keyboard input and character movement.

But this was aided by the fact that those computers had a relatively powerful built-in BASIC (you didn't have to master DirectX or the Windows API before you could even get something to compile, let alone draw any graphics or play back sounds) and that the "games" you could make were pretty simple (I mean, in an era when even commercial games were 2D platformers or shooters, one would be perfectly happy just to be able to move a smiley with the joystick across the screen, plus there was all this DIY culture).

Of course, once someone noticed that commercial games were more complex/faster/did "weird" stuff not possible with BASIC, things got into machine language and PEEK & POKE territory, and quite uglier/hairier ;-)

Strangely, while today there are much more powerful and comfortable programming tools available, a new PC doesn't come with the equivalent of those old BASIC interpreters anymore (even DOS used to have QBASIC, at least), and the heightened expectations (3D graphics, digital sound, point and click interfaces etc.) would mean that a novice would probably not be happy with drawing solid color lines and playing back beeps. The ante has been raised quite a bit, and choosing "the right" set of tools/language to start with is anything but trivial.

Certainly, there are dumbed-down "make-your-own-game" tools and even souped-up versions of those old BASICs (PowerBASIC, DarkBASIC etc.) but IMO those are counterproductive: they are too much of a sandbox environment, don't teach proper programming practices, and while they abstract away most of the aforementioned difficulties, whatever "skills" one might learn on them are not transferable.

I remember learning QBASIC on C64. That's where I learned how so many years ago.

Do you even need a book anymore? Just look it up online. Everyone seems to happy to give away free info on their site. Or youtube videos.

geo said:

QBASIC on C64

QBasic was a dumbed-down version of Microsoft's Quick Basic, only available on IBM PCs and starting from DOS 5.0 (still pretty powerful, though).

The C64 had its own dialect of BASIC, which was quite limited and unsuitable for doing anything advanced, without resorting to machine language and a tons of PEEKs and POKEs.

geo said:

I remember learning QBASIC on C64. That's where I learned how so many years ago.

Do you even need a book anymore? Just look it up online. Everyone seems to happy to give away free info on their site. Or youtube videos.

Yeah, if you're GOING to disregard all advice to the contrary and start by learning C++, don't waste a lot of money on books. Use stuff like cplusplus.com :P

Pygame comes with a number of books, including one that brings you from no experience to doing games fairly quickly. Depending on your goals, learning Python may be your best best, if you're not looking to be a professional programmer. (Python is great, but it has a few quirks that can give you bad habits.)

It seem to me that the problem with learning to program games, is that you have to start with wanting to learn how to program period.

I guess he could team-up with Katamori, who seems to have taken the hard route with some success.

Quite honestly, I didn't believe that just by cobbling code together like Katamori mostly did and fighting with the compiler, one could get a C++ game using standard APIs going so quickly.

But it seems that if enough energy is put into it, even if you don't know 100% what you're doing, it's possible to get something functional. At least it proves it's not impossible, but the catch here is that Katamori is a CS student, and that C++ is part of his curriculum, so that's quite a few steps above the "I don't know how to program but want to make a game anyway" category, in my book.

Also, a colleague of mine, managed to crash-course a group of complete novices into Android development, force-feeding them the fundamentals of Java and OOP along the way in less than 4 weeks, so perhaps with enough determination everything is possible, but I don't see this determination in the OP.

If you don't want to learn a "real" programming language, there's the risk of remaining stuck at the level of toy or sandbox languages. You can get out of that trap, eventually (I know I did...) but perhaps that's even harder than learning C++ straight away.

I made a Sokoban clone in Java back in high school. Does that qualify me to learn C++? I've been thinking about it too (though that's probably about as far as I'll get).

IMO, the closest equivalent to BASIC these days would be something small, lean and simple like Lua or Tcl. But you still need libraries to do graphics stuff unfortunately. So just stick with text-mode (ASCII) games for starters. :-)

ahh yes, you must go through the rite of passage and make an ascii rougelike or text-based adventure!

but yeah, as others have said: get the chops, then eventually fiddle with graphics libraries and such. I can vouch for pygame being easy to use (if you choose to learn python, which itself isn't overly difficult), I also played around with panda3d for a bit, which is an open-source game engine that was pretty fun to mess around with (c++ library with python bindings).

an alternative route I suppose would be programs like GameMaker, though I don't know the level of programming knowledge required to make use of those

I can make a very basic "breakout" or similar example in pygame if someone wants. My code is always in 1 file and breakout wouldn't be very many lines of code.

I wanted to make a topic about this but this one is good enough I guess:
What is the best "environment" to code plain c in?
Specifically I tried code stupid colon colon dumb named blocks, and look at this freakin' 28 step instruction manual just for setting up SDL:
http://lazyfoo.net/SDL_tutorials/lesson01/windows/codeblocks/
It's like... it's like... a bunch of peripheral meta programming. I want to "program", not do all this crap. It took like 2 solid days to figure out how to set it up so it works. I downloaded, deleted, re-downloaded crap. Eventually I had to right click something in the left panel and bla bla, I forget what even eventually worked. But with pygame, you plop SDL in a folder, and voila it works. In c, you have to do all this setup crap... dll files, linker settings, search directories, pasting some cryptic crap in the Compiler and Debugger settings area..
Is all that because code::blocks sucks? I suspect a lot of those steps have to be done for every single program you make too, whereas in pygame you just do it once. Like which c environment lets you use SDL with minimal peripheral busywork?

It's a bit easier on Unix systems. You just create a basic Makefile, with some invocations of sdl-config to setup the correct includes & libs, and then just include the required header files in your code.

Either way though, your code has to invoke all the necessary SDL functions to initialize the library, setup video modes, etc. (along with checking the return values, to see if something blew up). It's not all that much different from say, setting up VGA mode 13h on a DOS machine, so you can write to the framebuffer. There's still come "cruft" boilerplate code needed to setup the environment. It's still an extra step above and beyond what you had to do on the old 80's machines with BASIC interpreter that was customized for the hardware. Like for example, on Amstrad CPC you would only need to select one of three video modes and then you could immediately do graphics with BASIC instructions. Well actually you were *always* in video mode (the machine didn't have a pure text mode, like DOS) but you just wanted to make sure you were in the "right" mode for the color depth and resolution you wanted. Anyway, that BASIC dialect probably had the equivalent functionality of some modern graphic/sound libraries, to the point that some commercial games were even made with it.

hex11 said:

But you still need libraries to do graphics stuff unfortunately. So just stick with text-mode (ASCII) games for starters. :-)

Unfortunately, you get nowhere near the degree of control over text output afforded by QBasic or Borland's <conio.h> without using a third-party library nowadays (non-scrolling screens, colored text etc.), so even text-mode games are gonna look crappy if one uses just standard output functions. A rogulelike with non-scrolling text screens and block graphics would actually be quite high in difficulty.

I know little of makefiles but remember trying to run some program in codeblocks that used a makefile and it wouldn't work because codeblocks uses some other non-makefile format or something.

But what about
#include sdl
type stuff at the top of your code- shouldn't that take care of "invoking" the needed external sdl functions? Like is all that linker settings/search directories/etc just configuring codeblocks itself, or is it necessary for the actual c program? Maybe its better to code in c with no "IDE".
I still haven't even coded in c, because all that setup exhausted me so I just went back to pygame. Even ACS just works without needing to click around a bunch of windows and "link" stuff or whatever. Seems a bunch of tedious steps should be... automated.. since this is programming afterall.


Also I forgot to comment about the op topic of books. Every one I've read is almost useless. Its hello world drivel stuffed into a nice looking cover picture (often not even that) with a SEO title and astroturfed reviews to trick you into buying it. There's a crapflood of such books so if there are any real ones, good luck finding them. This leaves you with trial and error, and asking questions on forums. Its especially hard if you want to learn to program WITHOUT OOP... that paradigm is the borg, and maybe 1 out of 100 example programs don't use it, at least for python. And c was mostly hijacked by OOP c++ too.

hex11 said:

Anyway, that BASIC dialect [Locomotive BASIC] probably had the equivalent functionality of some modern graphic/sound libraries, to the point that some commercial games were even made with it.

Which was not always a Good Thing :-/

Maes said:

Unfortunately, you get nowhere near the degree of control over text output afforded by QBasic or Borland's <conio.h> without using a third-party library nowadays (non-scrolling screens, colored text etc.), so even text-mode games are gonna look crappy if one uses just standard output functions. A rogulelike with non-scrolling text screens and block graphics would actually be quite high in difficulty.

Yeah, an actual roguelike would be difficult. But my idea of text-mode games is more along the line of what you'd find in David Ahl's BASIC Computer Games (and other related books, on same the site). These are really old games originally designed for machines with actual teletype devices! :-)

And you can actually write a lot of fun games that way. It doesn't have to be just hangman or Hunt the Wumpus clones... you can also do sokoban-style puzzle games, RPGs like Legend of the Red Dragon (that old BBS game) and so on.

And if you're willing to "cheat" a little bit, you can do colorized output and basic screen handling with ANSI escape codes, or by shelling out to the 'tput' command (in Unix anyway), without going into the land of Curses.

@gggmork - google "Programming Linux Games", it's a free book that goes over the basics of setting up your environment, using the compiler, makefiles, etc.

hex11 said:

makefiles, etc.

There you go...
Instant turn off for beginners. What about tools that use the computer to do the computing instead of using the human brain like this stone age tool?

Graf Zahl said:

Instant turn off for beginners.

Which IDE or whatever would you recommend for plain ansi C?

All this C/C++ talk is nonsense, you don't need to know either these days to make something. This is like telling someone in 2000 to learn assembly.

Object orientation doesn't automatically make anything better, usually it does the opposite. Straight forward procedural code is enough for most projects.

Maes said:

A rogulelike with non-scrolling text screens and block graphics would actually be quite high in difficulty.

You'd have to emulate the old terminal interface in something like SDL. This is what Dwarf Fortress and probably a lot of other roguelikes do. Really just writing pixels to the frame buffer, but as discussed already you have to learn the basics of programming before you can do anything.

gggmork said:

Which IDE or whatever would you recommend for plain ansi C?

Unix *is* an IDE. :-)

Of course, you don't have to use Makefiles. They happen to work pretty well for projects with lots of files with dependencies, but if your have a simple project you can easily get away with a simple shell script (or Perl, Python, Tcl...)

Anyway read that book, it's oriented towards ANSI C, and shows you the basics of using the compiler, debugger, text editors, etc.

hex11 said:

Unix *is* an IDE. :-)

In the very loose sense of "collection of programming tools", yeah. But in practice an "IDE" usually contains some pretty pull-down menus, windows, etc. and in general a lot of bells & whistles. :-)

This includes even text-mode editing/execution environment that sit on top of said collection of tools (QBasic and Borland's products were a pretty good example of that, they had a windowing subsystem that almost rivaled Microsoft Windows).

Basically, anything that removes the need to use a command line for actual compiling, linking etc. *and* that removes the need to do metaprogramming such as makefiles etc. (those are simply building automation, and we all know how "well" they work --sometimes) and provides an easier means to organize stuff into projects.

Sometimes the "integration" goes so far that the compiler, linker etc. are not even accessible in any other way *but* from within the IDE itself (e.g. Turbo Basic, Mystic Pascal etc.) but I suppose RMS wouldn't approve ;-)

Graf Zahl said:

There you go...
Instant turn off for beginners. What about tools that use the computer to do the computing instead of using the human brain like this stone age tool?

For me, "computing" has never been the problem. Grasping the fundamentals of how computer logic and algorithms work is the easy, intuitive part. Hell, any student could pick it up after basic algebra. Most programming classes/textbooks disagree that this is the fundamental part of learning languages, and instead start off with "here is how your IDE and files and includes have to be set up, here is some syntax without context and you'll just kind of pick up how the rest works after you plug at it for a decade".

But no, I guess laboring to memorize ONE language is preferable to having a set of skills that can be applied to learning ANY language...

I agree with Graf. The best environments for learning programming are those that eliminate as much of the boilerplate tedium as possible and let the user focus on the fundamentals that they're trying to learn. If the setup involves makefiles, you've immediately made things harder, as the user is now learning how to program *and* how to write makefiles.

Same with the choice of programming language - if you use a language like C, you have to learn not only things like loops, variables and control flow (ie. the fundamentals), but also things like: what a type is, different classes of variables (static/auto, etc.), what a library is and how you #include it, etc. If you C++ then there's likely a whole load MORE boilerplate junk on top of that.

There's a lot to be said for a language where "print i" is all that's needed to output a number to the screen.

fraggle said:

There's a lot to be said for a language where "print i" is all that's needed to output a number to the screen.

Actually, you don't even need the "print" part in most BASIC dialects which have an interactive mode. Everybody seems to be forgetting the -once dominant- distinction between interpreted/interactive and compiled languages, too.

Interpreted ones have less boilerplate/overhead precisely because they are designed to handle laxness -the most extreme example being perhaps JavaScript, which however is FORCED and PAINFULLY used as if it was a super-stable, well-defined, rock-solid runtime environment and platform....

Maes said:

Actually, you don't even need the "print" part in most BASIC dialects which have an interactive mode. Everybody seems to be forgetting the -once dominant- distinction between interpreted/interactive and compiled languages, too.

You don't need to type out "print" in Python's interpreter shell, either. But neither one is actually writing a program, it's just poking a shell for the state.

Maes said:

FORCED and PAINFULLY

Do you have a mission that every thread contains these words?

chungy said:

Do you have a mission that every thread contains these words?

Rather, is it that most aspects of life sooner or later boil down to this?

Bucket said:

Most programming classes/textbooks disagree that this is the fundamental part of learning languages, and instead start off with "here is how your IDE and files and includes have to be set up, here is some syntax without context and you'll just kind of pick up how the rest works after you plug at it for a decade".

But no, I guess laboring to memorize ONE language is preferable to having a set of skills that can be applied to learning ANY language...

This has been my experience trying to teach myself programming. I found that reading The Structure and Interpretation of Computer Programs is a good way to learn important programming design principles and paradigms without being bogged down by lots of extraneous details. The book dedicates maybe the first section or two to syntax and setting things up and then immediately moves on to algorithm analysis and functional programming principles. While some of the example problems are hard and require domain knowledge like calculus, linear algebra and mathematical proof, the book teaches you how to program rather than teaching you syntax. Of course, the language the book is taught in isn't widely used or particularly practical, but I find that the language alongside the principles taught in the book and the extremely simple interpreter makes translating the ideas in my head directly into a usable and modular (if inefficient, at first) program a breeze compared to C/C++. I haven't finished the book yet, but later sections delve straight into building new programming languages, interpreters, assemblers and compilers.