Entertainment Forge was a Serbian-based one-man indie studio founded and run by Darko Peninger, the programmer and game designer. Darko later joined forces with Gilbert De Vera from the Philippines, the studio’s artist who also shares game designing duties. They’ve recently launched their second game for PC, How Smart Are You?, where the player happens to land on a planet with some intelligent civilization whose history arises as the visitor solves their puzzles in a pyramid. At the same time, the player’s IQ is being measured for some reason… Darko, with help from Gilbert, explains how they got to working together and how they’re going to conquer the world.
Darko Peninger, the founder of Entertainment Forge
First Choice: Less Money, More Work
I started working on my game-making career as soon as I finished high school on the 1st of July 2011, though I should have totally left school and started earlier! Back then, I didn’t know much about game design, knew almost nothing about programming, but had a big passion for making games - as I still do! So I just thought out and did everything myself, including artwork. Oh boy, was I bad in art! In about a year and a half, I made a game called Mystery IQ Test. It was my first game that got sponsored.
“Oh boy, I was bad at art!”
I got two sponsors fighting over the game. One offered more money, and the other one promised less money and some additional work. So, logically, I chose the latter! It was actually a good decision, because this is when I met Gilbert. The chosen sponsor from Yepi, Roy Tzayag, suggested paying an artist and working together to make the game even better. This could have been a valuable experience for a newbie, so I decided to give it a try.
Improved graphics by Gilbert
Since then, the story goes on around a new game with a similar idea, called How Smart Are You? and presented at the Indie Prize Showcase at Casual Connect Europe 2014.
From Call Center Trainer to Game Artist
Gilbert De Vera has been a game artist since 2010. He started it as a part-time job, while still working as a trainer in a call center of a company.
In 2011, Gilbert quit his day job and became a full-time game artist.
“Like everyone else who’s starting a new job, I didn’t have all the things I needed to make art: no tablet, printer, scanner and not even a good computer,” Gilbert explains. “I used my camera and took photos of my art in paper, and then transferred them to the computer for digital coloring. What is more, I was using a crappy old PC. That was really hard, but turned out a great challenge.”
“In 2011, I quit my day job and became a full-time game artist,” he recalls. “I’ve worked with different clients, garnered a lot of experience in game development and finished plenty of games. One of them was a game made by Darko. A client who happened to be his sponsor asked for help to improve the game’s visual aesthetics. After we finished that project, Darko planned to create a sequel to the game he made first. And How Smart Are You? appeared.”
Puzzles Make a Game Fun, Even With Little Mechanics
The game’s puzzles were designed with the help of my friends. They used to come to my place or we just sat in the park brainstorming puzzles. There were at least 200 ideas, but I picked the 40 I found most suitable for the game. Many of these still didn’t appear to be good enough, so only 30 ended up in the latest version of How Smart Are You?. I think figuring out puzzles was the hardest thing, cause the game itself doesn’t have much of a mechanic. And then Gilbert joined the team to do his magic and make art! We started creating games together with a 50/50 percentage deal.
There were at least 200 ideas of puzzles, and only 30 ended up in the game.
“I didn’t have any problem doing art on this game, since Darko explained all the details he needed pretty well,” Gilbert says. “At the start of the project, I always ask what kind of character is needed, to make sure to create two or more so that there’s a choice. Darko told me to draw a spaceman that looks like a human, while it’s actually an alien. There is a puzzle room where the character needs to put boxes behind an X-ray machine to see what’s inside. It also shows the character’s skeleton that should resemble a human one. This is the tricky part: making players believe that the character behind the spaceman suit is a human being.”
“Darko told me to create a spaceman that looks like a human, while it’s actually an alien,” Gilbert recalls.
This is the tricky part: making players believe that the character behind the spaceman suit is a human being.
“The best experience for me is when a player loves the game so much that we receive fan mail and good feedback,” the artist confesses.
“Sometimes we disagree about the design, but the good thing is that we respect each other’s opinion, value each other’s reasons, and eventually end up using the best version (that are mostly my suggestions),” Gilbert says. “But I really commend Darko for being one of the fastest coders I’ve worked with (or maybe I’m really that slow).”
“It took us almost 2 months to finish the game,” Gilbert recalls. “The main challenge for me was keeping up with Darko’s deadlines! Since I was working for several projects back then, my attention was split, and I wasn’t doing things fast enough. However, I learned one thing here: better to do one project at a time and focus on it, in order to finish it much faster. Never really expected that Darko and I will continue doing games in the future, but I really admired his efforts on finishing a project, and that’s why I suggested to him to make more games together.”
Currently, we’re working on smaller games to get more experience and build up some budget - Physics, Launcher, Action/Adventure games for Web (and planning to go mobile soon) platforms. We’ve noticed that making a small but fast to finish game is the safe way to earn money in this line of business. Risk is much lower compared to creating a game that we could finish in a few months.
Darko’s goal: to make awesome games that will rule the world
Plans: Rule the World and Beat Bill Gates’ Fortune
I have plans for bigger games (most likely web and mobile). From the very beginning, my goal was to make awesome games that will rule the world (Muahaha!!). To be serious, it’s creating really engaging and meaningful game experiences for players. And I will accomplish these goals, cause I strongly believe that I can and will give everything I’ve got to achieve them!
Gilbert wants to top Bill Gates’ fortune
“My future plan is to top Bill Gates fortune and be able to donate half of it to charity,” Gilbert smiles. “Kidding aside, my real plan is just to top Bill Gates fortune.”
Right now, How Smart Are You? is available for web only. In the meantime, Darko and Gilbert are thinking of some new games, both similar to the previous one, but, at the same time, totally different.
Team Pesky is a British game studio based in York, founded by Andy Gibson in 2012. Their first game Little Acorns was picked up by Chillingo for iOS, then got featured by Apple and went on to hit Windows Phone, Xbox Indie, Sony Vita and Xperia, and Nintendo 3DS. A few years ago, Andy came up with an idea of Kraken Sleepeth - something he wanted to play as much as to make. He shares the story of creation of his second game, where the player submerges into the deep seas to discover the awful forgotten secret. As he goes deeper, the lights go down, and he has to fight evil creatures on the way to the final discovery…
Community Creation Before Release
This whole idea started because I wanted to create something with a core mechanic of torch-lit shooting, a feeling of exploration in a period setting, and Hammer House of Horror aesthetic. A tester described it as “Jules Verne meets Lunar Lander,” which feels about right.
The success of Little Acorns allowed me this chance to make a small, polished, original game – very much the mantra of Team Pesky. I wanted to experiment with a game that could be quite short in length but very replayable and extensible with updated versions. I also wanted to try building a community before release, engaging with players and exploiting the successful elements of the game. By showing Kraken Sleepeth at conferences like Casual Connect and IGF, at local game stores, and to friends and colleagues, I’m constantly testing the game for that elusive ‘just one more go’ factor.
By showing Kraken Sleepeth at conferences like Casual Connect and IGF, I’m constantly testing the game for that elusive ‘just one more go’ factor.
Tools like TestFlight and Dropbox and sites like Kongregate allow quick and easy focus testing. After the alpha, I’ll be using third party QA, and all these elements improve not just stability, but the overall experience for the player. I’d like to actually start a public forum to seed clues and hints for the game, building the myths around the games central premise with hooks into the game itself.
Development with the simplest prototype started around August last year. The procedural level creation came together quickly. I added the torch light slowly depleting, but as soon as I made enemies suck the battery power with their touch, I felt like the ‘heart’ of the game was beating. Kraken Sleepeth was a little more than core controls, a few key features and art direction, but showing it around publishers, other developers and studios brought positive initial reactions, and I felt encouraged to make the game. The most common reaction was “I love the atmosphere!” followed by “the controls feel really good”, and then the inevitable “…but it’s way too hard!”.
Separating the First Flush of Excitement from Evaluating Risks and Work Amounts
That initial excitement and drive needs to carry everyone involved through to release. But it’s a natural part of the creative process to trim, rationalize, iterate, test theories, and have random ideas in the middle of the night. Taking a reductive approach results in a leaner, more focused experience.
The current result is very much in line with the original direction, but the feature set developed as the project went on.
So if an idea doesn’t work out, it is removed. For instance, I had ideas about the Professor’s sanity being shown in some kind of meter, camera cuts and pans, and lots of left-field stuff. None of these were ‘bad’ ideas per se. In fact, I still have them noted in my version 2.0 list. The current result is very much in line with the original direction, but the feature set developed as the project went on. Rationalizing my initial ‘brain dump’ of ideas has never been a strength, but I’ve learned to separate that first flush of excitement from the second step of evaluating features in terms of risk and work. The aim is to balance wild creativity with getting a project finished whilst fulfilling its potential. This is where agile independent developers can run rings around larger studios. This is where I want Team Pesky to be, chasing that line, making original games quickly and efficiently. That’s our best chance of commercial success to support making more games. The intention is to continue that approach to develop future versions through a more open-ended process.
Do Not Undervalue Sound
The best games are that perfect mix of interaction, mechanic, and theme – all working together in the moment. Audio is often undervalued and I always placeholder music and sound from day one. Beyond contextual information, they add so much to the ‘vibe’.
We used three levels of tension: an initial exploring theme which escalates to the main theme, and then a third section for level climaxes.
An initial exploring theme escalates to the main theme, and then a third section for level climaxes.
Having worked with Ben McCullough previously, I contacted him to ask if he’d be interested in coming on board with Kraken Sleepeth. His music brings such a ‘movie feel’ to the game that I can’t imagine Kraken Sleepeth without it. We used three levels of tension: an initial exploring theme which escalates to the main theme, and then a third section for level climaxes. The themes vary over the game and really add a lot of flavor as the player progresses.
Every Aspect Inspires Another
While coding, I can get an idea about music, so I quickly note it down without following the distraction. Working on particle effects inspired a new enemy behavior, as it reminded me of pictures of plankton. The association made me think of a predator darting out of rocks.
Music can influence animation phrasing, platform budgets push new ways to visual fidelity, enemy designs inspire sound effects.
Every idea gets noted, then later I go back and rationalize them, consider how much work is involved, where the risks are, then pick the quick wins and the things I’ll get the most return from. In this way, music can influence animation phrasing, platform budgets push new ways to visual fidelity, enemy designs inspire sound effects. Every aspect of the game supports another.
Remember the Data
While working in another studio, I watched a focus group test where a designer screamed “You’re not supposed to play it like that!” as he watched the frustrated players.
Focus groups provide useful insights. But only metrics give you the thousand of bits of raw data to capture patterns and trends.
Focus groups can provide useful insights: do players know where the fun is? What are they reacting to? When do they stop playing and, critically, why? But only metrics give you the thousand of bits of raw data to capture patterns and trends. We built in analytics pre-beta, and they provide critical data for planning subsequent versions. The amount of analytics we get pre-launch is not enough to make specific changes, but post-launch, they influence balancing, etc. in subsequent releases.
If the player particularly enjoys one aspect, we need to fully exploit that.
Also, showing and sharing regular builds keeps the momentum going. These sessions can be done remotely, but it’s best to do it in person. Recording each play-through should be done and all criticism is welcome. Suggestions are considered in the context of the game direction. If the player particularly enjoys one aspect, we need to fully exploit that. For example, the game is essentially a shooter, and players enjoy the narrow passages and route choices, so I built more of these sections. They give the game a change of pace and an additional challenge. One passing comment from a player led to an addition of a small ‘servant’ that appears later in the game. For relatively little work, the little chap adds a lot of appeal!
Missions According to Players’ Preference
At its heart, Kraken Sleepeth is a twin-stick shooter, so, if the shooting is not fun, the game has failed. One of the biggest challenges of making the game has been fighting the urge to end the game on a climax. Instead, I wanted to encourage a sense of exploration, which may contradicts the central shooter theme. The game polls how the player is progressing and players picking ‘kill monster’ missions have a higher chance of seeing more of those.
One of the biggest challenges of making the game has been fighting the urge to end the game on a climax.
Similarly, a player finishing more ‘collect these’ missions gets more of those. There’s always a choice, but I’d hope the game reacting will ultimately increase players’ enjoyment. I guess I’m asking players to have a little faith and trust they’ll be rewarded down the line.
Indie games: From Experiments to Polished and Rewarding Experiences
Making indie games should be experimental, while the aim should be releasing a polished, rewarding experience with the tease of something more. We’re taking risks developing and releasing Kraken Sleepeth, but an indie developer needs to take risks. Then it becomes a journey, shared between Professor Eldritch, the player, and the developer. And if players are enjoying the ride, Team Pesky will have succeeded.
An indie developer needs to take risks.
If the game absolutely bombs, I will still have learned lessons and hopefully get to make another independent project. I’m already designing another Little Acorns game, but don’t expect a simple sequel with just a few more levels. Taking risks keeps it fun. And fun is king.
Kraken Sleepeth will be available for Windows 8 in August 2014, supported by Microsoft and Creative England.
MildMania is a Turkey-based, self-funded game studio founded in May 2013 by Burkay Ozdemir and Emre Canbazoglu. Their first title Darklings barely made it in the end of November 2013. Making the game was “especially hard in Turkey, where the gaming industry is very small,” Emre recalls. Darklings is a mobile game with “truthfully” unique gameplay where light meets darkness like in epic tales. You control Lum, the face of light, to beat darkness and bring the light back to the Universe. Emre gives us the tale of making the game and beyond.
The Beginning: A Poster of a Games Incubator
It all started with Burkay seeing a poster of the only known (at the end of 2010) incubation centre focused mainly on games. He gathered two of his local friends to apply there. With that team, we submitted a project called Icons, a social board game totally unrelated to Darklings. That same year, Burkay got accepted to the Game Technologies Master Program, which I was also studying. For our term project, we submitted a game similar to the Harry Potter PC games (where you cast spells by drawing), and the Z-Type HTML5 game (where you write letters to blow up asteroids), with the difference that our game was mobile and perfectly adapted for touch screens.
Our team started to look for the right tools by joining all our experiences and getting help from friends
But before we could go on working on Icons in our first months with the new team at the incubation centre, there were some precautions to take care of. First of all, no one in the team had game development experience other than a couple of educational projects which were far from polished enough to be commercial games. So our team started to work on finding the right tools for the process by joining all our experiences and getting help from friends: professors at the program, fellow game development teams, and industry experts from the incubation center.
Later on, we put the project submitted to the centre on hold, and started working on a draw-to-kill game, since it felt like it could be finished in few months, under a temporary name of Monstiez.
A Break-Up for the Better
The ready prototype of Monstiez drew the attention of Chillingo and the Startup Turkey 2012 event. Our team was selected as one of the 15 best startups in Turkey, and we got a chance to talk to a lot of investors. Everything seemed to be going well. After we started working with Chillingo, we got a lot of advice on how to make the game better, and also changed the style to black and white - since Limbo and Contre Jour became pretty popular, getting sales and awards at that time.
We changed the style to black and white - since Limbo and Contre Jour became pretty popular, getting sales and awards at that time.
However, after some time, the development process got stuck, because everyone around thought that the game was too monotonous and shallow. As the whole design started to change too frequently, moving forward became frustrating. That and some other things brought the team to the verge of splitting. We weren’t able to work together anymore, and our points of view seemed too different. After long discussions, the team came to a total disagreement, and the break-up was inevitable. The designer decided to leave and take all of his visuals.
However, Burkay and I didn’t give up on the game. We were the ones keeping faith in the idea from the beginning, believing it had the potential of making a huge difference in the market. We tried to learn from our mistakes and not follow the (seemingly) wrong path again. One last time, we started to design the game, thinking everything twice to make sure the new edition was much better.
We didn’t give up on the game. We were the ones keeping faith in the idea from the beginning
We found Juan Pablo Casini for art and visual design and David Stanton for music and sound. What is more, we founded MildMania LLC and worked with Contrast8 to create our corporate identity. As a result, decisions were made much faster than before. It was all exhausting, but we were finally enjoying what we were doing, just like in the beginning.
Teamwork is Business, Friendship and a Relationship with Girlfriend/Boyfriend
One big mistake we made was sticking too much to certain people and the number of team members, and believing issues can be solved and we could go on working as the same team without any problems. Since we started with three people, we had the feeling we should still finish the game with three people.
The game might have been released earlier if all decisions were made right in the beginning
Splitting up is not easy for anyone. But looking back at it now, we see things going much better: from external relationships, connections, important or trivial decisions, and people we have worked with, to satisfaction we get from the results of our work. We understood we could have released the game much sooner and better-planned if we decided to break up and make it with our current designers earlier.
Every company should find out whether they’re able to get along with their partners and work together seamlessly.
This is how we learned that every company should find out whether they’re able to get along with their partners and work together seamlessly, without making every small thing a problem. Any individual should ask themselves if his/her vision or expectations is the same as his/her partners’. This is not just business or friendship, it’s a bit of both, and very similar to the relationship with your girl/boyfriend. 🙂
How to Protect Your Game From Getting Lost in the AppStore
For nine months, we worked with three designers, one audio designer, and two programmers. Three people in this team were freelancers we had been working with for a long time, which meant a relationship good enough to (if necessary) move in an office together and go on working from scratch: from corporate identity and new names to the game visuals. The main reason behind redesigning was not just the break-up, but ultimately the quality: we saw it needs to be much higher than before. We’ve worked with our team members and other people from the industry to modify and change the game to meet the expectations of AppStore users.
We tried to learn from our mistakes and not follow the wrong path again.
While the cost of eight months of redesigning might seem too much for a casual game, we couldn’t let it get lost in the ocean of thousands of apps after sacrificing so much to the project.
Testing Results May Lead to Complete Redesigning
We believe that we made Darklings more enjoyable by adding a lot of content (environment setups, tactical boss fights, objectives and achievements), customization options, and modifying the gameplay mechanics. Testing involved hundreds of people, including development, design, and business managers throughout the world. We performed all tests using TestFlight and beta test subscriptions that were made available after the teaser was released. We invited all people who showed interest to the game, and also our friends from Turkey, who are both game developers and gamers. Hundreds of people from lots of countries have contributed, and we also added an in-game feedback receiver along with some analytics to get all data possible. Darklings right now is nothing like the game we had been working on for a year and a half. All collected feedback helped us fix a lot of bugs.
UI redesigned from scratch: we made a unique fight for each boss
For instance, the UI happened not to work well with mobile phones - some buttons were too small, and players got bored from boss fights. So the latter was redesigned from scratch: we made a unique fight for each boss.
Instead of Getting Sucked into a Public Argument, We Tried to Focus on the Product
We planned the launch date for the 27th of November. After such a long time of waiting and development, we just couldn’t wait to see Darklings in the AppStore, and were very excited to get our first app published, to see “Ready For Sale” instead of test builds. 🙂
We couldn’t wait to see Darklings in the AppStore
But publishers were cautious towards us, considering the project too risky because our team split up before the game was published, and there was a blaming campaign held both publicly and privately by our former designer who was utterly speculating twisted stories and unfair things to stain the name of the game and company. We didn’t really react: instead of getting sucked into a public argument, we tried to focus on the product. Being sure that almost all stories from our old designer were lies, we could go to court and fight for our rights, but that would take years to accomplish. So, instead, we focused and got a different reward: the launch day and the day after. Both were amazing! Darklings was featured in US and Canada AppStore! Forum threads were being started by other people, great reviews came from media, and we received tons of support mails we instantly answered. Watching the Darklings spread over the world was a part of our dream, coming true at long last!
The Brand of Darklings Started Building Itself
Unexpectedly, self-publishing brought us to the new seas. Just a week before the game got to the AppStore, we met with Ajay Chadha, the founder of B27, and agreed to join efforts with them. It wasn’t a publishing deal, more like that of business development and marketing for US and Europe. It helped us self-publish the way we wanted.
Our brand started building up by itself
With additional help from Ajay, we started some really good relationships in the industry, getting recognized for both the quality of our game and our friendship with B27. Our brand started building up by itself. As of now, we’ve made an agreement with Unity Tech Japan and Kakehashi Games for Japanese local publishing, Joygame - for Turkey and MENA publishing, and we’re still negotiating about moving on to the Korean, Chinese, and other markets. We’re also trying to raise some money to grow the team and work on parallel projects without losing quality, and this is where our good relations with investors from the whole world can be useful.
The amount of work has nearly doubled after launch. We’ve discovered that what you do afterwards also matters in making the product successful. A whole different world is there behind the gates of development, and we’re trying to adapt ourselves to it while having a lot of fun.
A whole different world is there behind the gates of development
The business side of the industry, making relations, finding local publishers, giving interviews, getting reviews from press, seeing the game loved by industry veterans, planning the business a year ahead to make the game bigger and stronger – all this is new to us, since we were so focused on development before! Even though the creation process was a total headache, I believe we have proven ourselves that if we managed to enter this industry, we’ll make even better products in the future.
The amount of work has nearly doubled after the launch of Darklings
Right now, we are about to announce Season 2 of Darklings, which could actually be Darklings 2. But we decided to make it as an update because the game is only three months old. On the other hand – it’s something different to the core! This means we’re not going to throw this game to the attic, and will make sure that Darklings is fulfilling its potential.
Darklings is now available in the iOS AppStore. It’s going to be released on Google Play, Samsung Apps, Amazon, LeapMotion and for PC & Mac. The MildMania team says they have more surprises in their pocket, including exclusive releases and new titles, which they will announce soon!
Tunnel Vision Games consists of five students from Aalborg University in Denmark: Benjamin Nicholas Overgaard, Gustav Dahl, Lasse von Fintel Sostack, Mathias Klitgaard Berthelsen and Philip Hundevad Nymann. They created See You On The Other Side as a project for the fifth semester on the Bachelor’s program in Medialogy in Fall 2013. It’s a 3D first-person puzzle game where lights and shadows are used as the main game mechanics. Gustav Dahl tells us about how to do a successful scientific project and an original game at the same time.
Medialogy is an education only few have heard about. As the name suggests, we learn about media and technology in all kinds of ways. Basically, there is a little about all elements that can be related to media and computers: programming, 3D, sound, film, interaction design, electronics, etc. Another way to describe Medialogy is that we are geeks with humane skills, i.e. we know how to implement systems, but also focus on how people use and interact with these systems. In other words, we are perfect candidates for game designers.
The player has to escape a gloomy prison/asylum.
A Real Game Without Particular Hardware
Medialogy isn’t game education, but many students eventually opt for game development in one way or another. Unlike other universities in Denmark, Aalborg University has a big focus on project and group work. Each semester, we get to make a project based around a certain theme. This time it was Audio-Visual Experiments — Interactive Experiences. The theme was very broad, which meant that we could happily take it in any direction we liked, and we wanted to create a game!
During previous semesters, we had worked on games in various forms. But many, if not all, consisted of some kind of gimmick: a game that uses Arduino boards; an educational game with Kinect; a game that uses sound as the input device, etc. While in the project that later turned into See You On The Other Side, we were the five students who found each other and set the goal of creating a “real”, full-fledged game that didn’t require any special hardware. Why, you ask? Simply because we wanted to show the game to our friends and family afterwards, something we couldn’t do with previous projects due to the specific hardware requirements.
Challenge: A Game That Needs to be Science
The main dilemma was that we simply wanted to create a cool game, but, since we are university students, that game had to investigate some kind of problem in a scientific way. Mathias reminded us about a 2D indie game called Closure. Its premise is that the protagonist can only walk on and interact with objects that are in light. If things are in darkness, they simply don’t exist. Since we had courses about light and computer graphics rendering, we thought this was a really cool idea to explore.
We took inspiration from the 2D game Closure.
Besides creating a game and being scientific about it, we also wanted to learn more about 3D modelling and shader programming. We had the latter in a course, while 3D modelling was something all of us have always struggled with. So we decided to take the premise of Closure and turn it 3D. This would introduce not only the light-dark mechanic, but a 3D perspective as well.
Breaking Pre-established Mental Models
Then came the chicken-and-egg problem: it is required that all projects work from a problem statement: something in the world/society that you want to solve/change. However, we just wanted to create an awesome game. Usually, you first define your problem, then find the solution. We did the opposite, having the game concept in mind and then trying to come up with some kind of problem related to that.
We defined our game as a puzzle with unique rules, and this led to a problem statement hint: how to design a game universe where rules are different from what you expect from the real world (e.g. how lights and shadows work). We wanted to explore both level design and puzzle design, to see if it’s possible to break the player’s pre-established mental models about how lights and shadows work in games.
Early sketch showing the concept.
In the end, we came up with the following problem statement for our project: “We assume a 3D game universe with some core rules: in this world, you – the player – don’t collide with unlit parts of surfaces, and you don’t cast a shadow. Do players who are not told the rules understand it just as well (or better) than those who are told the rules in the beginning of the game? Do they enjoy the game more or less if they are not told the rules in the beginning?
Making Puzzles is Harder Than You Think
While working on the project, the group was reading Game Design Workshop: A Playcentric Approach to Creating Innovative Games by Tracy Fullerton. It focuses on iterative game design and prototyping. Therefore, we started making small paper prototypes to see what kinds of puzzles we could create with the light-shadow mechanic. It was a fun experience, but also harder than we expected. We thought we could easily make dozens of puzzles very quickly. However, it turned out that creating puzzles is way harder and time-consuming.
Many paper prototypes were made to test the puzzle design.
The Prison Escape
But our creation at this stage was still a very neutral puzzle game, without any proper context/theme.
Eventually, we understood that the big focus on puzzles didn’t suit our goals. Instead, we started thinking more about how our game should look and feel. This is how the premise about a prison escape appeared. Having a context made it much easier to start designing levels. We now had a basic idea for a simple narrative, and, unlike before, the levels were not isolated from each other, but gained a logical transition from one to another.
Moving lights could be a “twitch” puzzle.
Unity Engine and Hatching-Style Art
We settled with the already familiar Unity game engine and its built-in first-person controller, and then the group split duties: some were looking into the light-shadow mechanic, while others were learning how to create 3D models in Maya.
The initial idea was to have a binary art style.
We were studying computer rendering, which wasn’t directly related to the game project, but for that class, we had to work on a mini project to make use of the new knowledge. In the beginning, we were talking about how cool it would be to have a black & white art style similar to The Unfinished Swan. However, it turned out that this binary style made navigation in a 3D environment very difficult. Then our teacher Klaus Madsen came with a book called Real-Time Rendering (Tomas Akenine-Moller, et al.) that described a non-photorealistic rendering style called hatching. He suggested trying it, and we thought - why not? With the help from Martin Kraus, our supervisor for the project and a super awesome Unity and shader programmer, we started trying to implement the hatching shader in See You On The Other Side.
Depending on the amount of light, we blend between multiple hatching textures.
Basically, what the shader does is make everything look hand-drawn. It’s achieved through a post-processing effect on the camera that interpolates through a collection of hatching textures. The more lit an object is, the less strokes it will have (appearing white), while objects in shadow will have more strokes (and thereby appear darker).
To our big surprise, the hatching style made the game look much more interesting and less generic. You probably recognize the “Unity feel” that many games have, mainly because people use the same standard shaders. We were really happy to have created something that stands out.
The More We Removed, The Better it Became
The university encourages us to test early and often. This helped us streamline the levels and make them easier to understand for players. We found out that the more we removed from the game, the better it became. This might sound counter-intuitive, but we discovered that many of the small details and props just drew attention away from the core experience. Therefore, we focused on the most significant elements in the game, so many of our previous 3D models were scrapped.
The player starts in an isolated prison cell.
Enjoyment and Understanding Doesn’t Depend on Rules
James Gee in his book called What Video Games Have to Teach Us about Learning and Literacy lists some guidelines that good games should follow. Inspired by his work, the first level was designed as an isolated prison cell room. Only when the player understands the concept of shadows, i.e. that he can walk through surfaces that are in a shadow, can he escape and get to the prison hallway.
However, it turned out that some people just didn’t get the concept of walking into shadows, so a hint system was implemented where small signs would show up after some time to suggest what to do next. We think this is an elegant solution, since the signs never give the answer directly, but just point to what to do.
Signs pop up after some time to give a hint of what to do next.
Lessons from this experience: test early, and test often. Also, be aware of what you are testing: is it the game mechanic, the level design, pacing, difficulty, or something else?
We ended up with 30 test participants, where half have been told the rules in the beginning (as said in the problem statement), and the other half just played the game without any introduction. It turned out that there wasn’t a significant difference in either player’s enjoyment nor understanding of the game.
The Power of Reddit Virality
In Medialogy projects you are required to do AV production. It’s a video showing and summarizing the results you’ve gathered. However, we wanted to make a more traditional movie-like trailer that would motivate people to try out the game. So we made two videos: the one in the beginning of this article, and a full playthrough showing two people playing the game side by side for comparision. The latter was not so interesting to look at, but it revealed the differences in playstyles when the rules were provided/not provided in the beginning. After we uploaded the first video to YouTube and shared it with friends and family, we thought it would be cool to put it on Reddit. None of us has much experience with Reddit, but we decided to try and see where it goes. You often hear about games going viral thanks to Reddit … maybe the same thing could happen to us?
You often hear about games going viral thanks to Reddit. Maybe the same thing could happen to us?
I put a link to the game’s trailer on Reddit and asked the rest of my group members to upvote it. Later that evening, when we were writing our report, we got contacted by a game journalist from the Danish website Gameplay-Online. He saw our creation and wondered if we would like to participate in an interview. Of course we said yes! A few hours later, a really nice article about our game appeared.
Things started to snowball. IndieStatik wrote about the game, and people began posting Let’s Play videos on YouTube. We didn’t even ask them to do so, they just did because they saw the game on Reddit and thought it looked cool!
One of these Let’s Plays, created by RockLeeSmile, has over 4000 views! This is pretty amazing if you keep in mind that we didn’t expect anything like this AT ALL. We knew we created something to be proud of, but couldn’t even imagine we would ever receive so much exposure on the Internet. Besides this, one of the group members got the chance to travel to Germany and present the game at a storytelling workshop.
One of the group members went to Germany to talk about the game.
Today, we count more than ten Let’s Play videos on YouTube, as well as multiple posts on indie game websites. When you have zero expectations, this is a lot!
Visuals (and Being Free) Do Sell a Game
I think the main reason why See You On The Other Side got so popular is that we put it online for free. We’ve never thought of taking money for the game (how could we, it’s just a university project!), and apparently this approach helped breaking down the entry barrier for a lot of people.
The game has spawned many Let’s Play videos on YouTube.
The only thing I regret is that my website didn’t count the number of downloads, so we have no idea of how many have actually downloaded the game. Later, I installed a plugin that counts downloads, but the initial download peaks have long surpassed.
People praise the game for its unique mechanic and especially the hatching art style. To us, it was more of a coincidence, but to everybody else, the art became the defining element for the game. Visuals do indeed sell a game.
Despite the fact that the game is quite short (10 – 20 minutes of gameplay), most people seem to enjoy See You On The Other Side a lot. They ask if we are going to take it further and develop more on it. As for us, we really don’t know.
Four of the five group members. Sadly, one of the members had to leave early that day.
We’ll be like Marcus “Notch” Persson
Anyway, we wouldn’t be graded for how good the game itself is - we’re to be judged for how we approached and tested our problem statement. Luckily, the exam went well. Everybody from the group received A’s. The censors considered our game concept interesting, and, even though there were many things we could have done better from an academic point of view, we were able to present arguments for how and why we tested the way we did.
However, during the last part of the exam, we were asked whether we’ve heard about something called “the rockstar syndrome.
However, during the last part of the exam, we were asked whether we’ve heard about something called “the rockstar syndrome”. As you can guess from the name, it’s when people start to have unrealistic thoughts about themselves, become cocky and overconfident about their skills. Of course, this was said tongue-in-cheek and as advice for our future careers. We then talked about how Markus “Notch” Persson handles his fame and fortune from Minecraft in a very humble way. If we ever become “real” rockstars, this is how we want to behave: stay close to the ground, make games because we love it, not because we want to be rich or famous.
See You On The Other Side was awarded as Most Innovative game at Casual Connect Amsterdam 2014 Indie Showcase
At Casual Connect Europe 2014’s Indie Prize Showcase in Amsterdam, See You On The Other Side was awarded as the Most Innovative Game. The game is currently available for Windows only, and can be downloaded for free at Gustav’s site.
The MADFINGER team, founded in 2009 by four game industry veterans who were sick of the over-managed development process of big console and PC games, received a lot of praise for their mobile games Samurai and Shadowgun, and within two years, grew from four to thirteen members. Then in late 2011, they started thinking about a ‘side’ project, which MADFINGER could develop along with the planned multi-player game Shadowgun: DeadZone, to use to experiment with new features, technologies and gameplay ideas – or simply kill after some time, if it wasn’t viable. Petr Benysek, Senior Programmer, talks about how the Dead Trigger project started as an experiment and where it went from there.
The Beginning
Since there weren’t enough people for two projects, Mara, Emeth, Babec and Robotom, the founders of the company, decided to hire three more people, who could be fully dedicated to this new project, along with Emeth, the graphic artist and project leader. We are all long-time friends and have worked together in the past, so it didn’t take me a lot of thinking to take this opportunity and join the team in February 2012, along with two coders: Tomas Stepanek and Martin Capousek. Since we joined MADFINGER right after finishing a big console project, the first thing we actually did was to go on holiday. You can hardly be creative and fast when you are tired, and fortunately, MADFINGER is a company where people know this (we all have seen the results of infinite crunch too many times). There were several goals that this yet-to-be-born project should try to achieve:
o To serve as a training ground for the three of us, who already had a long history with games development, but not with mobile platforms and the Unity engine.
o To experiment with short and quick missions, as opposed to the huge areas and story-driven gameplay that we had been used to.
o To explore the new field of In-App purchases.
o To develop new technologies, such as cloud service and social network integration.
We had a time budget of 3-4 months to finish it. Coming from a ‘triple-A’ industry, I saw this as a joke more than a serious plan. Just imagine having to master the new engine, get familiar with C# (which none of us was seriously using before), create a completely new game and publish it on two platforms we didn’t have any experience with! But Mara’s answer was just: “Don’t worry, you’ll make it.”
Fortunately, we could stand on the shoulders of the Giants. We got support from Babec, the character artist, Robotom, the sound engineer and Ondra, the animator. We also got the full range of MADFINGER’s talent at our disposal for the last month before the initial release, and the entire team stayed onboard for few more weeks after the release to help us with our first updates. We were able to draw from the extensive knowledge the other team members already possessed of Unity and iOS/Android platforms. That way, we wouldn’t have to spend more than a few minutes looking for an answer to our questions. Mara was also able to take the code base from Shadowgun and establish the roots of the project, with the game’s framework and some tools. Of course, I also have to mention the Unity engine itself. I’m still blown away by how fast you can iterate, how easy and intuitive it is to extend and to add new things. Working with complete and satisfactory technology is essential when you want to make things fast and well.
The first thing we actually did was to go on holiday
The Design Decisions
We had neither much time or people at our disposal, so we had to be wise with our decisions. What kind of theme would it have? Zombies, of course! People like them, it’s positively necessary to mow them down and they don’t need to be super-intelligent, so you can spend less time debugging your AI. What about mission size? That had to be small, of course. Small missions can be created or redesigned quickly, and you can stuff them into the memory without the need to stream. As for gameplay, we went with several gameplay modes plus generated missions, with the possibility to have scripted story missions. Players should level up as well as the enemies and be able to unlock new game content.
People love zombies!
Next step: story. Having one would be nice! So we ended up with our apocalyptic version of the events of the apocalyptic year 2012, creating the Dead Trigger story. For the main menu, we chose to have a city map, which would allow us to connect the missions, story, shop, equip menu and other areas that the player could visit. It’s clear and expandable. As for the devices it should be played on: anything that will have enough memory and power to render our environments with six zombies spawned at the same time. After some tests, it turned out that we could run it on the iPod 4 Touch and comparable Android devices if we used lower level detail models, environments and shaders. We also created an ultra high-end version for the Tegra 3 and the newest iOS devices.
Small missions can be created or redesigned quickly.
Cuts, Redesigns…?
One of the great things of the Dead Trigger project was that nobody was forcing us to do anything. It was all up to the few people determining the direction of the game to discuss and decide what we were going to make. There were no publishers with their “amazingly cool ideas” that we had to implement, no producers trying to stuff ideas from other games that they just played into our game, no management guys cutting things they didn’t believe in, no design documents (that usually become obsolete as soon as you finish what’s in them). There were no designers, we all were designing the game with the passion of those who have the freedom to create what they wanted. For this reason, there was very little to cut or redesign and most of it was done on paper, before we even touched our keyboards or other input devices. For every considered feature the first criterion was: can we make it on time? If so, is it worth the effort, compared to other features?
“Knowing the limits, we wanted to achieve a scalable building set, composed of a game core that can be extended with any number of missions, types of gameplay, enemies, weapons and so on.”
With this simple approach, we’ve selected the most wanted features for the first release and left the others in our backlog for future updates. Knowing the limits, we wanted to achieve a scalable building set, composed of a game core that can be extended with any number of missions, types of gameplay, enemies, weapons and so on. We also wanted to re-use our environments as much as possible, so we created a system for defining spawn zones, gates, objects, enemies and objectives. On top of that, we created a data-driven game flow manager which generalizes the randomized missions and provides scripted story missions based on the player’s rank. In our first release, we had four different types of gameplay and just four maps. With that, we were able to generate over 60 unique gameplay configurations, which resulted in about 10 hours of fun.
…no management guys cutting things they didn’t believe in…
Release
As we were approaching the end of our four month deadline, the game was shaping up and it became apparent that it really is possible to finish and release a solid product within that timeframe. Still, we had a lot left to do, and we knew that some really cool things would probably have to wait until future updates, so the company decided to pause other development and allocated everybody to Dead Trigger for the last push. It was a huge help, because they contributed with new content, by polishing existing stuff and also by testing (it’s always a good idea to ask your friends’ opinions, since you will lose your objectivity after some time).
Paymium vs. Free2Play
One of the last things to decide was the business model. We definitely wanted to make the game very user friendly and affordable for everybody (we really disgust pumping hundreds of bucks out of players for virtual goods as some other games do), so the prices in the game were set fairly low, and we paid a lot of attention to balancing the game. That way, it’s playable without the need to spend money, while keeping it interesting for those who want to enjoy the game even more with premium weapons and gadgets. In the end, we set the price at $0.99, keeping the option to raise the price after release or to change it to a Free2Play model.
“Nearly all aspects of the game, as well as the price, blew people away.”
After four and a half months of development, full of expectations, we hit the release button and went to a pub to celebrate! We already had a few beers when the first player reviews started to appear and we finally knew that we did a good job, because all of them were fantastic! Nearly all aspects of the game, as well as the price, blew people away.
We finally knew that we did a good job
Mistakes Made, Lessons Learned
Although we’ve played it safe with most of our decisions, there were several areas that we had yet to explore, to learn how we could use them to our benefit and that of the player. One of those was In-App purchases. We’ve realized that some people didn’t expect them in the game (Dead Trigger was the first MADFINGER game with those) and were giving us one-star reviews just because of that. Unfortunately, somehow they didn’t realize that they could earn enough funds just by playing the game and don’t need to spend anything! Lesson learned: highlighting such facts clearly in advance should prevent any confusion.
“We realized that the game gets too hard for players who do not have any experience with First Person Shooters on phones or tablets.”
We’ve also recorded a significant drop in players after the first few missions, so after some research, we realized that the game gets too hard for players who do not have any experience with First Person Shooters on phones or tablets. Another lesson learned: make it even more casual in the beginning and slowly increase the difficulty. At the same time, provide harder difficulty missions for hard-core players. Related to that previous point is one of the things that we’ve omitted for our first release: the tutorial. It’s usually a pain in the ass to make, and most players skip it anyway, but it definitely helps the casual audience along, and there’s a lot of casual players on mobile platforms. Yet another lesson learned: to provide a tutorial even when you think everybody will understand your controls anyway.
Last but not least, we wanted to give players an easy way to contact us, so we added a mail form to the game (the Post building in the City). But we underestimated the number of players who would actually use it and moreover, didn’t expect so many (iOS) players to click “Send” rather than “Close” when they change their minds. The result was our mailbox getting spammed with hundreds of thousands of emails with just a preset signature in them - and some really important messages from players got lost (at least for week or two).
The Day After
The success of the Dead Trigger game exceeded all our expectations. The initial interest players took was amazing, and it only increased enormously a few weeks later when we decided to make the game free, relying just on the in-app purchases. Since then we’ve released around ten updates for each of the platforms, adding new content and improving the existing features in each of them.
Within nine months we’ve achieved seventeen million downloads (iOS +Android)
Within nine months we’ve achieved seventeen million downloads (iOS +Android), and even now have over fifty thousand daily installs and more than five hundred thousand daily active users. The game got several highly regarded awards, of which I should mention at least Unity’s Best Technical Achievement and Community Choice, Apple’s Hall Of Fame, Editor’s Choice or App Store’s Best of 2012 Showpiece Games, which we really, really value.
The game got several awards, including Editor’s Choice or App Store’s Best of 2012 Showpiece Games.
During the few weeks after the launch, all of us got back to work on Shadowgun: DeadZone (a great and challenging multi-player project), while revisiting Dead Trigger from time to time to work on updates.
MADFINGER Games successfully released Shadowgun: DeadZone back in November 2012 and right now are working on support for both Dead Trigger and Shadowgun: DeadZone, while also creating two new games; one of them being Dead Trigger 2.
Sergey Batishchev is an indie game developer and has been an enterprise Java developer and tech lead for more than 12 years. Still, games and game development have always been his hobby. After the successful launch of his Gluey game series, he is dedicating himself more on indie game development. Batishchev strives to make simple, polished and fun Flash and mobile games that appeal even to most casual gamers.
I spent many hours with my Watcom C++ compiler trying to code fire, fluid, and smoke
Gluey is a very simple action puzzle game. You just click the blobs, they disappear and you earn points. Large blob clusters give you bigger score bonuses. And, of course, it is seasoned with multiple levels, modes and power-ups. The idea for Gluey originated from an unusual source. Back in my university years, the demoscene was at its peak. I was amazed by the graphical effects in the demos and I wanted to learn how to do the same. So I spent many hours with my Watcom C++ compiler trying to code fire, fluid, and smoke.
Back in 2009, game development was purely a hobby for me. But one day I thought: Wouldn’t it be cool to create the simplest game possible, based purely on a rendering technique - like fire, liquid or particles? Surprisingly, no one made a match-3 or click group to clear-game with liquid blobs at that time! All other elements came quite naturally. I decided to use simple click group to clear-mechanics, as my friends really enjoyed games like that on their Windows 6.5 phones. It was also intuitive for the blobs to follow real physics, not just gridlines as in classic match-3. Within a couple of days, the prototype was finished. Although still in its early alpha-stages, the basic gameplay mechanic was already quite clear.
Still in its early alpha-stages, the basic gameplay mechanic was already quite clear.
Art was a weak point for my hobby games before Gluey. Psychologically it was hard for me to fork out real money to hire an artist and a musician. I first needed to prove to myself that my games could generate some revenue. In retrospect that was not very smart choice. If you are a part time indie, you really should treat your home game development just like other expensive hobbies that you enjoy!
Luckily my previous game Cyberhorde generated about $1.5K in primary and non-exclusive licenses, so I posted a job offer for art design for Gluey. Bogdan Ene responded very quickly. Within my tough budget constraints he managed to create compelling characters and nice visual style. The visual design was completely done in a matter of days; there was no need to send anything back for revisions. After that, it took me about 6 calendar weeks (working through the weekends and evenings) to complete the rest of the game, which included levels, power ups, bonuses and transition screens.
Sponsorship and Release
To this date, the viral version has generated 14 million views
Gluey attracted good attention from sponsors on FGL – 28 bids. I went with king.com for the primary sponsorship of this game. It was my first game with 5-digit primary offer and, to this day, my biggest success. The game met king.com’s expectations. It hit Kongregate and Newgrounds frontpages and spread quite well. To this date, the viral version has generated 14 million views. Unfortunately, ads were not allowed, but game did attract quite a lot of non-exclusive licensing offers.
What Went Right with Gluey
Being on a tight budget means you have limited possibilities. This […] pushed me to only focus on the important things
Being on a tight budget means you have limited possibilities. This turned out to be a positive thing: it pushed me to only focus on the important things. So the game was very light on content: only 16 levels, which calculates to about 20 minutes of gameplay (although some players replayed the game a lot). In retrospect, it was a good choice to limit the number of levels. If you don’t have time or money to add unique content, don’t just add same-looking levels. It is better to have people comment “Too short, needs more levels” on your game, than receiving comments like “Got bored on level 14”.
Another thing that went great was the way the blob mechanics felt. They were smooth, polished, and natural. If we compare them to actual droplets on a surface, we can see three core similarities:
All blobs leave a trail behind, as if they are sliding on the surface with traction.
Actual droplets cannot touch without merging. So blobs of different color repel from each other and from the edge to look natural.
Sharp boundary around blob stressed how blobs merge and break apart.
I resisted the temptation to make the gameplay time-bound, like a lot of other puzzle games. Adding a time constraint is the easiest way to add some challenge to an action puzzle. However, players liked the fact that they had to act timely so that blobs structures do not slide apart. They felt smart for inventing this technique, instead of being forced to it by a timer. They also liked the fact that after a short burst of clicks, they were able to relax for some time and figure out the next move, instead of being bugged by the ticking clock.
What Went Wrong with Gluey
It looks like the sweet spot for a casual Flash puzzle is 30-45 minutes
Despite all the good things about Gluey, it was still a bit short. It looks like the sweet spot for a casual Flash puzzle is 30-45 minutes. Many players complained the game ended too abruptly, and down-voted the game for that reason. Yes, Gluey did feature the unlockable Zen mode. But this mode did not match the players’ expectations. The idea for the Zen mode was that for each cluster of n blobs, you get n-1 blobs back. So a Zen game ended pretty quickly (gameplay lasting only 2-3 minutes) and did not feel as an endless survival challenge.
Completing levels in Gluey was based on a simple and quite artificial premise: Earn score x to complete the level. Once you got to score x, your only motivation is reaching the top of the highscore table, which is not a very strong motivation. The game did not have any stars to rate the players’ performance on some level.
The most embarrassing issue was the very large score/bonus floating messages that blocked the gameplay and prevented the player from acting quickly and basically playing the game in itself.
The sequel: Gluey 2!
As Gluey 1 was a success, I decided to go indie full time and started working on Gluey 2. The sequel was a much longer project (9 months compared to 6 weeks). I wanted to add lots of power-ups and polish every detail. Besides, I wanted to address the common complaint about “reach score x” as meaningless goal. The main mode of Gluey 2 was to survive the flow of blobs, a bit like a Tetris.
I was happy with the art of Gluey 1, but I felt I had to make the sequel totally fresh and new. So the game visuals were also redesigned from scratch! RetroStyleGames did a great job at keeping the game’s atmosphere, but making it look even more smooth and polished.
The banjo music track for Gluey 1 was very fun and recognizable, but probably a bit too sharp and repeatable for a casual game that you play often. People tend to either love it or hate it. Francesco D’Andrea created a much more subtle music track for Gluey 2.
Overdoing and Overthinking
The many changes disappointed the fans
Gluey 2 did okay when it was released. The primary license price tag was roughly the same as for Gluey 1 and the game attracted a lot of non-exclusive license requests. But the game did suffer a lot from overdoing and overthinking! In fact, the many changes disappointed the fans. Many claimed that the new gameplay was mindless arcade; they missed their clean and simple “Get score X” puzzles. Many people even wanted the stock banjo sound track back from Gluey 1, which quite a few players originally disliked and characterized as too sharp and distracting.
The new gameplay turned out to be creative, but very counterintuitive! When the blob flow comes, your first instinct is to click as fast as you can. But that’s exactly what you should not do in Gluey 2. Instead you have to carefully create huge clusters of blobs to save on the number of clicks you make. Numerous people left the game frustrated for this reason.
However, both Gluey 1 and Gluey 2 were successes for me. The total revenue from the games is approximately $68K.
Lesson 1: Target the player’s intuition
Going against intuitive behavior is dangerous, and it can go unnoticed until the actual release
Players feel smart if they can use their intuition and real life experience to predict behavior of the game. This is especially pleasing if the behavior itself is not trivial. For example, people immediately realized what the Shuffle Powerup is and does. Everywhere on the forum and in the comments it was called the Rubic cube powerup. Another example of this is sinking blobs. Both from real life and from arcade games players know that drowning is fatal. So it is relatively intuitive that you should keep blobs out of deep water. Only problem here is that players have no way to relate blob density to real world objects. They have no way to predict if the blobs would drown or float!
My partners used a similar metaphor for the iOS port, where they made the liquid look like green acid. Even though acid is dangerous and maybe out of place in a casual puzzle game, it worked really well. Everyone clearly knows from movies and comics that sinking in green acid is the worst thing that can ever happen.
Going against intuitive behavior is dangerous, and it can go unnoticed until the actual release. Pipes in real life feed water all the time (or at least when a valve is open). It turned out it is really hard to grasp that removing a blob on the screen actually releases more blobs from the pipe.
Lesson 2: A sequel does not need to be a revolution
Every little thing I changed in a sequel disappointed at least one player! People liked the original game for a reason. They wanted more of the same type of entertainment in Gluey 2, even though they didn’t want it to look and feel exactly the same.
From now on, my sequels will have…
● the same art style, just more variation and improved quality;
● the same music style, but evolved;
● the same pace;
● an evolved gameplay, not a replacement.
If I ever want to break those rules, I will be making spin-offs of the original. For example, arcade games in this Gluey universe can be Gluey Jumpers or Gluey Shooters, not Gluey 3.
Lesson 3: The Flash game licensing model is still viable
Casual single player games for portals can still pay the bills for an indie game developer. A quality casual game with solid gameplay, professional art will get sponsored and licensed. If I limit the development cycle to less than 4 months, the licensing fees in the first 6 months are likely to cover my costs and finance risky mobile projects.
Non-exclusive sales worked great for my type of games. They can occur years after initial release. Now I am even more reluctant to accept fully exclusive deals for my future games.
Recently, Gluey was ported to iOS. In the mean time, Sergey is working on Gluey 3. To see what else he has been up to, check out his website or Twitter (@sergebat).
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 advice on their attempt to turn their Global Game Jam project into a full-fledged commercial product.
The Global Game Jam version of FYI was developed by the Dutch game studio Digital Dreams and two friends of the studio. The concept of the game is based on infographics. Every action by the player results in changing bars and pie graphs, which make up the game world. After the Game Jam, FYI won the Independent Propeller Award for Best Design. The game has grown a lot since the team decided to continue development. Digital Dreams plans on releasing FYI to the public and is currently talking to publishers.
We were able to go just a little bit further with our game than the average Game Jam game
What triggered your initial consideration that your game was worth continuing with?
It felt right. From a gameplay point of view, the concept just felt right. Besides that, we had been able to reuse a lot of the code from previous projects at the Game Jam, so the prototype was already fairly complete as far as Game Jam standards go. We were lucky that our main programmer had recently worked on a similar game in terms of camera, physics and collision. Because of this we were able to go just a little bit further with our game than the average Game Jam game.
What do you believe was the main element of your game that allowed it to be commercially viable?
Even though it’s probably cliché and a common answer, we believe the uniqueness of the gameplay and the aesthetics makes FYI commercially viable. The gameplay is unfortunately really hard to explain in pictures and words, it’s something you should play for yourself in order to understand the concept completely. As far as aesthetics go, we use infographics as a visual style, which makes it stand out as well. This was also the main inspiration for the concept.
A screenshot of an early prototype of the game, showing the use of infographics in the game’s level design
The biggest realization of the team members from the company was that we could produce so much in so little time
How did you manage the aftermath in your team?
Four out of six persons from the Game Jam team were already part of Digital Dreams. The biggest realization of the team members from the company was that we could produce so much in so little time. That’s why Digital Dreams decided to switch to developing smaller projects after the GGJ. That was a valuable lesson.
Another valuable lesson was about handling the IP. We talked to the other 2 GGJ team members and discussed our intent to possibly continue working on the GGJ prototype. In hindsight, this wasn’t enough. We should have done more than just talking. It’s never a bad thing to have things like this in black and white to avoid problems later on, especially before any money comes into play.
It made sense for us to continue as a company, because we really wanted full dedication and commitment. Basically we wanted to invest a lot of time, which is hard to achieve when working together part-time with people that have lots of other stuff to do. We also knew from the start we were taking a huge risk as Digital Dreams by investing our resources into this rough prototype, because we didn’t have the slightest idea if it would pay off some day. We really started to believe in its commercial viability after we won the Indie Propeller Award for Best Design.
What were the most important experiences/learned lessons and/or challenges that you had while further developing your game?
We knew the project would take around a year, making it the largest project to date for Digital Dreams. We did not have the money to do that. Selling the game to a publisher was the follow-up challenge. But it is great to get experience in this important aspect of the game industry, and learn how to pitch to other parties. It took quite a while before we convinced a party to actually invest in us though. This is one of the hardest things to achieve as a new start-up.
A second important experience was the difficult but necessary choice of engine. We considered quite a few engines to support the game. Unfortunately we can’t say much more about this without giving away too much at this point.
In your case, what did you learn from getting the game out to the public?
Well, the game isn’t public yet. But when we showed co-developers, other friends and publishers one of the prototypes we made, we saw how hungry they were for more. You just know you have something worth spending your time and effort on when people want more. This sure gave us confidence to continue development on FYI.
If you think you want to continue work on a GGJ prototype, it’s a smart move […] to know all the team members
What kind of tips would you give to other GGJ participants who might decide to continue developing their project?
Make properly signed agreements with your teammates shortly after or even during the GGJ. It’s not 100% necessary from a legal point of view, but it might help avoid some issues once you decide to continue with the project.
Also, it helps to know all the team members, this will make it easier to discuss this option, and you’ll know with what kind of people you’re getting on board with. It kind of goes against the GGJ spirit - getting to know new people - but if you think you want to continue work on a GGJ prototype, it’s a smart move.
Last but not least: Have fun! Creating something cool with friends in such a short time is one of the most fun experiences we can think of. So don’t worry too much, just give it your best and enjoy the ride!
You can find more information on FYI on Digital Dreams’ website. Currently, Digital Dreams is working on a big project, which will be announced in the coming months. Stay updated through Twitter: @DigitalDreamZzz
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 King.com and decided to quit my job to become an indie flash developer. Since then I’m working at home, full-time. The past four years I’ve created different games about Red Ball on different platforms (Flash and iOS). I created Red Ball 2, Red Ball 3 and finally Red Ball 4 at the end of the last year. Next to that I’ve created the Red & Blue Balls series (three chapters) where you control two balls - switching between them. With every game I aim to improve the quality by hiring art designers, add story animation instead of comics and improve the user interface. I couldn’t say it better myself then what JayIsGames.com wrote about the Red Ball series progress.
Finding inspiration
The main focus in my games is game- and leveldesign. The seven Red Ball games count a total of over 100 levels. My inspiration for these levels came from some great games I played on the internet. For example, the buttons and levers in Red Ball 3 are inspired by Fireboy and Watergirl. Another game, Lee-Lee’s Quest 2 inspired multiple aspects of Red Ball 4. I really like the popular iPhone game Doodle Jump which is why I wanted to add a parody-level in Red Ball 3. The gears in Red Ball 4 are something I added after spending quite some time on a physics learning tool called Algodoo.
Other things in my life inspire me as well. On a vacation to Egypt I visited the pyramids (as seen in Red Ball 3) and I came up with the helicopter level after I was given a RC helicopter for my birthday. Wikipedia articles about different mechanisms also always inspire me to create new things.
Level design
Each level in the series goes through three different stages of development. First I draw some level challenges with a pencil and sketchbook. This part of the process takes about 50% of the time. The fun part about this stage in development is that I can do this wherever I want. Sometimes I work at a café, the beach or while traveling.
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
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.
Kjell ‘t Hoen is a game designer from the Netherlands, specialized in casual games. After creating his own concepts for his ‘Ludomo Gamestudio’, he is now mainly working as a game developer at Tingly Games. Kjell has a passion for making games and is always looking for new and original gameplay. This article describes the process of one of his games that he made in collaboration with YoYo Games, called Rick ‘O Shea.
The original idea for Rick ‘O Shea came from one of my earlier games called Curve Ball. Its core gameplay was controlling a metallic ball with the environment, i.e. launching it with flippers, bouncers and canons and having it follow rails. The concept came to me by looking at some beautiful clockworks and jewelry, which inspired me for the original design. The goal was to make something shiny and fun.
Since I was working with Gamemaker for a very long time, I had enough game concepts to show
The Rick ‘O Shea journey originally took off when I met Mark Overmars, the creator of Gamemaker (the engine I had been working with for years) at the Festival of Games 2011. He was interested in working together with indie/amateur Gamemaker developers who had interesting game concepts for mobile devices. Since I was working with Gamemaker for a very long time, I had enough game concepts to show and since most of them were one-button they were quite fit for mobile devices. So I met with Mark a few times, where I presented some of my ideas which I had already polished a little in the past and we picked the one that seemed the best fit.
Working together with Mark and YoYo Games, we developed my raw concept into a fully fletched app for iOS and Android. Both Mark and the YoYo Games crew put in a lot of effort to steer the design and gameplay to an even higher level and I feel the eventual product is as polished and fun as it can get. As a great bonus, half way through the process, I was invited to fly over to Scotland where YoYo Games was situated, to finish the game. Personally this was a great opportunity and made for an amazing experience.
Tackling art issues
The first graphical design
Right after the kickoff, the biggest issue we tackled was the theme and art style. It had to look great and we needed a believable ‘world’ as a setting for the rather abstract game mechanics. As my original idea was clockworks and jewelry, I first did a redo of my own graphical design for that. This design however lacked a likable character and believable world, so after it was rejected I thought about coins and how you could collect coins with a living piggy bank. That concept was also rejected, this time I think due to my personal lack of art-skills. Eventually we decided to move the entire art-issue over to Yoyogames. They were kind enough to assign the project to one of their in-house artists: Alan Morris, with whom I worked on the game from that moment on. He came up with the circus concept, and since that theme had actual cannons it fitted the mechanics perfectly. Also, with the art out of the way I could now completely focus my attention on gameplay, level design and programming.
Mistakes made, lessons learned
In Rick ‘O Shea, canons rotate automatically. The main thing the player has to do is time their shot when a canon is pointing in the right direction and make sure the ball ends up in the next canon.
The original concept was focused on one-button, being the entire screen. I had designed the levels in a way that experienced players could do speed runs, which could change pace of the game and offer some immersive gameplay. Mark and the Stuart however, convinced me early on that it would be better to give the player more control, by enabling the player to aim, turn the canons towards the finger of the player and not having to wait for the canon rotation. This was a tough decision for me because my entire concept was based around this mechanic. On the other hand, my original concept had huge levels, but the app version would consist of smaller levels. So I decided to go for it. This turned out to be for the better. Even though I had to let go of all my initial levels, I found that I could create even more interesting and challenging levels and that the gameplay now offered more freedom.Rick ‘O Shea would have been an entirely different game if not for this change.
The model would go from paid to in-app purchase where players could unlock two new worlds for each payment.
Another big issue was the business model. The idea of getting my old game concept to mobile devices got me really motivated, so before I knew it I had created 100+ levels. After showing them to Stuart, he suggested to break up the levels and sell them separately. The model would go from paid to in-app purchase where players could unlock two new worlds for each payment. This would also be a nice trial for YoYo Games to see if Gamemaker, their main engine, could handle in-app purchases properly, making it as Stuart called it the studio’s ‘guinea pig’.
I believe this has been a big mistake. What we did was divide the levels into 5 different episodes and give the first episode (24 levels) away for free. Even though we thought long and hard on how many levels to give away for free and what mechanics they should contain (and what mechanics to save for later), this was nothing more than an educated guess. And so it turned out to be. Even with more than a million downloads the number of actual sales was extremely disappointing. Looking back at this decision, there are simply too many risks I would never dare to take again. For example:
The player plays the free levels, has the feeling he has seen most of what the game has to offer and deletes it.
The player plays the free levels, loves them and downloads the game for free from some obscure website.
The player does not open the game at all and still mentions it is shit, causing a bad review (this actually happened!).
The player plays one level, doesn’t get it and deletes the game without looking beyond the first try.
I do believe the in-app purchase model can work nicely for extra gameplay variations (other weapon types and new features) that make it easier to play the game or offer the player more choices and strategies. The old demo/shareware model we went for though, was just not working out.
Personal development
I learned I was making levels too easy, this was a huge realization for me as I looked back at many of my other games
During the playtesting phase, done in the university where YoYo Games was located, I learned I was making levels a bit too easy. This was a huge realization for me as I looked back at many of my other games. The game was simply not challenging enough and I ended up giving 120 levels more ‘teeth’ and dangerous situations, which really made the game way more interesting and balanced.
Working with Mark and Stuart was a big deal for me and I was interested to see how a company like Yoyogames operated. They turned out to really supportive and had a lot of experience with creating games. They also gave me a lot of freedom and useful feedback while creating the game and tweaking it. But I also learned, when signing contracts about royalties, is that you should always check when you are supposed to get paid. I completely trust Yoyogames and I enjoyed working with them, but waiting for 9 months for a royalty payment is not cool and eventually took away some of the enthusiasm for making games on my own. I always say I’m not in it for the money and I am very patient, but without any financial results it’s hard to keep going and stay motivated.
Tips
Don’t do in-app purchase for levels, it’s simply not working. In-app purchase for extra variations, gameplay, strategies or guns can work fine, but not to complete the journey the player is on. In Rick ‘O Shea we also sold extra skins, which I think comes closest to what could have worked
Playtest with a wide variety of people. The play testers Yoyogames invited were really good, but most of them were also heading into game development. We could have done a better job if we had had some little children or grandparents play the game as well. I realized this after returning home and showing the game to my friends and seeing them have a really hard time getting past infamous level 5. So it was great feedback to make the levels harder, but what we missed was the feedback from the non-gamers as to where the game was too hard.
The day after
The day after Rick ‘O Shea was published on Google Play and iTunes it got featured on Kotaku, who made it ‘Gaming App of the Day’. I remember Andrew McCluskey, an employee at Yoyogames who became a good friend, coming over to my desk, tabbing me on the shoulder and telling me ‘Dude.. you’re on Kotaku’. Pocketgamer was next, giving the game a Silver Reward and a few other smaller websites gave some pretty nice reviews.
Checking some of the first levels of the game and looking at my bank account made me doubt whether or not my game was really as good as it could have been
A few months later, in March, Rick ‘O Shea got featured on Google play. I have an iPhone but I got a photo from one of my friends who saw the game sitting right next to the new Angry Birds Space and Sims. That really good news and as I heard later, caused for some 80k extra downloads per day. All this was great, but the best feeling I have comes from the fact that the game still has a 4 out of 5 star rating with 3300+ votes. That made the game my greatest success so far. But even though Rick ‘O Shea was such a great success, I realize I also made some mistakes. Checking some of the first levels of the game and looking at my bank account made me doubt whether or not my game was really as good as it could have been.
After creating Rick ‘O Shea (Apple AppStore & Google Play store), Kjell decided to move forward and work for a new exciting company called Tingly Games as a Gamemaker developer. In his spare time, Kjell is still working on his own games. For example, he collaborated with NextGamez and Gamious on a hidden object game called Excursions of Evil, which is to be launched soon. If you are interested in what he’s currently up to, check out Kjell’s blog.
It all started in the end of 2009 with three guys: me (Eugene Karateav) as the flash-developer; php-programmer Pavel Kostyuk ; and artist Alexey Egoshin. We decided to create our own website with flash games. In a couple of months we created the website’s engine, design, added several games, et cetera. In short: we made yet another websites full of flash games. With our website up and running, we needed a new flash game to promote our site, which would be Wake Up the Box 1. The game’s idea was born after my endless experiments with the physics engine Box2D. We developed the game in less than a month and released Wake Up The Box 1 in November 2009. It was surprisingly popular. In its high days, it attracted over 150.000 visitors. It was clear that we had to create a sequel. So, we created Wake Up The Box 2 and 3. After that, I decided there were enough games in the WUTB-serie and started doing my own thing: experimenting with the physics engine itself.
I would play for hours, just drawing objects
I continued creating new mechanics and one day I realized it was a lot of fun drawing shapes that behaved in accordance with the laws of physics after their creation (similar to Crayon Physics Deluxe). I would play for hours, just drawing objects. It was fun to see how they became rigid after drawing, how they fell under gravity, how they collided and bounced into each other. I decided to create a game based on this mechanics, which led to the first prototype. In small indie games the main and most important part is an interesting gameplay. Characters, story, art, etc. are secondary. So, after the prototype was done, I decided it was time to think about the world around the core mechanics. After some thinking I settled on the good old idea of waking up boxes. So, that’s how Wake Up the Box 4 was born.
Lessons learned
Development’s iterations using prototypes - Iterative development is very important when creating a game with an original gameplay. Our game’s idea is pretty simple: a player draws an outline, which becomes a physical object after creation. These objects are used to wake up the box in each level. I went through 10 iterations to make the drawing process as easy and user friendly as possible. The process went as follows:
Make a prototype.
Show the prototype to different people.
Watch the players play the prototype, pay attention to their reactions (pleasure, frustration, etc.).
Make changes to avoid the frustrating moments.
Go to step 2.
Sometimes a player tried to create a circle dozens of times and had no luck. In other cases they tried to make a rectangle but got a circle.
There are a couple of advantages to using prototypes. For example, in our game we have some predefined areas where a user can draw objects. The drawing process is allowed only inside those areas. Therefore, even if you move the mouse outside the drawing zones, the mouse pointer stays inside. You don’t have to worry about drawing carefully inside the areas. In our first prototypes the situation was different. A player could get out of the area’s bounds and that meant that the drawing couldn’t be completed. It was very frustrating for the players to try hard to stay inside the zones. And, of course, getting out of the drawing area caused outbursts of anger. We solved this problem by not letting a player get out of the drawing areas. A player’s outline is stuck to the area’s bounds.
Second, we learned about the difficulties creating circles. In the earlier versions of the game one had to draw an outline similar to a circle to get a round object. But it was a tough task for a player to do. So, in the next version I made the process of drawing circles a separate tool.
If you want to reach a wide audience, you should playtest using a wide audience
Test everywhere - If you want to reach a wide audience, you should playtest using a wide audience. Test it on your friends, colleagues, and relatives. A wide audience helps to get a lot of views at your game from many different perspectives. For example, I use a high quality wireless mouse and it’s easy for me to draw. But one day I was at my friend’s house and tried to play Wake Up the Box 4 with his mouse. It was really painful trying to create objects with that mouse. But this situation helped me to realize that players have different computer mice, and it forced me to make some changes in the level design.
Refactoring - When you work as an indie, you have a lot of ideas coming up in the development process. You constantly add, remove, modify and upgrade your game’s features. And as a result, you have a mess instead of code. You have no extrinsic motivators like bosses or deadlines, so it’s very important to sustain your intrinsic motivation to make a game. And that’s why you have to clean up your code every time you feel you get lost in your own code. I sometimes refactor my code even after the project is released.
Some tips
Experiment! - For example, in Wake Up the Box 4 we decided to make some drawing animations in the game’s main menu. Players liked this feature a lot. It showed endless possibilities of drawing different objects and their combinations. And we received a lot of feedback from people saying that they enjoyed not only playing but also just watching those animations.
In the main menu, an example drawing of a house is shown to the player.
The main advantage of us being indie developers is the ability to experiment with our games.
Simple idea - I believe that indie games should be based on one simple and original idea. The main advantage of us being indie developers is the ability to experiment with our games. We can decide which way to turn the development process and we’re independent from the publishers with these decisions. We can’t compete with big teams in the quality and the amount of the content, but we’re much more flexible with creating new game mechanics.
Check out the Wake Up The Box series at Olologames.com. Wake Up the Box 4 was nominated for the game of the year award in the category Physics on JayIsGames.com. In the future, Eugene Karataev will continue work on the physics genre and develop new games based on the physics mechanic.
