main

ContributionsPostmortem

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

April 8, 2013 — by Martijn van Dijk

critical_missions_featured.jpg

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

Veli-Pekka Piirainen
Veli-Pekka Piirainen

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.
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.

ContributionsPostmortem

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

March 18, 2013 — by Bart Eijk

featured2.jpg

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.

ContributionsPostmortem

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

March 12, 2013 — by Martijn van Dijk

WobbleBobble.jpg

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.

Wobble-Bobble
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.

ContributionsPostmortem

Indie Showcase: Arges System’s Hairy Tales (iOS, PC, Mac)

February 14, 2013 — by Martijn van Dijk

featured-hairy-tales.jpg

Arges Systems is a micro-studio doing game consulting and application development in Unity – their specialty is on game logic and AI. Arges Systems has been partnering with companies specializing in 3D graphics and visual design, as well as doing contracting for companies building games with Unity. In this article, Ricardo J. Méndez (founder of Arges Systems) shares some insights on their just-released Hairy Tales.

I initially founded Arges Systems to take advantage of my experience running remote teams and projects. We had been doing contracting on various game projects for a couple of years before I decided to switch gears and start working on our own stuff. I had just decided to pull the plug on a turn-based strategy game for which I realized the scope was too ambitious and was chatting with Yuriy Mazurkin, our concept artist, about possible themes for a follow up game. The conversation drifted to Russian illustrators – somehow we ended up talking about Ivan Bilibin and it got me thinking about action/adventure games.

A sword-wielding octogenarian

A sword-wielding octogenarian riding a warhorse charges forward from a hill. Nordic forests and evergreen trees spread before him. He’s also butt-naked.

It was a simple, straightforward picture by Russian illustrator Ivan Bilibin, from his Marya Morevna series, and my first encounter with Koschei the Deathless. He’s an archetypal antagonist of Slavic folklore, an even more evil version of their better-known Baba Yaga.

I took one look at it and with its combination of adventure and absurd, I thought “damn, this would make for an excellent slavic Zelda-like game”.

You can’t get there… from here

I wanted to do a game that was different, and this wasn’t it.

I experimented with gameplay styles while Yuriy drafted some concepts. We drafted several ideas for scenarios, including a story, but it quickly became apparent I had nothing new to say about the adventure genre. I wanted to do a game that was different, and this wasn’t it.

Partly as a way to cleanse our creative palate, I started experimenting with mixing puzzles in. You had to maneuver the main character through a corrupted land, frozen in time, but elements got un-frozen as you approach them. This had pros and cons, since you could activate machinery just by being near it, but enemies also came alive. The puzzle aspect was to figure out what to do when. I decided to discard this version as well. It seemed like a one-trick pony, with the sort of read-the-designer’s-mind approach that I hate, and lacked replayability – once you know the solution, that’s it. Also, the game was taking on a somewhat stoic tone that I felt dragged it down.

You will notice I haven’t mentioned anything about the modeling side of things. We had overenthusiastically already started modeling before I was done with the design, because I wanted to get the time-consuming assets out of the way – or at least properly estimated. Despite it being a bad strategic decision, it had a positive side effect: it made me realize early on that the 3D artist we were working with just wouldn’t cut it. The quality of his work had been in decline, he wasn’t paying attention to details, and both Yuriy and I kept having to bounce work back to him with notes. Eventually I had to let him go and start looking for a new hire. Fortunately we found Ash Barnard, from the UK, who meshed with the team perfectly. He has an eye for detail, very expressive animations and more importantly, just the right sense of humor to make the Hairy Tales animations memorable and peculiar. Ash also brought in a good eye for gameplay, and helped criticize mechanics as I was coming up with them.

Through several experiments and iterations, I ended up landing on something close to the current approach. The first few iterations were fixed stages, based around arrows that directed them and fences that made them turn two sides to the right. It also featured a first draft of the spreading corruption, with the twist that if it spread to a tile with a fence, then it got corrupted and the fence turned into a deadly wall of flame. I can hear the thought gears as you try to figure it out. Playtesters weren’t getting it, and even when they figured out stages the reaction often was “I know this is how it’s supposed to be, but don’t know why”.
That would not do.

Concept art for Hairy Tales

Dragging it there

I started paring down the elements. At this point we’ve been in a production iteration limbo for months, and all the associated hair pulling is starting to take its toll on me. Everything is self-funded, so Arges is hemorrhaging cash while we experiment, and my focus is split between the game and the client work that is funding the process. I started trying different games to relax – mostly playing demos, so I didn’t get too involved and lost track of the project. One day I was playing a demo of Atlus’ Catherine, moving Vincent around, pulling and pushing blocks into place, and then a light bulb went on. After simplifying the elements, the stages had felt too straightforward, and the new levels depended mostly on size for their complexity. What if players could drag tiles from one place to another?

I didn’t tell the team, just sent them a build where some later stages required them to move tiles. They were rather surprised at first, but immediately saw the possibilities, like tiles that drag Hairys from one place to another, weapons you can re-use or teleporters. So finally, after months of iterations, we had a design we were happy with.

The 90-90 rule

It took a lot to get from a game’s design to the final product, of course. We still had to design the look for the various tile elements as we were going, which kept Yuriy involved while Ash created the models and I both coded the behavior and came up with the stages. Yuriy was also helping with the texturing. His true love is painterly work, however, so he came to me when we were about to enter the final stretch and brought up that he wanted to move on.

As sad as this made me, since I enjoyed working with him, I helped coach him for interviews and gave him a sterling recommendation. He ended up getting employed by Yager in Berlin, who recently published Spec Ops: The Line, and I expect is right now working on their next project.

At about this time I brought on board composer Levan Iordanishvili as a contractor to work on the game’s music. He liked the game and offered to take care of the sound effects as well. To ensure both were cut from the same cloth – he did a smashing job of re-creating the sound that Ash’s animations made in your head when you looked at them, and his scoring of the three worlds and bosses was top notch.

One of the levels in Hairy Tales

Calling it

I had initially planned to release with five worlds and five bosses worth of content, for a total of 75 levels (15 per world). Playtesting had demonstrated that players needed a gentler level progression than the breakneck pace we initially had, so each world had increased to 24 stages. If we kept the same number of stages per world, we were looking at 120 stages total, plus the extra time it would take for the two other bosses and possibly new enemies to keep things lively. The scope was getting out of hand.

I made a judgment call. We would be launching with 72 levels and three bosses, using some minor characters as mini-bosses. Once we saw the initial reactions to these levels from our players, we could release a couple more worlds as add-ons and expand on those qualities that players enjoyed the most. The team agreed, and we geared up for polishing the worlds we had fully designed.

The initial stage sequence introduced one concept after another, presenting a more concentrated experience which gave the player little respite, with no stages that they could use to experiment with the mechanics they had just learned before throwing a new set of concepts at them.  After various rounds of playtesting, I introduced some intermediate levels that presented the concepts they’d just learned in different contexts, so that they could play around a bit more, which made the initial learning process smoother.  However, it also led to the initial stage sequence feeling a bit drawn out, so I then had to adjust the sequence once again. This process went on over several iterations, even after we had released.

ContributionsPostmortem

Indie Showcase: RedBallStudio’s Red Ball 4 (Flash)

February 4, 2013 — by Mariia Lototska

red_ball4-featured.jpg

RedBallStudio is a one-man studio based in Saratov, Russia. Founded in 2009 by Eugene Fedoseev, the studio publishes Flash and iOS physics platformers about their main character – Red Ball. There are seven games about Red Ball in the studio’s portfolio, but Fedoseev continues to publish more Red Ball games in the future.

From selling concrete mixers to game development

Fedoseev
Eugene Fedoseev

My educational background is in programming, but after I finished university I worked as sales clerk selling concrete mixers. I wasn’t interested in programming at that time – it seemed a little boring to me. One day at the end of 2008, while I was at work, a friend sent me a link to a blog. On this blog a guy shared his experience of how he earned money making flash games. I was really surprised because I thought making games was very difficult and could only be achieved with a big team. I’ve read the entire blog that day and after work I went to a bookshop and bought a book about ActionScript 3.0. It took me two weeks to read the book and I started making games while at work and at home afterwards. My first two simple puzzle games were Fastone Pyramid and Rain Drop.

I gained a lot of experience in game development, working with Action Script 3 and communicating with sponsors, but not a lot of money. I realized I really enjoyed creating games, but I could not afford to quit my daytime job.

While reading lots of different tutorials on the internet I found a tutorial on Platform game basics using Box2D. It allowed the player to control a red box and let it interact with physics in the game world. I got very excited and started playing with it. I added different objects and obstacles, unlocked box rotation and finally found out that the box’s body is difficult to control. To fix this I decided to change the box to a ball, thus creating Red Ball in the spring of 2009. Initially I created seventeen levels and added different objects, platforms and flags. I drew the graphics myself, my wife found a great musical soundtrack and after 3 months we released the game. After a while I got a really good offer from King.com and decided to quit my job to become an indie flash developer. Since then I’m working at home, full-time. The past four years I’ve created different games about Red Ball on different platforms (Flash and iOS). I created Red Ball 2, Red Ball 3 and finally Red Ball 4 at the end of the last year. Next to that I’ve created the Red & Blue Balls series (three chapters) where you control two balls – switching between them. With every game I aim to improve the quality by hiring art designers, add story animation instead of comics and improve the user interface. I couldn’t say it better myself then what JayIsGames.com wrote about the Red Ball series progress.

Finding inspiration

The main focus in my games is game- and leveldesign. The seven Red Ball games count a total of over 100 levels. My inspiration for these levels came from some great games I played on the internet. For example, the buttons and levers in Red Ball 3 are inspired by Fireboy and Watergirl. Another game, Lee-Lee’s Quest 2 inspired multiple aspects of Red Ball 4. I really like the popular iPhone game Doodle Jump which is why I wanted to add a parody-level in Red Ball 3. The gears in Red Ball 4 are something I added after spending quite some time on a physics learning tool called Algodoo.

Other things in my life inspire me as well. On a vacation to Egypt I visited the pyramids (as seen in Red Ball 3) and I came up with the helicopter level after I was given a RC helicopter for my birthday. Wikipedia articles about different mechanisms also always inspire me to create new things.

Level design

Each level in the series goes through three different stages of development. First I draw some level challenges with a pencil and sketchbook. This part of the process takes about 50% of the time. The fun part about this stage in development is that I can do this wherever I want. Sometimes I work at a café, the beach or while traveling.

Sketches
Initial sketches for mechanics

After that I combine different challenges into one level and sketch a background layer in Flash. Then I outline my sketch with simple primitives and create the level’s physics. This stage requires a lot of gameplay testing to see if challenges need to be changed. For example, a gap could be too big to jump over or some challenges could be very hard to pass.

Combining sketches in Flash
Combining sketches in Flash

This level is playable but it still needs some nice aesthetics. For this last stage in development I send these levels to my artist.

The benefits of working with sequels

Twelve times more profit

I’m really happy to be able to create games, it gives me both satisfaction and financial profit. The last four years I’ve created seven games about Red Ball and I’m not planning to quit anytime soon. The benefit of making sequels is that both players and sponsors know your games and want to play / buy them. Over time you create a fan base that follows your projects. For example; Red Ball 3 has doubled the results of Red Ball 2 when it was played 60 million times in the first year after launch. Sponsors also know what to expect from your games. As a result you get more profit. For example; I got twelve times more profit from Red Ball 4 then from the initial Red Ball.

Another benefit of working with sequels is that you can save a lot of time and increase your production efficiency when you don’t have to create game from the beginning. You can simply add new levels to your game engine. That’s how I’m currently working on developing Volume 2 of Red Ball 4. It will be the same red ball character with the same physics, but I’m adding fifteen new levels.

ContributionsPostmortem

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

January 29, 2013 — by Mariia Lototska

featured3.jpg

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.

ContributionsPostmortem

The Global Game Jam and beyond: Catch-22 (2012)

January 25, 2013 — by Mariia Lototska

featured-catch-22.jpg

The Global Game Jam and beyond series sheds light on the few brave Global Game Jam (GGJ) teams that have decided to take their GGJ projects to the next level and continue development after those challenging 48 hours. We ask each team to tell about their experiences, share learned lessons and offer advise on their attempt to turn their Global Game Jam project into a full fledged commercial product.

Last year’s edition of the Global Game Jam saw its biggest entry of games yet. Combined with the rather obscure theme of Ouroboros, the ancient symbol of a serpent or dragon eating its own tail.

Based on the Oroborus theme for the GGJ2012 the team behind the quirky one-button arcade game Catch-22 wanted to make a game in which your actions bite yourself in the ass. This resulted in them not only winning the local competition at their jam site, but later also won a prize for being the best Dutch Global Game Jam game. Catch-22 also later became one of the PAX 10 selected indie projects to be showcased at the PAX Prime event in Seattle back in August 2012.

Catch-22 has been in development for iOS ever since.

ContributionsGame Development

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

January 24, 2013 — by Mariia Lototska

ian-with-janis-600x242.jpg

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 Docter HDToca 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 CountingToddler 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 SoundsI 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
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.

Play PhoneOnce 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.

ContributionsPostmortem

Indie Showcase: Ticklebot’s Super Sub Hero (Flash)

January 23, 2013 — by Mariia Lototska

Post-mortem-Ticklebot-splash.jpg

Ticklebot is a tiny independent game studio, located in Serbia. The idea for Ticklebot formed soon after the meeting of its only two members, Stefan and Milica, and came to life in the spring of 2012. The name “Ticklebot” is derived from the founder’s true nature, as Stefan is a real human resembling robot and Milica is sort of a tickling maniac. This article is on their soon-to-be-published game Super Sub Hero.

Super Sub Hero is a puzzle platformer with an unusual kind of mechanics, a wintery atmosphere and a laid-back feel to it. What we started with, six month before its release, was a funny little ballet dancer hopping around and doing silly jumps. We wanted to make a game that would make players smile and relax while using their brains as well.

Video Coverage

Astralax’s Alexey Sedov on developing out of curiosity, being an programmer in the Soviet era and flying completely solo as an indie

January 17, 2013 — by Gamesauce Staff

featured.jpg

“The company only has one person, so you’re actually talking to the whole company”, Alexey Sedov from Astralax mentioned when he was asked about the size of his enterprise. Mr. Sedov from the Russian federal republic of Tatarstan has been programming for more than 20 years and is mostly known for developing Magic Particles, the special effects creation tool available both for game professionals and photo/video editors.

First project, bitter experience: the game that brought disappointment with publishers.

You cannot control sales.

Alexey’s first project, a real-time strategy game named Onimod Land, was released in 2005 with his programming and friends’ artwork. Nevertheless, this product was commercially unsuccessful. Sedov recalls that, back in 1998 when they started the project, publishers in Russia were demanding highest quality products they couldn’t even sell – in fact they had nowhere to do it. People wouldn’t buy games for their real prices, and the great deal of the market was about pirate content. What is more – one could only work with publishers totally sticking to their demands. The common scheme was that the publisher pays $10,000 in advance for a fully developed game, and promises about 25% royalty, while the latter was not necessarily paid. “You cannot control sales. There will be sold as many as they tell you. Without any doubt they all do accounting fraud”, Sedov explains. He says that the decision to work with a publisher in Moscow driven by being young and hopeful ended up in disappointment – the developer and his team understood the deal is initially an unfair one, and split up very soon. Alexey Sedov decided to finish everything himself and distribute the game for free. “And just as I started giving the game away, all those publishers appeared offering me to sell the product through them. I actually said no to all of those, since I found all their offers humiliating”.

A screenshot of Alexey's game Onimod
A screenshot of Alexey’s game Onimod

Because of just one person working on all, the game took ages to complete and, according to Alexey, is unlikely to impress people now due to drastic changes in both hardware and game graphics. “I came up with understanding that you either make games fast or don’t make them at all”, he concludes. And adds that if one day he becomes so rich that wouldn’t know what to do with money, he would consider re-making the game, but as of now it’s a dead project. The product is available through Astralax.com and various freeware sites by the “Onimod Land” search query.

No start-up capital? Better to work on your own

When he tried working with a small team of friends, Alexey Sedov understood that developing projects with no start-up capital might be too harsh for someone who is not as dedicated as he is, especially when they’re working on someone else’s idea. As a result, he decided to do everything on his own.

“These are current rules the world plays to – pretty much anything depends on whether a person has money or not. I hope it will come to an end sooner or later. But for now, you either have everything or work for someone”, says Sedov.

Sedov has chosen the riskiest path of any game professional: only doing what he likes. He already was able to make some money with the creation of Magic Particles, but a few years had to pass before the product caught on enough to sustain him. Sedov credits his own dedication and interest to have kept him going on all this time.

Though Alexey Sedov is known for the software he made from scratch, he doesn’t have a university degree in programming. “I graduated from University, but I’m no programmer, I’m a chemist”, – he reveals. In his senior year at college he was able to get a job that can now be called “network engineer” to serve hardware in healthcare industry.

How to assemble a computer from radio parts
Back then in Soviet times, computers were rare. Only big organizations could afford them. Amateurs and hobbyists were figuring out how to make their own by assembling their machines out of radio details bought separately.

Sedov’s very first encounter with a computer happened at the age of 12. “It was a BK-0010, it had 4 colors and a tape machine – there were no disc drives then. It had a crazy price of 650 rubles – while the average monthly salary of an engineer was 120. No wonder nobody had those computers at home. There were gaming salons where you could play for a ruble per hour”, he recalls.

Programming ended up eating most of Sedov’s time even during college studies. “I was only using Assembler, basically a machine code, but quite understandable for a human. I spent almost all spare time on learning programming as chemistry was gradually disappearing from my life.”

Programming enthusiasts in Russia didn’t have a big choice of information sources, they mostly got coding instructions from rare articles in technical magazines. Sedov would find pages with those tables full of directions on how to program and learn how to use Assembler. He still keeps the cutouts at his place.

A fragment of an ancient cutout with assembler code
A fragment of an ancient cutout with assembler code

Sedov left his first job in 1998 because of the crisis when the Russian ruble drastically collapsed. “I pulled my savings out of the bank on the last day – on the following one they didn’t give money back. And these were the funds I used for my first project of the game. Simply speaking, I was guzzling it away”.

The developer’s first notable project has been the Onimod Land game, but it was Magic Particles that came later and made him known.

“In my case, it is one person who makes and sells it, and technical support is also on me. Magic Particles is completely my own personal creation.”

Things are difficult before they are easy

I’m sure, nobody should do it like I did

Curiosity has been the initial reason to start Magic Particles – Sedov just wanted to experience how special effects are created. He says that in the beginning had no idea about how it’s done. “I decided to try just for myself and create a small special effects editor and a library for it. Later I thought I won’t manage it, the editor had too many capabilities and the library was unlikely to be used for real-time calculations in games.”
Thanks to internet mates’ encouragement, he didn’t stop on that. First users came rather soon, though it took up to two years to gain the first paying client.

“I started developing a graphic editor without a library. Then it happened so, that I showed it at the gamedev.ru website, and everyone started telling me to make a library. And I was like – guys, the calculations are too complicated, it won’t work fast enough. They said – no it will, just make it. And in 4 month I split the thing and made both – an editor and a library”.

Since then things went up for Astralax. Sedov explains that nobody wants to be the first one to use some software in a serious project since everyone is interested in experience of the others. It always takes some time before people start paying for software.

Magic Particles 3D
Magic Particles is now available as 2D and 3D versions, and also as a free one for non-commercial projects.

The technology was eventually picked up by game developers, and several known titles have been made with it. Among those are Dark Strokes: Sins of the Fathers and Treasures of Montezuma 3 by Alawar, Jewel Legends: Tree of Life by Cerasus Media, Garden Rescue from RainbowGames and Vampire Saga: Break Out from Go!Games.

According to Sedov, success has no recipe and is a truly individual thing. However, he did have some advice to share. “If I ever become a millionaire, and people will ask me about how to make money, I’ll say – guys, don’t act like me. It’s for sure, no one should do like me, hardly anyone would be able to stay without a salary for half a year while life keeps dictating its conditions”.

Sedov is currently working on the next version of Magic Particles, and as usual it takes him quite a lot of time to make it just the way he sees it. “My aim is to get to the modern 3D games market. Special effects for those are made in a way different from casual ones, for which I think I have everything”, – he shares. These new features will not only bring him to a new level of the 3D market, but are also likely to enhance the existing 2D features.

logo
SUPPORTED BY