Some things you may learn as you release your first indie game

There’s always something you could have done better and that’s okay.

Just like the title of this article, my first article on Gamasutra. I probably could have come up with a better one if I had put a lot more time and effort into it, but settling on this one and getting started, I know that I’ll learn from the exercise and probably have some better ideas next time around. My point here is not to be afraid of making mistakes because next time it will be less likely you’ll repeat them. Failure is often viewed as a negative thing, when in fact it should be viewed as something that gets you that much closer to success.

Grapple Bear trailer

A bit of background about myself: I’m a solo indie game developer coming from an artistic background and I got into game development a few years ago after teaching myself 3D modeling for a conceptual art project. Since then, I’ve been working on creating games that are challenging yet accessible and beautifully crafted, with a unique art style. In the run-up to the release of my newest game, Grapple Bear, I have decided to sit down and analyze some of the most important lessons I learned from this project and won’t be repeating any time soon. As the saying goes, it’s good to learn from your mistakes but better to learn from someone else’s.

In this article, I’ll be outlining some of the biggest mistakes I made and learned from in the development and release of two commercial games: DamCell and Grapple Bear, so that you might also learn something from them if you are developing an indie game for iOS or Android. Damcell is a puzzle RPG with hand-crafted dungeons, complex environmental puzzles and an uncanny aesthetic. Grapple Bear is a hand-drawn, skill-based platformer with a cartoony art style and physics-based swinging mechanics to move around progressively more difficult levels.

DamCell iOS release trailer

Finding the Fun: Playtesting

Feedback is, as I know now, an essential element in the early stages of your game’s development. Determining whether the mechanic you wanted to use is fun to play with or the puzzles you thought of are easy enough to understand are crucial to making a successful game. I have found that a good way to get free feedback from a relatively large audience is to participate in game jams. Game jams are ideal for prototyping and failing quickly, with an almost instantaneous feedback loop. Game jam play testers, unlike your friends and family, are not trying to spare your feelings and will generally tell you what they really think of your game. Therefore, if the feedback you’re getting is mostly positive with minor issues then there’s a good chance that you have something in your hands that is worth further development. Don’t forget that the game you make for the game jam is just the minimal viable product. By this I mean it gives a basic picture of what the game will be like while also being fun to play. At this point, there’s still likely a long way to go to make it a fleshed out game.

Selecting an art style:

When beginning a new game dev journey, there are a number of different art styles you can choose from. Whether it be pixel art, watercolor, 3D, cell-shaded or hand drawn and so on, there are certain factors that go into the decision of which style to choose, as they all require a different pipeline.

Grapple Bear screenshot

When developing DamCell, I set out to make each room and each dungeon unique and to hand-craft all of the levels individually. Coming from a fine art background, it felt natural for me to approach each dungeon layout composition-wise like a painting on canvas.  I soon realized that this was a big mistake. This approach actually made repairing broken puzzles much more time consuming and scrapping art assets more painful than if the rooms hadn't’t been individually drawn. What I should have done is create and use prefabs to construct the levels, saving a lot of time and hassle. With prefabs I could have experimented more with designing elements such as puzzles and made changes more quickly and freely. The result would have been better thought-out puzzle challenges that would probably have been more enjoyable and less frustrating for the player. Overall, using prefabs would have produced a game that would be more polished and have taken less time to make, with the level design benefiting the most. I later applied this lesson in Grapple Bear, making it much easier and faster to prototype new ideas and see how well they translate into the game. This method makes adding potential game mechanics easier to do. While it might seem obvious, it’s worth bearing this in mind so that you don’t end up having to learn the hard (and long) way.

DamCell screenshot

Another modification in the pipeline for my second game is the use of pen and paper. I have found that taking a break from the screen from time to time to write, draw or doodle ideas in a notebook to be pretty useful. I started off using pen and paper for a game jam and soon realized how freeing it felt to use this analogue medium again, as opposed to working entirely digitally. Using a pen and paper forces you to slow down while also allowing you to express and explore ideas in a different way than via the computer. This can free up more creative thought and sometimes enable you to work through ideas faster. While the work on Damcell was entirely dependent upon time spent at the computer, I spent a lot of time planning and designing Grapple Bear elements in my notebook that I carried around wherever I went. This made for quite a different game development experience, where creating art assets on paper was not only possible but also just as fast as digital drawing methods.

A few rules I set for myself that you might find helpful:

Pick an art style and execute it well. As there are lots of different styles I like to work in, I have to force myself to keep the art style cohesive for each game during the long development time. It can be easy to get bored with one style doing this, and so it can be helpful to take short breaks, even for a day, to work on other creative projects and refresh that part of your brain.

As far as the execution goes, highly detailed art is not necessarily better. Sometimes simplicity can often be harder to execute well but can also more effective and more elegant in the end. It goes without saying that professionalism in design is paramount. Although being a solo developer has its selling points, these can be detracted from by your game actually looking like it was made by one person. Being a solo developer means you have to wear many hats, and inevitably will be stronger in some areas than others. You just have to figure out a way to disguise it.

Stop putting off fixing issues in your game, as there’s a good chance they will end up not being fixed. Similarly, don’t spend a long time on placeholder art. Issues like poorly drawn assets, messy looking menus, animation flaws and random white pixels should not be underestimated. Leaving them there as you work around them opens you up to the risk that you get used to seeing them, forget about them and then ship the game with the flaws. Try to look at your game through the eyes of someone who hasn’t seen it before, or even better, have a fresh pair of eyes give you their feedback as to what looks good and what doesn't. You want to make the game as close to perfect as possible by the time it reaches users. Sure, you can add updates after the launch, but at this point there’s a good chance you might be less motivated to go back and make those changes, or you might be busy with your next project.

Be aware of and play to your strengths and weaknesses. For me personally, art is a priority in the games I produce as opposed to say, developing a complex and revolutionary new game mechanic. If you have the manpower to create time consuming art, beautiful animations and multiple game mechanics then you should exploit those opportunities. Certain game genres are more suited to develop in with certain skill sets and it’s important to know what is best suited for you.

Playing to your strengths and bearing in mind the KISS design principle (keep it simple, stupid) leads onto my next point: be realistic about what you can achieve in a reasonable timeframe. I put a lot of things into Damcell that were arguably overshooting what I should have aimed for in my first game. Elements that complicated the game such as time consuming painterly animated cut-scenes also slowed down the pipeline considerably. The longer the development of a game takes, the longer it takes for you to learn from the mistakes you will make.

Choose the platform(s) best suited to your game and you. Grapple Bear was intentionally made for mobile platforms as the input is ideal for touch controls and the levels are designed to be played in short sessions on the go. While it could work as a computer game, it would not be compatible with a controller, for example. When developing for mobile, another decision I had to make was whether to go with a Free to Play (F2P) or Premium scheme. It’s important to note that F2P games need to have a “hook” and a considerable amount of content that will lure the player into playing for hours and ideally, to spend money as well. As all of the levels in Grapple Bear and DamCell are handcrafted as opposed to being randomly generated and made by one person as opposed to a big studio, it wouldn't have been feasible to produce a quantity of content needed for the F2P scheme.

Development time for DamCell took 7-8 months but after applying these hard learned lessons, Grapple Bear took only 4 months. Going forward, I’m continuously experimenting with new game mechanics and new styles for future projects to make the game development pipeline even more efficient and optimized for creativity and productivity to work hand in hand.

For those reading who work as a team or solo on game dev projects, I have added some links to upcoming game jams where you can start making your own mistakes to learn from and maybe even try to apply some of the lessons in this article. I have learnt a great deal more from participating in game jams than from longer projects. Even so, the long development projects are also essential in learning how to finalize, polish and market your game.

And remember: think of failure not as a dirty word but as a key to success; each mistake teaches you something that you can use to keep improving and moving forward. Good luck!

Links to some game jams:

•Blackthornprod jam: https://itch.io/jam/blackthornprodgamejam2

•Brackeys https://itch.io/jam/brackeys-2

•Ludum dare: https://ldjam.com/

•The biggest itch.io game jam where you’d likely get the most feedback is Mark Brown’s GMTKjam (where I prototyped Grapple Bear), this year’s date TBA.

You can find all my games at BrightHandStudio.com

For any business inquiries, feel free to contact me at [email protected]