official devlog

Thursday Report: Tripped and Felled

It's been a little quiet here on the blog, but rest assured – I've been making some good progress.

I've done some traveling for the summer, taking some time out, and coming back to The Garden Path with a fresh head.

As we enter the second half of the year, the larger puzzle pieces of the game are slotting in to place, and I can begin transitioning toward clean up and polish. This way I can make sure the game is as solid as it can be before I start really generating some content.


Before my time away, I shared some video of tree felling. This was something I had been dreading to implement, only because I imagined it would need to involve a great deal of collision detections, and even some physics (god forbid). For instance, if a tree is cut down in a densely forested area, there may not be enough room to fall entirely, and it would need to rest up against the tree that blocks its path.

With that said, I've decided I'm cheating for now. Since the game is 2D, everything acts much like a cardboard cut out. Nothing has any depth, and the game decides (based on location) which prop appears in front of which – giving the illusion of depth. It's why the character can walk around a tree, and disappear when behind it.

Since positions are often measured within fractions of pixels, it's actually highly unlikely a felled tree would ever be in exactly the same horizontal row as any other prop, so it would just fall above or below it.

There is, of course, a point at which the illusion of depth would be broken. That said, felling a tree is, by design, uncommon, and keeping things this way saves me a great deal of time to spend elsewhere in development.

Each tree has a health node that tracks how broken down it is. A tree will heal overtime, but a player must be careful not to hack away at a tree too much. Chopping a tree is desirable, as it will provide certain items, but getting carried away will result in the tree being felled.

When a tree is felled, a tween is executed for the tree to slowly fall. I had attempted to animate this by hand node, but I ultimately had much more control creating the animation directly through code. The very slow, creeping start helps to give the tree that real sense of weight, especially as the speed picks up greatly toward the end, and the weight of the tree brings it down.

This speed is important, because it helps acts as a cover as the game swaps between two different props – the tree as it stood, and a new fallen tree prop. The smoke and other particles also help to cover up the swap. The positioning still isn't perfect, but it works well for now.

I used a large collection of free sounds sourced online to create the sound of the tree falling. The initial snap, to the creaking of the trunk, to the thud at the end. The final thud still needs some work, as it sounds a little too clean and tight. But give it a listen if you haven't done so already.

While at the moment the fallen tree is essentially just the existing tree but sideways, I'm hoping to have it be its own distinct prop, that ages and fades into the environment as time passes, that may even provide its own items, otherwise unobtainable.


The fishing mechanic is finally taking shape. I mentioned earlier in the blog that I wasn't quite ready to announce my plans, but with everything now underway, I'm excited to share it.

In The Garden Path, all fish are 'song fish', and they are attracted by a certain pattern of melody that the player may whistle while they fish. There will be four distinct keys that will allow the player to whistle different notes when selected, and different keys will attract different fish.

This essentially works by moving an invisible marker around an invisible grid. Each fish has their own co-ordinates, and whistling different notes will move this invisible marker along the grid in a different direction.

None of this will appear to the player, but they will get a sense if this marker is close as the fish will act more or less interested in the bait.

An exact co-ordinate match will not be necessary, however the fish that are harder to catch will be more picky, requiring a more precise match than others.

Different fish will also be available according to different seasons, and times of day.

Fish, once caught, may be used to sing their song to the garden, and provide a unique effect, then vanishing. Others may simply be more valuable, and have traits that appeal to different characters throughout the Garden.

The challenge at the moment is providing the fish with convincing movements, according to its level of interest with the player's song, which I'm working on at the moment.

I think this is a unique and fitting fishing mechanic that I can't wait to see unfold. It's had great feedback so far, and I can only hope I find that balance between joyful to play, and skillful enough to remain engaging.

After all, if you sleep you'll miss it.


Follow me on...


Thursday Report: Back Where They Belong

While I typically expect my freelancing to slow down around this time of year, it's been feeding into my schedule very steadily. That's great news for staying afloat, but does mean I have less time to work on The Garden Path than I'd planned.

But still, I've made some strides in the last few weeks since my last post, and, all things considered, I'm ahead of where I thought I would be.

Perhaps the most important new element is garden aging. The game can now tell how long it's been between saves and grow each plant accordingly when booting in. I'm keen to have a good number of stages of growth for each plant, especially trees. Many games have just two or three stages – maybe a seedling and then in a few days: a full tree. Trees in The Garden Path will take many real-world weeks to grow, and even more to mature fully. Different aged trees and plants might also provide different harvestables too – young fern may be collected as fiddleheads, for instance.

To build this, I created a new database called 'families'. Any 'prop' (which is my terminology for a physical object in the game world, like a tree) may belong to a family. A 'family' is then just a list of all the different props, in order, that grow into one another, and the age at which they do so. A 'birch tree' family contains a sprout, a seedling, a sapling, a young tree, and a mature tree, to give an example.

Everything is still just placeholders, but even seeing one placeholder plant become another after a few days have past makes the world feel much less static.


The other piece of the game's code I've worked on is loading all props from a save file into their respective locations. It's one thing loading in an 'acre', but every prop needs its ID, it's position and it's age to be placed by the game exactly as they were when they player left.

All props have their corresponding 'spawn point'. This is an extremely basic point on the map that carries just three pieces of data – the aforementioned ID, position and age. That, in theory, is everything the game needs to then load in the corresponding prop. This also means that props can be placed without loading in, helping with load times and performance. Only props close to the player are loaded, and once far away from the player can be safely unloaded.

Ultimately this was just making sure the right data goes in the right place, but it's a huge boon having it implemented. I can now move things around, and when I come back, they're just how I want them.


As mentioned over on Mastodon, I used the money I made from the sales on to invest in some VST instruments for the game's music. Everything I had been using prior had been the free instruments that come baked in with the software. These are usually a live instrument recorded playing a single note, then pitch-shifted to match what's being played on a keyboard. This works to an extent, but tends to result in something quite robotic sounding. That's fine for some games, you might even want that rigidity for, say, a pixel art game. I want The Garden Path to feel more organic and nostalgic, however.

High quality VSTs can be recordings of instruments in situ with a large number of microphones, performing each note and transitions between notes, and in a number of different playing styles. If I push a note harder on my keyboard, for example, I'll actually get a separate recording of that instrument being played harder. If I want the instrument far away, I can fade between a microphone that was close to the instrument, and one further back. It's not quite as good a live recording, but it's pretty damn close.

The difference has been mesmerizing, beyond what I had imagined (which is great because they often have a no-refund policy). Not only do the instruments sound more authentic, but the quality of the recordings mean they open up the piece and give more breathing room to the entire composition. It's hard to describe, but poor recordings can often muddy up different frequencies of the sound, making things blend together and sound mushy.

The only instruments I'm lacking now are the mallets, which still feel a little bit out of place in the mix. I've got my fingers crossed I'll be able to pick up some recordings soon. In the meantime, here's a quick look into what I've been doing with the new instruments. This is not the final mix by any stretch, but hopefully it gives you a taste.




Thursday Report: Saved by the bell

Sometimes I find myself in a rut, unsure what to work on next. What this looks like is me dipping into many pre-existing elements of the game, and making a few tweaks here and there, but never having the guts or the drive to commit to anything significant.

I think that's okay, and I also think it's natural. I do the same with illustration; sometimes I'll know the piece isn't the best it can be, but I'll reluctantly go through, making tiny adjustments to shading or lines, until I realize what's actually missing.

Because, often, the only thing keeping me from making inroads is some piece of knowledge, usually in the form of a decision. Typically I don't know what I don't know, so these little probes takes the form of mining at a rock, until eventually a little chip falls apart, bringing with it an entire chunk, and you can keep on mining and mining the soft earth until it becomes hard again.

So to speak.

So last week I've made probably the biggest (at least, the most sudden) inroad since I started working on this project. I always had in my notes the two behemoths of coding that I would be dreading: map generation, and a save system.

Map generation, as you might remember from my last blog posts, wasn't too breezy, but is – as far as I can tell – functional enough to enjoy the game.

A save system was still hanging over me – I knew it would require somehow writing data to the user's disk, and I didn't even know where to begin in that regard.

Turns out, following just a couple of tutorials, I had the schematics of a fully working save system in just a couple of hours. And I had completely underestimated how important a tool that system is. I only wish I had committed to figuring it out sooner.

By capturing a saved state, I'm able to then go into the data, and make tweaks directly – however large or small – and then load into that new scenario. It feels as though I'm no longer in a sandbox, but actually playing the game live. That's a whole shift in perspective.

This has allowed me to start shaping the 'New Game' experience. This is something that's been mulling in my head for quite some time. My philosophy is to have the most minimal introduction as possible, while still immersing the player into the game's world.

As discussed before, I want no character creator screen, but I don't realistically see a way around having a skin-tone selector before the player starts the game. It's rigid part of a person, and something that should have no 'default'. I've shared the skin-tone selector before, and I think it's an acceptable singular menu that appears before starting the game. You select the skin tone, and then you're in.

If anything, I've grown to appreciate something placing itself between the main menu and the game world. It neatly bridges the gap as a menu itself, but is the very first stepping stone as the first choice the player makes.

A five second cinematic then plays, subtly zooming away from some overgrowth. The player can be seen emerging from the overgrowth, and the game begins. This will be followed by some subtle tutorial guidance hinted by the world itself, but otherwise the player will be left entirely to their own devices.

(Don't worry, it'll look better than this, but you get the idea.)


The other big mechanic that save-files allow me to begin working in is time. 'The Garden Path' is real-time, meaning if you play the game at 4pm in the real world, it will be 4pm in 'The Garden Path'.

This comes with its own problems. It would be wrong to design a game around people who work 9-5, and also wrong to lock certain content at 3am. There will be systems to allow the player to shift sunrise and sunset to a certain degree, but another simple solution is to simply give the players the option to completely shift the game time in relation to their own time – twelve hours either side. Even if they work a night shift, they can still hop in after work and have the sun rising in the game.

Would players just use this to time travel and exploit the game? Not if they can only do it once – one of those 'tutorials' will be a sundial (or similar object), that will allow the player to change the time, but will become only decorative afterwards.

Can't players just adjust their system's time to exploit the game? Yes. That's on them. If you sell a kid an action man and he wants to pull all the limbs off, that's up the kid.

There's a number of appealing components of a real-time game. It helps players respect the world, it prevents burn-out, it gives players something to look forward to each day at a slower pace.

That slower pace can sometimes become stagnancy however. Winter's last long enough in the real world, and sometimes we might want to escape to somewhere where it's spring.

As such, I've decided the game will have it's own calender. Very simply, each week will be its own season. That means (roughly), every month the player will see spring, summer, autumn and winter.

This not only helps with things being stagnant, but also helps speed up the gardening process. In this way, a tree growing in a few weeks makes sense according to the game's logic.


I'm inching closer and closer toward being in a position to start building real content for the game.

There's still so much work to do, but for the first time, I feel like I can start to smell it.



Thursday Report: A Fresh Brew

Apologies for the absence! Virtually all my focus these last weeks have been building the trading system. The process has been laborious, and still needs a lot of work, but is now entirely functional.

Unfortunately with this being my main focus, the opportunity for fun gifs, or even much discussion, is pretty limited. I've spent hours this week essentially swapping hats between myself and a frog, keeping an eye on values as the items are evaluated and traded.

As described in my last blog post, all items have a series of tags, and each character has a preference over different tags. The game crunches the number between what you've selected from the NPC's inventory, and what you then offer from your own. It then finds the multiplier to see just how good a deal the trade is, so the NPC can emote accordingly, and decide to make the trade or not.

A large part of this process was essentially rewriting the existing inventory system. Beforehand, all the information for the inventory was actually held within the inventory node and slots themselves. Each slot had its own values – item id, quantity etc, and so what you saw was the slot representing the data within itself. Any changes would be physically changing that data inside the slot. This worked fine for testing, but was difficult to mass-manage. This difficultly becomes exponential as you begin adding more and more inventories, as more and more NPCs fill their pockets.

The new system uses a singleton to streamline everything. Now a single dictionary value holds all the active inventories in the game, and new dictionaries can be created with new unique ID's very quickly. That ID could be an NPC's name, but it could also be a storage container, for instance. In this way, inventories now represent this singleton, rather than themselves. Having a more secure and absolute piece of data is much more reliable, and much easier to work with.

The conversation system is also more streamlined, allowing for many different paths and avenues a conversation can go down, and it now being much easier for the game to know how the player and the NPC will react given the context. This will make things much easier as I begin introducing more flavour text, or even add new systems in like quests or challenges.


I'm going to be taking a step away now from trading to help refresh and reset my head, although there's still a lot of refinement and features that need including.

I'm developing a new 'global' menu currently. The 'fullscreen dim' concept was well received on social media, but it had a number of issues that I believe this new menu solves.

First is regarding the philosophy of the games UI. One of my original statements for the game is that all UI (while the game is in play) will feel as though it exists within the game world. Dimming the entire screen is essentially the complete opposite of this – it removes the player from the game. I felt so long as this was the only menu to do this, it was okay. The new menu is not perfect in this regard, but it feels more organic, almost as though you're pulling a book up in front of you, which suits the philosophy more to its original word.

Secondly, with this new menu the game world is still in-view. This is important because the game is both persistent and real-time. Dimming the screen obfuscates the world and creates a false sense that the game is being 'paused' or withdrawn. Also, with this new menu, the UI no longer blocks the view of the player character. As this menu will be used to manage items, it's important the player can preview how their character looks. Previously I had planned to do a sort of 'doppelgänger' node that generates based on the appearance of the actual character. I no longer have to do this with the new menu, and simple is usually better.

Lastly, I needed a way for the player to 'inspect' an item from their inventory. The inventory displays an image of the item, and it's name, but that's all. While a player's inventory is open, this menu can also be opened, providing a rich amount of information while still keeping the inventory in clear view.

There's still a lot of work to be done on this menu, and I'm still completely uncertain on how the contents will be laid out, but the concept of having details come in from the left side is working really well.


An increasingly obvious downside to having a game with anthropomorphic vegetables is that including edible apples and oranges would be somewhat unethical with sentient apples and oranges walking among you. This was a problem, particularly because I liked the idea of having the garden provide consumables that give temporary buffs to the player, and possibly even recipes that would further this.

Upon doing some read-ups on different species of vegetations, especially their wider practical uses, I was surprised how so many spices and herbs derive from otherwise totally innocuous plants, sometimes even from the same plant but different parts.

And this got me excited – why not have the game feature these herbs and spices as ingredients to brewing different teas? Many games feature recipes for dishes, but I'm unaware of a game that pays homage to the sheer number of different concoctions of tea. After all, you can basically pour hot water on anything and it'll be tea in one way or another.

It also suits the tone of the game perfectly.

This solves one of my greater conundrums – what systematic purpose does growing a garden give you beyond it's appearance? Now I think I might have it. All game mechanics in The Garden Path should have basic three functions – they must influence the other mechanics of the game, they must produce collectibles, and they must feel good to do.

Once you check those boxes, the mechanisms interlock, and the watch begins ticking away.




Thursday Report: Show Me The Money?

Game economies are notoriously difficult beasts to tame. Fortunately The Garden Path is single player, which makes things more manageable, but minds work in different ways, and when releasing a game to the wider world, suddenly there's exploits beyond what you can control. Unintentional loopholes, or ways to play the game that prove to be more profitable, ultimately ruining the fun.

From the beginning of building The Garden Path, I wanted to tackle the challenge of structuring a game with no global currency. No 'gold', 'rupees' or 'caps'. Instead, all items have an inherent value, but different characters all value different items differently.

I think this gives the game more flavour. Instead of selling items to characters that have seemingly endless pockets of currency, it encourages you to be more alert about what you have, and the characteristics of the personalities attracted to your garden.

A global currency typically lends a way to reward all play-styles. This is somewhat true, although inevitably players discover a specific play-style is often more efficient, forcing them away from the play-style they enjoy most. But a global currency means someone that likes, say, bug catching, can sell their bugs just as someone that enjoys fishing can sell their fish. Doing away with this adds an extra step – players may trade fish for constellation patterns from Jenny the stork. Players that don't enjoy fishing might have to buy fish off Augustus the bear by collecting honey. How much of a burden that is will be hard to say, but I think I would prefer to double down rather than work around it. By reducing everything to a currency, it somewhat homogenizes each part of the game. I'd prefer each play-style to have it's own identity, it's own paths and methods – that exites me more.

And so, every single item in the game will have a number of tags, invisible to the player, from a global list of possible tags. This could be 'edible', or 'shiny', or 'practical'. The tags are binary, the item either has the tag or it doesn't. Each character then has its list of tag preferences, and a numerical value to increase or decrease how much they value that tag – Augustus the bear will value rustic, wooden items over items that are decorative or modern, for example.

The item also has a value multiplier. Although characters have their preferences, they'll still likely concede to selling a bag of fertilizer to you for a cut diamond, even if they've got no use or want for a diamond. Since it's a multiplier, an item that's both valuable and appropriately tagged will appeal to that character exponentially, making it a very appealing trade.

A character will show you what they're willing to trade, you'll select what you want, and then make an offer. The game will then crunch the numbers – if the subjective value of what you're offering is higher than the subjective value of what the character has, they'll accept the trade. Simple!

A hidden 'warmth' value will affect how much you appeal to a character, both inside and away from trading, so this might just tip the scales in your favour.

Sure, sometimes you'll get a raw deal, but that's life, and life usually doesn't operate on any kind of objective value.

Social cues will make it obvious whether or not you're getting away with a good trade or not, so it isn't a complete shot in the dark, and you can always back out. If a character seems reluctant, but gives in, you know you've made a good trade. Maybe if you've totally overshot your mark, a character that warms to you will refuse on principle, or ask if you're certain.

When discussing this, a friend of mine pointed out that an exploit would be exponentially inflating an item's value by repeatedly buying low from one character and selling high to another. The reality is, however, a character's pockets aren't infinite – you can only trade so many times in a day. But more importantly, these characters aren't sales-people. The items they carry they do so because that's their business to do so. The characters are loss averse, as are we all, and are only trading because you were the one to ask. You can't forcibly sell your junk, but there's always someone who will think that junk is treasure.

Hopefully that shines a light. Coding this kind of thing is much less exciting than discussing the theory behind it, and it's a long, arduous process that I'm deep in the middle of.



Thursday Report: Under The Hood

As I'm closing in on finishing the broad stroke of features and systems in The Garden Path, the last couple week's I've been fine tuning and refactoring some older and some more haphazard code, so that I can start introducing more complex features that make the game a game.

'Singletons', in Godot and elsewhere, are functions and variables that can be accessed universally, no matter what scene the game is running. Since The Garden Path operates virtually entirely in one scene (and I've read in the past that Singletons can lead to some messy issues down the line) I thought it best to steer clear of them generally.

Item data, however, was causing a headache. The was no central hub of information, the details of each item were written into the item itself. Everytime an item was moved, dropped, traded and so on, the details of the item would be trusted between the scene that holds the item, and the scene that's about to accept it (think an NPC's inventory to the player's inventory). This, not unlike a game of chinese whispers, could easily lead to certain information getting lost or misinterpreted as it passes through some clumsy code of mine.

I finally bit the bullet and started an item database. So, instead of writing the details of an item in the scene of the item, I could have a spreadsheet that the game can access (as JSON) that has all the information laid out for me.

The trouble I previously had with JSON is that, as far as I could tell, to retrieve information I would need the numerical ID of the data. That is, 'what's the value of Blue Hat?' would become 'what's the value of 234?'. Not very readable or practical in real world work.

For dialogue, I had worked around this by grouping ID's that have certain information. Let's say it's raining, and we want the NPC to acknowledge that to the player – the game would look at every possible entry, then group the one's that contain the type 'rain'. This works okay since A) Data can be divided in chunks between characters, so files don't get too big, and B) We want a pool of options, not a single dialogue choice, to pick from at random.

With items, for the sake of making things comprehensive, there is one data file, and when requesting the details of an item, we're not grouping anything, we're seeking the details of that one item.

I'm surprised the solution didn't come to me sooner. When the game is loaded, we can simply fill a dictionary (a data class that has keys and values, ie. 'Pig : A mammal') with each item's id against it's name. That way, we can look up 'Blue Hat' in the dictionary, the dictionary returns '234', and we can search for item '234' in the database as we could have done.

With this, I created a very simple singleton function I called 'Lookup'. All you do is put in the name of the item and the detail you want, and it'll return it. By doing this the details of the item are now hard-wired to the database, and the only data that scenes need to lumber around is the name of the item – everything else is tucked away, ready to be reliably retrieved when I need it.


With that out the way, I had a opportunity to begin cleaning up certain interfaces and making them work better together.

The inventory now retrieves the item's name and displays it above, hiding itself away when there's no item in the slot.

I'm hoping to have a system soon where the player can inspect an item, displaying a larger icon, a description of the item and it's stats if applicable.

A single 'UI' state has replaced individual states the player enters when opening different screens. The 'overview' UI now operates the same as the inventory and equipment screens. It's also received a new look, where previously it was a large card, now it dims the view behind it.

Furniture can now be picked up as an item by long holding down the use button. The furniture piece deletes itself, spawns and icon which the player then automatically picks up.

Furniture can then by placed down from the inventory by simply hitting the use button.

A new 'queue' system under the hood expands the response system from the dialogue, so now dialogue can prepare to display different UI elements beyond just the player response, like a trade window, errands, mail and so on.

The trading system is what I'm hoping to work on next. I'm very excited about it, and all of these changes to items make it much easier to implement. I'm hoping to do away with having the player reduce their items to a single arbitrary value, like 'gold' or something similar. Instead, they'll have to be wise to each character's preferences and moods, and not all trades will reflect an items absolute value.

Hopefully I'll have something to share next week.



Thursday Report: A Whole New World

I took a break from the Thursday report last week because I was still knee-deep in developing a system that would generate fresh, unique maps for The Garden Path.

This was an area I had been bracing myself for since I began learning to program roughly a year ago now. Alongside AI for the characters, it was an area I had anticipated I may need to outsource for.

I saw a great quote yesterday, “You learn just enough to do, and you try to do more than you learned”. In that spirit, I decided to see how far I could get, and how much I could learn.

I found myself encumbered with a system hundreds of lines long that simply was not working. I would rubber duck debug into oblivion, frustrated when everything in writing seemed to make sense, but wasn't translating when the code was being run.

I ultimately decided it was time to take everything that I had learned from my first attempt, and rewrite it from scratch with a fresh head. By some stroke of luck, it worked seemingly immediately, and all in less than 100 lines of code.

So, how does it work?

The starting point is the 'acre' I mentioned a couple of blog posts ago. An 'acre' is made of 9 tiles, and so I divided the acre into 12 effective 'sides'. Think of it like a jigsaw piece, which usually has 4 'sides', either protruding or concaved. In order to know what pieces can sit next to each other, those sides need to be matched.

Here's the guide I made that helped me along the way:

Certain environmental features need to be preserved to make a cohesive map. For instance, an acre with a river ending on it's right side, will need to be connected to an acre that has a river coming in the from the left side.

For each acre, an entry in a JSON(!) file is made. It includes the ID number of the acre, and what can be found on the edge of each of it's sides. While I'm sure there's a way to automatic this process, that's something I can worry about later. I'm happy inputting the information manually for now.

The game see's all the points where an acre is spawned, and needs rules to know which acre ID it spawns there (rivers next to rivers, etc), with some degree of randomness.

It starts from the top left. This is just because that's how I laid it out, it might be more interesting if I scatter it, but I'll be working with it scanning left to right for now.

The very first acre point has absolutely no rules attached to it – it could be anything. So, the game takes a shot in the dark and picks an acre at random.

The tricky part comes next. Before placing the next acre, it must write rules for what can appear around it. The game looks at the acre it just placed, then compares it against all other acres. To use my earlier example, if there's a river on side 5, it must find all acres with a river coming from side 11. It does this for all acre spawn points adjacent to it, creating a whitelist for each of those points. When the game comes to picking that acre, it must select an ID at random from that whitelist.

Unfortunately, as I quickly found out, certain future tile placements may begin creating contradictory whitelists.

Take this example. Acre point 2 is spawned, and it creates a whitelist for acre point 4 (it's southern neighbour). It says, “the river in my acre is going from left to right. There's clear space at the bottom of my tile, so I'm going to whitelist an acre that is completely clear – one that has no river'. That makes perfect sense, so it adds it to the whitelist.

Since we're scanning from left to right, acre point 3 is next to spawn. It says, “I have a river in my acre coming from the bottom, curving to right. I need an acre next to me that has a river coming from the left”.

The trouble is, acre point 2 has already whitelisted an acre that's completely clear, which would not match the acre that acre point 3 has selected.

The solution is that I had to have each acre point write both a whitelist and a blacklist – both what it can be and what it can not be. Now, when acre point 3 is writing its whitelist, it writes in it's blacklist that it can't have an acre with nothing in it. It sees there's the same acre in both it's blacklist and it's whitelist, so it removes it from the whitelist.

And that's it, so far. I think it's quite a neat little solution.

The river paths in the image are deliberately very rigid for the sake of me seeing how they work, but they needn't be. These generating paths can become very natural – widening, curling, all within the same acre so long as it arrives at the right 'side'.

This is also exciting because it doesn't begin and end with rivers. This will allow interesting height-tiers across the map, it will allow an acre of birch trees fade into an acre of fir trees, or maybe even allow the addition waterfalls.

As with anything random, it's not the 'making-it-be-random' part that's tricky, it's controlling the chaos within set boundaries. It's very possible I run into issues that will require me to set harder parameters. Should I allow cyclical rivers? Is the chance of a map generating too many rivers too high? Are certain crucial acre types suddenly less common? All these factors I may eventually have to account for and control.

For now though, it's a thrill loading up the game and landing in an entirely new map. I can feel a little bit of that urge to explore in my gut.

I'm very keen to see how this all comes into play as I begin creating the final art assets next year.


Thursday Report: Show Me The Options

Just a quick report today.

With expanding the map by some size last week, I quickly ran into an issue of performance. While I could fill out an acre with many thousands of nodes, having the game render that another 36 times across the map on the fly was asking too much.

Fortunately Godot has a 'VisibilityEnabler' node that allows the game to know whether the character is walking into range of a prop (say, a bush or a tree), and when they are walking out of range. This means I can set each item to remove itself from the game, then spawn itself back in when the character moves close enough (hopefully, all off screen). This took a little time to figure out since it was all new to me, but things seem to work pretty smoothly. The trick is having things load in such a way as to prevent stuttering.

It's dawning on me that not only for the sake of performance, but also for the sake of saving and loading the game between play sessions, I'll likely need to package all props and items in their own container nodes that carries nothing more than the item's location, and whether or not the item has spawned or not. It will simplify things in the long run, but I do wish it was something I had considered earlier on into development.


I built a main menu for Godot some months ago now, but never showed it on the blog. The main reason was that I hadn't settled on a name at the time. In fact, when making the menu was the first I had written down 'The Garden Path' as a placeholder name, and I suppose seeing it everytime I booted in made me more and more fond of it.

I'm even more eager to show it now also because I spent some time this week fleshing out the options menu. I figured it was important to begin mapping out what the players would be able to change early on, so I can anticipate how the game might be played and perceived differently on different machines.

I do think there's a balance when it comes it options. While giving more power to the user is rarely a bad thing, sometimes you can overwhelm the user and create the opposite effect – where users will be hesitant to touch the settings at all. I know personally that while I love to get stuck in with a good number of options, having so much power can sometimes be a headache.

Being a 2D game, the possible list of options is pretty limited to begin with. I'll be building and testing the game at 1080p, but a wider range of resolutions will be supported. Currently shadows and foliage are the biggest culprits of performance, and although I'll be tuning things to run on my own modest machine at 60fps, I will need to experiment to see how less powerful computers tackle the game.

Sound will be divided into three buses, 'Music', 'Voice' and 'Effects', although I'm still deciding whether or not I want voices in the game. It certainly won't be full voice acting, but sometimes a line or two can help set the scene.


Godot 3.1 came out yesterday, which is a pretty exciting release that I had been looking forward to since the latter months of last year. While I had initially set aside the morning with plans to import The Garden Path into the new engine, as it turns out very little needed doing. The new engine is a bit more picky when reading and processing code, so some of my clumsy programming raised some flags that it didn't used to in 3.0. It's encouarged me to do a bit of spring cleaning under the hood, which is always a good thing. It only took editing a few lines to get things up and running again as they were before without error.

I had saved myself from using the new engine until its full release in case any bugs rendered The Garden Path dead in its tracks, so it's exciting to dive into all the new features for the first time. For the most part though, it seems like a refinement of what 3.0 brought to the table. 3.1 is, as the developers put it, a much more mature bit of kit, so it feels much more smooth, and more modern.

I'm unsure yet if any of the new features will be a boon to developing The Garden Path.

It's a simple game, so simple features are all it really needs.



Thursday Report: Picking Things Up Where We Left Off

Some more 'juice' this week, and making a start on some more serious scripting that should be keeping me busy for the month of March.

Last week I was expressed that, regarding analogue controls, I also wanted to have both walking and running states for the character depending on how far the analogue stick is pushed. This isn't necessary, but I thought it would a shame if the player couldn't walk at a slower pace through their garden – perhaps for a cinematic moment, or just while they think about what they want to do next.

The trouble I encountered last week was that I had the script running whenever the analogue was pushed further than a certain amount (say, if the analogue stick push is greater than 0.8, execute the running script). The trouble with this is that the script executed itself every 60th of second while the stick was pushed so far – returning the run animation to its very first frame (the animation is being initialized sixty times a second), making it appear as though the character is stuck on one frame, but sliding around the map.

This was a bit of a head scratcher, but the solution was easy once I saw it – check the current animation: if the player is already playing the 'run' animation, don't play the animation again.

Then everything fell into place. It was just a case of tuning the speeds so that the character's feet align roughly with the ground, so it doesn't look like they're walking on ice.

Holding Shift or either of the Triggers on the controller will have the character move at an even faster rate. I'm still undecided whether this should be put on a recharging limit. Speeding around the garden seems counter to the mood for the game, but I also don't want to dictate how anyone should play.

Trouble is, you give players power and they tend to use it, even to the detriment of their enjoyment. I think I'll just keep the speed in a reasonable place for now.


We're at the early stages of inventory management. The player can now drop items and pick them back up. It's not the cleanest piece of code written, but it successfully carries over the item's icon, it's name, and it's quantity – the bare minimum. The inventory will also now search for the first empty slot to fill upon doing so.

The animations are still baking, but picking up an item will have it find the top of the players head before lowering in – representing the item being picked up.

The player will exchange items with characters too, and I'll be soon needing a visual for this. Games famously obscure item transaction between characters, raising the camera just above elbow height as the two character lean in toward each other. It works – player imagination is a powerful tool, and it saves the hassle of mapping every item to each character's model's.

Animal crossing has a cute solution where each character has a 'holding out' pose, as well as a pocketing animation. The item kind of floats as an icon between the two characters, eventually shrinking into the receiving character's pocket. This works because each item is represented by its own icon, and all character share the same animations (and, obviously, we take the world of Animal Crossing with a grain of salt).

I'm considering an option that works similar to picking up items – having the item appear above the characters head, moving over toward the player's head, then lowering back down. It's representative rather than literal, and I'll be cautious with how well it really works, but I think it could be a fun compromise while I focus on more important things.


Lastly, I decide to begin dabbling in the world building script.

This came with a caveat that I thought I had an answer to, but turns out to be a more difficult question than anticipated: how big should the garden be?

This is obviously a question that I can't answer at this stage. The only way I'll really be able to know is by having a playable game, and seeing what 'feels' right.

It should feel expansive, but limited. I want players to feel like there's a thrill to exploring, but that they'll soon have it mapped roughly in their heads. To have curated the entire space should be a tremendous challenge, but most players should feel content that they have shaped a corner of the garden to their liking.

I've settled on not having the world entirely randomly generated, but compiled of different puzzle pieces (nostalgically named 'acres') that will be pre-baked. Each will have certain notable features, floor heights, rivers and so on, that will allow them to be put next to a series of other acres. Some will be more interesting than others, some will be rarer than other.

This way, while players who constantly reroll might experience some deja vu, I have a system that ensures a certain amount of reliability when a new world is generated, but also keeps things fresh.

An 'acre' will be approximately 9 screen sizes. A garden, for now, I've settled on being 36 of these acres.

This seems pretty big, and running from one side of the map to the other does take a fair bit of time, but currently the space is entirely empty.

As we all know, rooms feel so much bigger when all the furniture is removed.


The Garden Path was chosen as the featured image for Godot's 10th beta snapshot this last weekend, which gave the game a good little boost of publicity, especially over on with a spike of new followers.

If you're one of these new followers – hi! Thanks for reading. Hopefully I'll have some more exciting subjects for you soon.



Thursday Report: Aligning The Stars

This week has been mostly bug fixes and finicky programming on item ids, so I'll be going through some little pieces that I've neglected to mention from the last couple of weeks.

The star menu is coming along nicely, transforming from a concept to something that's actually starting to function and be fun to use. The main challenge is navigation. Stars won't be in such a rigid grid as, say, an inventory screen, so the game needs to know which star it should move to when the player pushes one of the four directions – up, down, left, right.

One possible solution was to assign each star up to four other stars that the player can move between. Which star the game should select if the player hits 'up' for example, would be predetermined and selected. This would ensure that things would feel as natural as possible, at least as attuned to my personal expectations. The first problem I immediately noted was that there could be well over 100 stars, so this would require a great deal of arduous work. I wouldn't mind that, except the other, larger issue: flexibility. Unless I were to decide the entire constellation before hand, moving any star as an after-thought would mean not only having to re-input the directions for that star, but also all the stars around it. That could be exponentially time consuming.

So I wrote in something to select stars automatically, based on their relative location. The easy part is selected between two stars on a clean axis – if there's a star to the right, and you push right, you want to select that star. But what if the closest star to the right (scanning left to right) is also way, way up high? Then you'd probably rather select the star further to the right, but on the same horizontal plane. What if there's two stars, equally distanced to the right, and equally horizontally apart, only one is above, the other is below?

Which star would you expect to be selected when moving left to right?

Well, in that case you might not get the one you want, but certain numeric thresholds can help disregard stars that are tangentially too far away.

As a bit of added 'juice' I implemented a simple three-layer background parallax to give the scene a real sense of depth. This was done by simply layering three different PNG star sheet sprites and assigning them different distances. The game finds the distance between the two stars selected, and multiplies that distance by 0.2, 0.5, and so on. The effect is quite satisfying!

I'm also considering looking into giving each individual star it's own depth, to make certain unlockable stars feel more or less distant. But that opens up a whole new can of worms that I'm reluctant to tackle at the moment – I think this works fine for now.


To the likely chagrin of some PC Gamers, I have decided that I will be developing The Garden Path with a gamepad first and foremost. I think this makes sense.

I recall when I first picked up Stardew Valley, which was first released on PC, I wanted nothing more than to kick back with a controller to play the game. I think it was a mistake that Stardew Valley was developed as a Mouse+Keyboard game first. Latter ports to console have a virtual mouse that's clumsy at best, and weren't well received.

That isn't to say their aren't benefits that come with a mouse. Everybody knows inventory menus are easy to navigate with a mouse, which is why I'm not striking out the possibility in the future, but it won't be a priority.

My highly sophisticated control map reference.

Hollow Knight is still immensely popular on PC despite essentially requiring a gamepad. And while you would have to be some kind of masochist to attempt the game on a keyboard – the option is still there for those who aren't fortunate enough to have a gamepad of their own. The key point here is where you center the game's control philosophy, not what can and can't be done. The Garden Path is about comfort, and controllers are a more comfortable way to play for many people.

So I've made a start by restructuring the character's movement as analogue rather than digital. Now you can move in all 360 directions, and adapt your speed based on how far you push the stick. It feels good, and it feels how it's meant to be played. Digital inputs, like WASD, can still be made, but they are translated back into analogue absolutes.

Zooming is now also done with the right analogue stick, allowing much smoother and controlled camera movement. The combination of the two makes everything feel much more slick.

I'm still figuring a way to have the player perform a walking animation when the stick is pushed just slightly, but things aren't quite working there yet.


Godot put out a call for game devs to submit footage of their game for their 2019 showreel which will be releasing soon. This gave me an excuse to clean up a few things in the game before submitting. I finally got round to filling out the player character's 'side' view – ie. giving the player their tools in their hands or on their back. Previously everything disappeared if the player turned.

I think the video does the game justice in it's current state. I wanted the video to appeal to those unaware of the game, so while those who have been following me will have seen Augustus and Tellstone a hundred times, they've routinely been my most popular characters when shared on social media, so it makes sense to feature them.

I decided to feature a music piece I'd recently finished that I'm quite proud of, although I'm fairly certain all sounds are being replaced with a selected track for the whole showcase. I guess you never know.

So fingers crossed we get featured. I got an email back from Juan Linietsky, Godot's lead developer, with some kind words – that meant a great deal. The last showreel has over 100k views, and interest in the engine is only growing, so hopefully that's a good number of fresh eyes that might be interested in learning more.

And of course, I'm looking forward to learning about more games being made in Godot myself!