carrotcake.studio

official devlog

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

Thursday Report: Designing Progress

With the holiday’s now long gone, it’s time to get deep into some dev time. Despite needing to blow off the dust and getting the ball rolling again, I’ve made some pretty comfortable progress already this month.

The general roadmap for this game has been to spend 2018 learning Godot, (which was very successful) then spending 2019 building the game’s systems to allow a smooth 2020 of content creation. This, above all, is a game about content. Even if that content might reveal itself slowly, a sandbox game needs huge variety to keep the intrigue ticking.

All players have different interests, and while they might play the same game and enjoy it, their drive for what keeps them playing can be widely different. Many players will enjoy the act of designing and curating their garden, and even if there are no further objectives, if the tools compliment their creativity well enough, no further systems need to be in place.

However other players may need something more — not everyone gets a thrill from design, and not everyone has the creativity to set their own goals. Sometimes, even if they do, they need that small push that rewards and inspires it.

So those are the two foundations for the game — providing fun tools for creativity, and providing a sense of progression.

Sweet, sweet statistics.

Progression often comes in two forms — horizontal and vertical. Vertical progression is where your character simply becomes stronger, and objectively better than they were when they started. Horizontal, on the contray, is where the player obtains more options. For a classic example — a character might find a better sword that kills enemies quicker, or they might find an axe that has the same power as their current sword, but attacks in a new interesting way that the player might enjoy, or might be better against certain enemies, but worse against others. More options.

I believe that most games these days find a balance between the two. Vertical games suffer from ‘power creep’, where (since the only way is up) things become so powerful that anything beneath it becomes trivial or obsolete. Horizontal games can obscure any feeling of progression — that player might unlock a hundred different unique weapons, but find they still like the first or second weapon they ever obtained the most.

Fortunately, ‘unlocks’ tend to be a compelling reason to progress for many players regardless of genre. Take Mario Odyssey, a game infamous for its huge number of ‘moons’ the player can achieve. While to begin with you will need to collect a certain number of moons to progress, many players will still enjoy collecting all remaining moons for nothing more than the glory of doing so. I’m the opposite. Any ‘unlock’ that doesn’t effect the game itself is ‘just a number’ and doesn’t engage me at all.

I hold the mantra that good design is when everything feels connected, and everything has a purpose. So why not give unlocks a purpose that effect the game in a meaningful way?

New star unlocked?

I came up with ‘constellations’ as what I hope will be an essential part of urging players to continue playing, by giving them meaningful objectives. Stars will become unlocked by the player completing a huge variety of different tasks, both menial and obscure. One star, for instance, might be for catching 20 fish, another might be catching a rare fish that only comes out at a certain time.

Once the right stars are unlocked, they can be connected as constellations. If a correct constellation is drawn, is becomes activated, and provides a unique change to the garden while it is active. Say four or five ‘fish’ related stars are connected, perhaps this increases the number of fish in the garden, or increases the speed at which fish go for the bait.

In this way, players both have a record of their accomplishments, but they can also utilise those accomplishments to actually benefit them in fun ways.

Elsewhere in the game, some players will get a kick out of finding clothing and cute matching outfits, or unlocking their favourite villagers to live in their perfectly designed garden. But why not also reward those that want to find the right gear that gives them the best stats for the task, or unlock the best combination of villagers with the right personality types to help unlock the most furniture types? The goal is to give each play style a chance to be gratifying, without being the ‘best’ way to play.

The ground-to-stars transition as-is.

I knew I wanted a transition to go from the game view to the stars. Being a top-down game, this makes things a little tricky. The imaginary camera would be pointing downward at the scene, and then would have to tilt upward toward the stars. This is a 3D motion, but in a 2D game this wouldn’t be possible without placing things on a 3D plane, or some smart shaders to bend the pixels in a convincing way.

What I did have on my side was speed — the stars are ultimately a menu, so it should be snappy going in and ou. What looks good isn’t always what ‘feels’ good, and while a slower transition might be more to behold, having to watch that transition for the 100th time might start feeling sluggish.

Speed helps with the illusion; the fewer frames, the more the brain fills in the gaps. The transition is made of a few moving parts, the camera, the gradient, the clouds, and the stars.

As the camera pans up on the Y axis (remember, it’s not tilting, this is 2D), the gradient (which is just three colours: complete transparency, sky colour, night sky colour) pans down.

Me moving the gradient up and down with my mouse.

Somewhere midway, the clouds (which are panning down with the gradient) do a little split animation. The clouds are made of four cloud sprites moving at different speeds to give a slight sense of depth.

Cue choir.

And that’s it. Once the gradient is all the way down, it’ll be the colour of the night sky, so we can just fade the stars in to form the scene for the menu.

I think it’s a pretty neat effect, and it conveys what it needs to convey without playing around with perspective. Again, the speed obscures that. I’m not entirely happy with the rhythm, so to speak, it feels a touch robot where it could be smoother. But, for now, it works just fine for testing purposes.

Also implemented was a system to move the furnishing around. This was pretty simple, the effect is put on the object to make it translucent and blue for that ‘blueprint’ look we’ve come to expect, and then it’s position is simply updated as it’s moved. The object can also be cancelled to move back to where it was.

The tricky part is actually determining exactly what item the player wants to move. Each item has it’s own zone that the player must be standing in for it to know the player might want to move it. But what if those zones are overlapping? Currently I have a system where the game finds all the items (yes, all — so we’ll see how performance is once we have a sizable furnished garden) and then compares the distances from the center of each item to the center of the player.

The same system works for NPCs as well, so I killed two birds with one stone. No more having two characters yapping at you when you only wanted to talk to one.

After all, three is a crowd.

*

Follow me on Twitter.

Thursday Report: Play Me A Song, Jack

I’ve always believed music is a perfect way to start any project. Perhaps more than any other medium, it transports you somewhere immediately, and all you really need to do to understand it is listen. In that way, a sense of tone is immediately in place, and from their it really lends to the imagination. Music is abstract enough that it doesn’t dictate what should be built around it, while providing that framework of ‘mood’ right from the get-go.

As such, I’ve discovered that all my recent game projects I’ve started with music. Even projects I haven’t yet started, I’m sitting on music for.

I’ve found writing music to be maybe the only creative activity I find difficult to put down once starting. Something about piecing everything together, and finding something new among the twelve few notes there are, is very satisfying once the ball is rolling. As such, it’s eaten up large portions of my spare time.

For this particular project, I began the very beginning of the game — the player entering the garden. ‘Breath of the Wild’ became reknowned for its radical step away of traditional soundtracking, opting for greater stretches of silence, and subtle piano motifs to compliment the vast open world that was new to the franchise.

So I started with this fresh in my mind — trying to find very simple melodies to punctuate moments of pause. And while this seemed like the way forward, I couldn’t ignore that I would also need to convey something entirely different — work needing to be done, plants emerging, characters going on about their day — a growing metropolis.

I started focusing more on arpeggiated chords for the piano, and to build that sense of adventure: rapid fire wind instruments (there’s surely a more accurate term for this).

All of sudden I had something that was showing an inkling of Sufjan Steven’s ‘Out Of Egypt, Into The Great Laugh Of Mankind’, the closing track to his 2005 release ‘Illinois’.

Link to Video

I knew then immediately who I had to look to — Sufjan’s own inspiration for this sound, Steve Reich. While ‘Music For 18 Musicians’ had always been a favourite record of mine, I had never really dived into his other prolific works. It wasn’t long before I knew I was exactly where I needed to be.

The foundation of Reich’s music is using melody to create rhythm, where we typically see this process done the other way round. Pitched percussive instruments like xylophones, marimbas and even pianos, are layered many times to create a wall of sound and unusual rhythms compliment one another to create something vastly larger than the sum of its very simple parts. At least, that’s my uneducated assessment.

Link to Video

Although I’m unaware of any other game that’s taken this approach to its music, I’m cautious not to sound like a Steve Reich wannabe. And afterall, hours of heavily layered music might be distracting to a player that just wants to focus on the game.

So I went back to the silence that I started with, and the piano melodies, and thought there was still a place for both.

The result, hopefully, is a sound that begins quiet and gradually builds. Sometimes, at least — maybe not always. I’ve begun scripting a system that will hopefully delivery music more dynamically, playing music at key moments, but with the likelihood of music playing becoming ever more increasing.

So all of my compositions so far have had a focus on both quiet and more ‘full’ moments, they begin often with simple piano, that may or may not build into something more rhythmic, with a deep body of strings underneath to give it more of a broody, pensive quality.

I’m sitting on at least half a dozen music ideas, but I’ll share just of them today (although you might have heard the others in the background of the various videos I’ve been sharing on social media). This is what I had written to be the main theme of the game — the melody that will appear and reappear in various places throughout.

Whether or not this piece will be played while game is running, or whether this is more of an introductory piece, I’ve yet to decide. Maybe a little bit of both — I’m hoping to strip each and every song into its elements to re-purpose them in as many ways as possible.

It’s certainly not finished, but I think it gives a good sense of how I’ll be working with music in the game. While everything else I have so far feels more static, I was able to get this piece to move between three distinct sections, and I’m very proud of it for what it is.

Link to Video

Enjoy!

Expect slower Thursday Reports as we move into the holiday season, but I’ll be back at it as soon as I can for the new year.

Happy Holidays!

*

Follow me on Twitter.

Thursday Report: JASON!

This week I spent some time looking into databases. Since there’s going to be a great deal of possible conversations through the game, it wouldn’t make sense to deal with this dialogue directly in the engine itself. Sorting through great numbers of copy in code probably isn’t even good for the soul.

External databases make things more manageable — I knew this much. My time creating or even using databases is virtually non-existent however, so I knew I had some learning to do.

I began looking into CSV, which seemed at first like the ideal format. It can be formatted and edited in most spreadsheet software, but exports to raw text that can be parsed by the editor.

Through my digging, however, I learnt about JSON, and how it’s a popular choice for many modern systems and software. While JSON is built with Javascript in mind, it’s wide-usage has made it viable on all kinds of different platforms, including Godot.

From what I’ve discovered, the beauty of JSON is also it’s curse: JSON is simple by design. You add the label of a thing, and then you type what that thing is.

From Wikipedia

Taking the above example, if you were writing this out the hard way, you bet your butt that you’re typing out “type” and “number” for every single “type” and “number” that you’re dealing with.

Fortunately, since both CSV and JSON are just text, they can be converted between format without too much trouble. My plan, then, is to build everything in a spreadsheet, where I have a full and clear view of all the data, export to CSV, and then convert to JSON. Which means we go from this:

To this

And it’s good to go.

I don’t know if this is the right way of doing things, but it seems to be working for now. As always, I’ll be keeping to the standard practice of keeping things as simple as possible, until anything breaks.

Speaking of which, I did spend an embarrassing amount of time this week trying to figure out why my arrays (the dialogue itself) wasn’t translating correctly between the JSON and the game when running. As it tturns out I had been using two different kinds of quotation mark the whole time, which systems don’t like much, no-sir. Who knew there was more than one kind — I certainly do now.

These aren’t the same thing, folks!

But, with that out the way, I now have a pretty effective way to assign each character their own unique database of dialogue that the engine will pick and hand the character on-the-fly. While travelers will each have their own unique dialogues, the vegetable villagers will have different personality ‘identifiers’ that they will be labelled with to help balance the workload.

Tellstone now speaking his mind.

Currently I’ve been able to randomise different dialogues, but I’m hoping to have Godot navigate the database to select dialogue based on many factors, including the weather, how ‘warm’ they feel toward the player, and pure chance.

I’ll eventually be extending databases for different items, tasks, and other such areas where there are too many items I’d be mad not to.

Unfortunately my previous plan to assign dialogue instructions by including capitalised, three letter terms to the end of each entry (such as ‘SHO’ for ‘shocked’) has fallen a bit short. It works by itself, but combining different instructions seems to be giving strange results.

Still, this is the beginning of building a dialogue system where I can start establishing conversations where character really start to react and convey emotion, all in an environment that’s clean and structured.

After saying, “Hey, it’s my favourite gardener!”

The player-response system is still being toyed with. I really like the philosophy behind using icons rather than text at this point — a picture paints a thousands words, after all. However I’m still struggling with finding icons that don’t feel too gamey or interfacey. It’s hard to describe, but I don’t want the player to suddenly feel like they’re navigating a phone rather than a world. So we’ll see, something to come back to.

Throwing around ideas for conversational responses.

Lastly, I’ve been reworking the inventory system with my new wisdom derived from working on the equipment screen.

The result is something that’s almost functional, but still needs some work. Each slot is now it’s own node that takes care of itself, rather than the inventory screen managing all the data. This makes it really easy to assign the quantities and item of each node.

Will six slots be enough?

The only thing left are the many items to begin filling those slots with.

My original placeholder was an apple, which I quickly scrapped after realizing that eating an apple in this game would, of course, be abominable.

*

Follow me on Twitter.

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.

Oops!

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

*

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.