official devlog

Another year, another inktober come and gone. This year I decided to aid the development of The Garden Path by illustrating a new character each day – you can read more about it in the post below. I thought I'd spend a bit of this report looking back at how things went.

Firstly, this was the first time I'd done a digital inktober. The original idea behind inktober was to get people away from computers and back to drawing on paper. Truthfully, I did miss getting the pen and ink out at the end of a day, even if I know the relief of not having to do so for another year is always an immense feeling at the end of it all.

I spend most of my day illustrating digitally, and so after finishing work it was a little bit hard to remain motivated after clocking out. Dinner, which would typically be a time to wind-down, suddenly because just another lunch break, as I'd be hitting the computer once again for another hour or so.

But ultimately once I would get started there wasn't a character I didn't enjoy drawing in the moment. I should stress the brevity, time spent on each of these characters probably averaged out to about an hour. As such, most I see an unfinished or at least in need of review. Any failures I had to suck up and publish anyway, because that's the nature of the event.

Not that there were too many failures across the board. Perhaps the best example of what I could consider a failure is Archer. I have a soft rule that if there are multiple characters of the same vegetable, I should try and choose a different variety or approach to avoid things getting samey. A good example of this would be Olga and Oliver the onions – two characters which came out really well. One is a sliced red onion, the other is a whole brown onion.

Archer was always going to be a little risky because the higher concept was to draw a non-conventional vegetable, ie. the kind of vegetables you don't see on super market shelves. I thought 'what if the character almost had another carrot growing off from them'.

I'm not too sure what went wrong, but it's likely down to an imbalance of simplicity and complexity. The shape of the character is complex, but with complex rendering there was too much detail to fit in a face without the character feeling cluttered. In the end the rendering is flat (and oddly shiny) while the face is doughy and boring. I think I'm onto something with this character though, and will definitely be returning.

Jaime and Harriet are two characters with naturally very tall heads. I recall being very happy with each at the time of publishing, but on reflection they feel a little out of place. I'm reluctant to give all the characters ._. faces, as popular and appealing as I know they are, and on the tall character it seemed especially hard to fit that design in.

As such they're a little bit more human-like with their noses and wide eyes. It may be difficult to read their faces in game, and I think they both need to be made more characterful in general. It may well be that the issue is their heads are far more interesting than their actual faces, and I'll need to decide whether the aim is to out-compete, or allow the upper-details to steal the show.

In general I think a lot of the characters come off perhaps as too 'cute'. Cute characters are often so because they are simple. That's okay, and many of them will remain cute, but I want to make sure they all have enough depth to be three dimensional characters, rather than aspirational plush toys. The world of 'The Garden Path' isn't dark by any stretch, but it isn't designed to be purely good-vibes either. Ideally each character should have something about them that's a little bit imperfect or unusual, something that might not be instantly appealing, but hopefully becomes an important part of how they are identified.


Development on The Garden Path has otherwise been mostly clinical. Crucially, I've been slowly building up a event system that allows for pre-scripted moments to occur for when they are triggered.

In a funny way, it reminds me of my time working in Visionaire Studio, where you build a game primarily using 50-or-so pre-written functions especially geared toward story-based adventure games. 'Move character' for example, 'Begin cutscene', or 'Cue music'. I've been plotting out the important functions I would need, so in theory the game can just reel through all the commands from a spreadsheet, rather than from in-engine code.

It won't be like Harvest Moon where scripted cutscenes are kicking off any-which-way, but certain key points, like starting a new game, or seeing in the new year, will need instructions.

Once that's all in place, the game will, in theory, be functionally playable for the first time. While before the alpha was mainly testing each of the game's mechanics in isolation, we're on track to have a playable experience by the end of the month.

The game now performs much better (better framerate, less stuttering) with some further tweaking to how the game brings in and loads out different props, and the game also now autosaves the game periodically. In addition, it now saves when the game is closed non-forcibly (ie. Alt+F4 or clicking the X in the top right hand corner of the window.

All save data has been streamlined now to be housed in just a few dictionary containers, vastly reducing the work required swapping in and out the individual save data entries back into the game, while also offering flexibility to how much data is necessarily stored. This has made working with save files much easier.

Oh, and the player's footsteps now change noise depending on what surface they're on.

Plenty more to share in the upcoming weeks.


Follow me on Twitter, or maybe even Mastodon.

'Tis the season of Inktober in the online art world, and while I usually enjoy the challenge of taking a step back from digital art, I figured this year I would utilize the time usually spent on the official prompts (of Jake Parker's) to aid the development of the project.

If you've not been following me elsewhere, I've been posting a new vegetable resident each day on social media, and will be doing so until the end of the month – in theory leaving us with 31 new faces.

With a total of 50 residents planned for release, and roughly 10 residents completed prior to the month starting, this will put me in a very good position for release. Do note that all time spent on these characters is in addition to usual development time, so everything else is still being built in tandem. Inktober should always be a challenge, and this approach poses both new perks and new trials.

I've built the style of The Garden Path to allow for quite rough artwork, which allows for quick art generation on a good day, but difficulties expressing certain shapes and shadings with such broad strokes on a bad one. I imagine very few of the villagers I share will be considered 'final', as I need to draw the line under each piece at some point so I don't totally burn out.

I'm generally happy with each resident so far, although with each one I'm learning a little more about expression, colour and shading as it fits into the game as a whole. I'm sure I'll be revisiting each one before the final release.

Stay tuned for many more to come.


Progress otherwise has been polishing and expanding the game's existing systems, particularly the seemingly-never-ending work on the game's item and inventory systems.

As mentioned in my last blog, items with the same ID but different characteristics will form 'stacks'. This is something I wanted to weasel out of, but eventually admitted to it being a necessity. By allowing items to carry their own characteristics, you open up a huge wealth of interesting possibilities within the game's economy, but you need to allow the player the agency to select what item with what characteristic they want.

You can do this by either creating a separate item slot entirely, using up the player's inventory space, or you do it by providing a new menu. While still in development, progress on the latter is coming along nicely, and has been my primary focus this week. In theory, if an item is in a stack, when selecting that item the various versions of that item become available, grouping those with identical characteristics, and those with unique ones.

This will be especially useful for the player to avoid or select higher grade items when trading, or possibly a system where items age the longer they are held in the player's inventory.

It's not entirely glamorous, but it's working. I suspect adding in an option so that the player can skip the middle man and just pick an item regardless of it's characteristics would be a good quality-of-life inclusion.


Another mechanic I couldn't face omitting was the inclusion of planters and pots.

It occured to me that I could use the same system as storage items for the player to move small plants in and out of a planter. Larger planters will have additional slots, so you'll be able to mix and match different plants, or have one bursting with one type of plant.

The trouble came with the practical element. The planter itself a is a 'prop', but so too are all the plants in the game. Originally I had intended for the plants in a planter to be purely aesthetic, but this seemed too shallow – it feels wrong that you can only collect roses from those grown in the ground, but not those grown in a planter, for example.

Plant props contain a large amount of data – how old they are, how far into bloom, how healthy they are, and so on. All props are individually registered in one map file – the prop would have to somehow be contained within the other prop for it to work, as the plant and planter don't exist tangentially to one another, they are intrinsically tied (the plant is in the planter)

Fortunately, since I introduced a way for any prop to save and load any amount of additional data (by essentially appending a dictionary to it), I was able to build onto the code I had so that any changes made to the plant will be superseded and written directly within a single class to the parent prop instead. In essence, props in props.

Currently the code only allows for two levels of props, but there's no reason it couldn't be infinite – I just can't think why I would ever need to.


Follow me on Twitter, or maybe even Mastodon.

A fairly big feature has finally seen its way into The Garden Path – knees!

Mind the jest, but this was something I had been reluctant to include for quite some time, but they've proven pretty invaluable.

While certain animations, like running seen from the front, effectively masked the lack of functional knees, I was beginning to lose hope I could make other animations convincing. I had to face the truth that I would need to separate the top half of the leg from the bottom half.

Running as seen from the side, for instance, previously had the legs always stretched fully outward. Try running without bending you're legs – it's not comfortable and it doesn't look comfortable. The new animation better matches the front and back animations, making for a smoother transition when turning.

The use of the trowel was the other key animation that I had to reluctantly admit required knees. While in the previous art-style the character digging a hole from a standing position kind of worked, the newer, likely more true-to-life style, virtually requires the character to actually kneel in order to reach the ground to convincingly dig a hole.

As it turns out, the inclusion of knees, thanks to layer masking in krita, is actually fairly simple. As all base layers in my art files are single-colour with no details, and details are all masked on top, I can split the base layers of trouser texture into two – above and below the knee – and simply toggle their visibility. The details will then overlap creating a fairly seamless joint.

I've been using a similar method for tree trunks – trees and legs are really quite similar.


The rework of items into Godot Objects, as mentioned in previous reports, has been the focus of the last few weeks, and things are all finally starting to settle into place.

A brief fear set upon me – that I hadn't considered whether or not an Object would be saved onto the text-based save-file format required to save the player's game. If not, this would require the game to break down each object, and build each one back up again, for every save and load.

Fortunately, Godot is sophisticated enough to save everything it needs, and build everything back up itself from the text – saving me a headache!

It's been a fairly arduous process rewriting a lot of old code to work with the Item Objects, work that unfortunately doesn't lend itself to pretty screenshots.

It's something I both didn't know about when starting Godot, and something I wouldn't need to utilize giving the smaller scope of the game, so I don't regret the time spent. It's all a learning experience. Items and UI were always going to be the two biggest time-sinks in development, but it's important to get them right, and important to make them scalable for future content. This change will do both.


Otherwise, I've been working on fleshing out the gardening itself. Players can now dig up certain plants in their garden and transplant them elsewhere.

While in real-life soil can be either acidic and alkaline, I decided such a direct imitation of the real world is both a little lacking in romance, and also much harder to balance and turn into satisfying gameplay.

So, instead, soil is on the fictitious scale of being either Rich or Aromatic. The (loose) idea here is that deeper, earthier herbs and spices prefer rich soil, whereas more floral and delicate botanicals prefer aromatic soil. While we could debate for days which herb ought to fall where, the important thing is that different soils yield different results. Players may experiment with different levels of each, resulting in different coloured flowers, for instance, and will need to figure out which plants prefer what soil.

Mosses can be added to soil to make it more aromatic, whereas dead leaves can be added to make them more rich. Our friend Buttercup, the mining pig, has the side hustle of selling the soil she digs up to gardeners in need of specific soil-types. Very high scales of either rich or aromatic will result in different, but similarly valuable yields.


Lastly, introducing flowers themselves into the game. While I had previously selected which flowers to include by their practical purposes (ie. whether they can be brewed into tea), I've started to expand the selection for the simple sake of aesthetics. A gardening game might feel a little empty without the ability to arrange flowers.

After long internal debate, I've decided flower's growth will be determined by the number of days that plant has seen of a certain season. Some plants will need more days than others, some will bloom all at once, others will be more staggered, some are delayed, and so on.

This is important because players will have a good deal of power when it comes to controlling the seasons. Decisions on what seasons the player casts the garden in will have consequences on what's able to grow.

As I'll discuss in a future report, growing the right things at the right time will prove important.


Follow me on Twitter, or maybe even Mastodon.

As most of the game mechanics are fleshed out now, we're back to the nitty gritty rather than the theory. Here's some of progress I've made over the last couple weeks.

I shared on Twitter and Mastodon a little while back about the small change in the radial menu. Originally a circular menu appeared around the character allowing you to quickly select which tool you wanted to use. This bred from the idea of a menu you could pin different items to, allowing the player to choose from any item. I soon abandoned this idea, as I wanted tools to be something you actually equip to your person – ie. the tools don't all sit in your inventory until you want to use them, they are added to your 'toolbelt' and contribute to your stats, whether in use or not – a bit like a typical RPG.

The system was to improve on how Animal Crossing did tools, wherein you simply go to your inventory to select the tool you wish to hold. Admittedly, I winced a little when I saw in New Horizons they actually introduced a radial menu – seems we had the same solution in mind!

I had to change the design anyway, as I wanted to include an extra tool – the firefly jar. I was eager to come up with an alternate solution so it didn't feel too similar to the system found in New Horizons while I was at it.

The new menu not only has its own identity, but better falls in-line with my UI philosophy – to tie everything to the game world. Now each circular option points to the item on the player's backpack, rather than abstractly surrounding the player.

Originally the game's map would be tied to this menu, but I decided an easier way about it was to tie it to its own hotkey – M or R3. This way it could be done in just one action, rather than a small handful.


Speaking of the game's map – the game has a map! It was a simple inclusion, as it just pings each character's global location while the map is open and translates it to a much smaller space. The rest is simply a case of having the artwork reflect the game's world. As the game's map is a selection of different chunks, this is just a case of going through the motions. Unfortunately the pipe-dream of having the trees on the map reflect trees in the world is something I'll likely not tackle, but it makes sense that the drawings wouldn't change. The real function of the map lies in navigating around the world's rivers, but more importantly tracking the locations of the different characters.

There will be some metric that calculates whether or not the character appears on the map, and whether the character is identified (just a question mark rather than the character's icon). This is something I'll have to figure out when balancing.

The main motive for the map was asking – 'is running around looking for a character fun?', to which the answer is 'to a point'. The trouble is, most characters are moving targets, giving them the potential of being very difficult to find. It's not worth the frustration.


Another 'map' in the game is the Star Map. A few tweaks in the way stars work in the engine has made it much easier for me to begin plotting out where each star is placed in the sky. This is important, because constellations need to both look at least a little bit like what they're meant to represent, and be made up of balanced stars that are appropriately hard to obtain against the reward of the constellation.

This will likely be near-endless trial and error, but I'm glad to have a system now to very quickly see which stars are which, and quickly move them around, without breaking the game.


Most of my time this last week was rebuilding how items work in the game. Before, item slots could theoretically contain any data, and all the data from the global data sheet was copied over to the slots and periodically updated. This is a little sloppy, because there's a lot of opportunities for data to get confused in the transfer.

Instead, I made items their own Object in Godot. This means an item isn't just a hodgepodge of data in a list, but an actual thing the game recognizes. Think of it like a bundle with all the correct information in the right place – instead of transferring lots of loose paperwork, now it's all in a neatly organized folder with a bow on top, so to speak. Everything also now refers back to the global data sheet, instead of copying data across, so there's only ever one point of reference.

I likely wouldn't have gone to the effort, only it became increasingly clear that items weren't modular enough for the systems I had planned on introducing. Previously, the only actual unique data an item would have is it's name, and it's quantity. Now, each item has it's own unique ID, and can hold a plethora of optional information – age, quality, effects, and so on. This will be crucial as I flesh out the tea brewing system, which dynamically creates new teas (instead of reaching into a database of predetermined items), and a grade system, allowing players to grow more valuable versions of the plants they're already familiar with.

While not visible yet, items are also now capable of becoming a stack – it's own self contained inventory within an inventory. This means players can choose a specific item with a quality grade (for instance) within a stack, without it clogging up their inventory space.


Lastly, a quick sneak peak at a new animal traveler, as the cat was somewhat let out the bag in my last post – Chashka, the sika deer. Functionally, Chashka acts as the wildcard tradesperson going by the rule: if any of the other travellers wouldn't sell, Chashka will.

Chashka's art will take a while as I'm keen to fill up her artwork with odds and edds to really reflect her purpose in the game.

She's a fun character to write, and I'm looking forward to having the full animation and artwork fleshed out in the game's world.


Follow me on Twitter, or maybe even Mastodon.

It was great seeing a small ignition of interest in The Garden Path with the release of the teaser trailer a couple of weeks go. I was contacted by a YouTube channel to supply some footage of the game, and so was under pressure to cook up some footage that best represents the game as it is now.

A good few days of crunch involved mostly taking artwork from Krita and getting it into the game as usable assets to demonstrate as much content as possible. Crazy to think how much the game has visually changed even since the showreel back in April – finally seeing all the new artwork in place was a huge morale boost. I think the game is settling into a style that I'm feeling more confident with working in each day, and has everything feeling cohesive. It was great actually having the flora artwork to fill in scenes to create thick forestry, and get a feel for how the game might feel when closer to release.

The 2 minutes was a good amount of time too, offering far more breathing room than the 15 seconds of the Godot showreel (often cut down to 10). I was worried I wouldn't have enough content to fill the 2 minutes, but I soon found myself in surplus, having to utilize a single scene to demonstrate an animated character, the inventory, fishing, weather effects, and so on.

The teaser itself got a healthy amount of attention and resulted in some really positive feedback, hopefully resulting in at least a few more people excited for the game.

I've since been on break, but returned with that boost behind me and a fresh head to get stuck back in. I've been channeling my work time toward less broadstroke design, and more-so the finer details of gameplay that hopefully keep the game fun to play and feel good to play.

The first I've introduced is a new indicator when trading to give the player a ballpark of how well received a trade might be. This means crunching the numbers in realtime, hopefully reducing some of the mystique of the system and reducing some of the downtime. Previously, if the trade was bad, the player would have to sit through some dialogue before trying again. I came to realize this is mostly just needless time-gating.

It also helps gamify the experience of trading. Rather than just shooting in the dark, the player can experiment with adding and removing certain items to get the best trade possible. I want it to actually feel good when the slider moves up, especially when an item of considerably value makes the slider rocket upward.

I think the key here is to make it a fuzzy unit of measurement. By simply telling the player the exact outcome of success before they attempt a trade makes might reduce the game world to the mechanics running beneath it. At the same time I don't want to trick the player into thinking they have a good deal when they don't, resulting in disappointment.

The plan is to have the slider get progressively more green, but unless the player's deal is vastly exceeds what's necessary, the slider will be more of a deep yellow. This is important, because the slider will only evaluate the inherent value against the characters preference, not the player's charm level, or relationship with the character, which are calculated afterward. This means there will be a degree of judgment from the player in knowing how risky a trade they can make.

This system is mainly in place to prevent a player from massively overpaying for some items without realizing, which is especially important as I start looking into considerably widening the value ranges of items as part of a move to include a form of 'end-game' (for those who don't know the jargon, the incentive to keep playing after experiencing all meaningful content in the game).

The current plan is to begin to introduce items and content that are likely too high for the player to afford by normal means. Instead, they will be accessed by the player obtaining rarer items that are rewarded from long term play, and long term planning from the player.

I'm hoping to introduce different events for each season in The Garden Path, but the most important will be 'Cold's Pass' – the final day of the year. At this time, the player will be given an option to wipe clean some of their work in the garden, and in return will have far better soil that will yield higher grade plants.

This brings with it a new important mechanic too. As The Garden Path runs alongside real time, what if someone misses Cold's Pass, for whatever reason, but had the intention of using it for the higher rewards? Should they miss it? It's unreasonable to expect a game to be a person's top priority. Since The Garden Path isn't hard-aligned to real-time already, I've decided to make a game world always run up to Cold's Pass, and then pause should the player not choose to play, or be unable to play.

I think this is a fine balance between running the game purely at realtime, and giving the player more choice when they want to play. Hopefully, for someone who hasn't played the game in sometime, the opportunity of a new year, with the option to start some of their garden again, will spark an excited sense of a fresh start. It should, in theory, emulate that sense of 'seasons' in other games-as-service games, like Path of Exile, where everyone starts from scratch again, and introduces a new sense of purpose to the game.

These features will likely be a long time in the making, as I turn my focus to getting the core gameplay feeling good and feeling meaningful.

Still, it's important to see the woods from the trees, as it'll help guide the smaller details toward something that feels like it function in tandem with the wider picture.


Follow me on Twitter, or maybe even Mastodon.

Keeping a player engaged in a game is like keeping a flame alight. It's one thing to start a fire, and it's another to keep it going, and eventually that flame will burn out.

What exactly turns a game from something you dip a few hours into, be glad you did, and never return, to something the player feels they could play for hundreds hours, is a magic bullet, and one every developer is looking for.

The trouble is that what motivates some players might not motivate others – not everyone can share the same imagination, patience, enthusiasm, and so on – we all bring different amounts of each to everything we engage with.

And I'm feeling confident that The Garden Path provides decent enough medium-to-long term motivations that suit the sort of players that would engage with the game to begin with.

The dilemma I was facing was short-term motivations – what drives the player to perform any individual action. When a player starts a game, what makes them want to start chopping a tree? Perhaps to obtain crafting materials, or maybe to sell resources for an in-game currency?

A friend made a good point – money in games is always a motivator because money tends to be infinite and money is never a bad thing to have. In Animal Crossing, for example, when most players log in to play, they know they can catch a few bugs, fish some fish, and make a bit of money. They don't need to worry about what to spend it on, because they know it'll provide them with utility in the future, and more is always better. I have friends who spend hours figuring out how they can best squeeze the most money out in their games, often without a clue or aspiration what to spend it on.

The trouble, of course, is that The Garden Path has no money. Going out and doing things is all well and good, but you're filling up your inventory with things that might not even have any value to you, depending on which travelers are around. More is not always better, because inventory space is limited and valuable.

In some games, an XP system compliments this even more so, meaning every action you take in the game, you get a sense of earning something. And again, more XP is never bad – you're working toward something, even if you're not sure what it is yet.

The idea I've settled on is more abstract, but I think it suits the world well. It's more rigid than money or experience, but that I think there's a chance that could play to its benefits.

The idea is 'work' flies (name very much pending).

The loops goes as follows:

  1. The player is given a special jar that can catch a certain type of firefly that inhabits the garden. The flies, they are told, feed on the energy the player exudes while in the garden. The player will then need to explore the garden in order to find some fireflies to catch.
  2. Once caught and jarred, the jar sits on the player's belt. Certain actions will charge the jar – chopping trees, pruning flora, planting seeds, catching fish, and so on. After so many actions, the jar will be fully charged, and further actions will not charge the jar.
  3. The jar can then be traded in with any NPC, who all highly value a charged jar of these fireflies. Each jar is either worth one of their services, or one of the items in the their inventory.
  4. The jar now empty, the player will learn that it is in their interest to go out and find more fireflies so that they can charge them.

There is no downside to charging the jar, and it provides a small sense of accomplishment after every action. Unlike money, it has a cap, meaning it needs to be exchanged quickly to obtain it's maximum value – it cannot be horded.

It encourages the player, without forcing them, to perform three important actions – explore their garden, work their garden, and find someone to talk to.

While the system in itself might sound a little bit dull and repetitive, the key here is what the player should experience while charging their jar. By chopping trees, they are not only charging their jar, but will also end up with new resources as a result. When finding an NPC to turn-in the jar to, they may also try their hand at trading these new resources for something else. They may even find themselves accepting an errand from the NPC, or learn about a new star they could unlock, which ought to motivate them further.

I had considered complicating the system, where different fireflies reward different actions – say, red glowing flies only reward the cutting of flora. But I think this system works because it doesn't discriminate, and gives the player the freedom to do what catches their interest. It should quietly guide the existing gameplay, rather than take center stage.

It's a start, and while it might just be enough of a change, it might also fall short.

As always, all we can do is test.


Follow me on Twitter, or maybe even Mastodon.

I think the systems are in place now, at least for the most part. I feel as though the right step forward, after reviewing the previous alpha release – is to b-line the game to playable a state as close to the final product as possible.

'Playable' being the key word here. Development time is ultimately a balance between playability, variety, and quality.

The Garden Path's gameplay loop relies on variety to a degree, so I'll need to generate a good, sizeable amount of content to test the game's playability.

Quality, at least right now, matters the least. So while it may be tempting to pour time into a really good looking chair, what's important is that the chair is in the game as an identifiable object, not the artwork itself

Fortunately, since all the the items in the game are created by a single spreadsheet, if an item is on the spreadsheet, it's in the game. That means that over 200 items are already readable by the game and entirely functional, even if the artwork doesn't yet exist.

The artwork that's crucial are props, NPCs, and (to some degree) player equipment. While it doesn't matter how good ferns (as an example) look at this point, it's crucial that they're there in some form. Likewise, all NPCs play an important role in the game, so while they might sell items with no artwork, their presence and function is still felt by the tester.

This means essentially making quick splashes of colour for a concept, and moving on quickly to something else. As a result I've got lots of pretty crazy looking artboards at the moment! I'm sure the time will come when I clean it all up – but its all form over function.

Unfortunately this dampens my plan of sharing hoards of artwork content on social media to help promote the game, as most of this content is maybe 30% complete. In due course things will begin to take shape, but for now I'm a little reluctant to litter people's feeds with half drawn wood burners.

Which is one factor that lead me to consider live-streaming parts of the game's development – half-completed things are more interesting when they're being worked on.

So I did just that! Yesterday for about 2 hours I did my first ever live stream. It went better than expected, exceeding my personal goal of 2 live viewers (since 1 would just be me monitoring the stream). While I knew it wouldn't be as by-the-minute productive as a typical session working on the game, the goal is hopefully get more people interested in the development, and provide an easier place to answer questions.

I'll definitely be streaming again next week. I had a handful of folks tell me that they would have watched live if they had more of a heads up, so I'll likely be tweeting something out in advance from now on as a reminder.

But, if you're interested in live development, do check out my page on Twitch. Don't feel any pressure to make an account or follow if that's not your scene. I want to make an effort to have Twitter and Mastodon as active platforms during the stream so people can contact me there, since I know some may be reluctant to register.


Lets just take a look a couple gameplay decisions I've made over the last couple weeks.

The player character, in any game really, always has a funny relationship with the player themselves. Some people want to play themselves, some people want to play anyone but themselves, and in some games it not even questioned that the physicality of the player-character is given to you rigid.

We all love customizing our Legend of Zelda Link, for instance — deciding which armour we like the look of best with what colour dye and so on. We never question why we can't make our Link a woman, or give our Link a beard, perhaps by way of convention, or perhaps because he's a fully formed character with a name and backstory (although, plenty of games do exist where the latter is true and you can still customize the character to your heart's content).

In some games, however, if a certain customization option isn't available when so many others are, it's only natural to feel a little robbed.

I've wondered if I could do a successful balance in The Garden Path, one that's somewhat centred in the 'respect the world' philosophy I've tried to bring to root everything back to. In theory, it should reduce character-creation fatigue and keep the excitement of customization into the gameplay loop, all while still feeling as though the character is (at least in someway) an extension of the player's person. I realize I might just end up displeasing everyone.

I've mentioned before that skin colour is probably the one option I feel uncomfortable taking the option away for. I recall Animal Crossing back-in-the-day had a kind of 'tanning' system where the character would gradually get darker-skinned the more they stand in the sunny weather. That's a can of worms I don't want to open, and lends almost nothing to the player themselves.

Having struggled with an idea for hairstyles, however, it occurred to me I could utilise a similar principle – hair growing over time. The player can have it cut back should they want to, but can't cut their hair 'long' like in so many games.

I like this, because it goes hand in hand with the theme of passing-time that's core to the gameplay, but also with the absence of binary gender options. Long hair is long hair, short hair is short hair – should the player wish to couple that with a more masculine or feminine look, they can do so. I've made an effort to have all the different tiers of hair look appropriate either way.


Finally, a few thoughts on tea. As anyone knows tea is going to be a core part of The Garden Path's gameplay and identity, so it's important to me to get it right.

It always irked me that in a game that I want to feel is 'anti-crafting' that tea brewing ultimately a form of crafting.

Instead, I'm in the process of building a system that will feel more akin to Breath of the Wild's cooking than a traditional crafting system. That is, the player should never be punished for what they choose to combine. With the removal of hard-recipes, the player might not be brewing things most efficiently, but it will always be worthwhile.

As such, teas will only be different teas by why of identification, functionally all teas will follow the same rules. Certain ingredients will increase stats, some will multiply particular stats, some ingredients will combo with others. For instance, adding mint to any tea will always increase a character's charm, and sweetening a tea with honeycomb or syrups will multiply any charm benefit already there.

The game's job is to calculate what that tea will be called. It would be boring if everything was just named exactly what's in the tea. So, if certain criteria are met, it will receive its appropriate name – adding ginger and cardamom and other sweet spices will likely result in a Masala Chai, for example.

And this, to my delight, has brought everything full circle. It never felt right requiring tea leaves for a tea. After-all, pouring hot water over a hibiscus isn't a 'true tea', but it is still widely viewed as a tea. Tea itself is a plant that requires a very particular climate and geography, and a long drying and oxidisation process to become what we know as tea.

Tea would begin to consume the game – players would feel compelled to have huge tea farming operations. 'Black' teas, and 'white' teas, and 'green' teas are all the same plant of course, so there would need to be a system in place to oxidize the leaves at different stages in order to give the player choice.

I don't want that. I want a garden that feels abundant with a huge variety of different herbs and spices, each with a similar sense of importance-of-function.

So — tea will not a growable plant (its visually pretty boring, so no great loss), instead dried tea leaves will be a valuable traded resource. A resource that, when brewed with other ingredients, becomes a 'true tea', greatly multiplying the benefits of that tea.

Who is the sole trader of our valuable resource? Our good friend Tabbal the Toad, of course.

And so, finally, his impatience becomes an obstacle worth overcoming.


Follow me on Twitter, or maybe even Mastodon.

Development progress on The Garden Path has been steady since our last report. As I close in on finalizing the key highlighted points from testing so far, I've found some time to begin rolling in some new features and content that's been in the oven.

The two most important points have been interaction and performance. As we discussed last week, I've rebuilt the world loading system to allow assets to smoothly load in and load out as the player moves through the map, rather than the hard loading from before that was causing major stuttering.

The game actually now becomes smoother the longer it is played, as assets that have already been loaded into the game's memory can simply be re-used.

This is fine for now, but could be a point of failure as more and more assets get introduced to the game. This is not only because it would take longer for the player to process all the different assets, but also because there may come a point where too many assets are in memory than what's reasonable.

The solution for the former would be simple – elongate the initial loading screen, loading in all the assets before the player begins playing the game. It's a trade-off, some players would prefer to jump into the game as quickly as possible, and suffer a small bit of stutter as they start off. Others might be glad to be a little more patient, and have the heavy-loading out of sight and out of mind. The answer is probably somewhere in the middle. I could ensure the most important and more frequent assets are always preloaded, whereas the more unusual assets are left to load in as they are needed.

The latter? Who knows. I'll just have to keep an eye on memory and cross that bridge should I ever come to it.


The interaction system is based on code I wrote a couple years back, and it became clear pretty quickly that it would need to be re-thunk.

For instance, if the player was stood by some flowers with a pair of secateurs, but a tree is technically closer to the player, the game would assume the player wants to interact with the tree, and return no action. This lead to a lot of dead inputs, especially in dense areas with lots of overlap and conflicts between all the different props.

The previous system actually pinged everything that was on the map at the time, reporting which one is closest, which, while not completely impractical, is still overkill. Now the game only pings the props that the player is stood in the area of – if the player happens to be in range of some flowers and a tree, it will ping those. It also pings those props directly, where previously it functioned by emitting a signal to any and all props in the hope one would answer.

The new system also introduces a priority system, where the game can make a guess from what the player has equipped, what they might want to be doing. So, even if a tree is closer, if a player is facing some flowers with secateurs, they likely want to cut the flowers, instead of do nothing to a tree.


I spent the last week or so restructuring the map saving system to be more comprehensive. The map data now saves separately to the player data, which makes things more manageable. Map data can get quite large and complicated, so it only makes sense to have it controlled in its own little pocket, away from simple things like 'what hat is the player wearing'. It also means that tinkerers, should they want to, can swap gardens with one another and load in their own player character to that map.

The goal was to have a map that updates itself on-the-fly as the map changes, instead of recording all the changes all at once.

This is for two reasons – the first is so that we get as close to a permanent world as possible. Meaning, if the player makes a mistake, or makes a weighty decision, or gets an unlucky outcome, that's all part of the game, and it shouldn't be circumvented by simply closing the game without saving. The second is to hopefully take the edge off the saving system. By not having to write the entire map each time it should (in theory) keep things running smoothly. All of this goes hand-in-hand to create a game the player can boot into and forget about their save file, and feel more like they're entering a persistent environment.

It seems tiny saves still lag the game out a bit, which I haven't yet been able to solve. It's currently not realistic, unfortunately, to save the map file every time the player makes a cut into a tree, for example. My research has lead me to believe this could just be the nature of the beast, although I wonder how other games manage background saving in they way they do. I imagine I'll either need to save the game during times when it's less obvious (although this could be exploited), or ensure the game is always saved on exit (also exploitable, but less so).

I think it's important not to get too hung up on preventing players who would go out of their way to exploit certain aspects of the game. There's going to be a point of resistance where 'cheating' simply isn't worth the know-how or time for the average player, and that's probably the sweet spot.


Fishing and errands will be the two biggest feature introductions in 0.0.3. While errands is somewhat by-the-by, fishing will likely need a very close eye in order to ensure it's a satisfying system that's fun to play.

After all, if you can't kick back and enjoy some fishing, why play at all.


Follow me on Twitter, or maybe even Mastodon.

The Garden Path dropped its first alpha release to testers last week, and a second release is being tested today.

The first alpha test went down a treat, and was even more valuable than I could have hoped. Not only did we unearth new strange bugs, but the testing also helped me begin cataloging and prioritizing bugs I was already aware of, but had maybe needed a reminder of.

Indeed, just as important as discovering what didn't work was discovering what did work. It's an incredibly satisfying payoff when, after all the hard work, things go according to plan. Hearing that testers were able to gather nuts and seeds, discovering a traveling NPC, and then make a successful trade with them, was remarkably reassuring.

But we're still early days — things didn't always go off without a hitch.

Generally stability and performance were highlighted as focuses, which was my focus for the week.

One bug, known now as the 'bug of death' crashes the game with no warning. The console leaves a cryptic message that could not be solved with either google or the debug.

The game, despite being a lot smoother than before, still stutters when the player is moving through the world. Some stutter inevitable, and to be expected, but in an ideal world we want things as smooth as possible.

In this second release, the way objects are loaded and unloaded has been entirely rebuilt. Now, rather than each of the many thousands of Spawn Points issuing their own loading commands, a central script now queues and manages all of the loading for them — the Spawn Points simply make the requests.

This way, the engine isn't being bombarded all at once, it's less like holding a glass bottle upside down, and more like pouring it gently. Things don't come out as quick, but we all benefit from it. Each prop in the garden path is very simple, but there's a lot of them. While loading them takes no time at all, things can get a little stuck when they're loaded all at once. This way, should the player enter the loading zone for multiple props at once, they'll still be loaded in a neat order.

I also discovered a trick in Godot of using 'call deferred'. By 'deferring' different functions, they are given less priority, and run during idle frames. This not only seems to reduce the number of complications, as things are only processing when safe, but prevents more stuttering by, again, not overloading the engine.

With those two tricks, it seems as though the bug of death is no more. In fact, for the first time since I can remember, The Garden Path runs with no reported scripting errors in the debugger — masterclass!

Alas, one sacrifice had to made. While Godot can handle thousands of nodes on screen, the dream of having each leaf on each tree rendered individually was proving to be a pipe dream. While it ran fine with ten, maybe even twenty trees on scene, frame rates began dropping hard once the garden got more dense.

It simply wasn't worth it for such a simple effect that's hardly noticeable. And, with the new shader that adds a subtle sway to all foliage in the game, it's difficult to tell the difference.

Now we can have attractive, densely populated forests, at a fraction of the performance loss. Just think, rather than all of those thousands of leaves rendering, we can spend those resources on filling the world with interesting flora and vegetation.

Not to mention, it's infinitely easier to build trees when the artwork is a single sprite. It offers vastly more control over the colour and shape of foliage, and takes much less time now that I'm not placing each individual leaf on the tree (I wish I joking). My seemingly endless attempts of syncing the foliage position to the position of each tree matters no more.

It's shaping up to be a pretty stable little package now, I think. Which, it should be, the game is too simple for things to be falling over.

Most of the bugs are from systems from some years ago when I was still learning code. That stuff's invaluable, it's messy and it hardly works, but it got me to my place of understanding today.

If this test goes all well, the next release will be focused on new content, rather than plugging holes.

That'll be more fun for all parties.


Follow me on Twitter, or maybe even Mastodon.

The key words in last week's report were 'if all goes to plan'.

Alas, I wasn't able to get the game to a good place to release to testers last weekend. A few bugs reared their heads with the introduction of much more content. But that's okay! Deadlines like these are designed to motivate, and by that metric it certainly worked.

With four days to totally commit to the project, I made some incredible progress and also learnt a good number of lessons to take with me moving forward. I figured, since I 'failed' to release the alpha last week, I could go over the mistakes and hurdles I faced and how I've since overcome them.

As this was the first time I actually booted a large amount of content into the game, this came with a few surprises. Some were good – my brother has been writing a large amount of dialogue for the game, and I was finally able to load a portion in. It was such a joy to suddenly be able to talk to the characters and experience new dialogue as I would a player playing the game for the first time. It made the characters feel so much more alive, and it really gave me an insight into how the experience would be, playing the game for real.

On Monday evening, at the end of crunch, I encountered a bug that essentially left me to throw my hands up and call it quits. While some characters operated their dialogue perfectly, others would repeat the same line, over and over, no matter what the player did. What really tripped me up here is that all the characters share the same code, so I couldn't figure what the variable was.

I won't bore you with too much minutia, but I had made some glib decisions in my code early on that tripped me up.

As I was testing the game, dialogue files were much smaller, and might have taken a millisecond less time to load in. With the larger files, that extra millisecond meant everything else was flying out of sync. So, while to the naked eye it was loading instantly, that fraction of a second made all the difference — hence why some characters worked better than others, some had larger dialogue data than others.

All it took was a simple line of code, something I previously neglected, that sits and waits for the data to be processed before confirming and continuing.


I had felt confident about The Garden Path's performance, having done tests where I would load hundreds of trees in and maintain a steady framerate.

While The Garden Path runs a single, large and seamless map, I had developed a simple system where all trees, flowers, plants and so on, are just co-ordinate data on the map until the player gets close enough.

In testing, however, the player does a whole lot of moving, which I rather sillily hadn't accounted for. Once the map was full of plants, the sheer amount of loading in and loading out as the player triggers the areas to load in, and leaves the areas to load out, for hundreds of plants — the game grinded to an absolute crawl.

This was especially demoralizing, as I had pinned so much of the game on being a large, seamless map, but fortunately there was a solution I landed on that worked a charm.

The big 'aha' moment for me was remembering Godot has something called a ResourceInteractiveLoader. It's primarily there to be used for loading screens, to prevent the game from crashing as it's overloaded from loading in a large game.

I use it for my own loading screens, and I was able to lift the code directly and place into each spawn point for every item.

Essentially, instead of the game demanding something be loaded now, it delegates the loading to the background, dripping in the loaded content as the game has resources to do so. As loading in a flower (for instance) is actually an incredibly low-resource task, the reality is that there's no waiting time at all – it just prevents a hundred flowers, say, being loaded all at the same time, all at top priority.

(Writing this I stumbled on a commit that says this feature will be removed shortly in favour of multithreading. So that'll be on the to-do.)

Couple this with a new system that holds onto already loaded assets so the game isn't unnecessarily loading them twice, and a simple timer that times down should a player leave the zone (preventing it from loading in and out if the player backtracks) and The Garden Path feels smoother than ever to play — a real boost.

Lastly, I've slightly adapted the artwork in the game to be both quicker to produce and easier to read on screen. It's only a minor stylistic change from the big update some months back. It'll be a big time saver in the long run, prioritizing larger and more bold brush strokes over the fine detailing I had used before. So much of the detail was getting lost and even confused once assets were shrunk down into world, so it made sense to double down on the details that really matter. Best yet, none of the old artwork goes to waste, as it only takes a minute or two to adjust the shading to fit into the new scheme.

I had a moment of clarity on Monday as I watched the variety of different veg headed villagers wander around the game, as I thought just how close this was to how I visualized the game in my head 3-4 years ago. It occurred to me the only thing that still didn't feel quite right was the player character.

I decided it was time for a complete rebuild of the player node, which was still using the puppet structure I set out in 2018. Adapting the existing artwork, I've settled on a look for the player that's more mature and proportioned.

It allowed me to rebuild the character from the ground up with everything I've learnt over the last years, resulting in a puppet that's really good to work with. This has allowed me to ditch the old running animation (my first ever animation in Godot) and create a new running animation that I'm very proud of, one that actually feels like you're running through the garden, rather than just gliding.

It's hard to describe without playing it yourself, but moving through the world feels so much more satisfying now.

If I can get something as fundamental as that right, then I'm hopeful the rest will follow.


Follow me on Twitter, or maybe even Mastodon.