GlobZ is a small French indie company of four team members: Alexandre Houdent and Laurent Fernandez, who work at an office in Paris, and Fabien Riffaud from Tours and Jérémy Damon from Vannes working from home. Alexandre talks about the challenges and lessons of the creative process for their latest game, ¡Oh My GlobZ Mucho Party!
The entire GlobZ team has been working together for more than 10 years, becoming works-for-hire for web/mobile games in order to finance our own productions. In the past, GlobZ got some recognition as an IGF finalist in 2008 and Milthon prize winner in 2009 for Globulos, released first on the web in 2003 and later on the Nintendo DSiWare in 2010, including in Japan, where the game was sold best. In 2011, we also published an iOS version. Since then, we released the arcade puzzler Twinspin on iOS and Android in 2012, but despite all the good reviews, the game did not sell well at all. The question arose: what game are we to make next!? The answer to that question turned out to be a touch party game called ¡Oh My GlobZ Mucho Party!, to be enjoyed by several players on a single iOS or Android device screen.
A Party Game: A Perfect Fit For a Work-For-Hire Studio
GlobZ is a very small studio, but the team members all have strong personalities and somewhat different tastes. And even if I am the “final boss”, I like it when decisions are collective and we reach a consensus. I like to say that we are two developers, two graphic designers, and four game designers!
Even if I am the “final boss”, I like it when decisions are collective and we reach a consensus.
So when thinking of a game, we thought about the games we like to play together. Bishi Bashi was in the top list. Thinking about it, we liked the idea of doing a touch party game with the spirit of that great Playstation game! Everything seemed a perfect match:
- Minigames were ideal for a possibly sliced (between work-for-hire) production!
- A crazy art direction would allow us to experience many funny styles at no cost!
- We did not find any game like ours in the App Store, so we had a kind of “blue ocean” strategy!
- This would qualify for a PREMIUM title! No F2P - because premium is all about “perceived value” (here we have 30 minigames) and “I don’t already have this app on my device” thinking (we hope so!).
Following All Great Advice Seen in Postmortems
We were very excited about the project. We made a huge document with 35 minigame ideas, came up with “Oh My GlobZ” as a working title, developed a prototype (Candy Match), and filed an application to a French state office (CNC), who agreed to give us some money at the end of 2012 to help develop the game.
I promised myself to follow all the great advice that I constantly see in postmortems.
And for once, I promised myself I would follow all the great advice that I constantly see in postmortems, like:
- Do playtests as often as possible and take the feedback into account!
- Speak about the game as soon as possible and as much as possible!
- Work with a PR company instead of doing it yourself!
What a Touch Party Game Needs
In 2013, we started working on the game. Production happened not to be sliced at all, and we had to make lots of decisions on a daily basis. In other projects, we usually have some time to think between actions, so this was new to us. We discovered quite a few more things during development as well. First, our gameplay had limitations. We had no buttons mashing up stability of the device, no swiping, and no virtual controls. Also, some games that we wrote out did not turn out as fun as we hoped.
We planned to use many local multiplayer possibilities, but kept only the two in the the top picture that appeared the best
Doing something “crazy” and “fun” might seem simple when you look at it, but it’s not like that in real life (unless you’re really crazy, maybe). The first designs were “serious” and too “well-executed”. They looked like nice Flash games, but lacked a special twist, a specific identity and style. We wanted the game to be recognizable from any screenshot, not dependent on the diversity of graphic directions.
The first designs were “serious” and too “well-executed”.
Our original plan for the identity of the game was to rely on some black-and-white characters we called Arcarids/Blubz, but we eventually changed them to avatars, where players would put pictures of their faces instead. We had worked on a Facebook game for a client where the Facebook profile picture was used as the face of the character in the game, and it was great fun and so much easier for the players to see who they are!
During development, we realized that the party game (“stupid, but fun”) orientation was a bit frustrating for some, because we also like simple and deep puzzle/strategy games, and had some as prototypes. At a certain point, in order to help ourselves decide to completely get rid of some of those we joked we would do a “¡#OMGZ Mucho Strategy!” sequel.
Some of the games that we kept for the ¡#OMGZ Mucho Strategy! sequel
The Mayonnaise Doesn’t Work
In April 2013, the production was put on pause due to some work-for-hire projects. By that time, we had lots of content for the game, but the whole thing still lacked a clear direction and identity. In French, we have a great expression that fit our situation: “the mayonnaise doesn’t work”. It means you have all the ingredients, but it does not work as great as you expect. The pause happened to be an awesome opportunity to perform many playtests and show the game to some fellow game designers. This helped us outline the “fun factor” and identity/style - the avatars were the thing! So we decided to feature them in all games, not only in the UI!
Some minigames, all featuring the avatars: the identity of the game is in every screenshot despite the graphic diversity
We got back to the project in mid-November. It’s terrible to say this, but it felt difficult to find the motivation to start working on the game again! I thought the way out was in making totally new games, but the team was much more reasonable, and we ended up polishing the existing games, UI, and game modes. It was a wise decision, because we really had the feeling of consolidating the grounds of the title at last. What is more, the Google documents we were using included too many comments, so we decided to clear everything and keep only the latest and relevant feedback (note: Google keeps all the modifications anyway!). We also had some communication issues due to remote locations, but solved that by simply doing some Skype conference calls!
The Remaining 10 Percent of a Project
Accounts for the Other 90 Percent
We are now super happy with the avatars; they are really fun and give a strong identity to the game. And when we do playtests, we see people enjoying the minigames, which is ultimately the goal of the whole thing!
Adding sound and music will be great because my four-year-old son won’t complain about the lack of sounds and music anymore!
As the “ninety-ninety” rule states: “The remaining 10 percent of a project accounts for the other 90 percent of time”. We still have to add some more mini games and music and sound (it’s the only thing we subcontract), not some random placeholders here and there. It will be great because my four-year-old son won’t complain about the lack of sounds and music anymore! We also have to localize the game in as many languages as possible, and work on real PR for great exposure at launch!
While they admit that it’s always difficult to set a date when you’re doing both your own game and some work-for-hire, the team plans to release the game by the end of Q1 or the beginning of Q2 2014. In the meantime, you can get a taste of it at the GlobZ site.
Kid Aviator is an endless flyer that launched on iOS and Android January 2014. It features Kid, a daring aviator-in-the-making willing to risk life and limb for his fans. The game was developed by two developers: Mattia Fortunati (programmer, designer and graphics rookie) and Claudia Perugini (visual artist and character designer), both hailing from Rome, Italy. Mattia shares their story.
A Lengthy Development
Kid Aviator Development Team
Kid Aviator was an interesting project for first-time developers such as ourselves. From start to finish, the development of Kid Aviator lasted more than two years, quite a bit of time for such a small game. Not only did we experience the expected false starts and ups and downs associated with a two-person team of first-time developers, but we were busy with school and day jobs. We only had time to work on the game in our spare time. Add to this the fact that Kid Aviator was built on a self-made game framework . . . and you get the picture.
It was also 100 percent self-funded. We invested our savings from our day jobs. We didn’t even start a Kickstarter campaign because it’s (sadly) not an option for Italian developers (Kickstarter only allows projects from the United States, UK, Canada, Australia, or New Zealand).
Dreams & Aspirations
We wanted to create a well-made, relaxing game, something that you could play in your spare time, during lunch breaks, or while waiting at the bus stop. We kept the game simple and full of personality. This was Claudia’s rule, and I’m glad we were able to stick to it. Kid Aviator was always meant to be welcoming and easy to learn so that players felt good playing it.
We also had a personal goal: to learn. Many teams around the world make great games year after year, but how do they do it? Our idea was to not take any shortcuts and pay attention to every single step: concept, prototype, production, testing, marketing, PR, all of it. Throughout development, we strengthened our writing, programming, drawing, interface, design, and polishing skills by asking for help and hearing war stories from fellow indie developers.
Kid Aviator’s Xcode and iPhone simulator
Pushing ourselves to the limit, we often found each other performing several roles at a time. After encountering a big problem, we sometimes wanted to simply surrender and leave things as they were instead of fixing them. As an indie developer, you will be tempted to give up from time to time because you’re way too busy with a day job or other projects. It’s like raising a bonsai: with some discipline, proper scheduling, and doing just a little every day, you’ll slowly see your miniature tree grow to be a strong and beautiful specimen.
Finding the Core Gameplay
The endless runners genre is marred by clones of clones now, but two years ago, there was still room for innovative gameplay. We wondered what would happen if the player moved the obstacles instead of controlling the main character. To add some variety to the gameplay, we included objects that could be destroyed, along with power-ups. Back then, Kid would move automatically (and randomly) around the screen – like a lifeless roboaviator.
Then we noticed that every time our friends played the game, they always ended up trying to move Kid by tilting the device. We didn’t have tilt controls then, so we said, ‘Why not?’ We immediately put our friends’ feedback to use and added tilt controls. Thus, the dual control system (in which players control both the protagonist and the interaction with each object) was born. Clearly, player feedback and the use of hardware capabilities particular to mobile devices have helped us develop (and refine) Kid Aviator‘s core gameplay.
The Circus Setting (& Choosing a Title)
Kid wants to become famous. He’s like a rock star, with his audience numbers increasing each time he wins a medal. It’s not about Saving Private Brian (I guess only Ryan was saved!), avenging a long lost cat, or cleansing the world of all evil. Kid Aviator is about flying endlessly toward the sky and becoming a star.
Early Concept Sketches of Kid by Claudia
It’s an unusual choice, we know. This simple (and somewhat basic) concept—a cute Kid flying toward the sky and encountering random strange objects along the way—was born organically. As for the setting, we didn’t take long to come to a decision. After a quick brainstorming session, we chose a more traditional “human cannonball” theme for the game—and a circus setting was a natural fit. But the title didn’t come as easily: in fact, it took us two months to choose one!
We had a whiteboard that we scribbled on everyday, looking for inspiration. Some of the early titles we considered included To the Top!, Sky-Man, and Cannon Kid. Eventually, we fell in love Kid Aviator, a variation of Cannon Kid. However, we secretly called it “scaimen” (Italian transliteration of “Sky-Man”), and the game directory is still named “skyexplorer.”
Time to Tighten Up Those Graphics!
We’ve heard that graphics are the most important element in game development. An awesome icon and beautiful, hand-drawn characters are essential to success. This is only partially true. A great game needs deep, rewarding gameplay or it will just be an average game with AAA graphics. Just ask regular players. Most of them will say that graphics are important but “gameplay is king.” I find that the gameplay is the game’s soul and the graphics are its body. Gameplay is a direct channel between game and player.
At first, Kid Aviator’s graphics were no more than placeholders (and heavily inspired by The Powerpuff Girls). Once Claudia got her hands on it though, a revolution took place. She realized that falling objects would be more familiar to the average player—and after many sketches, she made a major decision: Kid would now be based on Mr. Driller instead.
Claudia was totally new to computer graphics, and Kid Aviator was her first experience mixing art and computers. However, in no time at all, friends and fellow developers introduced us to professional tools and gave us honest and constructive feedback. We love the result! Kid Aviator boasts “cute and warm graphics”—as it should be in an Italian game. The way the game looks is a perfect translation of the studio’s ethos, and it’s a little piece of the spirit of Italy that can be played worldwide.
Old Graphics (left) vs. New Graphics (right)
Visibility: Limited
What’s the point of making a game that no one will ever play? We knew that the game would be invisible without a good promotional push behind it. However, it would have taken years for us alone to learn the PR tools of the trade—and we would never be able to finish the game if we turned our attention away from development.
We did not surrender—despite the cold, calculating replies—and we finally found Novy PR
We contacted a number of PR agencies with a detailed message explaining our needs. It was our first time seeking PR help, and we expected professional replies, but we quickly realized that most firms were more interested in money rather than helping indie developers. We did not surrender—despite the cold, calculating replies—and we finally found Novy PR.
Novy replied in a professional, yet passionate way. They listened to us and were interested in our project as a whole. They were also affordable for our small, self-funded studio. Novy took the role of Kid Aviator’s cheerleaders, testers, marketing mavens, you name it. In hiring a PR firm, we weren’t trying to top the App Store rankings; we just wanted to avoid oblivion. Novy PR helped us avoid that.
Homemade Framework
Due to my work in development, I ended up becoming one of two core creators of RapaNui. An open-source, Lua, high-level, 2D game framework, RapaNui can be used with the Moai SDK when developing cross-platform games for iOS and Android. Initially created as a Corona SDK porting framework, RapaNui would eventually become a “college in a box” for me. I learned a great deal about both the Lua language and Moai SDK.
Kid Aviator’s Moai Simulator
Since then, RapaNui has grown and led to a job making an AAA title. Working 60 hours a week while still fleshing out RapaNui reduced the time I could spend on Kid Aviator. At the same time, it allowed me to port my game to RapaNui. Improving the framework for the AAA project would mean improving Kid Aviator‘s engine as well—and vice-versa. Kid Aviator is bound to RapaNui, but it took much longer to develop because we relied on this exciting, but ever-changing new framework. I definitely don’t recommend going the “non-standard” route like we did—especially if you’re an indie developer.
However, I was personally willing to accept the risk, and I’m really happy with the end result. I feel closer to Kid Aviator because I built so much of it with my bare hands, a feeling I lack with my other games built with commercial engines.
Dire Straits
We were moving along at a such a smooth but busy pace handling the (successful) open beta, we didn’t realize that iOS7 was right around the corner.
With November already taken hostage by two major console launches, we decided to slow things down and delay the soft launch to December.
Kid Aviator was approved and ready for sale when suddenly, we had to make it compatible with the new Game Center and status bar designs. This meant that we had to re-submit the game to Apple and postpone the soft launch and worldwide release. With November already taken hostage by two major console launches (transitioning to the next generation, no less), we decided to slow things down and delay the soft launch to December, planning the launch for January. This was a two-month delay that we could not have predicted.
The second issue was the “December Curse,” which played a big part in our poor Australian/Canadian/Brazilian soft launch. Although it was intended to test the game’s viability and help us smooth out the actual release, the soft launch yielded almost zero downloads—and we didn’t get the feedback we so desperately needed.
In hindsight, we were hitting the freemium wall—with big titles, all free, released with the sole purpose to attract players at the expense of more premium indie offerings during the holiday season. Would you download Dungeon Keeper for free, or Kid Aviator for $0.99? The AAA game is obviously not truly free, but many mobile players still don’t realize this in advance. Most will skip the paid title and try a free download, even if they eventually uninstall it after 15 minutes. Kid Aviator was not made to do battle against the frighteningly competitive freemium market, but we couldn’t re-design it to counter that threat. Our only resort was to hope for a strong launch.
Texture Packet and Physics Editor for Kid Aviator
At no extra cost, Novy agreed to pursue a pre-launch campaign in order to generate some buzz. We reached out to journalists ahead of launch, and a number of outlets requested promo codes and Android builds, which made us quite happy. However, we stumbled upon a huge issue when it was time to release the game on Android: a black screen, which was reported by a large number of Android users on launch day. Of course, we fixed it as soon as possible to avoid missing out on any sales—but we received a number of refund requests before we could submit a fix (fixing the Android build took two full days – 48 hours without sleep).
It turns out that the Android logcat had no errors. This was a sneaky bug because it would happen only if the game was installed from Google Play. We found a solution, thanks to friends who lent us their time and Android devices — plus the help of other developers who had experienced the same issue. It was a problem caused by the new resource path system added to Android 4.3 (Jelly Bean): the game could not find its assets. After we fixed the problem, our Android players were happy and satisfied.
A note on Apple’s approval process vs. Google Play: Apple’s approval process is notoriously time-consuming. However, having a professional QA team test your game on every single iPod touch, iPad, and iPhone gives developers much-needed peace of mind. At the same time, Google Play allowed us to upload a stable build within a few hours – versus a few days on the Apple camp. I guess both platforms have their strengths and weaknesses!
First Week: Reviews, Feedback, Downloads
Freed from a nasty black screen, Kid Aviator flew across the world, ready for the real challenge: the App Store and Google Play. During those crazy days when we were busy fixing the Android build, we still felt incredible relief and excitement because we were reading the early coverage for Kid Aviator.
Journalists produced well-thought reviews with mostly positive scores. The few negative reviews were still very honest and always included constructive feedback. Players and reviewers alike enjoyed the dual control system, core gameplay, cute graphics, and charming characters.
It seemed to us that Kid Aviator was invisible in both stores, and we don’t remember adding an invisibility power-up.
Users rated the game, recommended Kid Aviator to their friends, and contacted us with a lot of awesome suggestions. However, while we got great reviews on top sites like 148Apps, Cult of Mac, and AppleTell – along with communities like Reddit and Touch Arcade’s forums – download numbers were low. It seemed to us that Kid Aviator was invisible in both stores, and we don’t remember adding an invisibility power-up.
I guess this speaks to the dark truth of mobile development: the competition is beyond fierce at the moment-more like “dog eat dog, who then eats you.” Free-to-play took the air out of the room, making it very difficult for a game like Kid Aviator to get download numbers matching its quality. If this was 2011, we would be in the thousands of downloads at this point. But we won’t give up. After all the hard work that went into Kid Aviator, we’ll keep pushing to give the game every chance it deserves.
The Bottom Line
Developing an indie, self-funded game is difficult, stressful, and crazy—fraught with ups and downs—but it’s also challenging, illuminating, and satisfying. Just make sure to hold on and never surrender!
This is our journey, brought to you with absolute sincerity. We hope that it can be useful to others like many postmortems on the web have been useful to us. A hearty goodbye from Mattia and Claudia, the small team behind Kid Aviator!
The duo invites you to try Kid Aviator today and leave your feedback (invaluable for indie developers like them). You can also keep track of how it is going with the team on Twitter, Facebook, and their website.
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.
KickBack is a team of two: Nick Konstantoglou and Vagelis Antonopoulos. Unofficially formed in early 2010, the team was officially founded in 2012. Lost Echo, their first game, came out in September 2013. Nick tells us about their experience.
Overambitious
Before I tell you the story of Lost Echo, I have to tell you the story of the game we never made. I used to do architectural visualization, but stopped for a variety of reasons. Wondering what to do next, the idea to make a game, specifically an adventure game, came to mind. Of course, I made the classic mistake most inexperienced developers make: start with a very, very ambitious idea. It would be a PC game with graphics that would rival games with a budget of millions, and mechanics that would be innovative and revolutionary. While that had over-ambition written all over it, my cousin Vagelis needed no convincing to come on-board. Thus, KickBack was formed.
Nick Konstantoglou and Vagelis Antonopoulos
A couple of months passed, and one thing became really obvious: we were never going to finish. We had one area with a really detailed entrance, but really blocky surroundings, and a pretty basic movement system working, but that was about it. No puzzles, no mechanics, no dialogue system…nothing. Fortunately, we had the wisdom to realize we were in over our heads, but we weren’t giving up. We shelved the project and thought about our next move.
Adjusting our ambitions led us to creating Lost Echo
Enter Lost Echo
We attempted to adjust our ambitions to a more realistic level. We started to consider mobile games. The more we thought about it, the more sense it made. The point-and-click controls made even more sense on a touch device than on a PC, so we weren’t compromising there. Actually, we were improving the experience. We had already bought a copy of Unity Pro, so the cost of just the iOS add-on was something we could afford at the time.
So we started from scratch. And in our naivety, we just made a list of things we like. We quickly decided on the following:
1) Touch controls that made sense: If touch is the input method we have, we wanted an experience that would take advantage of that and not emulate some other kind of non-existent input.
2) Setting: It was a no-brainer: Sci-fi, near-future. We both liked Sci-fi, and the rough idea we had of the story we wanted to tell worked really well in the near-future.
3) Graphics: They had to be the best we could make on a mobile device. Since it was a mobile platform, there was a limit on what we could do already. So why not shoot for the sky? As I had experience in architectural photorealism, I was pretty confident that I could bring the style I had developed over the years to mobile devices.
4) Gameplay: We decided to not reinvent the wheel here. This would be our first game, and so before we threw out the rulebook, we explored it. The puzzles would be grounded to logic, we would have enough variety, and we would have at least a couple of puzzles that would be really fun to do on a touch device.
5) We would be done in six months.
Do you see something really wrong in the list above? At the time, we didn’t.
A screenshot from Lost Echo
Realities of Development
The first couple of months were very exciting. We were serious this time, and the project seemed doable in a short amount of time. Using the small amount of experience we gained from the previous project, we were moving very fast. We started with nothing and a couple of months later, we had a lot of things in place, much more than our first attempt. The groundwork for the movement was done, a dialogue system was in place, we had the first silly puzzle, and I had started work on a multitude of areas. Yeah, so the game crashed every so often and all the areas were unfinished and untextured, but it felt like so much was in place.
Since we seemed to be doing really well, we went into feature creep mode. Every couple of days, either me or Vagelis would go “Wouldn’t it be cool if…” and then we’d both quickly decide to do it. The story became more intricate and complex each day (and it was pretty complex to begin with).
We were working more than ever, but we had nothing to show for it.
With the deadline we ourselves set creeping ever closer, we suddenly realized that development takes much longer than we originally thought. We hadn’t stopped working, and we had put a lot of work into it, but the end product was feeling like it was 10 percent better. It wasn’t crashing as much now, the calculations were more efficient, and there was some texturing, but I had to rework some areas completely, so everything felt just as unfinished as before. I remember showing our game to a friend who said, “Wow, you really stopped developing it, eh?”. But we hadn’t. We were working more than ever, but we had nothing to show for it.
Moving On
The next months of development were not pleasant. We made progress slowly. We kept pushing the deadline back, and each time, it was overly optimistic. We started feeling that we might never be done. There was no end in sight. At the same time, this was becoming a bigger commitment than we had realized. A six-month project that then flops is not a big deal; we could rationalize it as it being a learning experience. But as we passed a year of development, the stakes started to get higher.
There were other problems. The 2006 first gen Macbook Pro I had that I did most of the graphics on was really not up to the task. It’s not a bad machine (I’m still using it today!), it’s just that it was really starting to show its age. Baking lightmaps to compute lighting should be a one hour deal, but it became an overnight thing. Testing and tweaking things also was much slower than it should have been. Even Vagelis’ laptop died mid-development.
We realized every decision had to be correct the first time, which was almost impossible, and also made us a bit scared of making decisions.
Things started to get pretty desperate. We realized every decision had to be correct the first time, which was almost impossible, and also made us a bit scared of making decisions. What if that puzzle idea is not good enough, and we have to change it? That will push us back! What if I have to change that model again? I will have to bake the lighting in all the scenes again, and that’s going to take a week! Our inexperience in other areas was starting to show as well. I was pretty confident in my graphics ability as far as environments went, but characters were not something I was strong in. I had to redo some characters three or four times to get them to a passable level.
And Then…
This is usually the point in a story were something really positive happens that changes everything…but nothing of the sort happened. We just kept going.
We had a ton of problems we didn’t have immediate solutions to, and things were looking grim. We kept asking ourselves if we were just wasting our time. But despite all that, we never even thought to give up. Call it tenacity, stubbornness, or whatever you like, but we were determined to finish Lost Echo, no matter the cost. The only thing that changed was that we started looking for a publisher. At first, this game was a fun little project. Now it had become a bigger investment, and we were starting to feel scared. So instead of our original plan of self-publishing, we searched for a publisher. And as with all fear-induced decisions, it was a bad choice. I can’t really share what happened, and it wasn’t all bad, but overall it was a soul-crushing experience, the kind that makes you lose faith in humanity.
A Cliched, but Important, Lesson
In the end, we had to put more effort than ever before. We had to change a lot of things, because many of the decisions were clearly wrong. And even though we were already developing for much longer than we thought we were allowed to, we kept revisiting a lot of the decisions we made.
If there is one thing to take from this, it’s to never give up.
In the end, we were never sure about anything. We were never sure if our decisions were right, if people would like our game, or even if we would be able to cover our expenses. We just made it up as we went along and chose to do what we wanted to do. If there is one thing to take from this, it’s to never give up. A cliche, I know, but of all the things we did, this is the one thing we did 100 percent right.
We are also sure that we can do better next time. With the sales and general reception of Lost Echo being better than we expected, it seems that there will be a next time. We couldn’t be more excited.
Lost Echo is a participant in Casual Connect Kyiv 2013’s Indie Prize Showcase. Find out more information about Lost Echo and Kickback studios through their Facebook and Twitter.
Living as an indie developer for more than five years and currently doing a weekly podcast with other indie developers, George Zarkua has created a summary of his experience in QA mode.
Working as an Indie
I believe the life of an independent developer is the choice for people who understand that in a company, they do not get what indie work could give them. He may be a loner who feels that he can grow stronger, can release a more independent product, make more money, or make better use of his time. After separating from a company, he gets all the freedoms and limitations that are inherent for indie.
The first thing you have to think about, unfortunately, is time and money. You must honestly ask yourself how much time you can share with your PC. Then multiply this figure by two. At this time, we need some minimum cash cushion, big enough to cover sickness (paid health insurance and gyms are not included in an indie life package), fun (very few people can be productive in a state of depression), and contingencies. This amount is the budget of your game. Of course, these issues are only for a full-time indie. If you are developing parallel to your main work, then it is simply impossible to calculate time.
You must honestly ask yourself how much time you can share with your PC.
When you becoming an indie, you become free. There is the freedom to choose a convenient schedule, programs, and partners. But almost immediately, it becomes apparent that indies can’t compete with the big companies. They must either create a studio with suitable rules or otherwise cheat. You are competing with studios that specialize in having spent a lot of time creating animation and content, and with a lot of people who are doing essentially the same job. In my opinion, indies should surprise the competition with ideas, unique style, and atmosphere. The ability to look to the future is the best quality for the companies; the ability to surprise is the best quality for an indie.
Making a Game
Experience helps avoid errors that you will understand only while making games.
Certainly, an indie’s first game could be a great game (Beginner’s Luck), but that does not guarantee that it will hit the top. However, the experience provides a broader view on the development of a variety of tools, working schedule, and a sense of the market. Experience helps avoid errors that you will understand only while making games. For example, you might forget to add a button of turning on sound and run into the crowd of disgruntled users who will write angry reviews and put a minus wherever possible. Or make an active area for a button on the screen, and not the button entirely. Even if your game has super cool music, particularly harmful players will not forgive you for these blunders. Welcome to the Internet! But through the experience of making ten buttons correctly, the eleventh will be done automatically. This will help you avoid a hit from a foolish fail and polishes your creation.
It is possible to gain experience without making games, but for me, this attempt turned into a failure. A long time ago, I found a great resource with a stupendous number of articles for indies. There was an incredible collection of articles on game design, development, sales as a whole, free graphics and music, and more. Almost everything was very interesting, and I read through it, trying to apply all in one game. But the negative of such articles is that they are designed for people who have some experience, and therefore were not dismantling the problematic issues that may arise for beginners. That’s because the layers are important in the experience. Layer by layer, we create an understanding of development. Reading articles about behaviorism in MMO without experience is like having a second-grader read Kafka.
In my opinion, the first game should be small and test-like. Even if you have a super idea for a super game, you still have no budget, nor the sense of the market and the audience. Postpone that idea for a while, and take up a small test project instead. When working on a small game, it is now incredibly easy to make a prototype of the game. In a worst case scenario, it could take three days.
Often, there is a sense to do it all from scratch as we learn a new technique of painting or read a book about the architecture of the code. Small games are good so that we have time to finish the game before we come to destroyable thoughts. And even if you decide to remake the game or after the remarks on the unprecedented lag of it even on the most powerful computers, you don’t rewrite as much. However, a small game does not have time to change ideologically. In any game, even the great games, it is important to keep the idea, the rod of the game. We can add features, change the appearance, but the idea of it should remain unchanged.
If you want new ideas to the game, or a second head, which will criticize you, look for a partner.
Increasing the quality of the game and leaving the level of “small games”, you will be competing with the big companies and studios. If you start to feel that you can not make a competitive game - look for an assistant. The type of the assistant should depend on your confidence in the game. If you feel the game itself is lame or you poorly see the idea, it is better to find a partner. If you want new ideas to the game, or a second head, which will criticize you, look for a partner. The only difference between an assistant and a partner is that the partner is involved in the development of the game, not just doing the job, but that difference is huge. Choosing a partner for a long project is like choosing a partner for a flight into space. If something goes wrong after six months of work, replacing will be very expensive.
Surviving as an Indie
I think an indie’s significance is hard to overestimate. Now is the era of indie developers. Indie games are no longer for hipsters. Steam introduced an indie games section where you can buy them on a par with the games from bigger campaigns. Apple Store gives indie games the same privileges as games of big companies. Sony and Microsoft are also looking for indie cooperation. The market does not reject that talent. There are sites for people looking for a direct link with the customer, such as Kickstarter, as well as conferences and meetings.
Now is the era of indie developers.
The issue of earnings is always painful. Each platform has their own rules and profits. There is practically no limit. For example, Minecraft earned about 100 million for 2012. But not all situations are so smooth. According to the well-known statistics of mobile applications, the top 25 developers received half of all profits in 2012. 80 percent of developers get three percent profit. 19 percent of apps earn $24k, and for the 80 percent, $300. Even if your mobile game will earn 100k on iOS, 30 percent of it you give Apple, 30 percent to your publishers, and then you have to divide the rest with your partner and tax.(source: The Game Bakers)
To start receiving more than you would have received in office and still do it all the time, you have to be strategic. I’ve learned to think about games in terms of categories. The first category are the games with new ideas, mechanics, and games with the new features of the devices. These are usually hits. Next on the list are quality sequels of old hits, complete with a bunch of fans and games that can be headed by a certain niche of the market. Finally, there are the games that cover some deficiencies of hits with new features. After that are the clones and trash.
To succeed, you must either make a game out of the first category (like Minecraft and Journey), or make one or two games from the second category (like Shank 2, the successful continuation of the epic Shank, and Limbo), or make lots of games from the third category. Surprisingly, some studios are ready to cope with it. For example, Berzerk Studio, a group of six people, provides great games month after month, almost always on the old mechanics. They have over 20 games. Berzerk Ball 2 went for 100k , and their new one went for 50k, so we can assume that the guys with such strategies have success.
I’ve learned to think about games in terms of categories.
However, I think everything in a game shouldn’t be unique. What should be exclusive is the idea and style. Freedom of game elements is a vise, and there is the possibility of being misunderstood. The human brain is based on past experience, so to enhance the audience’s understanding of the game, you should use images with recognizable patterns. Choose a technique for illustrations, so that it strengthens the idea inherent in the game and matches the audience. If you want to reach the maximum audience, then you need to learn from movies/cartoons with a maximum audience (Shrek, Pirates of the Caribbean, Cut the Rope). Use recognizable patterns and be moderately predictable. In the case of niche games, rules are dictated by the specific audience. Use references for the drawing and screenshots of successful games for the understanding of the principles of drawing, but do not copy.
Games are remembered for their distinctive features: Ideas, graphics, music, and easter eggs. In Alien Anarchy, I did a lot of content, but almost all the comments were about the Easter eggs from the movies that I left. When the player is done with the game, he remembers what can be shared with others: a tough situation, a high score, and funny stories.
Use recognizable patterns and be moderately predictable.
Food for Thought
Indies should remember that an end product is expected. Without a good product, no one cares how much effort and energy was put into the game. The game is above the developer; this is important. If you want everyone to know your story, then place it in the game. Independent developers are asking questions and answers themselves, rather than just doing tasks. This gives them the opportunity to show off their own look. But be prepared for the fact that your opinion is not shared by all, and your game will not be the second Minecraft .
Before you finish the game, it is best to show it to a test group - your friends, family, and colleagues. Do not ask them what needs to be changed in the game. This is the number one mistake. Never ask them. You need to watch how they play. Just watch.
Creating a successful game is consistently making the right decisions, from the selection of the engine and the platform to the last pixel. The secret to being a successful indie is to do what you like. Otherwise, what is the sense of been indie? Make your strong brands stronger and new games cooler.
Currently, George is working on a mobile version of his strong brand, Alien Anarchy, Jim’s Dream, and the new version of Dream Symphony, which will be available to play at Casual Connect Kyiv 2013‘s Indie Prize Showcase.
Starting out AAA games, Jodon Karlik decided he wanted to go indie. With his skills in C++ and Unreal Engine, he created Coding Jar Studios and set out to create unique games. Fling Theory was the first product of this mission, and he describes the road he took to get there.
While working on console games at Propaganda Games (Disney Interactive), the studio decided to spark creativity by holding a game jam. The speed at which decisions were made and functionality came together during the game jam had sparked an interest in me. I made up my mind to leave the console games industry to try my hand at small mobile games. I enlisted the help of my friend, Doug Insley, who jumped at the opportunity to quit his sales job and join me in our adventure to create our first game, Fling Theory.
Jodon and Doug, ready to start!
Enough With the Violence!
After working on many violent games, I knew that I wanted to do something different. I always had a fascination with physics, so writing a simple physics simulator with educational aspects would be something that I’d find fun, and I could feel good about putting it on the market. After a few hours of brainstorming and prototyping, I came up with the idea that you could manipulate atoms to solve puzzles. The initial idea was that you could use electrons, protons, and neutrons to craft specific atoms to solve puzzles. With that, the development of Fling Theory had begun.
Simple Physics
We found that the knowledge range of the users was too wide to tune as a one-size-fits-all game.
The initial version of the game was extremely difficult. The fact that we were trying to teach the concepts of atomic physics while crafting difficult puzzles overwhelmed and frustrated many users. We spent weeks trying to tune difficulty curves and context-specific tutorials which would detect if you were having troubles and give you hints. Ultimately, we found that the knowledge range of the users was too wide to tune as a one-size-fits-all game. We ended up cutting many of the educational aspects in favor of casual game play.
The final version of the game simplifies the concepts to two rules: Opposites attract and like-charges repel. This allows users as young as five years old to enjoy the game and will hopefully encourage users to explore the science on their own rather than trying to hammer it into their head.
Would They Want it?
We were always worried about how the mobile market would receive the game. When we released an early version of the game on the web and received a 3.5 star rating, I decided that a failure in the mobile markets would mean very little to us. Was it the quality of the game, our marketing, or a lack of interest in the subject matter? With a low-rated game, these questions would be hard to answer. For this reason, we decided to redesign a significant portion of the game to achieve a higher quality bar.
We decided to redesign a significant portion of the game to achieve a higher quality bar.
Facing a redesign instead of crossing the finish line is always an enthusiasm killer, and our love for the product was soon diminishing. Furthermore, since we were self-funded, our bank accounts soon ran low and we ended up taking contract work to fund further development. After taking a long hiatus, we returned with a strong desire to polish the product to a higher quality bar.
Since this was our first independent game, we had a lot of questions surrounding our release strategy that went unanswered for a long time. We heard of people making money on all sorts of platforms, and since we were using the cross-platform Unity engine, we tried to port to all of them. This turned out to be a big mistake. The effort required to get the game running at a high-quality bar on many platforms did not make sense financially. For instance, we braved the Unity-Flash alpha and ported the game to Flash in the hopes of getting a sponsorship from a portal site. The effort required to do this far outweighed the highest bid we received, so we decided to hold off releasing on any platforms until we explored the best release strategy. It is best to focus on a single platform first, then expand to further platforms when you’re ready. This gives you time to do the important things like marketing and platform-specific features that make the difference in quality.
Time to Publish
We had many offers from publishers during our downtime, all with dubious terms, including one publisher that made an offer to keep 90 percent of the revenue. Eventually, we resolved to self-publish and were days away from releasing on the Apple iTunes Store, when we finally heard back from a publishing fund we had applied for called App Campus.
App Campus is a joint venture funded by Microsoft, Nokia, and Aalto University in Finland. The program terms for them were quite simple: create a high-quality mobile app and receive funding in exchange for a three month exclusivity period on the Windows Phone platform. We pulled the plug on the iOS release in order to comply with App Campus rules. It turned out to be one of the best decisions we made.
Successful Launch on Win8 & Win Phone 8 Platforms
We met Microsoft and Nokia evangelists at the Vancouver Global Game Jam, who turned out to be amazingly great contacts to have. App Campus flew us to Finland, trained us in how to market our game, and gave us even more contacts. Eventually, we were in contact with the director of product marketing for Windows Phones, who helped create buzz for our launch by showing it off at the Microsoft Booth at GDC. The amount of support Microsoft and Nokia provided is unparalleled to anything I’ve seen. Their evangelist programs are very friendly to indie developers looking to make a big splash on their platforms.
The extra work paid off and our ratings increased.
We launched the game, and the extra time we took to polish the game appears to have paid off. We are averaging a 4.5 star rating on the Windows Phone 8 platforms and saw over 100,000 downloads in the first month alone. It feels really great to finally release a product and be generally praised by the public.
Fling Theory will launch on iOS and Android in mid-September. They would love to hear from you! Contact them on Twitter, Facebook or their website, where they’ve been posting some of their other educational projects, such as game development tutorials.
Barking Mouse Studio is a two-person indie game studio in San Francisco, consisting of Danielle Swank and Jim Fleming. They consider Lost Toys to be their first full game. While both are software engineers and artists, they come from opposite backgrounds. Jim took computer science in college and is a self-taught artist. Danielle took ceramics in college and is a self-taught engineer. Together, they tell the story of Lost Toys.
Danielle Swank and Jim Fleming
Wandering Through Projects
We met when Danielle hired Jim to work at an interactive media agency. From the start, we wanted to work on our own projects together, but finding the right one took a bit longer than expected. Financial management app? Built it. News reader? Yep, several of them. Database GUI? Yup, it’s open-sourced here. With each new project, we learned a lot, but none of them ever felt quite right.
We did a couple of game jams and had a great time making the (often less than) 48 hour games. With every new jam, we would brainstorm ideas ahead of time. Suddenly, we were talking about games all the time. So naturally, we thought, “We’ll make a game to sell on the App Store! It’ll make a million dollars, and only take a month or so!” We barely knew game-making, we didn’t know mobile, and we really didn’t know 3D. It was nearly a year later before we were finally ready to launch our first game.
First Attempts
Our old GUI system, and the first time we were able to play a level.
Our first attempt at Lost Toys was with HTML5 and WebGL (using Three.js). For us, it was a nightmare. It felt like we had to re-invent the wheel, the scene view, the model importer, the audio player, the renderer, the camera, and… you get the idea. We struggled for about a month, and then realized that we needed something that would just work. After noticing a lot of fellow game jammers using Unity, we switched. In addition to being easier to develop in, this opened up a lot of doors for us, since we could now publish on nearly any platform.
In the trough of doubt between the switch from HTML5 to Unity, we questioned our initial game mechanic. It just wasn’t fitting with the aesthetic (creepy toys) and wasn’t as immersive as we wanted. Our budget was too tight to let us hire voice actors. We needed the environment alone to convey our story, and an unsettling theme can convey a lot of emotion. In the end, we drew inspiration from a lot of sources like Leonardo DaVinci to Apple to the San Francisco Exploratorium and games like The Room, Zen Bound and Cogs.
Scope and Resource Restrictions
We made progress, but the build was still really unstable.
Neither of us has any audio background, but we know the value of it. It was important to us not to compromise the game aesthetic. Having no soundtrack was better than having one that didn’t fit, and the budget wasn’t there for something custom. Fortunately, we found the beautiful, classical and free Creative Commons licensed work of pianist composer Peter Rudenko. We’ve listened to “The Fall” about a thousand times during development. It’s one of our favorite pieces of music ever, and it fits the tone and aesthetic of Lost Toys perfectly.
We also didn’t have the budget for any kind of custom audio samples or to hire a sound engineer. We looked at a number of websites that sold or offered free stock audio. Most of the sites didn’t offer trial samples, and we needed to playtest different sounds as cheaply as possible. Pond5 was great for this, we could download watermarked audio clips and see if they matched what we were going for.
Since the game needed to be as immersive as possible, we felt that everything should be a part of the game world - including the GUI elements. At first, we tried to make everything skeumorphic, “physical” elements of the game. The first version of Lost Toys was more of a ghost story with little “wisps” that flew around and “oozed” off of the toy at the start of each level. Made up of little puffs of glowing smoke, wisps were ethereal “undo” buttons. Unfortunately, the wisps complicated the code and gameplay quite a bit. None of our playtesters understood what to do with them. So they fell into the dung heap of history, in favor of a minimalist on-screen GUI. Surprisingly, we found that the new GUI helped players remain immersed in the game because they didn’t have to learn how to interact with the wisps.
For us, building a 2D game was never an option we considered. Neither of us are 2D illustrators, and Jim had some old experience with 3D graphics. Plus, we really like the aesthetics of minimal but realistic games (think Zen Bound and The Room) and enjoy puzzle games like Cogs and Flow that take advantage of a touch interface. Because of our 3D requirement, keeping development time under a year was very hard work. We ruthlessly limited the scope over and over again. Despite this, our main rotational mechanic in this “simple” game took three months, several revisions and many individual attempts before we pair programmed a solution.
Getting The Word Out
Why do we need a trailer? We’ve got a laggy video of the whole first chapter!
Lost Toys is our first attempt at a professional game, and rotational math was only one of the many things we didn’t know how to do when we started. We had no idea how to market or distribute a game. We just assumed that was what app stores were for. Fortunately for us, we live in San Francisco, where there is a wealth of established indie developers that are incredibly generous with their time and advice (thank you, thank you, thank you!) Many of them we met through our local IGDA chapter, which is a great organization to join if you’re interested in indie game development.
The biggest advice we received was to start reaching out to potential players immediately. To do that, we needed a great trailer. Like with the rest of our game, and indie development in general, we didn’t have the budget to hire someone to make our trailer. We had to figure out how to make it ourselves with zero film-editing experience. It took us about a week of studying movie trailers to come up with a rough storyboard. From there, we needed to figure out how to make what we wanted. The solution we came up with was to turn exported image sequences into movie clips. The problem with this method is that in-game audio can’t be used. To get around that limitation we borrowed a trick from all those movie trailers, and have a single piece of music playing throughout the trailer which helps tie together all the different bits of gameplay.
Everything Comes Together
The finished trailer
So here we are, almost a year from when we started. Lost Toys won “Most Promising Game” as part of the Indie Prize at Casual Connect, and we’re launching on iOS at the end of October with Android and BlackBerry to follow. As part of the process, we learned to say “no” to every idea we had that wasn’t in direct support of launching a solid game and that building the game is only half of the job.
You can keep up to date with launch notices for Lost Toys by following them on Facebook or Twitter.
Ruth Wilson is a communications consultant based just outside Manchester. Operating regionally, nationally or internationally, Ruth Wilson PR promotes products and services across consumer and business markets. Her article discusses the views of couples working together in game development, as seen by 100% Indie.
100% Indie helps Android indie developers worldwide get published, and noticed more couples working on great games.
Creating a game is a personal process. It’s full of passion, sometimes a bit tense and even - dare I say it? - a bit frustrating. Much like marriage, some might say.
But 100% Indie, the team helping Android indie developers worldwide get published, has noticed more and more couples working on some fantastic games. Marriage extending into the app marketplace is a noticeably rising trend
So what’s their secret? Is it down to chemistry? Or would game developing couples (Devouples? Decoups? Gooples?) advise you to stay solo or work in a larger team, for the sake of your sanity?
Alix and Calvin of Robot Loves Kitty
Alix Stolzer of Robot Loves Kitty believes it’s a recipe for success. She and her husband Calvin Goble have been creating games together for over seven years and have a strict work-split to ensure maximizing productivity and harmony. The Robot Loves Kitty website sums up this division of labor quite well, listing Calvin’s title as “Game Dev,” while Alix takes care of “Everything Else.” As she says, “The programming is all Calvin, and the business and marketing is all me.” It’s an arrangement that clearly works well; their project pulled in almost $33,000 USD on Kickstarter back in mid-December of 2012, well exceeding their funding target of $5,000. The key for Alix throughout? “Coffee and communication!”
Emilia and Paquale of Sparkling Labs
Emilia Ciardi, of Sparkling Labs, agrees that bespoke roles are necessary: “I’m a developer and graphic designer, while my husband is a strong coder,” she says. Their first game together, Liv’s Cupcake House, was one of 100% Indie’s first 30 Indie Heroes, promoted at E3, GDC and Develop. The couple have ‘day jobs’ in the games industry and are already working on two more titles, both of which they plan to launch as Samsung Apps through 100% Indie as, being a small company (“We’re just a team of two”), they found themselves somewhat lacking on the marketing side. “It was helpful to work with a third party like 100% Indie, who can advise on any tweaks and help you get self published as opposed to just getting lost,” says Emilia. “Marketing the games and showing them off is so valuable, as share of revenue streams can be useful only if the games themselves are visible and have actual chances to be discovered. This is a learning curve that we’ve found incredibly valuable.”
She sees herself as the creative force while her husband Paquale is the practical motivator, keeping things focused and energetic – and with day jobs as well as the odd creative slump, motivation is a key factor in game creation, as any developer will testify. “We try to be an inspiration and motivation for each other,” says Paquale. “As a real life couple, we should be pretty accustomed to that, shouldn’t we?”
Ville Mönkkönen of Instant Kingdom agrees that working with your partner can really help in a slump: “My biggest development enthusiasm only ever lasts for about two weeks when I start a new game,” he says. “After that, it’s mostly work, and I have to force myself to it daily. To me, it’s tremendously important that I get to share ideas with Anne in the evenings, watching a movie, or when taking a walk. She always finds a way to encourage me.”
Ville started making games in 1998, but Anne, a trained psychologist, came to the game world a little later. The Finnish couple’s Driftmoon took seven years to complete, and they admit it was a challenge at times: “It’s not very easy, that’s for sure, especially with two little kids,” says Anne. Ville agrees: “Much of the time during those seven years, we managed to only get about one hour per day to work on the game. Fortunately, I received the Sammon Tekijät Award, which enabled me to take some time off my regular job. That extra day per week did a lot for getting the game done, as Anne was also at home with the kids during the last two years of development.”
Ville and Anne of Instant Kingdom
“Working and developing games is an incredible challenge,” agrees Alix of Robot Loves Kitty. “It’s very hard to motivate yourself to do something when you’re tired after a long day of work.” She and Calvin had a unique solution: “We decided to live in a tree house for a few years, not only was it a massive adventure, but we could both stay home all day.”
“I honestly think we still have to do some work on our life/real work/indie dev balance,” says Emilia of Sparkling Labs. “As professionals of the mobile industry in our real work, we can have very hard days. Of course, this is what pays our bills, but it comes with a price - some days we just don’t have enough energy to devote to our indie games. I think in the future we could be looking for funding.”
The rewards are clearly worth it though, as Anne from Instant Kingdom says: “After all the work, love, tears and sweat we’ve put into Driftmoon, it’s been extremely rewarding to read the lovely messages we’ve received, and notice that we pretty much hit our goal of making a game that would brighten up its players’ days.”
So for any new game developing couples, the advice from others in the field is to stick with it and enjoy it as much as possible.
So for any new game developing couples (I’m going with Decoups), the advice from others in the field is to stick with it and enjoy it as much as possible. Emilia says: “You should try to bring together the best of each of you and start this new adventure with a playful and open mind.”
Anne agrees: “Always remember to keep your relationship (and any possible kids you have) first. Be supportive, constructive, honest, persistent, and merciful towards each other, and remember to take regular breaks off working as well.”
Alix advises: “Learn how to criticize and take criticism in a way that lets you both be completely honest about the state of the project. This is an amazingly valuable strength that often requires a stronger bond than most. Communicate.”
And finally, Ville’s top tips: “Start small, make your first game something that you can finish in a few months! And definitely find an idea for the game that both are eager to do. If you’re in game development to become a millionaire, start thinking about a change of plan!”
Indie developer Pixelbionic has a lot going on this week: Its game gets a name change, a new designer behind the wheel, and a just-launched Kickstarter campaign seeking $650,000 in funding in the next 31 days.
Pixelbionic’s game started life earlier this year as Autoduel, an online combat car game that sounds like a cross between Twisted Metal, Interstate ’76, and Guild Wars. Players customize cars and form teams to do battle and complete other objectives to earn more customization options and materials. Co-founders Mike Arkin and Maxx Kaufman were later joined by Twisted Metal creator David Jaffe and Interstate ’76 creator Zack Norman, for an extra dose of authentic car battle game DNA.
Now renamed MotorGun, Pixelbionic’s team picks up Gears of War and Unreal Tournament Lead Designer Lee Perry to uphold the creative direction of the game and bolster its battlegrounds. Perry plans to design an exclusive battleground for backers as part of the campaign’s stretch goals.
Navigating Kickstarter for a first-time developer isn’t easy, but Pixelbionic has a wealth of successful games campaigns to learn from. Co-founder Arkin (pictured, right) told Gamesauce that the team even received personal mentoring from Wasteland 2‘s Brian Fargo (which closed with over $2.9 million in funding on a $900,000 goal) and HEX’s Cory Jones (closed at over $2.2 million on a $300,000 goal).
“We are very lucky that there have been some great Kickstarters before us,” Arkin said. “We’re trying very hard to take all the lessons that those people have communicated to us and use the advice wisely.”
Over the last eight months, Arkin and his team have planned out goals and rewards for its Kickstarter campaign. Aside from Perry’s exclusive battlegrounds for backers, the upper tiers of funding grant backers exclusive cars as well as access to the beta and even the alpha version of MotorGun. Lower tiers get access to the game when it launches and an MP3 of the game’s soundtrack.
The stumbling block many first-timers encounter is pledging more than they can deliver either in content or physical rewards. Arkin says the team is aware of this obstacle and that he and Kaufman have done the math to avoid it.
“Max and I are experienced developers and we’ve planned the project and budgeted very carefully,” he said. “We’ve been conservative about the features that we’re promising and the stretch goals where we can announce new features we’ve already planned.”
MotorGun is targeting an October 2014 release. After the Kickstarter campaign closes, players can still pay for the game or make donations on Pixelbionic’s site.
“Once it launches, we plan to add content – more battlegrounds, more vehicles, more parts, more game modes,” Arkin said. “We plan to keep adding things… until we stop.”
Look for Arkin at Casual Connect this month during the Day 3 Free 2 Play track and on the floor of the Indie Prize Showcase.
Paladin Studios is an independent game studio based in The Hague, The Netherlands. The company was founded in 2005. In these years, they grew to a team of 10 developers coming from different backgrounds - design, animation and coding. Paladin Studios usually worked on contract-based projects. But apart from client work, they’ve always wanted to be an independent developer and create and publish their own games. Momonga is their first big self-published game.
In 2010, with the rise of the App Store in full swing, we felt the time was right to work on our first game. We wanted to start small, so we set our minds on developing and publishing an iOS game in two weeks. We started from scratch with an idea and our brand new Apple developers account. After two weeks of concepting, arguing and developing, we submitted the game to Apple. These weeks were just one gigantic learning experience, which laid the foundation of Momonga.
So there you had it, our first game on the App Store. We made it, we can do it! Now it was time to take things more seriously.
Game selection
One game caught their specific attention - it made their eyes twinkle and some even played the prototype for 45 minutes straight
With Jimmy Pataya and earlier prototypes, we underestimated the importance of a game concept and its selection. We had several concept-candidates for development, but lacked a good selection procedure. This led to discussions and fistfights, but most of all; it left the team with the feeling that this might not have been the best choice for us. So we figured we would not just start coding away on a big project. We needed a more formal selection process to get everyone on the same page.
For this, we used the stage-gate method as a starting point. In the stage-gate process, each stage has a “kill gate” where concepts get trashed based on predefined selection criteria. Everybody on the team had one week to bring in his or her ideas. At the end of this week we had a hundred ideas. What followed was a big pitch and vote session, which resulted in 10 remaining designs that we took to the next stage. We rated the concepts on different aspects, like innovation, feasibility, monetization, strategic value and remarkability. Eventually, we were left with three game concepts.
This is what the prototype first looked like. You can still play it here: http://www.teampaladin.com/pinball/
We developed a prototype for each one and invited testers to come over and play those prototypes. They sat down and played the games. One game caught their specific attention - it made their eyes twinkle and some even played the prototype for 45 minutes straight, trying to beat their scores. That game happened to be a prototype called “Pinball Forever”. It was an unexpected winner, and the start of a journey that lead to the release of Momonga Pinball Adventures.
After analyzing the prototype, we decided to drop the infinite game design and instead go for a level-based design. With a level-based approach, we had full control over the levels and could use that to dig deep into the story. From this point on, you could say the game was called ‘level-based pinball’, with a storyline.
World building
We started with building the world’s geography
The first step in building the story was to create the world in which the story takes place. When you look at international politics, the “Grand Strategy” theory concludes that every nation has specific needs for a sense of security. These needs are determined by the geographic differences like mountains, oceans and deserts. That is why we started with building the world’s geography. Drawing a map from scratch gave us poor results - so we looked at different random map generators, ranging from Civilization to Minecraft. We ended up settling on the map that was created by the Minecraft map generator.
Our Minecrafted Momonga world
The Grand Story
With the geography and politics in place, we could start writing the grand storyline; what was the main conflict in this world? We needed ‘one ring to rule them all’, ‘the darkside’ or a ‘Voldemort’ in our story. The epic conflict in the story, where we would base the much smaller game story on, was decided as:
The continent Aya has seen peace since the Great War. The civilized world is ruled by the Guardians, powerful animals who have sworn to protect the Element Sources. However, the Great War has left some species scattered and exiled. These Shadows live as outcasts, on the edges of civilization, waiting for their turn to come to once again overthrow the Guardians and seize the Sources. While the Guardians grow weak in their cities, the Shadow animals grow stronger in determination and strength.
This grand story sets the stage for the game, and it gave us a foundation to craft the game experience and characters.
Characters
Next up in the process were the characters. Based on our grand story, we decided to create characters by asking ourselves a couple of questions:
● What is their history?
● Where do they live?
● Who are they hanging out with?
● What events impacted their lives?
● What special abilities do they have?
● What do they look like?
Of the four characters that resulted from this process (Momo, Fry the Firefly, Panda the Panda and General Kuton), we’ll briefly introduce Momo and Fry the Firefly.
Momo
Momo is our hero. Born and raised in the Momonga village, he lived a peaceful and carefree life. One day, a band of owls burned his village and took away his tribe. Momo barely survived the attack, and was saved by Panda. As the last free momonga, he sets out on an epic journey to defeat the owls and free his family.
Even before the game story begins, Momo already made an epic journey. He came to life as ‘Dash’, the little red ball with big eyes in Pinball Forever. When we switched to level-based pinball, we redesigned him. The world of Momonga back then was a universe centered around vegetables, with Momo starring as a radish battling evil broccoli, potatoes and pickles.
Radishes are tasty, but we felt that it might not “stick” with a casual audience. Fortunately, we were hooked on a website called cuteoverload.com. Our CEO remembered a picture of little cute animals sitting in a tree, that looked like they could roll up like a pinball. After going through several dozens of kittens, puppies and baby hedgehogs, we finally found the picture.
These cute little buggers are Japanese Dwarf Flying Squirrels. Japanese. Dwarf. Flying. Squirrels. We never looked back: we had our hero.
Fry the firefly
Fry is a firefly from a lineage of martial art masters. His father is the head of the Ha Chi Order, and one of the finest firefly warriors. Fry, however, failed to live up to the expectations of his parents: he was defeated by a bunny that he was supposed to chase away as an initiation rite. He left his hometown because of shame. After leaving his town, Fry got caught by the owl bandits. They used him as a light bulb for the owl camp. Bummer.
The final in-game model shows bright colors, big eyes and a “let’s go!” attitude.
In Momonga, you save Fry from a lightbulby life, after which he becomes your trustworthy sidekick. Fry is heavily conditioned in the firefly school of martial arts, and he goes into a frenzy whenever he hears a ringing bell. This comes in handy when you have to defeat a whole bunch of owls.
Real fireflies are red, and very ugly. The first sketches were fairly close to the real thing, and pictured a fat, lazy firefly. This didn’t really work, because nobody wants to drag around a fat firefly while playing pinball. So instead we made Fry an energetic and cute little bug.
Pinball Physics
One of the hardest things, and something we underestimated the most, were the pinball physics. Once you are dealing with pinball mechanics, it means you are dealing with very high speeds and collisions. The fact that the game needs to perform well on a mobile device only made it harder for us. We came up with the following solution.
The basics are simple. You take a ball and flippers, set up a table at an angle and let gravity do the work. It didn’t take long before we got the basic setup working and were able to shoot some balls. But the tricky part in physics is always in the details… and this is where you go one step forward and two steps backwards.
In an ideal world, the player has full control over where the ball should go, and the ball can go just about anywhere. However, we quickly found out that some places were impossible to reach. The angle of the ball was limited; it was very hard to get the ball to the sides of the level.
But the tricky part in physics is always in the details… and this is where you go one step forward and two steps backwards
The movements of the ball involve quite some variables, which can be manipulated in order to enable better control of the ball:
- Flipper rest angle
- Flipper maximum angle
- Flipper strength
- Flipper material (friction, bounciness)
- Ball material
- Ball weight
- Ball drag
- Table material
- Gravity strength
- …and many more.
Changing any of them affects the whole game, and this is where game physics starts to hover between science and art.
We created an isolated test setup to determine exactly how all these variables influence the ball trajectory. In this test, a ball gets spawned every couple of milliseconds, and the flipper is activated automatically. We then traced the ball to see where it goes. Now we could change one setting at a time, and see clearly how it affected the ball trajectory. This, combined with several prediction and correction algorithms, made the physics work well enough for the critical consumer.
The things we learned
Momonga was our first “serious” self-published game, so there were a lot of things we learned the hard way:
Don’t underestimate marketing. Something you have probably heard before. Marketing takes a lot of time and needs a lot of funding. Publishers have the money and the time, you don’t.
You can self-publish a game and do successful marketing for it, but your game has to be remarkable for anyone to talk or write about it.
Making a pinball game is hard
Creating a game takes longer than you think, especially when you are bootstrapping your way to the launch. And yes, even when you take this into account, it will *still* take longer than you think.
The odds are against you when you launch a paid download on iOS.
Think about your business model and target audience in the early phases. The decisions you make will impact every design choice along the way. We chose a story-driven, level-based game, so the game had to be a premium download. If you want to go freemium, make that decision from the start.
The story and world you create can be a great foundation for your future games.
Good level design takes a lot of time. No, really, a *lot* of time.
Momonga in numbers
So how did we do? Here are the results, six weeks after launch on iOS:
- Our invested budget was around $250k
- Momonga has been downloaded 39,577 times, with a total revenue of $33,530.67.
- Momonga has been played by 69,075 unique users. 39,577 came from the App Store, so we have 29,498 illegal folks (43%).
- We got 199 user reviews with an average rating of 4.35
Despite excellent critical reception and positive reviews, Momonga did not break even by a long shot. There are several reasons for this, all of which we are going to address in our updates:
- The game is short and sweet, but still rather short
- There are no viral features, no way to spread the word
- There is no way to try the game for free
- It is a great game, but perhaps not perfectly suitable for the mobile market
- It is too difficult for some people, and too easy for others
Currently, Paladin Studios is working on a v1.1 patch for Momonga, which will contain extra content, Facebook leaderboards, and several other tweaks. To see what they’re currently doing, you can check out their developers blog, Facebook page, or Twitter.
