I recently went to Berlin to prepare for the upcoming Casual Connect show there in 2017. While there I spent several days visiting a few game studios and other companies in the industry, and I would have to say my visit to GameDuell was one of the highlights of my trip.
I remember my first exposure to GameDuell; they were a Platinum sponsor of Casual Connect Europe. They had a really fun setup with very colorful cube chairs, a projector, big banners labeled “GameDuell is cool” and very eccentric people. If you are lucky enough to visit their office, you will probably agree with me that GameDuell is definitely very cool.
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!
Hunter Hamster Studio was founded in 2010 by Andrey Kovalishin and Maxim Yurchenko. Located in Bryansk, Russia they started out developing Flash games. Now they are focusing on mobile devices, while trying to maintain the fun and brightness of Flash games. Their AppStore debut is a game called Snail Bob, on which Andrey will be sharing some insights in this port-mortem.
The story of how Snail Bob was born on Flash
We started out by doing only Flash games. One day Maxim contacted me and told: “I have a great idea – to make a game about an automatically crawling snail. We can think out various puzzles to guide him from point A to point B.” He showed me the first Snail Bob image.
I liked the idea so I created a simple prototype: a crawling snail that you can stop and get moving again by clicking. Initially we wanted to give players the opportunity to drag physical objects, but after creating the prototype, we found out it made the gameplay too hard. In the end we settled on Snail Bob crawling by himself. The player controls Bob by using different levers, buttons and other tools in order to get him to the finish on every level. This resulted in a funny mix between physics, puzzle and point-and-click games.
We didn’t really have a main strategy, everything came out on the run
We started out development of the levels by sketching several levels on a piece of paper, from which I tried to assemble them. The result looked awesome! The gameplay was simple and Snail was likeable. Maxim drew a lot of funny animations and the game got even better. We decided that players, on their first glance, needed to understand which objects were clickable in order to complete a level. So we added hints to interactive objects. And it worked really well – nobody had difficulties in playing Snail Bob.
We didn’t really have a main strategy. Everything came out on the run. We just tried to think out as many levels at the same time as we could, trying various game elements and mechanics. Afterwards it became a distinctive feature of the series of games about Snail Bob – players noted that each level is unique and never gets boring. The only disadvantage of such a feature is the longer development time, as each level is programmed separately.
To make Snail Bob more likeable for players, we thought up a simple but compelling story, which players learned from successive images. Snail Bob’s house was crushed by building machinery and Bob had to escape from the site to find a new quiet house. Now, who can refuse to help a poor little snail? To make the game atmosphere funnier and more cartoony our fellow composer Dmitry Petyakin composed some funny music on a banjo. The melody was quite catchy and kids really liked it.
We even received touching e-mails from kids aged 5-6 which were written by their parents
When the game was released it became really popular. Especially kids loved the game. We even received touching e-mails from kids aged 5-6 which were written by their parents. Everyone asked us for new levels, so we decided to make a sequel. Snail Bob 2 was funnier, more cartoony and featured more unique levels. At this point in time, Snail Bob has 208 million gameplays; Snail Bob 2 has 200 million gameplays.
We saw the success of both our titles and decided to start developing a version for the Apple AppStore, since the industry was turning towards mobile gaming. Since flash games are free, but players pay for a mobile game, we decided that we needed to significantly improve our current game. We wanted to give the fans their money’s worth. To do this, first we added a new chapter to have 60 levels in the game.
Secondly, we started to think about a three-stars-system, since players on mobile devices are used to it. We decided on a few standard options, for example to give stars for the most rapid level completion. In the end, we came up with a completely new concept. Stars are located somewhere on the level and players just need to tap a star to collect it. But the stars were well-hidden and the player has to solve small puzzles to find most of them. It added replay value to the game and levels got longer for those players who wanted to collect all three stars. Subsequently, we received many positive comments on the new three-star-system, players noted its uniqueness and advantages compared to the boring “complete faster, get more stars”-system. On the flipside, implementing the new system resulted in more development time.
Third, to motivate players to collect stars, we added a gallery with funny cartoon snail pictures, based on Spiderman, Jack Sparrow, etc. When the player collects stars, pictures are unlocked.
Finally we released Snail Bob on the AppStore. The game faired better on the iPad. This probably had to do with the fact that on the iPad it’s easier to use various levers and buttons, rather than on the small screen. Below are the highest spots Snail Bob reached in the top lists of the AppStore.
We realize that it‘s worthwhile to try cross-platform engines before starting a project
Picking the game engine – We didn’t think this over enough. We chose Cocos2d because it provides the best performance on iDevices. But now we realize that it‘s worthwhile to try cross-platform engines before starting a project. We feel sorry, because porting the game to Android will be much harder.
In-App Purchases – Our game featured only one in-app purchase (unlocking all chapters) and it has increased our profits by 5-7%. I’m sure that if we focused more on IAPs we could have increased this number to maybe 20%. It’s better to think in advance and immediately implement IAPs, than to put it off and add in updates.
Updates – I’m sure everyone knows that you should prepare the first update before the actual game is released. And we also knew about this. While the game was approved by Apple and the publisher was preparing marketing stuff, we started working on the update. But then Apple released the iPhone 5, which meant we needed to spend time reworking the game to support this new resolution as well. As a result, the update was not ready in time, and when the game came out, we couldn’t finish it in time. I would advise to have two finished content-updates before releasing the game.
The more diverse your life experiences are, the more creative games you’ll make
Based on our experience with Snail Bob on Flash and iOS, we offer a couple of points of advice.
Simple and intuitive gameplay
The simpler the gameplay is, the more players will be able to play it. As in many other areas of real life: throw away all the excess, leaving the basics – plain and simple.
The game should bring joy. Using humor we emotionally tie players to our game, as when they watch a great cartoon. We want players to have fun while playing our game. We want them to look forward to the next funny situation or animation.
In order to make the player want to reach the goal, you have to supply them with a clear and simple goal that the player wants to reach all his heart. The story doesn’t have to be complex. In fact, rather the opposite.
Make a Facebook community
Use your games to build a community of loyal fans. It’s not difficult, but it’s very effective and will help when an update or new games comes out.
Test your game at all stages of the development.and target your main audience: casual players, like kids or grandparents. If they understand the game, anyone will understand it.
Use statistic tools to keep track of what’s going on in your game, on which level most of the players get stuck, what is the length of the game session and so on. Use this data in your updates.
Flash as a test platform
Use Flash as a platform to evaluate the success of your game. Flash allows you to make the game very fast, quickly release and then get feedback from players.
And one very last piece of advice: Let everything inspire you: movies, music, travel, family, friends. The more diverse your life experiences are, the more creative games you’ll make.
Snail Bob is available in the AppStore. Currently, Andrey and Maxim (pictured above) are working on new chapters for the Mobile version to support the sales of the game. After that, they will be focusing on releasing the new levels for the flash version as well.