These kinds of games are heavily scripted, requiring a team or a lot of persistence spanning a long while.
One method not highlighted by others and easier to understand based on choices can be seen in SHADOW THE HEDGEHOG (2006) which uses a linear progression system moving the player down different storylines based on which goal(s) they achieved in the level. This method of choice-based narrative requires less data saving directly, just linear teleportation and sequencing (can be achieved with ROBLOXâs Universes System).
The method youâve shown - choices communicated through interaction (or lack thereof) - requires the data-saving method extensively throughout the duration of the game world. Others have communicated using modulescripts and remote events as the player progresses. You have to have more planning with this route and need a stable, organized means of structuring the player save data so that you can easily find the choices the player made at certain intervals or in chapters/levels. An example format:
-- Data Table
local PlayerData = {
-- Game Chapters as sub-tables
Chapter1 = {
InteractedWithNPCA = false,
InteractedWithNPCB = false
},
Chapter2 = {
CompletedNPCATask = false,
CompletedNPCBTask = true
}
}
-- Side note here: The InteractedWithNPCB and CompletedNPCB task contradiction is intentional.
-- It could be useful doing a dual-check in the event a player *can* complete a goal or meet a condition without ever meeting the starting conditions, if that's a part of your game design.
return playerData
Itâs likely this would be used by NPCs or triggers to check you meet conditions before allowing you to go forward in the storyline or to the next area in the level/world. These are also fairly closely related to Questing Systems, which is something that you should look at further than just the following example (especially look at how other games handle quests under the hood).
I do go on a tangent about this so fair warning beforehand.
Questing System Tangent
My favourite example of a questing system is how Bethesda handles quest data in Creation Engine titles through a Dual-ID system - Form ID and Editor ID. An Example Quest from one of those games being âFollowing in His Footstepsâ - a Main Quest in Fallout 3.
A positive to this system is that itâs easy to check which quests the player currently has unlocked and which one(s) theyâre progressing with. Thisâd be done via storing a table in player save data for the Quest IDs theyâve unlocked, storing a table for which oneâs focused and the two sets of Quest Co-ordinates for the Map HUD and World Location.
Representative Table for âFollowing in His Footstepsâ
local Quest = {
-- The key for the table being the hexadecimal "Form ID" above.
["00014E87"] = {
EditorID = "MQ01",
-- Main Quest 01
-- fun fact: it's actually the fifth main quest but it's likely the ID was assigned based on it being the first designed/intended quest.
QuestName = "Following In His Footsteps",
-- Quest Name for displaying on the User Interface
QuestSteps = {},
-- The list of steps, quest step lines (e.g. New Objective) and Conditions to:
-- A) Complete Quest
-- B) Move to Next Quest Step
-- C) If the player Fail the Quest Step
-- D) Next Quest Location (map co-ordinates for in-world map [Vector3] (and/or Map UI [UDim2])
CurrentQuestLocation = Vector3.zero,
CurrentStepConditions = {}
-- Whatever Conditions the player needs to meet.
-- Maybe a function that you call on which checks specific values of the player inventory or save file?
-- May also have other functions to check if the player has prevented progression.
}
}
return Quest
This post likely will also need corrections. If you notice anything I missed feel free to reply to this or send a PM about it.