Posted: June 17th, 2016 | Author: admin | Filed under: Rapture | No Comments »
Been a fantastic week with the Google feature – loads of new players have been in touch with feedback on the update and ideas for the next.
We’re currently working on a few new translations – then we’ll look into the next update – so please keep your ideas coming.
We have just passed the 1 million mark which is a huge landmark for our game – so thank you to everyone that has downloaded Rapture.
Posted: June 6th, 2016 | Author: admin | Filed under: Rapture | No Comments »
We have just released a big update for Rapture on iOS and Android – update your game and take a look at the new features. We’ve had lots of feedback from players (thanks for the emails!) and added a lot of the suggestions.
Download for Android and iOS
This screenshot shows the new “Colossal” planet with the Holodeck background and the new Incans civ. You can also see the new game speed button in the top left.
Here’s some further details of what’s new:
– A new game length option – Plenty of players have been asking for this – you can now select how long the game should be in the Play Options screen
– Game speed – You can also change the play speed with a new button in game – especially useful as you are just getting to grips with the game. (The button can be hidden via the Play Options and will be turned off at higher difficulty levels)
– New planet size option – There is now a colossal option which creates an enormous planet – please note that this option requires a device with reasonable power – older devices might experience slow down
– New planet landmass “Very High” and “Full” options – These cover the world with even more land – again older devices might experience slow down with these options. Also note that full coverage will still leave a few small inland seas – as they are needed for gameplay
– Play Options – We’ve moved the Play Options screen to appear after the missions screen – there’s a Quick Play button on the Missions screen if you want to get straight into game
– New Planets – There are 5 new planet shapes to choose from – X and Y shape, disk, heart and die shaped
– New sea – A beautiful rainbow colour sea option
– New spacescapes – 2 new “room” backgrounds – holodeck and padded room
– 7 new civilizations – Atlantis, Brazil, Zulu, Inca, Persian, Portuguese and Dutch
– New roman flag – A few people have mentioned that the yellow roman flag is actually the flag of the Holy Roman Empire – so we’ve changed the flag to try and be more historically accurate
– Help button – A new button on the main menu will take you through to our website where we’ve added help on how to play the game and what the miracles and domestic policies do
Let us know what you think at firstname.lastname@example.org and if you have any new ideas you’d like to see in the game we’d be interested to hear from you.
Please like and share this post!
Posted: April 13th, 2016 | Author: admin | Filed under: Rapture | No Comments »
Been a fun few months at Tundra – the android feature back in February brought in lots of new players. We have now tipped over the 500K downloads, which is fantastic.
We’ve also had lots of feedback and ideas for updates, which always gets added to the big list that we keep, with everything we want to do to the game. Please keep them coming in the comments or at email@example.com
The Russian update has been well received. We’ve had lots of updated reviews to 5 stars. We had a particularly detailed email, stretching over three A4 pages with thoughts on the translation and we hope to get all those in the next update.
Work on the update is going well – it should be out in the next few weeks (cross-fingers). We have a number of new planet shapes, spacescapes and civilizations. The main change will be the game options to select your game length and a button in game to select play speed. It’s probably the most asked for feature. Here’s a photo of the heart shaped planet to whet your appetite:
You might also be able to guess a few of the new civs in the screen shot. The hope is to get the game featured on the Play or App store as Best New Update – which again would be a great boost.
Strangely the last few weeks we’ve had an unusual jump in downloads on Android. We haven’t been featured again and we can’t find any reviews that might have pushed us up the charts, but it’s been very welcome, gives us hope that the game won’t disappear off the radar. If you have any ideas of where the boost might have come from, let us know. Here’s the downloads for the past couple of months, you can see the Feb feature and then the unexpected peak the last couple of weeks. There will be a new article to go with the update with some details of how the game has been going since the Android release in November – with lots of lovely statistics.
Lastly we’ve been trying to track down a bug that a number of players have mentioned – Blue Screens. It seems to be connected with videos, occasionally the screen will just go completely blue. If you are getting blue screens and especially if you can get them consistently please email us. A video of it happening would be fantastic.
Posted: February 28th, 2016 | Author: admin | Filed under: Uncategorized | No Comments »
Hi all, there has been a few problems with google payments over the last week or so and players haven’t been able to buy the VIP Pack. We appreciate anyone wanting to support us by getting the VIP Pack and those that wrote to us to let us know there was a problem.
It should all now be working and if you still fancied getting rid of ads (and getting the other goodies the VIP pack gives) please give it another try in game.
Posted: February 19th, 2016 | Author: admin | Filed under: Rapture | No Comments »
We’ve put up a new version of the game with a potential fix to the multiplayer issues we’ve been having the last couple of days. Please update and let us know if you still have problems. There’s also a new version of Google Play Services available and it might be worth grabbing that as well.
In the update is also a potential fix for the blue screens that a couple of people have been having.
If you still get either of these problems, or any others, please get in touch at firstname.lastname@example.org
Posted: February 19th, 2016 | Author: admin | Filed under: Uncategorized | No Comments »
Just a quick post to say Rapture is currently having multiplayer troubles. Looks like Google have changed something and it’s affecting online play so players can’t connected to each other.
We’re putting together a fix at the moment and hoping to have it up very soon.
Thanks for your patience!
Posted: February 6th, 2016 | Author: admin | Filed under: Rapture | No Comments »
In case anyone missed the latest update for Android – there are now two new planet shapes to play on – flat earth (for all you deniers out there) and the torus/donut shape. Just update your game and unlock them in the shop to play on them. There’s also an extra “Pangaea” option in the Play Options page (found off the Missions screen) – which makes all the regions appear as one big landmass.
Also for you techies out there – we have updated the game to work with the latest “MarshMallow” SDK. Let us know what you think of the new shapes and send us any thoughts on other shapes you’d like added.
This isn’t for iOS yet – we’re working on getting it on Apple devices very soon.
If you haven’t already please leave us a review on the Google Play store or the Apple App Store
Posted: November 23rd, 2015 | Author: admin | Filed under: Rapture | 2 Comments »
Written by Tundra Games CTO Andrew Weinkove
Rapture World Conquest is free to download here for iOS and here for Android
Our previous blog about going free can be found here
Rapture – World Conquest was released on iOS in September 2014 as a single player only game. Multiplayer was implemented later and was added in an update in March 2015. The game was released for Android at the end of October 2015.
Any programmer who has ever grafted multiplayer functionality onto a single player game will tell tales of just how difficult the process can be. For Rapture, the process went relatively smoothly because we planned ahead for lockstep multiplayer and built in a number of systems from the start.
To coincide with the recent release of our Android version we have written this article to talk about the systems and processes we put in place that minimized the pain of lockstep.
The idea behind lockstep multiplayer is simple, if every player shares their input with every other player, the simulation can be run on everyone’s machines with identical input to produce identical output.
Lockstep multiplayer has become somewhat unfashionable these days as server/client approaches offer many advantages in a lot of genres . The key advantage of lockstep is its low bandwidth demands, the key disadvantage is high lag as the simulation can’t step forward until a machine has received the input from all of the players. With audiences generally having access to decent broadband, the attractiveness of low bandwidth requirements typically looks insignificant against the usability cost of high lag.
However, the real-time strategy (RTS) genre is something of an exception. Latency in an RTS typically doesn’t affect usability anywhere near as much as it might in other genres like first person shooters. Meanwhile, massive numbers of units mean that alternatives to lockstep can easily use prohibitive amounts of bandwidth even on good connections.
Even in the RTS genre, lockstep is not the only option, however lockstep is especially attractive to mobile developers because cellular and bluetooth connections can be extremely poor relative to the broadband connections that PC and console developers can generally rely upon.
For these reasons, we decided early on that Rapture – World Conquest would use lockstep multiplayer, and we planned for it from the start.
Although the idea of lockstep is very simple, in practise it can be very challenging to keep the simulation running in perfect synchronisation. The code that drives your game logic must be fully deterministic across all the machines that will play against each other. That is, the machines must run the exact same set of calculations based on the exact same set of inputs and produce the exact same results. Any tiny variation between machines will cause knock-on effects so that after a short period of time the game state on different machines is totally different with no mechanism to bring them back into sync.
When variations occur, it is known as a desynchronisation bug, and in common with most lockstep games we share checksums of the game state between machines to detect desynchronisation and treat checksum mismatches similarly to network errors by stopping the game and displaying an appropriate message.
Desynchronisation bugs can be extremely difficult to track down, often requiring hours or days of debugging, so any steps that can be taken to catch these bugs early are very valuable. In the following paragraphs we discuss the strategies that we used to address these bugs as early as possible during development.
One of the simplest but often forgotten steps that we took was to organize our code to make it obvious which systems needed to be fully deterministic for lockstep. We refer to the section of our code that must run in lockstep as ‘the simulation’ and tried to make a clear distinction between simulation code and ordinary code.
All the simulation code source files were put under a directory called ‘Sim’ and have the word ‘Sim’ in their filename. We made sure coders knew to be extra careful when making modifications to the simulation, and regularly reviewed checkins on this directory for potential issues. We also compiled all our code with a high warning level, which can help highlight some programming errors like uninitialized variables which can lead to desyncs.
Fixed Timestep Updates
When we talk about all machines having to run from the same input, the immediate thought is of button presses or commands produced through the UI. In fact, the timestep is another important input into the simulation.
Right from the start we designed our simulation to run at a fixed timestep with interpolation. In common with lots of other RTS games, we run our simulation at quite a low tick rate, 10hz in our case, and interpolation allows the rendering to run at a fast smooth framerate.
This decoupling of the simulation loop from the render loop not only achieves the fixed timestep necessary for lockstep, but it also reduces CPU load by letting the complex simulation run at a lower rate.
At the same time, we also engineered our code to run the simulation on a separate thread. This has little to do with lockstep, but was great for performance as it can conceal the large CPU spikes when hundreds of units pathfind on the same frame, and also takes advantage of the multicore processors that most modern mobile devices have.
Another area that can produce desyncs is random number generation. We needed to ensure that every machine is generating the same set of pseudo random numbers otherwise multiplayer matches would quickly go out of sync.
Right from the start we made sure that our simulation used an independent random number generator from the rest of the game. This is because the game might be running at different framerates on different machines, so any random number generation in our rendering code (a particle emitter for example) will be called a different number of times across machines. Obviously, the random number seed used by the simulator needs to be agreed upon by all machines and we did this by generating a seed from a checksum of the shared launch settings.
Deciding to Prohibit Floating Point Math
Floating point numbers can present something of a problem. The challenge is that while the IEEE standards set out maximum errors for floating point calculations, individual implementations (either hardware implementations of maths operations or software implementations of functions like sine) have scope for producing slightly different results. These results won’t be very different, they’ll vary only occasionally and usually only by a very small amount. However, that is enough to upset the delicate balancing act of a lockstep game.
Now, to be clear, floating point math is not vague and indeterminate. We would always get the same result when running the same executable on the same hardware. The problems arise when running on different hardware, using a different compiler, or using different compiler settings.
It probably isn’t very productive to delve too deeply into issues surrounding cross-hardware floating point determinism as it seems to be a topic that can cause some passionate disagreement and many good articles cover this ground . Suffice to say that while games exist which use floats and run without desync across a variety of PC architectures, no-one has made the claim that it is an easy path to tread.
We decided that attempting to use floats in areas of our code that need to be deterministic would be a world of pain that is best avoided. Further to that, we were unsure if all the different FPUs found in mobile devices can actually be coerced to produce identical floating point results in the same way that PC FPUs can.
Finally, we’d set ourselves a target of supporting cross platform play during development. Having decided to support 4 player matches, it makes testing and debugging a lot easier if we can mix and match PC, OSX, Android and iOS builds with differing optimisation levels. Achieving flexible cross platform play like this just would not have been possible with floating point maths in our simulation.
Enforcing the Prohibition of Floating Point Math
Having decided not to use floating point math, we naturally decided to use fixed point math in its place. The idea is simple enough, we have a class that represents fixed point numbers, it’s simply a 32-bit integer where the bottom 12 bits represent the fractional part. So, the number 4096 represents 1.0, 2048 represents 0.5. Multiplying two fixed point numbers together would look something like ((FixedA * FixedB) >> 12), although all of our actual functions have a lot of checks to avoid preventable overflows and assert about unavoidable ones. We looked around for an existing fixed point math library that could be plugged in easily, but didn’t find anything suitable so we rolled our own.
Deciding not to use floating point maths is only half the story though. Ideally we would have a mechanism in place to catch any accidental use of them. Our solution was to use the floating point inexact exception.
Bruce Dawson’s article on floating point exceptions is a highly recommended introduction to the subject (his entire series of articles on floating point numbers is excellent), it includes some simple classes to help control which floating point exceptions are enabled . One of the floating point exceptions that you can enable is called the inexact exception and it fires if a floating point operation produces a result which requires rounding. As pointed out in the article this is usually not useful to game developers because floating point operations are very frequently inexact, and we are all used to writing code that allows for this fact. However, for this very specific purpose, the inexact exception is perfect as it will fire on almost any piece of code that uses floats. We do not attempt to handle or catch the exception, we simply let the debugger catch it and treat it the same way we would treat a crash or assert, as a serious bug that needs to be fixed.
On our debug builds, we enable the inexact exception (along with the rest for good measure) whenever we enter our simulation, and the exception will fire if we absent-mindedly use floats. The exception is disabled when we leave the simulation, and we use floating point maths extensively in other areas of our code-base such as rendering.
In practice we found that we rarely used floats in our simulation directly, more often we called an innocuous looking function that had some floating point operations buried deep within it. It is possible to use floating point maths without firing the inexact exception, but any floating point maths that is exact will probably exhibit consistent behaviour across different hardware anyway.
From the outset we knew from experience where desync bugs were likely to come from. However, for all the care we took to use the correct random number generator, to avoid uninitialised variables and to tightly control input to the simulation, we knew that we would make mistakes. We decided to put systems into place to catch them in our single-player mode long before we wrote a line of actual networking code.
The main tool we used was that every time we step our simulation forward, we load the previous state, and step forward again. We then compared the two new states we produced and if there are any differences then it indicates a problem in our determinism.
In order to achieve this we wrote code to serialize and deserialize the entire simulation state. Implementing and maintaining serialization code was a moderate amount of work, however we found that being able to save and load the entire game state was useful for other reasons. We used the same serialization code to support our in-game rewind feature, to generate the checksums that detect desyncs and for some debug systems (we found it handy being able to rewind and single-step the game in debug builds).
An simpler approach to ours would be to permanently maintain a main game state and a debug state, and by stepping both forward together and comparing the result, most of the same desync bugs can be caught. The reason we chose to load the previous state each time is that our approach lets us catch bugs in our serialization code at the same time as catching our desyncs.
When we detect a difference between the two states, we found that it’s not that useful to just assert there and then, as it leaves a lot of work to be done to track down where things went wrong. To help find the cause quicker, we added code to work out which is the first out-of-sync byte in the serialised data stream. We then loaded the serialized state again, but this time we fire an assert when we get to the first desynchronized byte. That way our callstack indicated which instance of which class had gotten out of sync, this helped us track down the cause a lot faster.
Overnight CPU matches
Putting systems in place to catch desyncs fast is all very well, and most bugs that these systems are capable of catching will be caught almost immediately. However, there’s always a handful of very rare problems.
We found it was incredibly valuable to invest the time on code to let the computer run automated matches overnight. Particularly as we lacked a QA budget, it was a huge deal to know that tens of thousands of games had been run without problems. With the mechanisms we’d put in place to catch non-deterministic behaviour, our overnight single-player tests caught lots of rare event desync bugs. In addition to helping us catch determinism issues, automated testing also helped us catch other bugs throughout our codebase and we have also used it for game balancing by examining how well AI perform against each other when forced to use only specific miracles or follow specific policies.
When we finally implemented multiplayer, we extended our automated testing to our multiplayer mode, and had two machines playing matches against each other continuously overnight.
Logging/Local Player/Undefined behaviour
Despite all our care there were a small handful of desync bugs that slipped through the net. It is invaluable during development to have extensive debug logging, so that if a rare desync occurs you can pinpoint the cause without necessarily needing to repro.
Our multiplayer logging in Rapture involved serialising and writing the entire state to a logfile every frame, along with the launch data structure and any input messages. We put code in place so that it was easy to re-run the step where the machines diverged.
What slipped through
Despite our forward planning, when we finally came to implement multiplayer, there were a few desync bugs to deal with. Mostly they were caused by bugs in the networking code as it was being implemented (i.e. a failure to share the input correctly, or the accidental processing of steps before input was received).
There were a couple of instances of code in the simulation being dependent on the index of the local player, which were simple to find and fix.
We had an interesting bug caused by ambiguous sequencing that looked something like:
There is no sequence point  between the two calls to GetRand, so different compilers are free to do the two GetRand calls in whatever order they like. MSVC and XCode obliged by picking different orderings.
The other bug we had was a qsort callback we had implemented which sometimes returned zero. As qsort is an unstable sort, we got inconsistent results across compilers. In most of our deterministic code, if we were sorting an array then we would always have a ‘tie break’ condition (usually based on the object’s unique ID) to ensure the sort is consistent. In this one case we had omitted to do so.
After fixing these few bugs, our overnight multiplayer tests began to run smoothly, bar the odd hitch where our extensive logging led us to run out of hard drive space! After a few nights of successful overnight runs, we became pretty confident in our multiplayer code.
By planning ahead and implementing a number of systems in advance to ensure our code was deterministic, it meant that the vast majority of multiplayer breaking bugs were found and fixed long before a single line of multiplayer code was written.
To anyone beginning a project which will eventually utilise lockstep multiplayer, we would strongly recommend investing the time upfront to build in systems to catch common desynchronisation errors. We are confident that by implementing these systems, we saved ourselves a lot of time.
If you have any questions or comments regarding multiplayer implementation please get in touch at email@example.com
 Lockstep as favoured by many RTS games: http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php
 Server/Client with prediction as favoured by many action games: https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
 Analysis of networking options for physics based gameplay: http://gafferongames.com/networked-physics/introduction-to-networked-physics/
 Planetary Annihilation, uses a modified server/client approach suitable for RTS: http://forrestthewoods.com/the-tech-of-planetary-annihilation-chronocam/
 Article on tracking desyncs: http://forrestthewoods.com/synchronous-rts-engines-and-a-tale-of-desyncs/
 Article on fixed timesteps: http://gafferongames.com/game-physics/fix-your-timestep/
 Floating point determinism: http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/
 More on floating point determinism: http://randomascii.wordpress.com/2013/07/16/floating-point-determinism/
 More on floating point determinism: http://yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html
 Article on floating point exceptions: https://randomascii.wordpress.com/2012/04/21/exceptional-floating-point/
 Article on sequence points in C and C++: https://en.wikipedia.org/wiki/Sequence_point
Tundra Games is an independent game studio based in Oxford & Colchester UK. It was founded in November 2013 by industry veterans Andrew Weinkove and Daniel Collier. We have worked on many AAA titles including Skate It, Sims 3, FIFA, Madden, Angry Birds Star Wars, Angry Birds Go and Need for Speed. We have worked for companies such as Exient, First Touch Games and Rebellion. Please contact Dan for further details at firstname.lastname@example.org.
Our game trailer can be found here, with further details and screenshots via our website.
Play the game for free on iOS here and on Android here.
Posted: October 27th, 2015 | Author: admin | Filed under: Rapture | No Comments »
Rapture World Conquest is free to download here and on Android here.
In May we updated our title Rapture – World Conquest making it Free to Play (F2P) on the App Store – adding static ads, rewarded video and tightening up our in-app purchases. It was a bit of a leap for us, but necessary after 7 months of mediocre premium sales. So five months on we thought we’d give a few details of how the transition has been, with some stats and overall whether the revenue has improved.
For those of you who haven’t read the original article it’s here. But to summarise our journey so far; Andy and I set up Tundra Games in 2013 to make our dream indie game. The game which finally arrived on the Apple App store shelves in September 2014 was Rapture – World Conquest – a lightning fast version of Sid Meier’s Civilization.
A bit of an homage to the great game and also a way of getting a flavour of the gameplay in as small a time frame as possible. Press reviews were good – TouchArcade and Pocket Gamer. And initial sales were great, especially with the feature we received from Apple in the first few weeks. However sales quickly died down as did our initial wide-eyed dreams of indie mega-stardom. Then began the long slog of trying to get people interested in our little title.
After 8 months of disappointing downloads and shouting into the indie game void, we decided to try our hand at the F2P market. There were countless articles about it and we thought we had little to lose. We also saw it as a useful exercise to see what worked – so potentially we could go a similar route with future games.
With the original game, we had already laid a lot of the groundwork for F2P. In-App Purchases were added fairly early on – we decided to include coin packs and a coin doubler in the game.
As mentioned in the previous article, this decision turned out to hurt us. We were careful to ensure that the coin packs were never a necessary part of the game – most of the unlockable elements in the game are decorative only and meant as a way of encouraging players to earn gold and customise the game. However the game was released around the time where players were pushing against premium games having purchasable items for real world money and many of the negative reviews focused on Rapture being a paid game, but still attempting to twist money of players. In subsequent updates we pushed the IAPs further into the background – less in the face of the paid players.
When we went free, we brought them back to the front a little more. We changed our coin doubler IAP to a “VIP pack”, which not only included the doubler, but also removed the ads from the game and gave a chunk of in game gold as a thank you. We hoped that the purchase of the VIP pack would be a no brainer for players -that they would see it as a bargain and as a way of supporting us, the developers.
We added static ads that pop up a full screen advert after each game. We saw these as the main reminder (irritant) to players that they were playing the free version and it would encourage them to (possibly, perhaps, please, thank-you) buy the VIP Pack. We also hoped that even if they didn’t pay any money, that we would still have a minimum amount of revenue from these ads.
We used AdMob (from Google) as the main provider of ads. Other developers had recommended it and AdMob has decent mediation support – where you can plug in a number of other ad-providers which will be served through the AdMob network. These ad-networks can be controlled from the AdMob online dashboard, you are able to switch them on and off and also control their weighing (how much the system will favour showing ads from a particular network). We felt this would give a lot more flexibility and would be less work than implementing providers separately and doing the mediation ourselves.
We also added Rewarded Videos – where players are rewarded with in-game gold for watching ad videos. After each Rapture session the player could watch a video and the gold from that game would be multiplied by 50%. We decided to make the videos fairly passive – available as a button on the results page that was available if the user decided they wanted to use it, but not too aggressively forced upon them.
A video watch option was also added to the main IAP shop. Players can go into the shop and get 100 coins directly by watching a video. Again a fairly passive system that was there for players to use if they wished.
Looking after our current users
We decided early that the F2P changes should not impact our current players – those that had already purchased the game. The plan was to make our current title free, rather than create a separate free game on the app store. So we spent a lot of time writing code to detect the version the player was using. Upon updating their game, premium players were automatically rewarded with the VIP pack – so they would never see the ads and would also receive the doubler and extra gold as a sort of thank you. The code detected the version number by querying the app store. There are a few known issues using this method and we foresaw other potential problems. To pre-empt this we added a reimbursement system, so if anyone complained, we could give them the VIP pack or in game gold by querying their device ID and adding it to a file hosted on our own server.
How did the game do as free to play
The game was updated to F2P in May. We received reasonable coverage and the initial downloads were very good. On the first 4 days we had 21,705 downloads. Most of the coverage seemed to come from being noticed by “free-app-a-day” websites. The transition to free went well, we only had a few problems with people updating, and usually it was due to old iOS versions.
Here’s the graph of the first week of downloads:
The peak is almost 12K downloads. We reached #61 in the US iPad charts. Less than we hoped, but still reasonable for the free charts.
After the first few weeks our chart positions fell quite fast as did the downloads. Here’s the downloads from May up to now.
In all we’ve had 47K new downloads in the 20 weeks since going free, compared to almost 11K in months before. Since the initial burst of free downloads the numbers have hovered around 100 to 150 per day.
So how did we do for revenue? As a reminder of our revenue before the change, the few months before looked like this:
We made $1,191 in premium sales for Jan-May with the price set at $2.99 – around 1-5 sales a day. Fairly poor compared to our first few weeks, when we peaked at 1,147 downloads in one day. (The peak in this graph is the release of multiplayer update, by the way).
And here’s the revenue for the first week after free:
$171 in all – $41 from IAPs and $130 from Ad revenue. And here’s the full revenue from May till now. Generally we’re hitting about $5 to $10 per day.
$1301 in total – $183 from IAPs and $1118 from Ad revenue. So how does this break down?
Static Ads make up the bulk of the revenue we’ve received – $948. Here’s the revenue from the static ads that pop up after a game:
Initially we played around with the mediation settings – changing the weighting of which ad-network to use. We had added several networks – Leadbolt, iAd (Apple’s network), Flurry, Facebook, Millennial Media and InMobi and we played around with different weights. However ultimately AdMob seemed to generate the most revenue by far and changing weighting seemed to negatively affect this revenue (perhaps we were being punished by Admob for fiddling with weighting) In the end we left AdMob to handle the weightings and turned off some of the less profitable networks. Nearly all the revenue above is from AdMob.
The videos did not generate the revenue we were hoping for. Of the $1118, $169 is from rewarded videos. Initially we seemed to generate a reasonable amount of revenue, however this dropped off quite quickly. Here’s the chart:
We implemented two video ad-networks – Chartboost and AdColony. We did the mediation ourselves – the code shows videos alternatively between the two networks. Chartboost has generated by far the largest revenue. But generally players have not been watching videos to boost their in game gold and very few have been going into the IAP shop to watch videos for gold. To be honest, we were quite surprised by this, it feels like easy money after a game to multiply your gold.
As mentioned, the inclusion of in-app purchases in our paid game met quite negative responses from players. However the revenue from IAPs during our paid time was reasonable. We made $1392 before going free. Perhaps not worth the negativity, but still a reasonable amount.
The IAPs sales since going F2P have been disappointing we have made $183 from 75 sales in the 20 weeks after going free. – perhaps 1 or 2 VIP pack ($2.99) per week. Here’s the graph:
Of those 75 sales, 57 were VIP packs and 18 were coin packs. Someone actually bought the most expensive pack at $19.99 (the big peak at the end of July). If you’re out there, we appreciate your support!
So although paid players have complained about IAPs, they actually seem more likely to actually buy IAPs. It’s as though those players who actually paid for the game are already a self selected group of people who actually spend money, plus they’re going to be a much more engaged audience because firstly they think that games like ours are worth money, and second, they’re likely to invest a decent amount of time in the game because of the sunk cost they’ve already put in.
So was it worth changing over? It’s hard to say, but taking a 100 day sample between two average (in terms of baseline sales) dates range:
28th November 2014 -> 7th March 2015 – $881
16th July -> 24th Oct 2015 – $794
It suggests that, no, in terms of revenue we’re not making as much. However revenue is not the whole picture.
Now we have a F2P model, there’s a lot more with can try in terms of changes the game to try and get people to buy IAPs and watch ads. Our new Android version and update to iOS will have a number of tweaks which we hope will improve the situation. I’ll save the details for the next blog post – when we have some data on whether the changes have helped.
We’ve also released a separate paid version of the iOS game (here). This is a stripped down version – no IAPs, no ads, just the pure, unadulterated game. We’re hoping it will appeal to gamers that might be put off with IAPs. And will let us compare against the free version and possibly market it differently. Again, we’ll come back and let you know how it did.
One additional area we were hoping to improve on was our chart position. We were hoping that the additional downloads would push us up the charts and get us further exposure. Generally we’re now slightly further up the charts, but if you’re not in the top 100, it doesn’t seem to help in terms of exposure.
Here’s our chart position on the US iPad Strategy chart.
Apart from the initial release where we peaked at #8 (oh happy days), we haven’t managed to get back up above 100. During our time as paid, we would bounce up and down. Since going free, you can see our position has stabilised, but still fairly low.
During our paid time we received a fairly mixed bag of reviews, people either loved or hated the game. Most of the negative comments were due to the IAPs and a few criticised the speed. Since going free, we have had more reviews (obviously due to more people playing). And generally they have been better.
If I’m honest personally the negative reviews were hard to take, especially after spending so long on the game. So receiving some new 5* reviews has helped reenergise my thirst for indie dev. It’s not all about money – actually knowing that 4 times as many people are playing and enjoying the game is immensely satisfying.
This week we have released the new Android version of the game. The Android version has a similar monetization strategy to the iOS version, with a number of tweaks. We’ve also made these changes in the iOS version. We’re hoping the free version of the game will be a great fit with Android.
If you fancy taking a look, please download the game from here for Android and here for iOS.
Once the dust has settled on Rapture we’re going to take a step back and consider what’s next. Having spent 3 years on a single game, it’s time to look to something new. We have a number of ideas for titles that have been thrown around, so watch this space for announcements in the coming months.
Please download Rapture and take a look. We appreciate feedback – even if it’s criticism. It’s the only way we can understand what players and fellow devs are thinking and where we might be missing the target. We’d also appreciate reviews on the app stores, as it really helps downloads.
Daniel Collier is the co-founder and managing director of Tundra Games.
Tundra Games is an independent game studio based in Oxford & Colchester UK. It was founded in November 2013 by industry veterans Andrew Weinkove and Daniel Collier. We have worked on many AAA titles including Skate It, Sims 3, FIFA, Madden, Angry Birds Star Wars, Angry Birds Go and Need for Speed. We have worked for companies such as Exient, First Touch Games and Rebellion.
Please contact Dan for further details at email@example.com.
Our game trailer can be found here: with further details and screenshots via our website – www.tundragames.com.
Play the game for free on iOS here and on Android here.
Posted: June 8th, 2015 | Author: admin | Filed under: Rapture | 2 Comments »
Been a busy couple of weeks for Tundra.
Rapture became free on the 18th May. Since then we’ve had 27,467 new users, which is fantastic. It’s wonderful to have so many people playing the game and hopefully people should have more luck finding games online. We’re getting reasonable revenue from the ads and in-app purchases – in a few months we’ll write up another blog post with some stats.
We’ve also been pushing forward with the Android version of the game. It’s now really coming together. Here’s the first screenshot of the game running on device.
The main game is running well. The pain now will be getting all the native functionality working – social, ads, IAPs etc. It’s been lots of fun learning a whole new platform and good to be coding on Windows.
Lastly we had a nice little gift from the guys at MadeInCreativeUK.com for our fridge:
These guys do a great job of promoting games development in the UK.
If you have any feedback please email firstname.lastname@example.org