Liveblogging A Game Engine
So here's where I'm at: I'm beginning my career as a software engineer and part-time game designer. I'm young, sure, but I've got loads and loads left to learn if I want to produce master-class work in the future, and working 40 hours a week just isn't going to cut it even to learn how to make software well, let alone make games. So I've got to work on some side projects in my spare time.
And since it never hurts to chat a bit about what you're doing and it's not like every other indie isn't doing the same thing these days, I'm going to try my hand at liveblogging the whole shebang as I go! And hopefully enough people will be interested that it'll keep me honest.
So, for my first project, I'm going to learn a little bit about how games work under the hood by creating my own rendition of the game engine described in the book 3D Game Engine Programming by Stefan Zerbst and Oliver Düvel. From what I've heard, this book takes you step-by-step through the process of programming your own 3D game engine (geared toward FPS's, because of course it was). This is a good starting project for me since up till now I've only made digital games in the Unity3D engine, and it'll be useful to know how to modify or write my own engine for the times when Unity or other engines can't do what I want them to do. Plus I'll hopefully learn a bit about vanilla software engineering in the process! And on top of all that, since this book was written in 2004, hopefully the Internet will find it useful to know whether the book's lessons still hold up after ten years of advancement.
I've already read the first couple chapters, which cover the basic description of what an engine should do as well as the high-level architecture of the engine. The authors break it down into about six different parts: renderer, input processing, audio, networking, 3D math, and general helper functions. Each is stored in its own DLL (or LIB, in the case of the last two), and the engine follows what seems like a decent method of platform-agnosticism by abstracting away the DLLs from whatever game wants to use them with a set of interfaces. Additionally, the game actually loads each DLL and implements their classes via another LIB. The idea, the authors state, is so that if, say, the reader happens to be very comfortable with OpenGL, they can easily swap out the book's Direct3D renderer for an OpenGL one. My instinct thus far is that this abstraction will either be the saving grace of the engine, insulating its application from the worst parts of the changes to APIs that time has wrought, or it will be the engine's downfall because the interfaces or libraries themselves will be using deprecated functionality that will be tough to fix.
We shall see...In the next post I'll be done reading and will instead get the actual the workspace for this project set up and starting in on implementing the renderer.
Final note: I'm not sure what the license on the code in the book is, but hopefully I'll be able to post my project to Github as I go.