GamesOnly.com is a Dutch game studio and game portal founded in 2009 by Robin Ras.Located in Amsterdam, Robin started to work with other game devs to develop Unity 3D games like the Orange Jet Fighter. “Being a big fan of jet fighter games, it was great to finally be able to develop something similar”, Robin says as he shares the story of Orange Jet Fighter.
In July 2011, Eldwin Viriya took a leave of his job as a lecturer of basic algorithm and data structure for a semester to take a GRE test for the master’s degree. Having passed it successfully, Eldwin discovered he had a lot of free time. He decided to use this time for self-development and made DragManArdsin 1.5 months.This Flash game really sparks the light of game development spirit in its author. Later, his company, Own Games, created DragManArds’ remake Own Kingdom,a fantasy medieval strategy game where you need to protect the kingdom from waves of monsters. He describes it as an experience of tower defense games with a taste of war games.
Get the Taste of Making Games
When I first created DragManArds, I used MochiAds for monetization, since that was the only monetization option that I knew at that time. I didn’t even know about Flash sponsorship back then! The result turned out interesting: I got a lot of feedback from real players in Kongregate, some fan messages and suggestions, and also managed to earn more than 200 USD in the first month (which was cut down to only a quarter in the following month, and to almost nothing for the rest of the month).
It felt amazing to actually experience the thrill of launching a game, but the best part was when DragManArds dragged me into the gaming ecosystem of Indonesia. Groups such as Gamedevid allowed me to get to know game developers of the country, as well as big companies like Blackberry and Nokia.
Remake DragManArds: More Features, Better Graphics
In late 2011, Nokia held a game developer competition for their feature phone platform. I asked Jefvin Viriya, my brother (who was still in high school) to help me make the game in time. Having submitted a mini game named Beyond the Well, we came out as the third winner in the competition, and since then, we continue developing games together under the name of Own Games.
We started attending local gamedev events here in Indonesia, one of which was Game Developer Gathering. After this gathering, Kris Antoni from Toge Productions invited me to a meeting with Mochi Media. I got a chance to show DragManArds to their representative and received good feedback about the game. He said he was interested in being contacted again if there’s any sequel to the DragManArds. This meeting made me believe that my game has a lot of potential within.
The meeting with Mochi Media made me believe my game has a lot of potential.
At that time, working on a new Flash game would have been really hard for us. Firstly, Own Games already had a good amount of players from Nokia Store, and we want to keep them happy with our creations. Moreover, I was also busy with my day job as a lecturer, and my brother got overwhelmed with his high school final exams (not to mention that he didn’t understand ActionScript at all). So we continued our life as usual after that time.
A few months later, Nokia launched Lumia, a Windows Phone smartphone. Until this day, Own Games was focusing on feature phones only. We were working in native J2ME and were not really familiar with modern game engines. Then I noticed that one of my juniors had graduated from the bachelor program, and I invited him to work together in Own Games. The first thing he did in the company was port DragManArds to Lumia. The results turned out great: DragManArds got a gold medal in the Lumia Apps Olympiad in December 2012.
Then I finally decided to quit my job to completely focus on Own Games. On April 1, 2013, Own Games transformed into an official company. Agustian, a 2D artist, also started to help us out. It was really a big move for us: before he joined, we were short on manpower and, what is more, he had a degree in arts and experience in making games. The first objective became clear: remake DragManArds with more features and better graphics.
Learning From Mistakes and Feedback
DragManArds already has a lot of versions: Flash, Windows Phone, Blackberry 10, and even J2ME. Having received a LOT of feedback, we planned a lot of stuff that we wanted to implement in the remake. It turned out to be a lot of tasks. But as Agustian is a talented artist with experience in game industry, I could fully dedicate myself to improving the gameplay and user experience, and our programmer had proven himself successful in making the Windows Phone and Blackberry version of DragManArds, we believed we’ll make it.
I was too optimistic back then, and set the deadline to 3-4 months (DragManArds was made in 1.5 month by me alone, right?). But we weren’t able to finish everything in that time. As any new startup, we faced many challenges, both technical and not. I often argued with Agustian about how he used a lot of time to draw some tiny details that cannot even be clearly seen in the final game. Meanwhile, our programmer had to work remotely from another city because his father had a serious illness. In the end, he realized that he didn’t have enough time to develop anything and left Own Games. So we lost our programmer, our art assets production took more time than planned, and my entrepreneur’s soul was still on a very early development stage. I used to get a salary each month, now I had to pay salaries each month – It feels totally hard in the beginning even though you are already aware of the risk.
I used to get a salary each month, now I had to pay salaries each month. Feels hard in the beginning.
A few months after our programmer left the team, we met Ray Naldo,a former junior in the university where I worked. But we didn’t want to give him the pressure of developing a game as big as Own Kingdom for his first time. So we decide to make Eyes on Dragon, a 3D endless runner. During its development, we also got some help on 2D art assets from Okky, Agustian’s junior.
Meanwhile, Jefvin was learning C++ and tried to make Own Kingdom for Windows Phone 8 using Cocos 2dx. The WP8 version eventually became the finalist of the Indonesia Game Show. During our presentation at the competition, the judges called Own Kingdom’s gameplay a unique and promising one, but pointed out that the program was crashing and the buttons weren’t working smoothly. Even though we didn’t win the competition, this encouraged us to go on with Own Kingdom. But, sadly, once again, we had to put development for WP8 on hiatus when we realized that Cocos 2dx for WP8 didn’t support mp3 files.
Back to an Abandoned Game
A few more months had passed. Eyes on Dragon was published. We were happy with what we made, and decided to go on with the development of Own Kingdom. Ray started learning Unity 4.3 for 2D, Agustian and Okky made more art assets for the game, and Jefvin and I kept improving the game design, level design, and also the whole gaming experience.
The second development phase was not easy, but definitely better than the first one. Continuing the game that was once abandoned is for sure not an easy task, since most of the courage is gone. What is more, there were two desires we struggled with: to make the game better but, at the same time, finish it as fast as we could. Yeah, that’s shameful. Nevertheless, coming back to Own Kingdom had positive sides, too: we already knew that the game is worthy and that a lot of people wanted to see it completed. What is more, now we had a bigger team and some experience. Eventually, we managed to finish Own Kingdom in April 2014.
The development of Own Kingdom is a long journey, and we realize that it has not ended yet. But we are really happy with the growth of each of us. Agustian has started to become more efficient and effective at allocating his energy to finish the work in time. Ray got a lot of experience in making the game using Unity in both 2D and 3D, which opened the possibilities to reach more platforms. I became more familiar with project management, and got a whole new experience in leadership. But the most valuable thing that makes me really grateful is how Own Kingdom turned Own Games into a more solid and powerful team.
Fearless Fantasy began in 2012, when animator/director Andrew Kerekes, encouraged by a couple of Flash RPGs that made a splash at the time, decided to create an RPG of his own. Its unique selling point would be a skill-based gesture mechanic which would replace the random number generator and create a more immersive experience. More than two years later, the originally humble Flash project got released on Steam, with plans to bring it to mobile devices soon. Daniel Borgmann was responsible for the development side, and now shares the experience of creating a game in an ever-changing market.
The Beginning: A Tempting Offer
I joined the project when Andrew was looking for a programmer to implement his concept. At this point, I had just decided to dive into full-time game development. While I was working on a couple of projects of my own, his offer was too tempting to pass up, so I jumped at the chance.
At this point, Andrew had mostly made a name for himself through animation projects, but also contributed and created a few smaller Flash games, the biggest one being an elaborate hidden objects game called Memohuntress. I remembered this game for its unusual atmosphere, and the prospects of creating an RPG with his unique style were exciting.
The plan originally was to finish the entire game in about three months, but it soon became clear that this wasn’t a realistic projection. We both still believed in the concept though and, because we were working well together, decided to change our arrangement to a 50/50 profit share. At this point, I wasn’t feeling too much pressure yet, as I had some savings left and was confident that our hard work would pay off in the end one way or another.
Collaborating Across the Globe
A distinctive feature of our collaboration was that the majority of work was done exactly 12 hours apart; by Andrew in Hawaii and me in Berlin. Everything considered, we dealt with the time difference pretty well. It probably helped that both of us occasionally confuse the moon for the sun. We kept working this way for many months, while the game went through various stages and we both also dealt with some significant personal changes.
It probably helped that both of us occasionally confuse the moon for the sun.
Realizing how much work it would be to implement the original vision, we started to aggressively cut down features to focus on the essentials. One of the first things that had to go was the world map. After a few iterations, we ended up with a simple level-select screen so typical for casual and mobile games. This was a natural fit for our game, given that its core is the unique battle system and ease of play.
With this renewed focus, things really started to fall into place. We changed the battles to have multiple waves of enemies, which created a nice amount of challenge without becoming frustrating. We tweaked the upgrade system to allow unlimited re-specs, and even changed the shop to allow buying and selling items without experiencing a loss. In many ways, we were turning the game from a pure RPG into a skill-based game “with an RPG element”.
The Ever-Changing Flash Market: The Good and Bad
As the months went on, we both started to reach our limits. Both of us dealt with some personal issues, and the pressure already started piling up. We now had to rely on our families to keep us going, but we knew that this couldn’t go on any longer.
For me, the hardest thing to deal with was my marriage falling apart. I tried to avoid resolving it until the end of the project, but eventually it just affected me too much. After the separation, I went through a short slump but had a lot of time to reflect. So, when I had pulled myself back together, I knew it was time to bring things to the logical ending.
After one last major push to add a layer of polish and quality, we were finally ready to present Fearless Fantasy to potential sponsors. By this time, we had put so much of our personalities into the game that we didn’t really expect it to be profitable. Nevertheless, we were hoping to get an offer good enough to keep us going for a while, while we worked on sequels or new projects.
The Flash market just wasn’t where it used to be when we started the project.
We contacted a few sponsors and received some phenomenal feedback, while the exact offers turned out disappointing. We had to realize that the Flash market just wasn’t where it used to be when we started the project, and our prospects looked grim. We were ready to cut our losses and put our hopes into a quick sequel or mobile release, but then we met tinyBuild.
tinyBuild’s Vote of Confidence
Alex Nichiporchik from tinyBuild played our game and liked it enough to offer us a publishing deal. He brought up the idea to get the game on Steam, like they did with their own Flash game No Time To Explain before. We had considered this before, but going through Greenlight looked too daunting given the situation we were in. tinyBuild’s vote of confidence and the possibility to bypass Greenlight convinced us to give it a try, and it’s not like we had anything to lose at this point. Of course, this also meant a few additional months of hard work.
The biggest task was to properly support high-resolution full-screen displays. What helped us was the fact that we had already chosen a rather large resolution for the Flash game, and used bitmap graphics exclusively, so we could set the stage quality to low and get reasonable rendering speeds from Flash. But we were already pushing Flash to the limits, and increasing the pixel counts to potentially very large numbers still posed a real problem. Our solution was to sacrifice disk space (which now was much less crucial) for the sake of performance by pre-rendering complex characters into a number of static frames.
We had already chosen a rather large resolution for the Flash game, and used bitmap graphics exclusively, so we could set the stage quality to low and get reasonable rendering speeds from Flash.
The remainder was more straight-forward, and tinyBuild was able to help us out with their experience. We used MDM Zinc to package the game for Windows (incidentally AIR was not an option because it does not allow low stage quality with the desktop profile for some reason) and used a Steam extension they provided to implement achievements and cloud storage. Of course, we also improved the quality of the audio and graphics, and bought a few more music tracks since we could now afford the disk space.
We used MDM Zinc to package the game for Windows, and a Steam extension to implement achievements and cloud storage.
A Bad Surprise on Release Day
Finally, we were ready for the big release. After everything we went through to get to this point, I couldn’t even tell whether I felt more relief or anxiety. It was probably the strangest feeling I’ve ever experienced. Then, on the day of the release, Gamasutra posted a feature about how Steam is being flooded with games, and what this would mean for small game developers. Reading this on the actual day of our release was a bit surreal and, as it turned out, we released simultaneously with a large number of games, some of them highly anticipated.
We released simultaneously with a large number of games, some of them highly anticipated.
For this reason, it’s difficult to tell how we felt about the release. We didn’t get an impressive burst of sales we were cautiously hoping for from a Steam release. On the other hand, feedback so far has been overwhelmingly positive, and this keeps us optimistic that the game can be a success, if we manage to get people to talk about it.
One thing we learned from the release is that the Flash rendering just isn’t good enough. Despite the hoops we went through to keep performance as high as possible, some people ran into issues, and our performance workarounds also led to relatively high memory usage, which could lead to stability issues. We had already planned to move to Starling and DragonBones eventually for the mobile version, so we decided to prioritize this. It would provide a huge number of advantages, from better performance and graphics to increased stability and the ability to use AIR.
As soon as the Daniel and Andrew are done with this, they’ll try again to get the word out, and then work on the mobile version. Additionally, they’re planning to add a survival mode for long-term value, and considering the possibility to release it as a free demo version for web and mobile. Fearless Fantasy recently won the Best Art Award at Indie Prize at Casual Connect USA 2014.
Kurechii Studio was just a team back in 2009, and was officially established in 2011. From three members, the company grew to four: Yiwei P’ng, the founder, Zyen, an artist, Lydia, a copywriter, and Nick, the animator.Working on their debut iOS project, King’s League: Odyssey, they also had a few others, so used extra help from Ritchie the graphics artist, and two more programmers – Shin Hean and Pei San.Since the Kurechii team initially had experience with Flash, having someone familiar with iOS was extremely helpful, Yiwei recalls as he shares the story of the game.
Lost the Feeling of the Game? Launch and See Whether it’s Good or Not!
The first version of King’s League (Flash-based and playable in the browser) was completed within a month just by myself to fulfill the goal of creating a monthly Flash game, something I set to stay motivated. The game was beta tested by a friend, who found it rather short. At that point in time, only simple quests and sieges were available, and the interfaces were pretty confusing.
With that conclusion, the game obviously wasn’t ready for a proper audience. I decided to scrap that version and rebuild a whole new one with better graphics and interesting features, the major feature being unique characters. In hindsight, that one feature has greatly impacted the game in a positive way. We had cool-looking characters, with better stats! And they can only be unlocked by fulfilling some special requirements.
By the time I got around to implementing a proper league system in the game, it was already four months since I started the revamp! As I was already rather numb to the changes (I couldn’t tell if it was entertaining or bad anymore), I decided to launch it on Armorgames and see what the response would be like.
Surprisingly, many players picked it up, and the game gathered about 2 million plays in the first month. Users were really generous with their feedback, so I kept note of the comments. Regrettably, I still had tons of ideas that weren’t included in the game due to my lack of experience, particularly technical, and time – I was still working alone.
For that same reason, I had to cover both the artistic and technical aspects of the game. If there was ever going to be a sequel, I thought – I wanted to focus on the programming and game design. But I would need someone who really excels in game art and enjoys the genre King’s League is: simulation and strategy. Ritchie fit the picture perfectly, and that’s how we began working on King’s League: Odyssey.
Listen to Feedback and Follow Your Path
While working on the sequel, many features were sacrificed to complexity and the game pace that we wanted to retain.
One of the most desired features (according to the feedback we received) was a pause button, or a button to manually control when the players wanted the next day to come. However, we chose not to add that. Instead of letting the players control the pace of the game, we wanted them to stick to ours – to keep the feeling of thrill as a league match approaches, and when every decision matters.
Another feature we did not provide (again, after some feedback), was to have auto-assigned training. It would’ve been convenient, but would also highly reduce the player’s choices in decisions to make and actions to perform.
For more depth, we also wanted to include a Spy upgrade – a feature allowing players to check what units the opponent team will have, and to make captured cities upgradable. In theory, these were interesting things to have in a game (and after the launch, some players were suggesting them, too). However, they hadn’t been implemented, as this would add a lot of complexity to the project. We tried to avoid making the game too hardcore to appeal to casual players.
We tried to avoid making the game too hardcore to appeal to casual players.
Our decision to withhold these features did not negatively impact the sequel, but managed to help retain the pace we wanted for King’s League: Odyssey.
We revamped the Upgrade Facilities three times in terms of mechanics and design before settling on the final version. The first few versions were rather complex and confusing, and did not give a solid sense of progression. Using icons in the interface also helped players in deciding which upgrades to go for.
Asset-wise, we initially wanted all the units to have animations for every training option available – but that would mean a total of 495 extra animations. In the end, we had to forgo it because of the size.
The Pains of Going Mobile
If we planned everything ahead for the mobile version, things would’ve gone smoother. On the other hand, we did not entirely forget to prepare for porting; it’s just that we were more focused on the visual aspects (interfaces and graphic ratios) than the technical ones. Nevertheless, we had the UX ready for touch screens, so didn’t have to redesign the UI during the transition from PC/web to mobile.
Prior to this, we had no experience in mobile game development. The “3-months-with-1-programmer” plan to port the game grew into “11-months-with-2-programmers”.
One of our biggest struggles was definitely the file size. High quality graphics were something we really wanted to deliver, but that just served to increase the game’s file size. In Flash, it would not have been a major problem, since vector graphics were used. The raster images used for the mobile version at first caused a delay in loading and also memory problems. Eventually, we managed to cut the game install size on iOS from 1GB to about 500MB, but this cost us a few extra months and was still not the most satisfying file size for players: it was always at a high risk of being deleted if a player needed more space on their device.
We didn’t change anything about the save system when porting the game from Flash to iOS, but later, we understood we’d better had it updated: compared to the browser version, mobile players were more likely to quit at random points in the game due to phone calls or other device activities. Another month was spent to patch up the things we had missed.
Mobile players are more likely to quit the game at random points due to phone calls.
We could’ve saved up a lot of development cost and time if we did not go through these mistakes – as inevitable as they seemed then. It’s a price to pay for inexperience, and definitely a lesson learned to be applied to our future projects.
Walking in Your Teammates’ Shoes
Everyone in the team has been exposed to developing for iOS in certain aspects (coding, visuals, design, etc), but none of us has gone through it from A-Z. During this project development, everyone has tasted the responsibilities and tasks of different roles: programmers learned how artists manage and export art assets, while artists got more than a hint about how certain codes work. This helped everyone work in a way that would benefit others, allowing for a more efficient workflow.
It was certainly a tough journey, but a great one. We grew as a team with the same goal in mind. As a more mature team, members now know how to use their expertise to help ease the tasks of other roles, too.
IAPs Done by Players as Support for Devs
Saying we did not hope that King’s League would do well would mean we didn’t believe in our own efforts. But with the help of our publisher, Gamenauts, the game got much more coverage during its launch than we could’ve managed to get on our own. Gamenauts dropped us an email after playing the first version of King’s League on Kongregate. Not many publishers were contacting us at that time, while this company made us an offer at an early stage of the sequel project. We agreed, and, as devs with little experience, we thought having a publisher can help us a lot in many ways, from development to monetization.
Initially, we wanted the game to be fully premium and without in-app purchases (IAP), but Gamenauts suggested having some better-looking and stronger units for sale. After some careful crafting, we included premium units that would not cause game imbalance, but still had unique features. Firstly, we made sure the game is playable without any IAP content. I can say that the advantages of our IAPs mostly come from aesthetic side. For instance, the characters-to-buy are slightly more powerful, but still require training like common characters to make them really strong.
The sales of these units surprised us – they were actually quite good! Many players bought the items after finishing the game and left comments letting us know it was an act to support us. We were very grateful for that. It also encouraged us to continue producing premium games, even though the freemium model is believed to generate more revenue.
King’s League: Odyssey also did well in the App Store ranking of various countries, serving to be a huge motivation boost. The Android version has been released in May, but, since Google Play is favor to freemium games, the sales there are not as good as on Apple’s App Store. The game also won the “Best Mobile Game” prize at the Indie Prize contest at Casual Connect Asia 2014.
GAF Media was created to solve the problem a team of developers was having when converting Flash to a format that could be played on mobile devices. Now, the team works to provide solutions to the development community. Denis Balon, COO and co-founder, talks about their journey.
The story of GAF Media started when a team of game developers decided to expand their popular Facebook game to mobile devices. The main challenge was to convert over a thousand animations from Flash to a format that could be played on all mobile devices at any resolution. Existing tools and approaches didn’t do well with the task or involved a prohibitively large amount of work. So we decided to create the necessary tools ourselves.
Creating a Solution
Founded in 2009, the team located in the US as well as Ukraine first came to market with Pet City, a game on Facebook. The game quickly became popular and is going as strong as ever, three years later. Given the sustained popularity of the game, we decided to port the game to mobile.
There were no turnkey solutions that could convert complex animations into a size-effective format while also supporting high performance playback. The alternative and widely used approach was conversion into frame sequences, which was not an option because full control over animations and the resulting file sizes were far from optimal.
But even more important was the developers’ need for a reliable set of tools to allow them to continue developing animations using Flash CS while targeting various mobile platforms. Hence, the GAF Media team was formed to develop a set of tools that would port Flash animations to various mobile platforms (mainly iOS and Android). We defined a graphic format called Generic Animation Format (GAF) and created a tool to convert Flash animation files into GAF. Libraries were then developed to play the GAF files on any mobile device, enabling game developers to greatly cut down the time to port their Flash animations to mobile devices. The beta version of the tools was launched around the end of 2013. After over 18 months in development, we were able to launch our first product.
Prove It Actually Works
Even though some suggest Flash is dead, that’s far from being the case. Animators and developers still prefer using Flash CS to create animations, as it offers a deep and unmatched set of authoring tools. What remains daunting for many developers however is the task of quickly porting these animations for mobile. To address this need, the GAF Media team decided to offer their enabling set of tools to the game developer community.
We faced major challenges to create a worthy set of tools. The first was to prove the advantages of an automated set of tools that were versatile, but still possessed powerful performance advantages. The team’s mission was to show that the GAF solution packed a full list of features that went far beyond other solutions on the market. The tools had to combine high performance with killer features that would meet the needs of almost every developer and animator.
Privacy was also found to be a major concern by major game companies. They expressed the need to to keep their animation assets a secret until game launch. This compelled the team to develop a standalone version of GAF Converter which would run conversion of Flash animations on one’s computer without the need to upload the animations to the GAF Media SAAS service online.
Developer Community is Key
Throughout the process of commercializing our tool set, we actively sought developer feedback to help implement the right mix of features and performance. Community feedback had a direct impact far before first launch. Besides helping developers to create games faster, it was important to support animation properties that animators needed to add creativity and polish to their animations.
From automation utilities that were created solely for internal use, we ended up developing a tool set to benefit major game companies and indie developers alike, a tool that we hope someday will become as well known as Flash itself! But this is just the beginning for us. We have already started our next major effort: the GAF Converter for UI elements in games.
The GAF Converter, including a free version for download for Mac and Windows, is available at www.gafmedia.com. To welcome GameSauce readers, GAF Media is also doing a special limited offer! Sign up at GAF Media through this link and receive 500 conversion for free!
One word for it is “miraculous” – it’s miraculous how such a team came together in the right place at the right time. “It was as though someone had dropped a bag of scrabble letters, and amongst the resulting alphabetical catastrophe on the floor, one sentence lay there fully formed, ‘Start Company, Make Bingo’,” Oliver Jones, the director and co-founder of Moonfrog Labs recalls as he tells the story of their first game Bingo Club. The game was in made in six months by a team of four that grew to eleven.
A Gamedev Startup – a Crazy Idea for Indian Business
This story is as much about game design as it is about India. Bingo Club and Moonfrog would not exist if Zynga did not open up a shop in India and hire the best talents they could find in all competencies. At the Zynga shop, our team saw the potentials of a fast-moving mobile company in an emerging market, and made the jump into founderhood. It was a bold move! Generally, Indian entrepreneurs like to start traditional buy/sell businesses. As a result, this startup idea of a gamedev company seemed far too risky for some of our family and friends, who asked us to slow down and think twice. We did neither.
We knew that our team’s combination of development skills essential for games is quite rare in this part of the world. In India, it’s tough to find design, product, and game programming professionals able to handle these big 1M+ player bases. It’s also challenging to find creative people who will push for awesome player experiences, and even more difficult to bring all these people together. In the hard times when Bingo Club was finding its feet on the marketplace and players riled about bugs, we would remind ourselves that we could be making a part of history. We could become the first Indian gaming startup to actually execute on both scalability and high quality. It was the idea that kept us polishing and pushing our standards higher.
Math is King in a Bingo Game
The “spit and polish” approach, however, can only be applied to a smooth, solid object. For Bingo Club, this meant some solid, smooth math. Believe it or not, the average number of Bingo balls called in a game dictates absolutely everything else! From session length to level curve, even the cost of power ups could be calculated from that single number. In order to find that number, we had to define a set of rules and simulate bingo games a couple of thousand times. While the company was still inchoate, I quickly realized this fact and knocked together a simple Bingo simulator in Flash, that you can play around with on my website. Simply input the number of players and hit play!
This simulator allows you to define a set of rules, such as player/Bingo ratio, XP per daub, and run it thousands of times. It outputs values such as how many bingo numbers are drawn before a game is over, and even what quantities of XP and coins you would earn per game. These numbers became my constants, my guiding star in the sea of shifting XP requirements and jackpot payouts. Of course later, we started being more creative with our game mechanics and made more sophisticated simulations with no designer-friendly UI.
Casual Means Usable, Not Easy
It may come as unfortunate news for developers and designers that you can’t launch a spreadsheet on the app store. Bingo Club only existed for a while as a glorious mashup of formulas and calculations, while our UI remained a blank canvas. As we started drafting screens, it dawned on us that perhaps we didn’t really know what would resonate with our target audience. Who were the players of Bingo? What semiotics and game patterns are they familiar with?
To get rid of this problem, we started iterating. Above is a sample of what we greyboxed for the lobby screen before we came up with our final result. Each screen was tested, scrutinized in detail, and compared with our closest competitors. Along the rocky road to a clean interface, we also experimented with meta-games trying bizarre stuff like a Candy Crush Saga-inspired story and zoo animal collection. Along the way, we created hundreds of wireframe configurations.
Lesson Learned: Launch, Adjust, and Update
Despite the fact that we haven’t spent a single marketing dollar over the last few weeks, Bingo Club is naturally climbing its way into the top 100 in various countries, including the USA, UK, Canada, France, Italy, Germany, and Spain. Our reviews are averaging 4.5 stars. The future looks bright! However, we can say that we launched too late! Bingo Club could have been launched three months earlier. But instead of that, we decided to push to become more feature-complete. This was a bad idea, as our app would have become far more polished had we received precious feedback and suggestions from the players sooner.
One could argue that Bingo Club has already completed its mission. It has gone a long way to prove that both Moonfrog and the entire Indian indie game scene is capable of competing against the best developers in the global arena. We saw the bar of quality exhibited in current bingo games, ran, and jumped right over it. You could say that Moonfrog hopped as high as you would expect a frog would on the moon. But our journey was not entirely frictionless, and certainly had no shortage of lessons along the way. Our plan for Bingo Club however, does not end here! With continued support, we intend to see how big our little game can grow. Expect us to add fresh ideas, new levels, and more. For now, its only one small step for Bingo, but one giant leap for Moonfrog.
At the time of writing Bingo Club is available worldwide on Android, but they are still waiting to see whether or not their efforts will be fruitful and rewards, more than intrinsic. Regardless of the outcome, they feel they have proven themselves as a team.
The Game Kitchen is a small game company based in Spain, that has been working independently for two years. Formed from a group of friends, they aim to create their own unique IP and make their mark on indie development. Raul Diez talks about the creation of the company’s first original game, The Last Door.
Building the Dream and the Team
To really explain the origin of The Last Door, we have to go back to 2004. Back then, we were just a bunch of friends who really enjoyed making games as a hobby, but it wasn’t our profession. But we all knew that our destiny was different. Our true passion was to develop games. Every day after work, we met together to spend hours learning how to make games and creating our first amateur projects. We lost a lot of sleep to master the necessary tools to develop games, and then decided to start up Nivel21 Entertainment in 2009, a really tiny pseudo-professional studio.
We developed some games and participated in a few contests. Rotor’scope, one of our most successful games, won several awards (Prize on DreamBuildPlay 2009, Best Spanish Indie Game 2010, etc.). We started to gain recognition and the necessary self-confidence to take the leap, quit our boring jobs, and create our own full professional company in early 2010: The Game Kitchen.
For the first two years, we did contract work for other companies and game studios, including ports of existing games and educational titles. We were quite happy in those times, but the advent of the crisis complicated things. Developing indie games in Spain became complicated, since no funding nor financial support was provided. Our clients were suffering, too, and contracted work became much more scarce, pricing went down, and payment came too little, too late.
The moment had arrived for us to step forward and reach our dream: to fully develop our passion and develop games we would loved to play. It was to time to move away from clients’ restrictions and be completely free to create. Thus, at the end of 2012, we stood our ground! We felt there had to be another way to fund games, and so we placed our hopes on Kickstarter as an alternative way around scarcity of bank loans, and a more sustainable and honest way to do business.
The Birth of The Last Door
We knew what we wanted to do and the path to follow. We were only missing the particular idea for a game. To solve that, we decided to have an idea contest internally. It had to be something different, something really groundbreaking… and then appeared. Enrique Cabeza, one of the team’s artists, introduced us to a simple game prototype made with PowerPoint based in pursuing the same feelings caused by classic horror books, where you rely heavily on your imagination to depict the scenes and situations.
The brainstorming began and all the game components started to flow; it had to be an adventure game, immersive, with low visibility and dark scenarios, even more..over-pixelated! The retro concept gained ground and the point-and-click mechanic was almost mandatory. We are quite a homogenous group, and have a mutual understanding when approaching video games. It wasn’t difficult to agree on the shape of the game and completely fall in love with the idea and concept. There was no turning back.
Designing the Kickstarter Campaign
Preparing for our Kickstarter, we knew that we had a lot of work to do before we were ready. It was the first time we were crowdfunding a project, and everything was new and vibrant, but also very time-consuming and stressful. Kickstarter gives you a month to reach the funding objective, so when we decided to start the campaign in December 2012, we also started a race against time to set a good communication flow with the community and create as many contents as possible. It’s common sense that the backers want to have a deep knowledge about the project they are going to support. Videos, social media, a functional website, art, team introductions, PR and marketing activities, as well as a playable prologue– all ideas were welcomed to explain the game and to tease and convince potential backers.
Videos, social media, a functional website, art, team introductions, PR and marketing activities, as well as a playable prologue– all ideas were welcomed to explain the game and to tease and convince potential backers.
In our ingenuity, we thought that part of the team would be enough to handle the campaign while the others start work on certain aspects of the game for when we were up and running (and more importantly, funded). But that wasn’t the case, as most of the resources were spent on the campaign itself. The only exception was the creation of the playable prologue. Even though we barely reused any lines of code or assets from it, it turned out to be a good prototype and gave us a real and concrete vision of what we wanted to achieve in the first chapter.
After a month of madness and frenzy, 285 backers not only supported the pilot chapter of The Last Door, but also helped us to reach 20 percent over the objective. That’s the way we were able to undertake our beloved project: an over-pixelated horror game in which the player would have to use his imagination more often than he’s used to.
The Moment of Truth: Developing the First Chapter
When approaching the design of the game, the first thing was to decide the technology to be used. We went for Flash, since we mastered this software, and it represented the best alternative in terms of budget and time, although it also had some restrictions. One of the restrictions is that Flash is “high level,” so it isn’t designed to be optimized from a technical point of view. Another limitation was that only one out of our three programmers really mastered this software and had previous experience with it.
As for methodology, we are used to work under Scrum, so we stuck with it. Our first decision was to make a first sprint that would last for a little less than a month, because we had to build a clear-cut, well-defined basis for every aspect of the game. This is the way we have continued developing our game until today, adding new features along with new chapters, like refactoring the engine, support for NPCs and dialogues (including the integration with ChatMapper, a very cool tool to create conversations), savegame, accessibility features (closed captions and dyslexia-friendly fonts), support for community collaboration, etc.
With development, we had teams in charge of certain aspects of the game. Our two artists were in charge of the script and general design of the game. They created the main storyline, script, and gameplay of the first chapter. Obviously, for the first chapter, it had to be a script that would somehow “hide” the lack of features that would be entirely missing from the game because of time constraints, such as tree dialogs or navigation grids.
With development, we had teams in charge of certain aspects of the game.
For the programming team, the top priority was to create the game engine. The coding of the prologue was done rather hastily during the campaign, so it was obvious it needed a deep and thorough analysis and refactorization if we wanted it to hold up a much longer gameplay and the potential inclusion of more features in the future. Considering the script and design team would need a few weeks before finishing up the story, we decided it would be best to test our newly coded engine features by creating a replica of the prologue.
As for the orchestral original soundtrack and sound effects, it is one of the greatest features of The Last Door. The soundtrack completes the strange and frightening atmosphere of the game, and it has been highlighted and praised by almost any of the media which have covered our game. For that, we had the good fortune of counting on our friend Carlos Viola, a master music composer with a long history of composing for video games, who rapidly understood what we wanted for the game and did outstanding work.
From the beginning, we wanted to create a scary and enthralling story, making the player feel a gripping, immersive status. That was a real challenge, but also the key to our success. We are fans of horror literature and of authors such as Lovecraft and Poe, so our first intention was to reproduce that atmosphere of the dark ages: full of light and shadows, uncertainty, obscurantism and mysteries. The story behind The Last Door revolves around cosmic terror and Gothic novels, especially from those above-mentioned authors, so their literary universes are the leitmotif narrative of the game from its very conception.
The Importance of Our Community
Thanks to the crowdfunding concept and backed by our active community, we released our first pilot chapter “The Letter” in March 2013. The positive response from hundreds of players and the good critics encouraged us to continue with the project and produce a second chapter and design the whole saga. Due to our previous success with crowdfunding, we thought that we could crowd-fund future chapters of the game independently from Kickstarter. We implemented the necessary tools within our website to make it possible, such has creating a good basis that supported user profile management. People needed to be able to register, log in, edit basic information and identify themselves as backers (or new ones) to access their individual rewards. We managed it and in June 2013, we launched our second chapter “Memories.” Since then, the game has been played by hundreds of thousands players throughout different websites.
The main role of our community is obvious, not only from the funding perspective, but also in a creative way. To continue telling the story and making this a long-term project, we depend on our community. Our idea was to design an expanded experience for those who want to get more involved while allowing more casual players to play without interference. We have a web blog/forum that works as an effective communication channel. It allows our community members to participate and suggest ideas or improvements in any aspect of the game (from content to marketing). Thanks to them, we’ve been able not only to fix bugs, but to perform relevant improvements in gameplay. Another main role of the community is the writings, as no one in the team really has enough command of the English language. we got almost 100 percent of the texts re-written by them, and they are also localizing the game into several languages (we have twelve so far).
We believe in collaboration as a way of creation, and we are making further progress in that direction. In the last chapter, for instance, we organized a kind of contest where our community members had the chance to suggest descriptions for many objects we left intentionally undescribed within the game. The “Leave your Mark” initiative was highly successful, and we are thinking about new actions to interact with our fans and make them participant in the success of the project. All these inputs really help in the creative design and fine-tuning of the game, supplementing and improving our original ideas.
Finally, we are really proud of our fans, since they are also creating a lot of rich parallel content related to The Last Door. Illustrations, 3D modeling, recreations of the game in SIM’s, Minecraft, etc. and even poetry about the game! We just can’t believe it!
Future of The Project and Studio
Future? We don’t really worry about that. We will try our best to survive in this pure “indie mode” as long as possible. It’s not easy, but we have the necessary tools to battle it out. Also, The Last Door is starting to be economically viable, so prospects are positive. Many people ask us how long is going to take to end the game, and to be honest, we don’t really know. Our game is designed to be a web-series and, as such, it hasn’t a predetermined number of chapters. As long as the community continues supporting us, and the series makes sense story-wise, we will continue producing episodes. If the project stretches on, we could even divide the game into different seasons, much like a TV series. Our intention is that once we reach “cruising speed” in production, we will detach some resources from this project, since the production will have enough momentum to be carried out by less people. At the same time, these liberated resources would start pre-production for something new. It isn’t decided yet, but we have plenty of ideas.
The third chapter of the series, The Four Witness, is scheduled for release at the end of September. Keep up-to-date with The Last Door development on Facebook.
When the idea of this game appeared in my head, I had already done four projects in a rush mode. I enjoyed making games quickly, not only because it really saved valuable time, but also because this way the projects didn’t last long enough to bore me. The main idea for my new game was a bit blurry and existed only as an idea. The only clear thing was the concept, so I took it as a constant foundation that has been preserved from the beginning to the end of the development process.
I use tricks to escape the routine
When developing a game I try not to work in the same pattern over and over. I use tricks to escape the routine. On Dream Symphony, I tried to leave my comfort zone and tread into an area I had no experience with – music.
Despite the fact that indie games are mostly made without reliance on colorful graphics and effects, music always substantiates or even creates the atmosphere in those games.
Among flash games, there are outstanding representatives of the music games genre that are all based on the mechanics where static objects in the scene (such as obstacles or changes in the landscape) occur after the composition reaches a certain time or a certain pitch (Music in Motion and Take a Walk).
I wanted to create a musical flash game, but with rather unusual mechanics. The idea was simple: apart from the normal sound in the game, there were more sounds that were played in the interaction with surrounding objects. I.e. no objects were created depending on the music, but music was created by the objects.
The idea was very vague, and I could not explain what I wanted. So when I offered it to my partner programmers; four out of four said no. I created a thread in a forum, without a precise description of the concept. Before my idea gained any reputation, I got several messages from programmers who offered different kinds of partnership. There were about eight people and to each of them I described the idea. All of them were willing to work on the project., I couldn’t assess their levels, but one of them wrote GDD and showed his previous game with the mechanics of a platformer. This made for an easy choice. I chose Igor Kulakov. The last problem was me. I was tired after two years of working, so we agreed to start the game over time and I left for some relaxations.
At that time, I didn’t think that after the release of the game it would be featured on Newgrounds, Kongregate, NotDoppler, Bored, that we would win three cash prizes, including best game of Maypleyard, that I would read news about my game on leading indie news sites, including JayIsGames and that I would write this postmortem.
Before leaving, I made a couple of sketches of the main character (a huge goof pumped in a tracksuit, which jumped from cloud to cloud, and bursting bubbles with music) and a couple of backgrounds. It was cute, but not particularly interesting.
It was in a village deep in the heart of Russia where I decided to change the setting of the game. Originally, I had planned to make a quick jumper, with an active music. There I met a creature that changed my view of the future development of the plot. It was a sheep. I really wanted to see it in the game. I had only a pen and a notebook so all that I could do was make a few sketches. The body of the sheep looked like a cloud. In my head I animated the sheep slipping and awakening when you jump on it. This helped me to revive the game. However, the game still was in the same state, without any fundamental differences comparing to the flash jumper games, so I decided to add one more feature. The idea was that at the very beginning of the game the level was grey and while ascending in height, the game gradually became colored. This idea has also formed the basis for further work.
When I got home, the first thing to do for me was beating similar games. Meanwhile, my partner had created a working prototype. It was a very important step. After that, we coordinated our work through Dropbox and thanks to his prototype, we could work separately. He worked evenings and I started my work in the mornings.
You just need to turn off the internet. Switch it off. You will reach zen
We worked in a rush mode, so the development of the game was enjoyable. Rush mode is the apotheosis of self-discipline, self-control and determination. In the morning, after you get up, cook all the necessary food for the day. Work should ideally take about 10-15 hours a day plus three hours for breaks. You should consider disabling all things that can give a signal. The most important discovery that I made for myself and increased my productivity 5-6 times is that you just need to turn off the internet. Switch it off. You will reach zen. The first time I came across this, lightning hit the transformer vault in my house. That day, I finished a big to-do list for the entire week and even cleaned the room, paid the bills and went for a walk. The second time, I fully encoded and made all the graphics to the simple little match-3 game, which I later sold it for 4k.
You must be completely off-line. And if suddenly you need the internet write down what you need on a piece of paper. In the evening spend an hour online and go to bed cheerfully. Of course, working like this for a long time might not be healthy, but you should try it.
Working on the Sound
The effect created a sense of passage and epicness
We needed a specific type of music with a perfect tempo and a certain feel to it. We hired a professional musician who had to rewrite the main track a few times because it didn’t quite fit the gameplay. When objects exploded, the sounds did not fit with the overall tone of the music. In addition, the levels in the game seamlessly switched, and the track for the next level was a copy of the previous one with the addition of one more instrument. This effect, coupled with the effect of saturation rising, created a sense of passage and epicness. By the end of the level, you could see a completely colored game, with a soundtrack that also felt complete.
When all the music was ready, it had to fit the levels. Connected tracks should feel solid. As an artist of this project, I needed a simple program for sound processing. I was looking for a free, easy program with minimum functionality and intuitive function names. I only needed to be able to change the tempo, the pitch, and the volume. By changing these aspects, the music comes to the foreground, and the sound echoed in the background.
The most important part was yet to come. We had to place the sounds in a way that the track seemed to be solid. To do this, sounds had to fit into the gameplay music. The player should feel that he was involved in the creation of music. It should not distract the player from the process. So some sounds had to be neutral and others had to be more in tune with the rest of the audio. The musical instruments only appeared in intervals where there was a deliberate pause. Needless to say, because of these actions the game was really hard to balance. In the end, the balancing of the game took about 30% of the work.
Zarkua and Kulakov are currently working on a part two of their popular Dream Symphony, using new technologies of sound translation. More sounds, more graphics, and more achievements. Next to that, they are trying to implement new design elements to the game.
Sergey Batishchev is an indie game developer and has been an enterprise Java developer and tech lead for more than 12 years. Still, games and game development have always been his hobby. After the successful launch of his Gluey game series, he is dedicating himself more on indie game development. Batishchev strives to make simple, polished and fun Flash and mobile games that appeal even to most casual gamers.
Gluey is a very simple action puzzle game. You just click the blobs, they disappear and you earn points. Large blob clusters give you bigger score bonuses. And, of course, it is seasoned with multiple levels, modes and power-ups. The idea for Gluey originated from an unusual source. Back in my university years, the demoscene was at its peak. I was amazed by the graphical effects in the demos and I wanted to learn how to do the same. So I spent many hours with my Watcom C++ compiler trying to code fire, fluid, and smoke.
Back in 2009, game development was purely a hobby for me. But one day I thought: Wouldn’t it be cool to create the simplest game possible, based purely on a rendering technique – like fire, liquid or particles? Surprisingly, no one made a match-3 or click group to clear-game with liquid blobs at that time! All other elements came quite naturally. I decided to use simple click group to clear-mechanics, as my friends really enjoyed games like that on their Windows 6.5 phones. It was also intuitive for the blobs to follow real physics, not just gridlines as in classic match-3. Within a couple of days, the prototype was finished. Although still in its early alpha-stages, the basic gameplay mechanic was already quite clear.
Art was a weak point for my hobby games before Gluey. Psychologically it was hard for me to fork out real money to hire an artist and a musician. I first needed to prove to myself that my games could generate some revenue. In retrospect that was not very smart choice. If you are a part time indie, you really should treat your home game development just like other expensive hobbies that you enjoy!
Luckily my previous game Cyberhorde generated about $1.5K in primary and non-exclusive licenses, so I posted a job offer for art design for Gluey. Bogdan Ene responded very quickly. Within my tough budget constraints he managed to create compelling characters and nice visual style. The visual design was completely done in a matter of days; there was no need to send anything back for revisions. After that, it took me about 6 calendar weeks (working through the weekends and evenings) to complete the rest of the game, which included levels, power ups, bonuses and transition screens.
Sponsorship and Release
To this date, the viral version has generated 14 million views
Gluey attracted good attention from sponsors on FGL – 28 bids. I went with king.com for the primary sponsorship of this game. It was my first game with 5-digit primary offer and, to this day, my biggest success. The game met king.com’s expectations. It hit Kongregate and Newgrounds frontpages and spread quite well. To this date, the viral version has generated 14 million views. Unfortunately, ads were not allowed, but game did attract quite a lot of non-exclusive licensing offers.
What Went Right with Gluey
Being on a tight budget means you have limited possibilities. This […] pushed me to only focus on the important things
Being on a tight budget means you have limited possibilities. This turned out to be a positive thing: it pushed me to only focus on the important things. So the game was very light on content: only 16 levels, which calculates to about 20 minutes of gameplay (although some players replayed the game a lot). In retrospect, it was a good choice to limit the number of levels. If you don’t have time or money to add unique content, don’t just add same-looking levels. It is better to have people comment “Too short, needs more levels” on your game, than receiving comments like “Got bored on level 14”.
Another thing that went great was the way the blob mechanics felt. They were smooth, polished, and natural. If we compare them to actual droplets on a surface, we can see three core similarities:
All blobs leave a trail behind, as if they are sliding on the surface with traction.
Actual droplets cannot touch without merging. So blobs of different color repel from each other and from the edge to look natural.
Sharp boundary around blob stressed how blobs merge and break apart.
I resisted the temptation to make the gameplay time-bound, like a lot of other puzzle games. Adding a time constraint is the easiest way to add some challenge to an action puzzle. However, players liked the fact that they had to act timely so that blobs structures do not slide apart. They felt smart for inventing this technique, instead of being forced to it by a timer. They also liked the fact that after a short burst of clicks, they were able to relax for some time and figure out the next move, instead of being bugged by the ticking clock.
What Went Wrong with Gluey
It looks like the sweet spot for a casual Flash puzzle is 30-45 minutes
Despite all the good things about Gluey, it was still a bit short. It looks like the sweet spot for a casual Flash puzzle is 30-45 minutes. Many players complained the game ended too abruptly, and down-voted the game for that reason. Yes, Gluey did feature the unlockable Zen mode. But this mode did not match the players’ expectations. The idea for the Zen mode was that for each cluster of n blobs, you get n-1 blobs back. So a Zen game ended pretty quickly (gameplay lasting only 2-3 minutes) and did not feel as an endless survival challenge.
Completing levels in Gluey was based on a simple and quite artificial premise: Earn score x to complete the level. Once you got to score x, your only motivation is reaching the top of the highscore table, which is not a very strong motivation. The game did not have any stars to rate the players’ performance on some level.
The sequel: Gluey 2!
As Gluey 1 was a success, I decided to go indie full time and started working on Gluey 2. The sequel was a much longer project (9 months compared to 6 weeks). I wanted to add lots of power-ups and polish every detail. Besides, I wanted to address the common complaint about “reach score x” as meaningless goal. The main mode of Gluey 2 was to survive the flow of blobs, a bit like a Tetris.
I was happy with the art of Gluey 1, but I felt I had to make the sequel totally fresh and new. So the game visuals were also redesigned from scratch! RetroStyleGames did a great job at keeping the game’s atmosphere, but making it look even more smooth and polished.
The banjo music track for Gluey 1 was very fun and recognizable, but probably a bit too sharp and repeatable for a casual game that you play often. People tend to either love it or hate it. Francesco D’Andrea created a much more subtle music track for Gluey 2.
Overdoing and Overthinking
The many changes disappointed the fans
Gluey 2 did okay when it was released. The primary license price tag was roughly the same as for Gluey 1 and the game attracted a lot of non-exclusive license requests. But the game did suffer a lot from overdoing and overthinking! In fact, the many changes disappointed the fans. Many claimed that the new gameplay was mindless arcade; they missed their clean and simple “Get score X” puzzles. Many people even wanted the stock banjo sound track back from Gluey 1, which quite a few players originally disliked and characterized as too sharp and distracting.
The new gameplay turned out to be creative, but very counterintuitive! When the blob flow comes, your first instinct is to click as fast as you can. But that’s exactly what you should not do in Gluey 2. Instead you have to carefully create huge clusters of blobs to save on the number of clicks you make. Numerous people left the game frustrated for this reason.
However, both Gluey 1 and Gluey 2 were successes for me. The total revenue from the games is approximately $68K.
Lesson 1: Target the player’s intuition
Going against intuitive behavior is dangerous, and it can go unnoticed until the actual release
Players feel smart if they can use their intuition and real life experience to predict behavior of the game. This is especially pleasing if the behavior itself is not trivial. For example, people immediately realized what the Shuffle Powerup is and does. Everywhere on the forum and in the comments it was called the Rubic cube powerup. Another example of this is sinking blobs. Both from real life and from arcade games players know that drowning is fatal. So it is relatively intuitive that you should keep blobs out of deep water. Only problem here is that players have no way to relate blob density to real world objects. They have no way to predict if the blobs would drown or float!
My partners used a similar metaphor for the iOS port, where they made the liquid look like green acid. Even though acid is dangerous and maybe out of place in a casual puzzle game, it worked really well. Everyone clearly knows from movies and comics that sinking in green acid is the worst thing that can ever happen.
Going against intuitive behavior is dangerous, and it can go unnoticed until the actual release. Pipes in real life feed water all the time (or at least when a valve is open). It turned out it is really hard to grasp that removing a blob on the screen actually releases more blobs from the pipe.
Lesson 2: A sequel does not need to be a revolution
Every little thing I changed in a sequel disappointed at least one player! People liked the original game for a reason. They wanted more of the same type of entertainment in Gluey 2, even though they didn’t want it to look and feel exactly the same.
From now on, my sequels will have…
● the same art style, just more variation and improved quality;
● the same music style, but evolved;
● the same pace;
● an evolved gameplay, not a replacement.
If I ever want to break those rules, I will be making spin-offs of the original. For example, arcade games in this Gluey universe can be Gluey Jumpers or Gluey Shooters, not Gluey 3.
Lesson 3: The Flash game licensing model is still viable
Casual single player games for portals can still pay the bills for an indie game developer. A quality casual game with solid gameplay, professional art will get sponsored and licensed. If I limit the development cycle to less than 4 months, the licensing fees in the first 6 months are likely to cover my costs and finance risky mobile projects.
Non-exclusive sales worked great for my type of games. They can occur years after initial release. Now I am even more reluctant to accept fully exclusive deals for my future games.
Recently, Gluey was ported to iOS. In the mean time, Sergey is working on Gluey 3. To see what else he has been up to, check out his website or Twitter (@sergebat).
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.