For quite some time I have been waiting for a good data-glove to hit the market for use with virtual reality applications. So far the only consumer product that has come remotely close was the P5 glove, which was probably one of the biggest disappointments in my life. Although better data-gloves have existed since the 90’s, they have been so expensive to only be attainable by large corporations or the government. So with nothing really available off-the-shelf, I have decided to build my own.

Virtual Reality cannot really be had using archaic input devices like the keyboard and the mouse. While fine for web-browsing, they just don’t cut it for immersive interactive 3D  experiences. Tracking hand and finger movements just seem like a very intuitive way to interact with a virtual world. Although there are devices, like the Razer Hydra, that capture some of these elements, it’s just not the VR I dreamed of as a kid if you don’t don the gloves.

Currently I am evaluating good orientation trackers (rather, an inertial measurement unit or IMU). I found the Pololu MinIMU-9 v2 and it seems to fit the bill. The price, at $40, is not too shabby either. It does not come with a USB interface or anything fancy like that, so I had to solder some connections myself and use an Arduino to interface with the PC. Even so, the package is not bad at all. As you can see in the video, the tracking is decent. Maybe not the best I have ever seen, but certainly workable. I’m pretty sure it’s giving better performance than the Hillcrest Labs unit I was previously using, but it’s hard to say just by looking at a quick demo. Anyway, I’m happy with my $40 dollars.

Next up I will be looking at flex sensors to track finger movement. These ones from Spectra Symbol look nice and were supposedly used in the Nintendo PowerGlove (which could be bad or good depending on how you look at it). Hopefully those sensors won’t be too hard to get running, as it would be very convenient to grab parts like these off the shelf. Especially if I want to post the instructions online so other people can build their own.

Finally I will need to construct a proper positional tracking system so physical movement will be mirrored in the simulation. I have a couple of ideas for this, though I still have a lot to experiment with. Stay tuned.

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.

The Oculus Rift is great and all, but it still feels pretty constricting using VR sitting in a chair. The Virtuix Omni plans to change that. Commonly referred to as omni-directional treadmills, the Omni allows you to feel like you are walking, or even running, around a virtual space while in real-life you stay safely in the same spot. This project in particular is a passive device, with no moving parts, which means it could be provided for cheaper and in a smaller package than otherwise possible. The Kickstarter to slated to go live June 4th and I will, no doubt, be one of the first in line. Now all we need is cheap wireless data-gloves and I’ll be all set.

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.