Post

Game Programmers - how do you build your campaign systems? I mean: The things that track and determine which doors are locked, the current phase of the moon, and whether or not the last insult you hurl at the grand wizard is enough to make them leave the dinner party. #gamedev #gameprogramming

6 reposts16 likes

what I would do is have one or more director objects, one for each quest at the start of a quest or when maps are loaded, the director goes around and tells doors and npcs, ok, you work for me now

Save blobs within save blobs. A blob for level alterations, a blob for NPC dialogue progress, a blob for totals, etc. Some common sense when dealing with NPCs as they can add and increment variables in the totals blob. Flattens any branching because go_last_insult will be at the top of the tree.

Ta. I guess it's less the "how do I store this" problem and more the "where do I put the decision logic responsible for modifying it". It's very easy to end up with changes that need to be atomic spread across a cutscene, for example, and then forgetting about it and making the cutscene branch.

I currently have actors declaring / incrementing variables using their NPC scripts - which are basic state machines using said variables. They can also reload as different actors. I've not had too much trouble with cutscenes as deleting actors or renaming them usually solves problems.

save file lets me store arbitrary key-value pairs, every system has access to the current save file. most main progression in mew is defined in one data file which contains "unlocks" that consist of a trigger (ex "Beat caves with Fighter") and effects (ex "Unlock item, set flag, show popup").

I've seen a bunch of games just spray this logic absolutely everywhere, but that means for anything beyond very simple quest structures it's easy to introduce progression blocking bugs, you can't map possible game states and routes for analysis, and the only way to test is to play the entire thing.

I previously built a little IF prototype that uses rules (actually just nested ifs) to select available affordances which then modify the game state and... I really like building with it. All the logic is in one spot, I can click through a playthrough super fast, and it should be automatable.

I guess my question here is - should I push all my campaign logic through something like this or am I overthinking it? Right now I'm building an action RPG and testing and setting campaign state on individual doors, NPCs, pickups etc, and it feels extremely fragile.

The creator of unexplored has writted(/spoken) on how they managed to keep everything solvable and unsoftlocked. It's from a procgen standpoint. But no reason it wouldn't be applicable

I just bake my game state into save data, then map scene/system inputs/outputs so I can test them individually based on randomly generated saves. If I can load into a scene or run a system while missing something essential, then I add a sanity check and figure out where my state model broke.