A Woodsman: Post Mortem

(Cross posted from here)

A Woodsman has gone live (Buy it here). The game serves two purposes for me. In a creative sense, it was trying to capture something I enjoy (exploring a space) and haven't seen done in the form I enjoy adequately in a game since its biggest influence, Uncharted Waters : New Horizons. The other ones is to go through the process of releasing a game  for sale in preparation for future titles. I wanted to shake out as many issues so I am better prepared since despite being a professional developer for nearly a decade, I was insulated from a lot of the aspects of actually releasing a game to the world.

I am going to break with convention a bit. The post mortem will primarily be a history of development, with a small section on good, bad & learned at the end.

In the beginning... 

The game actually started as an interest in creating a sandbox where you can push around sand, changing the flow of water in December 2013. Although I quickly decided to move beyond that and toyed around with a block world you could map (e.g. mapping in Minecraft) and built the first iteration of the world generator. From that point it sort of morphed out of my desire to capture some of what I liked about the early Uncharted Waters games, and to (finally) bring an idea I have had for about twenty years to life.

My favourite early anecdote during development involed the world generated and a bug that magically made the world's pretty. Early implementation of biome distribution looked sort of right, but really bad. I use a complex set of rules and distributions to determine what goes where. After a two or so month break I came back to the game and started working on it again. I happened do a quick check on time and just happened to randomly get the right seed, which had a bad tile, which allowed me to identify some values that weren't set right. The worlds went from something vaguely reconisable to actually looking like biome distribution maps of real places.

Early on in development I settled on what would be the first of three tenets guiding me in developing the game.My previous game never got anywhere since one small feature for it involved me exploring four different techs (flocking, fluid dynamics, rubber band physics, and something else I forget now...) without even finding a remotely acceptable solution but using up months of time. On A Woodsman I ended up sinking a month into building a voronoi generator in the hopes to use it for world generation. In the end it just didn't work, but that month was mostly lost (until I need voronois for something...). As an occasional project at that point, that wasn't too much time (by hours) but was a big span of time. So I decided to force myself into drastically limit the 'new tech' I would use. I would still continue with my custom engine (I have a lot invested in it) but few new 'big' things would be added. In the end I kept it to multi-threading, streaming world, procedurally generated world, audio synthesiser, and shadows.  The last two were a late additions that I decided to allow because initial tests went quick (shadows) or I felt they were consistent with the general game design (audio). The limitation was important though. 

After getting the world generator acceptable I spent a lot of time exploring, refining and dropping gameplay ideas. These include a health bar, trading mechanic, interactive movement, 'language learning', and others I can't recall now. Health was dropped entirely because it took too much focus away from just wandering around exploring (the second tenet). The trading mechanic morphed into the current tool unlocking system for similar reasons. The interactive movement involved dragging the screen which was very tiring, then touch and drag the avatar (which was confusing), and then now just touch the screen as a target for the avatar. Language learning started as word matching, then became concept matching. I did the latter with puzzle looking pieces and folks started trying to fit them together, so it evolved into the actual puzzle game. 

Many of the changes to mechanics were guided by the third major tenet of the game: minimalism & direct interaction. Most of what I do is heavily influenced by minimalism. This is partly pragmatic (I work solo currently), but partly something that appeals to me (minimalism shows up throughout my interests and how I live). UI was also strongly influenced by my work in localisation. Less text = less localisation. It also means less issues with sizing. That is convenient some support for variable screen sizes is still necessary (it is way better than when I started on feature phones). In the end I did add a few small bits of UI back that I wasn't keen on (the tool bar and tooltips in the historian dialog) but I still did keep much of the UI to a minimum.

Late in development I did two major refactors. This was a decision I was cautious about. The intention of the refactors was to improve performance and allow for the game (and future games built on the codebase) to be ported to other platforms easily. The first definitely happened, and I am in the process of taking advantage of the later for the iOS build. The uncertainty comes with the timing. I sank nearly three months into it. Part of the reason for such a substantial time commitment was the shear volume of code that had been written already and needed to be converted (Java to C++) and debugged. There was a remarkably low issue rate. That is probably because I have done similar conversions, and just general multi-platform code, for years. But still, had I started the code in C++ or done it a year earlier, it would have gone quicker.

Of course there are reasons for the late start. The first is tenet #1: No new tech. Building native support wasn't strictly necessary to release on Android. So I put it off partly to avoid doing tech work instead of game work. There was also outside factors: native support in Eclipse didn't (easily) allow debugging. Yet the recommended IDE, Android Studio, didn't have very good native support yet (1.5? was about where it finally started being useful). So I had a similar pressure to the no new tech rule in that I didn't want to waste time on things that didn't help; I have spent enough of my life debugging with bad/no tools.

After the large refactor came a quasi polishing stage. This is also about the same time my professional contract ran out and I opted to go solo full-time over renewing it. I say quasi polishing since polishing usually means improving game feel with smaller changes. Although I did bug fixes and refinements, I also added in shadows (~2 weeks), audio synthesis (2 weeks?), and procedurally generated buildings (~1 week, only pyramids; dropped plans for all buildings). They were all things intended to drastically improve how the game looked, but all with limited success and it is debatable if I should have done them. The procedural pyramids look nice (I think), but without adding support for the other buildings there is inconsistency. Shadows add a lot, but there are issues because of the day night cycle and range since I used shadow maps. Audio synthesis was pretty much a flop. The only good thing that came out of it is that some looping sounds are less 'loop-y'.

Pre-launch bug fixes started off well. I managed to fix a decent amount of stuff quickly. I was still finding bugs right up to launch, which is pretty normal. However some of them could have been fixed earlier. 

The actual launch had several hiccups. I delayed it a week due to businessy reasons. I had to fix my account country which wasn't quick. I had to open a new developer account and transfer the game because I can't just rebase accounts (and wanted to separate personal from business). I discovered the pre-launch testing which identified a major crash in older devices (ones that cover ~1/3 of android install base) literally hours before launching. I had to recreate the app to make it paid because I had it set to free for the Alpha/Beta because I am not charging users who are kind enough to test an unknown, buggy app. Despite it being built ideally for tablets, GooglePlay isn't convinced, yet provides unclear guidelines on how to get the app considered 'designed for tablets'. Several times I have missed questions and comments online because places either have notifications off, or don't even offer it as an option. Users of the alpha/beta builds not only have to actively submit crashes, the option is often not even available; I have been told about several crashes long after they happened meaning there is no info to help me fix them. You can only find the game by the link or search for its exact title on GooglePlay; obvious keywords (minimalist) don't work, nor does it show up yet if you browse (by genre, new releases, new paid, etc).

What worked:

Having the guiding tenets helped. "No" new tech, minimalism, and (not explicitly mentioned) sticking to exploration. They helped me avoid wasting too much time writing code that may not even be useful, limited things that could require substantial debugging time (e.g. complex UI) , and features that are not fun or at least related. 

Having experience with the platform and tools. I am kind of a hypocrite since I encourage others not to make their own engine, and yet do it myself. There is a reason though: my engine is in its second iteration and is built both on the earlier iteration and substantial professional work in & on others. Although time is lost in some ways, debugging and adding new features is often a lot quicker because this is the tool I know best.

What failed:

Despite restraint, I still spent substantial time building functionality that wasn't used. Although an even bigger issue was building functionality that was used, but isn't in as good enough state. The audio system is terrible, the shadows are buggy, the procedural structures are incomplete. Aspects of language generation aren't even apparent to the player.

Debugging and play-testing was far, far too limited. There are bugs I should have caught sooner. There are bugs I should have fixed sooner. There are gameplay issues that are still difficult to understand, or non-intuitive, that I don't have good answers for.

I am still learning to have a public presence so that folks know about my games. I have made some steps to at least exist publicly, but have a long way to go to being more active, available, and engaged. I am still at a loss for exactly what works for me and doesn't, but at least trying to do something is a first step.

What I learned for the future:

Better define the project earlier. The origins as a personal interest make good definitions difficult. The iterative nature of games doesn't help that. However something a simple as the 'exploration only' tenet earlier would have let me cut some features before I even considered implementing them (it did later). As time went on I also became better about asking the question of 'what does this add?' If the answer is nothing it probably doesn't belong. This shouldn't be confused though. Little seemingly meaningless bits of polish do have worth (more professional appearance), but subtle features and mechanics might not (e.g. language capitialisation existed in the language generator. But capitalisation is not only meaningless, but potentially confusing, when you aren't familiar with an alphabet).

GooglePlay's Alpha/Beta test and Pre-launch testing are useful, but I need to do some management around them. Pre-launch should be turned on right away if you lack test devices. For Alphas & betas at the very least making it clear you need the crash reports, and at best provide an automated system (e.g. Crashlytics) so they can actually be fixed. 

Speaking of testing, keep a basic checklist to smoke-test some very basic things. For example, one crash an alpha tester found I would have found (and fixed) in minutes had I just done a quick pass on the APK before uploading (I should know better; but even when you do, you don't always think about it).

Simply posting about your game is not enough. You need to be active, you need to engage people. I haven't actively done marketing or sought out reviews yet, although I am aware of their value too and plan to improve upon that.

Some more general design things I came to appreciate surround player focus and touch. Consider where the action is on screen. Subtle stuff is missed a lot more easily than you may think. A lot. I didn't realise how much until a relevant pop-up was always missed by players. Action can also be easily covered on a touch screen. Touch, although easy, should come with the expectation it will be used economically. I.e.a lot of meaningless repetitive touches are not fun, keep it to very purposeful things (touched a button, dragged a thing), or short bursts (tap tap tap). 

'Hitting the button' is anti-climatic. Probably because not much happens instantly. Takes hours of prep to hit the button, and even though the game is 'live' it won't be fully live for a while after (took an hour just to show in the store where I am, nevermind the search/browse issues I have had).

What's next?

For a woodsman there is still a few more days before an iOS build is stable. I also want to do a patch with some more fixes and maybe another asset or two for the game. I was not expecting much directly to come of the game (my sales goal was 5 copies) for various reasons so I didn't plan for too much after launch.

Beyond that I will begin work on my next game, with the goal of being something more stable, more in line with professional work I have done, and actually have the goal of earning something.