Based out of Los Angeles, The Hohng Company is a one-man development studio created in 2011. Sangwoo Hong, the man behind the company, had worked with entertainment industry leaders such as Pixar, Squaresoft (now Square Enix), and Electronic Arts, but decided to break out on his own as an indie. After making a few games on his own, he teamed up with a partner to create The Asteroids Are Coming!, available for iOS, Android, and Kindle Fire.
Starting Off and Finding The Tools
Ever since I got a Commodore 128 as a birthday gift, I’ve been interested in creating my own games. I’ve fiddled with too many pieces of tech to remember since then, but I eventually found the one that works for me in early 2011. The years I spent banging my head against XNA paid off. After watching some tutorials, I grokked Unity3D and saw that I could make a game with it for real. So I did…or so I thought. I made prototype after prototype, but then I ran into a problem. I realized that I wouldn’t be able to finish any of the prototypes, at least not in a reasonable amount of time for me to be able to make a living doing so. I realized that I needed to explain to myself what I’m doing and why I’m doing it, or else I won’t be getting anywhere fast.
I realized that I needed to explain to myself what I’m doing and why I’m doing it, or else I won’t be getting anywhere fast.
Game Tiers: Seeing My Place in the Industry
By now, you might be wondering what does any of the above have to do with The Asteroids Are Coming!, the game to which this article is supposed to be a postmortem to, as well as what I mean by a Tier 2 game. The Asteroids Are Coming!, or TAAC for short, is the fourth game I’ve released since my first game Cubistry in August 2012. I’d like to think that a single man company putting out four games in a year and a half with just one external collaborator is pretty good. But things could have easily gone differently. I might still be hacking away at some unfinished game with no end in sight. But I knew I didn’t want to do that. I needed to ship games in order to start building up my business. And the thing that helped me do that is seeing my place in the game industry’s scheme of things, to know what tier of game I’m capable of creating for now.
I’ve released four games since my first game Cubistry in August 2012.
I’m not sure exactly when I started seeing things in tiers. What I can say is what I consider to be, at least for the moment, the five tiers of games that are out there.
-Tier 1: These are very simple games with a single game mechanic. Good examples would be the original incarnations of Tetris, Bejewelled, Columns, etc. This tier also includes many classic early console games like Missile Command, which of course has a direct connection to TAAC, a Missile Command-like game with Asteroids.
-Tier 2: These are simple games with a meta game component. TAAC fits here because it has missions to accomplish and ranks to earn. A very good example of a game in this tier is the wonderful mobile game 10000000, which was the direct inspiration for adding the meta game to TAAC.
The Asteroids Are Coming is a Tier 2 game
-Tier 3: These are games irrespective of game mechanics that have a certain amount of content which would be too much for a couple or even three or four people to put together in a reasonable amount of time. An example of this tier of game would be the excellent mobile game The Room.
-Tier 4: Games in this tier are what would have been “AAA” back in the days when single player games ruled the roost on consoles. Games like Resident Evil or Silent Hill come to mind. Early 3D games like Super Mario 64 and Legend of Zelda: Ocarina of Time do as well. One would definitely need a larger team, say 10 or more, to accomplish games in this tier in a reasonable amount of time.
-Tier 5: Sky’s the limit once you arrive here. Anything and everything which is now referred to as “AAA”, from the Halo series to League of Legends, which literally takes hundreds of people to put together and maintain, fall into this category. Obviously not something for the “traditional” indie developer.
Once I began to see games in tiers, I quickly came to see that the prototypes I put together were for Tier 3 and above games, with no chance of being finished by myself.
A Fresh Start
Once I began to see games in tiers, I quickly came to see that the prototypes I put together were for Tier 3 and above games, with no chance of being finished by myself. I needed a clean break and a fresh start. So I put all those early prototypes aside and started from scratch. I created Cubistry in a month’s time and shipped it first on PC, then on Android and iOS, and it’s been keeping the lights on for me since. But the goal for me is not to make Tier 1 games for the rest of my life. I needed to move on to the next level and that’s where TAAC came in.
After completing my last Tier 1 game, which is a simple free-to-play game called Fairy Artillery (a more direct clone of Missile Command with a fairy theme), my art partner on the game NVS Pixel asked if it would be okay for him to work on a space-themed reskin of Fairy Artillery. Having seen the quality of his art work and the professional manner in which he delivered them, I jumped at the chance to work with him again. And being a big fan of 10000000 by then, I decided to take the plunge in to Tier 2 with TAAC by adding the meta game component.
My art partner on the game NVS Pixel asked if it would be okay for him to work on a space-themed reskin of Fairy Artillery.
TAAC of course is not the end, but rather a stepping stone. I will take what I learned from TAAC and apply it to my upcoming games. Some of these games are Tier 2, a few are Tier 1 still, and there are even Tier 3 games which are now spinning up with new found partners, thanks to the success I’ve had in Tier 1 games. Will I ever attempt a Tier 4 or 5 game? I certainly hope so. But for now, I am content in knowing that I am continuing to grow as a game maker because I’ve made the choice to take things one tier at a time.
The Asteroids Are Coming! is a stepping stone.
Sangwoo Hong is currently busy working on his first Tier 3 games, Space Chicks and The Tomb. You can find out more about Sangwoo and his current and future projects by visiting http://hohng.com.
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.
This article was written by Sergey Babaev, Creative Director of GD-Team.
Hello everyone! Recently, GD-Team began the development of MO-shooter Metal War Online. The project seemed to be a multiplatform one, meaning it will unite all the gamers with browser and client versions. Metal War Online has run only in Russia as a stand-alone client game and a social application. Over time, we decided to enter the global market via Steam. Like many of our colleagues, we realized this project via Greenlight. We devote this article to our experience of getting approval.
Please note that we don’t pretend to any creative and innovative approaches. We saw some simple and available communications gap on Greenlight, so we collected all the points together and show their importance for reaching the main result – getting the Greenlight! This consists of two parts: the approval process (advises, mistakes, etc.) and the early access (results, measures).
Is it Possible to Go Without Greenlight?
If you are not a big publisher or if you don’t have any friends who deal with the top-management of Valve Corporation, you can forget about getting directly to Web Services.
Let’s be realists. If you are not a big publisher or if you don’t have any friends who deal with the top-management of Valve Corporation, you can forget about getting directly to Web Services. Even if you deal with regional or local managers, they will only compliment your project, express their happiness to work with you as potential partners, and ask you to get through the modest approval on Steam Greenlight.
Don’t take it personally. There is not much choice: it is either supreme privacy or attempts to form some self-regulation procedures and filtration of incoming requests. You could possibly avoid the approval, but let’s suppose this measure is an impossible one and don’t take it into consideration.
What Does the Public Like?
Getting on Steam shouldn’t and must not be your end in itself.
Now for the favorite question of all developers: what can we do to get on Steam? This is the wrong question, and it leads to many dangerous consequences for developers. Don’t try to find favor in the eyes of the platform. Getting on Steam shouldn’t and must not be your end in itself. You can give the look to the audience, you can manipulate the understanding of your project, but you needn’t repeat the games which have already gotten the Greenlight and ARE waiting for release. Here are the reasons:
The public probably doesn’t want the same game project.
You don’t know how the game will operate after release. The service of “games access” isn’t a shop. You can’t be sure that by getting through Steam, the project will collect good feedback and money for release. And the other way around, it doesn’t mean that the project can’t be a successful project without Steam. Greenlight is some kind of Steam level. It expresses the whole trend in the Greenlight-community. This group of users bought time to look through games which would never be released with Greenlight, allot the marks, and comment. They are like aid men of their favorite social medias, saving 90 percent from spam information.
If you try to duplicate the success of any other game projects, you may face comments like “downvote for the same one”.
We are not going to discuss deeply some main questions. We believe that each developer will decide if its project can pretend to be a successful one or not. We are just trying to allay concerns which face developers during preparation for Steam.
Preparation
So you are going to bring you project to Steam. First, you have to register by paying $100 and filling a form. Let’s divide the process of statement into some main parts and try to explain general mistakes in each one, because the first days in the catalog of specialties are the most active. Even if you can find an extra source of votes, you can’t maintain the same level of interest to your game for weeks.
1) Media Content
Preparing Metal War Online for Greenlight, we decided to post some of the most beautiful screenshots and our launch-trailer, quite stylish and dynamic demonstration, especially for F2P-projects. But here we faced the first catch…
Our Russian launch trailer
The first mistake…and it wasn’t mistake at all… was that the trailer was only in Russian. The soundtrack was made by Russian actors, and it consisted of Russian text. We didn’t consider that it was the first reason of negative understanding by gamers. We received comments like, “They just didn’t try to translate the trailer”. That’s why we didn’t want to waste time with translating the soundtrack. We had prepared for negative comments, but suddenly we saw quite nice ones: “Finally, it’s perfect Russian speech”, “We are tired of warped words”, and “The game is by Russians, and it is so cool!”. Some gamers thought that we just saved the style of Russian military negotiations and tried to interpret them for gamers.
We don’t advise you to repeat this event. Effect of such activities can be different and you can hear the same comments like “They just didn’t even try to translate”. If you have some Russian soundtracks, it’s better to add English frames – subtitles and translations. In this way, the gamers will understand that it isn’t the result of you poorness or laziness, but that you try to convey your own unique atmosphere.
If the enthusiastic gamers fixed their eyes on the trailer, the most hyper-correct ones wanted to look through screenshots because these screenshots are the unique demonstration of the live game. What they ended up seeing: Russian text in chat, Russian elements of interface, Russian indicators on speedometer. They didn’t accept the project. They decided to look through the application form in order to find some information about localized languages. More patient games gave some comments, and others commented with a “downvote”.
Comments regarding our Russian trailer
This little mistake created several thousands downvotes. But later, we corrected. We posted the screenshots without the interface. These screenshots looked more subjective and didn’t consist of provocative information. You can also use fake screenshots with localization as promo material.
Screenshots without an interface can be useful on Greenlight
If you are going into the international service, you need to prepare an English version and, even better, German, Spanish, and French versions. There aren’t many words and verbal cues in our project, so we could do the localization quickly and inexpensively. We realized our mistake, and we began the localization of our project in four more languages except Russian.
Another mistake was the gameplay. It’s the most important point, but we will not pay much attention to it because not every project has a good and useful build for making a video for Greenlight. Many times, the gamers saw a lot of perfect screenshots, but later found out that these screens were just fake promo materials. That’s why they don’t believe the screenshots as a demonstration of gameplay. Also, they don’t believe the CG-trailer provides insight into real gameplay.
More negative comments we received….
If you don’t have any gameplay video, the gamers may doubt your project because they think you only have screenshots. Of course, such projects can still get the Greenlight. Still, you should try to make a video. Ordinarily, there are several demo scenes from the engine. This shows how you are progressing and developing. Speaking from the perspective of developers, such scenes can lead to negative comments and points of view. The users will be able to understand how much money and powers you have spent. It’s definitely easier to make a demo scene than paint a fake screenshot. It is important for ordinary users to understand if such a project has any chance for success. If you can’t make any video or promo materials, then the Steam approval should probably not be the most significant aim.
Another point to look at is multiplatform. You have to appreciate it, especially if the engine’s authors decided to support it. For example, look at Unity3D. It isn’t perfect (if we speak about service and support), but qualified specialists will make your game for any platform. It’s stupid to ignore an opportunity to reach a whole category of users. Some of them react to the absence of their favorite system very bluntly:
Linux is just one platform users want….
We aren’t saying to promise everything to users, because unfulfilled promises on Steam aren’t the right tactics. You have to estimate your resources and the opportunities of chosen technologies. If the engine is multiplatform, it’s better to think of a Linux version and its start. If the technologies and resources don’t give you opportunities to make everything like you want, we advise you to inform them that you are preparing a version release for some platforms during the months after your start on Steam. Also, you should name these platforms. In this way, you can collect hundreds and maybe thousands of upvotes.
2). Title and Description
Our description looked like typical promo text, but everyone has their own point of view about effective text. That’s why we don’t aim to give you any experience in this sphere. However, here are some simple rules that may help you avoid problems:
If the project is in the development stage, you need to indicate the dates of the main levels: close alpha, open alpha, closed and open beta testing and etc. You can construct a diagram, if necessary. People don’t want to pay for obscurity. If the project is in close beta testing, you should refer people to your site where users can find out information. The gamers can’t get into this level, but they begin to understand that it works. If the project has already started in one region (in our case, Russia), you must inform the users. Call the number of gamers and the places where the game has been started (in our case, it’s social media).
You should also specify system requirements. Although nowadays nobody takes into account system requirements when starting to play, they calm the users. The users will think, “If the guys know how their game works, it means that the tests were held.”
We have used such a logo where our reconnaissance equipment Chimera looks like a head of manlike robot.
And the most important part: you need to provide a description of your project in all the languages which you localized in. Unbalance and disparity leads to misunderstanding and doubts from users, meaning they will probably not be clients.
During the fulfillment of your title and description, you will be offered to choose an icon. We suggest that you shouldn’t abuse GIF-animations. You will be in the list of news even if you don’t have cool animations and perfect colors. It’s better to choose a good big logo to mystify the users. We have used such a logo where our reconnaissance equipment Chimera looks like a head of manlike robot.
After fulfilling everything, you will be published on Steam Greenlight. Now it is up to everybody to see and critic.
Work with the Community
Now you are at the beginning of a difficult road. You’ll have to face the gamers who have their own opinion about all the details of your project. It’s better to prepare for unusual critics – from dubstep in trailers to disgust towards F2P. People can say “no” to your long service only if they don’t like the music in trailer! It’s a harsh world!
And the negative comments keep coming….
Don’t despair! You did nothing bad. Sometimes, you can’t talk around your opponents. They are using their right to judge subjectively about content and are trying to exclude any aggravator. If they don’t like dubstep, the best you can do is load another soundtrack from the game if possible. But unfortunately, all your attempts will go to waste. Don’t play with moody gamers. You should try to connect with those who are making contact. Let’s consider some ways to connect during your time on Steam Greenlight.
First of all, you have to discuss the special aspects of your project. All the MO-games which include any technical equipment have one meme wrangler – the users see futuristic clones. We wasted a lot of time discussing all the special characteristics of our project to the gamers.
….but good comments come as well!
This doesn’t mean that you need to poke holes in or try to criticize the same projects. It’s the wrong way and leads your comments to flood with showdowns and mutual disses. Such a situation will create negative understanding and will influence the opinion of other gamers about your project.
Another famous style of trolling is to offer excuses. Who is offering excuses usually seems guilty. You always need to hold your position. If necessary, you can mention that your team isn’t big, and you can’t meet the needs of all the users. If the project gets to Steam, you will have more resources. It’s more difficult to talk in such way, especially if you are launching a fundraiser campaign in one of the crowd-funding stages.
Remember: don’t delete the comments. There can’t be perfect comments. Only inexperienced developers can dream about them, but others avoid such fact. There should be critics, good feedback, and arguments in your comments. You must instill order only in that way if you see that there are a lot of haters in comments from other groups or games. In all other ways, don’t remove the comments. Just take a breath and ignore the negative words.
Attracting Traffic
Gradually, the number of limited traffic of Greenlight came out:
The yellow line represents the number of visitors (not more than 50 per day). Less that 40 of them vote and only half of the visitors vote for. But these factors are not as important. The number of visitors isn’t so presentable, and you can’t collect 17-20 thousands of upvotes in such a situation. A demand to attract new users aroused. We decided to do it and faced some mistakes and problems.
The 1st Mistake: Attempting to Attract an Unknown Public Page
We placed a banner to attract the community
The most obvious way to attract new users is to place interesting banners on game resources.
We can’t say that such placing was ineffective, but the number of new users was poor. Then we remembered the social aspect of our project, which is more active. We posted an inset calling to vote for our project in the main news of the page. The mistake was that this call was understood as advertising and aroused resentment. The number of profile views and votes rose, but the proportions were the same.
Was it possible to attract social traffic properly? Of course, yes. You could just include in the news feed information about your project, attract the users to play in social version and than offer voting. Also, you need to inform them that it is the project of one team and not any registered post. Later, we held some activities. The quality of traffic from our other projects improved. The number of votes also rose.
We kept trying different ways to attract votes
The 2nd Mistake: “Administration is spoiling the game. Downvote!”
The second mistake was our attempt to attract the users to vote for the social version of Metal War. The gamers can vote only in that way if they bought something at least once on Steam. It affects the public, which can influence on your project and opinion about it. When we called the community to vote, the traffic suddenly rose. But there was a problem in the social version. Haters began threatening to revote or something similar. The haters always use the thunders if they don’t like some negative activity. But, don’t despair too much. It’s just a negative fact for the group and its moderators. Several times, we saw some misbalance in votes, but it was the result of such thunders.
The 3rd Mistake: Not Ready to Vote
Like many others, there is an original news digest in our project, and can be seen upon entering the game. We decided to post the news about voting, but there was only one problem: The digest was shown to everybody, including the new gamers who just started playing. They either were not ready to vote and just close the digest or were displeased by the project and ignored the voting. What’s worse is they could just vote against it. That’s why mobile game developers ask you to estimate the application. They want to do their best to remove all the negative factors. We thought about it late, so we lost part of our gamers. But we realized our mistake and offered the vote option after some successful levels in the game. That led to a 70 - 90 percent increase of votes for our project.
The Results
With the mistakes, we did lose some traffic, leading to a lot of downvotes and difficulties in getting the Greenlight. The diagram of voting pattern in several days was the following:
The first day, the number of downvotes was 845 among 1700. The next day, the number rose, and the traffic began to fall. In about four days, the number of reviews was less than 1000, and the number of downvotes still rose. Only in 1 - 5 weeks did the situation changed.
Discussing the problems of project localization, it is important to understand that we didn’t notice the habit to revote in Greenlight. You can correct you mistakes and attract other user to vote for your project. The users who speculate don’t vote for or against. They just do “Ask me later”. The number of such users is quite low. Even if you can talk them around, it doesn’t help you. Try to surprise the new public all the time. Those gamers who have already voted made a choice and forgot about you.
If you have some strategy for voting, you can only wait. In our case, we needed to gain 18 thousands votes to get the Greenlight. It can lead to accessing the Top 100. Top 100 is a life order which settles in each project selection. During several such selections, you can be in the Top 10 and get the Greenlight.
We did it!
After successfully getting the Greenlight, you get access to open beta testing. You need to prepare the integration of a payment service provider, authorization, a CDN for giving a game client, and develop a promo site, implement achievement system, and many other things which we are still working on. After getting on Steam, we will prepare the next installment in order to tell you about the technical and business aspects and what you should pay attention to. We hope that you have found something interesting in our information for your projects! Stay tuned for the next installment!
Located in Mazatlan and Cancun, Mexico, EnsenaSoft started in August 2009 with a desire to create educational and family-oriented video games. Their motto since the start has been “Learning. Fun.” With Where in the World is Monolisa, they believe they may have finally found a great balance. Samuel DenHartog, Founder & CCO, tells the story.
Beginning and Stopping Development
My team and I had come from a business app development and publicity design background, so we had a lot to learn about game creation and all of its many facets. Inspired by my childhood enjoyment of Where in the World Is Carmen Sandiego? from Broderbund, we had wanted to make a game that would make learning geography fun. We have emails going back to October 2009 related to this subject and our desire to make a tablet and touch-based game. I mention this so you understand how we got from our thoughts of the game then to how it is now.
Pamela Possum model
In 2009, we developed some preschool learning games and created the characters Pamela Possum and Sammy Squirrel. They were named after my two children, who were eight and four at that time. Living in Mexico, I wanted to create some games that would help them learn English letter pronunciation in a fun way. So we wanted to create a Trap A Thief Around the World with Pamela Possum and Trap A Thief In the USA with Sammy Squirrel. A raccoon would steal the acorns from the character, who then had to track them down. We were very much focused on creating 2D graphic backgrounds for each country, and a few characters who would offer clues as to where the thieving raccoon would travel next. We started development in 2010, but other projects kept taking priority. The background creation was slow, since we wanted to create three to four screens of background for each country. Ultimately, we stopped development.
In 2011, we had a big focus to bring our games to Mac and Android. At this time, we were using cocos2d for application development and would redevelop into Java for Android, and it was working well. In 2012, we brought our games to Windows 8 using HTML5. It was during this transition that we decided there had to be better way to support so many platforms. We were also getting interested in doing 3D vector-based game development.
Sammy Squirrel model
After looking around and talking to people at game conferences, we decided to move our development to using Unity3d. While initially a very scary step and a big investment both in money and time, it is by far the best decision we have ever made. Now, instead of developing a game once on iOS, and then having Mac, Android and Windows 8 teams spend 2-3 months redeveloping it on other platforms, we can develop it once and bring it to all of the platforms in a day or two! It also allows us to start doing things in game development that literally one year ago we would not have thought we would be able to do for many years. The downside is this created a huge imbalance as we needed more designers. We could create things quicker, and the designer’s job just got a lot more complicated. 3D games can require many more assets, and they needed to learn 3D model development at the same time.
Going in the Wrong Direction
We created new titles that probably would not have been wise in production, but seemed funny at the time.
We decided to restart the game with new titles last September in Unity3d. We initially thought of a very simple city with four 3D buildings, using some of our prior graphics to create the look of each country around the edges. The designers would still have to create four images per country, and each building would have a character you could talk to for a clue. So a couple of our designers started creating 3D characters of Pamela Possum for Find My Nuts Around the World and Sammy Squirrel for Find My Nuts in the USA, and other designers to work on background. We created new titles that probably would not have been wise in production, but seemed funny at the time.
However, there we started encountering a few problems that made us go back and completely rethink our approach.
First of all, using designers who are just learning 3D modeling development, even talented ones, is probably not a good idea. They had to throw out and restart models a few times, as we learned good approaches to designing low polygon models with bone structures created in a good way to achieve the animations we would want. After several iterations, it became clear that we were not quite ready as a team to develop our own characters.
After several iterations, it became clear that we were not quite ready as a team to develop our own characters.
Second, this left the others designers focused on pure 2D image development for at least the following year. When you think about four images per country with 30 countries in our Paid version of the Around the World game, and then four images per state with 50 states in our Paid version of the In the USA game, that meant a total of 320 images need to be created. All the while, the designers doing this work were not creating any 3D models and advancing their 3D modeling capabilities. It also left us with extremely redundant game play with just four buildings. We could create some different textures, but it got repetitive and boring.
We also felt our intro scene with the raccoon, which never even got started, would have been repetitive and decided a shorter scene with game starting in different countries would be better. We also wanted to create a bigger scene for each country and state, so the player would get to run around a bit more. Lastly, as we thought about it more, we thought of the possibility that the new titles would not be seen as appropriate in the marketplace, so we decide to make a big change.
The World of 3D Game Development
In Spanish, the word “mono” is the word for “monkey,” and it sort of fell into place with us creating the new titles..
As we came to accept that we would not be able to create characters, we looked around to see what we could purchase from the Unity Asset Store. We found some great animated cartoon characters with low polygon count to play our protagonist, created by Dexsoft Game in the Unity Asset Store. We found nine very cute characters created by PlayPlusPlusto give out clues. Lastly, and very important to our new title, we found a single character with ten different textures that we decided would be perfect for a gang of villains in the Monkey Girls characters by 3DRT. In Spanish, the word “mono” is the word for “monkey,” and it sort of fell into place with us creating the new titles: Where in the World is Monolisa? and Where in the USA is Monolisa?, where you attempt to track down one of the Monolisa Mafia Girls who have stolen important cultural or historical items.
Then we decided to make 3D models for all of the important buildings and monuments rather than 2D images at the sides of the city. Now that we had the characters done, the EnsenaSoft designers could focus on creating 2-3 models for each country and eventually each state. The character design time wasn’t a total waste; the two designers who had worked on character design turned out to be ready and really great at creating lightweight 3D models that did not need to move, perfect for our purposes. We were able to find a few models to purchase, but have made quite a few and will be making all of the rest ourselves.
On to the Game!
In the final version of the game, you see a city which may have monuments from very different parts of the country when you arrive in each country, and always the flag for that country waving on the left. You can run around and Pamela will tell you about the history of a particular building or monument if you get close to it. We felt this is a great way for people to really get to see them, and it adds additional information for the curious to learn more, although not integral to the game-play itself. We also play a short piece of that particular country’s hymn or popular music on arrival, so you feel like you are there.
You can run around and Pamela will tell you about the history of a particular building or monument if you get close to it.
That cartoon character pack we used for clue-giving characters only had an “idle” animation for each character, but this turned out to be just fine for our needs, as we have them at different corners. We only have four characters in any given country showing from nine random spots. Each destination has around 20 clues, so each time a particular country is the next destination, you may get very different clues, and each time you arrive in a country, it will have different characters.
We found that just running around in the now larger city was kind of tedious, so we added the extra task of collecting gems. The gems are randomly scattered all around the city, and you pick them up as you find characters. We originally had 50 scattered and made you find all 50 to pay for your next flight. This was too difficult and made the level “not fun”. We played around and reduced the required gems to 25, and it felt just right. The gem collection and finding the actual characters presents sort of a hidden object challenge to the game and is part of what we hope makes it fun.
Once you have tracked the criminal across enough countries, you arrive in the destination country with a message that the criminal is in the country. We did make it a lot tougher. The criminal is at 1 of 20 different locations that are not directly on the road, but are sometimes out of sight. Since there is only one thing to find, we felt making this one a little tougher was actually more fun.
Once you catch the criminal, it moves forward to the final taking to jail scene and unlocking a new detective badge.
3D model creation still takes time, and that is why the final Paid version of Where in the World is Monolisa? will not come out until first quarter and with Where in the USA is Monolisa? being released after that. The great thing is that by the time EnsenaSoft designers are done with all of this 3D model creation of buildings and monuments, my team will have a lot more experience, and I think we will be ready to tackle character creation for one of our games in 2014! The more they create and learn about 3D modeling, the faster they become with the tools.
We decided to release the game first on Windows 8, and then on the iPad, as we are seeing a lot of growth on the Windows 8 platform and wanted to see what would happen if we gave it a head start. We haven’t decided what platforms we will bring it to beyond that, as we are still learning how to optimize our 3D world and characters so they run well across the mobile devices. We could have easily made it Universal on iOS from a technical standpoint, but in the end, we felt that it really showed better on a tablet or PC device, and that is where people probably would have played it most anyways. We do hope to bring it to some consoles as well once we get the Paid versions completed.
We have really enjoyed creating this game and have a lot of work ahead of us in creating the Paid version and the In the USA version. We hope a new generation of young people can enjoy learning about the world around them in a fun 3D environment. In the end, we created something very different from our original design thoughts and very different from the games that inspired our original thoughts. I think the final result is better because of it all, and it shows that it is important to have the best tools for the job and also realize that sometimes you need to be flexible and just start over again (and again).
Keep up with what Ensenasoft is doing on Facebook!
Capital j Media is a game design and media production studio based out of Portland Oregon and headed by Polish-Canadian Jedrzej Jonasz. Starting out with the turn-based WW2 naval strategy game Battle Fleet, the studio now develops mid-core strategy, tactical and action games for clients and internal IPs such as Starbase Gunship.
For over 10 years, I had an idea for a top-down strategy game that started out as an ultra geeky pen/paper/protractor game in college. There was just one problem: I knew nothing about making games or programming. Along came Unity3D. After a lot of tutorials and long nights, I released my first game: Battle Fleet. It was an ambitious project for a first game, but thanks to the help of an artist who could handle the graphics, I was able to complete the game and release it on the App Store.
It was an ambitious project for a first game.
Battle Fleet wasn’t a smash hit by any means, but it did a lot better than I expected. It also taught me two things: making a game wasn’t some sort of black art that required a PhD in computer science, and, with a little help, it was something that could supplement, and maybe even completely replace, my income.
Prioritizing Strengths
For my next full project, I decided to create a smaller game, but one that would allow me to really fine-tune the gameplay instead of having to spend a lot of time adding more features and scripted content (like the campaign missions in Battle Fleet). I also wanted to bring in some of my film production experience with putting together and managing teams so that, like on a film set, I could concentrate more on my strengths and direct the creative side of the project.
I had to prioritize the list and be very careful with every expense.
I started out with a list of what I believed were my strengths at the time: story, creative design, project management, the Unity ecosystem, and enough programming to be dangerous. I didn’t have much skill or interest in creating the concept art, 3D modeling, UI design, AI programming, or math. This meant that I would have to find talented individuals to help fill those holes. Of course, this being an indie game, the budget was tiny. I had the money that I made from Battle Fleet, but not enough to hire anyone full-time, so I had to prioritize the above list and be very careful with every expense.
Be Specific
The first stage, as with most games, was to put together a prototype to see if the idea would work. Usually, I would just handle most of a prototype myself, but I didn’t really know where to start with the AI ship control and movement. The game takes place in a real-time 3D space environment, so my previous 2D turn-based AI experience wouldn’t help much. I turned to a programmer who had this type of experience and understood 3D math a lot better than I did. We worked out a reasonable hourly rate and guidelines for the scope of what he would create. Although I would have preferred to work with him in developing the entire prototype together, the budget simply didn’t allow for that. So I had to limit his time to specific elements that I could then expand on and integrate into the other game mechanics.
His responsibilities were to create an AI movement system that would:
- move a group of ships into orbit around the starbase
- allow them to have custom speeds and orbit distances
- avoid each other and any other AI controlled ships
- perform evasive maneuvers when fired upon
- ram the starbase after a set amount of time
I knew that I could only afford a certain amount of his time, so I was able to prioritize the things that would take the most time away from my strengths.
Being this specific with the tasks and knowing that I could integrate that into the other mechanics that I would create not only kept the budget down, but it also gave me guidelines on what features I would need to focus on. Whenever I reached some problem with the programming side that I wasn’t able to or didn’t have time to handle, I would send off a task to my programmer who would code it in when he could. I knew that I could only afford a certain amount of his time, so I was able to prioritize the things that would take the most time away from my strengths.
Design
Once I had a working prototype and could prove that destroying endless waves of mindless cybernetic drones was fun, I started with the next weakest link: the art assets. I had a modeller in mind that I had worked with on another project, but I wanted to give him something concrete to go by to limit the back and forth (and the cost). I didn’t know any concept artists, so I would have to find one by looking through forums, art websites and freelancer hiring sites like odesk.
Ultimately, I found a great artist in Poland whose style fit the look I was going for. I commissioned him to create the concept art for each of the ships, the starbase, and the emblems of the human and AI sides. As he was going to be working remotely and in a completely different time zone, it was critical to provide him with as much detail and background as possible. We didn’t have the luxury to sit down together and work through some sketches, so I put together a few Google Docs of style references for the ships, details about how these ships, and how the conflict in general came to be.
Here is an excerpt from the Docs:
The alien enemy in Starbase Gunship has its own design ethos, it is an extension of a mobile factory that excels in mass production to the point of it being more efficient to produce expendable ships and equipment rather than reuse and repair. Not too much unlike a dystopian extrapolation of our consumer culture. So just like in any mass production creating modular components and standardized building blocks directs their ship design.
With all of this reference material, it didn’t take us long to narrow down the designs and have something for the modeler to start working on.
Backups
Knowing that everyone had other projects, day jobs and responsibilities, I had to account for the fact that there was only so much each person could do per week. This meant that I needed a backup plan for each person’s work, in case they couldn’t keep up or they disappeared.
Finding backups or making backup plans early on helped to keep things sane when timing problems arose in later stages. If you rely on one person and they suddenly get a better contract or have other life events come up, you’ll just end up frustrated and angry. If you plan for that to happen (and it always will at least once on every project), you’ll actually be able to sleep at night when it does.
Working with a Studio
I wanted the interface and UI to be very simple, perhaps to compensate for the ridiculously un-intuitive UI in Battle Fleet, and to have a very hi-tech, sci-fi look.
The next big hurdle for me was the UI, an area I knew next to nothing about from either the design or art side. I wanted the interface and UI to be very simple, perhaps to compensate for the ridiculously un-intuitive UI in Battle Fleet, and to have a very hi-tech, sci-fi look. Again, after looking through forums and hiring sites, I came across a small design studio based out of Montreal that offered high-end work at indie prices. That, and the fact that their portfolio featured an a perfect example of the style I had in mind, made them an obvious choice. Even though I set out with the idea that I would find an individual freelancer to handle this, using a studio gave me a built-in backup, as they already had access to multiple artists and could compensate for any timing issues that came up.
Just like with the programming side, my budget couldn’t handle the entire UI design, asset creation, and implementation. So we worked out a deal where I would handle coding and integrating the UI elements, and all they had to provide me with was the design and assets.
Time to Publish
You never know where a new game might lead.
Bit by bit things started to come together. I finally had the freedom to spend more time tweaking gameplay, fine-tuning my vision for the game, and even have a few hours in the evening to spend with my wife.
The game launched on the App Store just before the Christmas holiday in 2012, which didn’t work out very well financially. It ended up being buried and received very little press coverage. At first, I was disappointed, but after a few weeks, the game led me down a new path of creating a mobile game for a PC game developer. That contract, which allowed me to expand my studio, make great connections, and continue doing this full-time, was a direct result of my client seeing and playing Starbase Gunship. So you never know where a new game might lead, if not fame and fortune, maybe a new job, new friends or the opportunity to bring your freelance team to bigger and better projects.
Located in Gothenburg, Swedens second largest city, Free Lunch Design employs a creative team that produces world class games for multiple platforms. The team has produced over 70 games for PC/Mac and iOS/Android so far; some of them have been downloaded millions of times. Free Lunch Design is looking to keep innovating and develop games that will knock your socks of, no matter what platform or genre. In this article we will focus on describing some major events in the development of Icy Tower 2.
One-man-army origins
A successful release of a Facebook version of Icy Tower in 2009 solidified the pursuit for B2C, and a name change to Free Lunch Design confirmed the decision.
Free Lunch Design was originally a one-man-army (consisting of Johan Peitz ) making retro-inspired PC games for free download. Out of the numerous games released, one of them stood head and shoulders above the rest: Icy Tower. Since its release in 2001, it became especially popular among young students around the world, in part due to the ease in which it could be installed on a school computer. The simple and fun game found a following and lived a life of its own for the remainder of the 00’s. Meanwhile, Johan Peitz joined forces with local game developers Muskedunder, to create advergames. Soon Muskedunder aimed to change focus from B2B to B2C, and to build on the previous success of Icy Tower became the obvious first step. A successful release of a Facebook version of Icy Tower in 2009 solidified the pursuit for B2C, and a name change to Free Lunch Design confirmed the decision.
Once mobile gaming became the next big thing, we knew the time for Icy Tower 2 had come. The game hit the app store in November of 2012, containing several exciting changes from the original to keep it fresh and suitable for handheld devices. The release was another success with 1 million downloads in 10 days, which led to the decision to bring the game to Android.
The Game Design Gauntlet
Game director Johan Peitz had the initial game design responsibility. This was during the early phase of the production, where the game had to have the “Icy Tower feeling”, something Johan has a unique sense for. Shortly after we completed a good version of the core game play, Johan had a son. This meant he was leaving us for more than a month in a critical stage of development: fine tuning the gameplay and evaluating new features. Luckily game designer Jimmy Öman jumped in to take over where Johan left off.
Johan’s short leave could have gone horribly wrong, but in the end just cost us a little bit of extra time. Actually, it led to a new way of working with game design proposals. Johan and Jimmy are game designers with different approaches and strengths. The key was not to let egos run the show, but to allow them to contribute mainly with their respective strengths. We went all in with this approach, involving the entire team in the game design. This made the differences between the designers play a proportionally small part and tapped into the full potential of each team member.
The way we involved the whole team was by letting all game design ideas run through a “gauntlet”. Every member of the team sat down in a “group design session” and it was the designer’s (or anyone else in the team with an idea) job to sell an idea for a problem solution, a feature or design change. It was everyone else’s job to try their hardest to shoot the idea down. If the designer could defend the idea in a convincing way, the idea passed the “gauntlet” and earned a slot in the next sprint. This went on for several weeks and really made a huge difference for the design quality, team morale and general fun factor of working on the project.
Be problem oriented and assign a moderator to pull the brake
Everyone was involved and felt they could bring up worries they had about the game in a constructive way. This was a new way to work with design for us, and even though it cost a lot of hours, we’ll be using “the gauntlet” again! One important thing to remember is to have some form of emergency brake, when the sheer joy of being creative is no longer relevant to solving your problems. Be problem oriented and assign a moderator to pull the brake.
Since its release on Android on December 18th, Icy Tower 2 has been downloaded over 500,000 times.
Good is not good enough
One lesson from our former B2B business model was that “good is good enough”. This had to be repeated as a mantra whenever our pride and ambition to deliver premium quality products was larger than what the budget allowed. At the end of the day we had to deliver what was paid for, not what we wanted to deliver in order to feel proud.
The game was good, but not quite good enough, when the budget was spent
Going from B2B to B2C, we had to re-program our minds in this area. Simply being “good enough” wouldn’t cut it, facing the cut-throat competition on the mobile platform. We had to raise the bar several times, which was an internal struggle. The uncomfortable truth was that the game was good, but not quite good enough, when the budget was spent. The budget for the project was set with the old “good is good enough” in mind, and we had to admit defeat when we realized the production would need to be extended several more weeks in order to get the game where it needed to be.
In retrospect this could be viewed as a failure to see the obvious, but the lesson is to understand that every start-up company has its growing pains. The discomfort it brings must not be seen as failure, but instead an opportunity to grow. We had in fact changed our business model completely and there are hard lessons every time you face a new area of expertise to master. This was one of them. Handling them successfully - albeit at a real cost - makes you grow. Growing is painful, so prepare to deal with it.
The complexities of being simple
You would think that having simple gameplay and having made several successful incarnations of that gameplay would make things easier. In some ways it is easier, since we have the experience and a proof of concept. In some ways it’s harder, since you work under the restrictions to not stray too far away from the original.
We knew there would be some fundamental changes to the game. The big one was controls. We wanted to design it for the handheld touch device and that meant getting rid of keyboard-like controls. This seemingly small change has effects that ripple throughout the product. It sets the bar for the speed of the game, the difficulty level of interactions, input frequency, etc. Getting it right took numerous iterations and only through hard work were we able to create controls that felt simple.
One other challenge was to add new and exciting features without changing the objective of the game. It has always been about getting as far up the tower as possible. Introducing mechanisms to acquire money - and things to spend the money on - diluted the simplicity of just beating your high score. We were obsessed with the thought of keeping the game objective true to the original. In the end we had to accept that the game could be played with different objectives for different players. Some want to complete stuns, others try to hoard money and yet other just want to have the highest score possible. You can’t tell someone how they should have fun, just let them play and figure it out themselves. We could do other things though: put in extra effort in the tutorial; adjust the timing in which we introduce new features and in overall presentation of the tower collapsing.
Personal growth
You don’t have to be a designer to propose an idea, just getting a design idea challenged from different points of views is healthy.
The biggest impact from a personal growth aspect was probably the way the game design gauntlet affected the team. Some team members stepped out of their ordinary role and got to shine elsewhere, either with an idea or throwing something wacky out there that triggered another person to formulate the “sane” version of the same idea. You don’t have to be a designer to propose an idea, just getting a design idea challenged from different points of views is healthy. It leads to constructive dialogues where people not only grow closer, but team members can have a lasting impression on your personal methodology in creative scenarios.
In retrospect
The development of Icy Tower 2 took longer than initially expected, but resulted in big value. It taught us how to act when losing key members, what it takes to raise the bar (quality-wise) and how to keep our heads in the game when assumed simplicity grew complex. Involving all team members in the design process gave us a fresh take on the creative process and we think that’s reflected in the game, which we feel successfully introduces new and fun ideas to a classic game.
Icy Tower 2 has recently been released on Google Play. Free Lunch Design will be sharing more in-depth insights on Icy Tower 2 during their indie-postmortem talk at the Casual Connect Europe conference in Hamburg, Germany.
Digital Dreams is a Dutch indie game developer that designs and develops playful experiences. It was founded by programmer Thijmen Bink, level designer Roy van de Mortel and game designer Geert Nellen. Currently, Digital Dreams is focussing on creating games for the downloadable console market, However, this post-mortem is about Cowbeam: their first, and probably last, iOS game.
Digital Dreams from left to right: Thijmen Bink, Roy van de Mortel, Geert Nellen
How everything got started
Let me start by saying that Cowbeam had virtually nothing to do with our former and current business strategy and portfolio. That is not meant as a disclaimer, but it is important to note because from the start this was an important factor in the decision-making processes during the production of Cowbeam. The idea came together due to very circumstantial and coincidental factors and it just seemed like a cool project to do at the time. In hindsight, this is not the way you want to make important decisions.
We naively started development of Project S because we basically thought everything was settled and done
We started out doing an assignment for another company somewhere early 2011. We were developing a hidden object game with a twist for them, of which the design document and assets had already been handed over to us. Let’s call it Project S. Without actually signing any contract yet, we naively started development of Project S because we basically thought everything was settled and done.
Our team was quite excited about Project S, because not only were we struggling to make money at that point, this was not some lame technical job. We were developing an actual game that we were enthusiastic about, although it was not something we would normally do. That’s why it seemed wise to let one of our team members start with Project S in advance. He created a technical backbone, so production could start off swiftly once we signed the contract.
Two weeks later we received a call from the other company. We were told they had to cancel Project S because of budget cuts. Now we were left with a half-finished game with which we obviously could not do anything due to copyright infringements. We were disappointed. Not only had we already invested time and resources in this project, we planned around the development of Project S. So basically we had nothing else planned in the upcoming period.
So with nothing on our hands, we thought about what code we could potentially reuse to make it not a complete waste of our time. One of the things we already developed for Project S was a simple but elegant system to show the player new objects he/she needed to find, and along with it, a way to arrange, dispose and organize these new objects in the HUD. New items would come into play sliding from the right until they bumped into a previous item that was already in place. Whenever an item was completed it would disappear and all remaining items would slide and arrange themselves into place. This system eventually led to a gameplay mechanic that resulted in the current hint system of Cowbeam, located at the top of the screen.
The arrange, dispose and organize-system that resulted from the left-over code of Project S
The new concept was called Cowbeam. A quirky little casual puzzle game, which puts the player in the shoes of Hank, a cow-hoarding alien. The player had to navigate a small galaxy and collect hints, which eventually showed on which planet a cow could be found. When the player finds the cow, the level is completed and the cow is shown. A big hook of the game were the cows, which resembled the planet they lived on. For instance: if the planet is red, the cow is red; if the planet is close to the sun, the cow would wear sunglasses or a sombrero, etc. We thought this was fun to see, and it was interesting for the casual audience on iOS as well.
Bringing Cowbeam to life
We had to start thinking more about our future and the monetization of our projects.
After the new concept was pitched internally, it took quite a few weeks for the idea to sink in and the team to pick it up and start prototyping the concept in Flash. The first few weeks of development went swiftly and the game came along quite nicely. We started building Cowbeam in Actionscript 3 with the idea to release it as a free browser game and get our money from advertisements. However, after 2 months of development we had to start thinking more about our future and the monetization of our projects. This meant for us we wanted to start using Unity3D. Another reason to switch to Unity3D was that the game felt not quite right on Flash. Mainly because you needed to swipe through galaxies which just feels weird with a mouse. We thought about releasing a Flash and iOS version simultaneously for a while but a Flash version just seemed redundant somehow.
Development of Cowbeam, after switching from Actionscript to Unity3D
We threw away everything we had so far in Flash and started the Cowbeam project all over again with a new engine to build with, a new language to write it in, a new platform to build for and even some new interns to work with. This was the first big change we made to the initial concept. Luckily Unity 3D is an easy engine to learn but this shift really put us behind schedule for quite some weeks, if not months. As an indie studio our deadlines were never really set into stone. However, we did know that by the time we started developing Cowbeam in Unity, we had planned on having the game completed in Flash.
Obviously, moving the game to the iOS platform pretty much meant a complete redesign of the concept as well. This forced us to rethink the game and strip it down to its bare essentials, which is using hints to narrow down your choices of picking the right planet. It cost us a lot of time to figure out what the most fun aspect of the core mechanic was for the player, which was a direct result of making something unique. We could have prevented this if we paper prototyped more, or incorporated playtests from earlier on.
It didn’t really feel like the game was complete and fun to play yet, so we had to make more design changes. A lot of features were cut at this point to make the game fun and suitable for the casual iOS market. These cut features include:
- Resources that could be gathered from planets;
- A currency system to buy hints;
- Time based gameplay and score system;
- Selecting and writing off planets.
Also using Unity3D, which as the name suggests is essentially a 3D engine, meant a complete redo of the graphics as well. Other than the menus and such, Cowbeam was now a 3D game instead of 2D.
On the left: The Flash version of Cowbeam; on the right: The iOS version of Cowbeam
This shift to 3D actually turned out great for the game itself because we were now able to rotate around the planets. We experimented with this rotation in combination with a number of features. We found the most interesting use of 3D was hiding certain characteristics from the planet out of plain sight. 3D also gave us more space and freedom to make the planets features more visually appealing and identifying.
Mistakes made, lessons learned
It was hard to think about killing our darling
The doubt we had with Cowbeam started to reflect on the team after a while in production: Is this game really going to be worth our time? Is it going to be fun enough? Is it even profitable in the end? Should we release this under our Digital Dreams brand when it’s this different from the stuff we want to make? Eventually it was a casual game, something completely different from the hardcore indie games we liked to make. The most important reasons to complete and release Cowbeam anyway were the amount of time we had already invested, everything we wanted to learn about Unity3D during the rest of development and wanting to have an actual finished game in the App Store. Especially the time we had already invested was a big factor in completing Cowbeam, it was hard to think about killing our darling.
Not playtesting enough fueled the doubt we had. Because we ran so far behind schedule, we somehow, without even really thinking about it, decided to scrap most of the playtesting and finish Cowbeam as soon as possible so we could start with our next project. In the end, we only playtested with visitors at our office and at the Festival of Games, a large Dutch event for people from the industry.
Our primary goal with Cowbeam was to master Unity3D and we succeeded at that
The doubt we had perhaps also lead to not properly marketing Cowbeam. All we really did was send out a pretty standard press release to our press network and hope they would pick it up. Of course we knew about the horror that is standing out and getting noticed on the App Store. But somehow we hoped it was going to be different for Cowbeam, because the concept was very unique and we believed it could stand out on itself. This wasn’t true. Sales were disappointing to say the least. On the other hand, it felt good to know we successfully published a game on the App Store ourselves and raised the bar for ourselves with the GUI and user-friendliness. Our primary goal with Cowbeam was to master Unity3D and we succeeded at that. Therefore we weren’t that disappointed about the sales in the end.
Just a few months ago we accidentally came across some little kids of around 12 years of age playing and really enjoying Cowbeam. This was actually the first time ever we saw anyone genuinely enjoying our game. Although it was a very cool moment it also brought us to the conclusion we should have seen this coming. We should have marketed and playtested for this target audience and maybe even design the game specifically for them.
Development tips
Our biggest pitfall was, as usual as with us indies, the lack of marketing knowledge and execution. Get someone to do this for you, find a good partner or really plan ahead and take your time to do this properly yourselves. We should have considered micro transactions, freemium or other means of monetization over a somewhat outdated simple pay once model which we ended up going with. The reason we went with this is mainly because of the extra programming and design effort it would take to implement micro transactions. We did try to weave it through the design when we were redesigning the game, but couldn’t really make it click when we did. Again, in hindsight, this time might have well been worth our effort.
We think the chances are very slim we’ll ever return and develop for the App Store. The market is too competitive for a small developer and the marketing power of big companies is killing for us. We believe the only way you can succeed on the App Store as a small developer is to have a really original and well-executed game and marketing plan. Even then, every investment is a very risky one.
Currently we shifted our focus to bigger projects for the downloadable console market, which was the goal of our company from the start. We worked on a prototype for a downloadable console game in the meantime and we are very happy we have an opportunity to work on that project now.
We hope you’ll pick up Cowbeam and let us know what you think!
Cowbeam is now available on Mac as well and has dropped in price in the App Store. Digital Dreams recently moved to a bigger office and is currently working on a new unannounced downloadable console project. They will also be sharing more in-depth insights on CowBeam during their indie-postmortem talk during the Casual Connect Europe conference in Hamburg, Germany.
Game director Johan Peitz had the initial game design responsibility. This was during the early phase of the production, where the game had to have the “Icy Tower feeling”, something Johan has a unique sense for. Shortly after we completed a good version of the core game play, Johan had a son. This meant he was leaving us for more than a month in a critical stage of development: fine tuning the gameplay and evaluating new features. Luckily game designer Jimmy Öman jumped in to take over where Johan left off.
