How we released our first indie game in one year
Learnings and experiences of bringing Totemori to life
Prologue
Totemori is the first desktop game we’ve released. Most of us are avid gamers, but we didn’t know much about the development side of the industry. We needed to discover the pitfalls as we went along. Mito Studio provided the framework and additional resources to develop the game - but without any hard KPIs.
How it started
On a Mito Studio idea pitch Máté and Dávid came up with the idea of making a game. They fell in love with the idea of a game in which an in-house environment was in constant flux when the player wasn’t observing it (think bush-monsters from the Shining applied to inhabited space). It looked like a great idea, so we started building it.
But then we hit a wall... The concept was proven, but we couldn’t figure out what to do with it. We really didn’t want to go down the survival-horror-jumpscare-spookfest route, but we couldn’t come up with anything that felt fun. Essentially, we realized we didn’t really have a plan.
The hardest part is to recognize the moment when you must let your idea go, and let it go for good. We didn’t recognize it for a long while.
After a few weeks of boiling and moot frustration we decided to take some time off and do a little personal game jam. We came up with a really simple idea, sat on it for a week, then made a prototype over the weekend. And it rocked!
What was the difference this time? Mostly, more realistic expectations. We’ve learned from our mistake, and learned to scale down. We then took a simple idea, which was small enough to grasp all at once. While it changed somewhat over the past few months, we had a pretty good idea from day one how it’s going to look like once it’s done. This time, we had a plan.
The Plan
The plan was that we were going to get this down in about four months (in retrospect: hahahahahahahahahahahahaha!!!). We spent a fateful night with figuring out the scope. Our motto was: chop off everything that can conceivably be chopped off. This included a lot of features that made it into the final product in the end, but we were dead set on not repeating our previous mistake.
Enemy AI? You are supposed to play with your pals anyway. Rebindable controls? You can still play the game with one set of keys, right? Texturing? We didn’t even know how to do that in the first place.
Now we had a scope that we felt comfortable with. Next was timing.
We measured out the 16 weeks and decided what is supposed to happen in each one. We knew it probably won’t work out exactly, but we set goals, so there’d be always something we could shoot for.
So what took you so long?
Well, real life happened. A lot of it.
We were on a hobby time-budget. Participating in Mito Studio, we were provided with one day per week to work on this, but we were ready to (and did) invest our weekends and evenings for months to come.
More often than not some of us had other matters to attend to (our real jobs), and it was a challenge to incorporate these blackouts into the project.
The last factor was scope creep. While that’s usually a very bad thing, in our case it was something different. As we went along, we learned, and got bolder.
“Hey, teaching a bot to play the game isn’t as hard as we imagined. Well, I know we agreed on no textures, but I could make the levels so much more beautiful, teach me how to do it!”
In hindsight, what features crept back into to scope were essential. There would have been no point of releasing the game without them. But by accepting our shortcomings in the beginning, when we could add one more thing, if felt like a little victory each time.
The above factors added up to an additional 4 months of development time, but it was totally worth it.
From square one
We have had huge gaps in our experience and capabilities, and this had to be taken into account. We are not game developers by trade, so learning stuff and teaching each other was part of the project plan from day one.
In the early months, we did regular self-training sessions about various topics, mostly related to content creation (e.g. low poly modeling, texturing etc.). We learned on a strict need-to-know basis: get a problem, do some research on possible solutions, pick one, learn, solve it, move on. If something turned out to be too complex or too time consuming we abandoned it in favour of something more simple, and worked within our limitations.
Our most treasured resource was motivation, including ours and that of our additional teammates and supporters. We were afraid, that unless we produce visible results regularly, the excitement will fade and we will lose the will to continue, along with the interest of our fledgeling audience.
To combat this, we did regular mini-hackathons where we sat in a room together, threw away the key, and tried to make as many things happen as possible before the sun came up. Much of the game’s content was born on these evenings, while the code evolved on the weekends between.
In the end, we learned a ton, but there was still some stuff to be done that we didn’t know how to do (or at least, do well.) That’s where Mito Studio came in, and helped us recruit helping hands from within the company, or in some cases, from the expanded network. That’s how Totemori got it’s music, sound effects, a kickass website, and also it’s fourth core member, who swooped in to save the day by taking a lot of burdens off our shoulders when we were out of fuel.
Testing
By trade, two of us are UX designers, so we knew the value of testing. At first, we have conducted pretty formal tests, asking our colleagues to participate. When the game was pretty enough, we took it to meetups and got strangers to play with it. Then we went to some events and got gamers to play it.
As we watched them play, we learned massively. I couldn’t count the number of gameplay changes that originated as a half-uttered sentence by someone engaging with the prototype.
The funniest example has to be the tantrum explosion mechanic. It was originally a debug feature to test object destruction, until playtesters found it by accident and demanded that it be part of the final product.
In addition to gameplay changes, testing also affected the tone of the game, majorly.
We started out with the assumption that our player base will be young, competitive adults (i.e. us), and we had this bucolic image of guys sitting on a couch over cold pizza, grasping salami-stained controllers and flat beers, taunting each other, arguing, boasting and perhaps even raging.
As it turned out through early testing, the game proved simple enough to enable non-gamers to quickly grasp it, and it had just enough randomness to enable people of different skill levels to play with or against each other. This makes it an ideal parent vs. kids game, and we observed kids pulling in their parents and teaching them to play in minutes. So we let go of our beer-fueled preconception, and removed the less kid-friendly content to accommodate this newfound audience.
Why no online multiplayer?
This is BY FAR the most common comment we get on the game. Why isn’t there an online multiplayer mode?
Well, because online multiplayer is very, very hard to build, and for our first game it’d would have been very risky to embark on this endeavour.
Allright. So the game is out, when is online multiplayer coming?
Sad to say, but probably never. In order for Totemori to have online multiplayer, it would have to be a different game.
Totemori was built to be a quick, twitchy multiplayer experience, with a high amount of physical interactions at any given time. Online multiplayer introduces lag, and the game needs to be re-designed with that lag in mind. I’m not saying that the concept of Totemori could not exist as an online game, but it would not be the same Totemori you know. We’d have to start over to make it happen.
Bennet Foddy of Polygon explains this problem in excellent detail.
In addition to the above, indie games are in a very tight spot when it comes to online multiplayer. You cannot expect to have a self-sustaining player base when it’s your first game on the market. You won’t have that critical mass that would ensure that whenever somebody comes online to play, they will always find a suitable partner.
Players are used to big hit multiplayer titles, where there are thousands of concurrent players available at any time of day. When they see an empty lobby, they might not come back another time, making the feature kind of pointless.
Why free?
We decided very early on that we will make Totemori freely available to all, and ask for no money. The reason for this was our inexperience and the fact that we did not commit our lives yet to being game developers. We wanted this to be a fun experience for us, and avoid dealing with whatever expectations a price tag would set.
What about communication?
We knew that the distribution channel will be one of the most important factors to spread our game. Making a landing page and making your game downloadable isn’t a good approach without massive advertising. But we want it to maximize, make it big and reach as many people as possible. Steam has the potential audience and it has a system with clear rules through which you can publish your game. That’s why after some research we decided on the beginning that we should aim for Steam. That gave us the exact frame and tasks to finish the game.
As mentioned, we went to meetups and events as early as possible to test the game and get together with the Hungarian game developer scene. We learned a lot from the swell guys from Gameloft, Insert Coin Association and other freelancer and hobby developers. But the point is you should dive into the scene and industry in which your product exists. You must cherish friendships, and share the knowledge, the fun and the trouble and help each other.
The main thing is, you should think horizontally and start build buzz around your game from day 1 on every possible platform, not just on the time of release. Find your local communities and be a part of them. Find local indie game competitions and enter. Be transparent and tell your story. Share your fails and successes. You have nothing to hide.
List of things we would do differently
Release can wait a week or two
We really wanted to release the game, and as a result, some things had to be left out. The most obvious mistake was not implementing Steam Achievements, which could have provided us with some handy information about how people actually play our game.
Don’t go free right away
As we decided at the beginning that the game will be free to play, we didn’t investigate other games’ pricing strategies, so we lost the chance to learn how to calculate the price for one. Even if we sticked to the F2P plan, we should have checked the game pricing topic to get some knowledge in the topic.
Steam is a must, but Itch.io is great
If we started development now, we’d use itch.io from day one. The itch.io release was an afterthought we set about to do when the dust settled around the Steam release. We were surprised at how accessible and easy to use itch.io (as a developer platform) has proven to be, especially compared to Steam. We could have done our testing and the distribution of development builds a hundred times easier, had we used itch.io earlier.
Share early builds
On that note, we could have involved external testers much more. As many developers starting out, we shied away from sharing the builds until they were ‘ready’. In retrospect, we were too cautious and could have used our early builds as a community building tool by inviting a ‘select few’ by sharing a limited number of beta keys.
All that said…
We believe Totemori has become an immensely fun game to play and we’re proud to have worked on it. Beside allowing us to put our foot in the door of game developing we also were able to gain massively usable, though sometimes basic knowledge of various related technical aspects. We encourage you to play the game, live the experience and share your thoughts with us, so that we can further improve Totemori and make an even better product the next time around!
Mito Studio is the place within Mito where we dream up and experiment with our own ideas besides our daily work. Check out some more clever things.
This post was written collaboratively with Máté Cziner.
