Time flies, even when not having fun

I am planning on adding a big update to Find the Gnome for over a year now. But life isn’t letting me, so I’m going to cheat.

The promise

The idea was simple: bring out Find the Gnome, and then add continues updates to it. Increasing (or maintaining) it’s value.

I had invested a lot of free time in Find the Gnome, so some other projects had to wait. Maintaining my house was one of the urgent projects that needed my time, so I made the promise to first fix my house and then continue on Find the Gnome.

Reality Kicking in

The reality is there are always things that need my time and attention. I don’t have that much spare time at hands because of other choices I made in life.

I’m a husband and father, and I want to dedicate a portion of my life to them. Plus I have to get a steady income for them and supply them with good housing and education. That’s already more that 40 hours/week of work and focus.

All my private and professional projects take way longer then anticipated, due to less focus and free time available than I foresaw. I hear from other fathers of young children that this is but a phase of life, and you have to accept it and just wait for better times to come.

For me another thing is on the line: I want to get into game development. I’m currently a software developer consultant in business software, so I need experience in the field of game development to be able to switch.
Combine all things said earlier, and you can imagine I’m having a hard time realizing my dreams.

Time well spend

So I’m currently looking for cheats, and this is what I did find already:

  • It is in our heads things get a meaning. This is and must be the fundamentals to build your business on. Sustainable business profit can’t be achieved without motivation. And in this self-motivation is the key, because all other forms of motivation are unstable to build reliable on.
    Why is this relevant? I came to realize my motivation is mostly based on what others think or what I ‘think’ other think. And those thoughts hunt me and deprive me of my joy in creating things. Like the thought that bringing out an update to Find the Gnome has a deadline. But goals like that don’t expire. You could argue that business wise it probably already expired 3 months after release, but lets be honest: a large portion of professional business objectives need passion and dedication and aren’t that profitable. Life has to be lived, and we need work to feel empowered and to have a meaning. Meaning is something we give to things, this is not something mathematically or scientifically connected to work. So when I think: ‘this update makes me proud’, it makes me proud.
  • Experiences can be gathered from a lot more sources than ‘professionally building games’. That is because tasks have two types of experience in it: the most obvious is the act of executing the task, this will get better and easier over time. And if you don’t do the specific task, your at a standstill. But the other one is way more subtle, and often overlooked when talked about experience: thinking on the task at hand. That thinking is often called ‘seniority’, but I think that is too simplistic. And I like to add that different tasks seems to need different ‘thinking spaces‘.
    Improvements to these thinking spaces seem to be more time related than action related, hence the ‘seniority’ often attributed. But there is more to it: these thinking spaces are only improved by self-reflection in combination with peer pressure. You need time to give certain thoughts way, but you can speed up the process immensely by adding peer pressure that is regulated by a healthy doses of self esteem combined with self-reflection.
    Why is this relevant? I can’t make time to focus on designs for a big update. But I can spend a few minutes to make a custom map for my favorite game, and on the way I learn from the community to improve my level-building-think-space (probably faster then when developing own tools first and having a small audience). I can’t spend hours to design and decorate large systems, but I can spend minutes decorating my house or combining new outfits and talk about it with my wife, improving my design-think-space (and learn to appreciate my wife more in the process :P).

Continues updates (or: after-launch support)

A big con against using Agile with Continues Deployment in gamedev is for me the question: ‘is it feasible as a business model’? Because at the end of the day the amount of work put into continues updates must be profitable to be able to run a business.

This is an article in the ‘Behind the scenes’ category where I share my personal experience developing games professionally.

The case at hand

I am currently thinking a lot about how to continue in developing Find the Gnome, but with a lot more ‘Agile’ and User-centered in this try. I am a professional software developer doing Agile/DevOps/Google design sprints/CI&CD/Metrics driven development/what-else, and I think this is one of my strong points that I should emphasis while developing games. (See my other blogs for more on these subjects)

Recently a Youtube of GDC 2019 caught my attention (thanks google suggestions!) It is a case study from Nick Popovich (Monomi Park), explaining his success. These are the points he made:

  • Keep your game essential (refine on it). And aim these essentials to provide an experience that is able to sell over time.
  • It is all about concurrent players (online, or offline) that are using your game. By using it they are advertising it (through conscious or unconscious updates to friends that they are liking this game)
  • It revolves around a continues game update cycle that keep the ‘concurrent users’ train going (and accelerating, if possible).

His points align very well with my Agile approach to gamedev I want to take.

The cons

However, I spotted some flaws already. For me these flaws aren’t that of an issue, but time will tell.

  • Nick Popovich is making money using this approach, but will others? Or was he just lucky?
  • You can’t just keep updating games, you will run out of money eventually. Or, on the contrary, you can’t just stop updating your game if you had just 1 bad month. In this talk the motivation behind the decisions sounds a lot like voodoo magic: the cause and causality of things aren’t analysed well.
    A start could be in the Q&A part of the YouTube (https://youtu.be/DTvBgmNL-p0?t=3533) where Nick Popovich gives a rough guide on how he uses sales data to space out content updates. I think the ‘something’-like-a-service business model (through all kind of business) are in a maturing stage right now, and more guides on this subject are going to hit the markets in the coming years.

Next

Well, see it for yourself in this YouTube vid and decide if it is worth trying.

I keep thinking about Agile

How can I use Agile methodologies to deliver better and faster with my planned update on Find the Gnome?
It is a question that is bothering me for some time now.

This is an article in the ‘Behind the scenes’ category where I share my personal experience developing games professionally.

The things at hand

When I look at developing games from a birds-eye perspective, I see the following area’s where Agile development has its impacts:

  1. Planning and executing on work
  2. Delegating responsibilities, building on trust
  3. Team-only driven improvements, Full-product deliveries after (a few) iterations, Course alignments on real consumer data only. (Inspect & Adapt)

For point 1, I think everyone is already on board. Across all industries we know the iterative approach is a more manageable way to execute on work. I had trouble finding evidence that game studio’s are on-board too, but I recently saw this YouTube video from a big studio that confirms my thoughts on this (link below).

Point 2 is already a bit more difficult as it seems. I know from personal experience this delegating/responsibility thing (and most of the times, combined with true multi-disciplinair teams) takes already place in the smaller companies. For larger companies though it is really difficult to get away from the line thinking, because due to the scale of the organisation the money and legal things tend to be too concerning to let them being handled by individual teams.
However, I’m seeing signs of change too. Due to the huge amount of pressure to innovate. But they are still doing it ‘differently’ from the small companies because at large there are KPI’s, organisational guidelines and other steering tools that are introduced to keep things in line.

Point 3 is where the icing is on the cake. Because this is where even small companies don’t dare to venture. In this area of Agile, the bosses aren’t the ones leading but facilitating (and don’t like being called ‘the boss’). It is this area where you aren’t an expert when you have idea’s but you are an expert only when you are able to execute on proven demands from consumers, or when you are data-proven able to forecast real consumer demands.
I know of a few companies that seems to have this down, or at least had it down in some point of time: Google, Facebook, Amazon, Tesla, Netflix (or the Chinese counterparts). But these are way too big to be an example for most of the companies in the world, especially game companies.
I did find one example of a small game dev studio that is even able to execute on point 3, see the links on Gram Games below.

But, how?

To succeed on my own game development projects, I have to think big when maximizing benefits from my experience as software developer in business software.

So, I think I have to go with the maximal Agility on my own projects. Inspired by the Gram Games YouTube video I think it will look like this:

  • Keep releasing full products at steam at low intervals
  • Release features stand-alone to mobile platforms
  • Move winning features to the full product release

The release-feature-to-mobile-first is the core idea, and here is some more depth to it:

  • 1-3 iterations
  • Real stand-alone gameplay
  • Full of metrics (but AVG compliant: I don’t need user specific data, only the global feeling)
  • No monitization
  • When 10 people use it 7+ days it is a win for me

The odds

Do I think I am right by choosing such a strange method?

Well, I can only think of 1 real cave-eat

  • It is really hard to separate features and prove their individual value

But other than that, I think It is worth the try.

The links

The video on a recent (2019) big company (Total War series, 550 people) that are doing some Agile form of planning and executing on work:

The video on a recent (2019) small company (Mobile games, 20 people) that are doing maximum Agile:

To succeed, create something you love (it seems)

Well, you probably heard this saying. And it could be that you have positive feelings about this idea.
But this is my take on this saying, and how this send me in the wrong direction.

This is an article in the ‘Behind the scenes’ category where I share my personal experience developing games professionally.

The start

It started with me wanting to make a game. At that time, I did already know it would be hard to keep focus on finishing the game, so I sought advice. The interwebs are full of advice, and the ‘create something you love’ is one of the advices you get for staying motivated.

So, I thought ‘what would be something I love?’
‘Well, me and my son (5 at the time) enjoying building the game together’
And, after some more thinking
‘Yeah, lets create game with a little bit more depth than the average child-focus game in a world childs of 5 could love, and with mechanics they could understand’

That was my start of ‘Find the Gnome’.

The catch

Immediately I ran into problems. My son did like to draw monsters and play monster vs monster scenes with Lego. So I thought it would be a cool thing for my world to contain monsters. But to get it child-friendly, those monsters would need some ‘friendly-ness’ over them. This proved to be very hard. And on top of that, I don’t like monsters fighting monsters.

So I switched focus. ‘Lets build something I like’.
‘Lets think… I want to create a game because that way I discover what parts in gamebuilding and publishing I am good at and what parts I’m not. So just choose… nah, just choose something I am already working on’

That was the start of the 3D-ish puzzle-like game ‘Find the Gnome’ with Gnomes.

And I discovered I don’t like to create puzzle games…

The assumption of the phrase ‘create something you like’ is that you know what you will like, that things you like to play are the same as things you like to create, and that things you like will stay like-able until the end of times.

In hindsight

I do personally think it is hard to find something that you like to play and create, and continue to like to play and create.

And after a few months after releasing this game, I found out that there is something else. Creating games professionally (subconsciously my intention) require other parameters to be satisfied than games created for private use.

I am a professional software developer so each day I build software related things. Thankfully I find everyday something I like in the job I do, so everyday I do what I love to do.
But do I like the subject? Or the people I’m working with? The requirements? All the tasks I have to fulfill? (Answer: not always everyday, but enough to keep the fun in it)
It is this mentality that I had to translate to game dev to get things going again.

And at last, a youtube I did find about this subject. I think it is a bit harsh on personal projects, but on the other hand: developing professional is a whole different game. Thankfully. Because, if not, what would set me (professional business software developer) apart from all those guys crafting excel-sheet-tools in their office-basements?

The game industrie seems to ignore Agile development, but can they?

In my daily life I am a senior software engineer, practicing the latest insights on Agile development. I have seen many business software development in organisations, small and big, old or brand-new (even startups).

But I personally don’t see the fruits of Agile development in game development…

This is an article in the ‘Behind the scenes’ category where I share my personal experience developing games professionally.

TLDR: The byproduct of non-Agile development (long development times, bad attuning to consumers) was always there, but its costs has increased so much that it is now unavoidable to start using Agile development methods.

What ‘Agile’?!

First a quick introduction to Agile development, as I perceive it. Because it is often used as a buzzword with few meaning left in it. Non-agile is the factory line: in advance you plan and rule out all odds, the actual work is thus repetitive and not requiring a lot of skills (although you can argue it can still require some practice… but that’s exactly the problem: no thinking involved). It is input driven: someone somewhere decides what has to happen, everything and everyone falls in line to execute on that. Everyone has a predetermined place and function. You don’t need trust, you need rules.

For me, Agile is the opposite of the factory line. When you are agile you think of what you want to achieve, and make that happen with respect to the current state of the world and the tools at hand. By building on trust, by being in connection with everyone, by embracing the unknown. I think this definition sounds idyllic. And I like it, because I think that’s how humans like to be.

To communicate or not, that is the question

But why all this Agile or non-Agile? Why bother with project methodologies anyway? Just build that game already!
Well, the following picture illustrates how a perfect world would look like. But look at all those connections. Wouldn’t it be great if we could build products in a world where all those connections between the content creators and consumers were flawless?

However from my own experience, all connections between humans suffer from communication issues. At least my communications do. This is the same picture, but now with the possible issues.

Communications in organisations

For me, a project management method is a tool that helps organisations cope with these communication issues. The non-Agile project methods, where almost all game developments methods belong, have the following characteristics:

  • You prepare to make a good-enough product that is sell-able to the masses. (This was done to account for the increasing costs of production, and the consumers accepted it because any product was better than none product at all)
  • You try to mitigate the communication risks by using experts to understand the market’s needs. (This was necessary because your goal was to make something that had maximal impact on as many people as possible, but don’t listen to the individual)
  • You plan in advance with what to build for what cost/benefit. (Because you had to prepare a whole factory line, where profits comes from doing it as efficient as possible)
  • You add a line hierarchy with narrow boundaries to manage your workers. (Because of all these activities, the organisation is like a machine where every gear has its place. But those gears can’t do more than they are ment for, for then the whole thing would turn out to be less efficient.)
  • You use mass media and and deals with large selling companies to get your products to the consumers.

But times are changing. A lot of the problems the non-Agile methods accounted for have been minimized in other ways:

  • Creators and consumers can find each other much more easily. (Much less need for all kinds of parties acting as the middle-man. The internet with platforms like Steam have brought both much more close together.)
  • Costs of tooling is so much more lower. (You can work from home, get tooling on-demand without upfront payments.)
  • Access to skills has changed radically. (Flex workers all over the world are available to you with specialized services.)
  • Access to information has changed radically. (You can learn basic to advance skills using the internet (and time/practice) where previously the access was the limiting factor now our time is the only limiting factor.)

Blast from the past

The non-Agile methods come at a huge cost: the distance of the consumer to the creator is almost automatically enlarged, the time to respond to changes is in terms of quarters and years, and with each change large losses in productivity are unavoidable.

These costs of non-Agile are currently outweighing the benefits.

When I look at modern media, the social media, I see shout outs from gamers all over the world. These gamers spit on the side effects of non-Agile methods and demand change. So, besides the fact that the world is changing faster than ever, the costs of the non-Agile methods are becoming the real issue. Here is a video of a review pointing out issues with game updates that inspired me to write this blogpost:

we CAN do better

I believe in the game industrie. They are showing they want to change.
The rise of Indy development, introduction of DLC, beta releases have become ‘Early Access’, whole new models like micro transactions combined with games-as-a-service.

But is this change for the better? Does it address the underlying core issues?
One could argue that some of the late improvements are Agile development, especially the ‘games-as-a-service’ model. Because a lot of those games increase their features over time, thus start small and become great over time (or that’s their target).

But I think there is very few agile development going on here. No one listens to the consumer. Or when they do, their communication lines are clouded up with bad incentives…

There is some good though. I see signs of a few (mobile) game developer companies that are building games incrementally, continuously having a sell-able product, and closely listening to the consumer on what to build next.
But the majority, especially AAA development, still suffer from the big problems that non-Agile development has nowadays. (Don’t mention Early access, it is often executed so poorly it deserves a blogpost on its own.)

And I want to point out that there are always examples of games that try to approach the problem differently.
One of the latest games I found was ‘Realm Grinder‘. A nice little game that received a lot of good updates over its lifetime that all increased its value, even with game-play altering expansions. The trick here is that these kind of games rely on introducing changes in game-play during the play-time every so often to keep things interesting. I think more game types should try finding out if it is possible to incrementally add to the games without altering all previous build stuff.

And I think I should mention ‘No mans sky‘. Not because of the horrible communications before launch, but because of the big updates that got to the game FOR ALL USERS. Even for those users who did pay already. Many studio could take example from that. I think It increases the bonding gamers have with you. (And for the sunk-money-fallacy excuse: money still comes from new players that enjoy the experience, finding a live and well-patched game from a caring publisher.)

I want to close this blogpost with a how-to. How do I know if a decision is Agile or not? I try to think of it as follows.

The past is: thinking/planning in advance (official name: input driven). The future is: building what’s needed/consumer metrics driven (official name: output driven).

Early access in gaming: Agile development done wrong

As a comment to the following video states:

‘I accidentally bought an Early Access movie at a Walmart a few months ago. The second act repeats seven times and half the dialogue is is unspoken text, but the story is basically alright. Maybe it’ll get better with future updates but I have no idea how to update dvds, please help.’

This is an article in the ‘Behind the scenes’ category where I share my personal experience developing games professionally.

In my opinion, Early access is just a reminiscent of a gone-by area of the style of thinking, trying to get the pro’s of something new but not wanting to let the old go. And yes, the end product is even less desirable than doing it ‘the old ways’. As pointed out by the reviewer in the video above.

Into the deep

Let me break down what I see is happening. And why I think that it is actually a nice try but executed miserably.

From what I have seen in gaming, game development is most of the time executed as a line projects. They describe a goal, get a few brilliant people to figure out how to get there so most things are accounted for (this is the important part of line thinking: smart work preparation, dumb work execution), create a few development teams to execute on the plan, and deliver all the goods at the set date.

This seemed to work well in the past times. But I know for a fact that is a fallacy. There were always signs that it wasn’t the best development method. But they did stick to it because.. because.
Back then there was no real incentive to change. 30 years ago the entrance fee to the gaming industry was very high: you needed connections everywhere to get something build for the right platform and get it published. A few knew how this trick was done, where the lucky first, and could then reign on their thrones for ages.

So?

Well, I think line-thinking is not the optimal approach when creating things. It suffers from a lot of problems. The most obvious: if you’re half-way into the project, big chance you don’t have anything working yet. (Working as in: it could sell for some money) Some less essential parts can be finished, but you need all parts together for it to be ‘the thing’ as specified at the start.
(Read my article on Agile vs non-Agile game development for more about those problems)

It is exactly this issue that early access has: it is a product that only functions as a whole, but someone decided to declare a few parts ‘optional’ and release it anyway.

but planning is everything?!

Don’t get me wrong, I get it on the business side. You want to plan in advance to know how the whole game plays out. And that planning then gives you the (although false) hopes that you have something worthy to invest in.

I like to see it from the consumer perspective. There is a real world out here: people’s tastes changes over time. One year your game is the ultimate, next year no-one plays your genre anymore. And that’s a problem in an era where games take 3 to 5 years to develop.

From my combined thoughts of how things have worked out, I understand the early access move. If a game company had plannen a big game IP, and suddenly sees diminished interests, they wanted to get a piece of the cake while they still can. So there is the early access release.

The early access move became relevant in the last years because there is an increasing pressure to deliver. Gaming has gained significantly increased exposure in the past 15 years. And I think most of the pressure on game studio’s is from the money-injecting side that want Return On Investment and low risks, and see a goldmine currently hitting the big veins they were after.

What do you oppose?

I am thinking about these things for a while now. They are really hard to solve, because there are so many things involved.

But wouldn’t it be great if a game was able to evolve? That you could make a small game first with a small user base and small scope, and iterate on that? (but without calling it sequel x?) I think everything is in place in the current times we live in to make this happen:

  • Very good and easy update infrastructure everywhere (and that people nowadays are trained to accept updates as something good)
  • Much better access to information (and training, and resources, etc)
  • Multiple ways of monetizing (that people are accustomed to)
  • Dev teams are up to this task (and almost expecting to develop that way)

The only important thing is to develop different than before. The planning-and-then-executing isn’t working any more, so get rid of it. Choose instead an Agile mindset (in contrary to the line-thinking). Aim your work and your organisation on the creation of needed stuff (the output).

I have had more thoughts on Agile related to gamedev. Check this blogpost.

Starting a game company

As I see it now, there are 3 ways of starting a game company. They vary greatly in the change of success, but they all have their own dislikes.

  1. Find an investor, or
  2. Do it on your own, or
  3. Just do something

This is an article in the ‘Behind the scenes’ category where I share my personal experience developing games professionally.

I thought I did the ‘on your own’ kind of starting up a game company. But in reality it was more of the ‘just do something’. It did bring me a lot of experience, but the result wasn’t me being independent and having a job in my own game company.

Don’t get me wrong, I value the experience greatly, but if you (like me) want to get more out of it than experience alone… you have to do things differently.

Option 1: find an investor

  • Catch
    • Build on trust.
    • Money injections on various moments in the development cycle.
    • You need to invest your own money and love time, the investments acts as levers for more success.
    • Biggest change of success, if you know what you are doing.
  • Identifying characteristics
    • At least 1 dedicated core team, investors must be able to trust them in being able to deliver.
    • Your daily job.
    • Clear product goal and product vision (for this and future products).
    • You have ample and solid evidence you are making games for markets that want these game.
    • Investors have control over your company and products.
    • 1+ years of development per product.
    • Big budget for marketing.

Here are two video’s that inspired me on the investor subject:

Option 2: On your own

  • On your own
  • Catch
    • In theory fun, in practice not that good. You don’t know when you can support yourself or your family. Brings big issues with timemanagement.
    • The invested time is not worth it (time vs gains) for a long time.
    • In the end you have very few financial means, change of a (even small) success is small.
    • If it works you have full control and are completely self sufficient.
  • Identifying characteristics
    • Part time (or dependent on cheap householding services of others like relatives).
    • Many small games.
    • Max half a year dev time per product.
    • Becoming a master in a niche (genre/style).
    • Small but dedicated fanbase.

Here are two great video’s. The first one inspired me to give it a try, the second one is afterwards when I discovered this option isn’t that great nether.

One important thing on this 11 years thing, if you missed it: the person in the video above made his fame before and in the Indy Apoctalyps. Things are different now. See the next one.

Option 3: Just do something

  • Just do something
  • Catch
    • Fiddling around.
    • Watch out with what you think what you are doing: it is very easy to get lost thinking that you are making something great.
    • Very very few people are able to make money this way. Although we know the examples (I look at you flappybird) these are extremely rare compared to the amount of people that tried. Just buy a lottery ticket, you then at least know your chance.
  • Identifying characteristics
    • You are just doing something.

Here is the video I saw that opened up my eyes and made me think ‘Am I this developer he is talking about?’

Booting up

This is an article in the ‘Behind the scenes’ category where I share my personal experience developing games professionally.

I am currently working on Find the Gnome again 😛

It is almost a year ago Find the Gnome hit the markets.
A lot of the original intended game-play didn’t make it into the version that came out on March 2018.

Expect a few updates in the coming year. They will change Find the Gnome quite dramatically.

I am still recovering from a burn-out, so I don’t promise anything.
But in the past months I was finally able to squeeze some code out again.

For those who think: why not abandoning Find the Gnome and bring a total new version instead?
Well… I am stubborn. It’s my game and I think it could be improved upon.

Update v1.0.2

This is an article in the ‘Behind the scenes’ category where I share my personal experience developing games professionally.

Quality improvements

I did some updates over the past months. The 6th of Juli I did a minor update, and today the 21th of August, I did another update.

  • More vibrant game play.
    • I make sure the action is happening in front of the camera. Gnomes in view do more actions/minute.
    • The visible triggers (shivering/runnig) updated. They had some issues: shivering did not trigger enough, and the panic running did not trigger consequently.
  • More consistency
    • If I need the player to click, I ask him to click. If there is nothing more to a mechanism, I keep to what it really does. So the expectations are now more clear from the text messages.
    • The Chaos mechanism revamped so it guides you in how you have to click the gnomes. And it gives a reward if you do search careful and click controlled.

Sales

A small update on the business side of things.

I did find out what the massive increase in traffic on Steam was that I experienced during launch and the weeks after it.

Quite simple:  Steam automatically starts a ‘visibility campaign’ of 1 month when you launch a game. Combine this with the ‘soon coming’ and ‘out now’ pages, and you have explained all the traffic boost I experienced.

So yeah, this ‘discovery’ of mine was a bit of a drawback. I hoped Steam did some underwater magic and had find some players that probably liked my game. (As they advertise they are doing.) But no, that’s not the case.
It is just… well… if you get increased organic traffic, Steam will introduce you to more players. Otherwise you have to ‘pay’ for more traffic by using the finite supply of visibility campaigns. (You get a finite bunch at launch and you can’t buy them)

And… I did my first sale. 10% off in the week of the 13th of August. That did work too! Got 4x more traffic out of it.

But I really have to get to work on my marketing. And start with a better Steam store page so I can turn the traffic into sales!

What next

I’m currently working on 2 projects.

  1. I’m working out how to improve Find the Gnome to get it to be a more fun game to play.
  2. I want to increase my profile as a game engineer and for that I’m updating my personal website to be more of a portfolio site. See https://erikderoos.nl/portfolio/

So my major gamedev focus is to improve the game-play of Find the Gnome.

This is because I think the game has some major issues that make it fun for a few minutes but not longer than that. Player feedback is also quite negative about the expectations the game sets and what it actually delivers.

I do have a couple idea’s laying around that originally had to be in the release. I’m quite sure they will improve the game, I just could not get them into the release because of issues that started happening in my personal life. So when my things get quiet again I will start by implementing them and just see where it will take Find the Gnome.

Reviews

I can’t build a game without people reaching out to me and to other players informing them about my game.

So, here is some more coverage on youtube.

And some text reviews:

http://findthegnome.hyperstudios.co/

How did the launch go

How did the launch of ‘Find the Gnome’ go?

Thanks for asking 😉

This is an article in the ‘Behind the scenes’ category where I share my personal experience developing games professionally.

Well, it was a really great launch. Way better than expected and received way better than expected. The sales do lag behind, but more on that later.

Expectations on forehand

First of all, what was my expectation before the release:

  • A few more people on my steam page due to being in the ‘just launched’ section. So instead of the normal 30 views/day average, an increase to about 120 views/day.
  • First 3 months a wish list conversion of around 50%.
  • One to three reviews, probably all negative or just indifferent. And a few notes in them how to improve the game for my audience.
  • A better understanding who the audience of ‘Find the Gnome’ is.
  • A few bug reports.

Reality at launch

The day before launch day there was a massive increase in traffic to my steam page. 11 times more to be precisely. And on launch day it peaked at 43 times more traffic. It has seen a decline since then but way less then I expected. Still on all time highs on 5 days since launch.

The wish list conversion is zero to nothing. But still got around 25 buyers in 5 days.
I got a load of people adding the game to their wish list: 4 months having a store page life NETS THE SAME amount of adds as from the day before the release until now (5 days)…

And I got a bunch of reviews: 1x steam review, 3x steam curator reviews, 5x YouTube gameplay coverage.

There were no bug reports.
But there was certainly some expression of not knowing what to expect. In the week before the launch I contacted reviewers to review my game and some of them told me the game was unclear in what to do: I immediately countered it by adding a help section to the game. It became clear to me that there the game-play is not guiding the people in what to do.

Retrospective of the launch

The game was received better than expected. The sales lag behind but I can’t be for certain yet because it is a common known phenomenon that you need to start doing sales in staffels to get people to convert. But yeah, this game is in the lowest regions of Steam units solds, compared to the other Steam games.

I am exhausted. That’s not good: It makes it a lot harder to counter some known issues that did arise on the launch day. As a father working full time at a job, I have a hard time directing energy to any kind of mind activity after working hours. I did promise some more updates on the game but I’m really glad I didn’t mention a time span. So mental note to myself: don’t target launch day as ‘the day there will finally be some rest’ but rather 2-4 weeks after it, and spread the energy accordingly.

The reviews were all-right. Although I did think my audience through, I have a hard time reaching out to them. Instead a whole other audience is playing my game now, and of course they have other expectations of the game.
But that’s oké for me. I just need some months redirecting the game a little so it fits my ‘real’ audience better.

The reviews

Goodies!
The youtube coverage I got so far: