44 Optimize workflows in Unity

Good news: a new video on my game development process! I know a few of my loyal readers really like the development side of game development, and like to know how I approach development. For them: Enjoy this new video!

And of course, the regular updates on Find the Gnome 2. With the demo release approaching, I am finishing up all systems and mechanics. In this blog I will tell you about 3 systems that need some rework now everything is coming together.

And a short update about Roan his game to finish up this blog post.

Optimize workflows in Unity

The video segment of this blog is this time about: How I use Unity Editor scripts to optimize my workflows.

In it I use Find the Gnome 2 to demonstrate most of the scripting. And on the end there is also a bit of Roan his game to demonstrate how editor tools can really improve the workflow of an artist.


From the video, on to the upcoming release of the demo. With first a bit of background on what the demo will be.

I know that I projected the game to be completed around now, but reality proved to be a stubborn thing. Especially with me wanting more and more quality. On the music, on the story clips, on the amount of content, on the mechanics, on the animations… pretty much on everything.

So that is why I am working on a demo first. With a few levels in it. That’s a goal that is manageable for me.

A few blogs ago I told I didn’t know when the demo would release due to asset delivery issues, but those issues have been solved. Most of that work was fixed and then done leading up to the previous blog.

Past weeks I have worked on a ‘demo’ release pipeline. These scripts and pipeline make it so that I can work on Find the Gnome 2, and automagically always have a demo that derives from the ‘full’ version.

How close is the demo? Its closer (than before), lol. But something happened last week.

3 Systems that need rework

I sat down with Meinder last week. He is my cartoon artist and concept artist, and he basically does the prototyping of the levels with his concept work. However, with time it became clear that almost all of these levels need rework because their layout and items don’t work that well together with the game mechanics.

So that is what we did. We played the game together. And talked about what needs rework to make the game even better and more interesting.

Do I think its a problem that the early designs of the levels didn’t work out? No. Not at all. We didn’t have all the components together like we do now. Its until now that we know for sure we need rework.

The 3 systems are

  • The hidingplaces for the gnomes are unbalanced. Some levels are extremely hard because of this. While other levels are waaaay to easy.
  • We had planned for some puzzle mechanics with machines you needed to activate. We totally forgot to include these. But we need them for the later levels for having ‘enough’ interesting & fun & challenging interactions.
  • The amount of levels is 12. That is 3 levels in each theme, with 4 themes in total. I want to make 6 levels in 4 themes, because creating more levels is relatively not that much work compared to inventing a whole new theme or adding in a new mechanic. You are probably finished too soon with these 12 levels.

Basically I have an amount of content problem and a difficulty curve problem. And I know I have the solution to solve these, so lets solve this in the 4 demo levels first. So that when you guys can play the demo, I know that at least these problem are less of an issue.

This brings me to the planning:

Release plan

I don’t have a release plan. Other than: I will release the full game after releasing the demo. So no point in time currently. The steam page is saying otherwise, but that’s just a date I keep pushing forward.

I do know what I need to do after the demo to get to the first release:

  • Complete all 12 levels worth of content
  • Complete all 9 parallax cinematics
  • Complete all the support systems: menu’s, achievements, control schemes

When this is completed, I will launch the game.

After that, I will do another content release:

  • 12 additional levels
  • 4 additional cinematics
  • accessibility improvements and requested features

And, while working on Find the Gnome 2, I am (of course) working on other projects. That’s something I need to keep going. Especially if some work is tedious, I need a side project to keep me happy.

Roan game

The game from Roan is such a game.

If you watch the video of the blog, you will see at timestamp 36:03 that I introduce Roan his game. It was called ‘Icelands’ when I introduced it a few blogs ago. The current name is a bit different, but we haven’t updated it yet.

But we did work on the game! We have sword, damage and death animations, a lot more dungeons, a lot more enemies, a lot more items. Still a lot of work left, but Roan is going very strong on the design and art. I barely keep up with my supplies of scripts and tools.

Sword with damage, and puddles of blood. In one of the starting dungeons:

A desert dungeon inside a pyramid. With mummies, traps, teleports, puzzle hallways to get lost in, and much more:

A part of the overworld that is a swamp with toxic clouds:

Roan is working on a lot of boss designs with interesting mechanics. All dungeons have their own bosses with their own mechanics. You need to kill these bosses to upgrading your tools so you can progress on to other dungeons.

We are still working on importing the animations from Aseprite into Unity and thinking about interesting ways we can script your actions and the enemies. So that its easy for Roan to create the world, but also for the mechanics to look cool and work properly.

That’s it for today. See you next time!

43 A work day

This week I have something new, something special: a video of me showing what I do if I do gamedev. Its 1 full hour of goodies, so, have fun!

What is further in this blog: a lot of work is done on the introshots, the music and the collectibles.

Peek into a work day

And a little note on the video: on the time of the recording I didn’t know that my camera had focusing issues. They are solved now, so next time better.

A work day

I have done vlogs on my gamedev before (in 2018), I am retrying this format. But with a lot of changes, like a better camera setup and more easy video editing workflow (no post editing, all live). And I am open for suggestions and improvements on the format.

In summary, this is what I am talking about in the video:

  • How do I find work to do.
  • Start working on a new movie sequence.
  • Using an editor script to speed up work.
  • My parallax movie scene setup.
  • Background info on how I approach animations.
  • Prepare assets for import.
  • Create the first scene in the movie sequence.
  • Whats next for this movie sequence.
  • Git commit.
  • Integrate new movie sequence: update map and unlock sequence.
  • Pull requests and build strategy.
  • My branching strategy in my build pipeline.

I am going to do more vlogs about specifics during game development, with my work on Find the Gnome 2 as an example.

The next vlog will be between now and the next blog. Maybe I release it at the same time as my blog (each 4 weeks), or maybe I am creating these vlogs when I am into it. I just don’t know yet.


In the previous video I mentioned, I add a new movie sequence, or ‘introshot’ as I like to call them. The past 4 weeks I did a lot more work on these ‘introshots’.

In the previous blog I mentioned my renewed parallax engine. So with the new engine, working on the introshots was really fun.

I did have to redo some of my old work though. Especially the introduction movie that plays when you start the game had to be fully redone. I also took the opportunity to make it align to the music clip.


This brings me to the music: Tobias is almost finished with his work on Find the Gnome 2.

In the past 4 weeks he has created the final tracks for the City theme levels. And helped with me understanding the music, and making sure the introshots are aligned with the music.

He also helped out with an improved loading screen music transitioning model. Still need to rework some things of it though, but I really like this concept of the music corresponding to what is in view. And he helped out with that a lot.

Level flow

While working on the music transitioning, I came to the realization that the level flow had some bugs. But also, it just didn’t convey the message I wanted to convey as good as it could be.

Before I did rework on this, the levels played with the introshots in between. Until you completed the game. However, if you wanted to exit the game you got back to the map. (And probably did see the map for the first time).

The map is the ‘captain cabin’ and Tobias has put a lot of work in creating these adventures-vibe tracks. On top of that, the ‘captain cabin’ room has a lot of stuff in it that is there for tracking progress and replay-ability.

Tobias his idea was to give the players a break on the end of each theme, return to the captain cabin, and let them continue to the next theme from there on. I really liked this idea because it solves a few things for me, and better presents his music.

So that is what I did change to the flow. You now play a theme, return to the map, see your progress while listening to a matching theme music, and then continue with the story (or do some replay on levels).


That brings me to the last thing I worked on: collectibles.

Each level contains 2 items that the gnomes lost. You can collect these. All these items will be on display in the map / ‘captain cabin’. And for certain items, completing the collection will reward you with an introshot displaying the gnomes in their daily work. So you get more of an insight into the daily life of these gnomes you helped out.

So, that’s it for today. Have a nice day, and see you next time around!

42 War… War never changes

This time not a video to start with, but some important announcements.

If you find it hard to read through the moody stuff fist: keep reading, I end on positive notes.

Ukrainian modeller

Important things first: I work together with 2 modellers. One of them comes from Ukraine.

He is safe right now and in hiding. Contact with him is difficult due to internet lines not being stable. He wasn’t used to use phone connections, and getting that to work is also not easy in a country in war.

Peek into the life of a Ukrainian game dev, confronted with the sudden outbreak of the war in his country

Its obvious he can’t work on my game right now. I completely understand this. I also wasn’t able to pay him on his last works due to things changing so fast. He said he doesn’t need the money, and if I am going to pay him eventually, he is probably going to use it to build up his country again.

With having said that, I have a problem right now. He was actively working on models and animations, and I need his work. So the consequence will be that this part of my game dev is going to slow down. And its probably going to be me filling up this gap.


If it wasn’t clear from earlier blogs, then let me state it clearly: I am a very sensitive person. Years back when the Ukraine revolt started, it already hit me hard. This time, it got even closer. And don’t even start on the pointlessness of this war, and war in general. Or that Putin threats Europe to start WWIII. Or that, with the advances of the real time media, images of the effects of war are at the tips of your finger.

The ‘war… war never changes’ quote comes from the Fallout game series, where WWIII has devastated the world in an all out nuclear war. At one moment I felt this was closer by than ever before.

But back to my game dev. I had a hard time past months getting to work on Find the Gnome 2 due to a few circumstances. This war is another things that makes it hard to get to work on my game. It is all really demoralizing for me at this point.

On the bright side: this is apparently how it works when being a solo dev, having a lot of other priorities at the same time, and having ‘life’ getting in between you and the things you love to do. Had the same mood issues when working on Find the Gnome (1) back in 2018. And its a recurring theme on Reddit, to find posts about solo game devs getting into despair or ADHD game devs getting into issues related to their weakpoints.

My solution to these issues is very simple: just demand less of myself. Postpone deadlines, relax the daily work schedules, look at what is really important.

Parallax engine

But all is not lost. I have been able to work on stuff. Past 4 weeks I have been working on my parallax cartoons. And specifically the way I create these parallax effects.

I used to have to spend 20 to 30 hours on 1 parallax scene. But I improved my tooling and have reduced this to a max of 3 hours, depending on the complexity. On top of that, I can now facilitate much more complex animation paths and camera paths.

Previously I did use the 2D camera view and sprites. Then I animated them with the Unity animator. The parallax effect was all manual, with me trying to gauge how fast each sprite needed to move. And once I liked how the sprite sketches moved, phase 1 was completed for this animation clip. Then in phase 2, when the final images arrive, I had to redo almost all this due to how the animator stores the animation links. This was all very tedious and time consuming.

Find the Gnome 2 – parallax ‘old style’ with the Unity animator

There are animation tools from Adobe that have the ability to simulate parallax effects. I didn’t want to use them, because I want to become proficient in Unity, not in some tool with some strange flow that you are not going to use if you want to create a game with a bit different of a feel (like no parallax).

But yeah, I sensed that I dreaded working on these animations so much. Something had to change.

So I looked up tutorials on how to do parallax animations in these Adobe tools and rebuild them in Unity. I used other Unity parallax tutorials to find out how the math works.

My own solution doesn’t have the same behavior as the ‘official’ parallax effects. However, I have seen a few parallax animations now and they are all a bit different in how they calculate movement, sizes, and effects in general. So I used this creative freedom to create a signature parallax behavior of my own.

Find the Gnome 2 – parallax ‘new style’ with a custom parallax engine

The side effect of this was that I immediately got more proficient in Unity editor integrations. I now know a lot more about custom inspectors.

Improved workflow

With the parallax animations working a lot better, and having seen a lot more about Unity editor integrations, I realized I had a few other area’s I dreaded to start working on. Especially the repetitive aspect of importing level models and making them scripted and animated properly is problematic right now.

So I looked at how I imported these objects into Unity, what I had to manually do each time to get objects to work properly. And then converted these actions into buttons I can push in a custom Unity window.

So now this work is just a matter of selecting something like a tree in the imported model, and then pushing the button ‘update to behave like a tree’, and then the tree is fully animated. I can then use other buttons like ‘add obfuscation spot’ to add a spot to the tree where a gnome can hide.

Find the Gnome 2 – improved Unity tooling to streamline the workflow, in this example applying the tree scripts and animations

Same for adding gnomes. Previously I had to create a script in a folder, give it a proper name so I can find it again, and then to search the object in the scene I want this gnome to hide in. Now it goes like this: select a spot a gnome can hide in, push the button ‘add gnome’, and it automatically creates a correctly named gnome and adds it to the right script on the object that is selected.

I don’t know why I didn’t think of these automations before. When I started GameFeelings I had this idea that I could use my software development knowledge to much more easily create games (than people that aren’t so much into programming). But it is until know that I finally understand what it means that a programmer has a few tricks of its own to speed up game dev.

Demo and planning

To be honest, I can’t give any estimate right now on the release date of the demo and on the release date of the final build.

But with the massive improvements to the level create flow and parallax animation flow I am now confident that a demo is close.

The only real obstacle is the following: I need to add a collectible items to the levels, and update the captain cabin (the level selection / map). My Ukrainian modeller was working on both of these. So I have to find a way of finishing up his work and/or change it into something that is good enough for the demo.

Thats all for today! Thanks for the read, and see you next time.

41 Gnomes making music

Hello and welcome to another blogpost!

Most of the blog is about the gnomes again. This time they got some nice music going on. And some lovely UI updates.

But I do have a special guest for today. Something about Roan, my son, and a game he is working on…


This is my most recent gameplay video. With a lot of minor improvements. And the major improvement of a whole new music composition.

Latest improvements

This brings me to the first item on my lists of things to discuss for today: details on the latest improvements on Find the Gnome.

Most noticeable is the inclusion of a new music composition. And on top of that, there now is a fully dynamic music system that reacts to the tension in the level. The composition is for each level different, with a per level AND a per theme progression. To further support and emphasize the story. For me this was very important, to have the music and story and gameplay have connection with each other. For that reason the map background scene (a captains cabin) is also going to include some of the instruments used in this game, as if the gnomes are playing on their instruments while you are catching these gnomes.

Another major improvement is the updated UI. A lot has changed since blog 40. In blog 40 you could already spot some sketches. But the UI / HUD in a level is now fully flushed out and final, the map UI / HUD is almost final, and the menu’s are also close to completion.

On the note of getting notification about my updates: On January the 9th I released a video showing off some of the new UI already. New updates will always show up on my channel on YouTube first before molding it into a format like this blog. So follow me on YouTube. And get on Discord, because I will post all available content there asap after creation.

Back to the improvements: I also started working on achievements. The support structures are in place currently. To get started, I integrated the ‘level finished’ achievements. The UI is far from completed, but if you look closely at the upper right corner of the video you see an achievement popup on a level completed.

Am I on track

And this brings me to the next item to discuss for today: am I on track with the progress made in the past 4 to 5 weeks since the last blog post?

To be honest: no, I am not on track. I did deliver on some nice features (like music and UI) and I am proud of the overall progress that I did make. However, the plan was to at least have the Stream page up by now, and at the end of this week to have a demo of the game available on this Steam page.

Overall, for me, January was a bit of a downer. After the mediocre results during the holidays, I hoped to get back some lost productivity, but it was the same story all over again during January. I regularly just didn’t feel healthy enough to work on my game besides my main job.

So yeah, mixed feelings about this one. Considering the circumstances I did make good progress on complex area’s (for me at least) such as music and UI. But I didn’t reach my goals set in the roadmap.

Good thing is, the store page is ready. But just not published yet. I still need to create some supporting articles for the launch of the store page. And I want better screenshots… but that requires the game to be more near completion (especially the achievements part) but I do think now further delaying of the store page isn’t going to increase the screenshot qualities by that much.

Icelands, by Roan

From ‘am I on track’ to ‘Icelands, by Roan’. This has more to do with each other than you might expect. But lets start from the beginning.

Roan is creating his own game. Inspired by YouTubers and the game ‘Forager’, he decided to download a 2d sprite pack and craft his own game around it.

A dungeon in Icelands

This tileset is from 0x72 and can be found on https://0x72.itch.io/16×16-dungeon-tileset.

Roan already has started on modding the tiles, creating new monsters, new tools, new weapons, new items, recipes, overworlds, multiple dungeons… he is going strong!

So thats where daddy comes along: I am making it happen from the technical perspective, facilitating his asset pipeline, and adding the code to make the mechanics come to live.

And yeah, I did have to spend a few evenings on getting things to work. I haven’t created a 2D game yet so I had to research a few things first and/or adapt my scripts from my 3D games to fit his needs.

Here are some more screenshots:

Dungeon crawling in Icelands
The overworld of Icelands
Hand crafted assets for Icelands

Thanks, and see you next time!

In the mean time, you can join me on Discord. If there is interest for it, I can see if we can create a space for Roan his game if you all want to track his progress too.

40 FtG content

Past 4 weeks I added a lot of content to Find the Gnome. In this post I will take you through the things I added and the learnings I had.

And of course, a happy new year to you all folks out there! (Or ’in’ there, if we are literal and take in account the COVID measures lol)


GIF of the FtG 2 gnome catch mechanic

Its not actually a ’video’, this is a GIF. A GIF of the improved catch mechanic. And here you see the new gnome model in use.

The bird is called ’Floris’ by the way.

Bird flight

So yeah, I spend a lot of time getting the bird animation right.

Mac7ua, the character modeller and animator, worked on the bird for some time. He created the lovely character ’Floris’ from the sketches provider by Meinder. And then set forth on animating the bird.

The most difficult part was to get the catch working. He did spend a lot of hours on trying to come up with a solution on animating the catch of the gnome. For example: he tried to animate the claws going forward in the descend, grappling the gnome at the shoulders, and then getting back up into the air. It was very hard to get this right. In the end I was like ’well just hand it over to me, it looks OK enough’.

I ended up removing the part of the catch. And focusing more on an interesting looking flight pattern. So your attention is drawn away from the actual catch. I even simplified it to the point its just an ’attach gnome to claw point and turn the gnome 90 degrees in an instant’. Its hard to spot on the GIF. But in-game it is even less apparent because your attention is on the other gnomes and not the drone.

Another thing worth mentioning is that I integrate all assets myself. I came to this conclusion after working together for a short time with Goran. I had even setup am Azure DevOps account for him. But it was waaay to much to handle for him, to fit into my way of working. So from then on I decided it was much more easy for me to integrate stuff and control the coding quality and project progress management. At least for now.

Gnome model

Another model by Mac7ua is the ’crazy gnome’ you have to catch. Meinder provided sketches for them:

FtG 2 character sketches

You can also see the bird ’Floris’ here. And some other, very interesting looking drone models… But that is something for later.

Its hard to spot in the actual level, so here is an animated GIF of the crazy gnome model:

FtG 2 crazy gnome model

Lovely fellows, aren’t they? Its really fun watching them running around, catching them, and returning them home again to join their fellow gnomes.

On the images I show here on this blog of my game: on one hand I want to keep my game secret, so there is something novel to explore if you buy my game. But on the other hand, I want to write blogs about the development process and give my fellow artists a way to show off their work for me in their own portfolio’s.

That’s a trade-off I have to decide on myself. I am more the ’just show what you have got’ type of guy, so thats why a lot of stuff is already known about FtG 2.

About portfolio’s of the other artists: You might want to check out Meinder his website on https://meinder.nl/. He is giving it a total overhaul. While writing this blog it was still under construction, but I know he has some interesting stuff going on. (By the way, Meinder is the cartoonist and concept artist for FtG 2)

Map scene

Back to my work on Find the Gnome 2 (in short, FtG 2). The map scene.

A part of the game that was a long time in construction is the overworld / map scene. It has seen a few iterations, but I still wasn’t sure on how I wanted it to work and look like. I knew I wanted it to portray the journey the gnomes have taken, it has to be integrated well into the game world, and I wanted it to be the hub from where you can replay previous levels and cartoons.

These are ways the map scene has looked like before:

And this is how it looks today (animated GIF):

So this map scene takes place in the inner hull of the hot air balloon, the same one the gnomes use to go onto their journey. The levels are plotted onto the map. And I want this room to include things you collect during your play-through, to add even more immersion.

Still a lot of work is needed, but i really like the direction this is going.

By the way, inspiration for this scene is from the Assassins Creed games. There are a few titles of this game in witch you command a ship and have a captain cabin in them to do stuff and direct people around.

And a shout out to Mac7ua for his work on all the models you see in view here. I gave him a few directions, but he nailed the execution. And even gave me some more very interesting idea’s, but those are for a later moment in dev time. I will get back to work on the map scene, but for this moment in the dev process its good enough.

COVID, holidays and delays

So, with all this work done on the game. Is there something that didn’t go as planned? Yes, a lot of stuff actually.

My wife and daughter got COVID during the holidays. And my son and I weren’t completely healthy either. So we dialed down the amount of festivities and rested a lot. I had hoped to make some progress on FtG 2 between the festivities, but with my wife out of action I had to step in a few times to keep it fun for everyone.

Also the kids are at home because we are in a total lockdown. The goverment had also mandated an additional week off for the kids before the official holidays. So it was already a bit harder and less efficient working from home. Add the health issues on top of this, and I had enough circumstances to not put out as much work as I wanted to. This total lockdown also limited the amount of stress relieve I and my family could have, so that was another reason I just started to work less to be able to keep my mind sane.

And, as a cherry on top of the pudding, I hadn’t thought about my artists taking some days off too. And that for my plan to work, I needed the assets to be completed beforehand. The plan I presented 4 weeks ago in my blog wasn’t counting in that a lot of my work comes from others having to work at it first. So yeah, my asset pipeline has a planning issue currently…

FtG 2 release plan… thats already outdated

So combine the short term pandemic related issues with the short to medium term asset pipeline issues, and I think I have to rework my planning. AGAIN.

But looking at the bright side, this plan made me make more progress in 2 months than I had made in a whole year. So I definitely work more efficient if I have a plan.

The downside is that I am not going to launch the full game in Februari. Maybe the demo will be available by then. But the full game will probably be available in late April.

39 Release date

Finally I have found ’my flow’ and I am now pumping out content like crazy. A large part of that is a feasible goal, my release plan.

Another thing in this blog is the new Find the Gome gameplay video. Its shows a few interesting new things.

So, buckle up and enjoy the ride!


There is a lot of new stuff in here. The 3rd level, the smooth gameplay (everything is coming together), the collectibles concept, the new UI concept and the new map concept (on the end).

My release plan

Its finished when its finished. That should be the foundation under every (game) project. However, I seem to work a lot better under pressure.

I don’t know how this happened to me, but I got myself together. I seems to be able now to pump out stuff at a good quality level and good speed at the same time.

A few things that I did lately

  • I did set myself a target to go for -> The delayed Steam Deck release date.
  • Upgraded my structure to support a good mix of quality and speed -> ’official’ sprints of 3 weeks + 2 predefined epics each sprint + epics that match ’the grand plan’ + my ’old’ system of structuring work during the sprint by having types of tickets/issues to work on with predefined points to check off / think about.
  • Surrounded myself by very good and inspiring artists -> I bring in 50%, they bring in the other 50%.
  • Accept good things cost money -> Paying others to do things I am not good at.
  • Keep control -> I make the decisions and set goals.
  • Keep progressing -> Accept that ’good enough is good enough’, with my own work or work provided by my payed artists.
  • Confidence boost -> On my ’main job’ I got a major acknowledgement for my performance lately.

My main thing I take away from this is that its very important to clarify things. I previously refrained from control but that made things very unclear. With getting things clear I mainly try to keep it human and focus on people, while at the same time the technical side must be clear at all times. This mix comes very natural to me and I really enjoy working with other people now.

And another recurring theme is: offloading work. Mental or delegating. My work structure helps with keeping mental load low. A plan to know where to head to so I don’t have to thing about that anymore. And other people to get to work on stuff I am not good at or don’t have time for. The ‘not good at’ or ‘dont have time for’ is something I am very aware of if I am doing it myself. So delegating that type of work is a double win for me.

So… you might think by now… ‘ok, but… you said you had a plan… what is your release plan?’

Week 6 or 7 in 2022 I expect something to be on Steam:

I also have concluded that I can’t release this game as a replacement for ‘Find the Gnome’. It will be a separate game (and store page). People that did buy ‘Find the Gnome’ in the expectation it will once be replaced by something better can claim a free code for the new version by reaching out to me.

I have a few reasons to release it on a new page. But mainly its because its confusing, both for me (things don’t align in the Store back-end anymore this way) and for existing and new customers (game is totally different from the previous one, only hidden object and gnomes are similarities). And yeah I think its a better homage to the amount of work put in by my artists (and me) to give this game a nice new and cozy place to land.

And the Steam deck support: I aim on getting my game officially certified. A big part of this is having support for a good controller/touch control scheme. It might be too hard to pull this off before the said deadline.

So… that’s it for this week!
Leave a reaction on this blog, on the youtube video, or get over to the GameFeeling discord.

38 Doing ‘things’

Most of the past 4 weeks was working on ‘providing for the family’ on my main job. But I managed to pull off some interesting pieces of code.

And the guys that help me with the models did their part too… but that’s for another time.

This blog is about a few code things and my new GIT branching strategy.


A short video demonstrating the new AI behavior. See this lovely gnome walk around and (try) to hide behind a tree stump or hide in the vase. And notice the sparkles FX for a bit of vibe.

Hidingspot upgrades

As you can see in the video that accompanies this blog post, I have added a mechanic where gnomes can run around.

Technically this was a deceivingly easy system. I started with a normal ‘rotate around point’. That part was easy. But the hard part was to get multiple gnomes to walk, with their walk speed constant independent of the circle size, a minimum distance to each other, entering the circle on a random spot but at the right distance to each other… and all this while the gnome can still be catched while walking.

In my code, this ‘RunInCircles’ script manages the registering/deregistering and around. It works together with a ‘RunInCirclesState’ script that manages the events and keeps track of the state (IsFull). The storage of the gnome data is in a ‘HidingspotSet’ script that both makes it so we can start with a set of gnomes in it or can serialize the state when we want to make a save game (I save only the gnome being on this circle, not things like where it is on the circle, no need for so much detail)

But from a gameplay mechanics point of view: this circle still needs a bit of tuning. It is part of an overflow system so the gnomes always have something to run to, but currently it is using it too much. And it is too long in this circle. And maybe it was more fun if the run around with their hands in the air like ‘whaaa, I dont know what to do’.

I also changed the ‘normal’ hidingspot to function more like the obfuscation spots and the circles scripts. So these hidingspots now too can be ‘full’ and thus keep state and use events.

I use the same patterns on all my interactions the gnomes can move to and hide in. But I try not to add too much coupling between different mechanics so my scripts are often specialized without base classes or libraries for re-use of code.

This makes that my gnome has an AI script that needs to behave differently and call different scripts when going to different places. For that I use a simple state machine that switches out logic depending on where its heading to. To keep things simple and tidy, and not too many ‘if this then that’ that could clutter up code and make things unreadable.

One note on the (non existing) vase animations: in general all animating needs rework. I am saving it for later when there is more to do, going to hire someone to do it in one big sweep.

New gnome behavior

I already hinted at reworking the gnome AI behavior with the hidingspot upgrades.

Previously I had 1 gnome model for each behavior. One did hide in hidingspots, one other did hide behind obstacles. And I was planning for more different gnomes, with each a unique model to make the player recognize them.

And I had 2 types of hidingspots where gnome could hide in. One of it you could open always, but the other one required the right timing on when a certain animation played.

From a code perspective this meant setting up behavior and animating in a generic way. For both the gnome and its corresponding hidingplace types it would use. That worked well.

However, from a gameplay perspective it wasn’t as interesting as I imagined it to be. During playtesting, it became clear to me that the hidingplace mechanics are more interesting than the gnomes themselves: Gnomes popping up everywhere and hiding everywhere is much more interesting (instead of using 1 type of hidingspot).

There is still variation, but its now only the hidingspots that can differ from interaction types.

Added benefit of this consolidation of behavior of gnomes into 1 gnome is that it the AI can be more intelligent. It now tries to find a place to hide in, subscribes it selves to that place. And if on the way something happens to it (got full, locked, player just touched it, or is in plain sight now), it immediately knows this and tries to find a new place.

This makes for emergent gameplay because now if you want to catch a gnome and it tries to enter a hidingspot, you can just put it in plain sight or click it and the gnome has to adjust course. This gives your helicopter more time to move in and catch the gnome.

GIT Branching strategy

That brings me to my latest point: with all these code updates I got annoyed with the amount of builds my pipeline was creating.

I currently have my Azure DevOps (with GIT repo) setup so that the main branch triggers releases. And I push to main branch only. And I manually added each commit to the accompanied issue, to track my changes.

While this is a very lean approach to software development and certainly CI/CD, its a bit too much of it. I just had too many updates cluttering my main branch and triggering releases that weren’t that interesting. And there were just too many commits to properly bound to an issue.

So I added manditory pullrequests. With a separate cheap and fast pullrequest build pipe. And the pullrequest requires an Azure DevOps issue to be assigned to it. And it will automatically squash merge all branch commits into 1 commit, further reducing the clutter.

I use the Azure DevOps issue flow now where you can start a branch from an issue. Makes it all much more convenient.

37 Find the Gnome

A peek into the beautiful low poly level design, a sketch of the game’s intro, and more.

I have been working hard the past four weeks, so I skipped a bi weekly update. But that s because I have enough stuff to work on. A good sign I think!

So enjoy this weeks content.


A both technical and story peek this time: I am demonstrating the use of additive loading of my scenes, and you can see parts of the intro scene (the sketch version).

Low poly level design

Here is a screenshot of work-in-progress on a city themed level:

Find the Gnome city themed level WIP

I am working with a few different artists currently. This design is from Syoma. He really nails the diorama vibe combined with the low poly techniques I want to use.

The game is currently planned to launch with 4 themes and 3 levels per theme, with the city levels being the largest (and last).

The gnomes in the city are more crazy than the earlier gnomes, not only lost but also possessed by the worldly goods they found here. Of course explained with a beautiful intro scene.

Intro scenes

Speaking of intro scenes. In the video of this blog you could see parts of the main introduction we are working on. Its a cartoon combined with some parallax effects.

For now its a sketch only, so we can see if it works and then move on to draw the final images and color them.

There will be 5 cartoon scenes in the story flow, and probably 2 to unlock if you find special objectives.

These cartoons are from a official cartoonist, so the game is already worth playing for getting to see the cartoons! See his other work on meinder.nl.

Additive scene loading

It took me a few attempts to get it working, but I have additive scene loading in my game now.

A bit of an insight into how I solved this. For the technical people that read my blogs. And I know that a lot of you, my readers, are technical minded people. So here you have my take on this!

So what was the problem, the promise, the solution and lessons learned?

The problem

I have created a few games already. And every time after a certain amount of work, I get the need in my game to automate going from scene to scene. Most of the times I create a data object somewhere to record what level is tied to what scene (file), and then use a manager of some kind to load this level on demand. This manager also knows a bit about menu’s and other places so it can direct you there. But it needs to fully unload the current scene to get you there.

Most of the time I also have another problem thats starting to appear: a level load sequence. (And level unloading). Just using the awake, start and the other object lifetimes in Unity is very limiting. Especially if you want to do some save state loading, or dynamic object discovery, you need more steps in the loading process. Creating your own signals and then managing what signal to hook on is quickly getting a mess, especially if you want it to work while in the editor as well as in the official build. And don’t add singletons to it (like ScriptableObjects) because this will make your game explode into a fountain of very hard to track bugs.

And if this isn’t enough, I tend to get into re-usability issues very quickly. I want some objects, like the UI, on all scenes of a specific type. For instance, levels need the level UI. Or I want a Debug UI to load and be always available. Or I want a loading screen to be visible while unloading the old scene and loading the new scene. And like I said, scenes fully unload at the end. So I don’t want these specific UI elements to unload. And yes I know this can be manually solved in Unity. But then you have to account for certain objects being around after the lifetime of a scene and not keeping ties to the (then unloaded) scene and cause problems… so in the end you need to manage this (proper tying and untying) anyway, so why not make that everything can be loaded/unloaded on demand?

The promise

Additive scene loading is the promise. And its often advertised as a best practice.

Additive scene loading comes with a few benefits. And you don’t need to use all of them, but its very easy to use these if you have these additive scenes working:

  • Seamless level transitions (without loading screens)
  • Much more easy to manage asynchronous level loading
  • No irritating UI that gets in the way while working in the editor
  • Less massive scenes and thus the chance for merge conflicts while working on scenes
  • Better decoupling because for this to work you need to implement a proper event subscribe/unsubscribe system

The solution

A scene can very easily be additive loaded by just stating to Unity load this scene additive .

But for this to work seamlessly you have to implement some sort of state machine to know whats happening. Previously you knew where you where by just looking at the scene’s name. But now you need an overarching machine that keeps track of where you are and where you want to go to.

I added a few additional layers on top of it to also address the other issues I faced.

  • A level sequence object that I can ask: ‘what are the available scenes for this game’. I have levels, intro shots, and 1 map. And fill this sequence object with directions on whats available in the editor with custom tools.
  • A level transition object that I can ask: ‘go to the next story scene’. Or ‘oneshot this level and then return to the map’. (It uses the level sequence combined with savestate to determine what unlocked and where the player is at story wise)
  • A state machine that consists of a few parts. (all custom code, not the Unity state machines)
    • The state machine itself. This keeps track of the current state it is in, initiates transitions, and keeps actions atomic. Uses IEnumerator to make it asynchronous (well, that is Unity-style async, not .Net async lol).
    • A state class model. 1 class for a start-game state, 1 class for a level state, 1 class for an intro shot state, 1 class for a map state, 1 class for a game-exit state. Each state has 2 main functions ‘`RunOnEntryLogic(transition info)’ and ‘RunOnExitLogic(transition info)’, both IEnumerator to support chaining actions inside the logic and to wait for stuff to happen. Each model has its own series of events on it so you can fine-tune the needed amount of events per state. These events are called in the logic functions with yields and such to keep the ticks flowing in Unity.
    • A static class with instances of each one of the a fore mentioned classes. So scripts can reference these from anywhere to hook themselves up to the events of their liking.
    • A transition object. Very simplistic, just to get basic info like ‘Start level 1.1’ or ‘Start map’ to the states.
    • A few smartly placed calls to ‘ensure loading screen’ and ‘hide loading screen’ and ‘pause game’ and ‘unpause game’ in the states. To make it possible to prepare stuff without the user seeing artifacts of this preparation.
  • A scene specific for the state machine. There is only 1 script on this scene, and it initiates state transitions. This scene is always around.
  • A startup sequence script. It knows what scenes to additive load. And triggers the state machine.
  • An editor version of the a fore mentioned startup sequence, that primes the scene as if it was started normally (and thus loads all needed additive scenes on play and sets the state machine to the correct state).

On the additive UI scenes: I have a bunch of additive scenes that are always on. Most of them look for certain events and/or state (transitions) to enable/disable parts of itself. (So its a reactive system, much easier to maintain) And most of the objects on these additive scenes have scripts that use OnEnable and OnDisable to hook and unhook events.

For more info, find me on GameFeeling’s Discord on the #game-dev-talk channel. There I can easily share some code and more insights. (And, if there is enough interest, create a full article on it with code and such)

Lessons learned

It works like a charm!

  • The state machine combined with the startup sequence scripts is sooo helpful. I now can be sure events are fired in the right order with the right systems loaded and prepared to the right state. Even with no difference between the editor and the official build.
  • It looks cool. In the editor. With all these scenes loading and unloading on demand. And it all runs without synchronous code that takes ages to complete and prevent certain parts of the code to continue.
  • I have a few ScriptableObjects for singleton behaviors and better decoupling, and normally these are hard to manage the state off. Because these don’t fit in with the normal game object lifetimes. But now these can be hooked up perfectly to state transitions to give them better boundaries, but at the same time not mess up the decoupling.
  • The class based static scene setup is very easy to use and maintain. And to understand. And thus to work with, reason about, and improve upon. Thats worth the downsides of this system for me. (Downsides being that its not using Unity’s preferred patterns and components, and another downside is the service locator antipattern of all these static singletons)
  • The IEnumerator is a bit of a pain to work with. Especially if you pause your game by setting Time.timeScale = 0, you then don’t want to use yield functions that wait for the next realtime tick to happen. You want to use WaitForSecondsRealtime instead.
  • And another thing on the IEnumerator: it needs to be started as a Coroutine on a script that is kept around, even when unloading stuff. So you don’t want to call it as a Coroutine from the scene that is being unloaded, but instead call a script on a scene that will be around that on its turn calls the Coroutine. Thats why I have a dedicated state machine scene now that first to be alive on start, and then manages the state (and scene) transitions from there.
    I have spend hours and hours locating a bug because of this. I wanted to transition away from the starting scene but the code just stopped executing at a certain point in time. Until I found out that the Coroutine is bound to lifetime of the MonoBehaviour, and I did fire it from within the starting scene.

36 Artists

It has been a while since the last post. That is because I have been working on very interesting things. Like hiring artists to help me out on Find the Gnome.

In this blog I will go a bit more into detail on what we are working on.

Fan art

Find the Gnome character Drone fan art

The game isn’t out yet, and one of the characters is already remade in a Lego. This characters is one of the drones you have at your disposal. It looks quite alike, see for yourself:

Find the Gnome character design Drone by Meinder

Concept art

For the concept art I am working together with Meinder. You can find samples of his work on his own website.

I hadn’t used concept art before, but it is a real help for me in refining my idea of the game. An example of the work he delivers is the character design as shown in the intro with the drone. But he also helps out with the look n feel of the levels:

Find the Gnome level design concept

He also helps out on a few other subjects. But that is something for the next blog to talk about.

Modelling and animation

With Meinder working on getting the look n feel right to make it easier to actually create the game I have in my mind, I realized this also makes it much more easy to hire someone to actually do the modelling and animation.

For me the modelling, and especially the animation, is the hardest part of game development. And I am not even good at it…

So I contacted Goran and he started working on the level design. By using the concept art Meinder had prepared. This is one of the early iterations:

Find the Gnome early level design

I really like where this is going. This looks and feels so much like the thing I had in my mind: a game with a vibe that makes you wish you were there.

For me this means I have to do a lot of the preparation work. But that is something I like doing, and are much better at then modelling. And I do all the coding. And the whole business part of the game. So I still have enough work to do each day.


I got a a very interesting insight on planning lately: By having to better prepare work for the artists to work on, I had to go to greater lengths in preparation of work then I normally do. While I was doing this, I realized the work was much more easy to start working on, even if I had to do the work myself.

That s something I can apply to my own work too! Getting to do the actual work is the hardest part for me. And this practice lowers the threshold on mental power needed to start on the work.

And yes, I tried it out. And it worked like a charm. I even tried it on a very complex subject. That ended up being not that complex because I could keep it nice and tidy.

I don’t know if this works for you. But me, by being not overwhelmed in the moment when starting on a story, I got a much better result. Yes I still need to do the thinking work. But I can do that type of work on a separate moment when I am in a good thinking-mood.

35 Rediscovery

I did take a leave for a few weeks to get revitalized… and because my kids have their summer holidays. Here is an update on how this went.

And yes, I did change up stuff, again. This time because I am getting to understand what was missing in my games: an artistic touch.

So get ready to be emerged into the world of ‘Rien Poortvliet’ and ‘Paulus de boskabouter’!


In this video you can see the art direction change, starting with the colors getting more cartoon-ish and the house having more attention to detail.

Color and vibe

There is something off with my games. As a designer I spoke about this summarizes it: “you look at it from a technical standpoint, but you really need to get your feelings into this”.

This is completely in line with the reactions I received at Reddit a while ago, and with my own concerns I had back in my mind.

Take for instance a look at this scene:

It looks so… ‘blend’. Only the green color stands out, but everything else is ‘about the same’. And the placement of things: it feels ‘as if this could be recreated quickly’. And the detail aren’t drawing your eye to the right parts, the road is overly detailed screams for attention.

First of all, I am realizing that one smart decision I made in the beginning of this projects is really holding me back. I wanted ‘to quickly be able to create levels’ so I used 1m by 1m cells and corresponding made all objects fit in those dimensions. That is giving off this ‘technical ambiance’ instead of this cozy vibe. So I am going to recreate the ground of the scene in Blender and use more interesting shapes.

Next I want to take a look at the colors used. I haven’t found the best setup yet, but this is how it looks after my recolor:

At the same time changed up some models to be more interesting, like the flowers. This is how the tutorial levels looks side by side:

I am not satisfied with the results yet.

But I have to be cautious with changing things up too much: I am going to change up a lot of other things too. I am planning on adding additional things to create more ambiance. Sun rays, particles, slight wind breeze (with moving trees). That is on top of the change of how I model the ground.

So I will be going back and forth a few times before I am finally satisfied. First getting everything to 80% and from there on improving individual parts.

But why? Why am I doing this?

Rediscovery of my design inspiration

Another major discovery I made was that my current game’s design was lacking any inspiration. Funny thing is though, I am full of inspiration: I have a document full of nice pictures, old memories of books I read, all kind of gnome related things and nice-scenery things.

But its not in the game. Because I emphasize the technical side of gameplay and design. And that emphasis was not al all planned. On the contrary, I think it it holding my game back massively and this is the root cause of me not being satisfied with the level designs and UI designs.

So it is time to (re) introduce my inspiration:

Its a combination of the cozy animal loving gnomes of ‘Rien Poortvliet’, with the machines found in ‘Paulus de Boskabouter’, low poly modelling like in diorama’s, and the environmental vibe of the hand-drawn paintings of a lake cabin in a warm but slightly misty evening.

As you might understand, I am limited to what I can model. Getting the vibe of ‘Rien Poortvliet’ his work into a low poly scene is a difficult task on its own, let alone for me as a mediocre modeler and designer.

With that knowledge, I am looking at alternatives. Getting other designers to help me out with getting the vibe right. So that each level is a discovery on itself, even without the gnomes to collect. Because that is what this game should all be about.