main

ContributionsDevelopmentGame DevelopmentIndieOnlinePostmortem

The Eschalon Trilogy: Surviving in a Niche Market

March 24, 2014 — by Mariia Lototska

feature15.jpg

Located in the US, Basilisk Games is an independent game developer with the mission to produce old-school computer RPGs. They have been working on the Eschalon trilogy since 2005, and released the last chapter in February 2014. Thomas Riegsecker, owner of Basilisk Games and Lead Developer of the Eschalon Trilogy, shares the story.


A Dream Project

Way back in 2005, I decided to take my notes from years of developing role-playing game ideas and turn them into a computer game. Originally called Under a Riven Sky, the game was going to be a trilogy based on secret societies, the end of the world, and an enigmatic race of creatures so advanced as to appear to be alien to the player. The game would feature pen-and-paper-like game mechanics, an open world, and a genuinely unique turn-based combat and movement system. Before I knew it, I was living off my savings account and working full-time on the game that would eventually be renamed Eschalon: Book 1.

book1
Before I knew it, I was living off my savings account and working full-time on the game that would eventually be renamed Eschalon: Book 1.

Encouraged by an ever-growing fan base who had seen screenshots and read about the game mechanics, I worked night and day for two years to complete the first game of the trilogy. In November 2007, I released the game to the world and was genuinely surprised by the response. The game earned back my full investment in three months and made enough in six months to fund the second game in the series. Not to mention, I was officially a successful indie game developer. Working from home, earning a solid paycheck, and making games was a dream come true.

2007: A Very Different World for Indie Games

When Book 1 launched in 2007, the gaming scene was very different than it is now. There were no tablets or smartphones back then. Computer displays were predominately 4:3 CRTs, and even the few LCDs that were available were not widescreen formatted. Indie gaming was in its infancy and the market was uncluttered. Eschalon: Book 1 was right at home in this market, and it sold very well to gamers who were tired of the path that mainstream RPGs had taken over the previous decade.

eb2_screen_072590b
By 2010, things had changed dramatically.

However, between 2007 and the launch of Book 2 in 2010, things changed dramatically. Many people had dropped their old CRT monitors in favor of a 16:9 wide-screen LCDs, yet others still clung to their old, beloved square CRT displays. This was a problem because the Eschalon game engine (which I was committed to reusing for all three games) used a fixed resolution with bitmap sprites. It was not particularly flexible and trying to make the game look good on these different displays was difficult. Although I did increase the native engine resolution up to 1024×768, I did not adjust it to a 16:9 format which was probably my single biggest mistake at that time of Book 2‘s development.

A Crowded Marketplace

The most dramatic change between 2007 and 2010 was that indie gaming had exploded during this time. When Book 1 launched, we had all the media coverage we could want. The game was featured in mainstream gaming magazines and websites, and not a week went by that I wasn’t asked to give an interview or write an article about the development of the game. But by Book 2‘s launch in 2010, we were just another indie game among hundreds, and our fixed resolution engine no longer looked as good to gamers who were accustomed to seeing high-resolution 3D graphics. I had to work much harder at promoting the second game, which ate into the first year of my development time on Book 3.

book3_game_cover
I had to work much harder at promoting the second game, which ate into the first year of my development time on Book 3.

Of course, by the time Book 3 launched in February 2014, the indie game scene had become an out-of-control monster. The market is now over-saturated, with dozens of indie games coming out weekly. This has driven the sale price of indie games to an all-time low, and even then, many customers will wait for the 50 percent discount that they can expect over the summer and holiday sale drives. It seems that as the indie scene grows more popular with the mainstream gamer, “niche genre” games are pushed further out of the spotlight for games that feature tried and true, familiar elements. And remember that mistake I had made in not converting Book 2‘s engine into widescreen format back in 2010? In 2014, many gamers refused to even try Book 3, citing the lack of widescreen support to be too jarring to be able to enjoy the game.

Reflecting Back and Looking Forward

intro1_male
It seems “niche genre” games are pushed further out of the spotlight for games that feature tried and true, familiar elements.

If I am honest about what has made Eschalon a minor success, it’s because it is a game series that caters to a very narrow spectrum of gamers. Many of our customers are over 30 and grew up on pre-Diablo style role-playing games, and they are looking for a very specific type of gaming experience now. These are the customers I focus on because if I tried to appeal to the mainstream gamer mass, I would be neglecting the customers who have supported Basilisk Games from the start. It’s a challenging path to follow, and more than once I drew the ire of Eschalon fans for trying to add a feature that I hoped might draw in new customers. Catering to this niche market has limited the game’s appeal to the general gaming audience, though it is the very reason for Eschalon‘s successes as well as its failures.

BG 2013 Logo
From the earliest design phase in 2005 to the release of Book 3 in 2014, it has been a long and difficult road marked with many highs and lows.

It’s hard to believe that I’ve spent nearly nine years working on Eschalon. From the earliest design phase in 2005 to the release of Book 3 in 2014, it has been a long and difficult road marked with many highs and lows. I’ve been asked by many people, “Was it worth it?” I assume that people want to know if the money I’ve made from the games justified the ridiculous, unhealthy number of hours I worked to develop them. I can’t really answer that right now – not until I’ve had a chance to decompress from this final game development cycle. Although, I will give some advice to other indie developers: do not let a large project take over your life. It’s very easy to find yourself working day and night, weekends and holidays, all towards the dream that your game will be loved by all and will sell a million copies in six months. That kind of success is extremely rare and the mental burnout that you experience from such an extended, crushing workload can have long-lasting, negative effects.

Our fans are already asking us what is next for Basilisk Games, and the truth is that the future is more clouded than ever. Everything depends on how well Book 3 sells in the next six months because this will determine the budget of the next game. One thing is for sure: Eschalon is done. There will not be another Eschalon game, and the Eschalon engine will not be used again. Beyond this absolute truth, I am honestly just as as curious as our fans are to discover what is next for Basilisk Games!

The Eschalon Trilogy is available on Steam, GoG.com, Mac App Store, and on their website. Stay up to date with Basilisk Games by following them on Facebook and Twitter.

 

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: Dream Symphony (Flash)

March 4, 2013 — by Martijn van Dijk

Dream-Symphony.jpg

George Zarkua is an indie game developer with four years of experience. He is the artist and game designer of Nude Hunter, Ragdoll Ball, Dream Symphony, and Spicy Story. He recently started his own studio, called Zarkua Studio.

A Vague Start

George Zarkua
George Zarkua

When the idea of this game appeared in my head, I had already done four projects in a rush mode. I enjoyed making games quickly, not only because it really saved valuable time, but also because this way the projects didn’t last long enough to bore me. The main idea for my new game was a bit blurry and existed only as an idea. The only clear thing was the concept, so I took it as a constant foundation that has been preserved from the beginning to the end of the development process.

I use tricks to escape the routine

When developing a game I try not to work in the same pattern over and over. I use tricks to escape the routine. On Dream Symphony, I tried to leave my comfort zone and tread into an area I had no experience with – music.

Despite the fact that indie games are mostly made without reliance on colorful graphics and effects, music always substantiates or even creates the atmosphere in those games.
Among flash games, there are outstanding representatives of the music games genre that are all based on the mechanics where static objects in the scene (such as obstacles or changes in the landscape) occur after the composition reaches a certain time or a certain pitch (Music in Motion and Take a Walk).

I wanted to create a musical flash game, but with rather unusual mechanics. The idea was simple: apart from the normal sound in the game, there were more sounds that were played in the interaction with surrounding objects. I.e. no objects were created depending on the music, but music was created by the objects.

The idea was very vague, and I could not explain what I wanted. So when I offered it to my partner programmers; four out of four said no. I created a thread in a forum, without a precise description of the concept. Before my idea gained any reputation, I got several messages from programmers who offered different kinds of partnership. There were about eight people and to each of them I described the idea. All of them were willing to work on the project., I couldn’t assess their levels, but one of them wrote GDD and showed his previous game with the mechanics of a platformer. This made for an easy choice. I chose Igor Kulakov. The last problem was me. I was tired after two years of working, so we agreed to start the game over time and I left for some relaxations.

At that time, I didn’t think that after the release of the game it would be featured on Newgrounds, Kongregate, NotDoppler, Bored, that we would win three cash prizes, including best game of Maypleyard, that I would read news about my game on leading indie news sites, including JayIsGames and that I would write this postmortem.

Character progress
Character progress

Before leaving, I made a couple of sketches of the main character (a huge goof pumped in a tracksuit, which jumped from cloud to cloud, and bursting bubbles with music) and a couple of backgrounds. It was cute, but not particularly interesting.

It was in a village deep in the heart of Russia where I decided to change the setting of the game. Originally, I had planned to make a quick jumper, with an active music. There I met a creature that changed my view of the future development of the plot. It was a sheep. I really wanted to see it in the game. I had only a pen and a notebook so all that I could do was make a few sketches. The body of the sheep looked like a cloud. In my head I animated the sheep slipping and awakening when you jump on it. This helped me to revive the game. However, the game still was in the same state, without any fundamental differences comparing to the flash jumper games, so I decided to add one more feature. The idea was that at the very beginning of the game the level was grey and while ascending in height, the game gradually became colored. This idea has also formed the basis for further work.

When I got home, the first thing to do for me was beating similar games. Meanwhile, my partner had created a working prototype. It was a very important step. After that, we coordinated our work through Dropbox and thanks to his prototype, we could work separately. He worked evenings and I started my work in the mornings.

Rush Mode

You just need to turn off the internet. Switch it off. You will reach zen

We worked in a rush mode, so the development of the game was enjoyable. Rush mode is the apotheosis of self-discipline, self-control and determination. In the morning, after you get up, cook all the necessary food for the day. Work should ideally take about 10-15 hours a day plus three hours for breaks. You should consider disabling all things that can give a signal. The most important discovery that I made for myself and increased my productivity 5-6 times is that you just need to turn off the internet. Switch it off. You will reach zen. The first time I came across this, lightning hit the transformer vault in my house. That day, I finished a big to-do list for the entire week and even cleaned the room, paid the bills and went for a walk. The second time, I fully encoded and made all the graphics to the simple little match-3 game, which I later sold it for 4k.

You must be completely off-line. And if suddenly you need the internet write down what you need on a piece of paper. In the evening spend an hour online and go to bed cheerfully. Of course, working like this for a long time might not be healthy, but you should try it.

Working on the Sound

The effect created a sense of passage and epicness

We needed a specific type of music with a perfect tempo and a certain feel to it. We hired a professional musician who had to rewrite the main track a few times because it didn’t quite fit the gameplay. When objects exploded, the sounds did not fit with the overall tone of the music. In addition, the levels in the game seamlessly switched, and the track for the next level was a copy of the previous one with the addition of one more instrument. This effect, coupled with the effect of saturation rising, created a sense of passage and epicness. By the end of the level, you could see a completely colored game, with a soundtrack that also felt complete.

The sheep in Dream Symphony
The sheep in Dream Symphony

When all the music was ready, it had to fit the levels. Connected tracks should feel solid. As an artist of this project, I needed a simple program for sound processing. I was looking for a free, easy program with minimum functionality and intuitive function names. I only needed to be able to change the tempo, the pitch, and the volume. By changing these aspects, the music comes to the foreground, and the sound echoed in the background.

The most important part was yet to come. We had to place the sounds in a way that the track seemed to be solid. To do this, sounds had to fit into the gameplay music. The player should feel that he was involved in the creation of music. It should not distract the player from the process. So some sounds had to be neutral and others had to be more in tune with the rest of the audio. The musical instruments only appeared in intervals where there was a deliberate pause. Needless to say, because of these actions the game was really hard to balance. In the end, the balancing of the game took about 30% of the work.

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

Indie Showcase: Olologames’ Wake Up the Box 4 (Flash)

January 28, 2013 — by Mariia Lototska

featured2.jpg

It all started in the end of 2009 with three guys: me (Eugene Karateav) as the flash-developer; php-programmer Pavel Kostyuk ; and artist Alexey Egoshin. We decided to create our own website with flash games. In a couple of months we created the website’s engine, design, added several games, et cetera. In short: we made yet another websites full of flash games. With our website up and running, we needed a new flash game to promote our site, which would be Wake Up the Box 1. The game’s idea was born after my endless experiments with the physics engine Box2D. We developed the game in less than a month and released Wake Up The Box 1 in November 2009. It was surprisingly popular. In its high days, it attracted over 150.000 visitors. It was clear that we had to create a sequel. So, we created Wake Up The Box 2 and 3. After that, I decided there were enough games in the WUTB-serie and started doing my own thing: experimenting with the physics engine itself.

I would play for hours, just drawing objects

I continued creating new mechanics and one day I realized it was a lot of fun drawing shapes that behaved in accordance with the laws of physics after their creation (similar to Crayon Physics Deluxe). I would play for hours, just drawing objects. It was fun to see how they became rigid after drawing, how they fell under gravity, how they collided and bounced into each other. I decided to create a game based on this mechanics, which led to the first prototype. In small indie games the main and most important part is an interesting gameplay. Characters, story, art, etc. are secondary. So, after the prototype was done, I decided it was time to think about the world around the core mechanics. After some thinking I settled on the good old idea of waking up boxes. So, that’s how Wake Up the Box 4 was born.

A screenshot of Wake Up The Box 4

Lessons learned

Development’s iterations using prototypes – Iterative development is very important when creating a game with an original gameplay. Our game’s idea is pretty simple: a player draws an outline, which becomes a physical object after creation. These objects are used to wake up the box in each level. I went through 10 iterations to make the drawing process as easy and user friendly as possible. The process went as follows:

  1. Make a prototype.
  2. Show the prototype to different people.
  3. Watch the players play the prototype, pay attention to their reactions (pleasure, frustration, etc.).
  4. Make changes to avoid the frustrating moments.
  5. Go to step 2.
Sometimes a player tried to create a circle dozens of times and had no luck. In other cases they tried to make a rectangle but got a circle.
Sometimes a player tried to create a circle dozens of times and had no luck. In other cases they tried to make a rectangle but got a circle.

There are a couple of advantages to using prototypes. For example, in our game we have some predefined areas where a user can draw objects. The drawing process is allowed only inside those areas. Therefore, even if you move the mouse outside the drawing zones, the mouse pointer stays inside. You don’t have to worry about drawing carefully inside the areas. In our first prototypes the situation was different. A player could get out of the area’s bounds and that meant that the drawing couldn’t be completed. It was very frustrating for the players to try hard to stay inside the zones. And, of course, getting out of the drawing area caused outbursts of anger. We solved this problem by not letting a player get out of the drawing areas. A player’s outline is stuck to the area’s bounds.

Second, we learned about the difficulties creating circles. In the earlier versions of the game one had to draw an outline similar to a circle to get a round object. But it was a tough task for a player to do. So, in the next version I made the process of drawing circles a separate tool.

If you want to reach a wide audience, you should playtest using a wide audience

Test everywhere – If you want to reach a wide audience, you should playtest using a wide audience. Test it on your friends, colleagues, and relatives. A wide audience helps to get a lot of views at your game from many different perspectives. For example, I use a high quality wireless mouse and it’s easy for me to draw. But one day I was at my friend’s house and tried to play Wake Up the Box 4 with his mouse. It was really painful trying to create objects with that mouse. But this situation helped me to realize that players have different computer mice, and it forced me to make some changes in the level design.

Refactoring – When you work as an indie, you have a lot of ideas coming up in the development process. You constantly add, remove, modify and upgrade your game’s features. And as a result, you have a mess instead of code. You have no extrinsic motivators like bosses or deadlines, so it’s very important to sustain your intrinsic motivation to make a game. And that’s why you have to clean up your code every time you feel you get lost in your own code. I sometimes refactor my code even after the project is released.

Some tips

Experiment! – For example, in Wake Up the Box 4 we decided to make some drawing animations in the game’s main menu. Players liked this feature a lot. It showed endless possibilities of drawing different objects and their combinations. And we received a lot of feedback from people saying that they enjoyed not only playing but also just watching those animations.

In the main menu, an example drawing of a house is shown to the player.
In the main menu, an example drawing of a house is shown to the player.
The main advantage of us being indie developers is the ability to experiment with our games.

Simple idea – I believe that indie games should be based on one simple and original idea. The main advantage of us being indie developers is the ability to experiment with our games. We can decide which way to turn the development process and we’re independent from the publishers with these decisions. We can’t compete with big teams in the quality and the amount of the content, but we’re much more flexible with creating new game mechanics.

Check out the Wake Up The Box series at Olologames.com. Wake Up the Box 4 was nominated for the game of the year award in the category Physics on JayIsGames.com. In the future, Eugene Karataev will continue work on the physics genre and develop new games based on the physics mechanic.

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

Post-Mortem: Stolen Couch Games’ Ichi (iOS, Android, PC & Mac)

January 21, 2013 — by Mariia Lototska

featured1.jpg

Stolen Couch Games is a young Dutch game studio formed by six alumni from the Utrecht School of Arts who decided to continue working together after their college projects. A part of the team came together to make a multiplayer prototype for XBLA and PSN title Chime made by developer Zoe Mode in collaboration with the One Big Game initiative. Stolen Couch Games then reformed and expanded the core team with an extra programmer and artist. Gamesauce recently featured a post-mortem on their first game Kids vs Goblins.

Early 2011, everyone at Stolen Couch Games was still in school developing our exam year project Kids vs Goblins. Jay van Hutten, a fellow year mate, was developing a game of his own called Ichi. It was a elegant puzzle game that utilized a one-button mechanic in a way that didn’t feel gimmicky. The goal of the game was to guide a ball past a number of rings on the screen. By touching the screen you rotate bumpers, which caused the ball to change in direction. You could also hold your finger down to draw a line, once the ball hit the line it would travel back in the direction it came from.

About a half year later we spoke to Jay at a congress were he was demoing his game. I (Eric) shared my interesting in redeveloping Ichi for multiple platforms and making it a really great commercial product. Jay loved the idea and the day we finished Kids vs Goblins we were working together to make a bigger and better version of Ichi.

ContributionsGame Development

Post-Mortem: Digital Dreams’ Cowbeam (iOS)

January 10, 2013 — by Mariia Lototska

splash.jpg

Digital Dreams is a Dutch indie game developer that designs and develops playful experiences. It was founded by programmer Thijmen Bink, level designer Roy van de Mortel and game designer Geert Nellen. Currently, Digital Dreams is focussing on creating games for the downloadable console market, However, this post-mortem is about Cowbeam: their first, and probably last, iOS game.

Digital Dreams from left to right: Thijmen Bink, Roy van de Mortel, Geert Nellen
Digital Dreams from left to right: Thijmen Bink, Roy van de Mortel, Geert Nellen

How everything got started

Let me start by saying that Cowbeam had virtually nothing to do with our former and current business strategy and portfolio. That is not meant as a disclaimer, but it is important to note because from the start this was an important factor in the decision-making processes during the production of Cowbeam. The idea came together due to very circumstantial and coincidental factors and it just seemed like a cool project to do at the time. In hindsight, this is not the way you want to make important decisions.

We naively started development of Project S because we basically thought everything was settled and done

We started out doing an assignment for another company somewhere early 2011. We were developing a hidden object game with a twist for them, of which the design document and assets had already been handed over to us. Let’s call it Project S. Without actually signing any contract yet, we naively started development of Project S because we basically thought everything was settled and done.
Our team was quite excited about Project S, because not only were we struggling to make money at that point, this was not some lame technical job. We were developing an actual game that we were enthusiastic about, although it was not something we would normally do. That’s why it seemed wise to let one of our team members start with Project S in advance. He created a technical backbone, so production could start off swiftly once we signed the contract.

Two weeks later we received a call from the other company. We were told they had to cancel Project S because of budget cuts. Now we were left with a half-finished game with which we obviously could not do anything due to copyright infringements. We were disappointed. Not only had we already invested time and resources in this project, we planned around the development of Project S. So basically we had nothing else planned in the upcoming period.

So with nothing on our hands, we thought about what code we could potentially reuse to make it not a complete waste of our time. One of the things we already developed for Project S was a simple but elegant system to show the player new objects he/she needed to find, and along with it, a way to arrange, dispose and organize these new objects in the HUD. New items would come into play sliding from the right until they bumped into a previous item that was already in place. Whenever an item was completed it would disappear and all remaining items would slide and arrange themselves into place. This system eventually led to a gameplay mechanic that resulted in the current hint system of Cowbeam, located at the top of the screen.

The arrange, dispose and organize-system that resulted from the left-over code of Project S
The arrange, dispose and organize-system that resulted from the left-over code of Project S

The new concept was called Cowbeam. A quirky little casual puzzle game, which puts the player in the shoes of Hank, a cow-hoarding alien. The player had to navigate a small galaxy and collect hints, which eventually showed on which planet a cow could be found. When the player finds the cow, the level is completed and the cow is shown. A big hook of the game were the cows, which resembled the planet they lived on. For instance: if the planet is red, the cow is red; if the planet is close to the sun, the cow would wear sunglasses or a sombrero, etc. We thought this was fun to see, and it was interesting for the casual audience on iOS as well.

Bringing Cowbeam to life

We had to start thinking more about our future and the monetization of our projects.

After the new concept was pitched internally, it took quite a few weeks for the idea to sink in and the team to pick it up and start prototyping the concept in Flash. The first few weeks of development went swiftly and the game came along quite nicely. We started building Cowbeam in Actionscript 3 with the idea to release it as a free browser game and get our money from advertisements. However, after 2 months of development we had to start thinking more about our future and the monetization of our projects. This meant for us we wanted to start using Unity3D. Another reason to switch to Unity3D was that the game felt not quite right on Flash. Mainly because you needed to swipe through galaxies which just feels weird with a mouse. We thought about releasing a Flash and iOS version simultaneously for a while but a Flash version just seemed redundant somehow.

Development of Cowbeam, after switching from Actionscript to Unity3D
Development of Cowbeam, after switching from Actionscript to Unity3D

We threw away everything we had so far in Flash and started the Cowbeam project all over again with a new engine to build with, a new language to write it in, a new platform to build for and even some new interns to work with. This was the first big change we made to the initial concept. Luckily Unity 3D is an easy engine to learn but this shift really put us behind schedule for quite some weeks, if not months. As an indie studio our deadlines were never really set into stone. However, we did know that by the time we started developing Cowbeam in Unity, we had planned on having the game completed in Flash.

Obviously, moving the game to the iOS platform pretty much meant a complete redesign of the concept as well. This forced us to rethink the game and strip it down to its bare essentials, which is using hints to narrow down your choices of picking the right planet. It cost us a lot of time to figure out what the most fun aspect of the core mechanic was for the player, which was a direct result of making something unique. We could have prevented this if we paper prototyped more, or incorporated playtests from earlier on.

It didn’t really feel like the game was complete and fun to play yet, so we had to make more design changes. A lot of features were cut at this point to make the game fun and suitable for the casual iOS market. These cut features include:
– Resources that could be gathered from planets;
– A currency system to buy hints;
– Time based gameplay and score system;
– Selecting and writing off planets.
Also using Unity3D, which as the name suggests is essentially a 3D engine, meant a complete redo of the graphics as well. Other than the menus and such, Cowbeam was now a 3D game instead of 2D.

On the left: The Flash version of Cowbeam; on the right: The iOS version of Cowbeam
On the left: The Flash version of Cowbeam; on the right: The iOS version of Cowbeam

This shift to 3D actually turned out great for the game itself because we were now able to rotate around the planets. We experimented with this rotation in combination with a number of features. We found the most interesting use of 3D was hiding certain characteristics from the planet out of plain sight. 3D also gave us more space and freedom to make the planets features more visually appealing and identifying.

Mistakes made, lessons learned

It was hard to think about killing our darling

The doubt we had with Cowbeam started to reflect on the team after a while in production: Is this game really going to be worth our time? Is it going to be fun enough? Is it even profitable in the end? Should we release this under our Digital Dreams brand when it’s this different from the stuff we want to make? Eventually it was a casual game, something completely different from the hardcore indie games we liked to make. The most important reasons to complete and release Cowbeam anyway were the amount of time we had already invested, everything we wanted to learn about Unity3D during the rest of development and wanting to have an actual finished game in the App Store. Especially the time we had already invested was a big factor in completing Cowbeam, it was hard to think about killing our darling.

Not playtesting enough fueled the doubt we had. Because we ran so far behind schedule, we somehow, without even really thinking about it, decided to scrap most of the playtesting and finish Cowbeam as soon as possible so we could start with our next project. In the end, we only playtested with visitors at our office and at the Festival of Games, a large Dutch event for people from the industry.

Our primary goal with Cowbeam was to master Unity3D and we succeeded at that

The doubt we had perhaps also lead to not properly marketing Cowbeam. All we really did was send out a pretty standard press release to our press network and hope they would pick it up. Of course we knew about the horror that is standing out and getting noticed on the App Store. But somehow we hoped it was going to be different for Cowbeam, because the concept was very unique and we believed it could stand out on itself. This wasn’t true. Sales were disappointing to say the least. On the other hand, it felt good to know we successfully published a game on the App Store ourselves and raised the bar for ourselves with the GUI and user-friendliness. Our primary goal with Cowbeam was to master Unity3D and we succeeded at that. Therefore we weren’t that disappointed about the sales in the end.

Just a few months ago we accidentally came across some little kids of around 12 years of age playing and really enjoying Cowbeam. This was actually the first time ever we saw anyone genuinely enjoying our game. Although it was a very cool moment it also brought us to the conclusion we should have seen this coming. We should have marketed and playtested for this target audience and maybe even design the game specifically for them.

Development tips

Our biggest pitfall was, as usual as with us indies, the lack of marketing knowledge and execution. Get someone to do this for you, find a good partner or really plan ahead and take your time to do this properly yourselves.
We should have considered micro transactions, freemium or other means of monetization over a somewhat outdated simple pay once model which we ended up going with. The reason we went with this is mainly because of the extra programming and design effort it would take to implement micro transactions. We did try to weave it through the design when we were redesigning the game, but couldn’t really make it click when we did. Again, in hindsight, this time might have well been worth our effort.

We think the chances are very slim we’ll ever return and develop for the App Store. The market is too competitive for a small developer and the marketing power of big companies is killing for us. We believe the only way you can succeed on the App Store as a small developer is to have a really original and well-executed game and marketing plan. Even then, every investment is a very risky one.

Currently we shifted our focus to bigger projects for the downloadable console market, which was the goal of our company from the start. We worked on a prototype for a downloadable console game in the meantime and we are very happy we have an opportunity to work on that project now.

We hope you’ll pick up Cowbeam and let us know what you think!

Cowbeam is now available on Mac as well and has dropped in price in the App Store. Digital Dreams recently moved to a bigger office and is currently working on a new unannounced downloadable console project. They will also be sharing more in-depth insights on CowBeam during their indie-postmortem talk during the Casual Connect Europe conference in Hamburg, Germany.

logo
SUPPORTED BY