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 http://www.theora.org/
    • Another great package from the xiph.org 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)  http://sox.sourceforge.net
    • A great set of audio manipulation routines as implemented by the command line tool ‘sox’

AI / Pathfinding

  • OpenSteer http://opensteer.sourceforge.net/
    • 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) http://ode.org/ode.html
    • 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 http://code.google.com/p/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 http://www.box2d.org/
    • My favourite of the 2d physics engines, very simple to integrate into your code and it seems to be pretty solid.

UI related

  • FreeType2 http://www.freetype.org/index2.html
    • 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  http://tulrich.com/geekstuff/gameswf.html
    • 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.
  • CEGUI http://www.cegui.org.uk/wiki/index.php/Main_Page
    • 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 http://librocket.com/
    • 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 http://www.wxwidgets.org/
    • We tend to use wx for tool UI development whenever possible though WPF is certainly very tempting for Windows tool UI development now.


  • Lua http://www.lua.org
    • 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 http://code.google.com/p/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 http://www.python.org/
    • A very popular language for tool development however many people also integrate into their games for scripting.


  • Libcurl http://curl.haxx.se/
    • 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 http://assimp.sourceforge.net/index.html
    • 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  http://codesuppository.blogspot.com/
    • A range of useful snippets (and larger) varying from convex decomposition to mesh cleaning and micro memory allocators.
  • Boost  (http://www.boost.org/)
    • 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 xiph.org 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 xiph.org 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

  • http://cbloomrants.blogspot.com/
    • 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.

User Clip Plane sailing

September 11, 2010 No comments yet

Hi all!

A little bit of a shorter post this week from me and also a little bit more technical in content.

GL ES 2.0

One of our upcoming projects is going to be (currently at least!) 100% GL ES 2.0 based, I ported our engine over quite a while back but only recently started looking at anything more advanced than vertex colour diffuse * diffuse texture shaders being applied.

It’s been enjoyable working on graphics code again and like we’ve seen working with iPhone and new mobile platforms previously there are a lot of déjà vu moments from early PC/console days (or not so long ago if you’re also working on DS / Wii as we are!).


We’re using a reflection pass in the title and so need to clip along a certain plane (to prevent geometry below the reflection plane from appearing in a ghost like fashion when we render using the reflection texture).

User clip planes aren’t supported GL ES 2.0 so we had to work out which option was nicest to resolve this.

This was something we’d gotten round on an Xbox 1 title by calculating the distance from the current vertex position to the clip plane and then passing that value into the pixel (fragment) shader to be texkill’d (i.e. the pixel wouldn’t be rendered) if the interpolated distance value was less than 0.

Another method I’ve heard of (which would work on hardware without pixel shaders also) was using alpha testing in a similar way by passing the distance from the clip place as a 1D texture coordinate which then looks up into a simple clamped alpha texture, the alpha test in the fixed function hardware would then cull the pixel.

One other method which sprung to mind writing this article but haven’t thought about much (or tried) would be to render the plane into the z-buffer (i.e. with colour / alpha writes disabled) and let the zbuffer clip the rest of the geometry for us. (Apologies if this has a major flaw I’ve not considered yet!)


One method I recalled from a Game Programming Gem book but had never used before was Oblique Near-plane clipping which was written by Eric Lengyel and he covers in the following slides from GDC (PPT PDF).

The projection matrix in the rendering pipeline projects your vertices from their camera/view space positions into clip space which are then divided through by w to give normalised device coordinates. Once projected valid geometry will exist between a near and far plane which is defined by the projection, the final primitives rendered are clipped to these planes (and the other side planes of clip space) by the graphics hardware (generally).

The technique takes advantage of this clipping by adjusting the near plane to be the same as a clip plane we specify. This effectively gives us free clipping against our own clip plane – as it’s part of the matrix multiplication already being done!

As described in the GDC slides the far plane has to be adjusted by the algorithm to contain the original view frustum fully and in doing so the z-buffer precision will likely be reduced due to increased distance between the new ‘near’ and far planes.

You can find a GL implementation of a function to transform a GL perspective projection matrix to clip a specified plane here


The code assumes the projection matrix being  modified is a perspective projection, Aras Pranckevičius wrote a post removing Erics optimisation based on that assumption and providing a generic version of the algorithm that will work for orthographic projections just as well.

If you’re working with DirectX it’s worth noting you’ll need to adjust the algorithm to project the z values from 0 – 1 rather than -1 to 1 as with OpenGL, you’ll need to change the the 2.0 divide in Erics to code to a 1.0 and remove the +1 near the bottom of his code to get rid of this mapping.

A couple of other notes from Eric (taken from a thread on the technique)

  • Ensure your clipping plane normal points away from the camera position C. That is, the camera is on the negative side of the plane P. If the dot product (Px,Py,Pz,Pw) * (Cx,Cy,Cz,1) isn’t negative, then negate all four components of your clipping plane.
  • The clip plane should be specified in camera space so you’ll need to transform from whatever space the clip plane is specified in.

Additionally NVIDIA have also a related sample on their site.


Hopefully this technique was new and could be useful to a few people and might encourage further exploration into 3D maths for others, I really recommend the following books

Things we’ve been enjoying this week

Aurifi – a postmortem

September 4, 2010 4 comments


Thanks for all the great feedback on last weeks post about QuizQuizQuiz it was really appreciated.

Today I’m going to talk a little about a project called Aurifi, an audio-only game for iPhone/iPod which was launched at the end of May.

We performed all the programming work and were also involved in the design process with the great bunch of people at Punk Pie Ltd.

What is Aurifi? (Or-If-Eye)

The game is made up of a set of challenges which the player must successfully complete  to advance and ‘grow’ the music. Each challenge only requires you to listen and to touch, tap, tilt and shake as indicated by the beat. The game features no meaningful visuals and can be played with your eyes closed (in fact it’s almost recommended!)

The music in the game is mixed real-time from a large amount of professionally created tune segments, because of the way these segments are selected and mixed together the music you hear will never be the same. After completing each piece of music the player will be asked to ‘steer’ towards the style of music they would like for the next set of challenges.

Be sure to check out the teaser trailer that Punk Pie had produced before release and even better buy the game

Scripting / Fast iteration

The design process was really interesting as not being able to use visual cues is a handicap when you’ve become used to certain techniques to communicate with the player – especially with any slightly complex mechanic!

Due to the amount of tweaking and testing we’d need to do during the development before the first design document appeared I started putting together a prototyping app based on the initial list of possible challenges. I did this using our own multi-platform middleware (‘Lemon engine’) at the backend, FMOD for the audio capabilities (at this stage we expected to use a lot of DSP effects) and Lua.

Previously we’ve written our own C++ to Lua glue code there are however quite a few options for this nowadays, I picked luabridge (despite – I believe – it no longer being maintained) simply because I preferred the syntax after scanning through a couple one evening. It was pretty complete in terms of our needs.

The prototyping app was designed for quickly testing out the ideas we had for the challenges, we worked on PC initially quickly tweaking the challenges in self contained Lua files with calls for playing samples, applying DSP effects to active channels, adjusting pitch, frequency, volume, looping mode, ‘3d’ position and velocity. Executing one of the challenge lua scripts overwrote the previous definition for that challenge so reloads could be done incredibly quickly.

My next step was to move all our prototyping across to the device, this never quite happened as we got too involved on the design and challenge side of things for me to implement the simple network update system I had in mind for the Lua files. The idea was that a HTTP server on the Mac/PC I was editing the challenge Lua files on would get requests from the iPhone to check for updates to any files and would push down the update.

This would have worked perfectly I feel but we stuck with PC due to time. We paid for this as we later encountered issues on device that we’d have found sooner (Early SDK versions of FMOD iPhone reacted a little differently to FMOD PC).

While(1) { script_some_more(); }

We ended up with a lot of script in the game by the end (I’ll include a few codebase stats later), initially the plan was just to script the challenges and have the rest of the game be implemented in C++ (mainly as it wouldn’t be tweaked much).

I found though that I was working so quickly in Lua for implementing challenges that the song selection and playback code (plus the data definitions for the pieces of music) just ended up getting implemented before I could think about what language I was working in!

The only code that I planned to script and ended up in C++ was the menu code, which was added fairly late in the project and I was coming back to the project having been on a non-Lua project for a little bit so perhaps wasn’t in the groove as much!

Terms & Conditions?!!

During development and as we came up to release there was trouble rumbling on the net over section 3.3.1 of Apple’s developer agreement stating

Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

As a company we felt this was mainly aimed at Flash however we were bracing ourselves to re-code the Lua scripts into C++ should we be rejected by Apple. We knew of plenty of other apps using Lua on the store so felt pretty happy, we also precompiled our scripts into bytecode which made the scripting a little less obvious!

Sound plan?

So how did things work out?

Well the client was (they tell me!) very happy with the way things went during development which is always a nice result.

The scripting system worked great for quick adjustments to the challenges as we tweaked near the end of development (this was stuff like tolerances for acceptance, applying different filtering to the inputs and in some cases a complete adjustment of how the scoring system worked).

Choosing to use Lua wasn’t an accident as we’ve got a fair bit of experience with it (we started using it around 8 years ago on a Xbox 1 title followed by heavy use on a MMO system, plus various smaller projects and some personal WoW mod writing!). It is possible to make quite a few syntax errors with Lua especially if you’re coming back to use it after a while, there are quite a lot of code modifications and tricks you can use to help with this and it’s still seems to be as popular as ever as a scripting language.

The main issues encountered with the project were down to the FMOD wrapper I wrote and not completely understanding FMODs channel management when initially writing it (and due to time not fixing it quite as well as we should have). This was further complicated as our requirements in terms of sound channel grouping changed later on as we rewrote parts of the song playback and randomisation system.

When moving over from PC to device we found had a lot of sync issues due to the update rate on device being slower than it was on PC (we were working with a dynamic timestep so the iPhone when running slower due to the amount of mixing / DSP work being done in FMOD ran at a slower rate). These were fixed by implementing callbacks for touches so that input code could run immediately and also by reducing the size of FMODs mix buffer (which was a fixed size in an earlier version of the FMOD iPhone libs) to reduce the latency between a call in the script and the sound being heard.

Another issue was memory usage, we had some crashes on older devices (jailbroken in particular) which we couldn’t replicate but do plan to re-investigate soon, I think this was purely down to available RAM on certain devices and our startup RAM usage being quite high with all the tutorial assets pre-cached. The best solution for this will be to stream more of the assets on lower RAM devices and pay attention to Apples low memory warnings at the expense of reponsiveness!

The main reason for our high memory usage was that lower end devices couldn’t decode the number of compressed samples we needed at once as well as FMOD mixing and applying DSP effects so we streamed and decoded to PCM data on load and then passed uncompressed buffers in (plus FMOD doesn’t support on the fly OGG decoding – we did implement our own but again it was just a little too slow and wasn’t worth the time optimising).

To control all this we had a fairly awkward pre-cache system which allowed us to tell the background stream system what we knew we’d need soon (for example during song transitions or in tutorials) and we could force these to be freed when we no longer needed them.

Stat attack!

A few stats on the data / source code involved with this game

The game data contained

  • 24minutes 48seconds of music audio (compressed with OGG Vorbis to 20.3mb)
  • 12minute 16seconds of game samples and tutorial speech (compressed with OGG Vorbis to 11.6mb)
  • 722,762 bytes of PNG images! Kind of obvious it’s an audio game looking at how little this is of the total build size!

The game source code was made up of

  • Lua – 11021 lines of code (28% comments)
  • C++ / ObjectiveC – 7679 lines of code (21% comments)
    • This is of actual game code we wrote not including PNG loader, fmod headers, lua, ogg or vorbis. This also doesn’t include the GL rendering code.

Note I’m considering writing an alternative loc (lines of code) tool which will calculate the number of cans of Pepsi (or Dr Pepper, Sprite, Fanta or tea based on the individual developer) involved in development of each SVN commit! A very important statistic I feel!

Unique set of gamers

The game had a great initial following despite it being a really hard concept to communicate to people, I believe it’s still selling well today.

Specifically one market of really strong supporters of the game are blind gamers, through the tilt controllable menu and having no requirement to see the screen we of course hoped it would really appeal. I think this is really great and I’d love to think about how our future games could be modified to cater for this passionate group of gamers.


Hopefully this was a useful review of Aurifi, we’ve been really lucky to be involved in some very interesting projects over the years and this was certainly up there in terms of the challenges faced especially in design terms.

Things we’ve been enjoying this week

QuizQuizQuiz – iPhone sales numbers – ‘US-eh?!’

August 28, 2010 7 comments

Welcome to our first iDevBlogADay post, if this is your first visit please have a look at my recent introduction post.

I thought it would be nice to start with a numbers post as they’re usually popular!

There is a focus of this particular post and it’s not meant to be a negative – more of a ‘this is a problem we have’ and ‘now we want to fix it’ advice / support is very welcome!

The Game!

“Very slick + addictive”; “Fantastic value for money.”; “Hugely addictive.”; “Perfect for snackable gaming”;”QuizQuizQuiz is the ultimate iPhone trivia game.”;”QuizQuizQuiz sets the bar for trivia apps.”;”QuizQuizQuiz is a breath of fresh air in the trivia genre.”

QuizQuizQuiz is

  • An addictive pick up and play trivia game
  • Packed with over 36,000 professionally written questions for English US, English UK, English Australian, English New Zealand, English International, French, Italian, German, Spanish markets
    • Specific topics related to each, i.e. less ‘soccer’ questions for the US, no baseball questions for the UK.
  • Adjustable difficulty setting offering a challenge to everyone from children to masterminds!
  • Features a unique sub-category selection feature letting users pick the topics they want as they play through
  • 4 different game modes (2 single player, 2 on-device multiplayer)
    • Beat The Clock – answer as many questions (correctly) in a specific time
    • QuizMaster – 3 lives, 3 lifelines, how will you do?
    • Challenge – Head to head multiplayer all players answering the same question
    • Passaround – Select a category and all players answer a different question from that category each round

Personally I believe that as long as a trivia game modes are fun the question content is the main value in any game of this genre, our cost to the user per question is probably 3 times lower than any competitor. The questions are also written and checked by professional quiz writers.

What shall we do tonight Pinky?

World domination wasn’t quite our plan but we felt we had a very strong title upon launch though we knew we were up against some big traditional trivia brands.

A chart of worldwide sales then

Just looking at the chart and ignoring the numbers this looks like a lot of initial sales charts I’ve seen (or even a retail sales chart) – high initial sales with a long tail.

Including the numbers however we were very lucky and had high initial sales (on this chart around 70,000 at $0.99 – $2.99, more the lower end), unfortunately the long tail numbers are fairly small right now though do pay for the free drinks and beers for everyone in the office I guess!

The main reason for our high sales was mainly due to being featured by Apple after a strong start in both UK, Europe and US. Our support for all the major markets helped massively with this we feel.

Once we were in the top 10 charts (and #1 or #2 Paid App in some European stores which was an awesome feeling!) we wanted to stay there and so dropped the price when we dropped below 5th. We believe this kept us up there longer and I think this was the correct decision as it kept us in front of peoples eyeballs and allowed us to build something of a recognised brand – at the time at least.

Time to order the Aston Martin? Not quite!

If you’re not in Europe it’s likely you’ve never seen our game anywhere on the charts, if we look at US sales it unfortunately doesn’t match sales in Europe.

This is further illustrated on the following piechart (which also shows Spanish localisation support wasn’t that worthwhile!)

When we were enjoying the success in Europe we were praying that we’d get a staggered mirror of the results in the largest App Store market, this didn’t happen and our US sales before Europe took off were actually higher than anything we did later on bizarrely

To be honest though we didn’t expect sales to ever be massive in the US and Canada due to the lack of brand attached to the product.

Speaking to other local British developers not as informed about the product they assumed we didn’t have US specific content and therefore we were putting people off but we had custom written App Descriptions explaining the content for each.

Riddle me this!

Of course with this kind of App Store evaluation you never really know why at a particular time something didn’t sell.

I do think A/B testing is possible on the App Store I imagine it’s just a bit of pain (both in setup and maintenance) and still has uncontrollable variables depending on how you do it. i.e. Release a separate app in different regions you believe to be similar, try a different price in each, release under two different names / icons across certain regions (possible to upset people buying twice here though).

Some ideas

  • Lack of brand
    • Still our main theory though this doesn’t seem to matter for all iPhone games (see Doodle  Jump / Angry Birds – although I guess they did become brands in their own right?)
  • Losing featuring in the US store
    • We lost feature in the US pretty quickly, this is most likely directly linked to lack of sales during the featured week however. I’ve not checked what else was released / featured that week but something probably took our sales if this was the main issue.
  • Poor initial reviews in the US store
    • We had some pretty harsh reviews early on, I seem to remember someone getting one of the few incorrect answers in the 5,000 US questions we have. Obviously some sneak through the QA and we’re quick to correct them. When people see something featured the current reviews is the only other guidance to go off I guess (as there is no indication of that items chart position).
  • People thinking that we didn’t have US content
    • I put this on here as lots of people say this to us, I don’t really think someone looking on the App Store at the game would actually think this – please let me know if you think otherwise though!
  • The US don’t like trivia games
    • I’ve been told that some of the popular multi-platform trivia games don’t do full releases in the US due to lack of interest in the genre. This may be true but obviously we’d still be higher up in the specific Trivia category chart if this was the case.

Avast, me hearties!

We were told by other developers that piracy was a big problem, at the time I posted a few times on twitter saying this either wasn’t a problem at all for us or our piracy test was broken. I had tried to find someone posting the game online and it just seems the pirates weren’t big fans of trivia.

That was until almost 1 month exactly after launch when a version got posted up on a file sharing site. The current stats show that 23% of the people who have played the game were playing pirated versions.

As I mentioned we do detect pirated copies but we didn’t do anything about them as we hoped they’d convert to purchases or encourage friends to try (though I guess they’d encourage them to try for ‘free’ as well!). We also have stats showing these people did play just as much as paying users though they tailed off a little earlier (due to less investment in the product I would think).

What we did next

With Christmas fast approaching we decided to try a ‘Lite’ version in the form of a Christmas edition, this featured around 300 questions for all the markets we supported in the full product. It contained a splashscreen which popped up quite a bit with a link sending people to the full game on the App Store.

The chart above shows around 210,000 downloads.

Believe it or not this still gets downloaded a lot and we think it has helped maintain our long tail of sales of the full product.

This again failed to touch the US market but did have a massive uptake in the Italian market which encouraged us to increase the amount of Italian content in the main game in the first update we did.

The first update fixed a couple of question selection issues, some of the incorrect answers and added even more question content making ours the highest value quiz game on the store.

What we should have done (maybe?)

So what should we have done next – or what could we still do perhaps?

  • Engage with more US journalists sooner, we mailed and tried to get their attention but they’re busy guys and Trivia is a hard sell (or it feels like it is!). We sent out review codes and had offers of reviews but unfortunately few materialised at the time.  We met a few of them at GDC and this will hopefully help in the future.
  • Actively look for potential buyers on twitter and forums, we could have done this while we were in the European top charts and talked about the success a bit more to help that transition to the US.
  • Buy advertising space focused on the US with the money we were making in the UK/Europe.
  • Produced an actual lite version rather than just the Christmas version. I’m not sure if this would have helped.
  • Produce more updates. This is one I really would have liked to do though we didn’t have much feedback after the first update which perhaps caused us to lose momentum on this, people seemed generally happy with the changes and we saw playtime increase.
  • Maintained the website. I’m not sure how much this does effect things and due to various reasons we didn’t have much access to site analytics. It’s still pretty out of date however and in the future we plan to make website updates something we schedule in with other marketing updates.

What we’re currently doing

We’ve been working on lots of different projects this year and now QuizQuizQuiz and our other trivia brands are getting even more of our attention.

We released QuizQuizQuiz World Football as a 59p app as a mid-way point lite version before the World Cup, this unfortunately got a little lost in the World Cup app frenzy. It did seem to gain us some extra fans though and the content is valuable for the future.

We’re currently working on updates for the app for the upcoming iOS features to see if we can revitalise sales of the game as the content is still very current.

Another trivia game You Are The Ref (a football / soccer trivia app based around the amazing artwork of sports artist Paul Trevillion) which we have developed is gradually growing its fanbase and we plan to cross-promote all of our apps in the near future.

We’re also listening and learning more as we go along, at the end of the day we’re developers trying to do marketing which is really good fun but we’ve learnt that we need to be disciplined in the approach we take and make sure we don’t let the ball drop at anytime.


That post certainly ended up a lot longer than I imagined!

Any feedback / ideas for us would be very welcome (and indeed any comments on the article or the blog in general).

Thanks for reading! (please check out the mini section below, will see how long I can maintain that too)

Things we’ve been enjoying this week

Please become a friend of FDL!


idevblogaday.com - idevblogaday Resources and Information.

This Domain Name Has Expired - Renewal Instructions.


RSS Feed