carrotcake.studio

official devlog

Thursday Report: The Big Push

Welcome to the first development blog of the new year! A fair bit of time over the last couple months have been spent moving out of my old flat, and redecorating the new office, which accounts for my absence.

I'm all set up now in the new den, and ready for the big push for The Garden Path.

A new deadline is on the horizon: The Godot 2020 Showreel. I can't believe it's already been a year since the last showreel. I've been looking back at the progress that's been made, considering what's worth sharing, and what will garner the most interest in the game — 10-15 seconds isn't a whole lot of time to fill.

With the majority of the game's systems in place, the showreel has been a great motivator to start getting some artwork down and imported into the game. This means villagers, flora, different clothing and furniture, all to showcase what the game is really about.

Somewhat under the hood, I've been preparing all the databases for which items and props will appear in the game, labelling my progress on each ones artwork as I go along. I think I've settled on a good number of different items, that's both realistic to achieve, while also pushing myself to make the game as rich as possible.

A visual update to the Overview menu (hopefully closing in on the final design this time) has opened up some new items for the player to customize their character. A lantern is the latest addition, a simply cosmetic item that the player can pull out and put away at anytime. This helps should be player be playing in the dead of night, if their garden isn't well lit.

Pouches are another small addition. While I was hesitant to have backpacks carry different stats on how much the player can carry (what if a player's favourite backpack is objectively worse, for instance) I figured a simply way to add some progression is with pouches. Two slots allow for gradually increasing the capacity of the player's inventory, while not affecting the visuals of the player character themselves.

While previously a player's trousers were dictated by their 'garb', now they're a separate item to collect and customize.

The final addition are dyes. Combining certain botanicals, the player can unlock different colour combinations to change the look of their character. This comes along with the change that there are no longer dozens of colour variations to collect and clutter, but instead if the player finds a hat they like, they can swap in and out any dye they desire.

For now, the main focus is getting key elements in presentable order for the showreel – these will be equipment, furniture, and villagers.

I've somewhat shied away from showing the vegetable villagers in my screenshots before, and this is only really because I only needed one in order to test – and that was Hubert the apple. No more! I want to make sure that they are the centre of the game's aesthetic, as they should be.

Currently 50 different villagers are planned with names, all with their own unique combination of personality, requirements to grow, and personality types. I've already made a good start on a handful of them, as each of their heads will be individually illustrated.

Along with the showreel, I'll be developing a proper announcement trailer for the game, closer to one minute in length, as well as finally pushing the new look and design for the game to Itch.io to give people a better feeling for the game's updated aesthetic.

It's been full steam and ahead, and no slowing down! I'm feeling burningly close to finally having a playable experience in my hands – with play testing still looming over me.

*

Follow me on Twitter, or maybe Mastodon.

Thursday Report: A World of Difference

Things are starting to really fall into place for 'The Garden Path', as 2019 is drawing to a close.

It finally feels as though the seeds I've been planting this year in development are starting to grow into something that feels like an actual game. That is, moving through the game is beginning to have its own sense of identity.

This is largely down to the introduction of the new music and artwork, that I've been holding off from introducing this year as I focused on the mechanics.

It's been wonderful having so many positive comments about the visual style of the placeholder artwork, and I hope that this new look of the game will be welcomed with the same open arms.

I've learnt a great deal over the last year about my own way of working in illustration, and it's been great finally lending that experience to this project. The game now has it's own colour palette that I am developing alongside the artwork, allow for much better visual consistency. Better use of perspective, as a top down game, is also being stressed, to help make the characters feel as though they are occupying the same space.

The style is admittedly more subdued than the previous art, which makes it slightly less eye-catching initially. But this was a very deliberate choice, as my originally vision for the game was to be a subdued experience. Bright colours and trees make good screenshots, but it's important to make the game easy on the eyes for long periods of play, and readability on screen.

But the tone is important too. Games in the same genre like Stardew Valley, Animal Crossing or even Ooblets, have an almost unapologetically upbeat and colourful tone. This isn't what I want to achieve in The Garden Path – instead I want something that strikes a balance between that sense of comfort and that sense of melancholy.

That isn't to say I want everything to be riddled with doom and gloom. In fact, it's the opposite. I want to invite players in with that sense of fun and colour, but through every action the player should start to feel that perhaps everything isn't awesome, but, crucially, that that's okay. Despite starting the game in Spring, they'll soon encounter the stillness of Winter, with the hope of Spring to come.

I decided to drop a little bit of money during 'Cyber Monday' on some sound libraries for the ambient sounds of the game. I've been sourcing most of my sound effects from freesound.org, which is a terrific source for almost any sound you can think of, and often freely licensed. While I had been using different sound pieces, cut and pasted together, for the ambience of the garden, I felt that I needed more consistency.

When you're using different sounds from different recordings, you get a different sense of space and place. Some microphones have a more intimate sound, other more wide. Some recordings feature more white noise, others less so. By picking up a library from a single recording artist, there's no subtle, nor more jarring differences, to draw the player out of garden.

I found a library that I'm pretty happy with – it's all recorded in the same forest, somewhere in Eastern Europe. There's this kind of slightly sinister vastness to the recordings that I love. It really feels as though you're lost in the middle of nowhere, even though there's some very beautiful birdsong and insect sounds that give it a sense of life. The biggest perk is that each season has its own recordings, which really helps provide that variety as time in garden passes.

I also finally picked up the last instrument library I was hoping to purchase, which gives me access to more realistic sounding mallet percussion — the backbone of the soundtrack for the game during the game's light hours. I've been revisiting my compositions from the last years, and restructuring them to better suit the game.

I found through playing that music with long, drawn out openings were much more appropriate, to bridge the player between experiencing the garden with and without music. Most of the songs have been rewritten to feature very subtle beginnings, that the player might not even notice at first, but gradually reveal themselves.

To carry across the theme, the soundtrack is mostly upbeat, melodic rhythms, but I've undercut them with very broody strings, to help balance the faster pace with a kind of swooping pensiveness.

With animations still missing (waiting for Godot's multi key frame editor) and the soundtrack and assets still limited at this early stage, it's more of a peek into what the game could eventually be.

Still, it's all coming together, and it may only be some months away until we finally get the big picture.

*

Follow me on Twitter, or maybe Mastodon.

Thursday Report: Lick of paint

This have been a little quiet over here, but fret not – development on The Garden Path has been as lively as ever, maybe even moreso.

With 2019 now coming to it's end, the big programming push is finally drawing to a close as well. While I have no doubt that 2020 will see it's fair share of coding, in theory it should all be hand-in-hand with all the content and artwork that will be tirelessly loaded into the game.

I've cheated a little bit, and already made a small start on the new artwork for the game. I'm feeling good about it. It's going to be a bit of a departure from the screenshots I've shared so far, but it will allow so much more visual cohesion across the game.

I've also migrated the artwork away from Affinity, and instead decided to house all my art for the game in Krita. Krita is the flagship free and open source painting software. While lacking a little bit in it's power as a design tool, as a painting too it's virtually unmatched.

By combining Krita and Godot, The Garden Path becomes a game that's entirely reproducible and editable under free and open software. This future-proofs the game, and removes any risk of being locked down behind software licensing or pay-walls.

Since I've started from scratch, I've had a chance to review my old artwork, and build upon it. The result is a look that's much closer to my original intended tone and aesthetics for the game.

I'll begin sharing more glimpses into the new artwork in the coming weeks, but it'll just be sneak previews for now, as I continue to settle on colours, brushes and textures across the game.

I'll be discussing my about my new way of working in an upcoming devlog.

*

Work on the game throughout October and into November has been focused on unifying the user interfaces throughout the game.

Previously, all UI elements had their own, unique code. This worked to a point, but I soon realized that as each UI would eventually need to talk to each other, it made sense to unify them under the same tree of code, so they each know what to expect.

The main incentive was being so that introducing new UI wouldn't get exponentially difficult, but something more streamlined.

As players will want to swap items between a number of different interfaces – their equipment, their inventory, a container – it's essential to have a system where moving between each interface feels like second nature.

It now works by having each UI that's open on the screen scanning all four directions to see if there's any other UI around them. If it detects UI above it, it allows the player to scroll up and over into that other UI, then disengaging the UI it came from, for instance.

Some UI even scans each individual slot of the other UI, so it knows that when exiting that UI, you're landed in the nearest slot possible. This way it doesn't always set you back to the first slot each time when switching, making it feel more natural.

This was more work than I had hoped! But I'm closing in on a system that works. Sometimes UI thinks there's no other UI, or that some UI below it is above it. It's these little quirks that I'm still ironing out. But, in theory, I'll only have to steam the creases once.

Also, a little bit of polish to the Overview screen for switches between tabs.

*

Otherwise, extensive planning has finally been going into the content of the game itself.

This involves building my own Wiki of all the game's items, plants, fish, teas, and how they all relate to one another.

I've settled on a minimum of forty different plants to start with. A sizable number, without being too crazy. What's fun is the huge variety of different resources that can be obtained from all the different plants available to the player.

It's fascinating reading how different plants are related to one another, and all the different uses each one has.

I've finalized all the animal travellers in the game, the things they buy and trade and the whole broadstrokes of how the game's economy will function. In theory, each character has something another character wants, and the player can use this to their advantage, to purchase the items each character has.

It's something that will undoubtedly require endless testing and tweaking, but a strong initial plan couldn't hurt.

*

Oh, and I've also added a bunch of parallax particles that make the game look really pretty.

Happy about that.

*

TwitterMastodon

Thursday Report: Lets Get an Overview.

Continuing on our theme, “the best UI is the one you never notice”, my original philosophy for The Garden Path was for the game to feel absent of any UI. Inventory, dialogue, and so on, would be represented as floating points that exist in the space of the game's world.

This has, over time, moved away from being a core philosophy to being an anchor. It's what I'm aiming for, and I think by grounding myself with such an anchor in mind, even though applying it might be impossible, I can at least make decisions to shift closer to that policy.

As I've introduced and fleshed out more features, it's become increasingly difficult to maintain that original philosophy. I've so far conceded in four areas.

The 'You've Unlocked A Star' notification is a necessary evil to overcome an even greater evil. My original concept, in accordance to this original philosophy, was that each time a player unlocked a star, control would immediately be taken away, and the player would have to watch a short cutscene of the star being unlocked.

What the notification allows is for players to decide when to watch this brief cutscene at their own pace. The nature of stars means they could be unlocked at any moment, and it's important not to remove the player from what 'flow' they are in by rudely interrupting them.

The first few stars also act a kind of tutorial, suggesting to the player what goals they might assume, and how the stars function. With newer player seeing more stars, it's important not to give the first impression that this is a game that likes to stop you in your tracks, and constantly away control.

The second UI is the item collection notifier, as we discussed last week. With the removal of item litter, this notification becomes unavoidable. But, even with item litter, I was straddling a dangerous UX line by not including this.

The obvious alternative is having the item itself appear to fly toward the character, into their inventory. Details like this are easily missed however, or items may be mistaken for other items. With no text, and only a moment to identify a very small, fast moving icon, it becomes a real challenge for the player. A nice large icon ensures that knows exactly what they've collected, and aren't scrambling to their inventory, trying to figure out if their seed count has gone up from 36 to 37.

The third is the clock. While the other two are only on the screen temporarily, the clock is a permanent addition to the screen. But, ultimately, if one thing should break the rule, it should be the clock. As the game is bound to real time, it's important the player has easy access to knowing the time. It's also nice to give the players an idea of how long they've been playing, and what time it is in the real world.

The final is what I've been calling the 'overview' menu. It's nothing special, but it's essentially the game's menu. You know the one, where you can look at your equipment, see what you've unlocked, change the game's settings, and so on.

To briefly go over my previous design decisions again, the very first concept for this was a sort of card that would appear on the screen. It was a little clunky, and looked pretty ugly, but I felt it made sense at the time – since a 'card' feels more like an object than a more abstract menu.

I scrapped the general idea, and moved over to a full screen fade. This looked much prettier, at the sacrifice of being essentially a completely abstract menu. At that stage, I felt it was worth the trade off, if this was going to be the only abstracted menu in the game.

But it didn't quite sit right with me still. It felt like I was trying to do something too sophisticated, when really I wanted something crunchier and more grounded. It pulls you out of the game world and reminds you that you're playing a game on a machine.

Instead, I thought perhaps the menu could appear like a page in a book, that opens over the screen. And while originally I designed the menu to be simply black and white to fit the theme of a printed page (no icons, just words), it was missing the richness and fun of a fully visualized menu – so I struck a compromise.

Most importantly, I recently implemented what I believe to be the most important feature of this menu: you can still play the game while it is open. While previously I still had my doubts in the design, by reworking parts of the game and making this possible, it cements in my mind that it's here to stay.

This also brings with it and interesting solution to a problem I had been trying to work out for some time. If the player wants to learn more about an item that they have equipped or is in their inventory, where do they see this information?

While most games that use a mouse and keyboard solve this by having an information box appear and follow the user's mouse (see Stardew Valley, World of Warcraft), games that focus on a controller usually have a shared, static space where information about the highlighted item is displayed (see Hollow Knight, Breath of the Wild).

I knew I was bound to the latter, but as the player inventory and overview menu are two very different menus, two separate shared spaces seemed inelegant.

Instead, I feel confident that by having the overview menu accessible at anytime with a single press, having just one shared space housed in the overview menu with seem like a natural place for players to go to if they want to learn more information.

For instance, if a player is trading with a traveler, and they are unsure what it is the traveler is selling, opening the overview menu will allow them to instantly read more information in this shared space, and also give them access to their current equipment, should they wish to compare.

It's a slightly unusual way of doing it, one that I'm unsure I've seen elsewhere, but it's what I'll be sticking with for now until I begin player testing.

In theory, this all means that there is only as much information on the screen as the player wishes, or as is necessary. With a few sound effects and animations, bringing up any further information should feel like flicking to page in a favourite book.

That's much nicer than a glossy piece of UI.

*

TwitterMastodon

Thursday Report: Pick Me Up

“Inventory” and “management” are two words that send chills down my spine.

It's the dreaded reality of any game with carry-able items – a menu that brings the player out of the game, and forces them to suddenly play house keeping.

Inventory management supersedes genre – and the more we want fun items, stats, rare loot, new equipment – the more management there is to do.

There are games that have tried to make something fun out of it, and it's certainly true that there are those of us who get a kick out of a perfectly organized inventory, but I think the underlying truth is that the best inventory is one that you hardly notice.

And it probably speaks volumes that the games I noted as examples of good inventory systems, I could barely remember at all how they functioned. Because your inventory shouldn't be fun, nor should it be a hassle – it should be part of the experience of the game itself.

*

I've made a number of changes to 'The Garden Path' that I believe make the game much cleaner and user friendly in regards to inventory management, that I'll be focusing on over the next few weeks.

The first, as much as it breaks my heart, was removing the action of dropping items.

Think Animal Crossing or Minecraft – any item that you can pick up, you can drop on the floor in item-form: a self contained package that sits on the floor and typically serves no purpose other than to give that item a home before it is picked up.

This is how 'The Garden Path' functioned up until now. It posed a number of problems. The first was figuring out a system where the game would remember the exact location the items were dropped. How long do they sit around for? Do they eventually disappear? Why, thematically, do they disappear? If there's a whole cluster of items, how does the player find what they want to pick up? Is there a limit to the number of items that can littered on the floor?

In addition, are there certain items that can't be dropped? Fish in 'The Garden Path' are not killed when caught (as they are a fantastical kind of fish), so it would not make sense for them to be represented by a lifeless icon, carelessly dropped on the cold-hard ground. Something about that unsettles me.

Admittedly, my biggest motive was that it's just messy. Placing an item down, like a chair or a new plant, has a weight and a purpose – throwing a shirt down on the floor only serves the purpose of giving it somewhere to live when it has nowhere else to go. A strange, temporary state.

Instead, items are now bound to the the inventory. They are held there and they are safe. When 'harvesting' a prop, instead of the prop flinging out the item it produces something, the item is added straight to the player's inventory. A shining light travels from the prop to the player, and an icon appears in the bottom right to notify the player that they have obtained a new item.

This also means players no longer need to run after whatever it is they harvested.

This immediately brought about a new problem, however – what if the player's inventory is full?

While before, items lying on the ground simply stay there until space is made. What about when an item is automatically placed into the player's inventory, how does the player know if they have the right capacity?

What I knew I wanted to avoid above all else is a dialogue window that reads (something along the lines of) “Uh oh! You've run out of space! Swap something out so you can pick this up.” Because, while it is cute, having a full inventory is already frustrating enough without having to sit through and navigate the same message every time.

And that's the trouble – a full inventory is always a frustration. It's an end to whatever flow the player was in, a roadblock to contain them. But to remove a limit entirely suddenly makes items trivial, and provides the player with bottomless pockets to fill and make endless returns on. It's a balancing nightmare.

I explored a number of games and how they went about this. Pillars of Eternity curiously does away with a limit all-together, Guild Wars 2 lets you carry excess items in a little menu until you create the necessary space. Most games simply stop you in your tracks.

It's Bethesda's open world games that brought me to what I think is the solution. It's an idea that I'm surprised isn't utilized more. The bottom line is: the more you carry, the slower you walk. Eventually, once you've hit the absolute limit, your character is unable to move.

Granted there's still a point at which the player is (literally) stopped in their tracks and forced to reorganize, but by design the player is given much warning before reaching that circumstance. The player may even decide that the walk back to base at a slower pace is worth the additional weight.

Best of all, it removes the need for any intrusive menus. Instead, the warning is tactile – it's felt by the player.

I've yet to implement it, but I think this will suit the game well. I'll be eager to see the response it gets during testing.

What I'm still figuring out is how the surplus items will be represented through the game's UI.

I've been working hard recently on how each element of the game's UI works with one another and plays. I think I've finally found a 'Overview' menu that fits right in, after many a re-design.

I'll be back to talk about that next week. Stay tuned.

*

TwitterMastodon

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

TwitterMastodon

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 itch.io 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.

Enjoy!

*

TwitterMastodon

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.

*

TwitterMastodon

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.

*

TwitterMastodon

*

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.

*

TwitterMastodon