34 Polish

Polish isn’t my cup of tea. But playing a polished game is definitely more fun than a rough one. So I go polish hunting this time!

Its only a few years now that I am actually able to handle feedback. So I take a look back at how I became more easy on myself.

Enjoy the read!


No game-play fragments this time. Making video content is very time consuming, I had other priorities this week.

Getting feedback

My plan is/was to release a public Steam version in 2 weeks time from now. I have like 3 levels ready, and felt like I could make a push for it to release something worthy. And from there on improve it.

However I haven’t shown my ‘improved’ version to many people yet. Yes a lot of the content is out in the open, and yes I actively test my game in a closed group, but I have not actively asked a larger audience for feedback. And that was stinging me, not ‘actually’ knowing if my improved version of Find the Gnome is actually an improvement.

So then an opportunity opened up: this new reddit group r/DestroyMyGame came along. It focuses on providing ‘actual’ feedback instead of the default ‘O your game is awesome but I dont want to discourage you and hurt your feelings’ comments you normally get.

I got destroyed: https://www.reddit.com/r/DestroyMyGame/comments/o4wqug/i_recreated_my_game_is_it_better_now/… and to my surprise they got some really good points.

It might be clear that I’m not going to release in 2 weeks time hehe.

Polish, not my strength

Almost all things pointed out are, sadly, known to me. I hadn’t given them priority yet.

  • Fading in/out gnomes and the helicopter instead of the hard appear/disappear they currently have.
  • No feedback when clicking gnomes.
  • Bad UI, mostly unnecessary.
  • Overhead map has too much detail compared to the levels.
  • The tutorial level looks really nice, but the mansion is ‘meh’.

I do think this habit of me of not applying polish is a bit problematic. Roan has pointed out some bugs for a few weeks straight before I got to fix it. And when I ask people for feedback they immediately pointed out stuff I already knew, these points are apparently so distracting. (And maybe I am missing out on other feedback because of this?)

However I do have to give myself leeway. ‘Knowing’ what is broken isn’t the same as knowing how to fix it. I think that is my main issue, I just don’t know what to do if the solution isn’t that apparent.

And there is another issue: I know that I can fix anything, given enough time and iterations. But I don’t have that much time available per week, and to redo stuff feels much less like progress comparing to adding new stuff.

These are my interpretations on the feedback and the approaches I am going to take to solve them:

  • Fading in/out gnomes and the helicopter instead of the hard appear/disappear they currently have. I have to just fix this, its on my own list for months already. Difficulty that withheld me to do this until now is how to fade an object. I looked into it and it is actually fairly easy.
  • No feedback when clicking gnomes. This about FX and animations, I am just not that versed into this. But I know already a few possible fixes. I only have to test which one looks best.
  • Bad UI, mostly unnecessary. Yeah, I know. I specifically told: its a placeholder. But after thinking about it some more they actually are more right than I thought them to be. The current implementation contains a lot of unnecessary elements: you can complete the game without needing most of them. Other games in this genre do this minimalist hand drawn UI. I am not fond of that. I have to give it some time and active experiments and try out a few different things to see what works for the looks. And the objective system is too complex, its can be simplified into ‘find x amount of gnomes’.
  • Overhead map has too much detail compared to the levels. I had the same feeling. But what is a proper solution to fix this? I need to have some content on my overhead map, cant just delete all trees… and then it dawned on me: I think the coloring is wrong so you get distracted by unimportant objects, and I could experiment with the block-ish island-ish approach I have in the tutorial level and apply this to the map too.
  • The tutorial level looks really nice, but the mansion is ‘meh’. I do have the same feeling as they do, but couldn’t point out on how to improve upon this. Until I came to that same conclusion I had on the overhead map: its about visual consistency. The island-ish approach (from the tutorial level) makes scenes much more interesting to look at, gives it a distinct vibe, and break up colors (so you don’t end up on uninteresting big large brown-ish fields).

So that’s quite some changes I have to make. I have to revisit a few level designs. Fully overhaul my UI. Experiment with colors.

But it feels really good actually. To know what ‘was wrong’. It is starting to feel like carving a diamond, gradually seeing something valuable going to get shapes.

And that ‘knowing to get some value’ is a good anti-dote to my feeling of not having too much time. If I dig deep down in my mind I think this comes down to very badly wanting to have some basic monthly income, so not to have to work for someone else anymore, and to ‘relax’ my mind so I can do more creative processes. The fallacy I see my mind getting into is: favor getting something low-value on the market quickly, instead of getting something valuable onto the market after a period of fruition.

But this ‘allowing time’ thing is still something that needs a lot more attention and thought on my side.

That brings me onto growth.

Personal growth

If you think I am late with asking for feedback just a few weeks before launch: you are totally right. However it was much and much worse. I am seeing a lot of growth on my side on this subject.

With Find the Gnome in 2018, I felt this massive pressure. I didn’t want to look at what others made because it felt like I was sooo bad and a fraud and such. Also I didn’t have that much experience with anything game related, but insisted on exploring it on my own without much outside help, so I was very hard and harsh on myself there. Requesting the impossible.

That resulted in a massive disappointment. In myself.

That behavior didn’t come out of nowhere. On the contrary: I remember feeling like a fraud as a teenager when programming stuff. Or when attending to school. Or when getting into relationships. And this continued when getting into professional life. I always felt this sting like ‘o maybe I am not that good as I think I am’.

It started to change 6 years ago when I entered into consultancy at Luminis. The more consultancy I did at different companies, the more I realized what my capabilities where. What I was good at. And also: what I was bad at. I indeed wasn’t that good in tech stuff, but not the way you might think. Technically I am very strong, but I have a hard time understanding what is actually needed and I have a hard time communicating what I need myself to be fully productive. Being harsh/unclear on myself also had the effect I was harsh on others.

It was 2 to 3 years ago (when I was 31 years old) that I started seeing things change to the better. I finally learnt how to ask for help, take someone’s advice and filter the right things out of it. At the same time I became better at working with others because with me understanding that I am a flawed human being, I now better understand how this works out in everyone else.

Same struggle, but now with more ‘accepting reality’ and ‘humility’.

I don’t know what triggered this change. I think its a combination of things. Find the Gnome did fail at that time. A few other things happened in my personal life. I encountered a good mentor at Luminis, and then discovered some other people around me that could mentor me on other subjects as well. Or maybe it was just me hitting 30 and realizing what is life about, and then me opening up to it.

So yes, I am grateful where I am today. With Find the Gnome. That I learned some valuable lessons from it in the past, was able to get feedback a few weeks before launch, now delay launch again, have some work to do…

If you feel like you want to help me out, join me over on Discord! Follow this link https://discord.gg/PywvqdEJ6b. I always post links to all things I do related to gamedev there. I have paused my monthly mailing because it took waaay to much time and I didn’t like doing it, so looking over at Discord is a good alternative.

Automating bug hunting

Another topic, but slightly related to ‘polish’: bug hunting. Bugs are also polish, but more a technical take on it.

I currently still employ manual testing, with me doing the testing on new stuff an Roan doing the majority of regression testing. I am getting into situations where bugs start to reappear or having a hard time getting them fully fixed.

Combine this with me trying to get a nice CI/CD pipe, and I am starting to see the value of automating my testing. I am still a bit unsure on how to do this, because the scripts I create currently are these modular MonoBehaviours that don’t lend themselves to a unittest that easily. But I am looking into ways in getting my code better test-able.

Expect some updates about this automated testing some time soon.

For now, enjoy your weekend. And see you next time!

Iterative game dev

Its now June 2021. I have written a few articles on iterative game dev in the past years. And I created a few well visited video’s on Youtube on how to automate your game build and deployment. Most of this is from a point of view of a software developer, versed in Agile development, taking a look at game dev.

However with me doing more and more game dev myself and actively professionalizing my craft, I got a few new insights. These are different from my original articles. Here a summary of my changes in vision:

  • All game studio’s do use iterative development already, however depending on their target markets they have different approaches on how and when to iterate.
  • Iterative development, CI/CD, Agile: none of these are silver bullets. There are consequences and costs associated with these approaches, and it is these that withhold the industry as a whole to make a switch.
  • A lot that goes wrong in game dev has to do with changing the requirements/scope too much during the development phase. This is a known issue, its part of the deal when you want to make creative products for a quickly changing market. No amount of iterative development is going to fix this.
  • There is much to win with proper testing strategies. However, this is not game dev related as software in general has trouble adapting ‘making all things testable’.

Lets start with looking at what the current practices are in game dev.


On reddit I have seen a few post of game devs from AAA studio’s (like Ubisoft) telling they utilize sprints, build stuff incremental, and emphasize modular patterns with automated testing. Can’t recall the posts, but they are from 2020-2021.

On my visit of the Amsterdam White Nights conference in 2020 I realized that iterative development is and always has been part of game development. The early phase of a game is about prototyping, and designers make an art of how to come up with good designs. Fawzi Mesmar from EA Dice did the talk ‘Effective prototyping’ on this.

And in mobile there is this frantic focus on iterative development and data driven decisions. I think that even in business software development nobody takes this stuff as serious as the big mobile development studio’s do. ‘Defining the MVP’ was a talk from Tatiana from Etermax on how to properly launch games on the market through iterative development. How to manage these iterations, call it quit, etc.

This all is backed up by video’s you can find on Youtube. I have gathered a few in my articles, for instance in this blog. They are a bit dated (2019) but still very relevant.

This brings me to a recent video that triggered me to write down my current vision on iterative development in gamedev. A major part of next gen business software development is the use of CI/CD to enable quality and speed with iterative development.

Focus on continues integration and/or deployment

Take for instance this video on CI/CD from a guy I respect. He is totally right, but something stings me.

A lot of the stuff this video discusses is known for years already. See for instance the book ‘Agile game development with Scrum’ from Clinton Keith (2010). He accepts the reality of the industry and gives practical advice. To my observation, the trick he presents is a different approach to production in general. And yes CI/CD can then be adopted, but that’s then a natural consequence of the different attitude of higher management / directors.

Even CI/CD can’t change the reality of game development: not knowing what to aim for (floating target to aim for), having to work in secrecy for a long time because thats how the industry works (so again no proper feedback), heavy investment needs (big risks), changing demands from the audience (again floating target), massive teams (high cost of communications) and massive (and I mean MASSIVE) structures of code+scripts+assets (high cost of change).
See my article on failing early access experiments in 2019 for more on this reality.

And to be honest, the ‘integration’ part is something all game studio’s naturally understand the benefits from. You don’t have to tell them that. Most studio’s even attribute a lot of their market value to this whole ‘tooling’ and ‘asset pipeline’ they have. These pipelines are ranging from ‘helping streamlining the process’ to a real continues integration where hundreds of employees can live change code+assets and see their contribution come to life immediately. You need this if you want to efficiency create games.

With this ‘silver bullet’ thing out of the way, the video addresses a good point: continues quality assessment is problematic in games. That is because testing is hard in games.


To manage complexity and changing scope, you need to be able to rely on your game to keep working according to spec. And gauging from what I see continues automated testing of all parts of the game is still not that big of a deal yet.

I myself work with Unity 3D and yes the code is unit test-able, but there is so much more than code that makes the game. Games are layers of mechanics, scripts and code. Unity 3D doesn’t lend itself for writing good tests on all the ‘live’ MonoBehaviour stuff. Yes they introduced some helpers to easier set up test scenes, but that is only a start. For proper test coverage, you need much quicker and better maintainable ways to assert the code is still within specs.

Again, this CI/CD guy delivered an interesting video on the certain types of tests you want to have. I do feel it needs a bit of adjusting to the requirements of game devs: not all target markets favor A/B like testing stuff (for instance you can’t introduce a new unit in an RTS on live servers, you want this to go to specific test servers only) and not all markets like having stuff live all the time (they explicitly want big bang releases for the hype train to work).

But then again, delivering quality games is something very much valued by the industry. There is a lot of emphasis on QA already in games. But naturally the biggest bunch of it takes only place late in production because only at that stage enough of the game is finished to judge it as a whole.

I myself do understand this issue of not being able to write test to ‘value’ the perceived quality that my audience will attribute to my game. However these are just 1 types of tests. A lot of the tests types addressed in the previous video are very technical of nature. And to be honest, a lot of the bugs we all saw in Cyberpunk where also of technical nature only…

So yeah, more automated testing on specs in game dev.

One note here: a lot of business I visit as a software developer don’t employ ‘proper’ testing methods too. Its hard to do right as in: get better quality and higher release speed at the same time. A lot of them struggle with setting up test and instead create things that slow development down over time.

With the apparent issues out of the way and the delicious low hanging fruit in our baskets, I now want to look at iterative development again to see if there are still a few things left to improve. Lets start with where it always starts, the prototypes.

Prototyping phase

When I look at prototyping, I see 2 distinct approaches:

  • Do all prototyping only in-house or on specific test groups. Selection is by group vote and major production members. Even when moving forward with a prototype, still keep things in-house or in these test groups.
    Effects: 1) nobody knows what you are up to, 2) and the judgement quality depends on the in-house selection mechanisms and representation of the test groups, 3) only high quality gets released eventually.
  • Do in-house prototyping but encourage live tests as soon as possible. When moving forward with a prototype, be data driven while constantly measure audience reception. Selection is mostly data driven with targets set by major production members.
    Effects: 1) players see an evolving game over time, 2) and the judgement quality depends on in-house selection combined with live data but limited by the reception of the early adopters, 3) quality varies over time in a product and between products.

To make a quick link back to the CI/CD video: this CI/CD stuff works very nicely with the second approach. And the second approach naturally aligns much better with how the mobile market works. But due to the side effects, especially effect 3, AAA games like Cyberpunk don’t want a continues live release. So these games naturally use the first approach.

It is a nasty thing however that the first approach has a big downside: somewhere during production you have to commit to the end goal you are going for. This is where things start to go wrong. You can’t alter course after you did this without massive costs. But what to do if you later find out that the game isn’t as fun as you wanted it to be but already committed? And are a few years in already?

Its an industry secret that every game does experience this. Always somewhere half way. This just seems to be how it works when you are making a creative work and optimize for ‘fun’.

It gets in a sh*tshow when you do this too often, promise too much, keep your release dates fixed and create toxic work environments. Something has to give.

I do think there is still place for this ‘committing to a prototype, not going live until it is finished’. The benefit of a hype train is commercially too big of a thing to ignore. But it should be done carefully with constant high technical quality during each phase of development, no cutting of the corners early or late production.

That is because this second prototyping style ‘live testing’ is also not a holy grail. Games produced this way vary greatly in quality and consistency. And are often way too optimized for ‘just enough fun’ instead of ‘maximal fun, maybe less revenue’. And another downside is the much shorter shelf-life of these games with half finished games and a lot of promises still left in the open or even killed and taken offline, when the team decides its not worth the effort anymore.

Wrapping things up

Again, the summary:

  • All game studio’s do use iterative development already, however depending on their target markets they have different approaches on how and when to iterate.
  • Iterative development, CI/CD, Agile: none of these are silver bullets. There are consequences and costs associated with these approaches, and it is these that withhold the industry as a whole to make a switch.
  • A lot that goes wrong in game dev has to do with changing the requirements/scope too much during the development phase. This is a known issue, its part of the deal when you want to make creative products for a quickly changing market. No amount of iterative development is going to fix this.
  • There is much to win with proper testing strategies. However, this is not game dev related as software in general has trouble adapting ‘making all things testable’.

If you like what you are seeing here and want to start using some CI/CD of your own, I got you covered.

I created a full walk-through on making a basic CI/CD pipeline for Unity 3D builds with Jenkins and Azure DevOps. (Although without the ‘proper’ testing part hehe, even for me hard to get right lol.)

33 Sneaky gnomes

I have been working on a new gnome type that is really living up to the ‘hiding’ part. So see for yourself how this works out!

And I have been experimenting with an overview map to tie all the levels together. But that is going to need some more time to come to fruition.

Find the Gnome – Update

This is a fresh video with the latest gameplay. The tutorial level is overhauled to feature this new gnome. And on the end you see a sneek peak at the map!

Hiding gnomes

It was an item on my list for a long time: some type of gnome behavior that will make them to automatically hide behind stuff, so you don’t see them. And when you move your camera to look at them, they will move to a new ‘obfuscated’ spot.

This ‘obfuscation’ system is what I worked on past weeks. If you look closely at the video of the introduction, you will see the starting level having this type of gnome now. It still needs some tuning, but it already adds a lot to the ‘find a gnome’ mechanic.

It took a long time to start working on it, because I had this fantastic over-the-top idea of how to implement this. So it naturally took an eternity to actually start working on it. Is was a waaay to complex approach to solve the problem, so even the thought of needing to start on is was paralyzing on itself.

So I took a shortcut: You set a point on the map, and this point will check if its visible (with a single raycast to the camera). If not visible, it will be usable by gnomes to walk to and hide in. This gnome then hooks into the events of this ‘obfuscation’ point and when things change (it becomes visible / is already taken by another gnome while moving to it) the gnome will change its plan accordingly.

It works like a charm. Yes it is not checking for total obfuscation, but hey now you keep to see parts of the gnome and that is actually quite helpful for the gameplay. And I have a 1 sec delay on raycast checks. Mostly for the same reasons: yes that is partly optimization, but it also gives a funny look and adds to the gameplay of quickly reacting while you still see them.


I am working on a map that will join the different levels together. The original Find the Gnome had one, but that one looked terrible. In the past 3 years I did think a lot on how to improve this specific part, and I ended up on keeping it but totally redesign it.

However as with all idea’s: when you actually make them come to life they end up different than imagined. Yes the looks are actually as I imagined them, but it just doesn’t feel right. I think the forest part is waaay to detailed and not as cool as I imagined it to be. (And yes the map is far from finished, but if you imagine everything in the screen being these forest tiles you see where this is going.)

Further more I wanted this map to have some exploration in it too. So my idea was to have these cloud formations that obstruct the map and clear up while you unlock levels. And some even allow you to find them early and thus unlock new levels yourself.

But this mechanic also needs more testing before I can add it. The looks are a bit ‘meh’, and gameplay wise it is unclear why you can unlock some by clicking and some other only by completing levels.

So that’s it for now!

Thanks for the read, and see you next time.

32 Farm level design

Today I give a peek at how I approach level designs.

Also, someone joined in to help me with the level designs! Stay tuned to see who is helping me out…


No game-play fragments this time. Next blog will probably have one again.

Level design

I always start out with drawing stuff on my whiteboards. Level 1 (mansion) is from the ‘original’ Find the Gnome. As is level 4 (village). But I want some levels in between that fit the vibe. And to get more usage out of my models of course. So that is why I came up with a farm level and a log cabin level.

The farm level was the easiest to draw. My parents in law live in the Dutch country side and we visit them often, so I have a lot of memories of scenery during the travel to draw inspiration from.

Next is to get it into the scenes using a few raw shapes. The model of the farm house is a re-use of the one in level 4 (village), so that’s an easy start.

But for this level to really come to life, I do need a few models I don’t have yet. I need a wire fence and something to emphasize the dirt field.

Then I moved in a lot of the more detailed models to get a better feel of the level size and its potential:

I hoped to have this level finished by here. But this sadly far from ready.

  • I have to add a lot (more) of interactive elements like hiding places.
  • I want to model a new fitting fence door for the wire fence.
  • I want cows that walk around as mobile ‘obfuscation’ spots.
  • I want to add gnomes that work with ‘obfuscation’ spots instead of ‘real hiding’.
  • I have to split the level up in sections that unlock in an interesting pattern.
  • And of course the ‘default’ stuff as in: the objectives and the gnome placements.

So yeah, that is me being a perfectionist. I want the levels to be fun to do, to come back to trying out new strategies, or just to enjoy the scenery. And that requires multiple iterations (and always more time than anticipated).


You probably guessed it right: Roan (my son) is helping me out.

He already likes to create custom levels for the games he plays. He is my main tester. And he wants to have more things to test (I basically have to up the pacing lol)

So 1 and 1 is 3 is this instance. Here he is working alongside me:

That was it folks. Thanks for the read and: See you again in 2 weeks!

31 At work

First a shout-out to Jonathan: Stay strong!

Last 2 weeks I have created this fancy pancy Unity build to Steam pipeline. Finally, the whole pipe is now ready! So easy to get new updates to Steam now.

And I did some small updates to Find the Gnome itself, like an improved UI.

Find the Gnome – Update

The video fragment of this blog is about that latest update on Find the Gnome.

While the past 2 weeks didn’t add that much functionality, the last video was from 4 weeks ago. So now I can show a lot of improvements like: improved UI, sounds, and the tutorial puzzle level!

New pipeline

I am so happy with my new release pipe. It now builds a QA version (with debug interface), 1 ‘production’ version for 3 targets (PC, Mac, Linux), and uploads this all to Steam.

Find the Gnome improved build pipe

There are still a few things on my wishlist to add to this pipe. But for now this is sufficient. Its pushing the content to my ‘beta’ channel on Steam and that is what matters the most!

Upcoming Unity to Steam CI/CD pipe video

I am working on a video of this pipe. I know a lot of people get onto my website because of the Unity –> Jenkins or Unity –> Azure DevOps video’s I made. And I like tinkering with this CI/CD stuff, so helping you all out with making a video of it is something I really like to do.

Previously I created big video’s like this in 2 or 3 consecutive days with 8 to 10 hours of work going into it. I am not that good in writing a good script, video editing and voice overs. This always felt like moving a mountain.

This time I want to do it in little pieces at a time. Getting a game out and working on my consultancy job is prio 1 for me, producing a CI/CD video is secondary. With this new approach I hope to make it more for for me and at the same time make it so I can stay producing Find the Gnome content at the same time time.

The result is that the video will now take a few weeks to make, but that is only good because its production quality will be a lot better and more consistent without the time pressure.

30 Change of pace

I am switching from consultancy job because of an opportunity that opened up.

At the same time, I have prepared for this so Find the Gnome is in a good place now to work part time on it.

Blast from the past

This is me, doing a vlog in 2018 on my first Find the Gnome game (on my old channel). Always nice to see old stuff, think about the progress I have made since then and the learnings I have had.

A new contracted job

I have a new contracted job starting this week at Topicus in the Netherlands. I planned for this, to keep the money coming in so I can stay developing my games. I will keep working on Find the Gnome part time.

Because I new this new job was coming, I have emphasized certain tasks on the rework on Find the Gnome. This was what I was doing most of the time in the past 4 weeks.

Find the Gnome is now in a good place where the most difficult parts have been sorted out. Most of the mechanics are sorted out, working technically and balanced in the gameplay. I have practiced my asset pipe so I know can easily put out more content, while at the same time work on my other job.

Back to that job. I am looking forward to it. It is close by (a 30 min drive), so I will be partly working on site. I will be enjoying the live presence of colleague’s again. That on itself is a reason for me to enjoy this new opportunity!

Find the Gnome

So, where is Find the Gnome currently at?

It is currently OK-ish. You can find and catch gnomes, unlock stuff in the level, have required and optional objectives. Sound and music is still very early with being worked on, and same for the HUD/UI.

The gameplay is fun but short. It is in dire need of more levels and more variation. But that was exactly where I wanted the game to be: polished gameplay, ready to add more content.

To give you an idea what I currently have:

  • 2 levels: 1 tutorial level, 1 ‘normal’ level
  • These levels feature:
    • 3 different hiding place models
    • 2 additional interactive models
    • 6 non interactive environment prop models
    • 3 ground tile models (excluding the variations)
    • the ‘normal’ level has 10 gnomes to find, 3 Required and 1 optional objectives
    • 4 different interaction sounds (excluding the variations)
  • 1 type of gnome

In addition, I already have 8 additional environment prop models (excluding the variations). I have 2 additional ground tile models (excluding the variations). I have 1 additional level fully prototyped but not with final models. I am working on 1 additional distinct gnome type behavior.

If I look at competitors, it is important to have object variation. They don’t have that much interaction variation. I do have a lot of variation for my starting scenes objects already, but I personally do like it to be even more, to add replay-ability to earlier scenes. And I definitely want to have more interaction variation, to get more out of each level.

And I have a good functioning CI/CD pipe, but its delivering up to test currently. I am working on adding automatic deployment to Steam. I hoped to fix this also in the past weeks but that task was a bit more difficult than anticipated. When this is ready, I will probably be releasing another video on this subject (CI/CD with Unity and Azure DevOps).

I think Find the Gnome is in a good place currently. Still needs a minimum of 6 weeks of part time work to get it up to quality for a beta release on Steam. But that was expected.

29 Making progress

In the past two weeks I was busy wrapping up my last freelance job. Currently I am enjoying 2 weeks off, and then on to a new job!

While all this is happening, I am still working on Find the Gnome. It is coming a long very nicely, if I may say so. A few interesting things are happening, so that is what I will talk about in this post.

Find the Gnome – Update

The video fragment of this blog is about that latest update on Find the Gnome.

Here you can see the improved camera, animations, level design and gameplay. Still working out the details on the final gameplay, and the UI is fully placeholders only, but its quite a fun game to play already!

Sound design

How a game feels is graphics on one hand, and sounds on the other hand. A good ambience can amplify the experience and really add to it.

On the previous installment of Find the Gnome I did all of this myself. And this wasn’t easy for me to do. For instance a month just before release I did not have the music in yet. That is because I had a hard time understanding what kind of ambiance I wanted to get with my music. And on top of that, finding the music on itself was very hard. Same with the sounds: the gnomes screaming are fun, but there could be so much more that makes a sound that adds to the experience.

So that is why I am working together with Theo from Daydream Sound to get professional sounds and musics on Find the Gnome. I just got his first set of samples so I am very curious of what he has come up with. A game like this, a hidden object game, really needs good sound design. That is a trademark for this genre. So I am probably going to need his services a few times during the development of Find the Gnome.

User interface

The user interface is another part of the game I really underestimated in the previous installment of Find the Gnome.

I didn’t think that I lacked experience creating user interfaces back then. However since then I did encounter a few very good ‘front end’ designers that really knew how to create compelling and clean/clear user interfaces. I am just not that good at this haha.

So with that knowledge I now look at other games to borrow concepts from them instead. For instance, I really liked the way the latest Hitman and Hitman 2 (basically the same game) told the player about possible objectives. You wouldn’t say that on first sight, but this game is a sandbox game with a lot of hidden objectives and possibilities. The way their user interface did give away some kind of hints on what to do while not spoiling the experience of discovering it yourself too much… yeah that is what I was looking for!

But another inspiration was to look at the competitors. They are more simplistic in things to do in the game, but their user interface layout is very similar across the genre. Hidden Folks, Hidden Paws, Out of Sight: all minimalist interfaces with a few components along the edges or, if applicable, an objective list in the bottom middle.

With this knowledge I designed the interface you see in the video at the start of the blog. But this is just the start of this interface: it still needs the touch of a professional. So as with the sound design, I am going to look for a prof to help me on the user interface to draw/design.


So I am looking at my competitors on where I should aim for. What kind of gameplay is expected, what are characteristics (sound, UI, drawing style), how do tutorials in this genre, how much content per level, how many levels in general.

My goal is to get 3 levels fully working and the gameplay flushed out and release this on Steam. From there on I will start adding content incrementally. Releasing early will give me the necessary input needed to make the game even better, and above all keep motivated.

This is is where I am at on my own progress chart. Read the chart like this: “Phase name. At the end of this phase, I have the things mentioned in the bullet points.”

I am trying to get the most out of my free time currently while I don’t have another consultancy job. So expect some more progress in the coming two weeks, but after that its probably going to slow down a bit. So that is why I really want to have at least my alpha ready by then so I can start working on the first Release version.

28 Test flow

Hi folks! Today a more technical blog with a peek into my game production and test flow, with DevOps yml code included!

But first, a gameplay fragment of Gearful. This is somehow connected to ‘Roan’, my new helper!


Level 7 of Gearful, played on itch.io. Play it yourself.

This level is created by Roan in March of 2020. He really liked to fantasize about Gearful while I was working on it. So he made a drawing for me, and I recreated it.

Testing by Roan

Last week Roan joined in on the game development team at GameFeelings. With his 9 years old he has a unique look at games. His job will mainly be to test the latest versions and hold me accountable for delivering on my promises.

He is a passionate player of games. He really likes to play games, and when he is not playing games he likes to draw scenes of his favorite games and do some modifications to the gameplay. And then play these out on paper.

Previous week he held a presentation in front of his class about the different types of games available. At the end his classmates could try out a game he created one level for. That is ‘Gearful’, level 7. That is why this bi-weekly shows off level 7 of Gearful in the introduction.

He already does play my games, out of his own curiosity and interest in games. That was really funny for me to discover. Over the past year he played my games a couple of times already, each time getting back to me and talking about how he enjoyed it. On Gearful a few levels are difficult to complete due to Unity Physics not working properly, but he manages to complete them anyway by exploiting the mechanics. And he really likes to tell me this. He does play (the old version of) Find the Gnome too, but less often. Because this game is a bit less appealing to him due to a few quirks in the gameplay. But he can already point those problems out to me, that’s quite remarkable for a 9 years old I think.

So yeah, I think he is a really valuable addition and will increase the quality of the games I deliver.

Testing setup

For those interested in how I do the test part of the production in my game development and the tooling I use, here a peek. If you are interested in more, look me up on my Discord and ask details there.

For me as a solo dev, I build the workflow around my preferred way of working. The testing workflow I am going to describe here is intended more as a signalling function then as an approvement flow. ‘Proper’ testing is still something I need to do myself before checking in my code. That is because in the flow show here there is no coupling between the builds and the stories/bugfixes that are solved in them.

Having said that, lets move on to some actual workflow. So when I check in my code on Azure DevOps the build starts.

I run Unity 2019.4 LTS and have my code on Azure DevOps. There i have a build agent connected to my local dev machine so the builds run locally. This is an evolution of the setup I did in this blog and on Youtube.

I run full yml now, so this is how that looks:

name: 2.0$(rev:.r)

# no PR triggers
pr: none

  name: Default
  demands: Unity_2019.4

  gameProjectDir: 'Find the Gnome Revisited'
  subscriptionConnector: 'redacted'

- stage: WindowsBuild
  displayName: 'Windows build'
  - job: Prepare
    displayName: 'Build FtG for windows'
    #cleanup for unity build
    - task: DeleteFiles@1
      displayName: 'Cleanup staging dir leftovers from last build'
        SourceFolder: '$(Build.ArtifactStagingDirectory)'
        Contents: '**/*'
    #cleanup for published artifact
    - task: DeleteFiles@1
      displayName: 'Cleanup published artifact target dir'
        SourceFolder: '$(Pipeline.Workspace)\GameBuildPcWin\'
        Contents: '**/*'

    #get the previously secured library (if any) for performance reasons
    - task: DeleteFiles@1
      displayName: 'Delete old libary content'
        SourceFolder: '$(Build.Repository.LocalPath)\$(gameProjectDir)\Library'
        Contents: '**/*'
    - task: CmdLine@2
      displayName: 'Restore Unity library from last build for performance reasons'
        script: 'if EXIST "$(Build.BinariesDirectory)\Library\" move "$(Build.BinariesDirectory)\Library" "$(Build.Repository.LocalPath)\$(gameProjectDir)\Library"'
    # Build -------------------------
    #unity PC build
    - task: UnityBuildTask@3
      displayName: 'Unity build'
        buildTarget: 'Win64'
        unityProjectPath: '$(Build.Repository.LocalPath)\$(gameProjectDir)'
        buildScriptType: 'existing'
        scriptExecuteMethod: 'ImprovedBuild.PerformBuild'
        additionalCmdArgs: '-outputPath "$(Build.ArtifactStagingDirectory)\WindowsBuild" -outputFileName "FindTheGnomeRevisited" -buildVersion "$(Build.BuildNumber)" -versionJsonFileName "Assets\Resources\ProjectVersion.json"'
    #upload normal game build artifact
    - task: PublishBuildArtifacts@1
      displayName: 'Upload clean build'
        PathtoPublish: '$(Build.ArtifactStagingDirectory)\WindowsBuild'
        ArtifactName: 'GameBuildPcWin'
    # Cleanup -------------------------
    #secure the library for performance reasons
    - task: DeleteFiles@1
      displayName: 'Clean the temp store library'
        SourceFolder: '$(Build.BinariesDirectory)\Library'
        Contents: '**/*'
    - task: CmdLine@2
      displayName: 'Move the files over to be saved for the next build'
        script: 'move "$(Build.Repository.LocalPath)\$(gameProjectDir)\Library" "$(Build.BinariesDirectory)\Library"'

    # upload the setup creator so we don't have to download the whole code base next time we want to build the game installer
    # can be uploaded in a separate concurrent job
  - job: UploadSetup
    displayName: 'Upload windows setup creator'
    - task: PublishBuildArtifacts@1
      displayName: 'Upload setup creator'
        pathtoPublish: '"$(Build.Repository.LocalPath)\Installer'
        artifactName: 'SetupCreator'

- stage: CreateQAInstaller
  displayName: 'Create installer for QA'
  - job: BuildInstaller
    displayName: 'Build installer for windows'
    - checkout: none

    - download: current
      artifact: 'GameBuildPcWin'
      displayName: 'Download GameBuildPcWin Artifact'

    - download: current
      artifact: 'SetupCreator'
      displayName: 'Download SetupCreator Artifact'

    #create the installer
    - task: BatchScript@1
      displayName: 'Create installer'
        filename: '$(Pipeline.Workspace)/SetupCreator/createsetup.bat'
        arguments: '"$(Pipeline.Workspace)\GameBuildPcWin\*" "$(Build.ArtifactStagingDirectory)\Installer" "$(Build.BuildNumber)"'
        workingFolder: '$(Pipeline.Workspace)\SetupCreator'

    #upload game installer artifact
    - task: PublishBuildArtifacts@1
      displayName: 'Upload installer'
        PathtoPublish: '$(Build.ArtifactStagingDirectory)\Installer'
        ArtifactName: 'GameInstallerPcWin'

- stage: Upload
  displayName: 'Upload to stores'
  - job: QAInstaller
    displayName: 'Installers for QA (early builds)'
    - checkout: none

    - download: current
      artifact: 'GameInstallerPcWin'
      displayName: 'Download GameInstallerPcWin Artifact'

    - task: AzureFileCopy@4
      displayName: 'Upload PcWin early build installer for QA to blob store https://redacted.exe'
        SourcePath: '$(Pipeline.Workspace)\GameInstallerPcWin\SetupPc.exe'
        azureSubscription: '$(subscriptionConnector)'
        Destination: 'AzureBlob'
        storage: 'redacted'
        ContainerName: 'earlybuild'

It still needs evolving. 1) I want to get it to build for and release to Steam too in the same script. 2) And I want to introduce 2 different game build types: one for early testing with all kinds of bells and whizzles and one for user release without test tools and shortcuts, probably by using different scriptExecuteMethod depending on my expected build output. 3) And the generated installer isn’t signed, so the browser is very picky on it currently and you have to jump a few big warning hoops to get the game installed this way.

Roan as a tester then has the following workflow:
He has a document on his desktop with a few links in them. First he uses the installer link to download & update the game to the latest version. Then he opens a google form with questions on the game, and answers those.

I then use the form excel document to create new tasks in DevOps. To do this efficiently I track the response and the reports I have processed.

One thing noteworthy is the tracking of the version number. To get a proper connection between reports and fixes, I had to somehow get an automatic build number to display in-game. This was not as easy as it sounds, because Unity hasn’t that great of a support for a build in versioning. TLDR: insert it at build time through a custom unity build script into a json file as a native Unity resource asset and read that asset when running the game.

The custom build script for the versioning part:

using System;
using System.IO;
using UnityEditor;
using UnityEngine;

#if UNITY_2018_1_OR_NEWER
using UnityEditor.Build.Reporting;

/// <summary>
/// Improved build script over GenericBuild.
/// -Use build version
/// </summary>
public class ImprovedBuild
    // Build inputs
    private static string outputFileNameArgName = "outputFileName";
    private static string locationPathNameArgName = "outputPath";

    // Version inputs
    private static string buildVersionArgName = "buildVersion";
    private static string versionJsonFileNameArgName = "versionJsonFileName";

    public static void PerformBuild()
            // Preset versions

            // Prepare build
            EditorBuildSettingsScene[] editorConfiguredBuildScenes = EditorBuildSettings.scenes;
            string[] includedScenes = new string[editorConfiguredBuildScenes.Length];

            for (int i = 0; i < editorConfiguredBuildScenes.Length; i++)
                includedScenes[i] = editorConfiguredBuildScenes[i].path;

#if UNITY_2018_1_OR_NEWER
            BuildReport buildReport = default(BuildReport);
                    string buildReport = "ERROR";

            var useLocationPathName = Path.Combine(FindArg(locationPathNameArgName), GetBuildTargetOutputFileNameAndExtension());
            Debug.Log("Using locationPathName: "+ useLocationPathName);  // Backward compatible with earlier unity editor C# versions

            // Build
            buildReport = BuildPipeline.BuildPlayer(new BuildPlayerOptions
                scenes = includedScenes,
                target = EditorUserBuildSettings.activeBuildTarget,
                locationPathName = useLocationPathName,
                targetGroup = EditorUserBuildSettings.selectedBuildTargetGroup,
                options = BuildOptions.None

            // Log build results

#if UNITY_2018_1_OR_NEWER
            switch (buildReport.summary.result)
                case BuildResult.Succeeded:
                case BuildResult.Unknown:
                case BuildResult.Failed:
                case BuildResult.Cancelled:
                    if (buildReport.StartsWith("Error"))
        catch (Exception ex)
            Debug.Log("BUILD FAILED: " + ex.Message);

    private static string GetBuildTargetOutputFileNameAndExtension()
        var outputFileName = FindArg(outputFileNameArgName);
        switch (EditorUserBuildSettings.activeBuildTarget)
            case BuildTarget.Android:
                return (outputFileName + ".apk");
            case BuildTarget.StandaloneWindows64:
            case BuildTarget.StandaloneWindows:
                return (outputFileName + ".exe");
#if UNITY_2018_1_OR_NEWER
            case BuildTarget.StandaloneOSX:
#if !UNITY_2017_3_OR_NEWER
                    case BuildTarget.StandaloneOSXIntel:
                    case BuildTarget.StandaloneOSXIntel64:
                return (outputFileName + ".app");
            case BuildTarget.iOS:
            case BuildTarget.tvOS:
#if !UNITY_2019_2_OR_NEWER
            case BuildTarget.StandaloneLinux:
            case BuildTarget.WebGL:
            case BuildTarget.WSAPlayer:
            case BuildTarget.StandaloneLinux64:
#if !UNITY_2019_2_OR_NEWER
            case BuildTarget.StandaloneLinuxUniversal:
#if !UNITY_2018_3_OR_NEWER
                    case BuildTarget.PSP2:    
            case BuildTarget.PS4:
            case BuildTarget.XboxOne:
#if !UNITY_2017_3_OR_NEWER
                    case BuildTarget.SamsungTV:
#if !UNITY_2018_1_OR_NEWER
                    case BuildTarget.N3DS:
                    case BuildTarget.WiiU:
            case BuildTarget.Switch:
            case BuildTarget.NoTarget:
                return outputFileName;

    private static string FindArg(string argName)
        argName = ("-" + argName).ToLower();  // Backward compatible with earlier unity editor C# versions
        string[] args = Environment.GetCommandLineArgs();
        for (int i = 0; i < args.Length; i++)
            var arg = (args[i] ?? string.Empty);
            if (arg.ToLower() != argName || i == args.Length - 1 || (args[i + 1] ?? string.Empty).StartsWith("-"))

            return args[i + 1];

        return string.Empty;

    /// <summary>
    /// Set all version numbers alike
    /// </summary>
    private static void SetVersions()
        var buildVersion = FindArg(buildVersionArgName);
        PlayerSettings.bundleVersion = buildVersion;
        UpdateVersionAssetFile(FindArg(versionJsonFileNameArgName), buildVersion);

    private static void UpdateVersionAssetFile(string versionJsonFileName, string newVersionNumber)
        if (string.IsNullOrEmpty(versionJsonFileName))
            Debug.LogFormat("Skipping updating version asset file, paramater -{0} is empty", versionJsonFileNameArgName);

            var fileContent = JsonUtility.ToJson(new BuildVersion { Version = newVersionNumber });
            File.WriteAllText(versionJsonFileName, fileContent);
        catch (Exception exc)
            Debug.LogWarning("Could not update version json file due to error: " + exc.Message);

    private class BuildVersion
        public string Version;

This is by the way an improved version of the script the Unity DevOps build task generates itself. One major difference is the original build script works in-line in the DevOps build so they can directly insert parameters into code, while I had to supply the DevOps build parameters into the Unity build startup parameters.

In conclusion: so this is how I do testing in my code. I work on DevOps tasks. When work is finished I test stuff myself, then let the build automatically create an installer for additional testing. Roan, or someone else that I instructed, then installs the updated version and runs a test on all the game that is in there. The test results are send back to me and I create new DevOps tasks if needed.

I like to share more of my ways of working if I improve my dev flow even more. Jump on my Discord if you want some help earlier, or wait for my video’s to come in the coming months.

27 First gameplay

Yes! YES!

I am back in business. My game dev is flowing freely again, from my fingers through the keyboard into the bits that make up the re-envision of Find the Gnome.

Please, enjoy this new writing of mine.

First gameplay on Find the Gnome

Here you see my boy Roan in action (9 years old) experimenting with the new game mechanics. He really likes watching the helicopter taking the gnome away on a successful catch.

So much improvement!

The past 2 weeks I have been inspired by my improved working practices keeping me motivated. The payoff was massive: I was able to get together a working piece of Find the Gnome with quite a few of the new mechanics already in it.

One of my major changes in working is to keep it very very simple. Unity 3D is build to facilitate precisely that, so my workflow has improved a lot. And I don’t make the things nice and tidy if I don’t know if I want to keep it around. Thus it seems like a lot of the animations look like they are ‘missing’ or ‘clunky’, but I don’t see it that way: they are exactly what I want for this stage of development.

This is such an improvement over my old way of working. I always build these massive systems in code without having something to show. And these systems are of course polished and prepared for every outlier that I could think of… but not this time anymore.


Where to take it from here?

My current goal is to get the mechanics down. I already did a short playtest with my kids Roan and Mirthe, and the results look very promising for the tested mechanics. But I have a lot more interaction mechanics envisioned, so there is still a lot to add and fine-tune. Also the user interface and user input needs some serious thought.

I came to discover is that I don’t have to worry about content in my games. I like modelling a lot, so much actually I have myself creating 1 object each day. This will me help to ‘automagically’ add more variation in objects and interactions to the game (and my other upcoming games) over time.

Since we are talking about upcoming stuff anyway, another thing I like to share is what I want to get out of the publication of this game. I want to achieve these: 1) replace the old game but still keep it around for people to play, 2) release late Alpha builds on Steam for my testers for each added level, 3) release the finished and polished game levels incrementally for everyone.

I still don’t know when the first Alpha will be available or when the first finished level can be played by everyone. It is done when it is done, hehe.

26 Gnomes everywhere!

Gnomes everywhere! Like… everywhere! But only a few of them are corrupted… That is how the ‘old’ Find the Gnome works. In the new one you just have to catch all gnomes. But for now, enjoy the little piece of gameplay I recorded for you on the old version!

I have an update on how catching gnomes will be different in the new version. A chopper!

And I have made a few changes. From now on: gnomes everywhere! More on this in ‘upgrading my habits’.

Have a nice read!

Gnomes casually walking around…

Here a piece of gameplay of me enjoying the view in the fourth level. In the soon-to-be revised / overhauled version of Find the Gnome.

#findthegnome a hidden object game with a twist! Find it on Steam.

Drone to catch your gnomes

One of the upcoming changes to Find the Gnome is having a drone pick-up the gnomes, instead of them disappearing when you click them.

Find the Gnome – drone

The idea behind this drone is to have a more natural system of limitations to catch gnomes, so clicking all over the scene isn’t that much of a problem anymore.

The drone will come to the mouse, catch the gnome, and take it off-screen. The drone amount is limited, its speed is just a bit slower than running gnomes. So once you find your gnome, you have to work out how to catch it by scaring it with your mouse or to ensnare it with other object interactions.

This will inspire a much more interactive experience of finding and catching gnomes. I like it already!

Upgrading my habits

Another thing I am working on is to improve my efficiency by doing more in less time, and make sure I work on things that contribute to my long term goals.

I attended to an online training ‘Online and social media marketing’, hosted by Qcredits. This was the second training I attended, and it emphasized on what I already knew. It is all about being clear on what you sell, and then make sure you sell it well and sell it everywhere. That ‘being clear on what you sell’ for me was always a bit vague, but I came to the conclusion I make games so that is what I sell: my games. So from now on, each blog, each email, is at least going to contain something about a game of mine.

Another thing I am working on currently is my procrastination. For this I am following a Dutch online course ‘Kies eieren voor je tijd’ from sochicken. It has 18 sessions of 15 minutes that spans multiple days. To me it already helps a lot in showing me how I procrastinate and what tricks others use to get over it. And it is very activating, it forces me to immediately apply the learning to the coming day. So fingers crossed: hope this helps me out being more productive!