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

Eugene Fedoseev

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

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

While reading lots of different tutorials on the internet I found a tutorial on Platform game basics using Box2D. It allowed the player to control a red box and let it interact with physics in the game world. I got very excited and started playing with it. I added different objects and obstacles, unlocked box rotation and finally found out that the box’s body is difficult to control. To fix this I decided to change the box to a ball, thus creating Red Ball in the spring of 2009. Initially I created seventeen levels and added different objects, platforms and flags. I drew the graphics myself, my wife found a great musical soundtrack and after 3 months we released the game. After a while I got a really good offer from 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 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.

Initial sketches for mechanics

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

Combining sketches in Flash
Combining sketches in Flash

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

The benefits of working with sequels

Twelve times more profit

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

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


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.

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 Wake Up the Box 4 was nominated for the game of the year award in the category Physics on In the future, Eugene Karataev will continue work on the physics genre and develop new games based on the physics mechanic.


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.


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.

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


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 DefenseSnail BobJelly CannonPheus and MorAcorn StoryTransformerDino TrekDream SymphonyRed Ball 4The Prince EdwardLazermanIntrusion 2On The Flat Of A DreamHordes and LordsZombotron 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

The Snowfort map editor
The Snowfort map editor

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