Indie Showcase: Critical Force Entertainment’s Critical Missions: SWAT (iOS, Android and Web)

main

Contributions Postmortem

Indie Showcase: Critical Force Entertainment’s Critical Missions: SWAT (iOS, Android and Web)

April 8, 2013 — by Martijn van Dijk

Critical Force Entertainment Ltd is a new game development studio founded in Kajaani, Finland. The studio created Critical Missions: SWAT, a first-person shooter available for iOS, Andriod (released under Studio OnMars) and playable on Kongregate. The company focuses on developing premium and free-to-play crossplatform games with a special focus on the Asian market. So far, the company is self-funded, but investors are welcome.

Veli-Pekka Piirainen is CEO and founder of Critical Force Entertainment Ltd. He is a former studio manager of Supercell North as well as a lecturer and head of Kajak Game Development Lab. Piirainen is also co-founder of NMP Games Ltd.

A student’s hobby project

In December 2011, I hired Igor Levochkin – one of the students at a school I taught at – as a programmer in my new startup company after following his work for the past two years. Igor and I would make games for the Apple AppStore, and we started making a prototype of a game called BomberBall. At the same time, Igor put his hobby game project in Kongregate. Early January 2012, Igor showed me that there were hundreds of players playing his hobby project game, but I didn’t pay much attention to it. I just thought it could be a good marketing channel for our iOS game.

However, at the end of January 2012, there were a couple of thousand players playing it and I started to get more interested in it. I gave Igor a Sony Xperia Play phone and told him to port the game to that device. Igor managed to have it up and running in a matter of days. Next, I told Igor to port the game to iOS; this was bit more difficult since he was not familiar with Mac and Xcode. After a week, the game was also running on iOS. Now I really started to see some potential in the game. Despite all this work on Igor’s project, we also continued to develop BomberBall because I wanted to have a good prototype for the GDC in San Francisco. I demonstrated both prototypes at the GDC and Igor’s project, Critical Strike Portable, gained more interest from the public. After that trip, we decided to concentrate fully on Critical Strike Portable.

Keeping up with high popularity

Igor started fulltime development on Critical Strike Portable by adding new weapons and features. I still worked part time at the university and couldn’t fully concentrate on the game development. I trusted Igor and also a team of Russian volunteers, who supported us in the growth of the user community as well as map creation. Another important task was to make a proper and more user friendly User Interface (UI) for the game. Unfortunately, Unity 3D’s tools for this job were pretty limited and we didn’t have any artist or UI specialist in our team to design a nice, good-looking and functional UI. So Igor made a “coder-style” UI with many different settings and options inspired by Counter Strike style menus. That UI was easy to use with a mouse, but for mobile phones with touch screens, we needed a different kind of UI.

The user interface of the mobile version.

Because I was inexperienced in game marketing, I hired Teemu Riikonen in April 2012 to lead the studio as well as take care of publishing and marketing of the game. Our next employee was Thanabodi Thongchat, a 2D artist from Thailand. She started designing backgrounds and UI graphics for the game in June 2012. Igor implemented more and more features to the game like new game modes, zombies, graphical effects, as well as fixing bugs. We released new versions on Kongregate weekly and got feedback from players on how to improve the game. At the end of June 2012, we had nearly 30,000 daily average users playing the web version of our game, but we were still growing.

We got over 1 million downloads in one month.

On June 26th, we released a free Android version of our game with exactly the same UI and almost the same features as the web version. Even though it was not so easy to use and the menu elements were pretty small on a phone screen, its popularity surprised us. We got over 1 million downloads in one month.
But the problem was that many players didn’t continue the game after their first try. Only hardcore players did so. We decided to create a totally different and simpler UI for mobile devices, because the current quality was not good enough for Apple’s AppStore to sell it as a premium game.

At the end of August 2012, two game development students, Olli Lahtinen and Aapo Lehikoinen, started their internship in my company. They started to build a totally new UI, added new controls for the iOS version of the game with a new NGUI toolkit we bought from the Unity Asset Store and started to design new maps for the game with Hammer editor. We also needed new character models, guns and animations for the iOS version. Modeling and animations were outsourced to freelancers in Thailand and our Thai artist was leading that work. Unfortunately, the quality was poor and delivery was very late. After that, all animations were outsourced to two Finnish startup game studios and for the modeling of guns, I hired another student.

A screenshot of the zombiemode of Critical Missions: SWAT. — A screenshot of the zombiemode in Critical Missions: SWAT.

Unfortunately, we had to remake all maps done with the Hammer editor (16 total), because our lawyer said we probably weren’t allowed to use that tool, since it’s licensing agreement is not clear enough. Our lawyer also recommended us to change the name of the game from Critical Strike Portable to something else, because that name reminds too much of Valve’s Counter Strike (Critical Missions: SWAT was born then). Our original plan was to release the iOS version in the end of September, but it was released in the end of November due to these difficulties. A new Android version was released just before Christmas, a Lite version in the beginning of January 2013 and the Mac version is in the review process as of this writing.

The iOS market is very competitive

At the end of the year, the amount of our players had increased dramatically. We had almost 200,000 daily players on the web and over 100,000 daily players on mobile devices, but all were playing our free versions. Monetizing with premium version seemed to be much more difficult than we thought it would be. The iOS market is very competitive and full of games, so getting visibility is very hard. We also had bad luck with a very important review, because the reviewer didn’t like our controls at all (many other not so significant reviewers did like them, however). Because of this, we didn’t start to get income fast but our server costs rose dramatically due to the massive amount of users. We also had some trouble with one specific server provider, who just calmly cut off the lines to our map server without any warning due to dramatically risen network traffic.

Looking back

Our biggest mistake was to save money in wrong places and get low quality from our international freelancers. We trusted our own artist’s capabilities to handle leading of the outsourcing, but she was too inexperienced for that. Of course, rates a quarter of the price compared to local studios were very attractive, but then the harsh reality revealed we had to do everything over again after that miserable trial period. It would have been wiser to use more professional outsourcing studios in the very beginning.

Our second mistake was not to solely focus on Critical Strike in the very beginning, but to also make the BomberBall prototype. Something else I would change was not to have a tighter management; everything went forward more or less without proper planning and scheduling. A fourth mistake was not to take a professional publisher to publish the premium iOS version. We thought it would be easy to self publish, because we had such great success with the free Android version, but we were wrong. A last mistake was not to pay enough attention to the server capacity, but that was more or less because of our inexperience with servers and also our idea to save money.

The team is currently working on a new game, called Critical Missions: Space. It has the same nostalgic fast paced FPS gaming experience as Critical Missions: SWAT, with the addition of space rangers, space pirates, laser guns, aliens, space themed maps and more.

Next to that, they keep adding more to Critical Missions: SWAT. They’ve scheduled new guns, characters and maps as well as unlockable content for the next update of their very popular shooter.

Contributions Postmortem

Post-mortem: Playlogic’s Fairytale Fights (PS3 & Xbox 260)

March 18, 2013 — by Bart Eijk

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." — “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.

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.

Contributions Postmortem

Post-Mortem: The Awesome Game Studio’s Wobble Bobble (iOS and Android)

March 12, 2013 — by Martijn van Dijk

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

Arcade-style — 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.

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.

Contributions Postmortem

Indie Showcase: Kjell ‘t Hoen’s Rick ‘O Shea (iOS & Android)

January 29, 2013 — by Mariia Lototska

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

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.

Contributions Game Development

Four game design essentials for developing mobile/tablet games for toddlers - by Ian Schreiber

January 24, 2013 — by Mariia Lototska

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? — 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.).

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.

Contributions Postmortem

Post-Mortem: Free Lunch Design’s Icy Tower 2 (iOS & Android)

January 15, 2013 — by Mariia Lototska

Located in Gothenburg, Swedens second largest city, Free Lunch Design employs a creative team that produces world class games for multiple platforms. The team has produced over 70 games for PC/Mac and iOS/Android so far; some of them have been downloaded millions of times. Free Lunch Design is looking to keep innovating and develop games that will knock your socks of, no matter what platform or genre. In this article we will focus on describing some major events in the development of Icy Tower 2.

One-man-army origins

A successful release of a Facebook version of Icy Tower in 2009 solidified the pursuit for B2C, and a name change to Free Lunch Design confirmed the decision.

Free Lunch Design was originally a one-man-army (consisting of Johan Peitz ) making retro-inspired PC games for free download. Out of the numerous games released, one of them stood head and shoulders above the rest: Icy Tower. Since its release in 2001, it became especially popular among young students around the world, in part due to the ease in which it could be installed on a school computer. The simple and fun game found a following and lived a life of its own for the remainder of the 00’s. Meanwhile, Johan Peitz joined forces with local game developers Muskedunder, to create advergames. Soon Muskedunder aimed to change focus from B2B to B2C, and to build on the previous success of Icy Tower became the obvious first step. A successful release of a Facebook version of Icy Tower in 2009 solidified the pursuit for B2C, and a name change to Free Lunch Design confirmed the decision.

Once mobile gaming became the next big thing, we knew the time for Icy Tower 2 had come. The game hit the app store in November of 2012, containing several exciting changes from the original to keep it fresh and suitable for handheld devices. The release was another success with 1 million downloads in 10 days, which led to the decision to bring the game to Android.

The Game Design Gauntlet

Game director Johan Peitz had the initial game design responsibility. This was during the early phase of the production, where the game had to have the “Icy Tower feeling”, something Johan has a unique sense for. Shortly after we completed a good version of the core game play, Johan had a son. This meant he was leaving us for more than a month in a critical stage of development: fine tuning the gameplay and evaluating new features. Luckily game designer Jimmy Öman jumped in to take over where Johan left off.

Johan’s short leave could have gone horribly wrong, but in the end just cost us a little bit of extra time. Actually, it led to a new way of working with game design proposals. Johan and Jimmy are game designers with different approaches and strengths. The key was not to let egos run the show, but to allow them to contribute mainly with their respective strengths. We went all in with this approach, involving the entire team in the game design. This made the differences between the designers play a proportionally small part and tapped into the full potential of each team member.

The way we involved the whole team was by letting all game design ideas run through a “gauntlet”. Every member of the team sat down in a “group design session” and it was the designer’s (or anyone else in the team with an idea) job to sell an idea for a problem solution, a feature or design change. It was everyone else’s job to try their hardest to shoot the idea down. If the designer could defend the idea in a convincing way, the idea passed the “gauntlet” and earned a slot in the next sprint. This went on for several weeks and really made a huge difference for the design quality, team morale and general fun factor of working on the project.

Be problem oriented and assign a moderator to pull the brake

Everyone was involved and felt they could bring up worries they had about the game in a constructive way. This was a new way to work with design for us, and even though it cost a lot of hours, we’ll be using “the gauntlet” again! One important thing to remember is to have some form of emergency brake, when the sheer joy of being creative is no longer relevant to solving your problems. Be problem oriented and assign a moderator to pull the brake.

Since its release on Android on December 18th, Icy Tower 2 has been downloaded over 500,000 times.

Good is not good enough

One lesson from our former B2B business model was that “good is good enough”. This had to be repeated as a mantra whenever our pride and ambition to deliver premium quality products was larger than what the budget allowed. At the end of the day we had to deliver what was paid for, not what we wanted to deliver in order to feel proud.

The game was good, but not quite good enough, when the budget was spent

Going from B2B to B2C, we had to re-program our minds in this area. Simply being “good enough” wouldn’t cut it, facing the cut-throat competition on the mobile platform. We had to raise the bar several times, which was an internal struggle. The uncomfortable truth was that the game was good, but not quite good enough, when the budget was spent. The budget for the project was set with the old “good is good enough” in mind, and we had to admit defeat when we realized the production would need to be extended several more weeks in order to get the game where it needed to be.

In retrospect this could be viewed as a failure to see the obvious, but the lesson is to understand that every start-up company has its growing pains. The discomfort it brings must not be seen as failure, but instead an opportunity to grow. We had in fact changed our business model completely and there are hard lessons every time you face a new area of expertise to master. This was one of them. Handling them successfully - albeit at a real cost - makes you grow. Growing is painful, so prepare to deal with it.

The complexities of being simple

You would think that having simple gameplay and having made several successful incarnations of that gameplay would make things easier. In some ways it is easier, since we have the experience and a proof of concept. In some ways it’s harder, since you work under the restrictions to not stray too far away from the original.

We knew there would be some fundamental changes to the game. The big one was controls. We wanted to design it for the handheld touch device and that meant getting rid of keyboard-like controls. This seemingly small change has effects that ripple throughout the product. It sets the bar for the speed of the game, the difficulty level of interactions, input frequency, etc. Getting it right took numerous iterations and only through hard work were we able to create controls that felt simple.

One other challenge was to add new and exciting features without changing the objective of the game. It has always been about getting as far up the tower as possible. Introducing mechanisms to acquire money - and things to spend the money on - diluted the simplicity of just beating your high score. We were obsessed with the thought of keeping the game objective true to the original. In the end we had to accept that the game could be played with different objectives for different players. Some want to complete stuns, others try to hoard money and yet other just want to have the highest score possible. You can’t tell someone how they should have fun, just let them play and figure it out themselves. We could do other things though: put in extra effort in the tutorial; adjust the timing in which we introduce new features and in overall presentation of the tower collapsing.

Personal growth

You don’t have to be a designer to propose an idea, just getting a design idea challenged from different points of views is healthy.

The biggest impact from a personal growth aspect was probably the way the game design gauntlet affected the team. Some team members stepped out of their ordinary role and got to shine elsewhere, either with an idea or throwing something wacky out there that triggered another person to formulate the “sane” version of the same idea. You don’t have to be a designer to propose an idea, just getting a design idea challenged from different points of views is healthy. It leads to constructive dialogues where people not only grow closer, but team members can have a lasting impression on your personal methodology in creative scenarios.

In retrospect

The development of Icy Tower 2 took longer than initially expected, but resulted in big value. It taught us how to act when losing key members, what it takes to raise the bar (quality-wise) and how to keep our heads in the game when assumed simplicity grew complex. Involving all team members in the design process gave us a fresh take on the creative process and we think that’s reflected in the game, which we feel successfully introduces new and fun ideas to a classic game.

Icy Tower 2 has recently been released on Google Play. Free Lunch Design will be sharing more in-depth insights on Icy Tower 2 during their indie-postmortem talk at the Casual Connect Europe conference in Hamburg, Germany.