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.

Direct Compute Lecture

Well I know this is kind of old, but I am just discovering it and it seems like a good resource. It’s basically a series of videos put together by Microsoft to explain their DirectCompute API. If you’re not familiar with DirectCompute, it’s an API that allows you to write general purpose algorithms and run them on the GPU. Since the GPU is massively parallel, certain algorithms can run orders of magnitude faster than on the CPU.

Currently I am trying to evaluate if DirectCompute is a good option for building a GPU accelerated physics engine. So far I have watched the first 3 lectures, and it appears to be helpful. If you are interested in leveraging DirectCompute in your applications, you should definitely check out this series.

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.

Among The Sleep

Seems like Kickstarter is just churning out hits lately, and this project could be the next success. It’s an original horror game where you play as a two year old boy. The early prototype videos look compelling, and I like that they are attempting a different theme with the title. Should be awesome, but they still have a ways before meeting their goal. So, if possible, please pledge your support for this game on Kickstarter. Also, rumor has it that the developers are interested in supporting the Oculus Rift. That would just be awesome if that happened. So, yeah, please back this project. Thanks.

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.

Unity 3x Essentials

I’ve been keeping tabs on Unity since back when it was a Mac only thing, and it sure has come a long way over the years. Even though I have downloaded and toyed with the program before, I hadn’t took the time to read a proper book on the engine. Now that I am having to work with Unity more for the job, I figured it was a good time to brush up on some knowledge. Although there are tons of Unity books out there, Unity 3.x Game Development Essentials seemed to have good reviews, and the price was right (only $16 for the Kindle e-book).

The book basically walks you through creating a dirt simple “game”, that you build up throughout the reading. Only the first chapter has a standalone demo to get your feet wet, the rest of the book is all one project. I found this format to work nicely, as you can concentrate on one aspect of the game design during each chapter but feel more accomplished as you built up the game. It covers creating a terrain, setting up a player controller, importing models, creating a GUI, collision detection, basic scripting to trigger events, and basically everything you would need for a simple demo. Although the game you build will not win any awards, it is functional and teaches some fundamental concepts.

What I will say is that the author did a bang-up job with the source code listings. There are tons of code snippets throughout the book and I found only one, yes one, mistake out of the whole thing. And, even then, it was a minor variable misnaming. Nothing major. This was a refreshing surprise, as many programming books are riddled with errors and non-compiling code. Bravo for that.

In general, though, I found this to be a very approachable book, even for a beginner. Of course, development experience doesn’t hurt, but it’s really not required for this text. The author clearly explains everything that is taught in the book and only at the end is some code glossed over (since it was already covered). I also liked how all the code is shown in both C# and Javascript, so the choice of language is up to the reader. Very nice.

The greatest part, I would say, is how far you can go with Unity itself in little time. I read this book in just one week and feel like I have covered more ground than I have with other engines spending *far* more time learning. So that just goes to show how solid the engine is. It’s not so much about the graphics of the engine, as it doesn’t really look any better than anything else out there. However the editor is very functional and very efficient. Especially nice is how you can create references to objects in the editor, greatly simplifying communication between different components. Overall I found it to be a great learning experience.

If you are just starting out with game development then this book is a great resource for learning the Unity engine. If you are already a developer but not familiar with Unity, this is also a great text. Granted, its not a very advanced book, so if you are already using Unity you can probably pass on it. That said, the book was very affordable and well worth the money in my opinion.

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.

So I’ve decided to start blogging again! For any loyal readers, you might have noticed it’s been nearly 5 years since my last post. A lot has happened in that time, and I think I’m finally ready to grab the controls again.

This time I will be focusing more on my personal projects and general musings on topics of interest, and not so much trying to post about all the latest gadgets (though there might be some of that too). Mostly I want to focus on virtual reality and the related hardware and software needed to attain that dream.

I also hope to post source code and maybe some tutorials on 3D graphics and gaming and all that good stuff. Anyway, thanks for coming to my blog and don’t be afraid to comment if you have anything to share.