The first global conference program to recognize and serve the game development community in Eastern Europe, Casual Connect works every year to bring great speakers, the most current topics, valuable industry learnings, and meaningful connections with the most qualified, successful game development community in Eastern Europe and beyond. The show included speakers from a number of multinational organizations such as Facebook, Game Insight, Big Fish Games, G5 Games, and Unity, as well as key domestic success stories like Odnoklassniki and Creative Mobile Games. More than 60 speakers from all over the world presented information-packed sessions about free-to-play games design and operations, social casino games, technological evolutions, development methodologies, new platforms, postmortems…and the list goes on.
In addition to the sessions, attendees at Casual Connect had the opportunity to build relationships with other businesses and create strong community ties, something that Casual Connect strives to accomplish with each conference. Networking opportunities were everywhere, including at the fun and unique sponsored parties. The Indie Prize Showcase also gave new developers a chance to talk to publishers and other developers about what they’ve been doing.
The Most Prominent Woman in Games Award from Casual Games Association was also awarded in Kyiv to Julia Palatovska, Business Development Director at G5 Entertainment.
With Casual Connect Kyiv now a fond memory, Casual Connect turns their attention towards their return to the location of the FIRST-ever show, and hopes to see you in AMSTERDAM in February 2014!
If you were unable to attend the show, the presentations were recorded on video and made available for free on Gamesauce and the conference website.
Critical Force Entertainment Ltd is a new game development studio founded in Kajaani, Finland. The studio created Critical Missions: SWAT, a first-person shooter available for iOS, Andriod (released under Studio OnMars) and playable on Kongregate. The company focuses on developing premium and free-to-play crossplatform games with a special focus on the Asian market. So far, the company is self-funded, but investors are welcome.
Veli-Pekka Piirainen is CEO and founder of Critical Force Entertainment Ltd. He is a former studio manager of Supercell North as well as a lecturer and head of Kajak Game Development Lab. Piirainen is also co-founder of NMP Games Ltd.
A student’s hobby project
In December 2011, I hired Igor Levochkin – one of the students at a school I taught at – as a programmer in my new startup company after following his work for the past two years. Igor and I would make games for the Apple AppStore, and we started making a prototype of a game called BomberBall. At the same time, Igor put his hobby game project in Kongregate. Early January 2012, Igor showed me that there were hundreds of players playing his hobby project game, but I didn’t pay much attention to it. I just thought it could be a good marketing channel for our iOS game.
However, at the end of January 2012, there were a couple of thousand players playing it and I started to get more interested in it. I gave Igor a Sony Xperia Play phone and told him to port the game to that device. Igor managed to have it up and running in a matter of days. Next, I told Igor to port the game to iOS; this was bit more difficult since he was not familiar with Mac and Xcode. After a week, the game was also running on iOS. Now I really started to see some potential in the game. Despite all this work on Igor’s project, we also continued to develop BomberBall because I wanted to have a good prototype for the GDC in San Francisco. I demonstrated both prototypes at the GDC and Igor’s project, Critical Strike Portable, gained more interest from the public. After that trip, we decided to concentrate fully on Critical Strike Portable.
Keeping up with high popularity
Igor started fulltime development on Critical Strike Portable by adding new weapons and features. I still worked part time at the university and couldn’t fully concentrate on the game development. I trusted Igor and also a team of Russian volunteers, who supported us in the growth of the user community as well as map creation. Another important task was to make a proper and more user friendly User Interface (UI) for the game. Unfortunately, Unity 3D’s tools for this job were pretty limited and we didn’t have any artist or UI specialist in our team to design a nice, good-looking and functional UI. So Igor made a “coder-style” UI with many different settings and options inspired by Counter Strike style menus. That UI was easy to use with a mouse, but for mobile phones with touch screens, we needed a different kind of UI.
Because I was inexperienced in game marketing, I hired Teemu Riikonen in April 2012 to lead the studio as well as take care of publishing and marketing of the game. Our next employee was Thanabodi Thongchat, a 2D artist from Thailand. She started designing backgrounds and UI graphics for the game in June 2012. Igor implemented more and more features to the game like new game modes, zombies, graphical effects, as well as fixing bugs. We released new versions on Kongregate weekly and got feedback from players on how to improve the game. At the end of June 2012, we had nearly 30,000 daily average users playing the web version of our game, but we were still growing.
We got over 1 million downloads in one month.
On June 26th, we released a free Android version of our game with exactly the same UI and almost the same features as the web version. Even though it was not so easy to use and the menu elements were pretty small on a phone screen, its popularity surprised us. We got over 1 million downloads in one month.
But the problem was that many players didn’t continue the game after their first try. Only hardcore players did so. We decided to create a totally different and simpler UI for mobile devices, because the current quality was not good enough for Apple’s AppStore to sell it as a premium game.
At the end of August 2012, two game development students, Olli Lahtinen and Aapo Lehikoinen, started their internship in my company. They started to build a totally new UI, added new controls for the iOS version of the game with a new NGUI toolkit we bought from the Unity Asset Store and started to design new maps for the game with Hammer editor. We also needed new character models, guns and animations for the iOS version. Modeling and animations were outsourced to freelancers in Thailand and our Thai artist was leading that work. Unfortunately, the quality was poor and delivery was very late. After that, all animations were outsourced to two Finnish startup game studios and for the modeling of guns, I hired another student.
Unfortunately, we had to remake all maps done with the Hammer editor (16 total), because our lawyer said we probably weren’t allowed to use that tool, since it’s licensing agreement is not clear enough. Our lawyer also recommended us to change the name of the game from Critical Strike Portable to something else, because that name reminds too much of Valve’s Counter Strike (Critical Missions: SWAT was born then). Our original plan was to release the iOS version in the end of September, but it was released in the end of November due to these difficulties. A new Android version was released just before Christmas, a Lite version in the beginning of January 2013 and the Mac version is in the review process as of this writing.
The iOS market is very competitive
At the end of the year, the amount of our players had increased dramatically. We had almost 200,000 daily players on the web and over 100,000 daily players on mobile devices, but all were playing our free versions. Monetizing with premium version seemed to be much more difficult than we thought it would be. The iOS market is very competitive and full of games, so getting visibility is very hard. We also had bad luck with a very important review, because the reviewer didn’t like our controls at all (many other not so significant reviewers did like them, however). Because of this, we didn’t start to get income fast but our server costs rose dramatically due to the massive amount of users. We also had some trouble with one specific server provider, who just calmly cut off the lines to our map server without any warning due to dramatically risen network traffic.
Our biggest mistake was to save money in wrong places and get low quality from our international freelancers. We trusted our own artist’s capabilities to handle leading of the outsourcing, but she was too inexperienced for that. Of course, rates a quarter of the price compared to local studios were very attractive, but then the harsh reality revealed we had to do everything over again after that miserable trial period. It would have been wiser to use more professional outsourcing studios in the very beginning.
Our second mistake was not to solely focus on Critical Strike in the very beginning, but to also make the BomberBall prototype. Something else I would change was not to have a tighter management; everything went forward more or less without proper planning and scheduling. A fourth mistake was not to take a professional publisher to publish the premium iOS version. We thought it would be easy to self publish, because we had such great success with the free Android version, but we were wrong. A last mistake was not to pay enough attention to the server capacity, but that was more or less because of our inexperience with servers and also our idea to save money.
The team is currently working on a new game, called Critical Missions: Space. It has the same nostalgic fast paced FPS gaming experience as Critical Missions: SWAT, with the addition of space rangers, space pirates, laser guns, aliens, space themed maps and more.
Next to that, they keep adding more to Critical Missions: SWAT. They’ve scheduled new guns, characters and maps as well as unlockable content for the next update of their very popular shooter.
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.
The preproduction period was challenging
Before pre-production started, our technical department evaluated different middleware solutions. They came to the conclusion that Unreal 3 Engine was the most suitable tool for creating Fairytale Fights and other possible future titles. It had a very strong editor and was by then the only middleware solution that proved it could deliver quality results on both PS3 and Xbox360. We knew that it would take some time to set up the work flow and to learn Unreal 3. As a result, a small team was assembled to start learning Unreal while also working on the liquid and dynamic slicing technology and creating content in order to develop a vertical slice of the game.
The preproduction period was challenging. The team encountered several technical obstacles such as recreating the experience of the prototype movie to a vertical slice of the game. Fortunately, a couple of weeks before the Leipzig Games Convention in August 2008, something magical happened. After making some harsh cuts and redesigns, everything fell in place. The vertical slice became a game with a soul, fun to play and a delight to watch. The vertical slice looked gorgeous and the dynamic slicing and liquid system worked. You could even jump into the puddles of blood and red drops would color your surroundings. Also you were able to slide through the blood puddles, painting the world red.
Sometimes we could see the journalists thinking “Oh no, not a kiddy platformer! Another 20 minutes wasted of my precious time!”
The decision was made to present the vertical slice only to a select group of press behind closed doors during Leipzig Games Convention. We all knew we had something special, something different. But the question was if the critical games press would like it as well? We all knew we took a chance with Fairytale Fights. Everyone was using the power of the recently released Xbox360 and PS3 to show realistic looking masculine battle scenes in space or industrial locations. Alternatively, we were creating a game that from the first glimpse looked like a game made for children, but contained cutting edge technology to recreate cartoon violence (salami violence as we called it internally) like dynamic slicing and dynamic liquids.
When we started our presentations during the Games Convention, sometimes we could see a journalists thinking “Oh no, not a kiddy platformer! Another 20 minutes wasted of my precious time!” But once we started the dynamic slicing on the first innocent bunny into small pieces and slide through the puddle of blood from the bunny, you saw a big grin on the faces of most of the journalists and they were keen to learn more about the game.
After the Leipzig Games Convention, it was clear that Fairytale Fights might become something big. Some journalists even wrote Fairytale Fights was the biggest surprise at Leipzig GC that year! Now we had to develop the full game. It took almost 1.5 years to create the vertical slice, a tiny fragment of the whole game. Some key features of the game were working, but still a lot of work had to be done, especially creating content (models, animations, levels) and making sure it would run on all supporting platforms.
One of the biggest issues we already faced during pre-production was finding skilled people. A studio in Rotterdam (not far from the development studio) called Coded Illusions went bankrupt. They were working with the Unreal Engine for several years and we were able to make several formal employees interested in working at the studio, but this was far from the amount people we needed to develop all the content needed (creating models, animations and levels). So we got in touch with a studio that was specialized in building props and animations for feature films and animated TV-series. They were in-between projects and were eager to enter the game content business. Only there was a small problem, our team was not finished with the design and they were working day and night to make sure all the deliverables were available to them on time.
Fairytale Fights was scheduled for a late 2009 release. Sometimes it felt like a mission impossible, especially when things didn’t work out as expected. We had to some cut features and content that was originally scheduled for the game. Everyone at Playlogic was extremely dedicated and spent many hours to finish the game on time.
Not being able to attract as many experienced candidates to the studio as we would like also caused delays
As mentioned before, the pre-production took longer than expected. Most of the lead members of the pre-production team were recently promoted and had no or limited experience with starting projects from scratch. Also several key members of the team had to support other running studio projects every now and then, also delaying the pre-production. Not being able to attract as many experienced candidates to the studio as we would like also caused delays. We were recruiting, but it was difficult finding skilled people that were also willing to relocate to Breda (the location of Playlogic Gamefactory, in the south of Holland). After the positive feedback during Leipzig GC in 2008, it became much easier to attract skilled personal. Also the decision to outsource work to other companies meant that people who otherwise could help in production, were now managing outsourcing.
Another thing that caused the delay was that sometimes development was dictated too much by the visual design of the game. For example: at the start of the game, the players and enemies are moving on forest paths with varied terrain. It looked great, but it caused a lot of problems regarding Artificial Intelligence, collision and physics. Looking back, too much time was spent on trying to solve technical issues that were caused by these visual decisions instead of finding alternative visual solutions so these technical issues would not arise.
When the game was released, it received mixed reviews. Many journalists liked the colorful visual style and over the top cartoon violence of the game, but found it a bit too repetitive or didn’t like the usage of the right stick for performing combat moves. Combat is indeed sometimes a bit too repetitive. There were many more puzzles and platform challenges in the original design of the game, but not all of them made it to the final version of the game, making the game too dependent on combat alone. After speaking with a lot of players (especially female players), there was also many who liked the usage of the right stick for combat. It made the game accessible and suitable for co-op play with less experienced gamers, because using the right stick for combat felt intuitive. Several male players told me that Fairytale Fights was one of the few games their girlfriends or wives enjoying playing and they both enjoy playing in co-op mode.
Several male players told me that Fairytale Fights was one of the few games their girlfriends or wives enjoying playing and they both enjoy playing in co-op mode
Not such a happy ending
After the release of the game, a small team continued to work on DLC, which was released shortly after. The rest of the team started pre-production for Fairytale Fights 2. The first Fairytale Fights 2 prototypes were very promising and showed the team had many new fresh ideas. Unfortunately Playlogic encountered financial troubles and the studio had to close its doors halfway 2010 just before winning 2 Dutch Games Award 2010 for Fairytale Fights a few months later.
Some footage of early prototypes of Fairytale Fights 2 has leaked unto the internet. If you are interested, you might be able to find it. Playlogic is currently only publishing games, primarily focusing on publishing digitally on consoles, handhelds and mobile devices.
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
When we started our work on Wobble Bobble, it was a very small game. The goal, our one simple game mechanic, was to keep the ball in the center of the table for as long as possible. By keeping the ball in certain circles in the game area, the player would earn points. We kept this feature and started thinking about expanding the gameplay mechanics to make the game more challenging. There was an immediate need to add fun to the game, and we took a routine path of adding new modes to the game. We added Challenge and Arcade modes and renamed the first mode to Classic mode. When we showcased the game to gameplay testers (including some industry leading people), they found the Arcade mode to be more fun. Because of this, we decided to make the arcade mode the standard.
Mistakes made, lessons learned
Since Wobble Bobble was our first attempt to do a true mobile game, we faced our own share of problems. Luckily, every problem taught us something we can incorporate in the development of new games.
One of our biggest mistakes was only checking the performance of the game on the latest iPod Touch and iPhone 4S. The game was working absolutely fine on these devices. When we tested on older devices, we found out the speed of the game was too slow. The speed of the ball used to depend on the processor of the device. When developing for PC, we take great care of issues like this, but we never bothered while developing a mobile game. We managed to fix this issue using Delta timing. In short: delta timing is used to handle complex graphics or a lot of code, by defining the speed of objects so that they will eventually move at the same speed, regardless of processor speed.
Another problem came from testing the Android version of the game on a Samsung S2. On the S2, everything worked perfectly fine, but on a Samsung Note the game would crash. We decided to do some quick ‘n’ dirty resolution tweaks so it would run on Samsung Note too. However, when we launched the game, we realized these tweaks were temporarily solutions for a bigger problem: Cocos automatically resizes the screen for Android. After more tweaking, we got everything working, both speed and resolution were permanently taken care of.
It was still a near perfect project
Though there were issues related to the shift, a lot of things went in favor of the project.
No major feature changes – Up until the development of Wobble Bobble, we had never worked on a game where the basic planned features never changed. Though we improved the basic gameplay mechanics of Wobble Bobble, no major changes occurred. Throughout the production, we were always aware of the exact scope of the game and things were neatly planned.
Our strong project management roots – Coming from large game projects, we always relied on strong project management. This worked in our favor as we had Microsoft Project, MantisBT and SVN running on our server, helping us to stay close to reality and allowing us to always have an up-to-date version of the code. There were stand up meetings every day and all the tasks were regularly updated in the Microsoft project. All the bugs were tracked in MantisBT and everything was accessible from home as well, so we always had access to what was going on with the project from anywhere.
Iterative Implementation – We never had a huge game design document written for the game, so we approached each module of the project as totally individual. Frankly, we didn’t even know what additional module will be added next, while working on the current one. We focused on perfecting one feature before even thinking about what the next feature would be.
A solid team – The biggest achievement of this project was that the entire team stuck together and kept sharing and debating ideas. Nobody in the entire studio was away from this project and everybody participated willingly. In most of the studios, the Pareto principle is in effect, i.e. 20% of the people doing 80% of work. In our studio, it seems like we only have the 20%, in a way that everyone is productive and 100% focused on the game.
The development of Wobble Bobble also saw people coming out and taking responsibility at an extraordinary level. For example, our QA manager took the responsibility of managing daily stand-up meetings and making sure things were transparent.
Playing games – In our earlier setup, we used to have at least 1 hour of Team Fortress 2 or Call of Duty LAN matches a day. We used to encourage everybody to play games whenever they were free, so there used to be a lot of single-player games, game-related discussions and showcasing in the office. When we started TAGS, we were busy working on games or game pitches, rather than spending time playing games. Most of the guys used to play 3 hours a day, but the initial struggling period left us wanting to focus more on development and gaming took a hit. We weren’t happy about it, but we had no choice. However, there was one thing that we religiously maintained: to stick to a five days a week schedule, so that the team could spend some time at home and play. It was a tough decision but we were spending more than 12 hours a day in the office. We all knew that it was a temporary phase and currently we are back to being normal, and normal people play videogames!
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.
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.
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.
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.
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.
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.
Zarkua and Kulakov are currently working on a part two of their popular Dream Symphony, using new technologies of sound translation. More sounds, more graphics, and more achievements. Next to that, they are trying to implement new design elements to the game.
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.
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.
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.
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.
The Global Game Jam and beyond series sheds light on the few brave Global Game Jam (GGJ) teams that have decided to take their GGJ projects to the next level and continue development after those challenging 48 hours. We ask each team to tell about their experiences, share learned lessons and offer advise on their attempt to turn their Global Game Jam project into a full fledged commercial product.
Last year’s edition of the Global Game Jam saw its biggest entry of games yet. Combined with the rather obscure theme of Ouroboros, the ancient symbol of a serpent or dragon eating its own tail.
Based on the Oroborus theme for the GGJ2012 the team behind the quirky one-button arcade game Catch-22 wanted to make a game in which your actions bite yourself in the ass. This resulted in them not only winning the local competition at their jam site, but later also won a prize for being the best Dutch Global Game Jam game. Catch-22 also later became one of the PAX 10 selected indie projects to be showcased at the PAX Prime event in Seattle back in August 2012.
Catch-22 has been in development for iOS ever since.
After we finished the game we realized we made a game in which there is no AI entity or anything attacking you in the game, but yourself. Contrary to normal arcade games, Catch-22 doesn’t pump you full of adrenaline with upbeat music and flashy stuff, or send in hordes of enemies towards you to defeat. You do that by yourself, because this game is all about the endless battle you have with yourself. That idea was truly unique and something that we hadn’t seen before ourselves, so we decided to continue developing Catch-22.
What triggered your initial consideration that your game was worth to continue development?
We didn’t have the idea that our game was worth continuing until after the GGJ ended. We only came to insight on what our concept was worth after the Jam, when we won first place in the national Dutch Global Game Jam. During the Jam itself, we were really just focusing on making the game, were exhausted afterwards and just glad we finished it.
Since our game is a one-button game it’s really easy to port it to any platform since you don’t need a controller. We also made it in Unity 3D, which gave us the power to port it to handheld devices (iOS and Android) instantly. So we figured; why not?!
What do you believe was the main element of your game that allowed it to be commercially viable?
After the jam we had a working proof of concept and it only need a lot of polishing. Next to that the game doesn’t require a specific input device such as a controller so it’s easy to port it virtually to any system. And again, Unity 3D gets you a long way.
What really got things in motion was that we got the Dutch “Gamefonds”, a local subsidy for creative projects, to financially support the development of the game just one month after the GGJ. I’ve seen enough projects die young because of the lack of funds, and our project almost suffered the same fate. The funding enabled us to finish the game, fly our butts over to A MAZE IndieConnect, PAX Prime and IndieCade, and hire the necessary artists to work on the game. We simply couldn’t have done it without this initial starting money.
How did you manage the step to go commercial in your team?
We have a really simple way of working which translates to this line; Drink beer, smoke cigarettes and make video games. Rinse and repeat this until the fat lady sings. Really, just flip the switch and go for it, because there is only two ways of doing things; Do them really well, or leave it for someone to do it really well. Because making games is hard, tedious work and you, my friend, are not a robot.
What were the three most important experiences/learned lessons and/or challenges that you had while further developing your game?
Make some solid agreements beforehand
First of all, make some solid agreements beforehand. If you do get in a situation where there is a conflict within the team, you can still have a level of conversation where you can clear the air. If you don’t do this, then be prepared for some hard loving from your close friends. For example in our team, team member Roel had spend a lot more time into the project in the beginning stage and wanted to be compensated for it. I agreed, but team member Marlon didn’t and had his own reasons for it. In the end we arranged to have a team leader (aka a neutral party) who overlooked the project and could talk to us as a supervisor. This made all the difference for the balance within the team. So unless you have really, really good agreements, you can’t simply overcome the possible conflicts that arise within your team. There are one too many teams who think they can do without a good agreement, and it just doesn’t work like that in any kind of game development setting.
Make sure you get your long-term focus right
Second, make a plan to where you want your game and/or company to be in a few months. Make your goals achievable, because just talking about it with your team will not just make it happen by itself. Things change over time and personal situations can get the upper hand if you don’t. I got de-motivated by the fact that things took too long or just simply weren’t done during a certain period of development. Motivation is the only thing that keeps you going when making games, whether it’s money or just finishing your game. So get your mind straight and make sure to get your long-term focus right. Nearing completion, we would regularly go out for drinks and enjoy ourselves from time to time. Having the release of the game within reach, things got a lot less stressful. Most conflicts took place at the beginning of the project. In retrospect, we also stayed motivated by the achievements we got in the meantime; from winning the GGJ to getting 25k honored, to being selected for PAX10 and IndieCade, and finally the release ahead. Having stuff to look forward to is great, especially finishing your game.
In your case, what did you learn from getting the game out to the public?
Start doing this as soon as possible. You will be surprised where it can take you and your game! We can’t stress people enough to do this. If you feel uncomfortable doing this, talk to some people, practice and work on your pitch. Because the public doesn’t see your game like you do and their opinion is the most valuable one you can get. It’s also a really good way to test if your game is commercially viable. If you get some reactions from people who ask you if it’s already for sale or available, Ka-ching! You got game!
What kind of tips would you give to other GGJ participants who might decide to continue developing their project?
It takes time for your game to pick up momentum
Stop crying and making excuses to not release your game or get it out in the open right now. It’s the first sign of failure and I witnessed this in person at the company where I did my traineeship.
It takes time for your game to pick up momentum if you haven’t released any games before or are a well known game developer. Don’t think people will be jumping and begging for your game, because there is a lot of competition out there.
Last but not least, get accustomed to the Nike mentality; just do it! And that goes for everything in your project, from making your game to marketing and PR. Best practices come from experience, and it’s ok to “fail” on your first go.
Cath-22 for iOS can be downloaded in the AppStore.
The Global Game Jam post-mortem series covers the experiences of various Global Game Jam (GGJ) teams from all around the world. We ask teams from various locations and GGJ editions to look back and tell us about their experiences, share learned lessons and offer advise on creating something beautiful and fun in less than 48 hours.
This is ship’s log for ARK-II, mission 2301.A.NULL, written by captain-in-charge, NoahX02.
Our mission will begin shortly. It will be our last mission before departing the solar system.
Preparations are complete. The estimated hour for execution was, unfortunately, imprecise.
NoahX01 is MIA as of the last hour. Our current measurements indicate that temperatures have reached critical levels, and we must depart at once.
The storage system is functioning properly, and is ready to receive the specimens. I fear that the early arrival of the sun’s thermatmosphere will render most of the remaining life in the system extinct before our current plan can be executed. It is for that reason that we have ultimately agreed upon adopting plan C.NULL to mission 2301, at our own expense and risk. That plan does not exist in your archives. It is as follows:
ARK-II will follow the designated route of the planets as of plan A.NULL;
Each landing will be the beginning of an approximately 1-minute search mission, instead of the 3 hours designed in A.NULL;
We will deploy as many NoahX units as we can, but only one at a time, to guarantee the success of the mission;
ARK-II will depart the planet when that time has elapsed, regardless of NoahX units that are in the surface of the planet;
The times are calculated for every planet to maximize our orbital jump’s effectiveness;
Upon leaving the last planet, the ARK-II will enter phase 2, and launch into hyperspace as expected.
All NoahX units have agreed on this.
All our hope are belong to you.
It begins now.
Cheers everyone! We are a team of independent game developers who participated in Global Game Jam 2011 from Curitiba, Brazil (with PUC-PR – one of the biggest jam sites in 2011) and created the game Planetary Plan C.
This year’s theme was “Extinction”, and the idea for the game came from looking up the word in a dictionary, where we found the meaning of stellar extinction. After a brainstorm session by most of the team, we came up with the basic ideas for the game mechanics and concept – at this point, it’s difficult to say who had which ideas.
In our basic game conception, the player is able to visit four different planets in succession. In each of them, he is given about a minute and a half to rescue as many plants, animals, people and novelty items as he possibly can, before everything is incinerated by an expanding sun in its Giant Red stellar phase. The game is played as a simple platformer, with the added twist that the worlds are small and circular, so you can walk all the way around it in a few seconds. To add challenge to the quest are natural hazards: lava, water, and volcanic eruptions. Once the time is over, the ship automatically takes off to the next planet, until they have all been visited, and the player is awarded with a sight of everything that he has rescued, on their new home planet.
Determining this basic gameplay took a lot of time. The duration of each world (and of the game as a whole) were also a serious issue, as we needed to decide it beforehand so the music could be composed to match it, but we didn’t have enough gameplay feedback to make a well-informed choice. We went by our gut feelings, and we think that we got it just about right. Beyond that, everything went very smoothly.
With the main idea in our heads, we then proceeded to organize our work process and assignments for each member on the team with what was important to take the most advantage of our time and resources.
The tasks were divided based on the specialty of each member of the team, so the programmer (Rodrigo) and composer (Rafael) worked on their own in their respective areas, and the art assignments were as follows: Santo was responsible for background art, props and audio effects; Amora made the art and animation of the main character, the robot Noah, as well as animating part of our game resources; Irene worked on the design of the game’s visual interfaces, menus and HUD; Henrique focused on concept art, animated resources and Noah’s spaceship – and also wrote the game intro message; and Karen made concept and resources art, spaceship and game introduction screen. That aside, everyone took part in the creation of concept and game mechanics.
“There’s much credit to be given to the classic platforms like Mario, Sonic and Megaman, for their influences on how we perceive platform movement.”
The influences and sources of inspiration for the game were many. There’s much credit to be given to the classic platforms like Mario, Sonic and Megaman, for their influences on how we perceive platform movement. The “controlled jump” and “accelerated move” of Mario and Sonic are seen in the game, as is Megaman X’s dash.
In the case of our composer, Rafael didn’t look for specific game soundtrack references with a thematic similar to our game idea, mostly because there was not enough time for this task. So he focused on his own musical preferences he was used to working with, so he could reach the soundtrack effect he wanted more easily. He took as inspirational sources L. V. Beethoven, J. Brahms, Leonard Bernstein, and music from Banjo-Kazooie, Zelda and especially, Mario Bros. He composed the orchestra as to provide the game with a dramatic atmosphere, supplying an urgent and epic feeling to the task of collecting resources and avoiding extinction. The musical percussion was specially designed so it could give an additional fun ambience to the missions.
The right scale
During the game’s development, several ideas didn’t make the cut, simply because we didn’t have enough time to implement them:
There were supposed to be at least two additional hazards, a lightning bolt and a meteor;
Smoke particles were supposed to be used for the dash and as a notification that the volcanoes were about to explode;
We originally had planned a solar system-wide view, where you could see the star swallowing the planets as time went by.
We tried to deliver the player an experience where he comes upon a situation in which choices are to be made, for he will never be able to save everything from each small planet. These choices per se imply results and responsibilities concerning the influence over the sustainability of a new world as well as the preservation and extinction of species and cultures. We wished this game to provide fun above it all, without trying to stuff the player with moral lessons or cliché preaching. If the player can gather a deeper meaning from his experience or just have a really good time playing, all is well, our mission is accomplished!
“Looking back on our development process, one thing that could probably have been better would be to have more time to balance and refine the gameplay.”
Looking back on our development process, one thing that could probably have been better would be to have more time to balance and refine the gameplay. Particularly, we believe that the final scoring and collectible distribution systems could have been improved. Our programmer’s opinion is also that the game might have ended up being too hard, perhaps due to the unpredictable spawn of volcanoes and the movement (in particular, the unstoppable dash).
Overall, everything went incredibly well. Some great ideas surfaced, like Henrique’s idea to use a “surface map” to indicate the hazard areas of the map. With a combination of Notepad++ Macros and Photoshop trickery, he could create a long string of 0s and 1s indicating which segments of the surface of each world was safe to step on, and Rodrigo hardcoded that into the game as C strings. Without that, it would have been impractical to implement this concept, at least given the time that we had with only one programmer. It was very surprising to see that all surface maps were very accurate, and not a single one required tweaking!
The team is very proud of all the polish that we were able to give the game, including finishing a reasonably complex game with relatively few bugs. We also managed to complete the GGJ-2011 Achievement Playing the Music: The game’s duration is matched to that of a song. When the song ends, the game ends. No loops allowed.
For events like the GGJ, where you only have a weekend to develop a whole game, the most important thing we can say is: THINK SMALL. Games are always more complex than they seem at first. In particular, we strongly recommend making a 2D game, since not only does 3D add extra difficulties in both programming and asset development, and given the time constraints, they are rarely worth the effort, and are more likely to look “amateurish” (it’s unlikely that you’ll have time to make professional-looking models and textures).
“There’s no “write the whole game first, program the whole game later” – and some questions are better left unanswered, too!”
After the first concepting phase, when you know what kind of game you want to make, you will have tons of gameplay and feature ideas. You will also get that paralyzing feeling of “we have to decide everything that would be in a game’s design”. We really think it should be avoided as much as possible. Think of all the questions on your mind, but don’t decide on anything beforehand – instead, think of the smallest subset of the game that you can build fast, and then as you build it you will feel the answers coming. We tried defining that smallest subset as early as possible, and work on it right away: “some platformer guy who is running around on a 2d planet with lots of hazards and a spaceship he has to return to. He collects things.” Whether the guy was a robot, a dragon or a human, whether the things he picks up are rocks or books or people: it didn’t matter at that time. There’s no “write the whole game first, program the whole game later” – and some questions are better left unanswered, too!
A tip we would like to give is that care should also be taken when picking your tools: pick something you’re familiar with; you already have enough on your plate, don’t try to learn new technologies as an added difficulty! Try to prepare in advance, setting up a blank workspace/project can save you a lot of time. When you’re trying to get a game done in 48 hours, you don’t want to spend a few of those tracking down dependencies and writing boilerplate. And finally, have fun! Otherwise, there’s no point in joining.
Finally, we wanted to say that having such a positive feedback about our work is without any doubt the best kind of stimulant we could get. It’s definitely an incentive to keep working hard and makes us value our work as a team and individuals, as game developers. We want to keep producing games and giving it our best.
We are sure that this positive response to Planetary Plan C is the result of an incredible teamwork, full of talents that not only complement one another, but are capable of communicating well and sharing a harmonious view of the whole.
Amora B. has a career in Animation, having worked in productions such as “The Princess and the Frog” (Disney), “Chico y Rita” (Estudio Mariscal y Magic Light Pictures), and other films and commercials. She’s a co-founder of MiniBoss.
Fernando Su is a friend of the team. He helped us as a Beta Tester, cooking-planner and moral support.
Henrique Schlatter Manfroi majored in Game Development. He has worked for Southlogic Studios and Ubisoft as a 2d and 3d artist, and is now co-owner of the independent developer Sulistas.
Irene Sasaki Imakuma majored in Architecture and Urbanism, and works in a retail architecture office. She also works with graphic design, animation and project management as a member of MiniBoss.
Karen Garcia Teixeira has majored in Visual Arts. She works as an Illustrator and is a member of MiniBoss team.
Rafael Miranda is a pianist and studies composition at Alcântara Machado College in Brazil. He composed the soundtracks for the games Jules: unboxing the world, Talbot´s Odyssey – part one and Planetary Plan C. He is a member of MiniBoss team.
Rodrigo Braz Monteirois the game’s programmer. He works for an online casual gaming company, where he is the lead programmer.
Santo, a.k.a. Pedro Medeiros, has majored in design and works with illustration and concept art. He is a co-founder of MiniBoss.
Find out more about Studio Miniboss team on their blog.
It’s one thing to own a successful brand. It’s a different thing entirely to be able to successfully leverage that brand across multiple different products and media. I spoke with Christian Meyer, Senior Vice President and General Manager of GSN.com, about how he was able to pull it off and where he was planning to go from here.
How were you able to successfully leverage your television brands across the digital sector?
Well, a lot of time is spent in activating a brand strategy where we license a third party brand, like Wheel of Fortune or Deal or No Deal or Family Feud for example, and ideally, they have both an acquisition value and a retention value. We’ve been pretty lucky in that regard. Sometimes you’ll get a branded IP that has a great acquisition value, but the conversion value as a casual game or any kind of game experience for that matter is a bit of a long shot. You end up with an under-leveraged investment because you spend a lot in licensing.
And you don’t make anything off of it?
You potentially don’t make anything off of it, yeah. But we as a company have an understanding that if we can acquire based on the brand IP and then migrate those consumers to a higher retention experience, then that works pretty well too. But certainly the home run is when you establish a great relationship with a brand and you can unlock the acquisition value of that brand as well as the retention value. Then you have the makings of something huge.
Which of your IPs demonstrated this investment strategy most successfully?
Wheel of Fortune is definitely the stand-out. It’s been the number one syndicated brand for probably thirty-five years. It amazes me still that it has such longevity, and that can be traced back to its accessibility. The brand does a lot of work. It acquires well, consumers love the game, and they can also envision themselves competing in it. You get this trifecta of properties that make it a very powerful asset.
You guys have been doing some interesting things with leaderboards in your games. Any plans to integrate them into the television show itself?
We’ve done a lot of research and development around cross platform play between the television and the web specifically. And we’re starting to do a bit more on mobile. Absolutely to your point. Consumers want to participate. Technology has been a little behind consumer desire in terms of allowing us to create something simple and compelling, but we’ll get there.
The ten winning games were selected from the 1487 games that were developed last weekend during the Global Game Jam 2011. Each winning team has been awarded the opportunity to showcase their game during Casual Connect Europe on Thursday, February 10, 2011 in Hamburg, Germany and all-access passes to Casual Connect Europe and three nights of accommodation.
Submissions were judged based on the potential of their teams to create commercially viable projects and meet with publishers during Casual Connect Europe. Each Global Game Jam site was given the opportunity to nominate their very best project for the contest.
The Winners (in alphabetical order)
Death Pizza Turku, Finland
Sabastian Jakaus, Tatu-Pekka Saarinen, Arash John Sammander. [email]
Utrecht, The Netherlands
Jan Willem Nijman, Rami Ismail, Jonathan Barbosa Rutger Muller, Paul Veer, Laurens de Gier. How to Kill Pandas Pelitalo Outokumpu, Finland
Antti Piironen, Anssi Pehrman, Tuuka Rinkinen, Salla Hakko, Heikki Koljonen, Hannu-Pekka Rötkö, Lauri Salo, Juho-Petteri Yliuntinen, Lari Strand, Henry Härkönen, Sina Aho.
Johann Sebastian Joust! Copenhagen Game Collective
Douglas Wilson, Nils Deneken, Lau Korsgaard, Sebbe Selvig, Patrick Jarnveldt.
MeteorCrash Córdoba, Argentina
Ezequiel Soler, German A. Martin, Carla Soledad Corcoba.