52 Hertz Whale are 3 guys from Nizhny Novgorod, Russia. They were once working at the same local IT company and decided to create an indie game together. Inspired by titles like Limbo, Badland and Ridiculous Fishing, these developers tried to create something unique and gorgeous, and they got it. JELLIES!, a color-matching arcade game. “It has a great simple design, unique entertaining gameplay and awesome little wicked jellies”, says Mikhail Shagin, the co-founder and developer in 52 Hertz Whale, as he shares the story of the game.
Winning Blimp specializes in science-fiction themed games with a 16-bit era flavor. Based in both Osaka, Japan and Florida, USA, Winning Blimp was founded in 2012 and is headed by Bear Trickey, a former game designer from Kyoto-based studio Q-Games, and Alex May, a multi-discipline graphic artist and musician. Alex May tells the story of Mosaique, a cerebral puzzle game.
The Birth Of The Blimp
Mosaique was a critical project for us as a team, as its development runs parallel with the formation of our company and solidified an excellent collaborative relationship between us as developers. Despite Mosaique being our second title, it was actually the first game prototype that we worked on together. Bear had been toying with a simple mechanic that involved a shooting device that traveled around a spline and shot projectiles at various obstacles, somewhat like an orthographic Tempest.
Bear was working with an old iPod Touch at the time and was having difficulty with the layout logistics of the smaller screen. It just wasn’t possible to get both controls and captivating level design into that small screen area. He decided to shift the concept from an action game to something more cerebral, his hope being that the puzzle genre might accommodate the limited screen area better. This resulted in the next prototype; the shooting device was now rotating around a square grid and the objective was to shoot objects in the middle with a limited number of shots.
This was the first prototype that Bear showed me, and incidentally the catalyst for the beginning of our relationship. Like many other game companies, it all started with a “Hey, could you help me out with some graphics for this?” The Blimp was born.
Without any concrete ideas for the context, we just threw together a quick placeholder virus-buster type setting where you control some kind of TRON-like unit zapping viruses on a grid. Highly unoriginal, but as Bear says, sometimes it pays to just jump first and think next. We coined the name “VRAXIS”, which was a mash-up of “Virtual” and “Axis”. I knocked up some quick graphics to get some momentum going.
For about two months, we wrestled with this idea, but it was like a greasy pig, constantly slipping from our grasp. After numerous iterations, we just couldn’t seem to find a good direction to take “VRAXIS”. Bear experimented with ideas involving disappearing and reappearing targets as well as a few other quirky twists, but in the end, we concluded it was all just feeling too ordinary. Who knew that Blimp cockpits had shelves that were so handy for storing sad, failed prototypes.
From The Ashes Of A Brick-Breaker
One day during a session working on “VRAXIS”, a frustrated and distracted Bear was struck with an idea for an action game that was a mixture of Pong and Breakout: a dual-paddled brick-breaker game that was played on a vertically scrolling play field. Bear showed me a loose prototype, and we both agreed that this idea had the potential to become something great. Our first pivot ensued (airships can turn really quickly when they need to, you know). For whatever reason, ideas came fast, and before we knew it we were releasing our first ever title: Ambi-ON.
Ambi-ON was less than successful. We had produced a game that looked good enough, had a killer soundtrack, and played well, but due to a few key shortcomings in the game design, too little effort put into marketing, a lack of practical experience with freemium models, and perhaps just a general lack of attention for the entire brick-breaker genre itself, Ambi-ON simply failed to secure any lasting attention.
This was the birth of Mosaique. Frustrated that our beloved Ambi-ON failed to garner any popularity, we wanted to seek revenge on the entire industry and create Ambi-ON‘s exact mirror image; an “anti-Ambi-ON” if you will. Where Ambi-ON was a dark action game with a particularly sadistic tone (it even has an “Ultimate Pain Mode,” as well as a cyborg that pops up to insult you and all humankind at Game Over), it was only fitting that Ambi-ON‘s opposite should be something that was serene, calm and light. We concluded that with some judicious massaging, “VRAXIS” had the potential to become this. Back onto the workbench it came.
Our Music-First Approach
For no particular reason, during Ambi-ON‘s development, I actually created the music first. As it turned out, doing it that way served us very well. We found that using music as a guide to keeping the various elements of the game consistent was actually extremely effective. Compared to post-it notes on a whiteboard or concept art, music has a far stronger capability to evoke emotion, and it’s that emotion that can be used as a compass to guide the design of a gaming experience. In addition, centering a game around the music also makes the planning and tweaking of game pace and momentum very easy. To fit with the profile of being Ambi-ON‘s opposite, I created a 10 minute long semi-ambient electronica track in 5/4, aiming for a peaceful, sophisticated and also accessible feel. This would become the spine of the game.
Bear started to work through ideas for puzzle mechanics that were more relaxing and fitting with the music. A game that came to his mind was one of his old SNES favorites Zoop, which had a great colour-matching mechanic, but was time-based and very stressful. He injected that Zoop colour-matching mechanic into “VRAXIS”, but left out the other white-knuckle aspects of the system. Our game was to have no time limit and very little pressure put on the player, but still needed some way to get a Game Over. We resurrected the original limited shot count idea from “VRAXIS”, and added it as a gauge style shot counter.
In line with the music, the mantra was “sophisticated yet accessible”. Puzzle games are all too often totally abstract (with good reason, in most cases), so to retain some sense of accessibility, we decided to ground the visual interface firmly in reality. This called for a design that resembled an actual hardware device instead of a software interface. The idea was that you would hold in your hand an actual functioning puzzle game, not a mobile phone running puzzle game software. This was the result:
Further tweaks were made to the colour scheme to pull it closer to the music’s slight tinge of sadness and melancholy. And finally, the name “VRAXIS” had to go. It was an awkward remnant of the old setting. We decided on the name Mosaique, intentionally choosing the French spelling for no other reason than it feeling more sophisticated to us (you guessed it, neither of us speak French) without seeming inaccessible or foreign.
The core mechanic to the game was completed, the music was done and the interface was in place. Unfortunately it was at this late stage that we realized this game would be a great experience once, but didn’t inspire much incentive for replay. Bear then had the idea of introducing a mechanism that would encourage the player to play the game every consecutive day for bonuses. As the game was completable in 10-minutes (to match the length of the soundtrack), this was the perfect complement. The short game length would impart little burden on the player’s daily schedule, and directly giving them incentive to play just a bit every day would keep them coming back.
Again, as a reaction to our inability to create a successful freemium game in Ambi-ON, Mosaique was to be proudly premium. 99¢ would buy you the entire experience. No limitations, no wallet-fondling, just good old fashioned value for money.
Mosaique Takes Flight
The release of Mosaique went extremely well. It was featured on a number of high profile sites (including Gamespot, C-NET, Joystiq, Gamezebo, and Touch Arcade), and also had a consecutive run of three weeks on or near the top of Apple’s App Store (New & Noteworthy, What’s Hot and Popular Puzzlers). Also, this:
Yes, that is Mosaique in Craig Federighi‘s demo of iOS7 during the Apple’s 2013 WWDC Keynote. Of course, an accolade like this does not lead to much in the way of downloads (who would see that screen and then go and buy the apps on it?!), but it certainly was a thrill for us and makes for a great story.
The 99¢ price point has meant that Mosaique hasn’t been hugely profitable, although it has successfully recouped all of our marketing costs. Regardless, we are simply happy to have achieved some modest success with a “proudly premium” game in the casual puzzler genre; a genre that is so saturated with high quality freemium alternatives. It’s also been a deeply gratifying experience having some degree of popularity for something we created together. It showed us that there is merit in the process we followed, and also great potential for the future of our creative relationship.
Patience is a Virtue
There was one interesting road bump in our development process for Mosaique: when you follow a process that involves a rough playable prototype that is eventually refined with finalized graphics, do not lock down the graphics too early. If there is any additional work required on the prototype to improve user experience, game features or replayability, by adding final graphics too soon, all you are doing is creating inflexibility and possibly reluctance to consider all options.
The visual and interactive elements of Mosaique were all fully formed at the time we realised the game needed more replay incentive. Had the game still been in a light, flexible and adaptable prototype stage, I’m sure that there would have been potential for a far greater range of solutions to the problem of replayability, and also greater freedom for brainstorming.
So for our future games, we intend to try and complete a fully encapsulated prototype prior to adding any finalised graphics. Hopefully this way, all the core elements of the game will be more visible without the distraction of pretty graphics, and drastic changes can be more efficiently applied if necessary.
Winning Blimp is gravitating towards platforms that are conducive to more interactive bandwidth and extended play sessions. They are always looking to connect with players, developers, and artists, so feel free to get in touch through Facebook or Twitter.
This is a guest post by Yaniv Nizan who is the CEO and Co-Founder of The SOOMLA Project, the platform for Creating In-App Purchase Stores for Mobile Games. You can follow Yaniv at @y_nizan.
Since Apple launched its In App Purchase functionality, it has been supporting two types of virtual goods: Consumables and Non-Consumables. With consumable items, the developer expects the user to consume the goods over time and possibly replenish the supply. Tokens, Coins and points are usually consumable goods. On the other hand, Non-Consumables are expected to last forever and can be used to implement extra levels, remove ads feature or upgrade to a premium version of the game.
One might note that this definition only applies to virtual goods that are sold as a cash transaction through the Apple In App Purchasing functionality. The Consumable items allow more flexibility to developers who can use them to design many types of virtual goods with different consumption models, including ones that last forever. The Google Play terminology of Managed Items (equivalent to Apple’s Non-Consumables) and Unmanaged Items (equivalent to Consumables) is more respective of the fact that developers can manage the consumption of their virtual goods based on different models.
Using In-App Purchase in mobile games requires more types of virtual goods then what is provided by the App Store, and many game designers find that there are at least four additional types: Single Use, Lifetime Use, Equippable Items and Item Upgrades.
Here is a short description of the different types:
Virtual items that the player can only use once before he has to purchase more are often called Single Use goods. These goods can normally be accumulated so the user has a balance of them. This type of goods is very similar to the original meaning of Consumable items but since Consumable now has a wider definition, we need to redefine these goods as Single Use. Another difference is that a developer can limit the accumulation of Single Use items. For example, you can only carry eight bullets in a cartridge. Good examples of Single Use items are shots, fuel and fish food.
These are virtual goods that are available for the player for as long as he plays the game. They are somewhat similar to Non-Consumable products with one big difference – they are not purchased directly as an In-App Purchase but with virtual coins. From this reason, the developer can’t rely on Apple’s Non-Consumable type and has to design it’s own way of preserving the goods for the user. Race tracks, Game Upgrades, and Buildings are good examples of Lifetime Use Goods.
Equippable items are a sub category of Lifetime Use items. The main difference here is that the user has to choose a virtual good before he enters the game play mode. Cars and Characters are usually implemented as equippable items.
Unlike upgrades to the game itself that are normally defined as Non-Consumables (Remove ads) or Lifetime Use (Double Coins), these items upgrade some attribute of another virtual good. There is usually a strong bind between the original virtual good and its upgrades so that an upgrade is only applicable to a specific virtual good. In some games, a Tire can be an upgrade for a Car while in others, Coin Magnet Level 2 will be an upgrade for the basic Coin Magnet. Item Upgrades are normally implemented as Lifetime products.
This is a guest post by Yaniv Nizan who is the CEO and Co-Founder of The SOOMLA Project, the platform for Creating In-App Purchase Stores for Mobile Games. You can follow Yaniv at @y_nizan.
Game Developers for iPhone and Android these days are well aware of the Free 2 Play model and the benefits of applying it in the context of mobile apps to monetize through In-App purchases.
It is no coincidence that out of the $7 Billion dollars paid by Apple to mobile game developers, more than 80 percent was due to transactions made with In-App Purchase Stores.
Less known are some of the hidden traps in this model. Unlike with paid apps, Free 2 Play games are better thought of as a service rather than a product. More specifically, this translates into a lot more post launch effort that can easily add up to a full time job when combining the work spent on business issues, code maintenance and design updates.
Here are some areas in which you can expect post launch activity in Free 2 Play Games:
-Billing support issues
-Monitoring ratings and reviews
-Analyzing and optimizing user engagement and conversion into paying customers
-Trying out different advertising based revenue sources, integrating, evaluating and optimizing
-Integrating different plugins to increase user engagement
-Managing notifications and promotions
-Adding and refreshing content such as seasonal/holiday related content
-Monitoring different SDKs and maintaining the code that interacts with them as the API changes
-Adding billing providers in different territories to increase the likelihood of IAP transactions
-Identifying user segments and designing different app interaction when applicable
All these different activities add up to a continuous stream of tasks that quickly becomes an unexpected burden. If you take another look at the list, you will also discover that none of these tasks are fun or glorious— not really what you signed up for when deciding to make games.
The good news is that there are quite a few ways to minimize the effort needed for these tasks.
Here are 6 methods to manage these tasks more effectively,
1 – Separate the App Meta Data from the Code
This is the most complicated one, so let’s get it out of the way first. When writing the game code, identify every element that can be turned into a parameter and put all of them in a single file, list or database. This will be called your App Meta Data. Doing so can save you a lot of time when you want to update parameters in the game and tweak it later on. Architecting your code in this manner will also allow you much quicker integration with any backend (BAAS) solution down the line.
2 – Use Services that Aggregate Different SDKs
One of the things developers quickly realize once they start using third party SDKs is that each SDK requires maintenance as time goes by. Any service that aggregates different advertising providers or different billing providers can help you save effort on SDK maintenance.
3 – Focus Your User Acquisition and Monetization Strategy
Most game developers would like to improve user acquisition and monetization. There is a temptation to add more channels in each one of those categories. The result is that each one of these channels takes its toll and increases the amount of ongoing effort. There is work associated with monitoring the performance of each one and making sure it doesn’t decline over time. Therefore, it’s recommended to focus efforts on a small number of proven channels rather than chasing too many opportunities.
4 – Measure a Small Number of KPIs and Double the Analysis Intervals
One area that can easily suck up a nice portion of your time is analysis and measurement. In an extreme situation, you can find yourself gazing at the revenue chart and hitting refresh every five minutes. In most cases, the time spent can be reduced drastically by focusing on 3-5 KPIs and resisting the urge to open your analytics console too frequently. In fact, for most games, the optimal analysis interval is bigger than two weeks due to the small number of data points.
5 – Create a Score Card for Providers and Include Post Launch Effort
Another method that can sometimes save effort after game launch is simply increasing your awareness to the ongoing effort issue and adding this parameter when evaluating different SDK and plugin providers. Some even go as far as creating a Score Card for evaluating different providers and adding the post launch time consumption as one of the parameters.
6 – Choose Cross Platform Providers
Many mobile games want to expand into new hardware platforms after seeing early success. Typically, a game would start on iOS and then move to Android, Amazon and Windows. There is an obvious effort in porting the game to a new platform which can be reduced significantly by developing the game on a cross-platform engine. Now, let’s imagine that this was already taken care of and compare a situation where you are using 5 SDKs/Plugins and moving from a single platform to three platforms. If the plugins are not seamlessly supporting multiple platforms, you need to find new providers for each platform which results in having 15 plugins (five plugins times three platforms) to manage.
To summarize, the key is preparation, awareness and focus. If you are launching your first mobile game, you should familiarize yourself with these issues and take the necessary steps beforehand and you should be fine. This way, you will have your mind free to focus on your exciting new game.
Critical Force Entertainment Ltd is a new game development studio founded in Kajaani, Finland. The studio created Critical Missions: SWAT, a first-person shooter available for iOS, Andriod (released under Studio OnMars) and playable on Kongregate. The company focuses on developing premium and free-to-play crossplatform games with a special focus on the Asian market. So far, the company is self-funded, but investors are welcome.
Veli-Pekka Piirainen is CEO and founder of Critical Force Entertainment Ltd. He is a former studio manager of Supercell North as well as a lecturer and head of Kajak Game Development Lab. Piirainen is also co-founder of NMP Games Ltd.
A student’s hobby project
In December 2011, I hired Igor Levochkin – one of the students at a school I taught at – as a programmer in my new startup company after following his work for the past two years. Igor and I would make games for the Apple AppStore, and we started making a prototype of a game called BomberBall. At the same time, Igor put his hobby game project in Kongregate. Early January 2012, Igor showed me that there were hundreds of players playing his hobby project game, but I didn’t pay much attention to it. I just thought it could be a good marketing channel for our iOS game.
However, at the end of January 2012, there were a couple of thousand players playing it and I started to get more interested in it. I gave Igor a Sony Xperia Play phone and told him to port the game to that device. Igor managed to have it up and running in a matter of days. Next, I told Igor to port the game to iOS; this was bit more difficult since he was not familiar with Mac and Xcode. After a week, the game was also running on iOS. Now I really started to see some potential in the game. Despite all this work on Igor’s project, we also continued to develop BomberBall because I wanted to have a good prototype for the GDC in San Francisco. I demonstrated both prototypes at the GDC and Igor’s project, Critical Strike Portable, gained more interest from the public. After that trip, we decided to concentrate fully on Critical Strike Portable.
Keeping up with high popularity
Igor started fulltime development on Critical Strike Portable by adding new weapons and features. I still worked part time at the university and couldn’t fully concentrate on the game development. I trusted Igor and also a team of Russian volunteers, who supported us in the growth of the user community as well as map creation. Another important task was to make a proper and more user friendly User Interface (UI) for the game. Unfortunately, Unity 3D’s tools for this job were pretty limited and we didn’t have any artist or UI specialist in our team to design a nice, good-looking and functional UI. So Igor made a “coder-style” UI with many different settings and options inspired by Counter Strike style menus. That UI was easy to use with a mouse, but for mobile phones with touch screens, we needed a different kind of UI.
Because I was inexperienced in game marketing, I hired Teemu Riikonen in April 2012 to lead the studio as well as take care of publishing and marketing of the game. Our next employee was Thanabodi Thongchat, a 2D artist from Thailand. She started designing backgrounds and UI graphics for the game in June 2012. Igor implemented more and more features to the game like new game modes, zombies, graphical effects, as well as fixing bugs. We released new versions on Kongregate weekly and got feedback from players on how to improve the game. At the end of June 2012, we had nearly 30,000 daily average users playing the web version of our game, but we were still growing.
We got over 1 million downloads in one month.
On June 26th, we released a free Android version of our game with exactly the same UI and almost the same features as the web version. Even though it was not so easy to use and the menu elements were pretty small on a phone screen, its popularity surprised us. We got over 1 million downloads in one month.
But the problem was that many players didn’t continue the game after their first try. Only hardcore players did so. We decided to create a totally different and simpler UI for mobile devices, because the current quality was not good enough for Apple’s AppStore to sell it as a premium game.
At the end of August 2012, two game development students, Olli Lahtinen and Aapo Lehikoinen, started their internship in my company. They started to build a totally new UI, added new controls for the iOS version of the game with a new NGUI toolkit we bought from the Unity Asset Store and started to design new maps for the game with Hammer editor. We also needed new character models, guns and animations for the iOS version. Modeling and animations were outsourced to freelancers in Thailand and our Thai artist was leading that work. Unfortunately, the quality was poor and delivery was very late. After that, all animations were outsourced to two Finnish startup game studios and for the modeling of guns, I hired another student.
Unfortunately, we had to remake all maps done with the Hammer editor (16 total), because our lawyer said we probably weren’t allowed to use that tool, since it’s licensing agreement is not clear enough. Our lawyer also recommended us to change the name of the game from Critical Strike Portable to something else, because that name reminds too much of Valve’s Counter Strike (Critical Missions: SWAT was born then). Our original plan was to release the iOS version in the end of September, but it was released in the end of November due to these difficulties. A new Android version was released just before Christmas, a Lite version in the beginning of January 2013 and the Mac version is in the review process as of this writing.
The iOS market is very competitive
At the end of the year, the amount of our players had increased dramatically. We had almost 200,000 daily players on the web and over 100,000 daily players on mobile devices, but all were playing our free versions. Monetizing with premium version seemed to be much more difficult than we thought it would be. The iOS market is very competitive and full of games, so getting visibility is very hard. We also had bad luck with a very important review, because the reviewer didn’t like our controls at all (many other not so significant reviewers did like them, however). Because of this, we didn’t start to get income fast but our server costs rose dramatically due to the massive amount of users. We also had some trouble with one specific server provider, who just calmly cut off the lines to our map server without any warning due to dramatically risen network traffic.
Our biggest mistake was to save money in wrong places and get low quality from our international freelancers. We trusted our own artist’s capabilities to handle leading of the outsourcing, but she was too inexperienced for that. Of course, rates a quarter of the price compared to local studios were very attractive, but then the harsh reality revealed we had to do everything over again after that miserable trial period. It would have been wiser to use more professional outsourcing studios in the very beginning.
Our second mistake was not to solely focus on Critical Strike in the very beginning, but to also make the BomberBall prototype. Something else I would change was not to have a tighter management; everything went forward more or less without proper planning and scheduling. A fourth mistake was not to take a professional publisher to publish the premium iOS version. We thought it would be easy to self publish, because we had such great success with the free Android version, but we were wrong. A last mistake was not to pay enough attention to the server capacity, but that was more or less because of our inexperience with servers and also our idea to save money.
The team is currently working on a new game, called Critical Missions: Space. It has the same nostalgic fast paced FPS gaming experience as Critical Missions: SWAT, with the addition of space rangers, space pirates, laser guns, aliens, space themed maps and more.
Next to that, they keep adding more to Critical Missions: SWAT. They’ve scheduled new guns, characters and maps as well as unlockable content for the next update of their very popular shooter.
TAGS is a brainchild of Rajat Ojha and he is supported by the incredibly talented and driven Atul Sharma and Ajay Singh. There are 10 others who joined the talented team of TAGS. Team TAGS is considered as the most experienced team in India and the only team which has experience in mobile, PC and console game development.
When we started The Awesome Game Studio (TAGS) in April 2012, we had just branched out of a behemoth where we had been doing some serious console stuff and defense simulators. Some unacceptable decisions were made and we ended up with the idea to continue our journey in the game industry only and keep making awesome games. Coming from a console background, it was challenging because we had been completely ignorant about mobile market. The choice we had was doing something we already know or doing something new. Somehow in our case the latter would take less time than doing something we already knew, so we decided to try this. This was the first decision in the development of a game that would later be known as Wobble Bobble.
Minimalism is a good thing
The next challenge was to decide what exactly we wanted to do. We decided on two important things: minimalism and simplicity. Minimalism is a good thing, because you don’t have to go overboard with graphics in order to create a nice game. We focused on a game that was simple to play, in a way that it would benefit from the possibilities of a mobile device. The advantage of having a simple game also means that you can count on it to be almost bug-free. This all would turn out to be a big lesson for the entire team, as we had always been thinking of big games and big platforms. Going back and trying to do something really basic was a big challenge for all of us.
The entire team was assigned to think of an idea that would fit the above points and within a couple of days we had 15 ideas to choose from. After some discussion, we decided to do Wobble Bobble, an idea by our physics programmer, Ankur Aggarwal.
Some of the criteria we had while brainstorming:
1. Short, but addictive gameplay
2. Developed specifically for the device – it should not look like a port
3. One hand controls
4. Iterative – we wanted to focus on one simple game mechanic and focus further development on adding different pickups, modes and themes to keep the title fresh. Nothing deviates from the core mechanic, but the game constantly improves.
Expectations grow, Scope grows
When we started our work on Wobble Bobble, it was a very small game. The goal, our one simple game mechanic, was to keep the ball in the center of the table for as long as possible. By keeping the ball in certain circles in the game area, the player would earn points. We kept this feature and started thinking about expanding the gameplay mechanics to make the game more challenging. There was an immediate need to add fun to the game, and we took a routine path of adding new modes to the game. We added Challenge and Arcade modes and renamed the first mode to Classic mode. When we showcased the game to gameplay testers (including some industry leading people), they found the Arcade mode to be more fun. Because of this, we decided to make the arcade mode the standard.
Mistakes made, lessons learned
Since Wobble Bobble was our first attempt to do a true mobile game, we faced our own share of problems. Luckily, every problem taught us something we can incorporate in the development of new games.
One of our biggest mistakes was only checking the performance of the game on the latest iPod Touch and iPhone 4S. The game was working absolutely fine on these devices. When we tested on older devices, we found out the speed of the game was too slow. The speed of the ball used to depend on the processor of the device. When developing for PC, we take great care of issues like this, but we never bothered while developing a mobile game. We managed to fix this issue using Delta timing. In short: delta timing is used to handle complex graphics or a lot of code, by defining the speed of objects so that they will eventually move at the same speed, regardless of processor speed.
Another problem came from testing the Android version of the game on a Samsung S2. On the S2, everything worked perfectly fine, but on a Samsung Note the game would crash. We decided to do some quick ‘n’ dirty resolution tweaks so it would run on Samsung Note too. However, when we launched the game, we realized these tweaks were temporarily solutions for a bigger problem: Cocos automatically resizes the screen for Android. After more tweaking, we got everything working, both speed and resolution were permanently taken care of.
It was still a near perfect project
Though there were issues related to the shift, a lot of things went in favor of the project.
No major feature changes – Up until the development of Wobble Bobble, we had never worked on a game where the basic planned features never changed. Though we improved the basic gameplay mechanics of Wobble Bobble, no major changes occurred. Throughout the production, we were always aware of the exact scope of the game and things were neatly planned.
Our strong project management roots – Coming from large game projects, we always relied on strong project management. This worked in our favor as we had Microsoft Project, MantisBT and SVN running on our server, helping us to stay close to reality and allowing us to always have an up-to-date version of the code. There were stand up meetings every day and all the tasks were regularly updated in the Microsoft project. All the bugs were tracked in MantisBT and everything was accessible from home as well, so we always had access to what was going on with the project from anywhere.
Iterative Implementation – We never had a huge game design document written for the game, so we approached each module of the project as totally individual. Frankly, we didn’t even know what additional module will be added next, while working on the current one. We focused on perfecting one feature before even thinking about what the next feature would be.
A solid team – The biggest achievement of this project was that the entire team stuck together and kept sharing and debating ideas. Nobody in the entire studio was away from this project and everybody participated willingly. In most of the studios, the Pareto principle is in effect, i.e. 20% of the people doing 80% of work. In our studio, it seems like we only have the 20%, in a way that everyone is productive and 100% focused on the game.
The development of Wobble Bobble also saw people coming out and taking responsibility at an extraordinary level. For example, our QA manager took the responsibility of managing daily stand-up meetings and making sure things were transparent.
Playing games – In our earlier setup, we used to have at least 1 hour of Team Fortress 2 or Call of Duty LAN matches a day. We used to encourage everybody to play games whenever they were free, so there used to be a lot of single-player games, game-related discussions and showcasing in the office. When we started TAGS, we were busy working on games or game pitches, rather than spending time playing games. Most of the guys used to play 3 hours a day, but the initial struggling period left us wanting to focus more on development and gaming took a hit. We weren’t happy about it, but we had no choice. However, there was one thing that we religiously maintained: to stick to a five days a week schedule, so that the team could spend some time at home and play. It was a tough decision but we were spending more than 12 hours a day in the office. We all knew that it was a temporary phase and currently we are back to being normal, and normal people play videogames!
China’s numbers were unexpectedly huge
When the game got launched on June 27, 2012, it immediately caught the attention of a lot of people. We got decent review from gamers, even though we didn’t have the money for decent PR. Still the game spread with the word-of-mouth publicity.
We developed Wobble Bobble Pro, but it didn’t pick up sales at all. Anyhow, our focus was not to make money with this game, so we immediately made the pro version free. Surprisingly, it became a huge success in some countries like USA and China. China’s numbers were unexpectedly huge. Many people like it so much, that they asked to have a tournament for the game, so we set up a separate Facebook page for players and the contest. We were actually really shocked to see people scoring millions, scores which a lot of our developers couldn’t get (except our QA manager).
This contest helped Wobble Bobble to establish itself and establish the all new brand The Awesome Game Studio.
Right now, TAGS’s hands are full and they say they feel like those typical Indian Gods with 4 hands. They are working on one of their most ambitious mobile IP which is called Alphaman and will be released in Q1 of 2013. TAGS has signed a three-year contract with USA-based toy manufacturing company Imagability Inc. to develop games across all the platforms. TAGS is working for a Fortune Five company on one of their brand IP. In all these projects, they strive to maintain control over the game design and processes which gives them complete creative freedom.
Apart from all these, TAGS is also working on a console game which is in Pre-Production right now. They hope to continue their awesome journey.
Arges Systems is a micro-studio doing game consulting and application development in Unity – their specialty is on game logic and AI. Arges Systems has been partnering with companies specializing in 3D graphics and visual design, as well as doing contracting for companies building games with Unity. In this article, Ricardo J. Méndez (founder of Arges Systems) shares some insights on their just-released Hairy Tales.
I initially founded Arges Systems to take advantage of my experience running remote teams and projects. We had been doing contracting on various game projects for a couple of years before I decided to switch gears and start working on our own stuff. I had just decided to pull the plug on a turn-based strategy game for which I realized the scope was too ambitious and was chatting with Yuriy Mazurkin, our concept artist, about possible themes for a follow up game. The conversation drifted to Russian illustrators – somehow we ended up talking about Ivan Bilibin and it got me thinking about action/adventure games.
A sword-wielding octogenarian riding a warhorse charges forward from a hill. Nordic forests and evergreen trees spread before him. He’s also butt-naked.
It was a simple, straightforward picture by Russian illustrator Ivan Bilibin, from his Marya Morevna series, and my first encounter with Koschei the Deathless. He’s an archetypal antagonist of Slavic folklore, an even more evil version of their better-known Baba Yaga.
I took one look at it and with its combination of adventure and absurd, I thought “damn, this would make for an excellent slavic Zelda-like game”.
You can’t get there… from here
I wanted to do a game that was different, and this wasn’t it.
I experimented with gameplay styles while Yuriy drafted some concepts. We drafted several ideas for scenarios, including a story, but it quickly became apparent I had nothing new to say about the adventure genre. I wanted to do a game that was different, and this wasn’t it.
Partly as a way to cleanse our creative palate, I started experimenting with mixing puzzles in. You had to maneuver the main character through a corrupted land, frozen in time, but elements got un-frozen as you approach them. This had pros and cons, since you could activate machinery just by being near it, but enemies also came alive. The puzzle aspect was to figure out what to do when. I decided to discard this version as well. It seemed like a one-trick pony, with the sort of read-the-designer’s-mind approach that I hate, and lacked replayability – once you know the solution, that’s it. Also, the game was taking on a somewhat stoic tone that I felt dragged it down.
You will notice I haven’t mentioned anything about the modeling side of things. We had overenthusiastically already started modeling before I was done with the design, because I wanted to get the time-consuming assets out of the way – or at least properly estimated. Despite it being a bad strategic decision, it had a positive side effect: it made me realize early on that the 3D artist we were working with just wouldn’t cut it. The quality of his work had been in decline, he wasn’t paying attention to details, and both Yuriy and I kept having to bounce work back to him with notes. Eventually I had to let him go and start looking for a new hire. Fortunately we found Ash Barnard, from the UK, who meshed with the team perfectly. He has an eye for detail, very expressive animations and more importantly, just the right sense of humor to make the Hairy Tales animations memorable and peculiar. Ash also brought in a good eye for gameplay, and helped criticize mechanics as I was coming up with them.
Through several experiments and iterations, I ended up landing on something close to the current approach. The first few iterations were fixed stages, based around arrows that directed them and fences that made them turn two sides to the right. It also featured a first draft of the spreading corruption, with the twist that if it spread to a tile with a fence, then it got corrupted and the fence turned into a deadly wall of flame. I can hear the thought gears as you try to figure it out. Playtesters weren’t getting it, and even when they figured out stages the reaction often was “I know this is how it’s supposed to be, but don’t know why”.
That would not do.
Dragging it there
I started paring down the elements. At this point we’ve been in a production iteration limbo for months, and all the associated hair pulling is starting to take its toll on me. Everything is self-funded, so Arges is hemorrhaging cash while we experiment, and my focus is split between the game and the client work that is funding the process. I started trying different games to relax – mostly playing demos, so I didn’t get too involved and lost track of the project. One day I was playing a demo of Atlus’ Catherine, moving Vincent around, pulling and pushing blocks into place, and then a light bulb went on. After simplifying the elements, the stages had felt too straightforward, and the new levels depended mostly on size for their complexity. What if players could drag tiles from one place to another?
I didn’t tell the team, just sent them a build where some later stages required them to move tiles. They were rather surprised at first, but immediately saw the possibilities, like tiles that drag Hairys from one place to another, weapons you can re-use or teleporters. So finally, after months of iterations, we had a design we were happy with.
The 90-90 rule
It took a lot to get from a game’s design to the final product, of course. We still had to design the look for the various tile elements as we were going, which kept Yuriy involved while Ash created the models and I both coded the behavior and came up with the stages. Yuriy was also helping with the texturing. His true love is painterly work, however, so he came to me when we were about to enter the final stretch and brought up that he wanted to move on.
As sad as this made me, since I enjoyed working with him, I helped coach him for interviews and gave him a sterling recommendation. He ended up getting employed by Yager in Berlin, who recently published Spec Ops: The Line, and I expect is right now working on their next project.
At about this time I brought on board composer Levan Iordanishvili as a contractor to work on the game’s music. He liked the game and offered to take care of the sound effects as well. To ensure both were cut from the same cloth – he did a smashing job of re-creating the sound that Ash’s animations made in your head when you looked at them, and his scoring of the three worlds and bosses was top notch.
I had initially planned to release with five worlds and five bosses worth of content, for a total of 75 levels (15 per world). Playtesting had demonstrated that players needed a gentler level progression than the breakneck pace we initially had, so each world had increased to 24 stages. If we kept the same number of stages per world, we were looking at 120 stages total, plus the extra time it would take for the two other bosses and possibly new enemies to keep things lively. The scope was getting out of hand.
I made a judgment call. We would be launching with 72 levels and three bosses, using some minor characters as mini-bosses. Once we saw the initial reactions to these levels from our players, we could release a couple more worlds as add-ons and expand on those qualities that players enjoyed the most. The team agreed, and we geared up for polishing the worlds we had fully designed.
The initial stage sequence introduced one concept after another, presenting a more concentrated experience which gave the player little respite, with no stages that they could use to experiment with the mechanics they had just learned before throwing a new set of concepts at them. After various rounds of playtesting, I introduced some intermediate levels that presented the concepts they’d just learned in different contexts, so that they could play around a bit more, which made the initial learning process smoother. However, it also led to the initial stage sequence feeling a bit drawn out, so I then had to adjust the sequence once again. This process went on over several iterations, even after we had released.
Launch and everything after
We wrapped what we considered to be version 1.0, went back to talk to some publishers we’d been in contact with, and settled on Forest Moon Games and BAM! The game was out the gate.
The game is currently sitting at a Metascore of 81
It was exceedingly well received by reviewers – sites like TouchArcade, EuroGamer and Gamezbo gave it glowing reviews, praising its flexibility, difficulty and character. The game is currently sitting at a Metascore of 81, the highest Forest Moon Games has gotten (and one of the highest of its less-experimental sister brand Crescent Moon Games). Apple picked the Mac version of the game as an Editor’s Choice on the Mac App Store, and gave it a humbler New and Noteworthy feature on iOS.
However, commercial reception was merely lukewarm. We were aware that the characters, not being your traditional cute-and-cuddly puzzle game stars, would be an issue. But we were not sure what was the main problem. The initial game difficulty was rather high – a throwback to the old school puzzle style – which might be turning off casual game players who get it expecting an easier time and hurting word of mouth. At the same time, the visuals are cartoonish, which leads players who would appreciate the challenge to dismiss it as a merely a casual game. Once we get it in front of players they usually love it, but doing so takes a fair amount of effort.
We’ve also had an overwhelming amount of piracy – 95% piracy rates on iOS and Mac, with Windows being well over 99% (Windows sales are comparatively a rounding error). It’s great that players are enjoying the game but having gone with a design oriented towards making it a premium app instead of a freemium game means we get no benefit from those playing it for free – not even a ranking increase.
We have continued supporting the game, releasing so far three minor and one major updates, including an adjusted difficulty curve and 12 new tutorial levels (bringing the total up to 84), but as of this writing that update has only been out for a couple of weeks – it still remains to be seen what effect it will have.
Where do we begin?
Target it, goddammit – We focused too much on the gameplay and on crafting characters with a personality we enjoyed, without considering if we were sending out mixed messages that could confuse players, alienating precisely those we wanted to rope in.
Cut the dead weight early – the initial modeler and animator just wasn’t working out, and keeping him on board for longer than I should have was not only an expense I could have saved, but risked losing us an invaluable team member. Deal with these problems sooner rather than later.
Be ready to trim – we have a plethora of characters and elements we just didn’t get to use because we simply had no time to properly develop them. As much as you love your designs, chances are a lot of them will end up having to be left out.
There doesn’t seem to be a middle market on iOS apps anymore
If you’re indie and working on a premium app, reconsider – there doesn’t seem to be a middle market on iOS apps anymore – it’s almost all either huge AAA-quality projects, or simpler one-mechanic freemium games (and some freemium games have been getting shinier and more elaborate). Do you really want to bet the house on a business model with a piracy rate higher than 90%, when the market is flooded with competing titles that players can get for free?
Where to go from here
Stubborn as we are, we find ourselves already working on our next title, after going through multiple prototypes and even more concepts – this time applying the lessons we learned from Hairy Tales. I expect we’ll manage to retain the spirit of experimentation and sense of humor that we imbued the game with, while setting it into a game design more fitting for today’s game climate. Wish us luck!
Dynamic Pixels is a leading mobile games developer based in Russia and CIS. Established in 2004, the company has grown into an experienced studio with almost 40 titles for java, Android, iOS and Bada. Dynamic Pixels games are distributed by content-providers, operators and vendors across South-East Asia, Middle East, Far East, South Africa and Western Europe, reaching in excess of 5 million players across the world.
We are all fans of the tower defense genre. So when the question of what kind of game we would like to develop came up, we knew it would be a tower defense game. But knowing the genre was not enough. What we needed was at least the slightest idea of a style or some kind of plot for the game. We spent days and wasted tons of pizza trying to figure it out, but in vain. At that point, our programmer saved the project. We still don’t know how, but he did it. When everything seemed to be lost he came in and said: “Let’s develop a tower defense game based on sports!” And you know, it clicked: the turrets and creeps would be transformed into sportsmen, the battlefield into a sports ground; a humorous touch would level the usual view on sports as a protracted process.
Being generous doesn’t pay off (or does it?)
We wanted users to feel free to enjoy the game at its fullest
It’s very important for the rest of our story to mention that we planned on earning some money on the project. That is why we thought out the business model of Goal Defense even before we started development. We decided to give the game an extremely loyal model of monetization. Basically, users had access to all in-game features and could finish Goal Defense without purchases and tiresome replays.
Why? We hoped that loyal monetization at release would help us get: (a) a high number of downloads, (b) top 10 spot in categories and (c) a large and constantly growing user base. After reaching these goals, a series of updates would take care of the monetization (high profits). In other words, we didn’t want to make users pay. We wanted them to feel free to enjoy the game at its fullest. In this case only truly addicted players would purchase anything. And though the percentage of those is very low, we hoped a huge user base would make this percentage rather substantial.
From free to temporarily paymium
The release of the game went great. Goal Defense managed to reach the 6th and 7th spot in the top lists in the US. We even received a letter from Apple, saying that they were considering the game for a feature in the AppStore. However, as good as the release went, a month after (and after more than 350,000 downloads), we realized we didn’t reach or goals in the first place. We had a high-quality project, lots of positive reviews, but Goal Defense didn’t become as big as we had hoped. The project could not boast an exceptionally high rate of downloads and, consequently, didn’t bring in much money! We didn’t panic. We simply switched to a ‘paymium’ mode, until we could make a well-informed decision. Which meant that we had to figure out how to make users that are not inclined to pay buy something. This required some analysis.
We figured out:
– at which point users left the game and why (Goal Defense: in the middle of the first episode/6th level, mostly because it was too difficult to play);
– how many users kept playing the game after aforementioned point and how many finished the game (Goal Defense: 50% kept on playing and 30% finished the game);
– at what point in the game user made their first purchase (Goal Defense: at the start of the second episode/11th level);
– what they bought first (Goal Defense: bonuses);
– the sum of the first payment (Goal Defense: $1.99);
– what items were bought more often (Goal Defense: bonuses ‘hail’).
From this data we understood that we had to:
– motivate users to buy sportsmen as they are more expensive than bonuses;
– nevertheless increase the number of bonuses they buy;
– make the game easier at the start;
– motivate users to make purchases during the first episode;
– motivate users to make purchases.
We came up with a series of updates to be released. A couple of weeks after each update we would repeat our analysis to check on the effectiveness of the updates. Each update included new features. The features were picked taking into account the expected effectiveness of the feature, the expected reaction of the users and the expected amount of time for its introduction.
Goal Defense v1.0.1
Goal Defense v1.0.2
Goal Defense v1.0.3
Goal Defense v1.0.4
Raise the game virality
Motivate users to buy diverse bonuses. At that moment ‘hail’ was the most popular bonus.
Motivate users to buy sportsmen
Motivate users to buy sportsmen and bonuses and do this earlier
Features added/purchases introduced
– Recommend the game and get in-game currency
– Introduced an automatic launch of a free bonus. When a user was on the verge of loss a bonus would appear to show how effective it could be.
– Switched off the auto unlock of sportsmen and bonuses (basically left only one sportsman and one bonus to play with, to unlock the rest the user had to buy them with crystals)
– Placed certain sportsmen from the shop on the field on some levels with a consequent proposition to buy him. Thus we ‘advertised’ them.
– Follow us on twitter and facebook and get in-game currency
– Improved the tutorial and the descriptions of bonuses in the shop
– Introduced the pop up of a shop window after each loss to motivate the user to buy smth
– Raised the price of bonuses. They were more difficult to acquire and users had to solve problems in some other way: by buying sportsmen!
– Switched off crystals acquisition after the level replay. You win the level – you get crystals, you replay it – you don’t.
– Made the first 10 levels easier
– Improved the description of sportsmen in the shop user clear
ARPU – 40%
These measures affected the gameplay. It became less diverse. But the problem was that users managed to finish the game even with one kind of sportsmen and 1 kind of bonus.
ARPU + 103%
Paymium is a great way to get any money for your project […] but it is never as effective as hard, well-thought monetization
Concluding from our own experience with Goal Defense, loyal monetization may bring you lots of positive comments, lots of traffic and favorable reviews. However, your game will never reach the top 10 and you might not be able to break even on development of the game. In short, paymium is a great way to get any money for your project, without the need for further updates, but it is never as effective as hard, well-thought monetization.
Hard, well-tought monetization should be aimed at those who do and those who do not want to pay. Especially the last group is important. If your user base is not very substantial you’ve got to make the most out of every user. It is hard, but if you find a way to do this you’ll be astonished by your financial results. Besides that, monetization, in the way we used it, requires constant monitoring and analysis until it’s perfected up to the stage of “wow, that’s a great deal of money we get here.” And for that you’ve got to find a way to integrate data collection into the game.
There’s still lots of thinking and analysis to be done in terms of Goal Defense. A few more updates are to be released. We strongly believe that the best has yet to come so we’ll go on pushing it up.
Goal Defense is available on iOS (iPhone, iPod Touch, iPad) in the AppStore. It’s available for Android as well, on Google Play. Check out Dynamic Pixel’s Dev Blog to see what the development team is currently working on.
The Global Game Jam and beyond series sheds light on the few brave Global Game Jam (GGJ) teams that have decided to take their GGJ projects to the next level and continue development after those challenging 48 hours. We ask each team to tell about their experiences, share learned lessons and offer advise on their attempt to turn their Global Game Jam project into a full fledged commercial product.
Last year’s edition of the Global Game Jam saw its biggest entry of games yet. Combined with the rather obscure theme of Ouroboros, the ancient symbol of a serpent or dragon eating its own tail.
Based on the Oroborus theme for the GGJ2012 the team behind the quirky one-button arcade game Catch-22 wanted to make a game in which your actions bite yourself in the ass. This resulted in them not only winning the local competition at their jam site, but later also won a prize for being the best Dutch Global Game Jam game. Catch-22 also later became one of the PAX 10 selected indie projects to be showcased at the PAX Prime event in Seattle back in August 2012.
Catch-22 has been in development for iOS ever since.
After we finished the game we realized we made a game in which there is no AI entity or anything attacking you in the game, but yourself. Contrary to normal arcade games, Catch-22 doesn’t pump you full of adrenaline with upbeat music and flashy stuff, or send in hordes of enemies towards you to defeat. You do that by yourself, because this game is all about the endless battle you have with yourself. That idea was truly unique and something that we hadn’t seen before ourselves, so we decided to continue developing Catch-22.
What triggered your initial consideration that your game was worth to continue development?
We didn’t have the idea that our game was worth continuing until after the GGJ ended. We only came to insight on what our concept was worth after the Jam, when we won first place in the national Dutch Global Game Jam. During the Jam itself, we were really just focusing on making the game, were exhausted afterwards and just glad we finished it.
Since our game is a one-button game it’s really easy to port it to any platform since you don’t need a controller. We also made it in Unity 3D, which gave us the power to port it to handheld devices (iOS and Android) instantly. So we figured; why not?!
What do you believe was the main element of your game that allowed it to be commercially viable?
After the jam we had a working proof of concept and it only need a lot of polishing. Next to that the game doesn’t require a specific input device such as a controller so it’s easy to port it virtually to any system. And again, Unity 3D gets you a long way.
What really got things in motion was that we got the Dutch “Gamefonds”, a local subsidy for creative projects, to financially support the development of the game just one month after the GGJ. I’ve seen enough projects die young because of the lack of funds, and our project almost suffered the same fate. The funding enabled us to finish the game, fly our butts over to A MAZE IndieConnect, PAX Prime and IndieCade, and hire the necessary artists to work on the game. We simply couldn’t have done it without this initial starting money.
How did you manage the step to go commercial in your team?
We have a really simple way of working which translates to this line; Drink beer, smoke cigarettes and make video games. Rinse and repeat this until the fat lady sings. Really, just flip the switch and go for it, because there is only two ways of doing things; Do them really well, or leave it for someone to do it really well. Because making games is hard, tedious work and you, my friend, are not a robot.
What were the three most important experiences/learned lessons and/or challenges that you had while further developing your game?
Make some solid agreements beforehand
First of all, make some solid agreements beforehand. If you do get in a situation where there is a conflict within the team, you can still have a level of conversation where you can clear the air. If you don’t do this, then be prepared for some hard loving from your close friends. For example in our team, team member Roel had spend a lot more time into the project in the beginning stage and wanted to be compensated for it. I agreed, but team member Marlon didn’t and had his own reasons for it. In the end we arranged to have a team leader (aka a neutral party) who overlooked the project and could talk to us as a supervisor. This made all the difference for the balance within the team. So unless you have really, really good agreements, you can’t simply overcome the possible conflicts that arise within your team. There are one too many teams who think they can do without a good agreement, and it just doesn’t work like that in any kind of game development setting.
Make sure you get your long-term focus right
Second, make a plan to where you want your game and/or company to be in a few months. Make your goals achievable, because just talking about it with your team will not just make it happen by itself. Things change over time and personal situations can get the upper hand if you don’t. I got de-motivated by the fact that things took too long or just simply weren’t done during a certain period of development. Motivation is the only thing that keeps you going when making games, whether it’s money or just finishing your game. So get your mind straight and make sure to get your long-term focus right. Nearing completion, we would regularly go out for drinks and enjoy ourselves from time to time. Having the release of the game within reach, things got a lot less stressful. Most conflicts took place at the beginning of the project. In retrospect, we also stayed motivated by the achievements we got in the meantime; from winning the GGJ to getting 25k honored, to being selected for PAX10 and IndieCade, and finally the release ahead. Having stuff to look forward to is great, especially finishing your game.
In your case, what did you learn from getting the game out to the public?
Start doing this as soon as possible. You will be surprised where it can take you and your game! We can’t stress people enough to do this. If you feel uncomfortable doing this, talk to some people, practice and work on your pitch. Because the public doesn’t see your game like you do and their opinion is the most valuable one you can get. It’s also a really good way to test if your game is commercially viable. If you get some reactions from people who ask you if it’s already for sale or available, Ka-ching! You got game!
What kind of tips would you give to other GGJ participants who might decide to continue developing their project?
It takes time for your game to pick up momentum
Stop crying and making excuses to not release your game or get it out in the open right now. It’s the first sign of failure and I witnessed this in person at the company where I did my traineeship.
It takes time for your game to pick up momentum if you haven’t released any games before or are a well known game developer. Don’t think people will be jumping and begging for your game, because there is a lot of competition out there.
Last but not least, get accustomed to the Nike mentality; just do it! And that goes for everything in your project, from making your game to marketing and PR. Best practices come from experience, and it’s ok to “fail” on your first go.
Cath-22 for iOS can be downloaded in the AppStore.
Stolen Couch Games is a young Dutch game studio formed by six alumni from the Utrecht School of Arts who decided to continue working together after their college projects. A part of the team came together to make a multiplayer prototype for XBLA and PSN title Chime made by developer Zoe Mode in collaboration with the One Big Game initiative. Stolen Couch Games then reformed and expanded the core team with an extra programmer and artist. Gamesauce recently featured a post-mortem on their first game Kids vs Goblins.
Early 2011, everyone at Stolen Couch Games was still in school developing our exam year project Kids vs Goblins. Jay van Hutten, a fellow year mate, was developing a game of his own called Ichi. It was a elegant puzzle game that utilized a one-button mechanic in a way that didn’t feel gimmicky. The goal of the game was to guide a ball past a number of rings on the screen. By touching the screen you rotate bumpers, which caused the ball to change in direction. You could also hold your finger down to draw a line, once the ball hit the line it would travel back in the direction it came from.
About a half year later we spoke to Jay at a congress were he was demoing his game. I (Eric) shared my interesting in redeveloping Ichi for multiple platforms and making it a really great commercial product. Jay loved the idea and the day we finished Kids vs Goblins we were working together to make a bigger and better version of Ichi.
No developers were harmed during the making of this game
Because the core of Ichi was so sound, it wasn’t hard to come up with dozens of new puzzle ideas to make the game better.
Redeveloping a game is nothing new to us. Stolen Couch Games actually started in 2010 when we got an assignment from Zoë Mode to create a multiplayer version of their hit game Chime. The multiplayer demo we made eventually led Zoë Mode to develop Chime Super Deluxe, which featured some nice multiplayer modes. While the programmers were re-creating Ichi in Unity, Jay and I were designing new features to add to the game. Because the core of Ichi was so sound, it wasn’t hard to come up with dozens of new puzzle ideas to make the game better. The final product had teleporters, splitters to create multiple balls, objects that could disappear and a few more things. Nothing too fancy, but it all worked great. The best thing we added was the level editor that allowed players to create their own levels and share them online. Since then, 11,000 levels have been shared, quite a bit more than the 50 levels we originally included with the game. Ichi launched in June, after 3 months of development, which went mostly smoothly. The actual problems started right after we launched the game.
We knew that many people would consider Ichi as just another puzzle game, so we had to let people know how special the game really is. We spent about a week contacting the press about our game and we got a nice amount of coverage. But press alone won’t make your game a hit. If you read any guide on marketing for mobile games you always get to the point were the importance of getting a feature by Apple/Amazon/Google is expressed. We already got a feature on the Mac app store for our first game, but our published arranged that. We didn’t have a direct contact within Apple, so we had to come up with a way to contact them.
Luckily we had a few device IDs that belonged to Apple employees on our Testflight account. So we found out the matching email addresses and we send separate emails to every one of them. 2 of them, responsible for the iOS AppStore, loved the game and showed the game to the rest of the team. Our contact from the Mac AppStore was in love with the game. We Skyped for a few hours and everything was set.
We’ve seen developers doing no marketing at all for their games because they believe they’re games will sell themselves. This is mentality is wrong. Just look at the top grossing games on iOS. Almost all of them spend enormous amount of time and money on marketing. Only by spending time and money, will you actually earn money.
The lessons we learned from this is that you should be prepared for something you can’t predict or test.
The launch of Ichi went great. We were selling thousands of units a day and those numbers were actually increasing the days after the launch. But than something went wrong. Suddenly the game would crash once it has launched. This had never happened in any of our tests before. Why did the game crash all of a sudden? It turned out that the firewall at our server provider, which hosted the user created levels, was malfunctioning. Since we had never encountered this before we weren’t prepared for this. As you can imagine we were pissed off, but the gamers were even more pissed off. The 1-star ratings were poring in, so we had to work quickly. Within a day we made a quick patch that made the game run again. We submitted it and Apple was kind enough to approve it in record time. But the harm was done. The sales momentum the game had was gone. Sales plummeted because of the bad reviews. Instead of getting thousands of sales at $4.99 a piece we were down to hundreds.
The lessons we learned from this is that you should be prepared for something you can’t predict or test. We expected our server to send just numbers to the game, instead it was sending lines of random code. For our next games we’re making sure that the game handles these rare cases the correct way. One day of extra development time is better than losing thousands of dollars in revenue.
At the end of 2012 only 300 people out of 400.000 bought the in app purchase, an insanely low percentage
We wanted to use in-app purchases in the game to earn some extra revenue post-launch. We were thinking of putting an in-app purchase on the level editor. So if you wanted to make your own levels you had to pay a dollar extra. But we opted against this because the editor would generate content for the game. Content is important so we couldn’t make the overall package weaker to earn some money. Instead we asked for an in-app purchase when the player played more than 10 user-created levels. We guessed that only 5% of the players might create a level and 70% would play user created levels. More people means more revenue. Unfortunately this tactic didn’t work.
We launched the game with 50 built-in levels and player could play 10 user created levels for free. At the end of 2012 only 300 people out of 400.000 bought the in app purchase, an insanely low percentage. Why did almost no-one buy the in app purchase? We think it’s because people were done with Ichi after playing 50 build in levels. Nobody is going to play 10.000 user created levels, let alone 100. Ichi’s retention wasn’t high enough.
Getting a lot of players, quickly
Instead of letting our game die we looked at “free app of the day” deals.
A few months after the release of Ichi sales were basically dead. We were making about $15 a day, which didn’t get us one step closer to world domination anytime soon. So we had to do something. Instead of letting our game die we looked at “free app of the day” deals. The first free app of the day deal we did was Free App A Day (FAAD). In one day Ichi was downloaded 130.000 times. We were blown away by this number. After this we contacted Amazon USA if they could feature us. They loved Ichi and featured it as their free app of the day. After that, Amazon Europe featured Ichi as well. AppEvent did the same, resulting in another 30.000 downloads from mostly the Netherlands
Free app of the day promotions are great. Unfortunately it is unlikely that your app will become super popular once the promotion is over. We earned only $80 from the days after the FAAD promotion. But still it is better than nothing. One good tactic might be to get a lot of downloads using these promotions and then switch to a freemium model. You will have hundreds of thousands of players who will generate revenue though ads and/or in app purchases.
Critically, Ichi is a great success. We’ve gotten wonderful reviews and players seem to love the game. But commercially the game hasn’t done that well. We barely broke even on the development costs. Most of the revenue came from the Mac version, mainly due to the feature by Apple. iOS came in second, revenue-wise. The Android, PC and Linux versions didn’t make more than a few hundred dollars. Despite all of this we feel that Ichi was worth our time, it was great developing it and we delivered something we’re proud of.