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?