Thursday Report: Under The Hood
As I’m closing in on finishing the broad stroke of features and systems in The Garden Path, the last couple week’s I’ve been fine tuning and refactoring some older and some more haphazard code, so that I can start introducing more complex features that make the game a game.
‘Singletons’, in Godot and elsewhere, are functions and variables that can be accessed universally, no matter what scene the game is running. Since The Garden Path operates virtually entirely in one scene (and I’ve read in the past that Singletons can lead to some messy issues down the line) I thought it best to steer clear of them generally.
Item data, however, was causing a headache. The was no central hub of information, the details of each item were written into the item itself. Everytime an item was moved, dropped, traded and so on, the details of the item would be trusted between the scene that holds the item, and the scene that’s about to accept it (think an NPC’s inventory to the player’s inventory). This, not unlike a game of chinese whispers, could easily lead to certain information getting lost or misinterpreted as it passes through some clumsy code of mine.
I finally bit the bullet and started an item database. So, instead of writing the details of an item in the scene of the item, I could have a spreadsheet that the game can access (as JSON) that has all the information laid out for me.
The trouble I previously had with JSON is that, as far as I could tell, to retrieve information I would need the numerical ID of the data. That is, ‘what’s the value of Blue Hat?’ would become ‘what’s the value of 234?’. Not very readable or practical in real world work.
For dialogue, I had worked around this by grouping ID’s that have certain information. Let’s say it’s raining, and we want the NPC to acknowledge that to the player – the game would look at every possible entry, then group the one’s that contain the type ‘rain’. This works okay since A) Data can be divided in chunks between characters, so files don’t get too big, and B) We want a pool of options, not a single dialogue choice, to pick from at random.
With items, for the sake of making things comprehensive, there is one data file, and when requesting the details of an item, we’re not grouping anything, we’re seeking the details of that one item.
I’m surprised the solution didn’t come to me sooner. When the game is loaded, we can simply fill a dictionary (a data class that has keys and values, ie. ‘Pig : A mammal’) with each item’s id against it’s name. That way, we can look up ‘Blue Hat’ in the dictionary, the dictionary returns ‘234’, and we can search for item ‘234’ in the database as we could have done.
With this, I created a very simple singleton function I called ‘Lookup’. All you do is put in the name of the item and the detail you want, and it’ll return it. By doing this the details of the item are now hard-wired to the database, and the only data that scenes need to lumber around is the name of the item – everything else is tucked away, ready to be reliably retrieved when I need it.
With that out the way, I had a opportunity to begin cleaning up certain interfaces and making them work better together.
The inventory now retrieves the item’s name and displays it above, hiding itself away when there’s no item in the slot.
I’m hoping to have a system soon where the player can inspect an item, displaying a larger icon, a description of the item and it’s stats if applicable.
A single ‘UI’ state has replaced individual states the player enters when opening different screens. The ‘overview’ UI now operates the same as the inventory and equipment screens. It’s also received a new look, where previously it was a large card, now it dims the view behind it.
Furniture can now be picked up as an item by long holding down the use button. The furniture piece deletes itself, spawns and icon which the player then automatically picks up.
Furniture can then by placed down from the inventory by simply hitting the use button.
A new ‘queue’ system under the hood expands the response system from the dialogue, so now dialogue can prepare to display different UI elements beyond just the player response, like a trade window, errands, mail and so on.
The trading system is what I’m hoping to work on next. I’m very excited about it, and all of these changes to items make it much easier to implement. I’m hoping to do away with having the player reduce their items to a single arbitrary value, like ‘gold’ or something similar. Instead, they’ll have to be wise to each character’s preferences and moods, and not all trades will reflect an items absolute value.
Hopefully I’ll have something to share next week.