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.

Practical Rendering

I was thoroughly impressed by Practical Rendering and Computation with Direct3D 11 by Jason Zink. Microsoft’s Direct3D API is certainly not for beginners, and neither is this book. But, at the same time, the author does a great job of explaining the material in a way that is approachable. The book assumes you are already comfortable with C++, and doesn’t hold your hand with the syntax. This is great, since you really should have an understanding of C++ before jumping into 3D graphics programming. It’s also not the kind of book that expects you to type in long pages of example code into your computer. In fact, there are not really any complete examples listed in the book at all. Instead the author chooses to highlight specific API calls and explain how different techniques can be implemented using the GPU.

This is in stark contrast to the last DirectX 11 book I read by Frank Luna. Luna’s text was great, don’t get me wrong. But it was very focused on producing functional demos to showcase certain effects (like shadow mapping or ambient occlusion). Instead Zink chooses to go totally knee-deep into the API itself and, as a reader, I came away much more confident that I understood the material. Just as an example, early on in the book there is a 100 page chapter just on resources. Most other tutorials would briefly show how to create a buffer, and then move on other stuff. Not here. In fact, the next 200 pages of the book is just about how the pipeline works. It’s really great, and rare to find such insight.

Don’t be fooled, there is certainly code in these pages, and there are a few examples. The book covers some topics like deferred rendering, multi-threaded graphics, dynamic tessellation, and physics. What I liked about the examples is that only the bare minimum amount of code was shown. Just enough to understand the key concepts without getting bogged down with boiler-plate code. It also made reading along much nicer, without having to feel like you need to get up every 5 minutes and type something in on a PC. Plus, the source code for the examples, and the author’s engine, are available for free online. So no need to type either way.

One thing I really enjoyed was the discussion on DirectCompute and on compute shaders. There are hardly any books covering DirectCompute, so it’s great to see so much space dedicated to the API. I am very interested in using this in my own engine, though it’s difficult to find information on the topic. Practical Rendering and Computation includes several chapters using compute shaders, for example to do image processing (blur). There was also a good amount of space given for tessellation. So if you are at all interested in these specific topics, it’s pretty much a no-brainer to get this book.

One other thing. Mad props to Jason Zink for being available to the community. You’ll find him on the gamedev.net forums, even helping out newbies with their 3D questions. Much respect.

All-in-all, this was quite an eye-opening read. I mean, after reading the Luna book and doing some online tutorials, I thought I knew about DirectX 11. Well, I knew something. But this book went much further than what I had previously seen on the topic. I would even recommend reading this *before* Frank Luna’s book, as I think that would flow a little better. Get the foundation solid, and then start learning how to code specific effects. Anyway, this book comes highly recommended by me if you are attempting to learn Direct3D.

3D Game Programming

Frank Luna’s DirectX series has been the go to book for DirectX development for many years. Although there are other great resources, Luna’s writing is both informative and approachable. The book also covers a broad range of topics from the basic lighting, texturing, and blending, to terrain rendering, normal and displacement mapping, geometry and compute shaders and more. He even tackles some tough topics like shadow mapping and ambient occlusion in a way that is understandable. Overall a lot of good material in a package that’s a bit under 900 pages.

The book assumes you have some knowledge of graphics and C++ programming, though it does go over some of the basics at the beginning. So you don’t need to be a graphics wizard to read this book, but you should at least have a firm grasp of C++ and some idea about 3D mathematics. Though you don’t need previous knowledge of DirectX. I had some experience with DirectX 9 going in, and I was still surprised about some of the changes with DirectX 11. Although the basic concepts are the same (using vertex and index buffers, for example), the code to accomplish things were very different in places.  That said, Luna’s style made even some of the denser code snippets manageable.

Luckily, the included samples did compile with only minor changes to the project properties. I purchased the Kindle e-book, but was able to download the samples from the website. Although I enjoyed the e-book, I will make note that many of the code snippets didn’t look great on the device. This is a common problem with programming books on the Kindle, where code that should be on one line spans multiple lines and makes a mess of the original print formatting. Unfortunately this book is not much better in that regard. Even so, I was still able to follow the code. I just wish more care would be taken with the formatting.

All in all, a great resource and should not be missed if you plan on writing a game or engine with DirectX 11.

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.

Game Coding Complete

Finally, I’ve got around to reading (and finishing) Game Coding Complete, and it’s up there on the list of great game development resources. I’d been meaning to read this book for quite some time, but got distracted with DirectX and Windows hooking for use with my 3D driver. Now that I’m back on the 3D engine kick, it seems like a good time to hit this book. Reading through this, I was thoroughly impressed by the content and the writing style. Don’t be discouraged by the lengthy size, this text is well worth the time to read.

The authors, both seasoned game developers, working on the Ultima series and various Sims games, have a lot of collective knowledge and it comes through in the book. There are a lot of snippets and stories about things the went right (or wrong) on the production of some of the games they worked on. I found these insights to be refreshing, and certainly interesting to read about. It also helps to teach people what professional game development is like, and things to expect if you are looking for a job in the industry.

Aside from the stories, there is a lot of topics covered in the book. They go over game loops, component architecture, process system, an event system, 3D math, DirectX, audio, collision and physics, scripting with Lua, AI, a game editor in C#, debugging, version control, multi-threading, etc. Really almost everything you would need to know. They weren’t joking when they said “Complete.” Although the book is long, it’s really amazing what they managed to cram in there. Granted, most topics only get one chapter, which isn’t really enough to fully cover everything. But it’s a great overview on a ton of stuff.

I found the coverage of the event and process system to be every insightful, and I will probably be using a variation of these in my own engine. The event system basically allows different objects to fire events at key points, and then have other objects respond without tight coupling. The process system allows objects to spawn logic loops, that will be updated along with the rest of the engine. So, for example, the player can hit a key to throw a grenade. That would fire an event, which would spawn a grenade with the proper velocity. The grenade itself would have a process, that would count down a few seconds and then explode. At the time of explosion, this could fire another event, which would then cause the audio system to play a sound and the particle engine to create a visual effect. This is a very clean way of handling events and processes, and this is probably the single more useful thing I found in the text.

If you are looking at creating your own game or engine, or just want to see what goes into a commercial title, Game Coding Complete may be one of the best resources to do so. While there is a good amount of C++ code in the book, it is not so much of a “cookbook”, it is more of an overview of architecture. The writing style is casual and friendly, and I really love all the stories told throughout the book. This is a great resource, and should not be missed. My only regret is that I did not read this book sooner. Highly recommended.

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.