It’s been quite a while since my last 3D game engine post, but I haven’t forgot about it. In fact, I’ve been so heads-down in research I haven’t really done any development at all. I still feel like there are a few more books I will need to read to be better prepared, but I guess that will always be the case. So I’ve decided to at least start some preliminary work on the engine itself. Honestly, I’ve barely even started but I thought this series would be more interesting if you saw the genesis of the engine. From absolutely nothing to, well, I hope something respectable.

Since I’m considering this the precursor to my first 3D engine, I am code-naming the project “Engine Zero”. Partly because this is sort of the “day zero” and partly because I’m a programmer and zero comes before one. Though it does look like there is a “Zero Engine” already, so I will have to come up with a better name once I am further along. So behold, the first screenshot of the engine below. Yes, it’s just a message box. You have to start somewhere, right?

Engine Zero 01

OK, so that took all of 5 minutes to whip together. But I have done some planning in terms of file management and source control. First off, the way Visual Studio organizes files by default is non-optimal. Having the source files mixed in with project/solution/temp files is not what I want. So I have made a folder just for source code, another for the build binaries, and a project folder for everything else. This feels a lot cleaner and will help keep the project more organized. You can see the structure below.

Engine Zero 02

Next up, I created a source control repository for the project. I ended up going with Subversion, as this will be fine for just coding by myself. I know everyone loves Git, but honestly I find the tools and front-ends for Subversion to be a lot more mature than with Git. If I can use a user-friendly GUI and save myself time, I’d rather do that over command-line hacking. However, I am not using source control as my sole backup method. I have the project folder backing up to an external hard-drive and to the cloud. Plus, it saves each file revision, so I could rollback changes even if I forgot to commit to SVN. It would literately take Armageddon to destroy this code. And, frankly, if it’s the end of the world I’ll probably have more important things to worry about than the integrity of my backups.

Anyway, I am still very excited about this project and think the potential is enormous. While there is not much room for yet another 3D engine, I think I have some innovative ideas to bring to the table that the community would be genuinely excited about. I don’t want to over hype things this early into development, or give away all my ideas, but if you stick around with me through this series, I think it’s going to be a fun ride.

3D Game Engine Programming
The quest to become a master of 3D engines has brought me to another book, 3D Game Engine Programming by Stefan Zerbst (with a forward from the legendary Andre LaMothe). This is one of the first books I’ve read in a while that wasn’t available on the Kindle, and it’s out of print, but I managed to find a used copy of the paperback without a problem. At a somewhat meaty 850 pages, it was a little cumbersome to read, especially laying down in bed. It’s really amazing how spoiled you get with new technology. Anyway, the book was great and I enjoyed the whole thing.

Though I have been reading a bunch of books on graphics programming, this one was a refreshing peek into the design of a 3D engine. It was also obvious that the engine was a living, breathing thing. Not just a sample created for the book. Zerbst covers a lot of ground here: rendering with DirectX9, sound, input, scene management, networking, a math library, even creating a simple level editor/low-poly modeler. And he goes in-depth, even to the point of hand-coding assembly for optimizing a vector class. And, somehow, he made it make sense.

I very much enjoyed the amount of code and the amount of discussion that followed each piece. There are tons of code samples throughout the book, with ample explanation as to what everything is doing. Though there were a few cases of long, multi-page code samples, for the most part the author kept things as concise as possible.

Another thing I liked was how Stefan Zerbst broke out each major component of the engine into it’s own DLL (i.e. one for graphics, one for sound, one for input, etc.). I think this is a great idea, and has the potential to speed up development without having to compile all these parts of the engine every time you need to test your game. This is certainly something I want to explore further with my engine.

Surprisingly, the book was not totally outdated considering it was first published in 2004 (almost 10 years ago, OMG!). Granted, there is some discussion of stencil shadows and the fixed-function pipeline but, for the most part, the basic concepts are still valid today. It’s also somewhat amazing (or amusing) that Microsoft created an API (DirectX9) that still going strong so many years later.

However, the book isn’t totally without fault. One thing that seemed a little strange was the authors liberal use of global variables for key parts of the engine. He would even say: “I am just using a global here to make things simple as an example, you may not want to do this in your engine” or something to that effect. I understand making things easy for illustration, but why not show us the right way to do it?

It’s not like one single book could ever cover all you need to know about writing 3D engines, certainly not in 850 pages. That being said, 3D Game Engine Programming is an awesome resource for the aspiring engine creator. It covers territory not seem in other books and really digs deep into the aspects that matter. All-in-all I found this text to be helpful and am glad to have it in my growing collection.

3D Game Engine Architecture

In preparation for my 3D game engine, I have been trying to read all I can on 3D engine design and architecture. Although there are some good books out there, it’s very difficult to find a text that will walk you through everything you need to know. That said, 3D Game Engine Architecture: Engineering Real-Time Applications with Wild Magic by David H. Eberly gives it a good attempt.

The book covers the author’s Wild Magic engine, and discusses certain choices he made when developing the engine. It briefly touches on OpenGL, discusses abstracting away platform-specific details, 3D mathematics (and there is a lot of math in this book), an object system, scene-graphs, level of detail, render states, sorting, terrain, animation, collision detection, physics, and more. A lot of ground is covered in less than 800 pages.

However, I found much of the book difficult to follow and still feel like I could have a better picture of the “architecture” of an engine. When I think of “architecture” I think about a broad 500 foot view of a project. I think of flow charts or UML. I expect discussion on how all these disparate elements come together a form a whole. Sadly, that is mostly missing from this book. What the author provides is a good insight into his particular engine, and certain specific aspects of that engine. While this is still a great example to look at, I feel the text could have been more robust in terms of painting the big picture. Some of the things that I found missing were an event system, which seems crucial to an object-oriented engine, or a component architecture, really any type of  structure that allows communication between classes.

Additionally, I found myself getting lost multiple times while reading the book. The author would frequently put in dense mathematical equations and proofs, sometimes spanning multiple pages, and by the end you would be left to wonder what the purpose of the equation even was. I feel like having proofs of equations was not really relevant to the architecture, and surely there are many books on straight math if the reader needed that. Some math is necessary, of course, for a 3D engine but the space could have been used for more important topics.

Not really a jab at the book so much as it is the author’s coding conventions, I really did not like his style. I realize this is somewhat of a holy-war with programmers, but I guess we all have a style that is comfortable for us. Personally I found the author’s style to be really obtuse, and made reading the code snippets more difficult. For example, for a camera’s forward vector, he would use something like:

m_pkFVec

Where “m_” was a member variable, “p” is a pointer, “k” is of a class type, and “FVec” for forward vector. Personally I would use simply:

forwardVector

Just glancing through the code, which one is more apparent to what it is? This really bothered me to no end, but I guess you can chock it up to personal taste.

All-in-all it may sound like I am putting down on this book, but I actually did find it useful in a lot of ways. Certainly if you are aiming to create a 3D game engine from scratch, you will need any and all the help you can get. So yes, still read this book. However, I had much higher expectations and I feel it was a missed opportunity for the author. While it is still a decent resource, this should not be your first stop in engine development.

So far I have mostly been talking about plans and theories, not much meat. Today I hope to remedy that with a discussion on main loops. Surely there are tons of different ways a main game loop can function, and I will explain a few of those methods. Keep in mind, I am still developing the architecture for this engine, so anything can change at this point. But this is, at least, the direction I am heading and hopefully it will prove useful as a learning exercise.

The first loop I am going to show is super basic, but should get the job done. Essentially it’s just a few global functions that get called in a while loop. For the sake of illustration I am leaving out the complexity of the Windows message pump you would have in a real application, but you get the idea.

while(running){
  handleInput();
  physicsTick();
  updatePlayer();
  processAI();
}

I will be honest. I have shipped more games than I care to admit with naive loops like seen above. Granted, for some simple games a loop like this can actually work OK. But what is wrong with it? Well first off, we have a bunch of global functions. Surely that can’t be good. I also don’t particularly like how the functions don’t seem to follow a standard naming convention, though this isn’t the end of the world. Also, as the game becomes bigger this list of functions can grow out of control. So while it might work, it’s not very pretty.

What I would like to have is some standard way of updating each of these systems, maybe with a function called “update()”. I think this would streamline everything and make it more clear what was happening. So to do this I will create an abstract interface class with a virtual “update()” function, like so:

class IUpdatable {
public:
  virtual void update(void) = 0;
};

Then we can define classes for each one of the game elements that need to be updated.

class InputHandler : public IUpdatable {
public:
  virtual void update(void){ DO_WORK };
};

class PhysicsWorld : public IUpdatable {
public:
  virtual void update(void){ DO_WORK };
};

class Player : public IUpdatable {
public:
  virtual void update(void){ DO_WORK };
};

class EnemyAI : public IUpdatable {
public:
  virtual void update(void){ DO_WORK };
};

Once that is setup, we’ll just need to create those elements somewhere above the loop in the same scope.

InputHandler input;
PhysicsWorld world;
Player player;
EnemyAI ai;

Finally we will call the respective “update()” functions from our revised main loop.

while(running){
  input.update();
  world.update();
  player.update();
  ai.update();
}

While this is certainly a lot better than before, it can still be improved. What I like is that all the elements are being called in a standard way, the code looks cleaner, and I have removed the global functions. What I don’t like is that it seems there is a lot of repetition calling “update()” four times in a row. Lets see how we can fix that.

One solution is to place those components in an array, and the use a for loop to cycle through the elements. We’ll see how to do that below.

IUpdatable* items[] = {&input, &world, &player, &ai};
int length = sizeof(items)/sizeof(IUpdatable);

Now that we have the pointers in an array, we can run our main loop much more compactly.

while(running){
  for(int i = 0; i < length; i++){
    items[i]->update();
  }
}

OK, this is certainly better but I’m still not sure I like it. While it does streamline the update process a bunch, and will definitely come in handy if you are updating dozens of elements, it’s still a bit rigid. Since it’s using an array, that means elements can’t be added or removed dynamically, which is a bummer. Lets see how the loop could be improved with a vector.

First we’ll have to initialize the vector from the same array we were using above.

vector updaters(items, items + length);
vector::iterator it;

Now the main loop becomes a little better, and more dynamic.

while(running){
  for(it = updaters.begin(); it != updaters.end(); ++it){
    (*it)->update();
  }
}

Still, we have a lot of variables in the global namespace and ideally we would want a class that can encapsulate this logic. We can do just that, and define an “Engine” class. For now it will just hold instances of our engine components, and have it’s own “update()” method. We’ll also want to define a “running()” function, rather than having this global Boolean value. Since this is similar to what’s already been shown, I’ll just post the code for the class below.

class Engine : public IUpdatable {
public:
  InputHandler input;
  PhysicsWorld world;
  Player player;
  EnemyAI ai;
  vector subsystems;
  vector::iterator it;

  Engine(){
    IUpdatable* parts[] = {&input, &world, &player, &ai};
    int length = sizeof(parts)/sizeof(IUpdatable);
    subsystems.assign(parts, parts + length);
  }

  virtual void update(void){
    for(it = subsystems.begin(); it != subsystems.end(); ++it){
      (*it)->update();
    }
  }

  bool running(void){
    return true;
  }
};

We can instantiate our class in the main function like so:

Engine engine;

Now here comes the beauty. Our main loop has been reduced to the following:

while(engine.running()){
  engine.update();
}

I think you will agree this is far more elegant than the previous attempts, and loads better than the original naive approach. The best part is that the updates can cascade down recursively just like in the Engine class. For example, the EnemyAI component could have a list of enemies that need their update functions called, etc. Seems to be like a robust solution to me. Of course in a real application there may be other things to handle (like I mentioned, the Windows message pump) but this covers the core of the logic. As I get further into creating this engine I will probably refine this architecture as needed, so don’t think this is the best a game loop can get. It’s just where I am at now, and I will continue to post updated code in future episodes of the series. Stay tuned.

So now we should have a good idea of why you’d want to create a 3D engine, and what kind of components make up the engine. Up next we will look at some of the tools and APIs necessary to actually compose the software. Keep in mind that the choices I am making are not necessarily the optimal choices for all situations. In fact, it may not be a good idea to follow this advice depending on what you are planning on doing. For me personally, this is mostly a learning exercise, so I want to mainly build up my skills. This means I may be taking the “scenic route” to (hopefully) completing this 3D game engine. If you want to follow me for the ride, maybe you will learn something too.

Programming Language and IDE

This is a no-brainer right here. I will be using C++ as the language of choice. By and large, C++ is the defacto standard for game development. While there may be some other languages that are becoming more popular on certain platforms (for example, on mobile), in the PC space it’s almost exclusively C++. Since one of the reasons for my building the game engine in the first place is to increase my skill-set, it makes absolute sense to use this language. It will also allow easier integration with different libraries and APIs, especially unique hardware devices which are almost always built for C++. And the performance will be better than some other options. There is no question here.

Specifically, I’d like to use C++11, since that is the latest standard. I learned a bit about the new features in C++ Primer, and I’d like to stay ahead of the curve and build the engine for the future. This also means I should probably be using Microsoft Visual Studio 2012. I think the Express edition should be fine for my needs, which is great because it’s free. Visual Studio is also probably the most popular IDE out there for professional software development, and I see no compelling reason to use any alternative.

Graphics API

For the graphics API, really the core of a 3D engine, there are only really two choices: OpenGL and DirectX. I am not going to try to argue whether one is better than the other, as I’m sure you can accomplish your vision with either. However, I will have to go with DirectX, again mostly because it’s the defacto standard. Nearly every AAA PC game is created with DirectX, and since I am trying to progress in this field I have no choice but to go with DirectX. I already have some experience with DirectX, at least version 9, so it makes more sense than learning OpenGL from scratch. While there is an argument for cross-platform support, this is not a priority for me at this point. Windows accounts for nearly 90% of the desktop market, there’s no good reason to not make this the main target platform. I develop on Windows, most PC gamers use Windows, it just makes sense. I can acknowledge that OS X and Linux are becoming more relevant, but I don’t personally use them so I am not going to go out of my way to code support.

The version I plan on using is DirectX 11. I have no desire to support Windows XP, since by the time I finish this project it will be largely irrelevant. I’d like to support the latest and greatest features, and that is just not happening on DirectX9. There is also a lot of good material on DirectX11, books, tutorials, etc. so I think it will be easier to pick up. Some of the features I am interested in are geometry shaders, compute shaders, and tessellation. So DirectX11 it is.

Audio Library

For sound I am still investigating options, but I am probably going to go with DirectSound. I am already engulfing myself in the Microsoft eco-system, it kind of makes sense. The main reason I chose this was because I am not a big fan of the licenses for other popular options. Some of the APIs I looked at were OpenAL and FMOD. FMOD costs a lot of money so that is off my list. OpenAL looks interesting (and I am still considering it), but I am uneasy about licensing. Basically, I want my 3D game engine to be 100% my ownership and my original code, with no strings attached. For example, if I decide to sell this one day as a commercial engine, I would like to have that option. I don’t want to have to pay anyone, or give them a cut of my profits, or have to release the source code, or any of those things. I’m not attempting to do anything fancy with audio, so I think DirectSound will suffice.

Input Library

Honestly haven’t given this one too much thought, but I could probably make do with the default Windows messaging for mouse and keyboard, and use XInput for game controllers. I also plan to support some more unique controllers like the Razer Hydra, but I would need to integrate their SDK directly anyway. I have used OIS a little, since it comes with OGRE, but I am not sure if this is really needed. Will see how far I can get just with the basic Windows messages for the time being.

Physics Library

Here is another area I am still debating. Previously I was set on using Nvidia PhysX, since I thought that would allow for the best performance. The applications I am aiming to write with this engine are seriously physics intensive. Probably more intensive than has ever been attempted in real-time. So I need a high-performance physics engine. I’d even be willing to dedicate a top of the line Nvidia card (like a GTX 680) just for PhysX alone. Most people would call this overkill, but I ask: is it enough? However, after looking carefully at the PhysX license I started to wonder if this would be the best option. I don’t like how Nvidia has to approve your application, I don’t like having to have logos and splash-screens all over the place, I don’t like the cost for platforms other than Windows. While none of these things are total deal-breakers, they do give me pause for thought. Plus the fact that it won’t run at full speed on AMD hardware is a major turn-off.

Another option is Bullet, which seems to be pretty mature and is free/open-source. They claim that their GPU-accelerated solver is “coming soon” but what does that even mean? It also doesn’t really instill confidence when their website homepage has only been updated twice in the past year. I mean, I’m just one guy and I can manage to post a new blog post at least once a week. You’d expect a whole team to be able to do better. Granted, the software itself appears pretty robust and I like the way it looks. Everything has a solid feel to it and animates well, not “floaty” like you see sometimes. I guess this could come down to the specific parameters, but the Bullet demos did impress me.

I am most interested in fluid dynamics and cloth simulation. I’ve seen demos of both, but I am not sure anything out-of-box does what I need. I am entertaining the idea of rolling my own physics engine, which I think would be a lot of fun. I have written physics engines before, but only in 2D. I know the step to 3D adds complexity, but I think the task is within reason. At least if I wrote it myself I could concentrate on the aspects I need the most, which seem lacking in most current video games. Since I am looking for the best performance, I’d like to code this on the GPU. I also want something that runs equally on Nvidia or AMD hardware, so I am looking squarely at DirectCompute. I know I am probably looking like the biggest Microsoft fanboy right now, but I don’t think that’s a bad thing. Microsoft has done a great service by creating all these awesome APIs and releasing them for free to developers. I do realize I am opening a can of worms with a custom physics engine, but I am really liking the idea of not using any 3rd party libraries (aside from what Microsoft provides).

Everything Else

A 3D game engine does include a lot more stuff than you get just cobbling together a few libraries, so I don’t want to gloss over this too much.  Of course, I still need to architect the structure of the engine, but that’s a given. Understandably there may be other small libraries I’d like to integrate, like for decompressing a zip file or whatever. So I am open to using external code provided I can still retain 100% ownership of the product. Though since this is mainly a learning exercise anyway, I’d like to do as much as I can myself. I can already tell that most people (maybe you) would think this is an impossible task for one person. You may be right. Maybe after doing some tests I will find that I’ll need to license an audio engine, or that I’m in over my head coding a custom physics engine. Sure, that’s fine. But even in trying and failing I think I would have learned more than never having tried at all.

Last time I recommended some good books for engine creation. Today I will talk a little bit more about what an engine actually is, since it’s rather silly to try to create something that is undefined. What I am defining a 3D game engine as is “a framework or set of tools that abstracts complexity and enables creation of real-time 3D experiences.”  It’s important that it deals with “a framework or set of tools” and not just a single tool. Obviously artists might use an image editor to create a texture, but we wouldn’t consider Photoshop to be part of a game engine. However we may have a standalone tool, let’s say a light-mapper, that works in conjunction with the 3D engine. In this case, we may count the tool as part of the engine. One key point is that the 3D game engine should “abstract complexity” and allow for more rapid development than otherwise possible. The whole point of using a game engine in the first place is to make common actions easier and quicker to do. It’s also important that you are not limited to creating games, although I would still call it a “game engine” since that is common terminology. The same engine could be used for virtual reality, or simulations, or data visualizations, or any number of non-gaming applications. The engine could even be used for non-interactive experiences (for example: machinima) but it would still need to be real-time in nature. Clearly a video player would not constitute an engine. So now that we have a clear, if not somewhat broad, definition of an engine, whats next?

Well a lot of people (including myself) would like to say they created their 3D game engine “from scratch.” Now what does that mean exactly? Does it mean not using any 3rd party libraries? How far will you go with this is? I mean, does the C++ standard library apply here? Are you going to re-implement the STL? Write your own C compiler? Clearly this is too far. Unless you are creating your own programming language and compiler in straight machine-code, then you are going to be using someone else’s work somehow. There is no shame here. To make a good high-level application, like a video game, you will need to use a variety of low-level functions that you may not want to code all from scratch. This is a given. Especially if you actually want to have a working application finished within your life-time. Obviously you would be using an API like OpenGL or DirectX. There’s no glory in re-inventing the wheel here. While you could write your own physics engine (and some developers do), there are a number of decent solutions available. There also probably isn’t a big need to write your own PNG decompressor. That’s fine, but I still haven’t explained what “from scratch” means. What I would call “from scratch” is something that started as a blank text file, and that was slowly built up over time to have more features. I think this is fair. Even if 3rd party libraries were integrated, I don’t think this takes away from your original code. It’s still “your creation.”

So I defined my 3D game engine as a “framework,” but what exactly does that entail? Though not exhaustive, some of the things I would expect from this engine are:

  • Input processing. Reading state from keyboard, mouse, controller, etc. and exposing a high-level interface (like an action-map).
  • A graphical representation of a 3D environment. For example, to be able to set positions and orientations of objects in space, and draw them onto the screen.
  • A audio system. Being able to play ambient background music, or one-off sound effects.
  • A math library for 3D gaming: vector, matrix, quaternion, collision, intersection, AABB, etc.
  • An animation and physics system. The ability to animate objects, either due to dynamic interaction or through scripted animation.
  • An event system, which would allow entities to fire events and other entities to listen for events and respond accordingly.
  • File management, loading resources, streaming assets, saving configuration, etc.
  • A scripting system, that allows for rapid iteration and prototyping without recompiling the application.
  • An editor that simplifies scene creation, connecting scripts, parameter setting, asset management and other authoring actions.
  • A state machine, that lets objects to have different states. Useful for GUI, AI, etc.
  • Possibly networking, if the game is multiplayer.

While this list is not going to include every single element of a 3D game engine, I think I have touched on the most important sub-systems of the framework. Certainly, this is no small task. I realize that there is a long road ahead of me (and I hope you do too, since you’re reading this). I’m aiming to spend about 2 years to make this happen. Granted, I hope to have a MVP (minimum viable product) up and running in a much shorter time-frame, lets say 6 months. But I understand that these things can take time, especially for a lone coder. But I think it will happen. No, it will happen. I will make it happen.

With the first part of this series I have listed a few motivating reasons for developing a 3D game engine in the first place. In this next part I will go deeper into some of the research I have been doing for amassing the skills I feel are necessary to actually complete a project like this. As I have mentioned, one of the core reasons I am working on this engine is for knowledge building and personal development. Researching computer graphics plays a huge part in this. So I’d like to share some of the books I have been reading in the past year or so in preparation for creating my dream engine.

Real-Time Rendering

Real-Time Rendering, Third Edition (Tomas Akenine-Moller, et al): This is one of the best books I have read so far on real-time graphics for gaming. There are a lot of equations, but they are usually explained well. However, there is not a lot of code here to just straight copy-and-paste. It’s not a cookbook. It’s really more of a 1000 foot view of gaming and real-time technology. It talks about all the different lighting and shading models currently used, discusses texturing, collision detection, intersection methods, image-based effects, 3D math for gaming, etc. Really a great overview of the types of things a 3D engine has to handle. As mentioned, it’s not a cookbook. There is very little code, if at all. But I found this to give a helpful glance at a lot of topics of interest, of course with sources to find more detailed information. Highly recommended.

GamEngineArch

Game Engine Architecture (Jason Gregory): This is another amazing text. It talks about all the things that go into building a professional game and game engine. So 3D math is covered, as well as version control tools, fundamentals of coding in C++ (with cool tricks like memory alignment), main loops for rendering and game logic, debugging, character animation, collision and physics, and more. I found this book very insightful and actually made some of the topics listed a lot more understandable. I was especially surprised by some examples of main loops, as they were a lot more straight-forward than I previously thought. If you are attempting to code your own engine, this book should certainly be on the list.

Game Coding Complete

Game Coding Complete, Fourth Edition (Mike McShaffry): All I can say about this book is “Wow!”. There is an unbelievable amount of knowledge in these pages. This is the book I am currently reading, about 25% through so far, and I have already learned a bunch. This is another 1000 foot view, but they ground it with some really useful snippets of code. They give examples of different main/game loops, actor and component architecture, an event system, loading and caching resources, DirectX, scripting in LUA, collision, physics, creating an editor in C#, even network programming. This book is amazing! I’m not even finished yet and already I feel like I have learned so much. This is a must read.

3D Math Primer

3D Math Primer for Graphics and Game Development, 2nd Edition (Fletcher Dunn): I actually read the first edition, but I’m sure the updated text is just as good or better. It’s a book on 3D math for games. Certainly this is the type of book that’s great for foundation learning. Creating a good 3D engine will require a deep understanding of this type of math (mostly linear algebra) and this is a great book to get you started. Even though a lot of the equations are dense, I found the writing style to be approachable. It talks about all the stuff you would expect: vectors, matrices, orientation, transformations, etc. I would also recommend this book.

3D Game Programming

Introduction to 3D Game Programming with DirectX 11 (Frank Luna): This is one for my wishlist. I have read the older edition on DirectX 9.0c, but haven’t got around to this latest version. However, the series is one of the most recommended and highest rated books on the DirectX API. Luna’s writting style is very clear, and there is a lot of ground covered in the book. 3D math, drawing basic primatives,  texture mapping, lighting, shadowing, normal/parallax mapping, ambient occlusion, etc. I like the little things that make the demo apps very polished (like being able to switch between windowed and full-screen with the touch of a button). If you plan to use the DirectX API for your engine, then this book is an absolute must.

C++ Primer

C++ Primer (5th Edition) (Stanley B. Lippman): Although I have been learning and working with C++ for years, I read this book recently and ended up learning a lot. Keep in mind this book covers the new C++11 standard, though most of the discussion still applies to the previous standard. This is, hands down, the most comprehensive book I’ve seen on C++. Most books teach you the basics, but fail to explain the intricacies of the language. Not here. The author goes deep and shows you everything you need to know (and more). I also liked that he kept the code samples short and to the point. There is not even one sample that you are expected to type in and test. If there was, the book would probably be twice as long (and it’s already pretty long at 1000+ pages). Rather the author chose to highlight relevant structures and algorithms with as little code possible. I found this method to be very effective. If you are just starting out with C++ then I would recommend reading C++ Primer Plus first. However, if you already know some C++ and just want to brush up on your skills, this is a great resource.

Of course, I’m not going to list every book I’ve ever read on programming. These are just a few recent ones that I found useful. I will continue to post links to new books and other material that help me get closer to completing my 3D game engine. Even reading these books, there is still a lot of knowledge that can only be found by doing, and I hope future posts in this series will address that. After I get a better idea of the architecture of the engine, I can post some simple samples for review and for performance testing. Again, this is a learning process for me, so I would love to hear feedback from the community of this. Don’t be shy.

This is the first part in, what I hope to be, a long running series of articles about creating a 3D game engine. Just to be completely honest, I have never created a 3D engine before. Granted, I have worked on many games but usually in the casual and social space (read: 2D). However, I do have some years experience using other people’s 3D engines as a hobbyist. So I’m not a complete noob, far from it. But this is very much a learning process for me. I hope to detail this process, mistakes and all, in a series of articles. At the end, hopefully I will have a fully functional 3D game engine. In the process, I will log basically all the steps needed to create said engine. Maybe eventually these notes could be the basis of a book. Who knows? I think the information will be valuable, and I hope it will prove helpful to other people walking this path.

So the big question is: why would you want to create yet another 3D engine?

That is actually a good question. Before you embark on a (potentially long) journey of creating your own engine, you probably want a good reason to do so. There are tons of engines out there, some even free, and many of them will be suitable for a variety of projects. This is true. There is also the advice that says “make games, not engines.” This is also sound advice for most people. Especially if you are on a deadline from school or a client, it makes absolutely no sense to waste time building an engine. Just make the game, and finish the project. Get your grade, or get paid.

For me, however, I’d like to learn exactly what goes into a 3D engine, as I feel this knowledge will be very useful. Even if I, ultimately, end up using a pre-existing engine. So knowledge is a big part of this. I don’t mind if my engine takes years to complete. I don’t expect it to compete with the big commercial engines. I just want something I can use for my own little projects and demos, and that I have absolute full control over.

Another aspect is limitation with current options. Many of these “all-in-one” game engines will get you 90% of the way there but you will struggle and twist the engine to get that last 10%. In some cases, you will encounter show-stopping bugs that you just have no way of fixing without the source code. In other cases it just means you have to “dial back” your vision to get things working. Some engines have restrictive licenses, or complex revenue sharing models that I’d like to avoid. Some of them are just too darn expensive (I guess this is a financial limitation more than anything). Some 3D engines look great, at first, but don’t include the types of things you would need to complete a game (like a proper level editor). There are lots of reasons to be dissatisfied with the popular options out there.

More concretely, I’d like to explore how using virtual reality can aid in the game development process. So some features that I consider requirements simply aren’t available today. For example, full stereoscopic 3D rendering not only in-game, but also inside the editor. Supporting 6DOF (degrees of freedom) motion controllers to place and orient objects, again, in the editor. Intuitive 3D model editing and texturing, no external content creation tool needed. Motion capture tools built straight into the engine, so you could literally animate a character in real-time as you play the game and save those animations out. I know this all sounds very “blue sky” but these are things within the realm of possibility. I believe it can be done, and this is a motivating factor for me. Maybe your vision is different, but I think this series could be helpful none-the-less.

I’d really love feedback on how I’m doing, or topics that you might be interested to have me cover. Remember, this is as much a learning experience for me as it will be for you. Surely mistakes will be made, just post a comment and correct me, or post a fix for the problem. I really have high hopes for this series, and I want this to be as much of an interactive experience as possible. So keep reading, have fun, and let me know what you think. Thanks.