Pros and Cons of Middleware

Coding

Whether you're a high end game maker working on a multi million dollar project, or an indie developer making a game for fun, you'd be very wise to consider what 3rd party systems you can leverage to save you time. Spending a little time to investigate what systems you can use could save you months or years of development effort.
High end commercial projects often license non-cheap systems for rendering, physics, sound etc (e.g. Renderware, Havok, Miles), while indie developers can use cheap or free systems like Ogre, Newton and OpenAL. Both at work and at home I like to look at the different systems out there just to know what's going on.
There are pros and cons to consider. Here are a few of the main ones which would face an indie developer:

Pros
1. Save LOTS of development time!
Taking the example of a rendering engine such as Ogre or Irrlicht. Using a system such as this usually gives you a well thought through and efficient system, which comes with advanced features like exporters, viewers, example code etc. If you attempt to build this yourself will take you far longer than it would to integrate and learn another system, and you'd also unlikely reach the same level of features.

2. Systems are debugged well due to the number of users.
Because open source systems have a lot of users, they tend to be pretty well debugged. The users will be developing in different operating systems, with different compilers, and different hardware. In terms of rendering engines, it's great news if you can be confident from day one that your rendering code has been tested on a broad range of hardware. Also note that the source will normally have a 'stable' branch, and a 'development' branch. The stable branch just gets bug fixes. The riskier new features go in the development branch.

3. You can use features you wouldn't otherwise use.
Engines often come with advanced features which can be easily 'turned on'. It can be trivial to turn on features like audio echo, stencil buffered shadows, full screen 'HDR blooming', etc. You may not have initially planned to need these features, but they can greatly enhance your game with very little effort.

4. Joining a community of developers.
All commonly used engines tend to have a wiki and/or forums to help you use the system. It's even more rewarding when you start to write your own wiki pages and help people in the forums. When you look back at a wiki page you wrote and see that several thousand people have read it and been helped along, it's a real buzz.

Cons
1. Reading licenses
Not so much a Con, but something you'll need to cope with. Each library comes with a license. This might say "do what you want with it", or it might say "don't modify it, and use it only as a DLL", or "You need to show our logo when the game starts" etc. The slightly annoying thing is that they're written in legaleese and distilling the meaning and looking for gotchas can give you a headache. Also look out for one system using another system, and you needing to read the licenses for the subsystems too. Examples of this are a rendering system using someone elses XML reader or true type font renderer. All this said, if you're just doing demos for your own ammusement, then you can usually just ignore the licenses (though that's not legal advice:)

2. Getting things working can be tricky.
Sometimes you get lucky, and sometimes you end up pulling your hair out. Installing all the right downloads to the right places, getting the right versions of everything, setting up project settings, and deciphering wierd crash bugs can be part of the territory when trying to get the first version working. That said, even if it takes you a couple of weeks to make it happy, you're still likely to be well ahead compared with writing it all yourself.

3. It may not do exactly what you want.
Third party systems, including commercial ones, will often 'like to do things a certain way', or more specifically 'make it really hard to do certain things'. When faced with something like this, either make sure that the system has the feature before you get too attached to it, or be ready to bend your requirements to fit better with what the system is capable of doing. For example, you might want to use Milkshape to build your models, but the system only comes with a Blender exporter - you could either change your choice of render system, join in with the development effort and make the new exporter, or just suck it up and learn the new program...

4. Getting new versions can be a pain.
Generally it's best if you get a version which works well enough for what you need, and then stick with it until you're done. Unfortunately you'll often need to upgrade. This can bring with it problems like needing to upgrade compiler, your data files being of an old format, the API changing, and new bugs being introduced. If the system has sensible people at the helm, these problems will be minimized by ownership of the system staying constant, version numbering which makes it clear whether to expect API changes, seperate branches for stable and release builds.

Tips for Choosing Systems
1. Get recommendations from friends/sources you trust.
2. Download the samples and try writing a simple demo / playing around with it before diving in and integrating it with your code.
3. You could use web traffic monitoring information to gauge how many users a system has. If, for example, Google Analytics shows low traffic, then it might mean that it's not a very popular system. Though that said, a system might get a lot of traffic if everyone is having trouble with it :)

This is quite an interesting topic, and I've only managed to unevenly scratch the surface here. I'll return to this topic in the future, and also detail some experiences with specific systems. (To avoid any legal issues, I'll talk mostly about non-commercial products)

Experimental Gameplay Competition

There's a website called www.experimentalgameplay.com which encourages people to create quick prototypes of games for fun.

I recently had the pleasure of working with the Experimental Gameplay guys to run a competition to win a summer internship at Heavy Iron. The contestants had about two weeks to make a game based on the theme of "Consumption". Sixteen people submitted games, and from these people we chose two interns for summer internships.

I really enjoyed being involved. The games were great fun to play and the winners are really looking forward to starting. Hopefully we'll be able to do the competition again next year.

I recommend checking out what the experimental gameplay site and playing some of the games there. One important thing that the games demonstrate is that you don't need to have a team of 50 people working for six months to work out whether something is going to be fun. There are some lessons in this for large and small developers.

Experiences with Visual Studio Express

A programmers choice of development environment often ranks slightly higher than religion and politics in the list of things which they're fanatical about. Recently I needed to upgrade my version of Visual Studio.

Last November, Microsoft released Visual Studio Express. The name always confuses me, I always want to add .NET 8 2005 to the end, just to be clear. It's a trimmed down version of each of their Visual Studio packages. First of all they said that it was going to be free for a year, but they recently changed their minds and made it free all the time (announcement).

For professional games development, for Xbox[360] and tools, we use the professional edition of Visual C++. This costs around $500 per seat, and so for playing around at home I decided to try out the express edition.

Previous to Express, I was using Visual C++ Professional 6.0. There are lots of enhancements that they've done here and there which I knew would make things better, but I was also worried about dropping from professional to express. I've now made the switch, and the main things I've noticed are as follows:

• First of all, it all feels very familiar to what I was used to with version 6.
  
• While you're editing text, it does a little pre-processing of the code. Among other things, this allows it to grey out code which isn't going to compile. For example, code is in a "#if 0" block would be grey. Good.
• When debugging, you can hold your mouse over a variable and a tooltip of the current value will pop up. If it's a pointer, it will let you drill down into the structure using the tool tip. Good.
• When coding, you can hold your mouse over functions, variables, and likely other things, to get tool tips which tell you the type/definition. This is very cool as it saves right clicking and going to the definition. Good.
• They've disabled source control integration in Express. This means you have to manually task switch to some other application to check things in/out of source control. Personally I have Perforce installed (it's free for under 2 users). I find the easiest way to check things in/out is to right click on the tab of the open source file and select "Open Containing Folder". This opens an explorer window with the appropriate file already selected. I then right click the selected file and use the Perforce context menu options to perform the operation. Also, due to the way that Perforce and VC work, if I'd accidentally started editing a source file which wasn't checked out, the check out operation wont stomp on my changes. I'd prefer proper source control integration, but my workaround is sufficient.
• I'm not sure but I think that the DirectX plugins for debugging surfaces and renderstates don't work. I can't see them in VC but haven't looked into it. It would be a shame if these weren't present, as they really make development of rendering code easier.
  

Overall, I give VC++ Express two thumbs up and a cheeky wink. It's hobbled a bit, but still a really great tool for game development.

Faster Build Times - Pre Compiled Headers

Coding

When compiling C/C++ code, header files get included. Headers often tend to include other headers. When a single c/cpp file is compiled, the compiler has to parse through all the headers recursively and process the contents. You may not realize this, but a huge amount of the build time is taken up with just processing the headers.

There's a concept called 'pre-compiled headers'. The idea is that you have one header which includes all the headers which don't change often (e.g. DirectX, OpenGL, third party rendering or sound APIs, STL etc.). These headers are processed and then stored as a processed binary blob. This pre-compiled header blob is then used by all your files, removing the need for them to parse the common files.

Whenever I've seen pre-compiled headers properly set up in a project, the improvement in build speed has been dramatic. Speed ups between 4x and 10x are normal.

The following web page does a great job of explaining this in more detail, and leading you through the simple (but un-intuitive) steps of setting up pre-compiled headers.

http://www.cygnus-software.com/papers/precompiledheaders.html

(Feel free to post a comment on how much this speeded your build time up)

Welcome to the Game Creator blog!

My name is Mark Pope, I'm a programmer and the Programming Director at Heavy Iron Studios (a division of THQ).

On this blog I'm going to be covering topics including coding, getting into the games industry, indie game development, and likely some random stuff which takes my fancy too.

Thanks for reading. Someone listening makes this a conversation, rather than a lunatic shouting in the park.