Friday, May 30, 2008

How to Evaluate Middleware

Most commercial games have got some middleware in them somewhere. Some types of middleware include video players, sound systems, physics systems, UI systems. I've already mentioned a few of the pro's and con's of using middleware in a previous post.

You need to be careful when choosing middleware. If you rush in, you could choose a system that doesn't do what you need, costs more than you need to pay, or gives you some nasty surprises down the road.

Here's a breakdown of some recommended steps in choosing middleware. Some are obvious, but some are less so.

  • Write a list of all the things you want the middleware to do, or be used for.
  • Do some searching and find all the different options which exist. Don't dig into the details of any of them just yet, just find out all your options so you've got the best chance of finding a good fit.
  • Ask other game programmers at your studio if they've used any of the systems in the past. If you have sister studios, then ask them too, and also see if they have hand written solutions which you could reuse.
  • Make a comparison spreadsheet of the high level features of each option, how well it meets your needs, and the pricing.
  • If you are developing for consoles, you likely need to be more concerned by how the engine component behaves. Ask whether you can override file access and memory allocation. Also ask if they use STL, or anything like it, and what their stance is on allocating memory at run time.
  • If your game is going to be localized, and the middleware will be using localized assets, work out how it will handle the different languages. E.g. Can the movie player handle different language tracks? Will the sound tool help you find wav files which haven't been translated? Will the UI support the large character sets needed for Japanese and Korean?
  • Consider how much of an evaluation you can do without coding. Integrating middleware at a code level takes a long time. Can you evaluate tools first?
  • Pick one or two options to evaluate in a hands-on fashion, and check with your boss and your legal advisor that they're OK with the concept of you using it, the price, and the license terms.
  • Integrate it with your engine in a code branch. Don't start relying on it yet though. It's easy to slip into assuming that you're using it.
  • Create a stress test to push it to its limits.
  • Check that it can do everything you need it to (to a reasonable degree of accuracy).
  • If you're focused on such things, check the memory allocations made, performance, and amount of memory used.
  • Have a review meeting in which you go over your findings and decide whether to officially approve the system for use.
  • If approved, then you can integrate your code branch to the main branch, and encourage people to start using it.

If you've used middleware before, it's fun to look at the above list and see the mistakes you made in the past :)

Monday, May 26, 2008

Game Development Studio Map

I've now opened up my map of game development studios so that it can be edited by anyone. Please be nice though :)

Is your studio there? If not, you can add it, or add a post and I'll add it for you.

View Larger Map

Saturday, May 24, 2008

Game Programming Books for Beginners

There are lots of books on game programming. How do you find an appropriate one for an absolute beginner?
Pick a Language
First of all, you need to understand that there are several many different programming languages. You need to pick a programming language first, and then pick a book which focuses on it. The language will either be in the title of the book, or will be mentioned in the blurb on the back. So which language should you pick?
  • C / C++As I've said in a previous article, if you're looking to get a job in console game development, then you should focus on 'C++'. As programming languages go, it can be pretty tricky for beginners. If you've done some programming before, or are looking at applying for a games job in a few years, then try C++.
  • C#C# is a relatively new language which Microsoft created. It's similar to C++ in how it looks, but it's quite a bit simpler to use. If C++ sounds a bit daunting, and you'd like to see your game working sooner, I'd start with C#. After you're comfortable with C#, you can come back to C++ later.
  • JavaJava is somewhat similar to C# from a language perspective. Some types of commercial games (e.g. cell phone) can be written in Java. I'm generally not very familiar with it though, and tend to recommend C# over it if you're thinking of getting into console development.
  • Basic
    There are many different types of Basic. Basic is generally seen as the easiest type of language to get started with, though personally I think that it's not going to be significantly easier than C#, and C# is going to get you closer to C++. If you're just looking to have fun though, and take your first steps in programming, there's nothing wrong with Basic. I first learned to program on Basic (on the ZX Spectrum), and it kept me busy coding for years.

Publishing DateThe next thing to look for is how old the book is. New versions of programming languages, tools, and libraries (don't worry if you don't know what I mean) come out all the time, and it's best to start by learning with the latest stuff. Aim to find a book that's been updated in the last five years.
Skill LevelFinally you need to pick the skill level. It's safest to aim low if you're just getting started. I recommend seeing if the index for the first couple of chapters has sections for things like 'variables', 'the "if" statement', 'for loops, while loops', and perhaps a little later 'arrays'. The words might be slightly different. Looking at the index and reading the blurb on the back should give you an idea of whether the book is for you.
Borrow or Buy?Programming books can be pricey. I recommend getting started by using library books or books available for free online. Then if you like the book, and feel like you want to keep on coding, you can buy it later.
Google has many books online. It might not be the best way to read a book if you're programming, but it's certainly good for seeing if a book is for you.
Is it any good?Read the user reviews for the book on Remember that skill level might come into play - someone might say a book is bad because it was too simple, but that might be just what you're after.
"CD Included"
These books will usually come with a CD/DVD which contains 'all you need to get started'. It's fine to use the contents of the disk, but if you get the book without the disk, then note that the tools on the disk are usually freely available online.
Example Books
I did a quick search for example books in each category. The links to most of the books show the full contents of the book.
Good luck getting started!

Thursday, May 15, 2008

List of Automated Build Systems

Once you've got a game in development, it becomes important to streamline your build process, so you can quickly create a build without a lot of manual work. (I explain what a build process is at the bottom.)

This is a list of products I've found which aim to speed up and automate the compilation and build process.

What do you use?

What's a build process?

A typical build process might look like this:

  • Fetch the latest code and data from source control.
  • Run a perl script which updates a version number in a header file.
  • Compile the game, and the editor.
  • Run the editor in command line mode, telling it to 'pack' all the game data for the various levels of the game.
  • Run a script which packages the compiled game and game data into a windows installer 'MSI' file.
  • Copy the MSI to the network for consumption by the team.
  • Send an email to the team, saying that the new build is available.

The reality is that they get a lot more complicated than this, as some steps may fail, you might be building for multiple consoles, you might be building from multiple code branches, you might have to build for multiple languages, etc...

Components of a Console Game

Something that comes up from time to time is the need for a full breakdown of everything which makes up a game. It's a tricky thing to do, as each game is different, and there are many approaches to any given part. Here's a quick brainstormed list though, to give an idea of what goes into a game.

  • Engine
    • You can choose to license/use an existing engine, or build your own. There are pro's and con's to both approaches.
    • The Basics
      • Memory allocation
      • Debug text output to screen and debugger
      • File IO
      • Reading config / xml files
      • Build process
    • Rendering
      • Shader pipeline
      • Render opaque static objects
      • Render skinned objects
      • Render transparent objects
      • More complex material effects. Lighting, environment mapping, bump/parallax, etc.
      • Screen effects. HDR/Bloom, lens flare, depth of field etc.
    • Animation
      • Hierarchical skinned animation, including art tool exporter and pack process.
      • Blending of animations
      • ‘Blend shape’ vertex animation
      • Ability to modify animated meshes ‘by hand’ (e.g. IK or head tracking).
    • Events - the ability to send events between systems/objects.


  • Gameplay
    • Player
      • Player moves
        • Walk / run / jump
        • Attack moves
        • Swim
        • Pick up weapon
      • Behaviour
        • Rag doll
        • IK for foot placement
        • Look at interesting objects
        • Conversations
        • Attached physics objects / cloth
    • NPC
      • Ambient characters / animals
      • Enemies
      • Bosses
      • Systems
        • State machine (often hierarchical).
        • Attaching of FX/sound.
        • Route planning.
        • Method for spawning / handling high numbers.
    • Gameplay Widgets
      • Static object
      • Breakable physics objects
      • Weapons
      • Treasure chest
      • Collectables
      • Pushable objects
      • Doors
      • Vehicles
    • Non-Gameplay Widgets
      • Butterflies.


  • Networking / Multiplayer
    • Guaranteed / Non guaranteed messaging system.
    • Synchronization strategy.
    • Testing harness.


  • Tools (some mentioned in other points)
    • Art pipeline for objects, environment and characters.
    • Level building tool for level layout and scripting.
    • UI building tool.


  • Systems
    • UI
      • Tool for building and animating UI, Scripting system for ‘gluing it together’, Integration with game engine.
      • Runtime component for playing the UI.
      • Font rendering.
      • Localization system.
    • Sound
      • Loading sounds, Memory resident sounds, Streamed sounds, 3D position support, Effects (e.g. Echo), Categorization of sounds (game/dialogue/menu), Volume controls by category, Connecting of sounds to other widgets.
    • Physics
      • Select from free or purchased middleware and integrate with engine.
    • FMV
      • Select from free or purchased middleware and integrate with engine.
    • Cinematics
      • If game calls for conveying story, build a system for using the game engine to enact story sections.
    • FX
      • Particles, Ribbons, Shrapnel, Lights, Water, Fire, Fog, Rain, Tool for artist to configure effects, Tool for adding effects to cinematics.
    • Networking / Lobby


  • UI Screens
    • Front end
      • Basic: Attract mode, Main Menu, Level Select, Load/Save, Options, Cheats, Unlocked Content, Credits.
      • Network play related: Chat room, Matchmaking, Leaderboard, Clans, News.
    • In game pause menu
      • Map, Objectives, Inventory, Some repeated functionality from front end.
    • TRC Compliance
    • Achievement points


  • Infrastructure
    • Automated building and testing
    • Builds / Fire fighting
    • Automated error reporting
      • ‘Crash dump’ information per platform, Detailed error reports sent by email automatically when tools fail.