One of the developers has just contacted me (yes it is 2 am 🙂 ) and has asked me to give him some information to persuade his investor to make his trip to Indie Prize USA possible as his investor doesn’t think it is a good idea to fly from Australia to San Francisco just to visit the conference. This article is my reply to those who are still hesitating whether to showcase their games or not.
First, let’s highlight WHO WILL VISIT INDIE PRIZE USA 2016.
Color Switch (75 millions downloads)
The infamous Liyla & the Shadows of War (a game based on the story about Palestinian people and rejection from AppStore)
The Forest Song (based on the Ukrainian folk novel, created by an American with Ukrainian roots)
Choices: Stories You Play which was #35 on the App Store’s Top Grossing Games list the first week after launch
Winners of local games’ contests from our Indie Indie Prize Nomination Partners
Up to 20 VR games in the showcase, as well as the opening of a new nomination genre Best VR Game!
Anders Evju’s colleague, John Golden, Playphone evangelist, spoke about paying attention to all markets on behalf of Evju during Casual Connect USA 2014. “Carriers can deliver a better mobile gaming experience,” he said.
Anders Evju, chief marketing officer for PlayPhone, has been involved with mobile entertainment services since its inception in the mid-90s, so he has seen it evolve over the years. He first became involved in the games industry in 2000 while co-founding and working for I-Play as their SVP and general manager and recognized early that the mobile industry was poised for massive growth. He believed that it was the future of communications and quickly discovered that it would be a major platform moving forward.
A Mobile Background
As chief marketing officer, Evju leads all business development and mobile social gaming partnership initiatives for PlayPhone. Prior to his work with PlayPhone and I-Play, he spent a number of years with MobileSpring and gained experience with US wireless carrier background with Omnipoint Communications. He also gained European telecom experience while working in Norway at NetCom BSN, where he was responsible for several major launches including Mother, one of the world’s first mobile portals.
Launching The Store
The most fulfilling time in Evju’s career so far came with the launch of PlayPhone’s social game store on Verizon. PlayPhone has been a leader in mobile gaming and mobile content distribution for the past 10 years. During the feature phone era, they powered mobile entertainment portals for major brands like Disney, Sega, Walmart, and Best Buy, distributing games and content to almost 2 billion users and forming deep relationships with all leading carriers worldwide. The evolution from feature phone gaming to smartphone gaming was the natural next step; they love mobile gaming and wanted to create the next generation mobile gaming experience.
The most fulfilling time in Evju’s career so far came with the launch of PlayPhone’s social game store on Verizon.
Evju says it has been exciting to see the evolution of mobile from flip phones to smartphones. He feels the best thing about his job is being a part of such an exciting industry, and a nice perk is that it involves playing all the new games that come onto PlayPhone’s mobile gaming network.
Mobile is naturally his favorite platform to play on. He plays everywhere, even while sailing in the Caribbean. He does not own any console, especially since he travels and likes to take his gaming with him, but he does reveal that his son got a PS4 for Christmas. Right now, along with everyone else, he is really enjoying Castle Clash. He owns an iPhone, but he doesn’t have a preference between iOS and Android. Both platforms have advantages in his opinion, but the main goal at PlayPhone is to connect gamers from both iOS and Android and let them play games with their friends regardless of the platform.
More Mobile Expansion Ahead
“Mobile gaming is on a steep incline, and we’ll continue to see aggressive global expansion of games, increased penetration and usage, faster phones and tablets, and better graphics in games that will entice even PC and console gamers.”
Evju insists, “Mobile gaming is on a steep incline, and we’ll continue to see aggressive global expansion of games, increased penetration and usage, faster phones and tablets, and better graphics in games that will entice even PC and console gamers.” He points out that we have already seen mobile gaming exploding globally, and it will continue to do so in regions like China, India and Indonesia. PlayPhone is hard at work to be sure their platform takes advantage of these trends, especially in a way that helps localize features so gamers have the most personalized, local gaming experience possible wherever they are in the world.
Besides being an avid gamer, Evju is a father of three children, so he spends a lot of free time with his family. He is also a swimmer and runner who has recently competed his first half-marathon.
Located in the US, Basilisk Games is an independent game developer with the mission to produce old-school computer RPGs. They have been working on the Eschalon trilogy since 2005, and released the last chapter in February 2014. Thomas Riegsecker, owner of Basilisk Games and Lead Developer of the Eschalon Trilogy, shares the story.
A Dream Project
Way back in 2005, I decided to take my notes from years of developing role-playing game ideas and turn them into a computer game. Originally called Under a Riven Sky, the game was going to be a trilogy based on secret societies, the end of the world, and an enigmatic race of creatures so advanced as to appear to be alien to the player. The game would feature pen-and-paper-like game mechanics, an open world, and a genuinely unique turn-based combat and movement system. Before I knew it, I was living off my savings account and working full-time on the game that would eventually be renamed Eschalon: Book 1.
Before I knew it, I was living off my savings account and working full-time on the game that would eventually be renamed Eschalon: Book 1.
Encouraged by an ever-growing fan base who had seen screenshots and read about the game mechanics, I worked night and day for two years to complete the first game of the trilogy. In November 2007, I released the game to the world and was genuinely surprised by the response. The game earned back my full investment in three months and made enough in six months to fund the second game in the series. Not to mention, I was officially a successful indie game developer. Working from home, earning a solid paycheck, and making games was a dream come true.
2007: A Very Different World for Indie Games
When Book 1 launched in 2007, the gaming scene was very different than it is now. There were no tablets or smartphones back then. Computer displays were predominately 4:3 CRTs, and even the few LCDs that were available were not widescreen formatted. Indie gaming was in its infancy and the market was uncluttered. Eschalon: Book 1 was right at home in this market, and it sold very well to gamers who were tired of the path that mainstream RPGs had taken over the previous decade.
By 2010, things had changed dramatically.
However, between 2007 and the launch of Book 2 in 2010, things changed dramatically. Many people had dropped their old CRT monitors in favor of a 16:9 wide-screen LCDs, yet others still clung to their old, beloved square CRT displays. This was a problem because the Eschalon game engine (which I was committed to reusing for all three games) used a fixed resolution with bitmap sprites. It was not particularly flexible and trying to make the game look good on these different displays was difficult. Although I did increase the native engine resolution up to 1024×768, I did not adjust it to a 16:9 format which was probably my single biggest mistake at that time of Book 2‘s development.
A Crowded Marketplace
The most dramatic change between 2007 and 2010 was that indie gaming had exploded during this time. When Book 1 launched, we had all the media coverage we could want. The game was featured in mainstream gaming magazines and websites, and not a week went by that I wasn’t asked to give an interview or write an article about the development of the game. But by Book 2‘s launch in 2010, we were just another indie game among hundreds, and our fixed resolution engine no longer looked as good to gamers who were accustomed to seeing high-resolution 3D graphics. I had to work much harder at promoting the second game, which ate into the first year of my development time on Book 3.
I had to work much harder at promoting the second game, which ate into the first year of my development time on Book 3.
Of course, by the time Book 3 launched in February 2014, the indie game scene had become an out-of-control monster. The market is now over-saturated, with dozens of indie games coming out weekly. This has driven the sale price of indie games to an all-time low, and even then, many customers will wait for the 50 percent discount that they can expect over the summer and holiday sale drives. It seems that as the indie scene grows more popular with the mainstream gamer, “niche genre” games are pushed further out of the spotlight for games that feature tried and true, familiar elements. And remember that mistake I had made in not converting Book 2‘s engine into widescreen format back in 2010? In 2014, many gamers refused to even try Book 3, citing the lack of widescreen support to be too jarring to be able to enjoy the game.
Reflecting Back and Looking Forward
It seems “niche genre” games are pushed further out of the spotlight for games that feature tried and true, familiar elements.
If I am honest about what has made Eschalon a minor success, it’s because it is a game series that caters to a very narrow spectrum of gamers. Many of our customers are over 30 and grew up on pre-Diablo style role-playing games, and they are looking for a very specific type of gaming experience now. These are the customers I focus on because if I tried to appeal to the mainstream gamer mass, I would be neglecting the customers who have supported Basilisk Games from the start. It’s a challenging path to follow, and more than once I drew the ire of Eschalon fans for trying to add a feature that I hoped might draw in new customers. Catering to this niche market has limited the game’s appeal to the general gaming audience, though it is the very reason for Eschalon‘s successes as well as its failures.
From the earliest design phase in 2005 to the release of Book 3 in 2014, it has been a long and difficult road marked with many highs and lows.
It’s hard to believe that I’ve spent nearly nine years working on Eschalon. From the earliest design phase in 2005 to the release of Book 3 in 2014, it has been a long and difficult road marked with many highs and lows. I’ve been asked by many people, “Was it worth it?” I assume that people want to know if the money I’ve made from the games justified the ridiculous, unhealthy number of hours I worked to develop them. I can’t really answer that right now - not until I’ve had a chance to decompress from this final game development cycle. Although, I will give some advice to other indie developers: do not let a large project take over your life. It’s very easy to find yourself working day and night, weekends and holidays, all towards the dream that your game will be loved by all and will sell a million copies in six months. That kind of success is extremely rare and the mental burnout that you experience from such an extended, crushing workload can have long-lasting, negative effects.
Our fans are already asking us what is next for Basilisk Games, and the truth is that the future is more clouded than ever. Everything depends on how well Book 3 sells in the next six months because this will determine the budget of the next game. One thing is for sure: Eschalon is done. There will not be another Eschalon game, and the Eschalon engine will not be used again. Beyond this absolute truth, I am honestly just as as curious as our fans are to discover what is next for Basilisk Games!
The Eschalon Trilogy is available on Steam, GoG.com, Mac App Store, and on their website. Stay up to date with Basilisk Games by following them on Facebook and Twitter.
Released in November 2009 for the Xbox360 and PS3, Fairytale Fights is an action hack-and-slash platform game supporting up to four players. The game combines cute looking fairytale characters with over-the-top slapstick violence. The game was developed by Playlogic Gamefactory, the in-house development studio of Playlogic. The studio previously had worked on titles like Xyanide (Xbox), Cyclone Circus (PS2) and Xyanide Resurrection (PSP, PS2). The studio also worked as first party developer for SCE London Studio on titles like Eye Pet, Mesmerize, Aqua Vita (Aquatopia in North America), Tori-Emaki and Pom Pom Party. In this post-mortem, Martin Janse tells the story of Playlogic’s game Fairytale Fights.
Instead of a making a game for children, we wanted to create a game that would appeal to an adult audience by using over the top slapstick violence and comical gore
The game started as concept for the PlayStation 2 Buzz controller party game. Gradually, the concept started to evolve into something bigger that could only be developed on the Xbox360 and PlayStation3 platforms. In Fairytale Fights, you play the part of a used-to-be-famous fairytale character on a personal mission to regain his/her lost fame by going on quests throughout the kingdom. A quest could be rescuing princesses (and princes), fighting wicked fairytale characters or finding magical treasures. The fairytale world consists of cute characters and vivid animations as seen in many 3D animation movies, but instead of a making a game for children, we wanted to create a game that would appeal to an adult audience by using over-the-top slapstick violence and comical gore that also can be seen in cartoons like Happy Tree Friends or Itsy and Scratchy from The Simpsons.
Since the game was targeted for Next Gen-consoles, we felt the game should include some unique features. One of the programmers had been working on a real-time fluid system and we wanted to incorporate this technology in the game, not just for creating all kinds of liquid effects, but also for the blood that would cover the whole scenery and drip from objects. Another idea we had was that the player should be able to slice enemies and objects dynamically so in theory, the player could slice everything he wanted in any direction he would choose.
In early 2006, a team was assembled. They started working on the high-level game design and creating a short animated movie showing some of the core gameplay mechanism and general visual style of the game. After a couple of months, the team of animators, visual designers, modelers and a game designer produced a stunning short animation that convinced everyone that this had the potential to become a fresh and fun game.
Pre-production
The preproduction period was challenging
Before pre-production started, our technical department evaluated different middleware solutions. They came to the conclusion that Unreal 3 Engine was the most suitable tool for creating Fairytale Fights and other possible future titles. It had a very strong editor and was by then the only middleware solution that proved it could deliver quality results on both PS3 and Xbox360. We knew that it would take some time to set up the work flow and to learn Unreal 3. As a result, a small team was assembled to start learning Unreal while also working on the liquid and dynamic slicing technology and creating content in order to develop a vertical slice of the game.
“Our ambition to make the game look like an interactive cartoon was finally met.”
The preproduction period was challenging. The team encountered several technical obstacles such as recreating the experience of the prototype movie to a vertical slice of the game. Fortunately, a couple of weeks before the Leipzig Games Convention in August 2008, something magical happened. After making some harsh cuts and redesigns, everything fell in place. The vertical slice became a game with a soul, fun to play and a delight to watch. The vertical slice looked gorgeous and the dynamic slicing and liquid system worked. You could even jump into the puddles of blood and red drops would color your surroundings. Also you were able to slide through the blood puddles, painting the world red.
Sometimes we could see the journalists thinking “Oh no, not a kiddy platformer! Another 20 minutes wasted of my precious time!”
The decision was made to present the vertical slice only to a select group of press behind closed doors during Leipzig Games Convention. We all knew we had something special, something different. But the question was if the critical games press would like it as well? We all knew we took a chance with Fairytale Fights. Everyone was using the power of the recently released Xbox360 and PS3 to show realistic looking masculine battle scenes in space or industrial locations. Alternatively, we were creating a game that from the first glimpse looked like a game made for children, but contained cutting edge technology to recreate cartoon violence (salami violence as we called it internally) like dynamic slicing and dynamic liquids.
When we started our presentations during the Games Convention, sometimes we could see a journalists thinking “Oh no, not a kiddy platformer! Another 20 minutes wasted of my precious time!” But once we started the dynamic slicing on the first innocent bunny into small pieces and slide through the puddle of blood from the bunny, you saw a big grin on the faces of most of the journalists and they were keen to learn more about the game.
Starting Production
After the Leipzig Games Convention, it was clear that Fairytale Fights might become something big. Some journalists even wrote Fairytale Fights was the biggest surprise at Leipzig GC that year! Now we had to develop the full game. It took almost 1.5 years to create the vertical slice, a tiny fragment of the whole game. Some key features of the game were working, but still a lot of work had to be done, especially creating content (models, animations, levels) and making sure it would run on all supporting platforms.
One of the biggest issues we already faced during pre-production was finding skilled people. A studio in Rotterdam (not far from the development studio) called Coded Illusions went bankrupt. They were working with the Unreal Engine for several years and we were able to make several formal employees interested in working at the studio, but this was far from the amount people we needed to develop all the content needed (creating models, animations and levels). So we got in touch with a studio that was specialized in building props and animations for feature films and animated TV-series. They were in-between projects and were eager to enter the game content business. Only there was a small problem, our team was not finished with the design and they were working day and night to make sure all the deliverables were available to them on time.
Fairytale Fights was scheduled for a late 2009 release. Sometimes it felt like a mission impossible, especially when things didn’t work out as expected. We had to some cut features and content that was originally scheduled for the game. Everyone at Playlogic was extremely dedicated and spent many hours to finish the game on time.
A group shot of the entire team.
Looking back
Not being able to attract as many experienced candidates to the studio as we would like also caused delays
As mentioned before, the pre-production took longer than expected. Most of the lead members of the pre-production team were recently promoted and had no or limited experience with starting projects from scratch. Also several key members of the team had to support other running studio projects every now and then, also delaying the pre-production. Not being able to attract as many experienced candidates to the studio as we would like also caused delays. We were recruiting, but it was difficult finding skilled people that were also willing to relocate to Breda (the location of Playlogic Gamefactory, in the south of Holland). After the positive feedback during Leipzig GC in 2008, it became much easier to attract skilled personal. Also the decision to outsource work to other companies meant that people who otherwise could help in production, were now managing outsourcing.
Another thing that caused the delay was that sometimes development was dictated too much by the visual design of the game. For example: at the start of the game, the players and enemies are moving on forest paths with varied terrain. It looked great, but it caused a lot of problems regarding Artificial Intelligence, collision and physics. Looking back, too much time was spent on trying to solve technical issues that were caused by these visual decisions instead of finding alternative visual solutions so these technical issues would not arise.
When the game was released, it received mixed reviews. Many journalists liked the colorful visual style and over the top cartoon violence of the game, but found it a bit too repetitive or didn’t like the usage of the right stick for performing combat moves. Combat is indeed sometimes a bit too repetitive. There were many more puzzles and platform challenges in the original design of the game, but not all of them made it to the final version of the game, making the game too dependent on combat alone. After speaking with a lot of players (especially female players), there was also many who liked the usage of the right stick for combat. It made the game accessible and suitable for co-op play with less experienced gamers, because using the right stick for combat felt intuitive. Several male players told me that Fairytale Fights was one of the few games their girlfriends or wives enjoying playing and they both enjoy playing in co-op mode.
Several male players told me that Fairytale Fights was one of the few games their girlfriends or wives enjoying playing and they both enjoy playing in co-op mode
Not such a happy ending
After the release of the game, a small team continued to work on DLC, which was released shortly after. The rest of the team started pre-production for Fairytale Fights 2. The first Fairytale Fights 2 prototypes were very promising and showed the team had many new fresh ideas. Unfortunately Playlogic encountered financial troubles and the studio had to close its doors halfway 2010 just before winning 2 Dutch Games Award 2010 for Fairytale Fights a few months later.
Some footage of early prototypes of Fairytale Fights 2 has leaked unto the internet. If you are interested, you might be able to find it. Playlogic is currently only publishing games, primarily focusing on publishing digitally on consoles, handhelds and mobile devices.
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 showcased the game to gameplay testers (including some industry leading people), they found the Arcade mode to be more fun.
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.
Though we improved the basic gameplay mechanics of Wobble Bobble, no major changes occurred.
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!
Post Release
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.
Wobble Bobble is available on iOS and Android.
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.
George Zarkua is an indie game developer with four years of experience. He is the artist and game designer of Nude Hunter, Ragdoll Ball, Dream Symphony, and Spicy Story. He recently started his own studio, called Zarkua Studio.
A Vague Start
George Zarkua
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.
Character progress
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.
Rush Mode
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.
The sheep in Dream Symphony
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.
Zarkua recently released his new game, a shooter called Roswell Defense.
Kjell ‘t Hoen is a game designer from the Netherlands, specialized in casual games. After creating his own concepts for his ‘Ludomo Gamestudio’, he is now mainly working as a game developer at Tingly Games. Kjell has a passion for making games and is always looking for new and original gameplay. This article describes the process of one of his games that he made in collaboration with YoYo Games, called Rick ‘O Shea.
The original idea for Rick ‘O Shea came from one of my earlier games called Curve Ball. Its core gameplay was controlling a metallic ball with the environment, i.e. launching it with flippers, bouncers and canons and having it follow rails. The concept came to me by looking at some beautiful clockworks and jewelry, which inspired me for the original design. The goal was to make something shiny and fun.
Since I was working with Gamemaker for a very long time, I had enough game concepts to show
The Rick ‘O Shea journey originally took off when I met Mark Overmars, the creator of Gamemaker (the engine I had been working with for years) at the Festival of Games 2011. He was interested in working together with indie/amateur Gamemaker developers who had interesting game concepts for mobile devices. Since I was working with Gamemaker for a very long time, I had enough game concepts to show and since most of them were one-button they were quite fit for mobile devices. So I met with Mark a few times, where I presented some of my ideas which I had already polished a little in the past and we picked the one that seemed the best fit.
Working together with Mark and YoYo Games, we developed my raw concept into a fully fletched app for iOS and Android. Both Mark and the YoYo Games crew put in a lot of effort to steer the design and gameplay to an even higher level and I feel the eventual product is as polished and fun as it can get. As a great bonus, half way through the process, I was invited to fly over to Scotland where YoYo Games was situated, to finish the game. Personally this was a great opportunity and made for an amazing experience.
Tackling art issues
The first graphical design
Right after the kickoff, the biggest issue we tackled was the theme and art style. It had to look great and we needed a believable ‘world’ as a setting for the rather abstract game mechanics. As my original idea was clockworks and jewelry, I first did a redo of my own graphical design for that. This design however lacked a likable character and believable world, so after it was rejected I thought about coins and how you could collect coins with a living piggy bank. That concept was also rejected, this time I think due to my personal lack of art-skills. Eventually we decided to move the entire art-issue over to Yoyogames. They were kind enough to assign the project to one of their in-house artists: Alan Morris, with whom I worked on the game from that moment on. He came up with the circus concept, and since that theme had actual cannons it fitted the mechanics perfectly. Also, with the art out of the way I could now completely focus my attention on gameplay, level design and programming.
Mistakes made, lessons learned
In Rick �O Shea, canons rotate automatically. The main thing the player has to do is time their shot when a canon is pointing in the right direction and make sure the ball ends up in the next canon.
The original concept was focused on one-button, being the entire screen. I had designed the levels in a way that experienced players could do speed runs, which could change pace of the game and offer some immersive gameplay. Mark and the Stuart however, convinced me early on that it would be better to give the player more control, by enabling the player to aim, turn the canons towards the finger of the player and not having to wait for the canon rotation. This was a tough decision for me because my entire concept was based around this mechanic. On the other hand, my original concept had huge levels, but the app version would consist of smaller levels. So I decided to go for it. This turned out to be for the better. Even though I had to let go of all my initial levels, I found that I could create even more interesting and challenging levels and that the gameplay now offered more freedom.Rick ‘O Shea would have been an entirely different game if not for this change.
The model would go from paid to in-app purchase where players could unlock two new worlds for each payment.
Another big issue was the business model. The idea of getting my old game concept to mobile devices got me really motivated, so before I knew it I had created 100+ levels. After showing them to Stuart, he suggested to break up the levels and sell them separately. The model would go from paid to in-app purchase where players could unlock two new worlds for each payment. This would also be a nice trial for YoYo Games to see if Gamemaker, their main engine, could handle in-app purchases properly, making it as Stuart called it the studio’s ‘guinea pig’.
I believe this has been a big mistake. What we did was divide the levels into 5 different episodes and give the first episode (24 levels) away for free. Even though we thought long and hard on how many levels to give away for free and what mechanics they should contain (and what mechanics to save for later), this was nothing more than an educated guess. And so it turned out to be. Even with more than a million downloads the number of actual sales was extremely disappointing. Looking back at this decision, there are simply too many risks I would never dare to take again. For example:
The player plays the free levels, has the feeling he has seen most of what the game has to offer and deletes it.
The player plays the free levels, loves them and downloads the game for free from some obscure website.
The player does not open the game at all and still mentions it is shit, causing a bad review (this actually happened!).
The player plays one level, doesn’t get it and deletes the game without looking beyond the first try.
I do believe the in-app purchase model can work nicely for extra gameplay variations (other weapon types and new features) that make it easier to play the game or offer the player more choices and strategies. The old demo/shareware model we went for though, was just not working out.
Personal development
I learned I was making levels too easy, this was a huge realization for me as I looked back at many of my other games
During the playtesting phase, done in the university where YoYo Games was located, I learned I was making levels a bit too easy. This was a huge realization for me as I looked back at many of my other games. The game was simply not challenging enough and I ended up giving 120 levels more ‘teeth’ and dangerous situations, which really made the game way more interesting and balanced.
Working with Mark and Stuart was a big deal for me and I was interested to see how a company like Yoyogames operated. They turned out to really supportive and had a lot of experience with creating games. They also gave me a lot of freedom and useful feedback while creating the game and tweaking it. But I also learned, when signing contracts about royalties, is that you should always check when you are supposed to get paid. I completely trust Yoyogames and I enjoyed working with them, but waiting for 9 months for a royalty payment is not cool and eventually took away some of the enthusiasm for making games on my own. I always say I’m not in it for the money and I am very patient, but without any financial results it’s hard to keep going and stay motivated.
Tips
Don’t do in-app purchase for levels, it’s simply not working. In-app purchase for extra variations, gameplay, strategies or guns can work fine, but not to complete the journey the player is on. In Rick ‘O Shea we also sold extra skins, which I think comes closest to what could have worked
Playtest with a wide variety of people. The play testers Yoyogames invited were really good, but most of them were also heading into game development. We could have done a better job if we had had some little children or grandparents play the game as well. I realized this after returning home and showing the game to my friends and seeing them have a really hard time getting past infamous level 5. So it was great feedback to make the levels harder, but what we missed was the feedback from the non-gamers as to where the game was too hard.
The day after
The day after Rick ‘O Shea was published on Google Play and iTunes it got featured on Kotaku, who made it ‘Gaming App of the Day’. I remember Andrew McCluskey, an employee at Yoyogames who became a good friend, coming over to my desk, tabbing me on the shoulder and telling me ‘Dude.. you’re on Kotaku’. Pocketgamer was next, giving the game a Silver Reward and a few other smaller websites gave some pretty nice reviews.
Checking some of the first levels of the game and looking at my bank account made me doubt whether or not my game was really as good as it could have been
A few months later, in March, Rick ‘O Shea got featured on Google play. I have an iPhone but I got a photo from one of my friends who saw the game sitting right next to the new Angry Birds Space and Sims. That really good news and as I heard later, caused for some 80k extra downloads per day. All this was great, but the best feeling I have comes from the fact that the game still has a 4 out of 5 star rating with 3300+ votes. That made the game my greatest success so far. But even though Rick ‘O Shea was such a great success, I realize I also made some mistakes. Checking some of the first levels of the game and looking at my bank account made me doubt whether or not my game was really as good as it could have been.
After creating Rick ‘O Shea (Apple AppStore & Google Play store), Kjell decided to move forward and work for a new exciting company called Tingly Games as a Gamemaker developer. In his spare time, Kjell is still working on his own games. For example, he collaborated with NextGamez and Gamious on a hidden object game called Excursions of Evil, which is to be launched soon. If you are interested in what he’s currently up to, check out Kjell’s blog.
It all started in the end of 2009 with three guys: me (Eugene Karateav) as the flash-developer; php-programmer Pavel Kostyuk ; and artist Alexey Egoshin. We decided to create our own website with flash games. In a couple of months we created the website’s engine, design, added several games, et cetera. In short: we made yet another websites full of flash games. With our website up and running, we needed a new flash game to promote our site, which would be Wake Up the Box 1. The game’s idea was born after my endless experiments with the physics engine Box2D. We developed the game in less than a month and released Wake Up The Box 1 in November 2009. It was surprisingly popular. In its high days, it attracted over 150.000 visitors. It was clear that we had to create a sequel. So, we created Wake Up The Box 2 and 3. After that, I decided there were enough games in the WUTB-serie and started doing my own thing: experimenting with the physics engine itself.
I would play for hours, just drawing objects
I continued creating new mechanics and one day I realized it was a lot of fun drawing shapes that behaved in accordance with the laws of physics after their creation (similar to Crayon Physics Deluxe). I would play for hours, just drawing objects. It was fun to see how they became rigid after drawing, how they fell under gravity, how they collided and bounced into each other. I decided to create a game based on this mechanics, which led to the first prototype. In small indie games the main and most important part is an interesting gameplay. Characters, story, art, etc. are secondary. So, after the prototype was done, I decided it was time to think about the world around the core mechanics. After some thinking I settled on the good old idea of waking up boxes. So, that’s how Wake Up the Box 4 was born.
Lessons learned
Development’s iterations using prototypes - Iterative development is very important when creating a game with an original gameplay. Our game’s idea is pretty simple: a player draws an outline, which becomes a physical object after creation. These objects are used to wake up the box in each level. I went through 10 iterations to make the drawing process as easy and user friendly as possible. The process went as follows:
Make a prototype.
Show the prototype to different people.
Watch the players play the prototype, pay attention to their reactions (pleasure, frustration, etc.).
Make changes to avoid the frustrating moments.
Go to step 2.
Sometimes a player tried to create a circle dozens of times and had no luck. In other cases they tried to make a rectangle but got a circle.
There are a couple of advantages to using prototypes. For example, in our game we have some predefined areas where a user can draw objects. The drawing process is allowed only inside those areas. Therefore, even if you move the mouse outside the drawing zones, the mouse pointer stays inside. You don’t have to worry about drawing carefully inside the areas. In our first prototypes the situation was different. A player could get out of the area’s bounds and that meant that the drawing couldn’t be completed. It was very frustrating for the players to try hard to stay inside the zones. And, of course, getting out of the drawing area caused outbursts of anger. We solved this problem by not letting a player get out of the drawing areas. A player’s outline is stuck to the area’s bounds.
Second, we learned about the difficulties creating circles. In the earlier versions of the game one had to draw an outline similar to a circle to get a round object. But it was a tough task for a player to do. So, in the next version I made the process of drawing circles a separate tool.
If you want to reach a wide audience, you should playtest using a wide audience
Test everywhere - If you want to reach a wide audience, you should playtest using a wide audience. Test it on your friends, colleagues, and relatives. A wide audience helps to get a lot of views at your game from many different perspectives. For example, I use a high quality wireless mouse and it’s easy for me to draw. But one day I was at my friend’s house and tried to play Wake Up the Box 4 with his mouse. It was really painful trying to create objects with that mouse. But this situation helped me to realize that players have different computer mice, and it forced me to make some changes in the level design.
Refactoring - When you work as an indie, you have a lot of ideas coming up in the development process. You constantly add, remove, modify and upgrade your game’s features. And as a result, you have a mess instead of code. You have no extrinsic motivators like bosses or deadlines, so it’s very important to sustain your intrinsic motivation to make a game. And that’s why you have to clean up your code every time you feel you get lost in your own code. I sometimes refactor my code even after the project is released.
Some tips
Experiment! - For example, in Wake Up the Box 4 we decided to make some drawing animations in the game’s main menu. Players liked this feature a lot. It showed endless possibilities of drawing different objects and their combinations. And we received a lot of feedback from people saying that they enjoyed not only playing but also just watching those animations.
In the main menu, an example drawing of a house is shown to the player.
The main advantage of us being indie developers is the ability to experiment with our games.
Simple idea - I believe that indie games should be based on one simple and original idea. The main advantage of us being indie developers is the ability to experiment with our games. We can decide which way to turn the development process and we’re independent from the publishers with these decisions. We can’t compete with big teams in the quality and the amount of the content, but we’re much more flexible with creating new game mechanics.
Check out the Wake Up The Box series at Olologames.com. Wake Up the Box 4 was nominated for the game of the year award in the category Physics on JayIsGames.com. In the future, Eugene Karataev will continue work on the physics genre and develop new games based on the physics mechanic.
Ian Schreiber has been in the video game industry since the year 2000, first as a programmer and then as a game designer. He has worked on eight published games, two textbooks, two free online courses in game design, and several other things he can’t talk about since he’s still under NDA. He has taught game design and development courses at a variety of colleges and universities. He is a proud father of an almost-two-year-old, whose favorite activities include talking on the phone, going to the zoo, playing iPad games, playing in the sand, and tucking her stuffed animals into bed, although her favorite “toys” by far are mommy and daddy. From this experience of seeing his child playing with an iPad, Ian shares four game design essentials with us on developing games for toddlers.
1. Design for a child’s hand and touch
If you actually make a distinction between finger-swipe and palm-swipe, and if your hit boxes aren’t really tolerant of near-misses, you’ll have a hard time convincing me that any kids tested your app before release. Most storybook apps are pretty good examples of how to do this once you get them started - any kind of finger or palm swipe to the left or right turns the page, plus there are buttons in the corners to flip pages if you touch them.
2. Avoid having loading screens
Is there really a reason or need to have several gigabytes of 3D animations in a kids’ game?
If your loading screen takes more than a second or two, my kid will think your app is broken. She doesn’t understand the concept of loading screens, but she knows how to hit the button to get out of your app and pick something else. If your game is aimed at young kids, just how much complexity do you want to have in there?
I suggest two ways of testing your loading screen. One is to set an actual metric goal, like half a second or less from startup to full load, and then you would just measure it. The other would be to test with actual young children, give them an iPad, have their parents guide their finger to touch your app in order to open it, and see what the kid does from there. I recommend you test with some kids who have iPads at home, so they know how to hit the button to exit an app when they get bored.
The trick is to not have loading screens of any noticeable duration in the first place. Most kids’ apps don’t particularly need to be all that complicated, they should not have a massive memory footprint or CPU requirements in the vast majority of cases. I assume any app that is running into long loading screens is either not (completely) optimized (i.e. the programmers were incredibly lazy with memory allocation or the use of inefficient graphics algorithms) or else it contains far too many assets for its own good.
3. In-App purchases don’t work
Don’t monetize via in-app purchases
In short: Don’t monetize via in-app purchases, I turned those off ages ago (as did any other parent who knows better). Also, if your business model relies on toddler miss-clicks when parents aren’t looking: well… you’re the one who has to live with that on your conscience.
My toddler doesn’t really grok in-app purchases yet, so the subject of how to let her buy something that she wants in a game hasn’t really come up. I’m pretty sure she kind-of-sort-of understands the concept of exchanging money for a tangible object like a toy or stuffed animal, but in-app purchases are another layer of abstraction that my almost-2-year-old hasn’t really figured out yet. Mainly, any purchase screen, subscreen, or menu that takes her out of the game, she just sees as some kind of annoyance that takes her away from the game.
I decided to disable in-app purchases after seeing far too many stories of parents whose kids made hundreds of dollars worth of purchases without the parents’ authorization. Yes, there’s a password in there, and my kid probably doesn’t have the manual dexterity or understanding to key in my password. Yet. But she’s an information sponge who has shown herself quite capable of mimicking just about anything she observes. I know it won’t be too long before she’ll be able to enter my password and surprise me. Better to be safe, than trying to fight a protracted battle between me, my daughter, some hapless developer, Apple, and my credit card company.
4. Do you monetize through in-game ads?
I just can’t imagine ads working on really young kids (1.5 to 2.5 years) in any conventional sense
My kid doesn’t grok ads. She might click on it by accident or on purpose because it looks colorful, but then you just take her out of the game and confuse her and she’ll shut the thing down and try something else. If you use a third-party ad server that asks a 2-year-old if they want to find a date on Zoosk, your app is getting deleted. (No, “it’s a third-party component, we have no control over it” is not a valid excuse. Your app, your responsibility.)
I just can’t imagine ads working on really young kids (1.5 to 2.5 years) in any conventional sense. Perhaps an advertising expert would disagree, but just from observing my (pretty smart) kid right now, she really just does not understand the concept of ads in the way that advertisers would like. It’s like designing all-text ads in the Japanese language, to an audience of monolingual English speakers: 99% of your meaning is lost. And if you’re asking how to interest the advertisers, I’d say you’re asking the wrong question! The real question here should be: “Okay, so in-app purchases and ads don’t work. What’s the way to monetize a very-young-children’s app, then?”
The answer: monetize via app sales. Make a free version of your app that shows what’s cool about it, just enough for a kid to play around and get engaged and interested (and for the parent to observe this). Then make a paid version with the full feature / content set unlocked. If it’s a ridiculously simple app that kids just find fun anyway, like a set of interactive flashcards or a counting or drawing app or something, I’d expect to pay 99 cents for it. If it’s a more full-featured app, like an interactive storybook that will either read itself to you, let you read it, or let the parent record it in their voice, plus some minigames related to the story, I’d expect to pay $4.99 for it. Those seem to be the price points of the successful apps I’ve seen, and why spend more when there are plenty of great apps at these prices already? Only time I’ve seen anything go above $4.99 is when it has a golden IP like Disney.
Alternative monetization if you have a whole series of apps: make one app totally free, charge for the other ones as above. A lot of storybook apps do this, but I’ve also seen it for apps that use the same core engine with a number of different themes.
But… there is hope!
If you want to know the best apps out there, instead of just taking my word for it (after all, I’m just a random developer who’s never made a kids’ game, mouthing off about this because I have a toddler and am frequently frustrated by the apps I download for her), I’d recommend searching on Google for “Best apps for kids” or “must-have ipad apps for toddlers”. Then just find a number of top-10 lists from other random parents mouthing off and take note of the apps that seem to be on a lot of the lists. Besides that, you can try the top-selling kids’ games in the App Store or look for other articles on kids’ games.
That said, there are some games I would put forward as positive examples (and one mixed example):
Toca Doctor HD - similar to the Trauma Center series or the Operation board game but for a much younger audience. First of all, it is a perfect example of a game that is designed for kids. There are basically no loading screens and the main menu is a giant button that takes up most of the screen so my daughter can start it on her own. After pressing the giant button, you’re taken to the main game menu where the only controls are things that flash or animate so it’s pretty obvious where to touch (and the hitboxes are generous). Each touch takes you to one of a variety of WarioWare-style minigames. Playing it for the first time, the minigames were hard for her to figure out on her own, but once I guided her hand with each of them she was able to do most of them on her own. Each minigame also has an exit button that’s always in the same corner, so it’s easy to exit a minigame when you’re stuck.
Toddler Counting - a very simple app where it just asks you to count some number of objects using your voice. Touch an object and it counts 1, then 2, then 3, and so on until you’ve touched them all. When done, it gives verbal praise (and in some cases an additional sound, like if you’re counting kittens it’ll meow at you). The free version does this like 4 or 5 times with fixed content and then locks up; the 99-cent paid version has more content and keeps going forever.
Again, there are no noticeable load times. Besides that, the main menu has two really big buttons: “easy” for counting 1-10, and “hard” for counting 11-20. No other controls at all, just touch the objects. About as simple as it can get.
I Hear Ewe Animal Sounds - another simple app. No main menu at all - it just throws you right into the app. The screen is divided into 12 large buttons, each one with an animal icon on it. If you tap an animal, the graphic will enlarge. Then a voice says “this is the sound an owl (or whatever animal) makes” and it plays the sound. You can sweep between three pages worth of animals with a finger or palm swipe.
Miss Spider’s Tea Party, and Toy Story Read-Along - both of these are interactive storybooks and similar in format. The main menu has relatively small buttons and does require my input to start off, at first. However, she’s seen me do this enough now, so she can start up the app and select what she wants on her own. The app features options to read the story manually (finger-swipe, palm-swipe, or touch a button on the side of the screen to turn pages); have the story read to you (basically playing a video, pages turn automatically, voice reads to you, words highlight as they are read); and play some mini-games with the story theme (small jigsaw puzzle, card matching, etc.).
Miss Spider’s Tea Party
While neither of these seems to have any load times, both have a brief intro animation on startup (same way the Sega Genesis always started up with “Seeee-gaaaaa!”) so I suppose it’s possible that it’s doing some loading while that animation plays, without announcing that it’s doing that - if so, clever for them.
So both of these apps include a lot of rich content and lots of stuff to do, which is pretty impressive for free apps. The other storybooks in the same series cost - and cost a lot - but they do show how you’re getting your money’s worth with the free app.
Play Phone - this one, I have a love/hate relationship with. Every time my daughter starts it up I debate whether I should delete it. On startup, first thing it invariably does is pop up a small text dialog asking if I want to leave the app, for reasons I don’t understand. Tapping �no’ reveals the main menu, which has three buttons which are all horizontal and spaced fairly close together. One of these takes you to the actual game, another to the developer’s page, and the third pops up some kind of announcements page (and they like to make frequent announcements that are, of course, completely meaningless to a toddler). So, a play session of this basically starts with my daughter starting the app then calling me over to help her past the main menu.
Once you get past that, it’s a simple app where you have a standard 12-button phone layout. Hit a button and it plays a short animation. My daughter finds quite fun, even if I find it grating to hear the same sounds over and over. Additionally, the app includes one button where the parent can record their own message for playback on one of the buttons. This is done by hitting a two-button combination, in order to prevent the kid from recording over it accidentally. Great idea for a feature, but there are two problems, which I assume came from a simple lack of field testing. First, hitting the playback button before anything is recorded leads to the app locking up for 30 seconds or so. Second, hitting the record button on its own pops up a small text dialog that explains how to record properly. which is fine for me, but meaningless to my daughter, and difficult for her to dismiss if she brings it up by mistake. The app is free though, so I guess you get what you pay for.
Currently, Ian is (again) under an NDA. However, you can check out some books he co-authored: Challenges for Game Designers and Breaking Into The Game Industry. Be sure to check out his blog as well.
Stolen Couch Games is a young Dutch game studio formed by six alumni from the Utrecht School of Arts who decided to continue working together after their college projects. A part of the team came together to make a multiplayer prototype for XBLA and PSN title Chime made by developer Zoe Mode in collaboration with the One Big Game initiative. Stolen Couch Games then reformed and expanded the core team with an extra programmer and artist. Gamesauce recently featured a post-mortem on their first game Kids vs Goblins.
Early 2011, everyone at Stolen Couch Games was still in school developing our exam year project Kids vs Goblins. Jay van Hutten, a fellow year mate, was developing a game of his own called Ichi. It was a elegant puzzle game that utilized a one-button mechanic in a way that didn’t feel gimmicky. The goal of the game was to guide a ball past a number of rings on the screen. By touching the screen you rotate bumpers, which caused the ball to change in direction. You could also hold your finger down to draw a line, once the ball hit the line it would travel back in the direction it came from.
About a half year later we spoke to Jay at a congress were he was demoing his game. I (Eric) shared my interesting in redeveloping Ichi for multiple platforms and making it a really great commercial product. Jay loved the idea and the day we finished Kids vs Goblins we were working together to make a bigger and better version of Ichi.
No developers were harmed during the making of this game
Because the core of Ichi was so sound, it wasn’t hard to come up with dozens of new puzzle ideas to make the game better.
Redeveloping a game is nothing new to us. Stolen Couch Games actually started in 2010 when we got an assignment from Zoë Mode to create a multiplayer version of their hit game Chime. The multiplayer demo we made eventually led Zoë Mode to develop Chime Super Deluxe, which featured some nice multiplayer modes. While the programmers were re-creating Ichi in Unity, Jay and I were designing new features to add to the game. Because the core of Ichi was so sound, it wasn’t hard to come up with dozens of new puzzle ideas to make the game better. The final product had teleporters, splitters to create multiple balls, objects that could disappear and a few more things. Nothing too fancy, but it all worked great. The best thing we added was the level editor that allowed players to create their own levels and share them online. Since then, 11,000 levels have been shared, quite a bit more than the 50 levels we originally included with the game. Ichi launched in June, after 3 months of development, which went mostly smoothly. The actual problems started right after we launched the game.
Getting featured
We knew that many people would consider Ichi as just another puzzle game, so we had to let people know how special the game really is. We spent about a week contacting the press about our game and we got a nice amount of coverage. But press alone won’t make your game a hit. If you read any guide on marketing for mobile games you always get to the point were the importance of getting a feature by Apple/Amazon/Google is expressed. We already got a feature on the Mac app store for our first game, but our published arranged that. We didn’t have a direct contact within Apple, so we had to come up with a way to contact them.
Luckily we had a few device IDs that belonged to Apple employees on our Testflight account. So we found out the matching email addresses and we send separate emails to every one of them. 2 of them, responsible for the iOS AppStore, loved the game and showed the game to the rest of the team. Our contact from the Mac AppStore was in love with the game. We Skyped for a few hours and everything was set.
Ichi was Apple’s Editor’s Choice for a week on the Mac AppStore and on iOS we were bumped to the new and noteworthy category and we got a small banner in the games section.
We’ve seen developers doing no marketing at all for their games because they believe they’re games will sell themselves. This is mentality is wrong. Just look at the top grossing games on iOS. Almost all of them spend enormous amount of time and money on marketing. Only by spending time and money, will you actually earn money.
Mayday, mayday!
The lessons we learned from this is that you should be prepared for something you can’t predict or test.
The launch of Ichi went great. We were selling thousands of units a day and those numbers were actually increasing the days after the launch. But than something went wrong. Suddenly the game would crash once it has launched. This had never happened in any of our tests before. Why did the game crash all of a sudden? It turned out that the firewall at our server provider, which hosted the user created levels, was malfunctioning. Since we had never encountered this before we weren’t prepared for this. As you can imagine we were pissed off, but the gamers were even more pissed off. The 1-star ratings were poring in, so we had to work quickly. Within a day we made a quick patch that made the game run again. We submitted it and Apple was kind enough to approve it in record time. But the harm was done. The sales momentum the game had was gone. Sales plummeted because of the bad reviews. Instead of getting thousands of sales at $4.99 a piece we were down to hundreds.
The lessons we learned from this is that you should be prepared for something you can’t predict or test. We expected our server to send just numbers to the game, instead it was sending lines of random code. For our next games we’re making sure that the game handles these rare cases the correct way. One day of extra development time is better than losing thousands of dollars in revenue.
Monetizing
At the end of 2012 only 300 people out of 400.000 bought the in app purchase, an insanely low percentage
We wanted to use in-app purchases in the game to earn some extra revenue post-launch. We were thinking of putting an in-app purchase on the level editor. So if you wanted to make your own levels you had to pay a dollar extra. But we opted against this because the editor would generate content for the game. Content is important so we couldn’t make the overall package weaker to earn some money. Instead we asked for an in-app purchase when the player played more than 10 user-created levels. We guessed that only 5% of the players might create a level and 70% would play user created levels. More people means more revenue. Unfortunately this tactic didn’t work.
We launched the game with 50 built-in levels and player could play 10 user created levels for free. At the end of 2012 only 300 people out of 400.000 bought the in app purchase, an insanely low percentage. Why did almost no-one buy the in app purchase? We think it’s because people were done with Ichi after playing 50 build in levels. Nobody is going to play 10.000 user created levels, let alone 100. Ichi’s retention wasn’t high enough.
Getting a lot of players, quickly
Instead of letting our game die we looked at “free app of the day” deals.
A few months after the release of Ichi sales were basically dead. We were making about $15 a day, which didn’t get us one step closer to world domination anytime soon. So we had to do something. Instead of letting our game die we looked at “free app of the day” deals. The first free app of the day deal we did was Free App A Day (FAAD). In one day Ichi was downloaded 130.000 times. We were blown away by this number. After this we contacted Amazon USA if they could feature us. They loved Ichi and featured it as their free app of the day. After that, Amazon Europe featured Ichi as well. AppEvent did the same, resulting in another 30.000 downloads from mostly the Netherlands
Ichi featured in the Amazon AppStore
Free app of the day promotions are great. Unfortunately it is unlikely that your app will become super popular once the promotion is over. We earned only $80 from the days after the FAADÂ promotion. But still it is better than nothing. One good tactic might be to get a lot of downloads using these promotions and then switch to a freemium model. You will have hundreds of thousands of players who will generate revenue though ads and/or in app purchases.
Critically, Ichi is a great success. We’ve gotten wonderful reviews and players seem to love the game. But commercially the game hasn’t done that well. We barely broke even on the development costs. Most of the revenue came from the Mac version, mainly due to the feature by Apple. iOS came in second, revenue-wise. The Android, PC and Linux versions didn’t make more than a few hundred dollars. Despite all of this we feel that Ichi was worth our time, it was great developing it and we delivered something we’re proud of.
Ichi is available in the Apple AppStore. Stolen Couch Games is also working on third game, Castaway Paradise. Check out the trailer here. Vote for Castaway Paradise on Greenlight and support Stolen Couch Games.Â
Stolen Couch Games will also be sharing more in-depth insights and numbers on Ichi during their indie-postmortem talk during the Casual Connect Europe conference in Hamburg, Germany.
 
 
 
