The year before last, Jeremiah Alexander had two new game ideas. The first was a card collecting game, conceived in response to an emerging trend – let’s call it Project A. The second was based on an impulse to make a minesweeper game – let’s call it Project B. “Project A was approached in classical fashion: production of an extensive and detailed game design document (40 pages to be precise), sent on to a potential publisher”, Jeremiah recalls. “Project B had no formal design, more of a hacked together prototype that then became a game”.
Project B is now called Grave Matters. It was selected for the Indie Prize showcase and publicly unveiled at Casual Connect USA in July 2014. Project A is still currently just an expensively bound design document, gathering dust in the corner of a publisher’s office on the other side of the world. Jeremiah shares the story about two different approaches to making a game.
A Minesweeper Game to Rest From Project A
This story begins in my office, an open plan space I share with two other games companies (Fluid Pixel and Whispering Gibbon). We have a very different attitude to most things, nevertheless, we try hard to help each other out. We have no formal partnership agreements to this end, but just share the belief that it’s better if we all succeed. Your lawyer and business consultant might tell you this is foolish, companies must operate in independence, with NDAs and policies to conserve secrecy and intellectual property integrity. Whilst I am occasionally forced to deal with these legal formalities, I do prefer handshakes and IOUs.
One (probably rainy) day, I walked into the office and said, ‘I want to make a minesweeper game’. This sort of random idea outburst is common and most often ignored, as it was in this case, too. However, I had a bit of hiatus in paid projects, and was bored of writing documentation for Project A. So, I cracked open Unity and just started making the game, designing it as I went along.
In a rather short time, I had a basic version of the game. It wasn’t a lot of fun, but a couple of rewrites later, it became much better! These rewrites included a complete grid structure change (from squares to hexagons), and some different ways of representing danger. Generally, the gameplay design was just a process of experimentation, this project wasn’t about doing things by the book, it was about just letting off some steam.
Not long afterwards, I stopped working on Project B and went back to working on the design document for Project A, the card-collecting game. I was convinced that if I picked an emerging market trend, designed an amazing game within it, and produced the most beautiful game design document ever to illustrate it, then we’d be onto a winner. We did this, then we sent it to the best suited games publisher and waited…
Digging Grave Matters Out of the Dropbox
… and waited. I soon returned to Project B, which was quite fun at this point but looked appalling! So, I borrowed some of Gareth‘s (Fluid Pixel’s art lead) time to help me out with the graphics. I had already enlisted his help on some steampunk designs for Project A, so it made sense to stick with the theme. At the time, I was also working on an educational project around 19th Century English history, which included some interesting research into grave diggers and resurrectionists such as Burke & Hare. This became the inspiration for the game and Project B became “Harey Burke”, later to be renamed Grave Matters.
So the Grave Matters game already had a name, some graphics, and was fun. But then the clients started calling again, bills needed to be paid, and the game was put on the shelf where it sat for a while. Not long after this, Project A was rejected both by the publisher we had sent it to and also by a small prototyping fund we had applied for. At this point, both projects seemed to have fallen into the abyss. Time passed. Client work was done. Bills were paid. Life went on.
Late in 2013, over coffee, Stuart, the CEO of Fluid Pixel asked me, “What ever happened to Grave Matters?” I responded: “It’s sitting in my Dropbox, along with the tea-making app and football game and other half-finished endeavors.” He suggested Gareth and Chai, who had some downtime, to pick that game up for a while. We were aiming on what could be called proper development, but our approach to this project lacked anything close to finesse.
Thanks to working on a lot of client projects, I’m well-versed with project management, source control, quality assurance, and so forth, yet Grave Matters employed none of this. New design ideas were often scribbled on the backs of envelopes containing letters from creditors (I will pay, I promise).
The complete source code was hurled back and forward across the room on memory sticks to whoever was working on it at the moment, and we generally made it up as we went along – it wasn’t lean or agile project management, it was blasé. Closer to the end of development, we started using a board on Trello, but for nothing more than a list to remember what still needed to be done when we’d not been working on the project for a while.
After about six months of development intervals interspersed between client work, we had Grave Matters, and now it was time to get it out there.
Here’s where I’d love to say: we self-published the game and it became a huge success, shooting to top of the App Store and making millions. In reality, as I’m writing this, we don’t yet know how this story ends.Grave Matters was released as a Halloween launch in October 2014. The game is still in it’s early days, and we’ll see how it goes in a few weeks.
Project A would probably have been a better game: it’s definitely better designed, more innovative, and has a better business model. Yet, we never had the resources or connections to get it off the ground. Grave Matters, on the other hand, has been released independently and, if early impressions are anything to go by, it could do really well (at least with fans of Minesweeper).
If Grave Matters is a success, it will challenge much of what I thought I knew about the right way of developing a game: comprehensive GDDs, robust planning, well-formulated business models, strict project management, etc. This might make me a little sad, but I’d have a successful game instead, so I’m sure I’d get over it 🙂
“What publishers really offer game developers today is, first of all, development tools that already have the know-how of how to make better games, how to make games more addictive, how to make them more successful,” Yaniv Nizan tells his audience during Casual Connect Asia 2014.
Yaniv Nizan, co-founder and CEO of SOOMLA, is a man who loves a challenge, especially the challenge of creating something new. He describes himself as an adrenaline junkie, saying, “New ventures mean you have to succeed where others failed, you have to compete against much bigger companies in markets that are undergoing tremendous changes.”
He believes the trick to winning against these large competitors is using their size to your advantage. The opportunities for new ventures usually come when the market is so dynamic that large companies have difficulty adapting.
He offers these suggestions to companies starting up. First, read Lean Startup. Second, read the SOOMLA blog for resources about starting a company and about game design.
Simplify The Complex
Nizan admits that leading a company requires many skills, but there is one that he uses constantly: the ability to take things that are complex and simplifying them so they can be understood by everyone and communicated in mass. This skill is necessary in many areas, including marketing, blogging, fundraising, investor relations, product, public speaking, and more. But he emphasizes, “In order to do that, you have to know the space you are in very well and understand how people think.”
Where It All Started
Nizan’s interest in games began with a 1983 game called Digger, which he played for hours. This game taught him a great deal about how computers work, since, at that time, it wasn’t simple to download an app; you had to do a lot of hacking to even be playing the game. He claims these games were the impetus for his career in the computer industry.
These days, he is a much more mobile gamer. Currently, he is hooked on a game called Box It, which involves blocking areas of the screen by moving a ball and trapping other balls. He has been playing this puzzle game exclusively for the past two months.
The creativity of the games industry, combining visual art, audio, interaction and programming at the highest level, is something he especially values. He also enjoys the extremely competitive nature of the industry that requires fast thinking at all times. And, he says, “Nothing beats playing games at work!”
Casual Connect’s Indie Prize is a demo of creativity and a great way to get exposure, although the ultimate way to get exposure is to license existing IP. “The best thing is to license existing IP from a book, a film, or a retry game. This has to be done on a revenue-sharing basis, as you don’t want to be paying out of pocket.” He also suggests applying for the Indie Prize or submitting the game to be featured on the SOOMLA blog.
A History of Platforms
As Nizan considers the history of the games industry, he notes that it has always been driven by platforms. These have included PCs, consoles, handhelds, then PCs again, followed by online games, Facebook games, and now mobile games. He insists, “In every shift, huge companies collapsed and new giants came to replace them. So the main question we should be asking is: what is the next platform?”
“So the main question we should be asking is: what is the next platform?”
The most interesting trend Nizan sees coming in the industry is shared economy. It is already a part of other industries and is just beginning to be seen in the games industry. There are now ways self-published game developers can pull together resources, something that will happen more frequently in the future. He expects to see more open source and more shared resources for developers and by developers, especially in areas that were traditionally the domain of publishers.
Nizan hopes that more game developers will mature in their understanding of the business aspects of getting users, engaging them and retaining them. He believes this is about building two basic things into a game: a sense of progress in the form of achievements or levels, and wealth accumulation in a virtual economy. He says, “When these are balanced, they make users come back to the game naturally. They are not that hard to build, but most developers build them as an afterthought.”
Keitai is a five-people indie team from Taiwan, founded in 2005. They started with designing Java games for feature phones and have made various types of those and other apps. Keitai includes three main team members: Claire, the founder, Neil, the game producer, and Code Anonymous, lead programmer. In 2013, two new members joined the team: Ivan the programmer and Dani the business development professional. Claire talks about the development of their latest project, Rocket Cube.
At Keitai, we all have a great passion for games; not just playing them, but also making games that can entertain other people. We believe that as long as we keep ourselves devoted to making games, they will somehow come alive and enrich the world with lots of fun. In 2013, we continued our psycho process of game development while participated in several showcases. And we’ve learned a lesson from our game, which is “A game speaks for itself.”
A Game of Flashes and Strange Sounds for Developers’ Entertainment
There was actually another project we were working on, and most of our attention was paid to it. Rocket Cube was nothing more than a recreational project. In other words, we created Rocket Cube just for our own fun. What we wanted to make was a simple game that would bring us pure excitement.
The original design concept for Rocket Cube was to add more excitement to regular puzzle games. We decided to have cubes dropping constantly and stacking up, while gradually increasing the dropping speed. When the stacks build up to a certain height, strong warning sounds appear, making the player’s experience even more tense. Removing stacks of cubes in the same color by launching them, players get the exhilaration of destroying and surviving, which goes higher and higher.
At first, we developed the “1-minute” mode, where the player needed to complete an exciting and thrilling round of the game in one minute. We also added the speed-up button to increase the player’s experience of exhilaration.
It’s easy for all types of players to master the game because we’ve built Rocket Cube around the main mechanism of “touch to launch”. As players are getting accustomed to the increasing pace, the excitement grows, and tapping the “restart” button becomes irresistible.
Opportunity at Casual Connect USA: Rocket Cube’s Chance Showcase
The prototype of Rocket Cube was launched only a week before we set off to Casual Connect USA in July 2013, where we later encountered lots of trouble.
Of course, we thought it would be better not to showcase a game that didn’t even have a proper UI.
Of course, we thought it would be better not to showcase a game that didn’t even have a proper UI. We hoped to have our main project accomplished in time and showcased, but stumbled upon some technical issues. While Rocket Cube was still nothing more than a game just for our own fun, we asked some of our newly-met friends to play the prototype and give us feedback. We were so surprised that they liked it!
But our bad luck continued: I was robbed and the mobile device with the demo build of our main project was gone! You might think our journey to Casual Connect USA was doomed, but giving up is never an option for Keitai. We just didn’t want to think we had come all the way for nothing! At the very least, we could have fun. Besides, there’s always an alternative and anything can be possible. For us, Rocket Cube turned out to be that alternative, even though we still didn’t think it was ready, despite a recent upgrade.
“Since we had lost our primary weapon, a sidearm would do,” we thought. And the effect was fascinating! Some kept playing Rocket Cube for more than an hour, until the device died and needed recharging. Some invited us for a lunch because they loved the game so much. The just-for-fun game sent us a clear message through these new friends: “I would like to be seen by more people and be fully developed.” But we were still obsessed with “The Project”.
The Game that Makes People Want to Touch It
Now, after many versions, Rocket Cube has evolved a lot. I still remember the day we were testing a new version until 3:00 AM; all of us just couldn’t leave our devices alone! Even our business development guy Dani said, “I have never thought it could be this fun.” Dani didn’t like Rocket Cube when he first tested the prototype, but changed his mind after playing the updated build. He is now totally excited about the game and hasn’t put his phone down since he installed the app.
We dared to bring our creation to Tokyo Game Show (TGS). The Asian gamer’s dream is to be a part of TGS, and so was ours. But you know what? We were still thinking of “The Project”! At the same time, we had noticed the potential of Rocket Cube and decided to give it a shot at TGS. And it worked! People kept telling us Rocket Cube deserves the opportunity. They launched rockets over and over and over. Rocket Cube makes people want to touch it, especially the “Restart” spot on its UI. At last, it is not just a simple cube, but a cube that turns into a beautiful one with heat and energy.
The Best Reward Comes From Something You Don’t Mind
Rocket Cube taught us some lessons. First of all, don’t be too focused on just one aspect. If you are sticking to it too much, it might not help you at all. Due to the accident and unexpected network issues, we were not able to showcase our first mobile game on smart phones as planned at Casual Connect USA 2013. Rocket Cube, which was a test project at the time, stepped in and became the star. During the three-day event, we kept receiving positive reviews and feedback, which made us even more confident on speeding up the development plan. This is how something that you didn’t really pay attention to could happen to give you the biggest reward.
Secondly, make games that you really like and always keep that in mind. We made Rocket Cube because we simply wanted a game that would let us have fun. The origin of Rocket Cube is just a simple concept. However, it brings pleasure. We think this is also a development challenge: to keep the concept simple from the beginning to the release, without too much decoration or exaggeration.
Last but not least, let your game meet people, so that you could receive feedback. Give it a shot and find out how functional your creation is, and let people know what you have.
Rocket Cube is available for free download from the AppStore and Google Play. It’s a full version that includes three gaming modules: (1) Infinity, (2) 1-minute and (3) Cube War, where scores of players with the same nationality are added together to compete with scores of players of other nationalities. In the next version of Rocket Cube, we’re going to add new modes with the element of “stillness”.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
Megafuzz is a Danish indie game studio founded in 2013 by Jeff Jensen. With their flagship game Spoiler Alert conceived at a game jam, they are all about passion, creativity, and fun. A genuine love for the game is their strongest foundation. Jeff discusses the ups and downs of creating Spoiler Alert.
When Everyone Goes Right, Go Left. Literally.
In true indie spirit, Spoiler Alert was born at a small Danish game jam in Viborg in 2012. I remember the jam’s theme had just been announced: “resistance”. As many jammers in the corners were discussing various rebel games, friction-based games etc., I had a slightly different train of thought. I was thinking of “resistance to mainstream”. And what was the most mainstream thing I could think of in a videogame? That you had to complete it! Why not uncomplete it instead?
The jamming was about to begin, and I still hadn’t found anyone with whom I really got along. I was about to go solo when a tall, calm guy approached me, introducing himself as Martin Pedersen, a graphics artist. I explained to him my idea for the game (a reversed Super Mario), and we made an official team. Discussing ideas of how to proceed with our game, we immediately hit it off, and there was chemistry unlike anything I’ve ever felt before with a game jam partner.
Internet and Phone – Connecting Developers
The game jam was a success to us; Spoiler Alert won first prize for best game, best pitch, and also received a Judge’s Favorite, as well as Audience’s Favorite award. A couple of weeks later, it also got mentioned favorably in the Danish newspaper, Politiken.
Martin and I felt that we had a fun game idea, and, with the response we’d gotten based on our little 48-hour prototype, we wanted to turn it into a full game. We still believed there was a lot of untapped potential in the gameplay. Armed with nothing more than the idea and intense passion to carry it out much further, we launched a full assault on taking Spoiler Alert from a game jam prototype to a full game. We live in different cities with a significant distance between us, so we have to rely almost exclusively on the internet and phone for communication. Facebook and Google Docs are among our favorite go-to tools.
Making a “Reversed” Game
Even though I’ve worked on numerous small games before, this was my first serious project, as well as my first time working with a partner. As for Martin, it was his first time making a game. Period. So, neither of us was that experienced. On top of that, we were doing a rather unique game, with a lot of uncommon design-related challenges. Just wrapping my own mind properly around everything going backwards was difficult enough at times.
I remember making an entire boss fight, being satisfied with it, showing it to Martin who was also satisfied, and then we realized I did it going forward (like a “normal” game). We both looked at it without realizing that. Instead of swallowing his own fireballs, the boss was shooting them – just to name an example. This sounds simple and stupid, but it caught us both a few times before we really got used to designing everything in reverse-logic.
About midway through the project, we saw a handful of issues. First off, the game wasn’t suited all that well for handheld devices (which was a strong focus), because we made the levels fairly long (2-5 minutes). So we cut them up into smaller pieces, and added a lot more new levels. We went from having 30 long levels to 100 shorter levels.
Also, there were virtual buttons; one for jumping and one for using your powerup. The problem was, that as you didn’t always have a powerup, 50 percent of the GUI was redundant and confusing. We discussed having the powerup button only appear when you had a powerup, but then became afraid people wouldn’t notice it. Also, we thought it would be inconsistent. We ended up removing virtual buttons altogether. Instead, tapping anywhere on the screen would make you jump, unless there was a fireball to catch, in which case you would swallow it. In other words, we made it context-based. This worked much better and was way more streamlined.
We’re Done! Oh Wait…
About eight months of development later, and we were done! Or so we thought. We were about to release the game, but were forced to wait a few weeks as I was in limbo with paperwork (I was registering Megafuzz as a company, getting it approved as a business at Apple, doing bank stuff, and many other grown-up things). These weeks let us take a step back and look more critically and objectively at our own game. We realized that, in the end, we just weren’t satisfied. We could do so much better!
We chose to postpone release, and took Spoiler Alert back into full re-development. This was a long process, which extended into another 6-8 months. Things became much better; the graphics got a huge overhaul, many old levels were improved and new ones added, UI was animated, and, thanks to extensive testing, we found out that the game was way too hard and unfair. We spent a lot of time making Spoiler Alert more intuitive, and re-balancing its difficulty. I’d estimate that we’ve reduced the difficulty level about 10x since the first version. At least.
The Encouraging Impatience of YoYo Games
We were knee-deep in development, moods were high, but exhaustion was also there. Spoiler Alert was developed using GameMaker: Studio, and I would often use the game as a basis for bug reports to YoYo Games. I guess this is how they noticed the game, because we didn’t really advertise it, but, all of a sudden, I got an email from their PR manager. She said that she and some of her colleagues had been playing around with the game, and would like to include it in their (at that point, non-existing) official games showcase. This definitely gave Martin and me some extra fuel, and we were promised to be included in their showcase as soon as it went live a few months later.
Eventually it was there, and I was supposed to email YoYo Games some materials for Spoiler Alert so they could put it up. Even though I really wanted us to get in the showcase, I deliberately waited until the game was in a state I would be more comfortable showing off. I actually held off for several months after the showcase went live.
I guess they got tired of waiting because one day in November 2013, I saw a mention on Twitter that Spoiler Alert was now in the showcase. As we hadn’t given them any proper materials, it didn’t look its best, and we had not submitted proper info either, so the showcase stated that the game was out, and provided a dead link. Being honored and excited, we understood we had to hurry and send in some proper materials and correct information. Even though we were fast, in less than an hour after the game info went live, I received the first email from a user who asked why he couldn’t download Spoiler Alert, and said it looked awesome. It was a mess, but a fun kind of mess!
A Team of Three, Yet Two Have Never Met the Third
I mentioned this was our first real game, and we’ve learned a lot from it. Martin has obviously improved very much as a graphic artist, and we’ve both gotten a completely new understanding of what it means to make a game. It’s a fun, but long and tough process, and often it pays to over-estimate schedules and times.
One of the areas in which I’ve personally grown the most is my own “quality bar” – it’s been set much higher. I’ve spent more time than ever on small but important polishing-related things, and have learned much about trying to make the interactive experience as intuitive and foolproof as possible. I’ve also gotten significantly more experienced in level design.
I’ve learned a lot about working with a team – Martin, and our musician and sound technician Roland La Goy, who’s based in the USA. It’s been interesting to make a game with a team where most communication is virtual, and two of three people have never met the third person. I’m still amazed that this worked out well, but I’m just blessed with having such awesome people in the team.
Spoiler Alert will be available for download in February 2014, on iOS, Android, Windows, Mac OS X, Windows 8, Windows Phone 8, OUYA, Ubuntu, BlackBerry and Tizen. It also won the Most Promising Game in Development award at Casual Connect Europe‘s Indie Prize Showcase.
Myers comes to Reactive Studios with a background in entertainment industries. He was originally a creative writer and playwright, earning a student Academy Award nomination for a short film he co-wrote. One of his early experiences in the games industry was writing for Dejobann Games, a Boston indie company, working on the Valve Potato Sack ARG, which led to the release of Portal 2. He then began adapting story IP to Facebook for various companies. He worked as game writer for Zynga Boston on Indiana Jones Adventure World, which was named a top 5 social game of 2011 by Gamesutra. From there, he went to a narrative designer position with Disruptor Beam, planning the story and leading the writing team on Game of Thrones Ascent. He got into mobile through designing narrative and writing for Jack Lumber by Owlchemy Labs, and his focus remains on mobile today.
Myers particularly appreciates the camaraderie of indie developers and the community of support among writers around the world. Boston holds several monthly meetups where they come together to share knowledge, discuss problems and demonstrate games. He enjoys the same community cooperation at trade meetings such as GDC and Casual Connect.
The games industry entices him with the challenges of creative problem solving both as a writer and a designer. Delivering an entertainment product satisfies his desire to reach others with his creative work. And because it is a booming commercial industry, he can take practical steps to grow both his career and his business.
Innovation and Interaction
Innovation is especially important to Myers. He reached a turning point in his career with the opportunity to explain the innovations in the narrative of Indiana Jones Adventure World when he spoke at the Games Narrative Summit in Austin, TX in 2012. He tells us, “We had worked very hard to do something very different with story for a Facebook game.” With this game, he says, “I felt like a pioneer staking out new territory.” And now, the use of narrative elements has become much more prevalent in the mobile/social space. He insists, “I try to walk that path of innovation in all my projects.”
He tells us interactive entertainment is a category he expects will continue to boom in parallel with more accessible development tools that allow content authors to have creative control. As well, advances in mobile hardware and peripherals will allow for more innovations in audio. The limitations in these areas have been holding mobile games back until recently.
Reactive Studios are working to reach the largest possible audience for interactive stories, using a focus on acoustic storytelling. They are targeting an overlapping audience of audiobook listeners and casual gamers, with game content driven by audience demand. For 2014, they plan to focus on partnerships for new titles, allowing for rapid growth of the company.
Nadav Bar Kama, founder and Project Manager at NAFNA Games, is a self-described optimist whose exuberance for games comes through clearly as he describes the games he is currently playing. He says, “I try to play as much as I can. I play for both professional reasons and for joy, although sometimes I find it hard to distinguish between the two.”
He plays iPad and Browser Flash games. These days, his favorites are “BADLAND, an outstanding game; Zombie Tsunami, a technically brilliant game with a lovely sense of humor; Toss the Turtle, a great mix of gore and humor; Zombotron 1 and 2, both easy ambient adventure shooters, and the very intense Spell Sword, and Super Crate Box.” He also mentions Little Inferno because he just “loves burning stuff.” He prefers iOS for personal use, although for games development, his goal is to have their games on as many platforms as possible.
Love at First Ninjump
Nadav became a convert to the games industry when a friend let him play Ninjump from Blackflip Studios, on his device. It was, he says, “instant love. The mix of art and technology that form instant moments of joy just captivated me.” His first step was to start playing games, a lot of games! The next step was forming a team to begin developing games. Collectively, they have a lot of experience in programming, animation and design, so they simply needed to adapt their skills to the specifics of game development. The first step in this process was skinning a casual game, resulting in Footy Tap. The second step, now in process, they consider more innovative: the development of their new title, Asslay Gore, featured in the Indie Prize Showcase at Casual Connect Europe.
Although he is just getting started, Nadav feels the best thing about the industry is the people, saying, “There are so many great and talented people in the games industry; it is an honor mixing with them.”
Focus and Philosophy
The essence of Nadav’s work lies in keeping the team focused on their plan. Their short term objectives change, they have developed new knowledge and abilities, and new standards and tools become available almost daily, so constant adaptation is essential. But their long-term objectives and project philosophy remain. Nadav analyzes games to understand all the game elements, including game art, game play, user interface, menus, features, and sound tracks, among others. Then he tries to blend these insights into their philosophy of game development.
Trends Come and Go, Gaming Remains
As Nadav considers what the future trends in the game industry may be, he maintains that they must create an abstract game development philosophy that is beyond, and can contain, any trend or new technology. When there is a promising new trend, they will study it and see if it can blend into their project. But he insists, “Trends will come and go, but it is the basic human need for fun, competition, entertainment, distraction, and social connections that are the core of game and play. We hope they shall always be present in our creations.”
Keybol is a one-man indie game developer company from the Philippines. Bari Silvestre has made a bunch of popular flash games, some of which were showcased at game conferences around the world. Bari is now venturing into mobile, and his first big release happened to be a hit in the form of Pretentious Game.
Contest Entry Becomes Viral
Pretentious Game started out as a small flash game created for Ludum Dare 23 accelerated game development contest. The setting is about a blue block who is in love with the pink block at the other end of the screen. He must reach her in any possible way, even if this means breaking the rules set for the game, or even introducing a new mechanic. The ending is also a bomb waiting for every unwitting player.
The game turned out to be a hit! It went viral and topped the Reddit gaming subtopic. I understood Pretentious Game was a hit not only among gamers, but also within the indie games industry, when it got showcased twice at Casual Connect and was featured at Rock, Paper, Shotgun, and IndieGames. When the game was presented at the Indie Prize Showcase at Casual Connect San Francisco, it won the Director’s Choice award and was nominated for Best in Storytelling. Pretentious Game was also on the front page of big flash game sites such as Kongregate, ArmorGames, and Newgrounds.
The following chapters, Pretentious Game 2 and 3, were received positively as well, since the second one has a surprising ending, along with improved gameplay. The third part is interconnected and awes many players with how witty the whole story is.
I think the game gained popularity thanks to its story, but the gameplay wasn’t lagging behind too. Players liked the fun of solving new puzzles while discovering the whole story. They also found the title amusing, and some thought it was a sort of parody.
When Publishers Harbor at Forums
Since the reception for the franchise was overwhelming, I decided to port Pretentious Game to reach a wider audience. To promote the game, I needed a trailer to later post it to the TouchArcade forum. I found a very catchy tune at AudioJungle, and imagined a good trailer script with the positive reviews from Rock, Paper, Shotgun, JayIsGames, IndieGames and Mike Bithell himself – the creator of Thomas Was Alone. Rishikanth Somayaji, a developer I met at Casual Connect Asia, volunteered to make the trailer, and he did an awesome video with his own vision.
The trailer caused a brief discussion, and then Bulkypix, a French publisher, contacted me with an offer on that forum. They reminded me that mobile games need visibility to take off, and promised to help with that. Bulkypix was really giving me benefits, and I couldn’t reject their offer anymore. The most memorable thing in our discussion was when they told me what their Lead Programmer told them: “If we don’t take this one, we won’t take any game!”
After additional quality testing and 10 more languages later, the game was published on December 5, 2013.
The Friday When Bari Woke Up Successful
It was another Friday morning here in the Philippines, when I woke up and decided to check the Best New Games. Pretentious Game was one of them! I thought I was dreaming, I almost immediately thought of hitting the jackpot.
As for the reviews, they were great. I was overwhelmed to see my game in such prestigious sites as Touch Arcade, App Advice and Pocket Gamer. In a week, even more reviews followed. The players liked the game too: more than 1900 reviews averaging 4.6 on Google Play and mostly 4 and 5 stars in App Store.
Here are some reviews:
“I really like this game.” 4/5 stars — Touch Arcade
“I instantly fell in love with its challenging charm.”- App Advice
“Concealing a deeper meaning, Pretentious Game is an enjoyable platformer with a touching message.” – 148Apps
“I can say that it’s refreshing to see something like this come along.” – Arcade Sushi
“ Pretentious Game is one of those rare games on the App Store or Google Play Store full of originality.” – Pocket Gamer
I thought App Store’s feature rotation after a week of success would bring the number of downloads down, but instead we had entered the US App Store top charts!
I believe it’s because of the review from Touch Arcade and a video of 10 Fun Mobile Games by VSauce. It’s amazing how much this contributed to the number of downloads and sales. I can say I’m now more eager to move further through the US market. In fact, we reached 110,000 downloads in 10 days.
Promotion: Festivals, Contests, Press and Direct Suggestions
I’m now pursuing the game even more, since I’ve heard from other successful mobile developers that the first two months are the most critical, because what is being done now determines how long the tail of downloads to come will be.
I’ve met with directors from IGN Asia to tell them about the game, and reached out to local media to promote a Filipino-made game in my own country. Pretentious Game has also been suggested for a possible feature in Google Play, and is in process of being included in a mobile Humble Bundle – Bulkypix met with Google as part of their weekly roadmap, possibly pitching the games eligible for feature promotion.
I had also submitted the game to IGF 2014 before it was released, and hope they’ll choose it as one of the finalists.
Kickstarter-Style Monetization: Useful, but Unclear
We’ve tried a different approach to monetizing the game: a “Kickstarter-style” of purchasing the full game for a bigger price in exchange for more rewards like wallpapers and soundtrack. It was also meant for players to support the developer if they wanted to.
It worked, bringing some extra 30 percent to the earnings. But at one point after reading a comment from a player, I understood that it confuses other players. She said she can’t pay $4.99 to unlock the game, since she thinks it’s too much for a mobile game. I had to remind her that it will only cost her $0.99 to unlock the full game. The $4.99 is an option to support the developer and get an additional wallpaper and soundtrack. In the end, because we don’t have real stats to compare with (since, as far as I know, no other game has used this approach), we decided to leave it as is and focus on content instead.
Mistake in a Twitter URL May Have Cost Downloads
It’s a good thing that I manage the Facebook fan page of Pretentious Game, and can connect with the players to advise them what to do. Once there was a slight mistake in the URL of the link shared on Twitter, but that was easily fixed by the next week’s update. I am still wondering if it should have brought in extra downloads. I also noticed the Facebook sharing feature I put in the game did nothing! At least, that was the case when I checked for #pretentiousgame and saw a total of zero users having shared the message on Facebook.
Bari is now working on Circles with multiple personalities! He is planning to start a studio and gather a bunch of local talents in his provenance. If you want to check out more of his games, visit his Facebook Page.
Ukraine-based Room 8 Studio‘s mission is to break ground in the mobile games space. With the big sense of purpose and effort, they created their first game, Cyto’s Puzzle Adventure. The Room 8 team tells the story.
For about a year, the Room 8 team has been working on Cyto’s Puzzle Adventure, but the development process turned out to be longer and harder than we expected. Still, our whole team looks back on that time in a positive light, and we received invaluable experience.
A Sticky Start
The story of our game begins in late 2011. None of our team had experience in developing for iOS, or game development, for that matter. What we did have was a great desire to make a really high-quality product that we could be proud of. We came up with a great idea about a cute little creature with tentacles that could cling to different objects. Without thinking twice, we started to develop this game we called Sticky. The plan was to make it in a couple of months to be just in time for the Christmas sales, but in the end, the process was somewhat delayed.
By creating the first working demo, we immediately sent it to Chillingo, our prospective publisher. There were no levels or design, just the bare prototype with a brief description and some concept art. This is a very useful practice. The mistake of many developers is that they give publishers an almost complete, or even completely finished game, when publishers can also be beneficial to noticing a promising project at an early stage. The sooner they join in on the development process, even if it is at the level of general council as to which direction to go, the better it is for everyone.
However, we were disappointed. After looking at the concept, Chillingo said that the mechanics of the game was not new or original, and forwarded us several variants of such games. Although these examples had little resemblance to our concept, we started to think about alternatives. Looking back now, we realize that the publishers helped us a lot. If development of Sticky was not delayed, it’d be lost among the other similar games, many of which have become quite successful.
Just a couple of months after freezingthe project Sticky, Chillingo released the game Munch Time, and in October 2012, Microsoft introduced Tentacles: Enter the Dolphin. The appearance of these two games blew away the novelty effect we would have liked to achieve with Sticky. Then a new game Tupsu was released, which included some features we had planned to implement, not to mention the gameplay itself.
This happens all the time in the App Store: as long as you think through and develop some “brilliant” idea, someone has already started to implement it. Or, even worse, you can see a clone of your game in the Store just when you have done about 80 percent. You have to be ready for this and not delay the development of applications for iOS.
Changes in the Concept of the Game
At the close of the Sticky project, we had approved the concept art and character, and had finished the physical model. We didn’t want to start from scratch, so as a basis, it was decided to take the ready developments and modify them qualitatively. On one hand, this limited us in making some decisions, but on the other, it saved time and, although in a different form, helped us realize what we originally intended. After several days of stubborn brainstorms, we prepared a new concept. Among the sketches of the Sticky character, we liked this one the most:
The idea is that the character itself is inside the gelatinous envelope. We can see an expressive little face with different emotions, surrounded by a deformed envelope from which the tentacles can be drawn out. Such a character perfectly suited our new concept: we don`t pull the tentacles from the outside, but rather, the character itself deforms the envelope in which he lives.
At first, it was assumed that the character would stick its shell to multiple objects and move around in this way. But after some thought, we abandoned this option because there were no interesting mechanics with it. After observing the behavior of the different elastic objects (don`t get it wrong, haha), we came to the conclusion that the best thing would be to make the skin more elastic, like a rubber band, so the character could run itself like a slingshot. Such game mechanics have already become clear and familiar to many people, but with our approach to the game, it does not look like a clone of Angry Birds. With this in mind, and with enthusiasm, we started to develop.
As for the setting of the game, it was decided to put the character into the microscopic world. Its shell could stick to organic objects (cells), and float around different crystals, viruses, and other poultry. Of course, we had to abandon the backgrounds that were drawn for Sticky.
In some sense, the nature of the game world dictated the design requirements. It was supposed to be rich, “juicy”, and minimalist at the same time. So we thought to make the whole design monotonous, almost monochrome, and play with only a few shades of the base color. Also, it was planned to present levels in the form of macro photography with a deep background and a set of realistic small details. However, these locations poorly suited the cartoon character, and so it was decided to simplify them, too.
Naming the Game
When we came up with the name of the game, we wanted to convey the microscopic nature of the game world, make it unique, like a biological term, but short and well-remembered. A perfect example is the term Osmos: it has all of the above, plus, in some way, a description of gameplay. There were not so many options, but among them was Cyto. This is not an independent word; it is a prefix meaning cell and is used in compound terms, such as cytoplasm.
It was a good idea for the working title of the project, so we went with it. More than once, we tried to come up with a new title, but in the process of development we got so used to Cyto that we could not imagine it being called something else. We even decided to name the main character Cyto, even though we had assumed that it would have its own name.
Revealing Cyto’s Puzzle Adventure
In the end, after many revisions and improvements, Cyto Puzzle Adventure finally came into existence. In this regard, we would like to advise novice developers to assess their strength and timing realistically. We planned to make the game in a couple of months, but spent much more time on it. We were lucky, and were able to complete the project. For most startups, unfortunately, the overestimation of the forces is equivalent to failure.
Optional, but very desirable, attributes of high-quality games are the little details, like sailing bubbles and particles on the background, beautifully appearing buttons, and all sorts of invisible (at first glance) animations and effects. For example, has anyone tried “to tap” on Cyto’s face? 🙂 Start your fabulous journey in microcosm now by downloading the puzzle!
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.
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.
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.
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.
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.
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.
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.
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.