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!).

Clipped!

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!)

Oblique

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

http://www.terathon.com/code/oblique.html

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.

Thanks!

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

Hello!

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.

Thanks!

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.

Thanks!

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

Hello friends, new and old!

August 26, 2010 1 comment

Hello!

This post has two audiences – the lovely followers we’ve gained in recent years as we’ve started on more of our own projects and the new readers from iDevBlogADay , which is an indie developers weekly blog initiative we’re lucky to be part of.

Essentially this means I’ll be trying to keep up with writing a new (and hopefully interesting) blog post every Saturday. I did debate for a bit whether to have a separate site for these posts as some people may be glad to see only a rare monthly post from me!!

We’ll be taking the opportunity to make some improvements to the site and we’re trying our FeedBurner for our RSS feeds now – please subscribe! Also if you aren’t already be sure to follow us on Twitter and Facebook.

WHO ARE WE?

Some of you may not have a clue who Four Door Lemon Ltd are (apart from being a really weirdly named British company!).

We’re a five year old games developer based in Bradford, West Yorkshire in the North of England. We started out as 2 guys, grew quite a bit with remote contractors at one stage in 2008 (while having a core team of 5 in the office) and we currently have 7 people in the office.

It’s been a very interesting journey so far and we’ve been involved in a huge variety of projects across pretty much every gaming platform. Internally we are fairly code orientated but the last year or so has seen us performing a lot more design and working more closely with our art guys (who are mostly external contractors we have had close relationships with for  many years).

When we started out we aimed to earn enough money from work-for-hire and licensing out our engine to produce our own titles for 6-12months. This money never materialised due to various reasons (not helped by the financial crisis) but we survived and then ended up falling into self-publishing on iPhone (starting with QuizQuizQuiz and more recently You Are The Ref) which has led to us starting on similar fun projects.

We see our future being a healthier split of our own work across a large amount of digital distribution platforms and client projects.

WHAT’S COMING UP?

I’ve got a list of topics for the blog but looking at other iDevBlogADay posts I’m not really sure where exactly to pitch it or whether people have specific queries that could coincide with stuff we’re working on.

Feel free to post a comment on this post or to contact me on twitter with any suggestions for posts!