carrotcake.studio

official devlog

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

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.

*

TwitterMastodon

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.

TwitterMastodon

Thursday Report: Show Me The Options

Just a quick report today.

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

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

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

*

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

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

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

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

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

*

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

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

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

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

*

TwitterMastodon

Thursday Report: Picking Things Up Where We Left Off

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

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

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

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

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

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

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

*

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

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

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

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

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

*

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

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

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

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

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

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

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

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

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

*

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

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

*

TwitterMastodon

Thursday Report: Aligning The Stars

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

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

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

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

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

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

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

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

*

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

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

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

My highly sophisticated control map reference.

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

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

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

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

*

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

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

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

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

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

*

TwitterMastodon

Thursday Report: Feeling the Breeze

I've been focusing on smaller aspects of the game over the last couple of weeks. While a lot of 'polish' isn't always necessary at such an early stage, I think it's good for the proverbial soul – when testing something that feels more polished it's easier to get excited, and that helps with motivation on more arduous tasks.

I had been toying in my head for some time about rendering the foliage for the game's trees leaf-by-leaf. Previously, foliage for any tree would be a single pre-rendered texture. This worked fine, and it meant texturing and shading was easily managed, but it also meant that foliage was what-you-see-is-what-you-get.

Instead, I thought perhaps I could import a single 'leaf' texture, have that leaf be its own node, and then individually place each leaf on the tree in order to form the foliage. This way, each leaf can be altered by itself – it's colour changed, it's position changed – all on the fly.

I gave each leaf it's own AnimationPlayer node, with a simple animation of the leaf rising and falling. Then, when launching the game, each leaf determines its own playback speed at random. This way, none of the leaves are in-sync, and they can react more naturally.

The result was transformative. Although subtle, having that soft sense of motion really loosens the game up. Things feel less like cardboard cut outs, and more like there's a weight and an air to the environment.

Godot's animation blending also helps give a sort of pseudo-physics impression to the trees, where I can fade in a more violent rustle of the leaf when the tree is reaction to being hit or chopped, for instance. Hopefully in the future I'll be able to have all trees react to stronger wind, or even rainy weather.

My biggest concern was performance. Each layer of a tree's foliage could have some three hundred leaf nodes, each tree could have three or four layers, and there could be dozens of trees on screen at any one time. Suddenly what would have been a a few nodes, is a few thousand nodes, all individually doing something more complex than those few nodes ever were to begin with.

And for the most part, that's okay. Being new to programming, I'm often surprised just how fast computers actually are, and how many lines of code can be completed in a fraction of a second.

The Garden Path needn't be a demanding game – if my computer can run Witcher 3 without a hitch then it shouldn't be struggling with a 2D gardening game – so I'll be hunting down drops in performance first and foremost. Having two or three trees on screen was okay, but when dropping in some twenty-or-so trees, performance began to cut in half very quickly.

As a compromise, I realized that it's the foliage in the foreground that plays the biggest role in given the environment a sense of movement. As such, I decided to make static the very back layer of the foliage by making it a single texture as before, effectively cutting the number of nodes being generated by a third. The visual difference is negligible, especially when seeing how much smoother the game runs as a result. As I begin really filling out the scenes, I may also comprise the middle layer of a series of multiple leaf batches – so instead of each leaf animating itself, maybe five or six move and react together. This would likely bring that layer's node's down from a few hundred to just a handful, while still giving that sense of motion underneath the first layer.

The trees have already been well received on social media, and will certainly help make the game look even more professional.

*

I also finally made a bit more progress on a global shadow system. Godot doesn't yet have directional lighting (as in, a light coming from a single, global source, like the sun) for 2D games, because none of the items have a Z-height to draw a shadow from – how long do you know a shadow will be if you don't know how tall what's casting it is? The lighting option for 2D games currently is omnidirectonal, it casts shadows all around the object. Which, while technically is what our sun does, the sun is so huge and far away that it visibly casts shadows in only one direction.

One solution, then, since the sun is so huge and far away, is to create a light source that's ridiculously huge and very far away. It's not elegant, but it kind of works, especially for a small scene. The available map in the Garden Path is going to be quite large, however, and the larger the map, the larger and more far away said light source would need to be. Otherwise, the light source would run out on one part of the map, like the dark side of the moon. The further away the light source, the less accurate the shadow casting becomes.

One idea was to create a dynamic polygon with a fading gradient that I could shape through code to react as though a shadow would. There's a number of problems with this method. The first is that polygons, being vectors, are very clean lines, whereas shadows often bleed or soften depending on the light source. The second, is that shadows are the absence of light, not the presence of a shadow – creating a shadow by drawing them means that multiple shadows begin to stack – getting gradually darker the more shadows are stacked. That's not how shadows work.

I realized, however, I could put the light source on the CanvasLayer. This is the layer that the user interface sits on – it doesn't move with the rest of the game world, the game world moves underneath it. As such, the game world can be as large as it needs to be, and the sun is sat among the menus and the clock, just off screen

This means, well, the 'sun' needn't be quite so huge, or quite so far away.

Again, it's not elegant, but I'd hate to see the game launching without it – shadows give a real depth to any on-screen environment.

*

TwitterMastodon

Thursday Report: Give a little, Get a little.

It was only natural I found myself working on dialogue and inventory at the same time. Both are data heavy, and both are about giving and receiving between nodes. As such, both became a little bit messy — with a large number of signals and functions all passing along the same information to one another.

Should the player decide to equip a specific hat, for instance, a series of signals collect and submit information about the hat. What’s the name of the hat? What does it look like? Does the player have more than one of the hat? What stats does the hat give the player? Is the hat even a hat at all?

Once this is received, it must be updated by asking the same questions to replace it. When wearing a hat, it must be taken off to wear a new hat. That way, the ‘slot’ on the players head has all the right information, and so does the ‘slot’ in the players bag where the hat is put away.

Dialogue, similarly, requires both the player and the character to exchange information. Who is the player talking to? Is it currently raining? Does the character like the player? What might the player say in response?

I had used JSON previously for tiered dialogue, but needed to do something more sophisticated with the database to introduce response and reply.

How does the game know if the conversation is ending or if this is when the player should be given the option to respond? Originally I thought I could tack it on to the same way the game knows what emotion the character should be feeling. Dialogue that ends with “*sus*” allows the game to know that the character should have their ‘suspicious’ face swapped in, for instance. So perhaps I could tell it that should the dialogue end with “*res” it should allow the player to respond.

For whatever reason, this caused a number of problems. A character can only show one emotion at a time, and layering further commands lead to the engine getting confused.

The current solution was more simple, add a new field to the JSON — ‘response — and the game simply checks whether or not this field is empty or not. If the content exists, it is displayed.

The next challenge was dialogue trees. As soon as you give the player more than one thing to say, you begin branching the possible dialogue the character responds with.

In my last game, Kingdom Ka, I was dealing with a small number of very branched out conversations. The first conversation in particular, had the player talking to the game itself in effort to convince the game they are human. I spent some days on this, providing as many conversation branches as possible to keep it feeling as natural and conversational, allowing what must be in the thousands of possible paths to the final conclusion.

Fortunately, while The Garden Path will feature many more conversations, there will be far fewer options. Kingdom Ka was a game about talking, The Garden Path will be (among everything else) a game about listening.

The player will always be presented with three options. The third will always be ‘Goodbye’ (because if the player wants to bail, who am I to stop them?). I had toyed with the other two options being simply a happy face, and a sad face — a yes and a no — for the sake of simplicity and manageability when it comes to possible translation.

But why pass on all the possible flavour that written text can give? If the player is asked a more philosophical question, a simple smiley face suddenly feels a bit redundant, or at least a bit too narrow.

The vast majority of these two options will be asking the character if they would like to talk, or asking if they have a task they would like fulfilled. Point of all this being, a system allowing a sprawling tree of dialogue simply isn’t necessary.

So, the response is a dictionary with three entries each holding an array with the following data— what the text says, and what ‘type’ the NPC should respond with. If the player wants to chat, the game can deliver any one of many different dialogues that are appropriate. If the player says ‘goodbye!’ I could write hundreds of different goodbye messages if I wanted to, and the game will have the character say one at random. If a response is more specific, the ‘type’ can be a unique identifier, so a unique reply is given.

Phew.

I’m feeling happy with it for now, but I’m excited I’m at a stage where I can theoretically begin writing content for the game and slotting it in without my trouble.

While I’m forcing myself to spend as little time on artwork on the game at this stage as possible, I fancied stepping back from coding and working on some visuals this week as a breather.

Fire was an interesting challenge. While the particle itself was fairly easy to set up (I drew a fiery spiral and had it emitting from a central point), fire burns a much less steady source of light than, say, a lamp. So, I set up a script that shifts the light in a random direction, and enlarges or shrinks it by a random factor after a certain amount of time has passed. This allows shadows to react, and gives it that flickering look that’s so cozy.

Lastly, I figured out how simple it was to mask sprites using Godot, which meant I could get stuck into making the UI for when the character is fishing.

Still early days, but hopefully I’ll have something for next week.

What’s a game without fishing?

*

TwitterMastodon