How We Survived Making Our First Indie Game

Taken from the perspective of Danielle Swank and Jim Fleming of Barking Mouse Studio, the following postmortem details how first-time game makers succeeded in the highly competitive mobile games market with the studio’s very first title “Lost Toys.” 

We started Barking Mouse Studio last year, and since our founding, we’ve released one game, Lost Toys, a 3D puzzle game that asks players to fix toys are lost, broken, or forgotten. It’s our first game, not as a studio, but ever. We jumped into making a 3D mobile game without any experience and our past selves would have benefitted greatly if we had known half of what we know today.

With lots of hard work and determination, we shipped the game January 2014. So far, we’ve had about 20K downloads on iOS to date and won a few awards: Most Artistic by Codame, Most Promising by Casual Connect, and even Best Game Design at the Tokyo Game Show's Sense of Wonder Night indie showcase.

While the lessons we learned during the past year helped get the game to where it is today, it wasn’t always easy and we thought we’d share our experiences. Living it was a wild ride, and we hope the post-mortem is interesting.

What We Did Right

Do Something Different, Like 3D

A few months ago we attended a roundtable given by a couple of indie game journalists. While talking about their jobs they all mentioned that they were sick of seeing X type games (X being whatever is popular right now). We mention this not because you shouldn’t make your awesome X type game, just that you should realize and accept the challenge of standing out from all the other great games.

As a first time studio, we knew were going to be up against a lot of indifference since there are about 134 new games released everyday on the App Store alone. In order to stand out you have to do something interesting. For us, 3D was that thing because it’s something different coming from an indie studio.

We also ran into more than one person that immediately said, “but 3D doesn’t work on mobile”. It’s a bold statement and one that struck us as odd because that wasn’t ever one of the things that occurred to us when we started. We just dove in, assuming that 3D would work, and if you look around there are tons of good examples of 3D on mobile. Infinity Blade, Oceanhorn and Republique are just a few examples of what’s possible. As first time developers, we relied heavily on the experiences of others. But if we listened to knee jerk reactions instead of trusting ourselves, Lost Toys would be a very different game today.

Don’t be Afraid of 3D

It helped that neither of us can draw, so 2D was never an option for us. If we wanted to make something that looked remotely professional, we had to make a 3D game. We’re always in awe of other people’s beautiful concept art, ours is always drawn with dry erase markers on a whiteboard. It’s much easier for us to move things around in the scene and do a render then it is to arrange them in Photoshop.

Our first attempt at a bird

While it can be intimidating if you’ve never worked with it before, the 3D pipeline is really flexible and adaptive. It’s a long pipeline, but that’s also part of its strength. We found it great to work with. Each component is simple and modular and they can be layered together to build something complex while keeping the ability to iterate on a piece at a time to achieve greater and greater fidelity, immersion and quality.

In Lost Toys all the toys are wooden and use the same wooden texture. If we had wanted to change them to metal or plastic toys it’s just swapping out a single image. We wouldn’t have to redraw the toys themselves. The whole process would have taken the amount of time it would take to find a good metal texture for free on the internet, so maybe a half hour. In fact, the pipeline is flexible enough that you can even make a 3D game that looks like a 2D game with a cel shader. Ni No Kuni does this really well and Unity comes with one bundled as part of its “standard assets” package.

Ask for Help

Time is your most valuable asset and each layer in a 3D game is an opportunity to outsource. In order to meet our release date we outsourced about half of the model creation in Lost Toys. Unfortunately, it took us about six months of doing it all ourselves before we came to that decision. Initially we were hesitant because we were worried that we would lose too much creative control or the quality of the work would suffer. It’s silly and we’re embarrassed to admit it, but the other reason we were hesitant is because we didn’t want to share the credits screen. Lost Toys was our baby, and it was hard to see the benefits of sharing. Thankfully we came to our senses and struck gold with our wonderful and talented freelancer, Laura Jolly.

Other than Laura’s general awesomeness, there are two main things that helped the outsourcing go smoothly. First, while we didn’t go with someone local, we did go with someone in the same time zone. It meant that we were more or less on the same schedule and we didn’t have to accommodate very early or very late meetings and could give feedback in a timely manner so neither of us wasted days or had much downtime. Second, we only outsourced one layer at a time. For us this initially meant just the unfinished 3D models with UV maps, and we even did that in sections. So we would send off some example artwork of the model we wanted and we would get side, front, top and perspective images of the rough draft. We used Photoshop to draw in exactly where we wanted the slice lines to go plus any additional tweaks or feedback, and once we approved the final version it would be lightmapped and sent off to us.

The nice thing about this approach is that it was a small portion of the overall aesthetic but helped speed up the game creation enormously. Since we used the same ash textures on all of our models you can’t tell the difference between the ones that we created and the ones that Laura created. We eventually decided to outsource the painted texture work for those models to her as well. And that followed a similar process of us providing source colors and palettes and a round of revisions where we gave visual feedback using Photoshop.

Experiment and Give Yourself Time

We self-fund Barking Mouse by alternating day jobs, so every dollar and hour is important to us. During the development of Lost Toys, Jim worked a full time day job and then came home and worked evenings and weekends on the game. Plus he used his vacation time to go to conferences while I worked full-time on the game. For previous projects we’ve switched and I’ve worked the day job. If it’s an option that’s open to you, I highly recommend this funding model. It means that you can have both long term financial stability and full creative control.

Knowing that your development will take longer than you planned is a truth that you have to be very comfortable with. It’s frustrating and doesn’t neatly fit into a schedule, but once you get over the chaos of it all, start to take advantage of the iterative creation process. Playtesting and open betas are great ways to get your game in the hands of real players. These tests are invaluable for surfacing game ending bugs, but it also gave us the opportunity to try new things. Some of them ended up on the proverbial cutting room floor, but the lessons we learned from those experiments made us better developers and made Lost Toys a better game.

Progress!

Get Involved With the Community

Coming from a traditional web startup background where secrecy often trumps collaboration, we were surprised at how open the indie gaming community is. We were able to ask notable people in the industry for advice and guidance. Not only did they spend time with us, they offered invaluable advice on how to launch our first game. Our initial roadmap was a very underwear gnome plan, in that we literally had no plan. It was just: 1) make game 2) ... crickets… crickets… 3) profit!

Getting outside experienced feedback, helped put us on a more realistic track which boiled down to 1) start talking publicly about the game now, even if its not finished 2) do more talking on Facebook and Twitter 3) go to festivals. While you’re building your game, you should also be building your community. Community building can be a lot less daunting if you think about it like this: if you’re making an indie game you’re probably making a game that you love, so all you have to do is find other people that love what you love but aren’t in the position to make it themselves. Most people in the world don't make video games, but many of those people are fascinated by the work that goes into them.

How we prepped for the community

Today we try to pay it forward by hosting a game developer meet-up every other week. Indie games are really fragile projects, so having a support system for when things are hard or unknown is really helpful. You’re much more likely to finish a game if you have other people cheering you on. Even if finishing isn’t your goal, being around a bunch of other game developers is one of the most fun things you can do.

It’s also important to celebrate the successes. Jim and I had a launch party when we released Lost Toys. We wanted to have one even if the game was a flop and even if it was just more money out. It's important to celebrate milestones and say thank you to all the people that helped get you there. Lost Toys didn't get made in a vacuum. While Jim and I pulled most of the crazy hours, it took a village to make this game.

What We Did Wrong

Not Taking Advantage of Out-of-the-Box Technology

Unless your project is to make a 3D game engine, don’t make a 3D game engine — making a game is hard enough and lots of people, probably with more time and experience, have made faster, better, stronger engines. Focus on the game. We started with HTML5 and WebGL thinking, how hard can this be? We lost a good two months of time trying to start from scratch and we’re experienced software engineers with big egos. In the end, we finally realized that we wanted to make a game, not the engine.

One of the biggest reasons we initially wanted to avoid using someone else’s engine was the “engine look”. We didn’t want our game to look like a specific type of game, which can happen when a lot of stock assets are used. We were also worried that an existing engine wouldn’t be flexible enough to do what we wanted. Our fears turned out to be mostly unfounded.

While there is definitely a built-in flow with a lot of game engines and a learning curve, figuring out what that is, is still much, much faster than writing our own engine from scratch. We discovered that the stock “engine” look can easily be avoided in most cases with custom shaders and models tailored to the game instead of drop-in assets.

Not Customizing Our Pipeline

Once we switched to an engine, we should have spent a lot more time up front making pipeline tools. For the majority of our development we didn’t have a level creator and did all the setup by hand. It originally took days to setup a chapter, and we couldn’t change it afterwards. Arrrgh. The one constant in game development is change. Building a level creator felt like a distraction when we were scrambling to just build our game, but it was one of the best things that we could have done.

It turns out that it just took about a day and a half to build and saved us weeks of time. Suddenly the light bulb turned on, and we wanted to script everything. By the end we had the whole model import pipeline scripted. Starting in Maya LT, our scripts cleaned up the files and renamed all our levels of detail (LOD) using Unity’s naming conventions so they imported beautifully. From there we ran the level setup from inside Unity with added all our game scripts, created a prefab and automatically scrambled all of the pieces.

Creating Specialized Systems That Can’t be Reused

Depending on your 2D engine experience you may have worked with an orthographic camera, while 3D games typically use a perspective camera which simulates the vanishing point where things farther from the camera appear smaller. Lost Toys combines both camera types. We use a perspective camera to render the main scene and overlay all the user interface elements on top using an orthographic camera.

We did this because Unity’s built in GUI system is notoriously bad. When we tried to use it, it dropped our frame rate to unacceptable levels. There are other third-party solutions available, but for our simple needs we found them heavy handed. So this was one instance where we felt that we had to build a system from scratch.

I’m still not sure if building our own was the right decision in retrospect. While our GUI works well for the game and scales to the different scene sizes and ratios needed for mobile, it’s tied into our game code pretty heavily and not architected very well from an engineering perspective. In other words, it’s not code we could reuse in another game which should always be your goal when building systems.

…And Optimizing For Problems We Didn’t Have

Especially on mobile, the current platforms are more powerful than we gave them credit for and the situation is only improving. If we had it all to do over again we would benchmark first, and then optimize from there.

Lost Toys takes place in the same environment and all the levels are on screen at the same time and in retrospect we worried way too much about polygon count. Because we over worried about it we spent time and money on two extra lower poly versions of each level and ended up barely using them. We have about 30 thousand polygons in our ending scene on and didn’t run into performance issues because of them and PC games can get away with many, many more.

If we were going to do Lost Toys over again and if we were worried about our final polygon count, we would just drop a bunch of models into a test scene and benchmarked our lowest-performing supported devices to determine our polygon range. However, I don’t think we’d be worried if we had to do it over again. Instead we would just build our game, make sure that it was running ok the whole way through and save all the performance tuning for the end. And really, isn’t that what QA is for anyways?

Remember What We Said About Community Feedback? Listen to it Closely.

Interpreting feedback is tricky. While we actively sought community responses, we sometimes found ourselves dismissing that same feedback. Oops! Even though we felt that did a lot of play testing at various festivals, it wasn't enough since we had some blind spots about our game that became apparent only after we launched.

While playtesting, a few people mentioned that they wanted to look at the toys more. Since we weren't sure how to interpret that feedback we discounted it. When we launched the game it became clear that people didn't always want limitations on turns, and some people just wanted to make free moves and explore the toys on their own, particularly on later levels, which we didn't play test at the festivals. Another Oops!

In the end, we got beat up a little in the ratings and hovered between 3 and 4 stars initially. Unfortunately, we also got lower scores from some professional reviewers then we would have if we had had that feature at launch. We took the feedback to heart, and pushed out an update within the month of launch. Since then we've been at 5 stars on the App Store with better and better reviews much to our relief, and we’re probably slightly better game designers for the experience.

In the End

We’re proud of Lost Toys and very happy with the game. Late nights and long hours pale in comparison when you finally see your game in the hands of gamers. And even starting from scratch with zero game or 3D experience and a shoestring budget, we were able to launch a high polish game in a year. We learned a ton about modeling, texturing, shaders, cameras and post-effects.

For anyone trying to get into game development, we hope we didn’t scare you off. We wanted to highlight the things we wish that we had known when we started to build Lost Toys because it would have saved us a bunch of time. Hit us up @barkingmice if you’ve got any questions.