Game Design Docs

October 16, 2010 5 comments

The last few weeks we’ve been working on the initial version of a Game Design Document for a new project we’re working on.

We’re pretty much required to produce one for our publisher as it’s important to communicate the project as the game was signed off a higher level concept. It’s also very useful to us internally though as it helps us run through the ins and outs of the mechanics and the balancing issues that we’ll be facing on the project.

The topic of usefulness of GDDs has come up in recent weeks on a few forums, spawned by Sean Murray of Hello Games calling them insane (for their team and possibly he meant for Joe Danger)

My current opinion on GDDs would be

  • Positives
    • It’s very useful to write down ideas, it helps identify issues before you start coding which you might have missed in your mental map / whiteboard discussions or even prototypes (depending on which way round you’re doing things). Also some people’s brains are wired so that actually writing down or voicing an idea makes them analyse it in a certain way. I certainly find this with difficult coding issues that talking it through with someone I’ll sometimes realise I’ve got an answer locked away.
    • Having a GDD makes it easy to send out to contractors and to give to employees new to a project. They can quickly understand the full project, the designers intention and the planned implementation for it.
    • Linked to the above point it’s vital for providing to QA teams who need to verify that things are functioning as they’re intended, especially in terms of edge cases with particular mechanics.
    • And as I originally stated they’re almost required for certain projects to provide to everyone from our external producers, external marketing and business teams (who need to understand the game early in the development process to plan / look at possible opportunities) and lawyers to understand what we’re aiming to pull off with the project.
  • Negatives
    • The biggest problem with GDDs is the amount of change that occurs especially in early development and the GDD not being updated to replace it. This effectively gives GDDs a use-by date after which you need to take it with a pinch of salt. Companies tend to use wikis and other live documentation systems to counter this but unless someone is actively maintaining it things can still easily slip when more important production tasks come up.
    • Even worse than not updating the GDD is people not actually reading it! The initial GDD I’ve been writing is 50 pages in total (and will get longer as information on particular items and NPCs is inserted) and more than a few read-throughs could be time consuming. Highlighting changes and structuring the document well for referencing is essential to aid with this.
    • Wasted development time – writing / maintaining / reading the GDD could be spent just developing, testing and iterating on the project and for smaller teams as Sean mentioned this can be a much more efficient route.

Iteration is vital to the design process which Sean hinted towards, you can’t just write down the recipe for the game you need to actually cook it (and then experiment).

We’re fortunate in that we’ve organised our current pre-production to occur before we deliver what we deem to be ‘THE’ GDD and TDD for our project, this should hopefully get us closer to the line on the documents than we normally would be at this stage in a project.

Personally I find the writing and structure elements of GDDs the hardest. I’ve regretted going from OneNote to Word too early in the process – a few days were spent cutting + pasting parts around the document trying to get the flow of things right.

It’s also important to keep a consistent writing style to allow easy reading and also getting across the fun of what you’re describing (especially when selling the idea to marketing who may not be as invested in the project at an early stage). I’m not sure how well I’ve mastered this yet but fingers crossed 😉

Hopefully I’ll be able to talk a bit more about our pre-production process over the coming weeks.


Things we’ve been enjoying this week

    • A great post by industry veteran Simeon Pashley showing the breakdown of costs involved with running a games studio. He has stolen one of my future blog post ideas but I couldn’t have done as good a job as he has 🙂
    • This shows how much being a solo dev working from home / remote team can earn you extra on a title with decent sales. There are benefits to having and running a studio however which is why we still do!
    • EA have open sourced their WebKit implementation which also includes some of the EA STL. I presume they are forced to due open source a lot of this due to some of the viral source licenses in there. Looks like they’ve packaged it nicely and pushed it out to the public though which could be useful for some people.

Some interesting code snippets & blogs

October 9, 2010 1 comment


It’s been a bit of a crazy week again over at FDL towers (I *say* tower – we’re on the top floor of an office building) and I left it late to decide on a topic for this week while  we hold off a little more on talking about our current projects!

Looking back on the previous posts the open source libraries and sales posts were certainly very popular so along similar lines I’m going to talk about a couple of sources of useful code snippets (and slightly larger)  I’ve found around the web which could be good reference for learning or even directly solve a problem in certain situations. As always  be aware of license stipulations with any code you’re using online however.  Again this isn’t by any means a complete list but hopefully a couple will be new to some of you!

  • Bit twiddling hacks – some very useful bit twiddling tricks that you may not be aware of, some of these operations now have specific instructions for them on chipsets but these are still a fun set to look through and hopefully understand
  • Paul Nettles memory manager, a drop in debug memory manager which was has been popular for a very long time, we certainly got some ideas from this for our own debug memory manager and we still rely on these occasionally today when we run into issues

Couple of the big boys now..

  • Microsoft – Some of the DirectX SDK code is a little scary side in terms of the handling of certain Win32 edge cases (in terms of handling input/windows/resizing/multiple monitors) but if you’ve not had to work through the pain yourself before you should check out the DX SDK for tips. Of course it’s a great reference for certain graphic techniques as well

Other resources

  • Stackoverflow is a very popular site and for non-games work I’ve done it’s normally shown up issues I’ve encountered higher up google searches than the iPhone reference materials. Note there is also a game developer stackexchange site (i.e. based on the same system as stackoverflow) which will hopefully increase in quality overtime.


  • Charles Blooms blog – previously mentioned this in the things we’ve been enjoying list but looking at my Google Reader profile I probably ‘star’ more of this blog than any other, some really interesting insights
  • GafferOnGames – Some great notes on physics and networking from Gaffer (Glenn Fiedler) someone I remember hanging around with on IRC many moons ago 🙂
  • Bit of a shout out for iDevBlogADay as well here as it’s getting some really high quality posts, I was about to list some favourites but I think there have been so many high quality posts recently it would be unfair!

Not so small snippets

  • written by Maciej Sinilo contains some really interesting articles and some useful looking code snippets including a Win32 crash reporting, memory tracing system, his own ‘STL’ type classes and thread pool job system.

Things we’ve been enjoying this week

  • Surviving Oktoberfest and not being thrown out of iDevBlogADay by mysterycoconut for my unfinished scheduled post on Saturday.

15 games in 15 minutes

October 2, 2010 3 comments

UPDATE: Many apologies to everyone involved with iDevBlogADay, I drafted this post earlier in the week and planned to update before Saturday from Germany however due to lack of decent connectivity, the correct EU plug convertor, WordPress app fails (and possibly beer) this didn’t occur! Won’t happen again!

A little bit of an apology to start with, this week isn’t normal service!

At the time this post is going live I’m in Munich in Germany enjoying the Oktoberfest beer festival and so haven’t had time for my usual Friday night sketching out of the post and Saturday morning fleshing out. Hopefully I’ve built a bit of credit up with some fairly lengthy posts the past few weeks!

This weeks post is going to be based on a Facebook thing doing the rounds, with a maximum of 15 minutes you need to list in no particular order 15 games that will always stick with you. I’m preparing the basis for this post on Wednesday night and imagine I’ll be rewriting this list of 15 a few times, I’m going to try and be true to myself rather than go with what I should be writing down though 🙂

I presume whoever started the idea didn’t intend for game developers to write their lists, I think we’ve all got some game projects which will always stick with us (for better or worse!!)

In no particular order!

1. Counterstrike Beta

2. Everquest (PvP)

3. Eye of the beholder

4. Dizzy games (all of them)

5. Sleepwalker

6. Day of the tentacle

7. Dune 2

8. Roadblasters

9. Indy 500

10. Doom

11. Championship Manager

12. Sonic

13. XCOM

14. Return to Zork

15. FIFA ’96

I don’t want to reduce the rest of iDevBlogADay to similar posts for the week but it would be interesting to see a few of the other contributors if they get a few minutes at the end of their posts this week!

Thanks for reading!

Things we’ve been enjoying this week

    • John Carmack trying to kick off a TCR list for iOS games, something I’ve been begging Apple to force on us for a while (so that we can actually test against the same list they are and be more sure about whether we’ll be approved or not!)
    • Khan Academy is an awesome teaching resource and this last week it received funding from Google to produce more content. If you’ve not had a look before I really recommend it.

A selection of open source libs

September 26, 2010 3 comments

Hi everyone,

After my post last week mentioning Speex, Wavpack and Vorbis I had a request for more open source options that may be of interest (thanks @karnakgames) as I hinted at there being quite a lot of them.

This post is going to be a list of interesting libraries that are ones we have used or would consider using, I’ve missed off larger libs such as OGRE / Irrilicht as those include many features covered by our own multi-platform technology. That being said we do occasionally use alternative solutions for things we do support in our tech either as an experiment testing out other interfaces or if feature implementations for a particular project would be too much of a time/cost investment.

I’m sure I’ve forgotten plenty of quality libraries and snippets so please post up in the comment and I’ll integrate those (plus any new ones I think of over the next few weeks!)


  • Speex/Vorbis/Wavpack
  • Theora
    • Another great package from the group, this time a video codec that has become more and more popular the last few years. The encoders have steadily improved since we last used it and I believe it’s reasonably competitive with more popular codecs now (in terms of quality / bitrate) and has been mentioned in the news quite a bit this last year with the support for it in some browsers using the HTML5 video tag. It still has quite a way to go against h264 but it is a feasible solution depending on your video playback requirements.
  • Libsox (LGPL)
    • A great set of audio manipulation routines as implemented by the command line tool ‘sox’

AI / Pathfinding

  • OpenSteer
    • In the past when we’ve implemented boid systems we wrote our own based off Craig Reynolds work, OpenSteer is a library featuring implementations of the earlier steering behaviours and may be useful as an introduction


  • Open Dynamics Engine (ODE)
    • This was a very popular open source physics engine (and still is though not maintained as much it seems), we’ve worked quite a bit with ODE in the past.
  • Bullet
    • The new leader of open source physics engines with as many features as commercially available solutions and an active community. We’ve not had chance to use it in a project yet but look forward to doing so.
  • Box2d
    • My favourite of the 2d physics engines, very simple to integrate into your code and it seems to be pretty solid.

UI related

  • FreeType2
    • The very popular font engine, we’ve not used it in a project but have integrated it into some of our tools for the future. For completely dynamic font usage you could integrate this directly into your game for on the fly font generation.
  • Gameswf
    • Thatcher Ulrichs public domain library which I believe is still being maintained and has spawned many of the commercial Flash players / Flash based UI tools. This is something we played around with on internal projects many years ago and I’d love to look at again.
    • A GUI system which seems to be very popular, I’ve not looked at it in the past as I believe it was previously LGPL which is a bit of a scarier license when working on certain gaming platforms.
  • libRocket
    • Another interesting UI middleware package (based on HTML/CSS standards) I spotted the other day and will be investigating as an alternative to our existing UI solutions.
  • wxWidgets
    • We tend to use wx for tool UI development whenever possible though WPF is certainly very tempting for Windows tool UI development now.


  • Lua
    • One of the most popular scripting languages used for in-game scripting, we’ve used it on a few projects and are still massive fans. Early development was a lot tougher than it is now (having to write our own debugger!) but the community has really grown.
  • V8
    • Googles open source JavaScript engine, I’ve heard of a few people integrating this into their games. I’m not a massive JavaScript fan to be honest but I can see the appeal.
  • Python
    • A very popular language for tool development however many people also integrate into their games for scripting.


  • Libcurl
    • The library beneath command line tool ‘curl’ which supports about everything you can imagine in terms of standard internet protocols – HTTP/FTP in particular and is very useful for interaction with web browsers across your cross-platform games.


  • Open Asset Import Library
    • I came across this looking for some for a mesh import routine on a prototype project I was working on and flagged it as something to look into integrating with our tools. It seems to support a decent list of file format imports and mesh cleaning.
  • John Ratcliff’s Code Suppository
    • A range of useful snippets (and larger) varying from convex decomposition to mesh cleaning and micro memory allocators.
  • Boost  (
    • Not a library we use to be honest but very popular and for good reason especially in terms of useful code for tool development.

That’s all!

The above list is far from complete and I could have added quite a few more in each section, I’m sure I’ll kick myself over some of the ones I’ve missed.

Next week I’m actually away so I’ll be putting together the post in a few days and scheduling it, any requests are welcome for upcoming posts. We’re getting nearer to talking about our upcoming project releases which is very exciting for us.

Things we’ve been enjoying this week

  • Minecraft
    • I’m not going to link it as I’m not evil. I finally gave it a try and got sucked in!

Sound/Speech compression

September 18, 2010 1 comment

Hi all,

This week I’m going to talk a bit about some very useful open source libraries we’ve used in developing some of our past client projects. These have mainly been used on DS which is a little more restricted in terms of space than other platforms.

Sounds interesting!

Sound has been the main component of the projects I’m covering today, probably 60%-80% of the final size of the games was audio.

One of the titles consisted of 5 languages of speech audio data to playback during gameplay. We also have to deal with very little available RAM on the DS which means we can’t precache much information if any, and so data needs to be decompressed on the fly.

Looking at the English speech only for one of the titles we had 187,199,378bytes (178.5mb) of source data stored at a sampe rate of 44100hz with 16bit mono samples this was roughly 35 minutes of speech.

Storing speech at 44100hz is a little excessive to start with, the Nyquist-Shannon sampling theorem tells us that perfect reconstruction of a signal (a sound signal in this case) is possible as long as the sampling frequency used to represent it is possible when the sampling frequency is greater than twice the maximum frequency of the signal being sampled.

This means we can safely resample down based off the highest frequency in the sound, this can be automated in a tool so that we find the maximum frequency in the audio and then resample to twice that.

Speech tends to be 0-4000hz frequencies which is why most speech data is sampled at 8khz. Note this obviously doesn’t represent all possible sounds a person can make and is purely meant for speech which is why listening to music (or singing) down the phone doesn’t exactly sound great!

Our speech data is kind of stylised and we actually used a sampling rate of 11025hz. If we were just storing the data as raw PCM this would mean our data is 1/4 of the size (46,215,824bytes, 44.1mb for our data set) already but that’s not good enough for our needs.


This is an alternative compression method for audio data and is supported in hardware on many platforms (meaning lower in RAM storage overhead and no playback slowdown), the actual algorithm varies but most platforms use IMA ADPCM. Depending on the implementation the compression ratio varies but generally it’s 4:1 (another 1/4 of the data size!) note this is a fixed ratio compression and the same amount of data would be used to store a piece of silence in your audio data as it would to store the most ‘interesting’ data.

Most audio people I’ve worked with don’t really like ADPCM for general use, I’ve not really looked into how it fares in terms of comparing to the source sample but even I can hear some of the issues on certain sounds!

For our speech data 4:1 ADPCM would result in 11,553,956 bytes (11mb) of data at 11025hz.

Speex of the devil

There are some truly great open source / free software packages available and one of them is Speex from the same who bring us Vorbis (mentioned briefly below) and Theora.

As you can probably guess from the name Speex is intended for speech compression and therefore won’t perform as well with none-speech data.

For our project we implemented a decoder thread that would when notified stream the compressed data from disc and decode either directly into a double buffered audio stream (i.e. direct to the sound hardware or the sound API) or into a decompressed buffer if the speech was going to be used a few times in that particular part of the game (to save decompressing the same sound over and over).

To give an idea on compression ratio using quality 5, complexity 1 on our 11025hz mono speech data we compressed all the data into only 4,401,832bytes (4.2mb). As you can see this is a massive saving on the original data! The quality is still very good. During development we produced a tool that we sent to testers to help them evaluate the various quality settings so we could find a good trade off on size/quality.


Briefly I want to mention WAVPACK this is a compression format we used for a really great but unfortunately unreleased project a few years ago.

This again was a DS title but this was featuring instrument samples and needed to be really high quality in terms of the quality achieved. WavPack produced some really impressive results for us and again worked very quick even on the DS CPU for both compression and decompression.


A final brief mention for another quality compression format from this time Vorbis which is a very decent competitor for mp3 and doesn’t come with any associated licensing overhead or concerns. Again we use this for decompressing on the fly on PC and newer console hardware plus have used on iPhone on Aurifi


Hopefully some of you are looking at reducing your games footprint and these libraries may be of use, even in terms of install size you could use the above methods to compress the files and then decompress on first load.

Things we’ve been enjoying this week

    • Charles Bloom is posting at the moment about data compression challenges, it’s an area that fascinates me but I’ve never had chance to do much work in other than tinkering on the periphery. If you’ve not read his blog before it’s well worth looking into including some great posts on threading last year and many more before that – I’ve no idea how he gets so much time to write some really quality posts.

Please become a friend of FDL!

iDevBlogADay - idevblogaday Resources and Information.

This Domain Name Has Expired - Renewal Instructions.

RSS Feed