The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
Hello there! 
After the release of my fourth game, I’m excited to write about its development in a Post Mortem type article. Nubs’ Adventure is what I would call an “Exploratory Platformer”. You play as Nubs, a little guy whose house gets destroyed by evil red dudes and accompany him on his adventure to rebuild his home. The game is released on iOS, Android and soon desktop systems (Windows, Mac, Linux).
If you like, you can get Nubs’ Adventure here:
This article starts with a list of aspects that I found noteworthy, which either turned out to be “good”, “bad” or “ugly”. I’ll also try to formulate what I’ve learned during the development of Nubs’ Adventure and what I want to improve in my next projects in chapter “Lessons learned”. Additionally, I kept track of my working hours during the complete development process, from which I’ll try to derive valuable information and data for future efforts in chapter “How long it took”. At the time of writing, it is too early to release sales figures unfortunately. The same applies to the monetization model I chose, marketing efforts and conclusions on how good or bad that went. I will definitely publish my thoughts on these topics (including sales figures) once I have enough data though.
Putting things into categories is fun, so I did that. Let’s start with the good stuff:
The Good
In-game map editor
One lesson I learned from my last game Rico is that if I want to be creating levels manually (that is, not procedurally generated) and in a reasonable quantity, I must take the time to develop a map editor. I wanted the editor to be in-game, so I could pause the game while playtesting, switch to editor mode, change something and switch right back to playing again. I could have NEVER created enough content without a proper level editor. Creating content takes SO much time (see the corresponding “ugly” point below), developing a fast and usable level editor was definitely time well spent. The editor was developed with having myself as the only user in mind. No other person would (or could, for that matter) use it, which lead to a lot of development shortcuts. Here’s a screenshot of the mapeditor:
There is no proper GUI or drag-and-drop interface. For example, you hit ‘G’ to go to ground-editing mode, draw a closed loop with your mouse, then hit ‘space’ and the polygon will be filled with ground tiles. Or you type the beginning of ‘movingplatform’ (you just need to type until the mode you want is unambiguous), define the moving platform’s size with the keys 1-4, then draw line segments to define its movement path. Finally, hit ‘space’ to place it or ‘escape’ to cancel. All other elements in the game can be added in a similar fashion. The editor was relatively fast to implement, quick to work with, but definitely not user-friendly. I didn’t care though, it let me get the job done fast most of the time and that’s all that counts for me.
libGDX
Nubs’ Adventure is my fourth game developed with libGDX. Much has been written about libGDX and its ecosystem, but I think it cannot be stated enough: libGDX is AWESOME! Mario and the other contributors have created such a fantastic game development library. Unlike “bigger” engines like Unity or UDK, it sits at just the level of abstraction I enjoy. In the past couple of years I’ve been working with libGDX and I’ve built myself quite a few things “on top”, but that’s just my personal preference. And the point is that libGDX allowed me to do this, rather than force me into a certain workflow or development style. Simply put: libGDX is AWESOME!
Nubs loves libGDX.. and you should too!
A decent (code) base to build upon
My previous game served as a good base in terms of code. Many classes I could just take out and reuse in Nubs’ Adventure. Both games being 2D platformers helped a lot of course. Many “utility”-classes grew in functionality during Nubs’ Adventure’s development, and I will again be able to transfer large parts on to the next project.
But code wasn’t the only thing I could reutilize from Rico. I gained a TON of experience regarding cross-platform game development: dealing with different device resolutions, input methods, form factors, different app store requirements, Apple’s review process, dealing with customers/bug reports, … the list goes on. All these skills took me a long time to acquire and it was often a painful process riddled with setbacks. Today, Nubs’ Adventure is the game where I was able to hone these skills and put them to good use.
Creating decent graphics without (being) an artist
I’ve always struggled with the graphical part of my games. I consider myself a programmer/engineer/developer, but definitely not an artist. I never properly learned anything about drawing. Professional artists learn about anatomy, colors, practice different art styles and techniques and do all sorts of other things I have no clue about. Besides for my games, I haven’t drawn anything since art class in school. Creating art for my games has always been a big obstacle for me. It even dictated what kind of games I set out to create in the past. The style I’m most comfortable with is low-res pixel art (I’m a walking stereotype, I know). It’s the only type of art-style I can create something in and – given enough time – not be downright embarrassed about it. But I’d still describe my general workflow when creating art as “throw random pixels at the screen until it’s ok”. Creating art is a long and error-prone process for me.
The main reason why this item is on the “good”-list is because I enhanced my crappy art skills by leveraging my programming skills to produce reasonable results. My main weapons of choice in this battle included – among others – randomization, parametrization and particles, all things a programmer can work with. Screenshots probably do a much better job at explaining than words. So here’s a GIF:
Caves have rocks, right? On the left, you see the (upscaled) base sprites that make up the cave scene on the right. They are all really simple! Three bare-bone tilesets, two for the back- and foreground-layer and one for the water, a bunch of small bits like rocks, stalagnates and vines. Also, a single sprite for the particle effects (torches, diamond). Especially the rocks are reused many times in different tints and sizes: Once over the whole background, once for the blue-ish background layer and then again to decorate the borders of the foreground layer in a brown hue. Another area where I applied that technique to break up repetition and make the scene more interesting are the “grassy plains”:
Adding a lot of small grass pieces, as well as small flowers and rocks breaks up the monotony and make the place feel more “alive”. All the pieces are placed programmatically by defining rules regarding what goes where and in what quantity. The final result is rendered to a texture and drawn to the screen with a single draw call (except the moving parts like the particle effects).
You could call this approach “procedural” in some way, but that would probably do a disservice to true procedurally generated art. According to Wikipedia the definition seems to fit though.
Maybe this approach inspires others to try it out themselves. If you’re a indie developer (like me), don’t know a lot about visual art and can’t draw (yup, that’s me), but still want to create art for your games (artists don’t grow on trees, after all), maybe this works for you! It did for me!
Beta tests
Towards the end of the development, the urge to show Nubs’ Adventure to people got bigger and bigger. I decided to start with an internal Android beta test for invited players. I couldn’t get many people to play at first though. I partly blame Google’s difficult beta test program which requires joining a Google+ group, which even I myself had trouble with. Shortly after, I decided to release an open beta on Android that everyone could download and check out (this is not allowed on the Apple App Store). The build was simply uploaded to the Google Play Store like any “official” release, I just marked it with “Early Access” in the title. Strangely enough, some Youtubers already picked up the game in this state. One even got ~11000 views and lead to a lot of (Russion) players.
I also did an invitation-based beta for iOS via TestFlight, which attracted some really dedicated beta testers who provided valuable feedback. One example where this was indispensable was the following: as Nubs’ Adventure is sort of openworld-ish, it is definitely possible for players to get lost. Before the beta tests, I was aware of that, but didn’t realize the amount of confusion the game triggered. Some players didn’t open the minimap when they got lost (which made me introduce an NPC at a critical point in the game who specifically hints to players that they could always check the minimap if they were lost). Other’s found the minimap to be lacking in detail and that it didn’t provide them with enough information about where to go next. After the beta, I spend some time improving the minimap and I think that has definitely paid off.
On Android, where I released the open beta, I also implemented a way for players to donate money by buying me a virtual coffee:
(I REALLY look that pixelly, I swear!)
That served two purposes: obviously, to gauge player’s interest and to maybe raise some money (which it did, even if not a lot). But secondly, it also allowed me to test whether I implemented Android’s IAP services correctly. If you’ve ever implemented IAP functionality yourself, you’ll probably know what I’m talking about. Even getting to a point where you can successfully buy your own products in a sandbox environment took me quite a while. Without doing the beta tests, I would have never been truly sure whether or not I did everything right and if it would work once the game was released.
Closing words: YAY for beta tests!
Cross platform testing
Cross platform testing and deployment worked amazingly well…and it’s all thanks to libGDX. Since they switched from Xamarin to RoboVM, I was able to set up a development environment in Eclipse where I could deploy to all platforms I wanted to support (iOS, Android, Desktop) with “a single click” (it’s a bit more than one, but you get the point). Luckily I have iOS and Android devices to test on, but testing in the simulators/emulators also just worked™. A lot of the differences between the ecosystems are smoothened out and for the most part, I was able to concentrate on the game itself, rather than platform intricacies.
The Bad
Lacking the bigger picture
I didn’t really plan out Nubs’ Adventure from the beginning. I always had ideas floating in my head regarding mechanics, enemies and level designs, but the overall picture was somehow missing… or at least not well articulated.
Especially at the beginning of development, I came up with things that felt cool to me at the time and just implemented them. I didn’t give much thought to whether they fit into the grand scheme of things as I didn’t have that bigger picture. This is the reason why I feel that some of the game’s elements feel out of place. I don’t want to go into detail which elements this applies to because it seems like a very subjective topic and given enough time, I might come to appreciate these elements yet again.
What I definitely regret though is the lack of a big picture from the start. I wanted to make a platformer that emphasizes the exploration aspect more than my previous games. And I also quickly decided on the motive for exploration for your character Nubs: your house is destroyed by evil guys and Nubs becomes homeless, forced to find a new home. But other than that, I didn’t know until late in development how I want to close this arc. Does Nubs just find a new house in the end? Does he build it himself? What is the purpose of all these diamonds you find scattered across the world? The idea to add a magical fairy that rebuilds the house for Nubs if you bring her enough fairy dust was kind of an afterthought. I forced myself into a corner in terms of story and that dictated how I can close it up. I also didn’t find the space to tell the story about why the red guys actually destroy his house. They come across as stereotypical bad guys that are evil just because. I generally hate it when characters are this one-dimensional, but I wasn’t able to fit their backstory into the game properly, which makes me a sad panda.
Writing
There’s not much I can say about it other than: I’m terrible at writing good dialog. I find the dialogs in Nubs’ Adventure partly boring/uninteresting, partly downright cringeworthy. Not being a native English speaker definitely plays a role here, but I doubt good English alone would have been the saving grace. Before Nubs’ Adventure, I’ve never put much thought into a game’s writing. Nubs’ Adventure’s development made me realize that writing is a truly important and complex part of a game… and that it’s very hard to get right.
The Ugly
Content creation
Oh god, it takes SO. MUCH. TIME! The two things I’ve grossly underestimated in terms of how much time is required are level design and the cutscenes. There’s so much effort that has to go into designing a good level, it’s absurd. Well designed levels are a combination of architecture, enemies, traps, collectibles and all the other pieces that make up the game. Change one of the things and the level you have worked on for so long might just be utterly broken. Especially the way in which you design your enemies places a lot of restrictions on the types of levels you can create with them. Changes later in development result in catastrophic amounts of work. Iteration is definitely necessary from a game design standpoint, but turns into a fickle bitch when I have already created X levels containing enemy type Y and now have to redo all of them because I changed its behavior. But even when I properly playtested all the elements before starting to design levels with them, the creation process was still long and dominated by iteration.
While I had a decent workflow for creating levels thanks to my map-editor, it didn’t look so good on the cutscene front. I had an XML-based file format for defining a cutscene, so working on one generally meant: writing/changing some XML tags, getting the game into the state to play the cutscene (by triggering it with my character for example) and observing it. Rinse and repeat. Over. And. Over. Again. I always had to watch the cutscene from the start! You can probably see how much fun it was to apply some tweak to the ending of a one-minute cutscene. I implemented basic controls to at least fast forward to the point in time I was currently interested in, but the workflow was still abysmal. Why I didn’t improve it? Couple of reasons:
I wanted short-term results and didn’t want to spend a lot of time improving my tools (I talk about that in chapter “Lessons learned”)
My codebase didn’t allow time-rewinding. Try telling your physics engine of choice you want to rewind time… mine (Box2D) didn’t like that very much.
I genuinely thought I didn’t need it because I only planned for a handful of cutscenes in the beginning. In hindsight, having a workflow this bad for designing cutscenes was the main reason why there are so little in the game, not the other way round.
In hindsight, creating the cutscenes for Nubs’ Adventure was the worst part of the whole development process.
Motivation
So much was been said about motivation in the context of indie game development… and it’s all true!
My motivation faded towards the end. Development came to a grinding halt. I couldn’t even force myself to look at the game sometimes. Feelings of despair and futility cropped up. “Is it even worth it?” and “will anybody care, even if I do finish it?” were thoughts that crossed my mind more often than I can count.
On top of that, the infamous 80-20 rule struck hard, really hard! If you take a look at chapter “How long it took”, you can see its manifestation crystal clear. There are months with very little or even no progress at all. At the time I kept telling myself that I had so many other things to do (Master’s degree, day-job, other projects, life in general, …) and because of that can’t work on Nubs’ Adventure. Now, having put a safe distance between me and those moments, I can say: I deluded myself. I could have worked on Nubs’ Adventure, I just chose to not do it! There would have always been time, I simply didn’t want to! A few days of inactivity would be justifiable, but a WHOLE MONTH? Definitely not!
I wish there was much I could say about the issue that would improve it. Being aware of the fact probably helps, but there’s no silver bullet in sight. I’m currently trying to find the sources for why my motivation faded. Maybe identifying the reasons can offer some salvation.
How I still managed to finish? Perseverance, probably. The simple realization that I had to work on Nubs’ Adventure even if I didn’t want to. Reading one of the many motivational articles on the topic probably also helped as well as reading about other people’s success stories regarding finishing a game. In the end it was a case of “shut up and finish the game”. I wish there was a better answer… but there isn’t
Improving my workflows
I’ve never been one to do things in a roundabout way. If there’s something that needs to be done, I jump right at it. I’ve never liked doing preparatory work because I felt I’m moving away from the solution and the completion of the task rather than towards it. Working on Nubs’ Adventure showed me that it is more often beneficial in the long run to do prep work and to do it properly. Instead of exporting images from Photoshop 100s of times manually, invest the time to learn how a macro is made and bind it to a hotkey. Instead of cleaning up assets manually, invest the time to write a shell-script that does just that. Dozens of tasks would have been much faster if I had invested the time to do it right from the start instead of wasting a lot by doing it over and over again.
An example: according to my notes, designing the icon for Nubs’ Adventure took around 15 hours. Here’s the final result:
15 hours for this?!?
Doesn’t look like 15 hours of work, does it? But this is not the full picture. Between Android and iOS, you need a total of about ~20 different icon sizes. Luckily, I looked for an Illustrator template and found a good one for iOS. I used that as my base and added the necessary sizes for Android. The template allowed me to design the icon once but export into all resolutions with a single click. Except for one thing: I wanted Nubs to look pixel crisp on all sizes (ranging from 40x40px to 1024x1024px), so I invested time to make that work in Adobe Illustrator. I spent quite a few hours trying to get Illustrator to resize smart objects in a way that kept the pixels crisp… it didn’t work. I had to cave in and manually resize Nubs for each resolution, then apply the glow effect to it. But the template still saved me a lot of time as the background is not pixel art and hence could be resized (and antialiased) automatically. Combined with two shell scripts for renaming the files and creating the proper folder structures, I had a virtually automatic “build process” for app icons for Android and iOS. Iteration is still the fickle bitch it always was, making me redesign the icon at least three times… but the decent workflow saved me from a lot of tedious work and made the process bearable. Morale of the story: I’m so glad I spent the time to develop a template for creating app icons!
This is of course easy to say in hindsight, but when you’re in the thick of things, it was often hard for me to go: “no, I’ll NOT just do this now, I’ll take a step back and examine if I can improve my workflow somehow to make future tasks easier/faster”.
Not all tasks require this much attention to their workflow. It depends on how long a tasks currently takes, how often you expect to do it in the future (which is almost always more often than you initially think, see the icon design example above), how much time an improvement would take and how much time the improvement saves you. I wouldn’t generally advise calculating all these parameters, putting them into a formula and deciding from there… but even making yourself aware that the parameters exist can help you estimate whether or not it’s worth it. Or use a cheat sheet:
Relevant XKCD (when does xkcd ever NOT have a relevant comic?)
Another factor to think about when looking at your development workflows is the FUN. How much fun is it to do what I’m currently doing? As an indie dev, you need to draw motivation from the work you’re doing. It needs to be fun. Just working based on the motivation from having a finished game one day in the future is not enough, at least for me. I NEED to enjoy what I’m doing NOW to some degree, or I’ll not ever get to the “finished game”-stage. Doing monotonous, repetitive and mundane tasks is NOT fun. Burning out on a project is a HUGE risk for indie developers (see the ugly point about motivation), which makes managing the fun factor during development even more important!
The realization of doing preparatory work wherever reasonable was not an epiphany. It didn’t suddenly dawn on me, but was a rather slow learning process. After all, I already did SOME things right at the beginning of development, by implementing a proper map-editor for example. But many parts of the work I did could have been done faster, more efficient, all while having more fun. If I had just taken the time to analyze the workflow first rather than jump right in.
Do more prototyping
One of the main initial premises for Nubs’ Adventure was the exploration of game mechanics regarding the space in a typical 2D platformer. In most games of this genre, the action takes place on the ground. Not that much time is spend in the air, and much less underground. I wanted to explore these two spaces with Nubs’ Adventure. I thought about how movement in the air and underground feels like and how it differs from ground-based movement. What flies, what tunnels through the ground?
I eventually decided on having three distinct controllable characters:
Nubs, who’s your regular platforming hero
the wisp Ally, who’s tiny but can fly (and subsequently explore spaces Nubs can’t go to)
the giant worm Brute, who can tunnel through the soil and emerge only briefly before being brought back underground by gravity (moving through space not reachable by the other two characters)
Closely related to the character definition was their control scheme. I wanted Nubs to be controlled just like you’d expect it to. Left and right to move, button A to jump (with various jump heights based on how long you press A). Gravity constantly pulls him down back onto the ground and falling from too high even kills him. The wisp Ally does not have to fear gravity at all. By simply holding the A button, it soars up into the sky. Letting go of the button lets it gently descend again. Unlike Nubs, who’s horizontal movement is snappy without inertia, the movement of Ally is entirely velocity based. Directional changes can only happen over time, in both dimensions. The wisp is also capable of picking up objects and carrying them elsewhere. It can even pick up Nubs and get him to places otherwise unreachable!
The design of the worm Brute’s control scheme took forever! I think I fully redesigned it at least five times during the course of development, not even counting the times I’ve spent tweaking smaller parameters. I wanted to reflect the worm’s power in the control scheme and eventually settled on the player only being able to make him turn. It’s a force constantly moving forward, crushing everything in its way. To a degree, I WANT the player to feel a bit overwhelmed at first to convey the worm’s raw power better. How the worm interacts with the ground and the air was also a part I constantly kept rethinking. Should the worm be affected by gravity when emerging from the ground? And if so, how? Is the player still able to control the worm in mid-air? (early development GIF: Brute not care about gravity) In the end, the fantastic game Super Mega Worm provided a lot of insight into how a giant worm is supposed to behave. I designed the worm to be nimble underground, but only having limited movement abilities once airborne. I also slowed down time to make enemies more easily hittable without actually slowing down the worm.
Super Mega Worm and Brute – Separated after birth
Another question I should probably have asked myself more often: can I build the levels in a way that’s actually feasible and fun for a giant worm to traverse just as well as a platforming character and a tiny flying wisp? Exploring the spaces that are typically “empty” in a platformer sounded like a neat idea from a game design perspective at first. The thought of having three completely different characters each play a vital part in the game’s progression was really intriguing. Only Ally can get something high up in the sky, and only Brute can smash that underground lock that blocks the player’s path. But unfortunately, this was definitely one of the things that sounded awesome in theory but I couldn’t quite pull off adequately. I didn’t do enough prototyping in the beginning to find enough interesting gameplay elements and settings. Redesigning the worm so many times didn’t help either. I’m SURE there is a lot that can be explored from a game design perspective but what I came up with doesn’t satisfy me. With motivation for the game fading during the later parts of development, I just couldn’t keep iterating and had to fixate the game mechanics at some point. After that, I tried my best to create interesting levels and situations for the wisp and the worm, but could only fully finish a handful for each. My initial dream of having three equally usable characters and having playtime be divided equally between the three crashed pretty hard. Both Ally’s and Brute’s appearances in the game feel like gimmicks to me, even though I spend so much time creating them.
Especially filling the underground with meaning was tough. I knew controlling a giant worm would make an AWESOME boss fight, but what else can I come up with? The mechanic of having to destroy something (a gate, some boulders, …) using the worm in order to proceed lost its appeal pretty fast. The only other thing I came up with was putting objects necessary for progression underground, the worm being the only one who could collect them. It’s a fetch-quest for a giant worm! >:-(
Closing thoughts: I’m not happy with how the two characters besides Nubs turned out and that’s because I didn’t prototype enough before committing myself. In the future, I definitely want to increase the time I spent prototyping ideas before committing to anything.
From the start of development to submitting the first build to the Apple App Store and the Google Play Store, Nubs’ Adventure took 726 hours spread over 2 years to create. This includes:
programming (features, bugfixing, performance improvements, …)
drawing (tilesets, characters, menus, …)
game design
story
playtesting
content creation (levels)
beta tests (one for Android, one for iOS)
marketing (asset creation, press communication, website, social media, …)
distribution (app stores)
What the number does not entail is the time I spent thinking about things while being away from the computer, mostly while commuting. I can’t really put that into numbers, and even if, it would be unfair to add it to the rest. But I’m sure it’s also a significant factor.
I’ve never worked on Nubs’ Adventure full-time. There was always something else I was doing: getting my Master’s degree in computer science, working as a regular employee in companies, working as a freelancer. Doing game development has so far always been somewhat of a hobby or part-time work at the most. You might look at the 726 hours, divide them by a reasonable work week (let’s say 40) and arrive at about 18 weeks of development. Not even five months… that doesn’t sound like a lot. Given I would devote myself fully to game development, I could theoretically release a game of this magnitude about twice a year… except that I couldn’t! The thought of working one a single game 8 hours a day, 5 days a week kind of scares me, to be honest. Game development is a mentally draining activity. The idea of doing full time game development sounds awesome, but I’m not yet sure if I’m build for that.
Anyway, here’s a chart showing the hours I’ve worked on Nubs’ Adventure for each month from May 2013 to May 2015:
What the hell did I do during August 2014?!?
Looks like a pretty typical indie game development project to me. Good motivation at the beginning, indicated by solid 25+ hours each month, even close to 100 in June 2013. And then the first dip, arriving at its low point in April 2014. After that, a short (yep, I’m calling 3 months short) motivation surge, possibly guilt related. The development comes to a crashing halt in August 2014, where I didn’t work on the game for a single minute! I was burned out! At that time, it could have very well been over for Nubs’ Adventure. For some reason I can’t really explain, I somehow managed to motivate myself again to come back and continue working. This also roughly marks the beginning of the 20-portion of the dreaded 80/20 rule about project length in software development. Lots of smaller ups and downs with regards to working hours I managed to put in, as well as sluggish development in terms of getting the last pieces to work dominated these months. April 2015 was probably the last well-intended effort of a burned out individual to finally getting it done, once and for all… and I did! I powered through! March 2015 consisted of bugfixing and cosmetic changes, as well as handling the distribution and beta-tests.
Another (hopefully) interesting analysis is the distribution of work between categories. I labelled each work I did as either “programming”, “content”, “graphics”, “idea/brainstorming”, “marketing” or “sound/music”. This is the result:
Programming was the biggest amount of work still, taking about 40% of the time. Content creation (which involves designing levels and creating cutscenes) comes in second place, taking slightly more than a quarter of the full development time. To my surprise, drawing the graphics only took about one sixth of the 726 hours. I attribute that mainly to my programmatic approach to drawing (see the “good” point about drawing above). I’ve never been a big “marketeer” (is that a word?), which is why the marketing portion is really small. And I didn’t do sound and music myself, so the only thing I had to do regarding music and sound was to integrate it into the game.
Maybe these numbers can help other developers put things into perspective. I don’t claim that my results are more than a single data point, so I’m hoping more developers collect and share their numbers with the community. Having this data will definitely help me estimate future projects, I hope it helps you too!
Developing Nubs’ Adventure has been a rollercoaster ride that was partly amazing, partly boring, partly downright depressing. I’m currently incredibly happy that I’ve managed to stick with it to the end and release a finished product! I can’t however make ANY comment on whether I like what I’ve created or not. I’m too close to it to say anything about it. Maybe in a couple of months I’ll start to hate the game. Or maybe I can look back and say: “I created Nubs’ Adventure and I’m proud of it”… but I can’t do that now. All I’m currently hoping for is that people genuinely enjoy the game. That’s all!
Thanks for reading!
You can get Nubs’ Adventure here:
Source:The fine details of building a small-scale, exploratory platformer for mobile