Beginning OpenGL Game Programming
Core Techniques & Algorithms in Game Programming
Game Programming Gems
Game Code Complete, 2nd Ed.
Code Complete, 2nd Ed.
Artificial Intelligence: A Modern Approach (2nd ed)
Computer Graphics with OpenGL, 3rd Ed
and
The C++ Programming Language, Special Edition, which I didn't see in the books section but you probably know what it is.
Now, the AI and Computer Graphics books were for classes, but the rest I bought on my own free will. Imagine what I should be able to do if I spend reasonable time with each of these books! Clearly I can't spend all my time reading, but I can certainly spend more!
I've tried reading the core algorithms book, code complete, game code complete, and the C++ programming language books cover to cover. I've read all the the language definition in C++, but the rest I'm only like a couple hundred pages in.
The only other book I've spent time with is the Beginning OpenGL Game Programming, which I've used as a reference more than anything, and it's been very usefull too, I'm looking forward to the next book.
I've been trying to make myself read more in Game Code Complete (a really good book by the way, fun to read too), since I've gotten to the chapters that apply directly to what I am trying to do now: input and 2d stuff.
Which brings me to my project: SnakeEngine.
Currently I am working on SnakeEngine[Garter]. Why the name? No, I'm not because I'm a Metal Gear fan, but because in Game Code Complete he recommends using version names, rather than version numbers, or something to that effect. Well I thought that sounded like fun, so I kinda took it in my own direction and ran with it.
I wanted something that has a bunch of words that can be grouped together.
I wanted something that is cool to a 5 year old, but pretty cheesy to the rest of us (not surprisingly, the same thought process that was behind the naming of Radical Racers).
I like snakes.
This worked out even better than I originally expected, here's why:
So long as the engine ("engine") only supports 2D models (sprites), the version name will be of a non-venomous snake.
When I begin to implement true 3D into the engine ("engine"), I will switch to venomous snakes.
Awesome.
And naturally, "Garter" is the best place to start.
Later I'll try comming up with a common logo between versions, with some variation for each one, not sure what yet though.
Also, SnakeEngine would probably be better named as "The Snake Experiments", meaning I'm not caring too much about backwards compatibility between versions. This is because the Radical Racers engine is the only game engine I've ever made (not counting text adventures and the like). And it sucks. I learned a lot from it, but there's no way my first next engine will be perfectly designed, with a perfectly designed interface, especially since I've never used OpenGL for a game before. In the end, the goal is that I will be able to take this graphics library I end up with, and use it in a game and never have to know it's using OpenGL.
Anway, Garter.
Garter is pretty much done, it's goal was to be as simple as possible and still do what I want, those things being:
- Initialize and set up OpenGL
- Display Points
- Display Lines
- Display Circles
- Display Squares
- Display Textures
- Display Text
I still need to add triangles, which I honestly have no idea why I haven't put that in.
Notice that it displays Textures, not Sprites. I decided to keep Garter as empty as possible, and as I used it decide what would possibly be better as part of the engine itself. For now I didn't want to restrict myself to a specific sprite format, so I left it out.
Text should never be used from the engine directly as-is except for debug purposes. It's just a bitmap font and it's really slow for some reason (not noticably unless you fill the screen with text, but still). I have some ideas for optimization, but that may come later.
You may be saying "Hey, that's not an engine, that's just an OpenGL wrapper", to which I would say "Yeah, that's exactly what it is".
I get internet Friday, I'll try to post some screens.
Along side Garter I've been working on a simple sprite engine, because why wouldn't I want that? I decided to name it after the first sprite I animated, so I call it SamusSE (Samus sprite engine, duh).
There's not much to say about this, except it uses Garter (I'll probably try to de-couple those two, so I can use it without changing it with future engines, which should be trivial), reads text files (which need to be robustified still) describing the sprite (animations and such), and loads a texture (separate file from the description), and displays it. The update rate for frames is described in milliseconds, a default is given in the file but it can be changed on the fly. I can't remember off the top of my head if you can select individual frames yet, but you should.
Other than that I now need to work on some sort of input, mouse and keyboard. I really haven't done a lot of this at all so I'll have to do some reading, shouldn't be too hard though. I just want something that reads (or gets or whatever) the input, translates it into some generic message, and passes it to whatever may be concerned. I'm somewhat familiar with signal/slot designs from some work with Qt, but I'm not sure how to go about implementing it.
I would also like to make some sort of resource loader library, that can load files directly from disk, or from some type of archive. A while back I made my own archive format using Huffman compression, I'd like to use that if I can. Huffman doesn't work super great by itself for most things, but it'd be cool to use something I made. Right now I have tools that will compress an entire directory if you want (including subdirectories) and preserve the directory structure, so in theory I can have a game ask for file "graphics/car/cinder.bmp" and it won't need to care if it's loaded from a file on disk or from a compressed archive. I call it a Glob archive (.glb), which isn't what I wanted to use, really, but I called it that once, and you know how it is, if you call it something, you better come up with something else real fast or else it will stick. Unfortunately while I was trying to use good programming practices when writting this, it has a lot of Windows specific code, and if at all possible I'd like to be able to use these tools to make games for both windows and linux.
Anyway, I have to go now, but I might add more to this later.
