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.

Twitter • Mastodon

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.

Twitter • Mastodon

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!

Twitter • Mastodon

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.

Twitter • Mastodon

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?

Twitter • Mastodon

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

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

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.

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.

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