CarrotsCritters
patreon
This Week in the Forest! #163
🕑 Added 2024-07-21 17:48:40 +0000 UTCYO FOLKS~!
Lil mix up for this TWITF, it's gonna be all Vixel since he's got a ton of concept stuff to share!
SO LETS GET STARTED!
-
Heya floofs, Vixel here! Bigger update from me this week! ^w^ I wanted to share some of the design improvements we've made in recent weeks to better handle sidequests, and tackle the problem areas where we keep seeing bug reports!
BUT before I highlight our solutions, let me summarize a few of the problems! :V
Problem: Quests don't always play in a predictable order!
This is especially true for side quests like Booty Lineup and Blessing of the Bells, which can be played anytime after they're unlocked! Some side quests even start spontaneously, like talking to Mabel, Maverick and Oliver about spa shenanigans in the Deep Woods. As the game evolves, the different ways to play through it are increasing, creating some unexpected bugs.
For example, Mabel started riding around in your inventory during the Act 3 storm. Mabel can't simultaneously be available for her side quests AND be riding around in your inventory! And it doesn't make sense for her to go on dates either, while she's traveling with Rascal.
Problem: Spawn rules are hard-coded, and must consider every combination of dialogues and triggers that come before.
There's a spawner script for each room in the forest (Central Forest, Lake, Mountains, etc.) Most of our spawn rules are written like: "if dialogueA is played and dialogueB isn't played, spawn the thing." Some are written with extra complexity like: "spawn the thing if the player made choiceA previously."
After the big storm when Mabel's riding around in your inventory, I updated spawn rules in Central Forest to disable her home spawn, her dates, and all the side quests like Booty Lineup or Blessing of the Bells where she participates. I also disabled specific dialogues for other critters (Scarlett shouldn't tell you about Booty Lineup, and you shouldn't be able to gossip with Scarlett and activate the Blessing of the Bells sidequest.)
The opposite situation is also important - if you're already playing a Mabel sidequest, Mabel shouldn't be able to ride in your inventory, which means I needed extra rules in various spawners to delay the big storm! Disabling the storm implies Melody can't start her photoshoot, which implies Charlotte and Melody can't leave the cave to come meet the critters... and on it goes!
That's a LOT of code to keep updating as we continue expanding the main story, and it's super easy to accidentally introduce new bugs.
Problem: A lot of stuff is triggered, when it could really be inferred.
Whaa? Yeah, this one is confusing - but important! When you play the Blessing of the Bells sidequest, your savegame keeps track of:
- The quest status.
- Each quest log you encountered.
- Each dialogue that played.
- Each trigger that fired.
Various spawn rules check that data to know whether you're currently playing Blessing of the Bells; or to move critters around; or to lock out critter dates and gifts; or to schedule the next dialogues for critters, etc.
The amount of data I store in the savestate matters a WHOLE LOT if content can be replayed!
You can replay Blessing of the Bells as many times as you want. To "rewind" the adventure and play it all over again, I need extra code to un-complete all the Blessings dialogues, reset the quest status to Unplayed, erase the savekeys for affected triggers, and erase all the saved Quest Log entries. Any of that code could break later or contain bugs, and I might forget or mismanage some of the data and reeeallly confuse the game.
BUT thankfully, it turns out, we really only need to track which dialogues are played. We can infer all the rest!
- There are two Blessings quests total. We know both quests are in-progress as soon as the first Blessings dialogue is available.
- Each Blessings quest ends as soon as a specific dialogue is played.
- Which quest logs you've unlocked depend on which dialogues you've played so far.
- After carefully rewriting some spawn rules, triggers don't actually need to be saved at all.
If all this data is inferred and not saved, I'd only have to uncomplete all the Blessings dialogues to replay Blessings as often as needed, and everything else would just work.
Problem: Rules are all written differently, and there are rules scattered all over the place!
Some rules are hard-coded into scripts, some are stored in our database. Different rules are written in terms of quest status checks, dialogue status checks, trigger checks, inventory checks, etc. The lack of consistency makes each rule its own special case to maintain. Finding and updating them all is hard, and it's way too easy to overlook one and accidentally create a bug.
ALRIGHT so those are some of the problems! What about SOLUTIONS? o.O
First, I created new database control panels for Conditions! Conditions are now the universal language for writing any kind of rule. I can set up Conditions in whatever way is needed - they can track data about quests, dialogues, inventory items, easter eggs you've unlocked, anything.
For example: I created a condition called "AdventureModeActive" that is satisfied whenever any big side quest is in-progress (Blessings, Booty Lineup) and another called "QuestInProgress_BootyLineupFemales" that is satisfied whenever that specific quest is in-progress.
Next I created database control panels for all kinds of different RULES. (Rules about quests, dialogues, critter dates and gifts, side quests, dustin's arena minigame, etc.)
This gives us exactly one place to set up rules (the database), and one simple language for writing and understanding all the rules! (conditions)
Rules don't need to know what makes a condition satisfied or not, they just link to whatever Conditions they care about. Scripts can be dumb now, and just ask if a rule is currently active or not.
For example: I added a Date Rule that disables dates for all critters whenever the "AdventureModeActive" condition is satisfied.
Here's an example of how I can use this new design to clean up spawner scripts and organize spawn rules.
I created new database control panels for Spawn Rules, where I can list all the spawn rules and link which Conditions activate or deactivate them. All the spawner scripts now only check spawn rules by name. Spawners just ask: can I spawn the thing attached to rule X? They don't know anything about what makes rule X active or inactive.
For example: the Mountains spawner just checks if the spawn rule "Mountains_BootyLineupLadyCritters" is active, to see if it can spawn the group of lady critters. It doesn't need to know anything else!
I'm currently cleaning up what data gets stored in the savestate, and writing new code to keep Conditions in sync as data changes during gameplay. There's a lot still to do, but I'm closing the gap fast.
IN SUMMARY
- Scripts (especially spawners) are a lot more stable and don't need to change much when we add new story content.
- The "flow" of the game is completely moved into to the database where it can be efficiently organized.
- Now I've got a ton of nifty switchboards where I can tweak rules and conditions to control when and where our story content can play.
This is a pretty huge (but much needed) design overhaul! :O Once I'm done with code cleanup and playtesting, we're looking to post a build so we can get this in front of yall and finish squashing any related bugs. Whenever stuff's good to go, I'll be diving back into Act 3 and continuing our main story with further shenanigans in the Deep Woods!
---
Back to Carrot:
WHEW~! That's a lot~! But super necessary stuff for how modular we want the end-game stuff to be. It'd be good for y'all to be able to replay a quest whenever, instead of like, redoing the whole game to see something lol. The paradigm of stuff was really tricky to figure out, but Vixel's on it!
I did a bunch this week too but info overload lol. I'll post mine in the next update soon!
Comments
Sprink
Really appreciate the insight into your coding process, that was a really cool read. Well, at least for a mechanic like me it was.
Jack_Wolfe
Thats such a nice layout of a plan, its awesome seeing you tackle these game dev problems and finding solutions.
VGR
Who’s in the sketch?
wolf
I am fascinated by all this, how professional your work is.
Gashren
Mabel Spawning: Maybe, instead of checking conditions one by one each time, you should just add a public boolean field isSpawn (I guess to the Mabel class?), and set it to true/false depending on the circumstances? That way SpawnMabel would only have to check if the field value is true, and the other methods (for example, the one responsible for starting conversation), would be responsible for setting the field value. Would probably need some refactor in your code, though.
