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

main

Contributions Postmortem

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

February 4, 2013 — by Mariia Lototska

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

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.

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.

After completing Volume 2, Fedoseev plans on creating a Volume 3. His motivation is to provide the fans of the Red Ball series with a lot of levels to play in the future. The studio is currently working on a website where you can follow their progress; www.redballstudio.com.

Contributions Postmortem

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

January 28, 2013 — by Mariia Lototska

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

I would play for hours, just drawing objects

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

Lessons learned

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

Make a prototype.
Show the prototype to different people.
Watch the players play the prototype, pay attention to their reactions (pleasure, frustration, etc.).
Make changes to avoid the frustrating moments.
Go to step 2.

Sometimes a player tried to create a circle dozens of times and had no luck. In other cases they tried to make a rectangle but got a circle.

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

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

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

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

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

Some tips

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

In the main menu, an example drawing of a house is shown to the player.

The main advantage of us being indie developers is the ability to experiment with our games.

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

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

Contributions Postmortem

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

January 23, 2013 — by Mariia Lototska

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.

Art imitates art

We try to expose ourselves to various forms of art looking for inspiration

Our inspiration was originally a puzzle game Midas: The True Weight of Gold, by Wanderlands studio. We came across it and were instantly drawn by the simplistic concept, unique mechanics and the fact that it was based on a well-known myth. These are the main qualities that we wanted to show in our game. We try to expose ourselves to various forms of art looking for inspiration, so we came up with a main character that is a prince from the classical ballet piece Swan Lake. It was an attempt to combine the storytelling and unique mechanics with humor, giving the game little bit of charm, but keeping it simple.
Now that we had a puzzle game that was somewhat funny, it was still lacking something crucial to make it worth players’ attention. At this point, we started experimenting with mechanics and it resulted in the core of our latter version of the game. We knew it was something to hold on to when we realized how fun it was for us to play around with it and explore the possibilities. The fact that you could easily alter the structure of the level, and the way of solving it gave us a whole new perspective.

Along the way, Ticklebot's love for Lode Runner had its influence, giving the game its action and skill layer. — Along the way, Ticklebot’s love for *Lode Runner* had its influence, giving the game its action and skill layer.

As excited as we were to discover numerous possibilities - and with many ideas in mind - we started to move further away from our original concept. Focusing on the puzzle part, and leaving out the humor, the story telling part happened spontaneously. However, we felt like we went too far into that direction and could not put all the pieces back together. It started to feel like we were getting lost in the mess of our own ideas, so we needed to stop for a moment and just think about which way do we want to go. It was clear to us that we wanted to keep the new mechanics, but we felt like the prince slash ballet dancer did not fit anymore. So we concentrated on our starting goals and worked from there. It was important for us to make a pleasant environment for the players, to make it simple and to retain the modest, not pretentious feel.

We gave 100% and it wasn’t enough, It was devastating.

As we got deeper into developing it got more and more complex and we were making a lot effort to keep the creative work alive. We were both in our home cities and had lots of other things going on as well. Most of the time we weren’t in the same room - or even in the same city - but it was still working well. We were constantly trying to improve the game play, and changed design and art style many times. It was getting better and better, we felt we were nearly there. Somewhere around the last iteration of the character design, we started to feel drained. We gave 100% and it wasn’t enough, It was devastating. We tried really hard, not even noticing how exhausting it became. There was no creativity left, and we lost the energy to bounce back. It was time to make a break.

Pause… PLAY!

We put aside everything and left everything that reminded us of work. It was a time to go out, ride a bike, go hiking, have a picnic, have fun and just restart. We did that, trying not to think about, talk about, or look at Super Sub Hero. In our spare time we made one small game (Uniwords) because we were broke. It helped us cover some expenses. After about a month, it was finally time to get back and get working on Super Sub Hero. It was amazing how a break like that has helped us to recover. We were happy to go back to Super Sub Hero and worked harder than ever. It was the most productive period, we were having fun with it and we were finally seeing everything fall into place.

Understanding the need for creative time, for letting go when it’s not working, has been crucial for us. It is such an obvious thing that we never even gave it a thought, like it was going to happen by itself. But after learning to listen to ourselves we made a big progress. We learned to communicate more clearly and direct, to be open and give chances, to let go when we were in a dead end. Even though it has been a (relatively) short and not very demanding project, it has given us valuable experience. Our confidence has grown as well. Our goals seem clearer and we are in a better understanding with ourselves, as well as with one another.

<em>Super Sub Hero</em>s look from prototype to final product. — *Super Sub Hero*s look from prototype to final product.

Every day you learn something you could implement in your work.

There are a lot things that could have been done in a far better way. Every time I look at the game now that it’s been finished, I see many things that need to or could be improved. Every day you learn something you could implement in your work. And if you give yourself time to be playful and childish, to be free and careless, you can’t help but bring a part of that into what you do. Now that it is all done, and the game is released, we still need to wait and see how the players will like it. As for us, we are satisfied, and the reactions so far have been good, even promising. A better timing would have been a much bigger success, so that is another lesson learned. Overall, it has been a hard learning experience, but also the biggest inspiration for us to keep doing what we love. After releasing Super Sub Hero, we started working on a few concepts and are expecting to bring one of them to an end soon.

Super Sub Hero is set for an early 2013 release. Ticklebot will be sharing more in-depth insights on Super Sub Hero during their indie-postmortem talk during the Casual Connect Europe conference in Hamburg, Germany. To see what Stefan and Milica are doing in the mean time, have a look at their website.

Contributions Postmortem

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

January 15, 2013 — by Mariia Lototska

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

One-man-army origins

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

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

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

The Game Design Gauntlet

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

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

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

Be problem oriented and assign a moderator to pull the brake

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

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

Good is not good enough

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

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

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

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

The complexities of being simple

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

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

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

Personal growth

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

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

In retrospect

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

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

Contributions Game Development

Post-Mortem: Digital Dreams’ Cowbeam (iOS)

January 10, 2013 — by Mariia Lototska

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

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

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

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.

Indie

Indie Winners of Flash GAMM 2012 Game Contest Invited to Casual Connect Europe Conference

January 8, 2013 — by Vlad Micu

During the fifth edition of the Flash GAMM conference in Kiev, Ukraine fifteen indie game developers were selected by the Casual Games Association (CGA) to receive an Innovation Scholarship, including a free airplane tickets and full conference passes to the Casual Connect Europe conference and the opportunity to show their games in Hamburg. The winning games included Red Ball 4, Dino Trek and Zombotron 2.

Besides receiving the Innovation Scholarship, Zombotron 2 was awarded the title “Audience choice award”. — Besides receiving the Innovation Scholarship, Zombotron 2 was awarded for the “Audience choice award”.

95 game titles entered the Flash GAMM Game Contest this year. Casual Connect (CGA) selected 15 indie developers that received Innovation Scholarships for their trip to Casual Connect Europe and Flash GAMM Hamburg. The indie games that were picked to receive the scholarship are: – Goal Defense – Snail Bob – Jelly Cannon – Pheus and Mor – Acorn Story – Transformer – Dino Trek – Dream Symphony – Red Ball 4 – The Prince Edward – Lazerman – Intrusion 2 – On The Flat Of A Dream – Hordes and Lords – Zombotron 2 Besides a free accommodation and a conference pass to Casual Connect Europe, the teams are given the opportunity to showcase their games at the Innovation Showcase, an “art-gallery” style exhibition in which twelve games are displayed that are considered innovative. The winners will also have an opportunity to present a short post-mortem presentation about their titles. Flash GAMM is a conference for flash, social and mobile games, which has been around since 2009. Casual Connect Europe will be held from 12-14 February in Hamburg and involves over 1.600 professionals.

Exclusive Interviews

Joju Games’ Juan Gril on building Snowfort, catering to gamers with families and working from a virtual office

January 2, 2013 — by Vlad Micu

With only enough budget to put three people on the development team (one artist, one developer and one producer), the flash game Snowfort came to life. Juan Gril, Joju Games’ Studio Manager, describes Snowfort as an ‘arcade comedy’. It’s a squadron-based RTS game based on a snowball fight, one that has been nominated for the ‘most creative’ game at the Flash Gaming Summit.

Building Snowfort

Snowfort was quite a challenge for the small development team. Even though it’s a flash game, tons of features were built in to the game. The Joju Games team of one developer, one artist and one producer had to create a single player campaign and allow for leaderboard play. The latter also had to include complete customization for your squadron. “And if you’re playing the game I [can] go to your profile, see your team and raid them. Your team, who [are] going to be managed by the AI, is going to defend,” Juan Gril explains. You can play asynchronously with your friends, and the developers are also working on the multiplayer right now.

“We’re basically taking concepts from social games and putting them in a normal game.”

The process of developing Snowfort has been an interesting one, Gril shares. “In general the problem that we have in the flash game industry is that it’s a five minute game. You have tons of games being released each day so the audience gets accustomed to play this game and never come back to it. We’re trying to change that with Snowfort”. He describes Snowfort as more like a social game than a regular flash game. It lives in a game portal and it uses a free-to-play system with a shop. “We’re basically taking concepts from social games and putting them in a normal game.”

Game play for gamers with families

“There’s nothing wrong with competitive games”, Gril says. “I like creating collaborative games, but gaming has always been competitive. You look at the oldest game we’ve got and it’s a competitive game”. But not everybody likes this kind of competition. For example the competition you can find in multiplayer games. You can still find plenty of people who buy a game just for the single player campaign and don’t even touch the multiplayer. “A lot of people don’t play multiplayer games because they go into a multiplayer shooter and they get shot in the face”, Gril offers as an explanation. “They get t-bagged or they get insulted; there are no nice places to play together”.

“The key is to create games that are accessible to everybody.”

The solution? “The key is to create games that are accessible to everybody.” Joju Games wants to focus on two groups in particular, groups who are often forgotten by big game productions and pose a perfect target group for Flash games:
Gamer #1: Those who were hardcore gamers when they were young, then got married, had kids and jobs, and don’t have time to play for three hours straight. Juan Gril sees this first type of gamer as a perfect focus. “If we can come up with game mechanics like Snowfort where we can play synchronously AND asynchronously, that makes a huge difference for people like us. If we can play with OUR friends in our own times, then we can still be gaming”. Out of experience, Gril knows that this type of gamer often has a high income which could be spending on games; if only the time barrier could be circumvented.
Gamer #2: The hardcore gamer who is taking his lunch break. Who’s not in front of his Xbox, PS3 or high-end pc and just wants to play for 15 minutes.

The Joju Games team

The Joju Games team now consists of 30 people, which is big in flash game terms. The games they create take a lot of commitment. As Gril explains, they are always thinking of an environment into which they can throw different mechanics. So the success of the game comes by maintaining it, by thinking of new features and mechanics to add to an existing environment. For Gril, this is why it’s important to have a steady team. “When you have monthly releases you have a lot of processes that you have to do in order to add a new feature. Like, make sure data is migrated successfully, and that a new feature isn’t affecting anything in the old environment. You team is constantly busy with maintenance”.
So crunch time is something that isn’t unknown to the team, Gril is aware of that. Although his team is passionate about what they do, the sacrifices that are made in their personal lifes are not unknown. Gril himself has dealt with them as well. Fortunately, Joju Games offers a way for the devs to still stay close to their families.

“And all our guys have worked in the industry before, in a regular game industry job, and they just wanted to have a different life”.

“We are [mostly all] over 30, and a lot of us have families and kids, and we know that game devs crunch all the time. We’re passionate about what we do and we have to stay late and get things done. And at the same time it’s very difficult to raise a family as a game developer. So we wanted to have a virtual office environment so that we could be closer to our families. What I always say is, ‘look, we may have to crunch a few days, but at least we’ll always have dinner with our families’. And all our guys have worked in the industry before, in a regular game industry job, and they just wanted to have a different life”.

The virtual office has given Gril himself a different average working day that the normal game studio manager. He works from home in the small office he has there. On a typical day, he looks at e-mails, has a conference call with his producers and takes a look at their current project. “We have four games at a time,” Gril says. “I sync up with each [of the producers] on how the game is going. Based on those conversations I can go and think of ideas [or solutions for problems]. I can record video’s while I’m talking, which I’ll then upload and send a URL to whoever I want to see it”. The rest of his day pretty much consists of the tasks familiar to every studio manager: talking to clients, publishers, team members, and thinking of new ideas. But Gril can keep his family life close.

Fortunately, his work doesn’t just take him to virtual office spaces. During his visit to Casual Connect Europe 2011, he had the opportunity to be reminded of why he enjoys working with games so much. “Something that gives me a lot of satisfaction every Casual Connect is the Games for Gamers Track, all these small games are very creative games. And they can come from the indie scene, the Game Jam, from flash games, etcetera. But the greatest thing is the fact that most of these games are not copycats, not an evolution of a FPS or an evolution of existing genres. They’re trying to come up with new genres, think of new ideas. Look at Joe Danger or Kingdoms of Camelot. It all shows that we can do a lot more.”

Newer Posts