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 feedback@tundragames.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.
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.
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 feedback@tundragames.com
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.
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.
This slideshow requires JavaScript.
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.
Rapture World Conquest is free to download here for iOS and here for Android
Our previous blog about going free can be found here
Introduction
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.
Choosing 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.[1]
Lockstep multiplayer has become somewhat unfashionable these days as server/client approaches offer many advantages in a lot of genres [2][3]. 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[4], 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.
Desynchronisation
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[5], 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.
Code Organization
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[6]. 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.
Random Numbers
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 [7][8][9]. 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 [10]. 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.
Serialization
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:
MyFunction(myRNG.GetRand(), myRNG.GetRand());
There is no sequence point [11] 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.
Conclusion
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 feedback@tundragames.com
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 dan.c@tundragames.com.
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.
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.
Quick Introduction
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.
Development
In-App Purchases
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.
Static ads
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.
Rewarded Videos
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.
Revenue
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
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.
Rewarded Videos
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.
IAPs
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.
Overall
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.
Game Tweaks
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.
Chart position
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.
Reviews/Warm fuzzy
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.
What’s next?
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.
About Tundra
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.
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 feedback@tundragames.com
It’s been 8 months since we released our first iOS title Rapture – World Conquest. It’s been a roller-coaster of a ride – mostly consisting of a big steady climb at the start, a sharp plunge and then a long graceful slide. We’ve learnt an awful lot and I wanted to share a few thoughts on our experiences.
A Little about Tundra
Tundra Games consists of myself (Dan Collier) and the other co-founder Andrew Weinkove. We both started in games many moons ago and worked together at Exient in Oxford. Andy and I have been in the games industry a while and have worked on many mainstream titles, mostly on handheld and like a lot of seasoned games developers we wanted more creative control over the games we were making. So we decided to set up Tundra and started developing our own.
The Game
Andy originally came up with the concept of Rapture while thinking about two of his all-time favourite games, Civilization and Counter-Strike. The idea was to explore what would happen if the rapid five minute rounds of Counter-Strike were transplanted into the majestic historical sweep of Civilization.
Rapture – World Conquest is a god game where you control your followers and attack your enemies. You build up your forces and try to take over as many regions as you can before the End of Times arrives. You also have various miracles you can use along the bottom; Meteors, Earthquakes, Tsunamis etc.
Here’s the trailer:
Development
All in all the game took about 2 1/2 years to write, it was mostly written evenings and weekends. This was about 6 months over our self-imposed deadline, but when there’s no publisher breathing down your neck it’s easily done. By holding paying jobs we have been able to finance ourselves without any outside help. We kept costs minimal – the main one being the graphics, where we spent money on some decent 2D artwork. It’s been slow steady development with low risk. We also tried to keep feature creep to a minimum. We released the game mid-September 2014 for iOS.
Stats
The game has been on the App Store for 8 months now. It was priced at $2.99/£2.29. The game has in-app purchases, which consist of coin packs to buy various upgrades in the shop and also a doubler, which doubles the amount of coins you earn in game.
So here’s the sales graph for those 8 months:
All time downloads
And the initial few weeks of release:
First few weeks after release
Just after initial release in September we managed to get featured by Apple. As any developer will tell you this is about the best thing that can happen to an iOS game. The first week it was featured on the US store and we peaked at 750 downloads in a day. I’m not sure how we got featured, it came out of the blue. The second week we were featured in most of the rest of the world. This second feature may have been through emailing Apple to point out that we were featured on the US store and us asking about other stores, but to be honest we might have been featured anyway. That second week we managed to peak at 1100 downloads in a day. This was a really wonderful start for us and we were ecstatic.
Overall we managed to get into the top 10 paid strategy charts in over 40 countries, including the US, Canada, UK, Russia, Japan and China.
Yay featured
The features lasted 2 weeks. After which we dropped down fairly quickly and settled into our long tail. Normally getting around 5-10 downloads each day. Over the following months this dropped further and we are typically getting 1-5 downloads per day
Reaction
We were very happy with the reaction to the game. It got some lovely reviews and comments from some of the big sites:
“4.5 out of 5 – …there are plenty of world conquering strategy games out there, but this one has a fantastically frenetic pace that is perfect for on-the-go gaming.” – TouchArcade.com
“Unlike other strategy games it gets your mind racing, reacting to what’s happening, and before you realise it’s all over and you’re raring to go again.” – Pocket Gamer
“Like Sid Meier’s Civilization on a sugar rush, Rapture: World Conquest accelerates centuries of global conflict into mere minutes for a super-fast strategy experience the likes of which I’ve never seen.” – IGN.com
Though this didn’t seem to affect downloads as much as we expected. We also got a number of great user reviews and emails from people. Players seemed to like it and found it fun, which is the one of the reasons we wanted to create games, and the great thing about going indie is that you have direct contact with fans.
There were however a number of negative user reviews and some online comments and I’ll admit it can hit you quite hard, especially if you’re not used to it. It’s easy to focus on the negative, and a lot of our negative comments centred around our IAPs.
In-App Purchases
We added IAPs as we’d seen them in a number of paid games – seeing them as a way of generating a little extra revenue. I’ve always seen IAPs as a sort of cheat – for players who want to move ahead faster than normal; see extra content early before unlocking it in the normal way. However several users felt the IAPs were cynically added – given that they had already bought the game, they thought it greedy to then ask for more money in game. We would have priced our shop items the same whether or not the IAPs existed, but the trust of your customers is a fragile, easily damaged thing, and we should have been more mindful of that before adding IAPs.
As you can see, the revenue from IAPs is dwarfed by the revenue from game purchases.
Download Revenue
IAP Revenue
However, this is to be expected from a paid title which does not aggressively push its IAPs. If anything we were surprised that they were as high as 6% of total revenue.
We speculate that the effect of the negative App Store reviews that resulted from the inclusion of IAPs probably outweighed their revenue.
Post-Release
Once the feature and the initial euphoria had disappeared and we realised we weren’t going to be zillionaires, we settled down and looked at what we wanted to do next. Not having the game localized into some languages had prevented us getting featured in those countries. We decided to quickly translate the game in French, German and Spanish and see if we hadn’t missed the boat. A month later we updated the game, but unfortunately Apple didn’t feature us and the translations didn’t seem to help downloads in those territories.
Publicity
The feature aside, one of the main areas we lacked (and still do) as indie dev newbies is any method to publicise ourselves. On release we emailed everyone and anyone that might be interested. We did manage to get a few reviews from big sites, but generally it was hard to get a response from journalists. This is doubly true, once the game is already out, journalists are much less inclined to comment on an update.
In November we went along to Apps World at the London eXcel. It was a great couple of days. We showed off the game to countless people and journalists and met and chatted with lots of fellow developers. I managed a stuttering panel talk about Rapture and had a go at the Pocket Gamer Big Pitch. All good fun, but the event didn’t graze our download graph. Even a 4-star review from the major website 148apps in November made no noticeable impact on our downloads.
In March we released our second big update – adding Multiplayer to the game. We weren’t expecting a huge response to MP, it was more for our own satisfaction as the game had always been envisioned as having an online mode and had been engineered from the start to support it. We combined this with a price reduction to $0.79/£0.79 and managed a modest jump – 250 downloads in one day, but quickly dropped back down. It’s hard to know how many of those downloads were based on the price change and how many on the new game mode.
We always knew we’d struggle to reach the minimum viable population to sustain a multiplayer community but we have been particularly disappointed by the numbers of multiplayer games being played. According to our analytics, less than 100 multiplayer games have been completed, which is a very poor result considering the massive effort it required.
Finances Breakdown:
So here’s the raw figures:
Revenue from downloads:
$22,175.71/£14,155.31
Revenue from IAPs:
$1,389.38/£886.88
Costs:
$4,406.78/£2,812.96
Costs include art work, localisation, visits to a couple of conferences, website/server hosting and some small experiments with advertising. They do not include anything for the time invested by me or Andy.
The Future – Going free
So this week we’ve released another big update – we’ve made the game free. The game now has incentivized video adverts and post-game interstitial adverts joining the existing IAPs. Existing users automatically receive the game’s VIP pack which gives them a few new extras and disables their adverts. We’re treading carefully – not wanting to upset existing players that have paid. We really appreciate their support in this respect.
As classic gamers the idea of free games is fairly alien. We toyed with the idea of going F2P whilst writing the game, but veered away. Possibly the IAPs were a compromise in this respect, but in hindsight perhaps we should have gone one way or the other. However, in switching to free we’ve steered clear of banner adverts and energy/timer mechanics as we feel they’re the mechanisms which most damage our enjoyment of games.
It will be interesting to see how the game fares now, whether we get a reasonable number of downloads, some decent reviews and hopefully a little extra revenue. At the very least, it’ll be nice to have our game played by a lot more people and maybe we’ll even manage to sustain a reasonable multiplayer population.
Once we see how the game does as a free title we’re considering a possible Android version of the game. We’re also thinking about removing the ads and IAPs and creating a Steam version for Windows/OSX. Plus we have lots of ideas for a sequel and new game ideas we’d like to explore.
Daniel Collier is the co-founder and managing director of Tundra Games.
About Tundra
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 dan.c@tundragames.com.
Been quiet for the last month. The multiplayer update has gone well, lots of people playing the game over game center. Numbers have dipped a little now, so if you haven’t already please have a play, helps to get everyone a game.
We’re currently working on upgrading the game to use Apple’s Metal graphics API. Once completed the game will run at a blistering 60fps – making gameplay (even more) silky smooth. We’ve also planning some bigger changes, which we’ll announce closer to release.
As well as those changes we’re also looking towards a PC version of the game on Steam.
We’re going to be attending the Develop conference down in Brighton over the Summer, hopefully we’ll see some of you down there.
Tundra
