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:

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:

image.png
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.

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

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

33 Sneaky gnomes

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

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

Find the Gnome – Update

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

Hiding gnomes

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

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

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

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

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

Map

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

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

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

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

So that’s it for now!

Thanks for the read, and see you next time.

32 Farm level design

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

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

Video

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

Level design

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

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

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

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

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

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

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

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

Help

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

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

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

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

31 At work

First a shout-out to Jonathan: Stay strong!

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

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

Find the Gnome – Update

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

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

New pipeline

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

Find the Gnome improved build pipe

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

Upcoming Unity to Steam CI/CD pipe video

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

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

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

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

30 Change of pace

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

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

Blast from the past

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

A new contracted job

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

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

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

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

Find the Gnome

So, where is Find the Gnome currently at?

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

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

To give you an idea what I currently have:

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

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

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

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

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