Own Kingdom: A Game Remake that Built the Team

main

Contributions Development Game Development Indie Online Postmortem

Own Kingdom: A Game Remake that Built the Team

September 22, 2014 — by Mariia Lototska

In July 2011, Eldwin Viriya took a leave of his job as a lecturer of basic algorithm and data structure for a semester to take a GRE test for the master’s degree. Having passed it successfully, Eldwin discovered he had a lot of free time. He decided to use this time for self-development and made DragManArds in 1.5 months. This Flash game really sparks the light of game development spirit in its author. Later, his company, Own Games, created DragManArds’ remake Own Kingdom, a fantasy medieval strategy game where you need to protect the kingdom from waves of monsters. He describes it as an experience of tower defense games with a taste of war games.

Get the Taste of Making Games

When I first created DragManArds, I used MochiAds for monetization, since that was the only monetization option that I knew at that time. I didn’t even know about Flash sponsorship back then! The result turned out interesting: I got a lot of feedback from real players in Kongregate, some fan messages and suggestions, and also managed to earn more than 200 USD in the first month (which was cut down to only a quarter in the following month, and to almost nothing for the rest of the month).

It felt amazing to actually experience the thrill of launching a game, but the best part was when DragManArds dragged me into the gaming ecosystem of Indonesia. Groups such as Gamedevid allowed me to get to know game developers of the country, as well as big companies like Blackberry and Nokia.

Own Games Team - left to right - Raynaldo - Jefvin - Eldwin - Okky - Agustian — The current Own Games team: Raynaldo, Jefvin, Eldwin, Okky and Agustian

Remake DragManArds: More Features, Better Graphics

In late 2011, Nokia held a game developer competition for their feature phone platform. I asked Jefvin Viriya, my brother (who was still in high school) to help me make the game in time. Having submitted a mini game named Beyond the Well, we came out as the third winner in the competition, and since then, we continue developing games together under the name of Own Games.

We started attending local gamedev events here in Indonesia, one of which was Game Developer Gathering. After this gathering, Kris Antoni from Toge Productions invited me to a meeting with Mochi Media. I got a chance to show DragManArds to their representative and received good feedback about the game. He said he was interested in being contacted again if there’s any sequel to the DragManArds. This meeting made me believe that my game has a lot of potential within.

The meeting with Mochi Media made me believe my game has a lot of potential.

At that time, working on a new Flash game would have been really hard for us. Firstly, Own Games already had a good amount of players from Nokia Store, and we want to keep them happy with our creations. Moreover, I was also busy with my day job as a lecturer, and my brother got overwhelmed with his high school final exams (not to mention that he didn’t understand ActionScript at all). So we continued our life as usual after that time.

A few months later, Nokia launched Lumia, a Windows Phone smartphone. Until this day, Own Games was focusing on feature phones only. We were working in native J2ME and were not really familiar with modern game engines. Then I noticed that one of my juniors had graduated from the bachelor program, and I invited him to work together in Own Games. The first thing he did in the company was port DragManArds to Lumia. The results turned out great: DragManArds got a gold medal in the Lumia Apps Olympiad in December 2012.

DragManArds Gold Medal from Lumia Apps Olympiad — DragManArds’ gold medal in Lumia Apps Olympiad in December 2012.

Then I finally decided to quit my job to completely focus on Own Games. On April 1, 2013, Own Games transformed into an official company. Agustian, a 2D artist, also started to help us out. It was really a big move for us: before he joined, we were short on manpower and, what is more, he had a degree in arts and experience in making games. The first objective became clear: remake DragManArds with more features and better graphics.

Learning From Mistakes and Feedback

DragManArds already has a lot of versions: Flash, Windows Phone, Blackberry 10, and even J2ME. Having received a LOT of feedback, we planned a lot of stuff that we wanted to implement in the remake. It turned out to be a lot of tasks. But as Agustian is a talented artist with experience in game industry, I could fully dedicate myself to improving the gameplay and user experience, and our programmer had proven himself successful in making the Windows Phone and Blackberry version of DragManArds, we believed we’ll make it.

Own Kingdom Banner — The DragManArds remake, Own Kingdom, needed much more effort than expected.

I was too optimistic back then, and set the deadline to 3-4 months (DragManArds was made in 1.5 month by me alone, right?). But we weren’t able to finish everything in that time. As any new startup, we faced many challenges, both technical and not. I often argued with Agustian about how he used a lot of time to draw some tiny details that cannot even be clearly seen in the final game. Meanwhile, our programmer had to work remotely from another city because his father had a serious illness. In the end, he realized that he didn’t have enough time to develop anything and left Own Games. So we lost our programmer, our art assets production took more time than planned, and my entrepreneur’s soul was still on a very early development stage. I used to get a salary each month, now I had to pay salaries each month – It feels totally hard in the beginning even though you are already aware of the risk.

I used to get a salary each month, now I had to pay salaries each month. Feels hard in the beginning.

A few months after our programmer left the team, we met Ray Naldo, a former junior in the university where I worked. But we didn’t want to give him the pressure of developing a game as big as Own Kingdom for his first time. So we decide to make Eyes on Dragon, a 3D endless runner. During its development, we also got some help on 2D art assets from Okky, Agustian’s junior.

Eyes On Dragon: project for the new programmer to adapt.

Meanwhile, Jefvin was learning C++ and tried to make Own Kingdom for Windows Phone 8 using Cocos 2dx. The WP8 version eventually became the finalist of the Indonesia Game Show. During our presentation at the competition, the judges called Own Kingdom’s gameplay a unique and promising one, but pointed out that the program was crashing and the buttons weren’t working smoothly. Even though we didn’t win the competition, this encouraged us to go on with Own Kingdom. But, sadly, once again, we had to put development for WP8 on hiatus when we realized that Cocos 2dx for WP8 didn’t support mp3 files.

Back to an Abandoned Game

A few more months had passed. Eyes on Dragon was published. We were happy with what we made, and decided to go on with the development of Own Kingdom. Ray started learning Unity 4.3 for 2D, Agustian and Okky made more art assets for the game, and Jefvin and I kept improving the game design, level design, and also the whole gaming experience.

The second development phase was not easy, but definitely better than the first one. Continuing the game that was once abandoned is for sure not an easy task, since most of the courage is gone. What is more, there were two desires we struggled with: to make the game better but, at the same time, finish it as fast as we could. Yeah, that’s shameful. Nevertheless, coming back to Own Kingdom had positive sides, too: we already knew that the game is worthy and that a lot of people wanted to see it completed. What is more, now we had a bigger team and some experience. Eventually, we managed to finish Own Kingdom in April 2014.

own kingdom gameplay 1 — In April 2014 Own Kindgom was ready.

The development of Own Kingdom is a long journey, and we realize that it has not ended yet. But we are really happy with the growth of each of us. Agustian has started to become more efficient and effective at allocating his energy to finish the work in time. Ray got a lot of experience in making the game using Unity in both 2D and 3D, which opened the possibilities to reach more platforms. I became more familiar with project management, and got a whole new experience in leadership. But the most valuable thing that makes me really grateful is how Own Kingdom turned Own Games into a more solid and powerful team.

own kingdom gameplay 2 — Own Kingdom turned Own Games into a more solid and powerful team.

Own Kingdom is available in Windows Phone Store and Nokia Store (Nokia X only), and has recently been launched on Android.

Contributions Development Indie Postmortem

See You On The Other Side: How Internet Virality Boosted an Academic Project

February 21, 2014 — by Mariia Lototska

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.

1_Logo_SeeYouOnTheOtherSide — 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.

2_Closure_game — 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.

3_Early_concept — 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.

4_Paper_prototype — 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.

5_Concept_sketch_level — 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.

6_Binary_style — 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.

8_First_prison_room — 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.

9_Hint_LookUpToGoDown — 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.

10_Hamborg — 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.

11_LetsPlay — 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.

12_Group — 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.

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.

Contributions Development Game Development Indie Postmortem

Lost Echo - Seeing It Through to the End

October 23, 2013 — by Mariia Lototska

KickBack is a team of two: Nick Konstantoglou and Vagelis Antonopoulos. Unofficially formed in early 2010, the team was officially founded in 2012. Lost Echo, their first game, came out in September 2013. Nick tells us about their experience.

Overambitious

Before I tell you the story of Lost Echo, I have to tell you the story of the game we never made. I used to do architectural visualization, but stopped for a variety of reasons. Wondering what to do next, the idea to make a game, specifically an adventure game, came to mind. Of course, I made the classic mistake most inexperienced developers make: start with a very, very ambitious idea. It would be a PC game with graphics that would rival games with a budget of millions, and mechanics that would be innovative and revolutionary. While that had over-ambition written all over it, my cousin Vagelis needed no convincing to come on-board. Thus, KickBack was formed.

Nick and Vagelis — Nick Konstantoglou and Vagelis Antonopoulos

A couple of months passed, and one thing became really obvious: we were never going to finish. We had one area with a really detailed entrance, but really blocky surroundings, and a pretty basic movement system working, but that was about it. No puzzles, no mechanics, no dialogue system…nothing. Fortunately, we had the wisdom to realize we were in over our heads, but we weren’t giving up. We shelved the project and thought about our next move.

We considered our next move. — Adjusting our ambitions led us to creating Lost Echo

Enter Lost Echo

We attempted to adjust our ambitions to a more realistic level. We started to consider mobile games. The more we thought about it, the more sense it made. The point-and-click controls made even more sense on a touch device than on a PC, so we weren’t compromising there. Actually, we were improving the experience. We had already bought a copy of Unity Pro, so the cost of just the iOS add-on was something we could afford at the time.

So we started from scratch. And in our naivety, we just made a list of things we like. We quickly decided on the following:

1) Touch controls that made sense: If touch is the input method we have, we wanted an experience that would take advantage of that and not emulate some other kind of non-existent input.

2) Setting: It was a no-brainer: Sci-fi, near-future. We both liked Sci-fi, and the rough idea we had of the story we wanted to tell worked really well in the near-future.

3) Graphics: They had to be the best we could make on a mobile device. Since it was a mobile platform, there was a limit on what we could do already. So why not shoot for the sky? As I had experience in architectural photorealism, I was pretty confident that I could bring the style I had developed over the years to mobile devices.

4) Gameplay: We decided to not reinvent the wheel here. This would be our first game, and so before we threw out the rulebook, we explored it. The puzzles would be grounded to logic, we would have enough variety, and we would have at least a couple of puzzles that would be really fun to do on a touch device.

5) We would be done in six months.

Do you see something really wrong in the list above? At the time, we didn’t.

Realities of Development

The first couple of months were very exciting. We were serious this time, and the project seemed doable in a short amount of time. Using the small amount of experience we gained from the previous project, we were moving very fast. We started with nothing and a couple of months later, we had a lot of things in place, much more than our first attempt. The groundwork for the movement was done, a dialogue system was in place, we had the first silly puzzle, and I had started work on a multitude of areas. Yeah, so the game crashed every so often and all the areas were unfinished and untextured, but it felt like so much was in place.

Since we seemed to be doing really well, we went into feature creep mode. Every couple of days, either me or Vagelis would go “Wouldn’t it be cool if…” and then we’d both quickly decide to do it. The story became more intricate and complex each day (and it was pretty complex to begin with).

We were working more than ever, but we had nothing to show for it.

With the deadline we ourselves set creeping ever closer, we suddenly realized that development takes much longer than we originally thought. We hadn’t stopped working, and we had put a lot of work into it, but the end product was feeling like it was 10 percent better. It wasn’t crashing as much now, the calculations were more efficient, and there was some texturing, but I had to rework some areas completely, so everything felt just as unfinished as before. I remember showing our game to a friend who said, “Wow, you really stopped developing it, eh?”. But we hadn’t. We were working more than ever, but we had nothing to show for it.

Moving On

The next months of development were not pleasant. We made progress slowly. We kept pushing the deadline back, and each time, it was overly optimistic. We started feeling that we might never be done. There was no end in sight. At the same time, this was becoming a bigger commitment than we had realized. A six-month project that then flops is not a big deal; we could rationalize it as it being a learning experience. But as we passed a year of development, the stakes started to get higher.

There were other problems. The 2006 first gen Macbook Pro I had that I did most of the graphics on was really not up to the task. It’s not a bad machine (I’m still using it today!), it’s just that it was really starting to show its age. Baking lightmaps to compute lighting should be a one hour deal, but it became an overnight thing. Testing and tweaking things also was much slower than it should have been. Even Vagelis’ laptop died mid-development.

We realized every decision had to be correct the first time, which was almost impossible, and also made us a bit scared of making decisions.

Things started to get pretty desperate. We realized every decision had to be correct the first time, which was almost impossible, and also made us a bit scared of making decisions. What if that puzzle idea is not good enough, and we have to change it? That will push us back! What if I have to change that model again? I will have to bake the lighting in all the scenes again, and that’s going to take a week! Our inexperience in other areas was starting to show as well. I was pretty confident in my graphics ability as far as environments went, but characters were not something I was strong in. I had to redo some characters three or four times to get them to a passable level.

And Then…

This is usually the point in a story were something really positive happens that changes everything…but nothing of the sort happened. We just kept going.

We had a ton of problems we didn’t have immediate solutions to, and things were looking grim. We kept asking ourselves if we were just wasting our time. But despite all that, we never even thought to give up. Call it tenacity, stubbornness, or whatever you like, but we were determined to finish Lost Echo, no matter the cost. The only thing that changed was that we started looking for a publisher. At first, this game was a fun little project. Now it had become a bigger investment, and we were starting to feel scared. So instead of our original plan of self-publishing, we searched for a publisher. And as with all fear-induced decisions, it was a bad choice. I can’t really share what happened, and it wasn’t all bad, but overall it was a soul-crushing experience, the kind that makes you lose faith in humanity.

A Cliched, but Important, Lesson

In the end, we had to put more effort than ever before. We had to change a lot of things, because many of the decisions were clearly wrong. And even though we were already developing for much longer than we thought we were allowed to, we kept revisiting a lot of the decisions we made.

Lost Echo City — If there is one thing to take from this, it’s to never give up.

In the end, we were never sure about anything. We were never sure if our decisions were right, if people would like our game, or even if we would be able to cover our expenses. We just made it up as we went along and chose to do what we wanted to do. If there is one thing to take from this, it’s to never give up. A cliche, I know, but of all the things we did, this is the one thing we did 100 percent right.

We are also sure that we can do better next time. With the sales and general reception of Lost Echo being better than we expected, it seems that there will be a next time. We couldn’t be more excited.

Lost Echo is a participant in Casual Connect Kyiv 2013’s Indie Prize Showcase. Find out more information about Lost Echo and Kickback studios through their Facebook and Twitter.

Contributions Postmortem

Lost Toys: Landing on Games

August 26, 2013 — by Mariia Lototska

Barking Mouse Studio is a two-person indie game studio in San Francisco, consisting of Danielle Swank and Jim Fleming. They consider Lost Toys to be their first full game. While both are software engineers and artists, they come from opposite backgrounds. Jim took computer science in college and is a self-taught artist. Danielle took ceramics in college and is a self-taught engineer. Together, they tell the story of Lost Toys.

Barking Mouse Studios — Danielle Swank and Jim Fleming

Wandering Through Projects

We met when Danielle hired Jim to work at an interactive media agency. From the start, we wanted to work on our own projects together, but finding the right one took a bit longer than expected. Financial management app? Built it. News reader? Yep, several of them. Database GUI? Yup, it’s open-sourced here. With each new project, we learned a lot, but none of them ever felt quite right.

We did a couple of game jams and had a great time making the (often less than) 48 hour games. With every new jam, we would brainstorm ideas ahead of time. Suddenly, we were talking about games all the time. So naturally, we thought, “We’ll make a game to sell on the App Store! It’ll make a million dollars, and only take a month or so!” We barely knew game-making, we didn’t know mobile, and we really didn’t know 3D. It was nearly a year later before we were finally ready to launch our first game.

First Attempts

Our old GUI system, and the first time we were able to play a level.

Our first attempt at Lost Toys was with HTML5 and WebGL (using Three.js). For us, it was a nightmare. It felt like we had to re-invent the wheel, the scene view, the model importer, the audio player, the renderer, the camera, and… you get the idea. We struggled for about a month, and then realized that we needed something that would just work. After noticing a lot of fellow game jammers using Unity, we switched. In addition to being easier to develop in, this opened up a lot of doors for us, since we could now publish on nearly any platform.

In the trough of doubt between the switch from HTML5 to Unity, we questioned our initial game mechanic. It just wasn’t fitting with the aesthetic (creepy toys) and wasn’t as immersive as we wanted. Our budget was too tight to let us hire voice actors. We needed the environment alone to convey our story, and an unsettling theme can convey a lot of emotion. In the end, we drew inspiration from a lot of sources like Leonardo DaVinci to Apple to the San Francisco Exploratorium and games like The Room, Zen Bound and Cogs.

Scope and Resource Restrictions

Lost Toys — We made progress, but the build was still really unstable.

Neither of us has any audio background, but we know the value of it. It was important to us not to compromise the game aesthetic. Having no soundtrack was better than having one that didn’t fit, and the budget wasn’t there for something custom. Fortunately, we found the beautiful, classical and free Creative Commons licensed work of pianist composer Peter Rudenko. We’ve listened to “The Fall” about a thousand times during development. It’s one of our favorite pieces of music ever, and it fits the tone and aesthetic of Lost Toys perfectly.

We also didn’t have the budget for any kind of custom audio samples or to hire a sound engineer. We looked at a number of websites that sold or offered free stock audio. Most of the sites didn’t offer trial samples, and we needed to playtest different sounds as cheaply as possible. Pond5 was great for this, we could download watermarked audio clips and see if they matched what we were going for.

Since the game needed to be as immersive as possible, we felt that everything should be a part of the game world - including the GUI elements. At first, we tried to make everything skeumorphic, “physical” elements of the game. The first version of Lost Toys was more of a ghost story with little “wisps” that flew around and “oozed” off of the toy at the start of each level. Made up of little puffs of glowing smoke, wisps were ethereal “undo” buttons. Unfortunately, the wisps complicated the code and gameplay quite a bit. None of our playtesters understood what to do with them. So they fell into the dung heap of history, in favor of a minimalist on-screen GUI. Surprisingly, we found that the new GUI helped players remain immersed in the game because they didn’t have to learn how to interact with the wisps.

For us, building a 2D game was never an option we considered. Neither of us are 2D illustrators, and Jim had some old experience with 3D graphics. Plus, we really like the aesthetics of minimal but realistic games (think Zen Bound and The Room) and enjoy puzzle games like Cogs and Flow that take advantage of a touch interface. Because of our 3D requirement, keeping development time under a year was very hard work. We ruthlessly limited the scope over and over again. Despite this, our main rotational mechanic in this “simple” game took three months, several revisions and many individual attempts before we pair programmed a solution.

Getting The Word Out

Why do we need a trailer? We’ve got a laggy video of the whole first chapter!

Lost Toys is our first attempt at a professional game, and rotational math was only one of the many things we didn’t know how to do when we started. We had no idea how to market or distribute a game. We just assumed that was what app stores were for. Fortunately for us, we live in San Francisco, where there is a wealth of established indie developers that are incredibly generous with their time and advice (thank you, thank you, thank you!) Many of them we met through our local IGDA chapter, which is a great organization to join if you’re interested in indie game development.

The biggest advice we received was to start reaching out to potential players immediately. To do that, we needed a great trailer. Like with the rest of our game, and indie development in general, we didn’t have the budget to hire someone to make our trailer. We had to figure out how to make it ourselves with zero film-editing experience. It took us about a week of studying movie trailers to come up with a rough storyboard. From there, we needed to figure out how to make what we wanted. The solution we came up with was to turn exported image sequences into movie clips. The problem with this method is that in-game audio can’t be used. To get around that limitation we borrowed a trick from all those movie trailers, and have a single piece of music playing throughout the trailer which helps tie together all the different bits of gameplay.

Everything Comes Together

The finished trailer

So here we are, almost a year from when we started. Lost Toys won “Most Promising Game” as part of the Indie Prize at Casual Connect, and we’re launching on iOS at the end of October with Android and BlackBerry to follow. As part of the process, we learned to say “no” to every idea we had that wasn’t in direct support of launching a solid game and that building the game is only half of the job.

You can keep up to date with launch notices for Lost Toys by following them on Facebook or Twitter.