
This book/CD-ROM package will explain the basic and advanced ideas and topics behind the development of a flight simulator, a 3D walk-through game, and many utilities used to manipulate video, audio, and input devices. The CD-ROM includes all the source code from the book, shareware games, commercial software demos, and utilities for game design and image manipulation.
I was in my late junior or early senior year of high school when it came out. My stepfather had a 386/20 and then later a 486/33, a Borland C compiler, and a generic 700 page "Learn C" book at home, and I had worked all the way through the book. But I couldn't for the life of me figure how in the world to bridge the gap between the extremely slow, "high res" 16 color graphics libraries that came with the compiler, on the one hand, and what Wolfenstein and Doom were doing, on the other, both of which I was utterly entranced by.
And then I saw LaMothe's book on a random shopping trip to... Software Etc, I think? I'd never seen anything like it. And I knew I had to have it, immediately.
After getting that book, I was diving headlong into relatively fast VGA C programming in mode 13h (320x200x256 color). I spent the afternoons of my senior year of high school writing relatively fast texture mapping routines and trying to get full screen 30+ fps interactive scenes and levels running, which I think I mostly did. I had to write my own paint program, too, for 256 color palettized textures. It was thrilling.
Thanks largely to my time with that book, later when I was introduced to the internet the first week I started a Computer Science program at college, I was primed to dive into all the awesome C open source game libraries and tools (like Allegro and DJGPP) that I found online, and I was making commercial games and working in the guts of the Quake and Quake 2 code bases two short years later. (The book and then the internet were not, however, great for my college career)
I know there are corny parts of the book, and maybe things that weren't as cutting edge as they claimed to be. It doesn't teach you how to actually write actual Doom, of course.
But prior to the widespread roll out of the internet, it's hard to get across just how inaccessible most of the knowledge in the book was, at least for a high school kid like me. It really was like turning on a light switch when I got it. Sometimes something is just at the right place at the right time for someone, and that's what that book was for me.
Not great to learn that way. I finally got a computer in 1996 and had trouble getting the code examples setup... So I called Andre at this home! I was 15 at the time.
Back then, people generally had their number in the phone book so I somehow found the number for "Information" in San Francisco (Information was Google before google, for phone numbers basically. It had all the White Page information).
Anyway, I call up, and his girlfriend answered the phone. She seemed a little disgruntled (maybe just woke up) but I asked her if I could talk to Andre. He got on the phone and actually explained to me that I needed to link the libraries needed in the C++ GUI (I vaguely recall that the CD maybe came with one?)
After that he talked to me about a bunch of stuff about work ethic and programming philosphy. He had a super duper insane work ethic, writing all those 900 page books plus all the code and example games for that. And he was grinding them out pretty often, plus contributing a lot to other books, plus doing his own startup. 100 hours a week for years, and he's pretty smart so he works quick.
Anyway. I really took his advice to heart and when I got into the working world I took jobs very seriously and worked like a madman. In about 6 years I went from broke to basically having enough money to retire. And I really owe it all to him and that conversation we had that day. The lesson I took away from it wasn't to kill yourself working but that it's better to sacrifice some time upfront than have constant money issues. As a kid from a poor family this was huge in helping me get out of poverty. I never got a degree but really just his advice about hard work made it possible.
I got a chance to reconnect with him on Linkedin a couple years ago and share my story and he was really thrilled with how it went and took a lot of interest. He's continued on with all sorts of game programming startups and we kinda talked about it.
He could have easily done web development and made a killing doing his own startups but he was just so passionate about video games (keep in mind he was an adviser to Carmack). He led an army of people who went off to be game developers, though he said most pivoted to other things.
Andre was quite literally one of the most influential people in my life and I owe him a lot, and to this day I can't believe he'd take time out of his insanely busy schedule to help some kid all the way across the country, for no real gain to himself.
I still have a copy to this day, missing both front and rear cover and with with significant wear throughout. Unfortunately I don't appear to have the disc that came with it[2].
[0] https://archive.org/details/tricksofgameprog0000unse
[1] Chapter 2 is called "Assembly Language Basics".
[2] https://archive.org/details/Tricks_of_the_Game_Programming_G...
Depends on what you want to do. If you want to code games because you find the programming aspect interesting, start small by writing your own versions of some simple games. I personally wouldn't recommend any frameworks or libraries other than (maybe) SDL. Implement everything in the simplest way you can think of that will actually work and only go back and refactor if you need to, that's the time to look up how other people have solved that problem [0]. Resist the urge to over engineer. I might be biased but I say target PC first. Windows specifically, but Linux isn't much worse as long as you never plan to deploy the thing. This is because these platforms are incredibly open and there is a lot of information and tooling available. After you get a feel for it, and have a good idea of what you want to make next, start incrementally branching out in directions that interest you.
If you have a good idea of the kind of game you want to make and want to start making it with as little friction as possible, then your best bet is to find an engine that is already well suited to that kind of game and learn just the things you need to in order to make it happen. Again, you'll want to start small regardless of what it is you actually want to make, just ensure that you're always moving toward that goal. That is very much not my path, so I have little other advice.
[0] If you look it up first without trying it yourself, you won't have a good understanding of the problem space. You'll end up believing in the commonly accepted answer as dogma and severely limit yourself.
I love this. I did the exact same thing at my local library looking for books on BASIC (now I lurk on HN instead of at the library). I always had trouble getting the code listings to work because they were usually written for a slightly different version of BASIC than what I had. Without the internet there wasn't really any way for me to figure out what the problem was so there was plenty of trial and error.
One of my best memories was finally buying Tricks of the Game Programming Gurus by Andre LaMothe. I remember reading almost the whole book the first day I got it and trying out all the great code examples. This was the first time I really saw how real games were made. It basically runs though making a game like Wolfenstein 3D only two years after it was released. I think it would be a struggle to write a book about how to make a triple A title from 2010.
Near the end of high school I stopped coding but when I got back into it several years later, I was amazed at the resources and tools freely available on the internet.