official devlog

Thursday Report: The Right Tool For The Job

This week I focused on building and refining the action system in the game.

While I had something rudimentary in place to handle digging holes, talking to NPCs, and so on, building upon the system should give me a great platform to fill the game with potential interactions.

This time, the system first checks which tool the player is holding, and then looks to see if that tool is relevant to any contextual item that is around them. This goes on the theory than there’ll be fewer tools in the game that interactable object types. This might be jumping the gun at the moment, but I guess time will tell!

Certain actions will likely supersede everything else — speaking to an NPC, for instance, shouldn’t mean you have to put away anything you’re holding. So, if the player’s interaction bubble meets an NPC’s, and they press the action button, a discussion will always take place. I’ve no doubt somewhere down the line this could cause frustration, where a character might be milling around a space where the player wants to dig. I’d certainly favour this over swapping out tools whenever a character is nearby.

That said, there’s no reason I couldn’t implement a toggle button where the tool always have priority.

This actually a terrible interaction bubble, squares might be better.

With the new system in place, I’ve begun rolling out more specific actions like, for instance, planting a seed in a hole dug by a trowel.

I’ve yet to sit down and figure out a system where a vast array of different types of items, seeds, flowers and so on, can all be introduced into the game’s framework without too much work on each typeset.

Not quite tall enough for golden goose eggs.

This leads me to the new equipment menu (or so I’m calling it for now) that I have been developing. Most games have a menu separate from their inventory menu that allows quicker access to certain items. This usually resides at the bottom of the screen, always visible, and items can be hot swapped much faster than trawling through any inventory screen.

There are a few principles I’m resting my laurels on in regards to the game and UI. The first is that I want the screen free of any UI whenever possible, and the second is that UI (when on-screen) should feel tied to the world itself.

A bar at the bottom of the screen wouldn’t feel tied to the world, since that space is dictated by the screen itself (the ‘screen’ doesn’t exist in the established world). Instead, a menu that appears around the character is more appropriate.

A definite downside to having no constant UI elements is that this usually means the UI is locked behind a button and an animation that only leads to slowing you down. While I’ve always been one for taking the slow road, I want to create something that feels very clean, and responsiveness is a big part of that. Some players may also wish to play as efficiently as possible, and that’s fine too.

I’m comfortable with how snappy the menu is behind a button, but I’m hoping to have the menu also tied to the number keys on the keyboard, and the right analogue stick on controllers, so tools are just a flick or a press away.

I’m undecided whether this menu should be tied to exclusively the tools the player owns, or if this is something the player can customize with whatever items from the inventory they wish. Currently I have the seeds tied to the fifth slot for the sake of demonstration.

A few small animations and sounds tie the whole package together.

Many of you have probably also noticed the addition of the player’s tools being appended to the backpack itself. I’m surprised this isn’t something that occurred to me even after playing some hours of ‘Breath of the Wild’. It’s an addition that just gives the world a little bit more weight, especially as more and more tools get added. It also helps visualize swapping out different tools, as they’ll appear and disappear from the player’s back.

Maybe most importantly, it’ll be a chance to flaunt unique and rare tools that can be obtained throughout the game. Of course, those that aren’t so hot on the ‘burdened gardener’ look should be able to switch it all off if they choose to.

So stylish!

I’ve toyed with the idea for a unique visual gimmick being ridiculously large backpacks, but I’m not sure I’m ready to make that jump yet.


Follow me on Twitter.

Thursday Report: The Race

One of the scariest aspects as an artist on large-scale projects is competing against one’s own artist capabilities. It’s a race — the longer a project takes, the better an artist you’ll probably be by the finish line. That is, of course, if you are practicing and creating and improving in the meantime (which during a project, you almost certainly are).

I have no idea if this is avoidable. A year ago I released ‘Crossing to the Cold Valley’ — a project which I had initially created entirely in about 21 days as a university project back in spring 2016. It was the first time I had really committed to environmental illustrations; I adopted a quick brush-stroke style that seem to generate backgrounds very quickly, and I remember being very happy with how they looked.

When deciding to release the game to the public a year later, the job was simple, I had to upscale all the 720p artwork (I have no idea why I built the game in 720p) to be 1080p and call it a day. I soon realized I would need to touch up areas with the brush tool, and after just a few minutes on my first image I realized: ‘Oh, I’m better at this now’.

Suddenly I knew in my gut that a week’s work was actually going to take me until Christmas.

2016 v. 2017

Over those months, something even worse happened — the last improved illustrations were looking much stronger than my first attempts. All of a sudden, I wasn’t correcting 2016-me, I was correcting 4-weeks-ago-me. That’s even more work to tackle.

‘Half of art is knowing when to stop’ — just about everyone is quoted as saying something along these lines online, but that’s probably because it rings true. The answer is, of course, to set a deadline and stick to it. While we can look back as single pieces as relics of a past, old artwork for a larger project, while ‘finished’ is part of a much bigger piece that isn’t. The challenge is a compromise.

I’m guilty of being human: social media has been invaluable in sharing with me inspirational artworks that teach and guide what I do, but I do get jealous. Not necessarily jealous of someone’s ability, but more often a stylistic decision they’ve made in a project that looks stunning. I often find myself thinking ‘What if my game looked like that?’.

And it’s liberating to know that I’ve made things aren’t yet set in stone, the style of the game could change. That said, it’s important to remind myself to see value in my own style and my own perspective. Always bring yourself to something if you can.

So, I’ll go back to some placeholder artwork and improve on it. I pushed out a large amount of art, before and during the summer this year, because it’s an easy way to build engagement, and it’s something I know I can do already. And sure, it’s nice to take a break from coding and development, but I do run the risk of pushing out artwork that will only need to be replaced a month or two down the line as my understanding of lighting, shading, shapes and colour change.

That said, practice is practice, and there’s no shame in wanting a project to look as good as it can be. Right now I’m going to be slowing down on artwork, so that as the game mechanics develop I’ll have (hopefully) grown into a stronger artist from my other illustration experience over time.

I’m always flattered whenever anyone comments kindly on the look of the game, because, for the most part, the sprites themselves are very rough still. But so much more than the raw artwork contributes to the look of a game. It’s important to experiment in taking those rough sprites as far they can go, so that when more refined sprites come through, it’s the full package.

I added subtle eye movements to Augustus, and it contributes a great deal of life and character to the game experience. Suddenly you read more into his character, he seems more anxious and observational, rather than having his eyes focused dead on a single, dull point. It’s a simple loop, but it goes a long way.

In a similar vein, I had a request a couple weeks ago to talk about my dynamic shadows, and felt it made sense since it’s a feature that’s often commented on across social media. Truth is, it’s built right into Godot, and requires very little work to get working, but it certainly gives the characters a sense of weight and place.

Godot has a ‘Light2D’ node as-standard. This is essentially a bunch of preset features for how the game should treat a certain texture.

The texture itself is just a radial gradient, with a bright yellow tone in the center, fading out gradually to full transparency.

Godot then runs this as the blend mode ‘Add’. Blend modes, for anyone that doesn’t know, are fairly standardized across many pieces of software dealing with visuals. The gist is that it decides how a layer visually effects the layer beneath it. ‘Add’ lightens the layer beneath it according to the brightness of the layer above it — so with the texture above, the center would be lighter than it’s surroundings, gradually fading away from the center. That’s exactly how a light should be.

Godot also has a ‘LightOcculder2D’ node. This is a two-dimensional polygon that, as the light emits and hits it, will remove the light texture in that direction to create the illusion of a shadow.

It’s essentially an invisible opaque wall, but it should be drawn to reflect the character that is drawing the shadow. Larger characters would have larger light occluders, for example.

And you’re ready to go. You toggle shadows and so long as the light occluder is within the light texture, it will draw a shadow. The shadow will continue until it reaches the end of the light texture.

I would love to have a global lighting system, for sunlight or moonlight, but this isn’t currently so easy in Godot. The Light2D shadows rely on the shadow extending as far as the light itself . The sun lasts as far as the horizon, so it would need additional data to figure out how long to cast the shadow for. One trick is to make an absolutely huge Light2D that covers the entire game, but this is pretty taxing and unpredictable. I’m still looking for other solutions. I would love to convey light breaking through foliage somehow.

The last thing I will mention is ‘Item Cull Mask’. In Godot, you assign each node to a different, labeled layer. This helps the engine, but also me, to know what’s the ground, what’s the interface, what’s an NPC and so on. By ticking on only ‘env’, it means the shadow only casts itself along the ground, and not through items or characters, resulting in things looking unintentionally translucent.

I’m hoping to focus myself and make strides in the game’s mechanics themselves as top priority over the weeks leading up to Christmas.

I’ll be sharing as much as I can on the development along the way.


Follow me on Twitter.

Thursday Report: Splash Into Shaders

Making progress with deciding how the garden would be pieced together felt difficult without knowing exactly how a key feature would play: water.

No garden would be complete without water features, and a natural world wouldn’t feel right without ponds, rivers, lakes existing in and in between it.

Water has been the bane of all developers probably since it became a necessity. Solid ground requires, at a minimum, a texture that reflects the ground itself. Maybe some nice lighting. Water presents challenges that a static texture of water can’t solve — perhaps most importantly because it’s not static. It’s translucent, it reflects light, and it reacts dynamically based on it’s surroundings. I would say these are the key to presenting convincing water.

‘Don’t Starve’ takes a stylized approach, using 2D images of waves tiled in front of one another, moving in an almost puppet-show way. It’s a striking solution for a 2D-styled world, and fits in perfectly with the game’s kooky, macabre tone.

I imitated this in ‘Kingdom Ka’ during the head-swapping scene for the small-scale water needed for the figure to pull heads from. It’s a quirky solution that suits the absurd nature of the scene well. It’s immediately recognizable, despite sharing very little in common with actual water.

The salesman delivers.

And while this approach suits these two cases, I had my hesitations when thinking if this would be the way forward for Walled Gardens.

Although still a heavily stylized game, it’s objectives are different. I want visiting a pond or a river to evoke those feelings we get when sitting next to water in a quiet corner of a forest. It brings a certain calm, and invites you to stop for thought. Don’t Starve’s waves say ‘Danger!’ in a world where you’re constantly on your toes. You can’t watch 2D cut-outs of water for any longer than a moment before wanting to move on.

I knew then that I would need to dive into the world of shaders to achieve something that would feel both in-line with the style of the world, but also something that felt like real, calming water.

As it turns out, scripting shaders is a whole other kettle of fish to work I’ve done previously. Since water would like be the main shader (and possibly the only shader) in the game, I didn’t think it would be worth learning an entirely new language — there’s people who dedicate their working lives to this sort of thing. So, I dipped into some shorter tutorials, found a few pieces of open source code, and kind of stitched and all together, slightly changing values and inserting multiplications randomly where it seemed right to see what it all might result in.

And hey, it kind of worked. Making changes and seeing how code reacts triggers a sort of boyish excitement in me, so it was a good way to spend some late afternoons.

The first breakthrough was having a reflection set up. A simple flipped portion of an image goes a long way in looking like water. The gist is that the game captures the pixels from the screen directly above the shader and inverts them horizontally, all in realtime.

There’s definitely something magical about seeing the characters reflection suddenly appear in the water. The trouble with this solution is, as it relies on the actual pixels on the screen, it flips and breaks when things aren’t exactly what it is expecting.

For instance, if the camera moves so that the ‘water’ is too far up the screen, the shader doesn’t have the information on what to reflect, as it would be out of shot. The result is the shader stretches the few pixels that are available, resulting in visual glitches that wouldn’t be passable in a final game.


This makes sense. The source I based the code on was for a side scrolling game, where the water level remains constant. The shader also stretches things in exaggerated ways when the camera is zoomed in and out, likely because so much new information is introduced or taken away.

So maybe reflections can wait for another day. I’m sure the solution is for the game to reflect the scene rather than the pixels on the screen, which I’ll need to look into.

So I looked to focusing on the surface of the water itself. As water flows, it skews and shapes the light around it. ‘Displacement mapping’ in shader-talk is where a texture is used to instruct how the shader should manipulate the pixels beneath it. You can say, for instance, that the texture should react the reds and greens in a texture . Then, you pass that texture to move slowly across, the sprite below.

Think of it almost like those funhouse mirrors at carnivals where you stretch and distort your face or body in different ways by moving yourself up and down. Only here, it’s the mirror that is the one that’s moving.

Example of a displacement texture.

So I quickly drew out a sort of pond-like sprite with the stones sitting at the bottom, and mapped out a polygon to match its shape that the shader would occupy.

The texture separated from the game.

After some value tweaking, it looked good! Satisfying like water. It even masks my hideous stone texture underneath somewhat. Trouble is that it’s also unsatisfying like treacle. The gloopiness of the texture gives it this glossy, old-school 3D look that feels entirely out of place for the rest of the game.

Treacle pond.

With some further tuning, I was able to get something that looked much more crispy, and more fitting.

The water as it looks now.

I think the sharper look suits the game’s 2D style much better, although I don’t see this as the final product. I’m sure I’ll be going back for some further tinkering to get something that works better.

For now though, I’m happy to finally have something functional and adaptable. I can draw out rivers and ponds, throw a shader on top and very quickly have some effective water.

Ready, no doubt, for some self-reflection, and countless fishing hours.


Follow me on Twitter.

Thursday Report: Find a Way!

The playable character got a slight make-over, including smaller, more manageable ears and blinking eyes. It’s a nice touch that certainly makes the character feel more alive. The plan is that these features will easily be swapped out based on future customization options.

I’m somewhat averted to the idea of a character creator. I have a habit of spending far too long in them, when at my core I would love to dive into the game itself. That said, I don’t see it as something I could completely do away with — something static like skin colour might have be selected before entering the game. In theory, the character should both be potentially male or female, or anywhere in between depending on the player’s wishes. Hairstyles will help give the player the option for the character to appear more or less feminine, for instance, without the player feeling locked out by a creation screen.

The existing face is still very boyish, so I’ll need to decide if this is something the player can change, or something to homogenize.

New backpack layer is a fun addition — lots of possibilities for this slot that the player could customize and wear.

A rustling sound effect gives the backpack a sense of weight and place.

A bug I had trouble with, but didn’t share (because it looks terrible), is that characters would pick a point to walk to, and then do so regardless of whatever obstacle might be in their way. This meant characters would often get stuck against trees, or other impassable objects.

I toyed with the idea of having a zone around each impassable object that once the NPC enters, would stop, think, and redirect themselves.

Instead, I currently use a ‘Ray Cast’ node. This creates an invisible line between where the NPC is, and where they want to go. Should this line pass through any object that might potentially block the character, the character will then decide on a new location.

I think this works well because the effect is virtually instantaneous. It means that, instead of having the character walk up to a tree and realize there’s a tree in the way, they simply won’t choose a path they can’t get to. I think this seems more natural.

The NPCs do still walk into the player character like it’s nothing, continually plowing through like no tomorrow. The solution isn’t so simple here, as the Ray Cast can cover a very long distance. Ideally, the character would stop (not change direction) if the player gets too close within a certain radius, and is actively blocking their path.

A bug that had plagued me for some time was that if the player filled a small hole, all holes would be filled across the map. The hole is essentially a sprite that looks like a hole with an area surrounding it telling the game — ‘this is a hole!’. The command to remove a node in Godot is ‘queue_free()’: queue the node to be removed from the game once it’s ready (not affecting any other part of the game).

Once the player emits the signal that he wishes to fill the hole he is in front of, all holes would fill. Signals are global, so this makes sense.

All holes across the map were receiving the same signal. ‘self.queue_free()’ produced the same result, and finding the exact name of the specific hole (Godot keeps unique names of all nodes) and calling that to remove did not work either (still unsure why).

The solution was obvious, to check the distance from the player and the hole. The the hole is in range — remove this hole. If not, leave it be.

The animation is still absent, but this puts me back on track for working on the action system throughout the game.

Amusingly, I still have similar a bug where engaging with one character in conversation will lead to all characters in a certain radius joining in on the conversation.

Hey, at least they’re keen.

If you like the look of my work, a great way to support me right now is to check out my adventure games, currently both 75% off on


Follow me on Twitter.

Thursday Report: Chitter Chatter

Mostly polishing things up this week with some animations and tweening.

One issue I had run into with the dialogue box is that, although the box spawns in the correct locations according to the NPC’s head, if the player were to move the camera, the box might obscure the NPC or simply look strange.

The fix was surprisingly simple. I set up a signal that gets emitted by the camera whenever the camera is zoomed in or out. It says to the rest of the game ‘camera changed!’ and certain parts of the game can act accordingly. The dialogue box listens for this signal, and it knows that once the camera changes to find the spawn location again (now that it’s moved by the camera moving), and change position.

This worked fine, but looked a bit choppy — the dialogue box would suddenly appear in its new location. A simple tween takes the two points, where the box is and where the box will be, and makes a nice little animation between them.

Godot comes with a number of different mathematical animation options to change the feel of this animation — I went for ‘CIRC’, which once arriving at its destination floats a little bit back of forth. I think this gives the box a better sense of place by making it seem less rigid. Speech bubbles would float around in real life, right?

Don’t we all?

Oh, and boxes now automatically find the name of the NPC and place it’s name atop the box.

Hubert is a fresh addition to the crew, and marks the first ‘villager’ archetype added in the game. I figured, as a round and well proportioned apple, Hubert would be perfect for the ‘default’ villager on which all other villagers are based. In theory, all the work done on Hubert (states, scripts, animations etc) can simply be hot-swapped with new sprites and information and a new villager is ready to go.

Since there will be vastly more villagers than travelers, this makes sense in the face of father time. If at any point this feels homogeneous, I’ll be sure to make adjustments. In theory, however, personality types will be as easy to assign as, well, assigning them. Then the game will know how the villager might act, and what they might say.

Ready to hit the town.

But for now, I’m focusing on getting Hubert right.

Facial animation was another focus this week. It occurred to me that ‘AnimatedSprites’ would be an ideal solution to the problem I had. Previously, as seen in the video footage of Tellstone the Toad, I had the mouth animate open and closed on a tween. It looked repetitive and too bouncy for normal speech. An ‘AnimatedSprite’ node allows me to load in many different sprites and either pick between them or cycle through them. So, with many mouths loaded in, I can select the closed mouth when the character isn’t talking, and spin through all the mouths when they are.

By just pasting in each mouth at a fairly random order, you can quite easily create the illustration of speech.

The fun part is spamming these in a random order.

It looks smoother than my GIF capture lets on.

I think the jitter of the blinking eyes and moving mouth is a nice contrast against the smoothness of the tweens. I think it’s a nice reminder of the story-book like aesthetic the game has.

Nodding in agreement.

And above is a simple example of how some small gestures can really give life to the conversation. I’m hoping that I’ll be able to change character expressions depending on their dialogue, and their actions as well. Perhaps for more casual conversations (not when a character is ‘shocked’, for instance), a series of different animations can play out randomly to make things look more natural.

Nothing too extreme, of course. No one wants two wild hand gestures after another. That would just be silly.


Follow me on Twitter.

Thursday Report: The Groundwork

On Thursdays I write up a short report on my developments and thoughts if to do nothing more than keep myself accountable. Enjoy!

Last week I was up transferring my websites over to new hosting and briefly lost access to my email addresses, which wouldn’t be a problem if it weren’t for Medium’s unusual passwordless log-in system. So, oops! Plenty to dive into this week.

My priority over the last couple weeks was to improve on to the dialogue system. It’s still bare-bones, but I’m figuring out ways to make it more complex.

Previously, upon approaching an NPC and pressing the action button, the NPC will spout a single line, and the the dialogue would end.

My solution for adding multiple lines of dialogue was to convert the dialogue data into an array. An array is simply a series of strings (text) separated by a comma, where each string can be summoned by pointing to its number in the order it appears.

Then, all we do is +1 to the original number so the game knows to look to the next dialogue entry, in order. This would go on forever, though, so we need to find when the dialogue would end. For this, I conclude a line of dialogue with ‘END’, the game then checks if the word ‘END’ is in the current line. If it is, the word is hidden, and instead of continuing onto another line of dialogue, a signal is emitted to let both characters they are free to go on their merry way.

I like this system because it’s based on human language, and it’s simple.

Sounds scary!

In the future, for dialogue options, I’ll likely introduce a similar system, where if a line ends in ‘OPT’, or something similar, the game knows to pass the dialogue onto the player.

But this is all very static for now. NPC’s will always say the same line of dialogue. Eventually some selective database will need to be put in place to deliver a range of different lines to the player, and provide the player with dialogue options contextually.

That being said, this isn’t a conversation game. Listening, however, will play a large part. I’m hoping that a large part of my time working on this game will eventually be in the writing — what the characters say and express. Most dialogue options will be agree, disagree or say nothing. Options are important to keep the player engaged, and also feel as though the world is reacting to them. A little goes a very long way.

Concept for dialogue selection.

The above is just a concept at this stage. I like the idea of most UI elements feeling as though they’re floating within the world, and not on some abstracted plane on the user’s screen. Thought-bubbles play into this nicely. Perhaps using icons instead of text would give it a different feel. That’s something I’ll need to decide.

You may have also noticed in the GIF above — snow! In efforts to move the world building forward, I devised a new way of tiling the ground. A while ago I started building a tile-sheet of sprites — essentially a sheet small squares with slight differences that get drawn from and form the world. The two major issues with this is, first, blockiness — when you build a world from squares our minds can really sense the mathematics order of it, and things seem rigid. Secondly, is repetitive textures. Our brains are designed to see patterns, and it’s remarkable how puzzle-piece even the most random of textures can look when stepping back.

Instead, I’ve made a single large block of plain white that’s just larger than the average screen. On top of that sits a speckled texture that gives the ground that flowering, grassy feel. The texture overhangs, so that it merges with the blocks surrounding it. The result, even when zoomed out, is a ground that’s impressively seamless. But the best part is something I hadn’t considered — colour modulating!

Here’s the overlay atop the block.

Any texture that’s pure-white can be changed to any other colour through the engine. This means that, on the fly, both the colour of the ground and the overlay can be faded into a different tone dynamically.

With this we can have the grass reflect the seasons, snow cover, or anything else. I’m hoping to see if I can introduce this to tree foliage, to perhaps randomize the colours of each tree for variety, and have them gradually fade between seasonal colours.

This is ugly, but it demonstrates the point.

And just to finish us off, a new WIP animation for the old traveling gardener. He doesn’t have a name yet, despite much inner-deliberation. Turns out when a character has a cane you can’t animate them as you normally would.

This old man represents a time before the player arrives in the garden, and welcomes all fresh and exciting things to come.


Follow me on Twitter.

Thursday Report: The Conventional and the Non

I thought I’d use this report to look back at some of the design work I’ve done, particularly regarding characters.

Animals are always a fun way to capture certain characteristics that bring out a role. We all anticipate a way a monkey would act against, for example, how an owl would act — then we can take that further into the real world, how would a monkey lawyer conduct themselves compared to an owl lawyer?

It’s surprising how easy our minds allow the personification of animals. A monkey in a pinstripe suit doesn’t require much justification to be immediately believable, and there’s already a huge weight of traits we assume about him.

The task I had, then, was finding that balance. Riding on those assumptions too much and we have a cliche, steering away too far and things begin to feel ridiculous.

Let’s say we’re designing a scuba diving character. We might immediately start considering a penguin, maybe a seal, or perhaps even a dolphin that walks on its flippers. What if it was a blackbird? Why would a blackbird be going under water? Wouldn’t its feathers get wet? Suddenly we feel that sense of doubt, it could happen, but it’s a bit goofy — it’s trying to steer away from expectation. Why couldn’t it just be a penguin?

There are still roles I’m having a hard time deciding on, and maybe I’ll concede and choose the obvious. However, there are some characters I’ve settled on that I think were the perfect choices.

Constellations will play an important role in ‘Walled Gardens’. Players will need to discover which stars to connect with which to unlock certain bonuses. I needed a character that would provide that knowledge, and more, to the player. So — what animal would be looking to the stars?

Our aforementioned owl is the obvious choice. Maybe a bat could have been another. I settled on a heron. A bird known for standing very still by the riverside, it’s head often turned upward. And while nothing specifically is carried over from a heron to a night, or even astrological theme, here we have an animal known for its patience, observation and staunch neck — having a heron with a telescope in hand suddenly doesn’t seem so outlandish.

And what about a character known for digging, making tunnels? Our minds probably immediately go to a mole. While a pig might not be known for it’s digging underground — showing a pig character covered in mud and dirt is just what we’ve come to expect, so it doesn’t take such a leap of faith to give it a mining hat and a certain ‘can-do’ attitude.

Again, I still have a fair few more to consider, but hopefully this gives an insight into my designs.

Shying away from the conventional choice just gives everything that slight edge, it feels new and carries with it that bit of magic.

But, at the same time, not so unusual that it doesn’t feel familiar, and doesn’t feel at home.

‘Home’ is ultimately what I want to capture.


Follow me on Twitter.

Thursday Report: Digging Yourself a Hole

This week I was able to make a quick start on the landscaping that the player will do throughout the garden.

Although it’s only small, it’s great to see the systems for how the player might affect the garden after its generation. I decided to start with the trowel — it’s the only tool I’m absolutely sure on including, so it was a safe choice. It has a small form factor, and a many handy uses that the player might find themselves taking advantage of.

Maybe the traditional gaming shovel will make an appearance for those larger, deeper holes — although in a game where most gardening is planting seeds, would such a hole be necessary? Maybe a shovel would be used to remove a tree stump from the ground, but in the real world this would be arduous work. I like the idea of a tree having a real presence and sense of place, planting a tree shouldn’t be done frivolously, and neither should taking one down.

I haven’t yet figured out the best way to obscure the tip of the trowel to give the illusion it’s digging into the ground. I’m happy with the animation for the most part, it has rhythm and a good sense of weight and snappiness.

An easy way to establish a rhythm is to simply make sure each part of the animation plays out for the same time interval — or a division thereof. Watch the animation above, and you can count a consistent beat: 1, 2, 3!, as each motion lasts for exactly 0.2 seconds.

I would prefer if the player got on the knees — for the promotion of good posture! — , but that’s something I might have to figure out down the road, as it might involve swapping out sprites.

I still need to add the hands, and I’m still torn whether arms are a necessary inclusion — it would certainly make life a lot easier without having to flail those meat sticks around in animation.

While I originally had in mind to animate the dirt being dug up myself, it occurred to me that setting up a particle would be easier and offer many benefits. Some acceleration is added to the sprites and then a large amount of gravity is applied so they fall toward the ground. I randomized the size, the rotation, and the position of each piece. Now, every time the player will dig up the ground, the effect will look different with each dig.

The game creates a node with the image of the hole just below the player, and plays the particles as it appears. Just how many nodes can the player create before the engine collapses in on itself? Who knows! I’ll likely have to start removing holes when they’re off camera to keep things from spiraling out of control.

Next on the list to continue this will be for the player to fill in the hole after pressing the same button, or — of course — planting a seed.


Follow me on Twitter.

Thursday Report: RNG Trees

Every Thursday I write up a report on my latest developments and thoughts if to do nothing more than keep myself accountable. Enjoy!

I always knew I wanted some kind of random generation when it came to the game’s environment. To what exact extent, I’m still undecided. Currently I’m fond of the idea that there will be a number of large ‘parcels’ have predetermined features — certain elevation, certain water features etc. When a new game would be made, these parcels would be pieced together randomly, like a jigsaw with hundreds of different outcomes. I think this would give a good balance of random and predictable outcomes, which would make things more manageable but also fresh.

I’m still new at all this, so I’ve decided to start by building a ‘Spawn Sheet’. This is a sheet of many points, wherein each point rolls a digital dice. Depending on the number that lands, depends on what will be generated — a bush, a flower and so on. Then, once that’s been decided, another dice is rolled to determine whether this prop will spawn at all. I’ve called this ‘likelihood’ and I simply rank it from 1–100: 100 means it’s guaranteed to spawn, 1 and it will never spawn.

I can see this system getting out of hand very quickly since it’s so simple. Currently this spawns 1 of 4 outcomes, but once hundreds of different props are added to the game, I’ll need to figure out something more modular.

Having each point running it’s own code is probably a messy solution too. There will be thousands of points in a single game, so I’ll likely need to think of a way to generate each point through code, instead of plonking it down myself.

Still, I’m proud of delivering something that works at all. It’s exciting seeing the game do so much work for me already, and my main game scene is no longer filled with a hundred flower nodes that I’ve been having to sift through to find the player.

A small bit of code randomly shifts each point so there’s no obvious grid — things look more organic this way.

Eventually stricter rules will need to be in place. Certain zones might spawn more fir trees, for instance. Three bushes should never spawn directly on top of one another, for instance. That should come eventually.

‘Tellstone’ now has both placeholder walking animations. I originally envisioned his foot sprite swapping out for a version that shows the base of his foot, in front of his body. Godot doesn’t offer a super-easy way of swapping out sprites, or even showing and hiding certain sprites in its built in animation system, not without attaching code that triggers when a specific keyframe is played.

I’m actually very happy with the current animation without the foot coming up over his body. It’s surprising how much just shifting a still-sprite gives the illusion of weight and depth. I’m keen to return to the animation to give his backpack more of a clumsy heaviness, because it looks too rigid at the moment. He’s a comedic character, so I want that to come through in his animation.

Character’s now face the player when they talk to one another. This was far more simple than I anticipated — I simply deducted the character’s position from the player’s position. If the number is below 0, the character knows to turn to the left, and visa versa.

I decided that characters would always face forward when speaking. This not only simplifies the checks on where the player is standing, but also means all the fun expressions the characters will show won’t be lost to the player. It also doesn’t look as outlandish as I had worried.

Next week I’m hoping to make a solid start with the tools the player will use throughout the game, starting with the trowel, so that the player may dig small holes with which to place seeds in to cultivate their garden.


Follow me on Twitter.