Game Development Middleware - What is it? Do I need it?

This is a companion text blog to the video blog that will  be released on Channel 9 next week. I wanted to also make this information available for search engines to pick up. I'll update this blog with a link to the video as soon as it is published.

I’ve been a direct to DirectX purest for most of my career but lately I have been changing my tune. I was given the opportunity to take a close look at the state of DirectX middleware projects. Honestly I was very impressed. In response to these eye opening revelations I felt it necessary to let people know that there are some really great alternatives to just coding directly to the DirectX APIs.

So in this blog I am going to talk with you about game middleware. What it is and why you might need it. Keep in mind that what we are going to talk about today applies to both Windows Phone and Windows Store apps.

Now comes the disclaimer part. There is no right or wrong answer when it comes to choosing middleware. I’m going to offer some of my personal opinions but don’t let that stop you from looking at all your options. There are a lot of great solutions out there, so shop around and choose one that is right for you. If you have a favorite solution that I don’t mention here make sure to add it to the comments so that others can check it out. And to be, clear just because I mention 3rd party solutions this doesn’t mean that I am officially endorsing of any of them (except maybe DXTK).

I’m going to break down the middleware options out there into two buckets, frameworks or toolkits (we’ll use those terms interchangeably) and game engines. Keep in mind that there are a lot of subtle variations in the game middleware market but for our purposes these two buckets will help us get the conversation started.

Typically when you think about game programming for the Microsoft platforms you think DirectX or Direct3D. The DirectX technologies are certainly at the core of all of Microsoft’s platforms. The “problem” with writing your game using nothing more than the raw DirectX APIs is that you will likely be spending  a lot of your time wrestling with the APIs. Game frameworks or toolkits and game engines do a lot of the coding grunt work for you so you don’t have to.

Don’t get me wrong there is certainly a time and place for coding directly to the DirextX APIs. If you are working on a large game and you know that you are going to need to eek every ounce of performance out of the game that you can, then optimizing your code by going directly to the low level DirectX APIs is the way to go. However, if you and your friends are coding out of your garage trying to create the next “flappy something” you might want to consider alternatives.

Game frameworks are a great alternative. They let you do most everything that you can using the DirectX APIs directly but most of the time you only have to write a fraction of the code. Game frameworks typically wrap the low level DirectX APIs using higher level constructs. For example for me using the DirectX APIs to load a mesh can be a complex task. A good framework or toolkit will just take the file name of your mesh and do what needs to be done to load, turn it into a useable DirectX construct and hand it back to you. No need to write file I/O code or worry about buffer creation.

Some game frameworks offer high level coding constructs but still give you access to the full power of the underlying DirectX APIs. So if you need to tweak something at a lower level you can but still offer the continence of high level constructs.

Other game frameworks offer different language options. Officially we, that is Microsoft, only support calling DirectX APIs from C++ code. This tends to make the barrier for entry pretty high as C++ is not the easiest language to master and certainly not the most forgiving. So choosing a framework that gives you a managed language option might be just what you need.

Game engines are a little different. Game engines offer a platform that you use to build your game. Some game engines are specific to a type of game-play such as FPS or Tower Defense. Other game engines are more generic offering a broad platform and plug-ins that allow you to develop just about any type of game. Game engines tend to incorporate all of the features that you might need to create your game like physics simulations, mesh conversions and some even offer AI. Instead of cannibalizing 3rd party libraries and trying to shoehorn them into your app, the integration is already done for you.

One of the problems I’ve seen with game engines is that they tend to abstract you so far from the underlying DirectX APIs that you don’t always know why something is happening. This can be particularly frustrating if you are trying to track down a shader bug in your pipeline. The DirectX debugging tools in Visual Studio 2013 are absolutely amazing and allow you to spy on every pixel in your scene (the subject of a future video blog). Not all game engines offer these types of extremely helpful tools.

When using some of the large game engines like Unity or Unreal Engine the first thing you will notice is that there is no code anywhere in the main UI. Most game engines of this scale are very visual. The idea here is that you get all of your assets (I.e. characters, levels, lighting, etc.) setup visually rather than procedurally in code. This allows designers and not coders to get everything setup. You then wire everything together in code.

Here are some other things you might want to consider when deciding on your game middleware solution: Think about the level of support you are going to get from the owners or maintainers of the game engine. Is there good training and sample code available to get you started quickly? If you do run into a problem is there someone you can talk to?

Personally I’ve become a game engine convert in recent months but there is still something to be said for the power and control of procedurally coding your entire scene. So again, investigate your options I’m sure there is a game middleware solution out there that is just right for you.