official devlog for
carrotcake
written by Louis Durrant
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.
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.
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.
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…
>> Link to post.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!
Thursday Report: Saved by the bell
Sometimes I find myself in a rut, unsure what to work on next. What this looks like is me dipping into many pre-existing elements of the game, and making a few tweaks here and there, but never having the guts or the drive to commit to anything significant.
I think that’s okay, and I also think it’s natural. I do the same with illustration; sometimes I’ll know the piece isn’t the best it can be, but I’ll reluctantly go through, making tiny adjustments to shading or lines, until I realize what’s actually missing.
Because, often, the only thing keeping me from making inroads is some piece of knowledge, usually in the form of a decision. Typically I don’t know what I don’t know, so these little probes takes the form of mining at a rock, until eventually a little chip falls apart, bringing with it an entire chunk, and you can keep on mining and mining the soft earth until it becomes hard again.
So to speak.
So last week I’ve made probably the biggest (at least, the most sudden) inroad since I started working on this project. I always had in my notes the two behemoths of coding that I would be dreading: map generation, and a save system.
Map generation, as you might remember from my last blog posts, wasn’t too breezy, but is – as far as I can tell – functional enough to enjoy the game.
A save system was still hanging over me – I knew it would require somehow writing data to the user’s disk, and I didn’t even know where to begin in that regard.
Turns out, following just a couple of tutorials, I had the schematics of a fully working save system in just a couple of hours. And I had completely underestimated how important a tool that system is. I only wish I had committed to figuring it out sooner.
By capturing a saved state, I’m able to then go into the data, and make tweaks directly – however large or small – and then load into that new scenario. It feels as though I’m no longer in a sandbox, but actually playing the game live. That’s a whole shift in perspective.
This has allowed me to start shaping the ‘New Game’ experience. This is something that’s been mulling in my head for quite some time. My philosophy is to have the most minimal introduction as possible, while still immersing the player into the game’s world.
As discussed before, I want no character creator screen, but I don’t realistically see a way around having a skin-tone selector before the player starts the game. It’s rigid part of a person, and something that should have no ‘default’. I’ve shared the skin-tone selector before, and I think it’s an acceptable singular menu that appears before starting the game. You select the skin tone, and then you’re in.
If anything, I’ve grown to appreciate something placing itself between the main menu and the game world. It neatly bridges the gap as a menu itself, but is the very first stepping stone as the first choice the player makes.
A five second cinematic then plays, subtly zooming away from some overgrowth. The player can be seen emerging from the overgrowth, and the game begins. This will be followed by some subtle tutorial guidance hinted by the world itself, but otherwise the player will be left entirely to their own devices.
(Don’t worry, it’ll look better than this, but you get the idea.)
The other big mechanic that save-files allow me to begin working in is time. ‘The Garden Path’ is real-time, meaning if you play the game at 4pm in the real world, it will be 4pm in ‘The Garden Path’.
This comes with its own problems. It would be wrong to design a game around people who work 9-5, and also wrong to lock certain content at 3am. There will be systems to allow the player to shift sunrise and sunset to a certain degree, but another simple solution is to simply give the players the option to completely shift the game time in relation to their own time – twelve hours either side. Even if they work a night shift, they can still hop in after work and have the sun rising in the game.
Would players just use this to time travel and exploit the game? Not if they can only do it once – one of those ’tutorials’ will be a sundial (or similar object), that will allow the player to change the time, but will become only decorative afterwards.
Can’t players just adjust their system’s time to exploit the game? Yes. That’s on them. If you sell a kid an action man and he wants to pull all the limbs off, that’s up the kid.
There’s a number of appealing components of a real-time game. It helps players respect the world, it prevents burn-out, it gives players something to look forward to each day at a slower pace.
That slower pace can sometimes become stagnancy however. Winter’s last long enough in the real world, and sometimes we might want to escape to somewhere where it’s spring.
As such, I’ve decided the game will have it’s own calender. Very simply, each week will be its own season. That means (roughly), every month the player will see spring, summer, autumn and winter.
This not only helps with things being stagnant, but also helps speed up the gardening process. In this way, a tree growing in a few weeks makes sense according to the game’s logic.
I’m inching closer and closer toward being in a position to start building real content for the game.
There’s still so much work to do, but for the first time, I feel like I can start to smell it.
Thursday Report: A Fresh Brew
Apologies for the absence! Virtually all my focus these last weeks have been building the trading system. The process has been laborious, and still needs a lot of work, but is now entirely functional.
Unfortunately with this being my main focus, the opportunity for fun gifs, or even much discussion, is pretty limited. I’ve spent hours this week essentially swapping hats between myself and a frog, keeping an eye on values as the items are evaluated and traded.
As described in my last blog post, all items have a series of tags, and each character has a preference over different tags. The game crunches the number between what you’ve selected from the NPC’s inventory, and what you then offer from your own. It then finds the multiplier to see just how good a deal the trade is, so the NPC can emote accordingly, and decide to make the trade or not.
A large part of this process was essentially rewriting the existing inventory system. Beforehand, all the information for the inventory was actually held within the inventory node and slots themselves. Each slot had its own values – item id, quantity etc, and so what you saw was the slot representing the data within itself. Any changes would be physically changing that data inside the slot. This worked fine for testing, but was difficult to mass-manage. This difficultly becomes exponential as you begin adding more and more inventories, as more and more NPCs fill their pockets.
The new system uses a singleton to streamline everything. Now a single dictionary value holds all the active inventories in the game, and new dictionaries can be created with new unique ID’s very quickly. That ID could be an NPC’s name, but it could also be a storage container, for instance. In this way, inventories now represent this singleton, rather than themselves. Having a more secure and absolute piece of data is much more reliable, and much easier to work with.
The conversation system is also more streamlined, allowing for many different paths and avenues a conversation can go down, and it now being much easier for the game to know how the player and the NPC will react given the context. This will make things much easier as I begin introducing more flavour text, or even add new systems in like quests or challenges.
I’m going to be taking a step away now from trading to help refresh and reset my head, although there’s still a lot of refinement and features that need including.
I’m developing a new ‘global’ menu currently. The ‘fullscreen dim’ concept was well received on social media, but it had a number of issues that I believe this new menu solves.
First is regarding the philosophy of the games UI. One of my original statements for the game is that all UI (while the game is in play) will feel as though it exists within the game world. Dimming the entire screen is essentially the complete opposite of this – it removes the player from the game. I felt so long as this was the only menu to do this, it was okay. The new menu is not perfect in this regard, but it feels more organic, almost as though you’re pulling a book up in front of you, which suits the philosophy more to its original word.
Secondly, with this new menu the game world is still in-view. This is important because the game is both persistent and real-time. Dimming the screen obfuscates the world and creates a false sense that the game is being ‘paused’ or withdrawn. Also, with this new menu, the UI no longer blocks the view of the player character. As this menu will be used to manage items, it’s important the player can preview how their character looks. Previously I had planned to do a sort of ‘doppelgänger’ node that generates based on the appearance of the actual character. I no longer have to do this with the new menu, and simple is usually better.
Lastly, I needed a way for the player to ‘inspect’ an item from their inventory. The inventory displays an image of the item, and it’s name, but that’s all. While a player’s inventory is open, this menu can also be opened, providing a rich amount of information while still keeping the inventory in clear view.
There’s still a lot of work to be done on this menu, and I’m still completely uncertain on how the contents will be laid out, but the concept of having details come in from the left side is working really well.
An increasingly obvious downside to having a game with anthropomorphic vegetables is that including edible apples and oranges would be somewhat unethical with sentient apples and oranges walking among you. This was a problem, particularly because I liked the idea of having the garden provide consumables that give temporary buffs to the player, and possibly even recipes that would further this.
Upon doing some read-ups on different species of vegetations, especially their wider practical uses, I was surprised how so many spices and herbs derive from otherwise totally innocuous plants, sometimes even from the same plant but different parts.
And this got me excited – why not have the game feature these herbs and spices as ingredients to brewing different teas? Many games feature recipes for dishes, but I’m unaware of a game that pays homage to the sheer number of different concoctions of tea. After all, you can basically pour hot water on anything and it’ll be tea in one way or another.
It also suits the tone of the game perfectly.
This solves one of my greater conundrums – what systematic purpose does growing a garden give you beyond it’s appearance? Now I think I might have it. All game mechanics in The Garden Path should have basic three functions – they must influence the other mechanics of the game, they must produce collectibles, and they must feel good to do.
Once you check those boxes, the mechanisms interlock, and the watch begins ticking away.
Thursday Report: Show Me The Money?
Game economies are notoriously difficult beasts to tame. Fortunately The Garden Path is single player, which makes things more manageable, but minds work in different ways, and when releasing a game to the wider world, suddenly there’s exploits beyond what you can control. Unintentional loopholes, or ways to play the game that prove to be more profitable, ultimately ruining the fun.
From the beginning of building The Garden Path, I wanted to tackle the challenge of structuring a game with no global currency. No ‘gold’, ‘rupees’ or ‘caps’. Instead, all items have an inherent value, but different characters all value different items differently.
I think this gives the game more flavour. Instead of selling items to characters that have seemingly endless pockets of currency, it encourages you to be more alert about what you have, and the characteristics of the personalities attracted to your garden.
A global currency typically lends a way to reward all play-styles. This is somewhat true, although inevitably players discover a specific play-style is often more efficient, forcing them away from the play-style they enjoy most. But a global currency means someone that likes, say, bug catching, can sell their bugs just as someone that enjoys fishing can sell their fish. Doing away with this adds an extra step – players may trade fish for constellation patterns from Jenny the stork. Players that don’t enjoy fishing might have to buy fish off Augustus the bear by collecting honey. How much of a burden that is will be hard to say, but I think I would prefer to double down rather than work around it. By reducing everything to a currency, it somewhat homogenizes each part of the game. I’d prefer each play-style to have it’s own identity, it’s own paths and methods – that exites me more.
And so, every single item in the game will have a number of tags, invisible to the player, from a global list of possible tags. This could be ’edible’, or ‘shiny’, or ‘practical’. The tags are binary, the item either has the tag or it doesn’t. Each character then has its list of tag preferences, and a numerical value to increase or decrease how much they value that tag – Augustus the bear will value rustic, wooden items over items that are decorative or modern, for example.
The item also has a value multiplier. Although characters have their preferences, they’ll still likely concede to selling a bag of fertilizer to you for a cut diamond, even if they’ve got no use or want for a diamond. Since it’s a multiplier, an item that’s both valuable and appropriately tagged will appeal to that character exponentially, making it a very appealing trade.
A character will show you what they’re willing to trade, you’ll select what you want, and then make an offer. The game will then crunch the numbers – if the subjective value of what you’re offering is higher than the subjective value of what the character has, they’ll accept the trade. Simple!
A hidden ‘warmth’ value will affect how much you appeal to a character, both inside and away from trading, so this might just tip the scales in your favour.
Sure, sometimes you’ll get a raw deal, but that’s life, and life usually doesn’t operate on any kind of objective value.
Social cues will make it obvious whether or not you’re getting away with a good trade or not, so it isn’t a complete shot in the dark, and you can always back out. If a character seems reluctant, but gives in, you know you’ve made a good trade. Maybe if you’ve totally overshot your mark, a character that warms to you will refuse on principle, or ask if you’re certain.
When discussing this, a friend of mine pointed out that an exploit would be exponentially inflating an item’s value by repeatedly buying low from one character and selling high to another. The reality is, however, a character’s pockets aren’t infinite – you can only trade so many times in a day. But more importantly, these characters aren’t sales-people. The items they carry they do so because that’s their business to do so. The characters are loss averse, as are we all, and are only trading because you were the one to ask. You can’t forcibly sell your junk, but there’s always someone who will think that junk is treasure.
Hopefully that shines a light. Coding this kind of thing is much less exciting than discussing the theory behind it, and it’s a long, arduous process that I’m deep in the middle of.
Thursday Report: Under The Hood
As I’m closing in on finishing the broad stroke of features and systems in The Garden Path, the last couple week’s I’ve been fine tuning and refactoring some older and some more haphazard code, so that I can start introducing more complex features that make the game a game.
‘Singletons’, in Godot and elsewhere, are functions and variables that can be accessed universally, no matter what scene the game is running. Since The Garden Path operates virtually entirely in one scene (and I’ve read in the past that Singletons can lead to some messy issues down the line) I thought it best to steer clear of them generally.
Item data, however, was causing a headache. The was no central hub of information, the details of each item were written into the item itself. Everytime an item was moved, dropped, traded and so on, the details of the item would be trusted between the scene that holds the item, and the scene that’s about to accept it (think an NPC’s inventory to the player’s inventory). This, not unlike a game of chinese whispers, could easily lead to certain information getting lost or misinterpreted as it passes through some clumsy code of mine.
I finally bit the bullet and started an item database. So, instead of writing the details of an item in the scene of the item, I could have a spreadsheet that the game can access (as JSON) that has all the information laid out for me.
The trouble I previously had with JSON is that, as far as I could tell, to retrieve information I would need the numerical ID of the data. That is, ‘what’s the value of Blue Hat?’ would become ‘what’s the value of 234?’. Not very readable or practical in real world work.
For dialogue, I had worked around this by grouping ID’s that have certain information. Let’s say it’s raining, and we want the NPC to acknowledge that to the player – the game would look at every possible entry, then group the one’s that contain the type ‘rain’. This works okay since A) Data can be divided in chunks between characters, so files don’t get too big, and B) We want a pool of options, not a single dialogue choice, to pick from at random.
With items, for the sake of making things comprehensive, there is one data file, and when requesting the details of an item, we’re not grouping anything, we’re seeking the details of that one item.
I’m surprised the solution didn’t come to me sooner. When the game is loaded, we can simply fill a dictionary (a data class that has keys and values, ie. ‘Pig : A mammal’) with each item’s id against it’s name. That way, we can look up ‘Blue Hat’ in the dictionary, the dictionary returns ‘234’, and we can search for item ‘234’ in the database as we could have done.
With this, I created a very simple singleton function I called ‘Lookup’. All you do is put in the name of the item and the detail you want, and it’ll return it. By doing this the details of the item are now hard-wired to the database, and the only data that scenes need to lumber around is the name of the item – everything else is tucked away, ready to be reliably retrieved when I need it.
With that out the way, I had a opportunity to begin cleaning up certain interfaces and making them work better together.
The inventory now retrieves the item’s name and displays it above, hiding itself away when there’s no item in the slot.
I’m hoping to have a system soon where the player can inspect an item, displaying a larger icon, a description of the item and it’s stats if applicable.
A single ‘UI’ state has replaced individual states the player enters when opening different screens. The ‘overview’ UI now operates the same as the inventory and equipment screens. It’s also received a new look, where previously it was a large card, now it dims the view behind it.
Furniture can now be picked up as an item by long holding down the use button. The furniture piece deletes itself, spawns and icon which the player then automatically picks up.
Furniture can then by placed down from the inventory by simply hitting the use button.
A new ‘queue’ system under the hood expands the response system from the dialogue, so now dialogue can prepare to display different UI elements beyond just the player response, like a trade window, errands, mail and so on.
The trading system is what I’m hoping to work on next. I’m very excited about it, and all of these changes to items make it much easier to implement. I’m hoping to do away with having the player reduce their items to a single arbitrary value, like ‘gold’ or something similar. Instead, they’ll have to be wise to each character’s preferences and moods, and not all trades will reflect an items absolute value.
Hopefully I’ll have something to share next week.
Thursday Report: A Whole New World
I took a break from the Thursday report last week because I was still knee-deep in developing a system that would generate fresh, unique maps for The Garden Path.
This was an area I had been bracing myself for since I began learning to program roughly a year ago now. Alongside AI for the characters, it was an area I had anticipated I may need to outsource for.
I saw a great quote yesterday, “You learn just enough to do, and you try to do more than you learned”. In that spirit, I decided to see how far I could get, and how much I could learn.
I found myself encumbered with a system hundreds of lines long that simply was not working. I would rubber duck debug into oblivion, frustrated when everything in writing seemed to make sense, but wasn’t translating when the code was being run.
I ultimately decided it was time to take everything that I had learned from my first attempt, and rewrite it from scratch with a fresh head. By some stroke of luck, it worked seemingly immediately, and all in less than 100 lines of code.
So, how does it work?
The starting point is the ‘acre’ I mentioned a couple of blog posts ago. An ‘acre’ is made of 9 tiles, and so I divided the acre into 12 effective ‘sides’. Think of it like a jigsaw piece, which usually has 4 ‘sides’, either protruding or concaved. In order to know what pieces can sit next to each other, those sides need to be matched.
Here’s the guide I made that helped me along the way:
Certain environmental features need to be preserved to make a cohesive map. For instance, an acre with a river ending on it’s right side, will need to be connected to an acre that has a river coming in the from the left side.
For each acre, an entry in a JSON(!) file is made. It includes the ID number of the acre, and what can be found on the edge of each of it’s sides. While I’m sure there’s a way to automatic this process, that’s something I can worry about later. I’m happy inputting the information manually for now.
The game see’s all the points where an acre is spawned, and needs rules to know which acre ID it spawns there (rivers next to rivers, etc), with some degree of randomness.
It starts from the top left. This is just because that’s how I laid it out, it might be more interesting if I scatter it, but I’ll be working with it scanning left to right for now.
The very first acre point has absolutely no rules attached to it – it could be anything. So, the game takes a shot in the dark and picks an acre at random.
The tricky part comes next. Before placing the next acre, it must write rules for what can appear around it. The game looks at the acre it just placed, then compares it against all other acres. To use my earlier example, if there’s a river on side 5, it must find all acres with a river coming from side 11. It does this for all acre spawn points adjacent to it, creating a whitelist for each of those points. When the game comes to picking that acre, it must select an ID at random from that whitelist.
Unfortunately, as I quickly found out, certain future tile placements may begin creating contradictory whitelists.
Take this example. Acre point 2 is spawned, and it creates a whitelist for acre point 4 (it’s southern neighbour). It says, “the river in my acre is going from left to right. There’s clear space at the bottom of my tile, so I’m going to whitelist an acre that is completely clear – one that has no river’. That makes perfect sense, so it adds it to the whitelist.
Since we’re scanning from left to right, acre point 3 is next to spawn. It says, “I have a river in my acre coming from the bottom, curving to right. I need an acre next to me that has a river coming from the left”.
The trouble is, acre point 2 has already whitelisted an acre that’s completely clear, which would not match the acre that acre point 3 has selected.
The solution is that I had to have each acre point write both a whitelist and a blacklist – both what it can be and what it can not be. Now, when acre point 3 is writing its whitelist, it writes in it’s blacklist that it can’t have an acre with nothing in it. It sees there’s the same acre in both it’s blacklist and it’s whitelist, so it removes it from the whitelist.
And that’s it, so far. I think it’s quite a neat little solution.
The river paths in the image are deliberately very rigid for the sake of me seeing how they work, but they needn’t be. These generating paths can become very natural – widening, curling, all within the same acre so long as it arrives at the right ‘side’.
This is also exciting because it doesn’t begin and end with rivers. This will allow interesting height-tiers across the map, it will allow an acre of birch trees fade into an acre of fir trees, or maybe even allow the addition waterfalls.
As with anything random, it’s not the ‘making-it-be-random’ part that’s tricky, it’s controlling the chaos within set boundaries. It’s very possible I run into issues that will require me to set harder parameters. Should I allow cyclical rivers? Is the chance of a map generating too many rivers too high? Are certain crucial acre types suddenly less common? All these factors I may eventually have to account for and control.
For now though, it’s a thrill loading up the game and landing in an entirely new map. I can feel a little bit of that urge to explore in my gut.
I’m very keen to see how this all comes into play as I begin creating the final art assets next year.
>> Link to post.