GameFeelings

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.

Mood

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…

Video

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.

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:

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)

Video

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:

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:

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!

Video

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.

Video

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.

Video

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:

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

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:

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:

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.

Planning

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’!

Video

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.

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!

Video

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

Update: newest addition to article series is State of gaming.

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.

Reality

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.

Testing

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.)