Building A Quest System: Tracking A Player's Progress

[KeeperS Karu]

Heyla! So I'm working on making a quest system. The idea is for the User to write their story, then put the essential narration and dialog on a notecard, then have the script take what's written to output a fun quest for the Player to enjoy. The features that the system currently have are:

1) Branching dialog based on User notecard input
2) The ability to receive an item and xp
3) The ability to perform a difficulty check
4) The ability to switch to a different notecard if needed (useful, for example, if the player opens up a whole new subquest during the conversation)

Now, I'm hoping to add in the ability to track quest progress. I'm a bit stuck as to how to approach it. Here's what I have so far:

The main quest system script: https://pastebin.com/X2Q5FRkd

The sample notecard: https://pastebin.com/F3JSfwKu

The quest system is meant to be largely self-contained, with very little needed from the Player's HUD (the HUD houses the Player's stats, performs the actual difficulty check rolls based on messages sent from the quest system, accepts input from stat-altering items/objects, and can accept and deal melee damage to other Players and NPC monsters). I want the system to be as independent of the HUD as possible. As in specific quest data should not be needed of the Player's HUD. Instead, it should only ask for difficulty check rolls and alter stats based on events from the quest (such as adding xp or healing the player, etc.). All the tracking of quest progress should be performed within the quest system itself

The reason I want it this way is because I want people who play my game to be able to write their own quests for it. I can't account for each and every game everyone makes. Instead, I can make the quests account for themselves. The basic idea is this: The Player runs through the quest. The Player completes the quest. The Player receives rewards from completing the quest. The Player also receives a "Quest Completion Trophy." This trophy is not just for decorating your home with. Instead, they're meant to communicate with any future quest packs that the Player has successfully completed a previous quest, if completion of a previous quest is required to play the current quest.

I'm thinking the system will eventually be designed so that there's a main quest controller. This quest controller then communicates with the other objects in the quest, whether they be NPCs, Mobs, or objects you can interact with, and keeps track of Player progress that way. So, I'm thinking the script I've written so far might not be the controller script, but rather, just an NPC script. I've been so focused on the NPC interaction script that I didn't really think about the quest controller script. But I'm not certain how to even go about designing it.

Hoping you all might have some ideas I can work into this. Maybe it's because of the late hour that I'm writing this, but I'm drawing a blank.

 

Thank you in advance for all your help and advice,

KeeperS Karu

[KeeperS Karu]

Chatting with a game dev friend about ways to approach the tracking of Player progress. So the simplest type of quest to implement is the fetch quest: where the Player has to go and collect items or kill a certain number of monsters in order to progress in the story. So with this in mind, we would create an item object that communicates with the main quest controller that it has been clicked or otherwise interacted with by the Player. The quest controller receives this message and notes this, and it flags the event has having made progress towards the quest objective.

Making the item would be simple. It would just be an object that, once touched, sends out the message to the main quest controller that it was obtained, then it destroys itself.

In the main quest controller, I'd need to make a function. An ItemCollected() function that is called when it receives the message from the quest object. This function tracks the number of objects that send out the "Player interaction" message. When the appropriate number is reached, it flags the quest as having been completed.

Now, it should be able to have a number of fetch activities active at once. The User would need to use the notecard to enter the number of quest objectives, the names of those quest objectives, the variables for those quest objectives, and the number of items collected that the Player needs to reach to clear the objective. It can use a system similar to what the branching dialogue uses, or even make direct use of the branching dialog system. It uses the various slots to store information needed about the quest objectives.

When the notecard is initially read, it takes that information. Then, when the player accepts the quest, the quest is flagged as having been started by the Player. Basically, the player chooses the "accept quest" option in the dialog, and the quest acceptance flags true in the main quest controller. When the quest is flagged as "complete," the rest of the dialog continues. I think I can manage this. I'll think about other, more complicated quests once I've got this simple setup set up.

[Mr Amore]

From my observation, there's a high demand for them but very few quest, inventory and progress tracking systems in SL. Because it seems simple enough on the outside but once you get started these are complex systems. All I can offer is some general advice,

Start with a design document today, I cannot overstate the importance of one. During the documentation phase you'll visualize the system from a different perspective, it also brings fresh ideas to mind which you may not have considered whilst coding. Here's a brief overview.

Stay flexible, everything you've written today is liable to change at the midpoint, and again at the end. Build working elements first, then optimize.

And you may benefit from storing players' progress in an SL Experience, it's preferable to have a central store than depending on the player's HUD.

[KeeperS Karu]

8 hours ago, Mr Amore said:

From my observation, there's a high demand for them but very few quest, inventory and progress tracking systems in SL. Because it seems simple enough on the outside but once you get started these are complex systems. All I can offer is some general advice,

Start with a design document today, I cannot overstate the importance of one. During the documentation phase you'll visualize the system from a different perspective, it also brings fresh ideas to mind which you may not have considered whilst coding. Here's a brief overview.

Stay flexible, everything you've written today is liable to change at the midpoint, and again at the end. Build working elements first, then optimize.

And you may benefit from storing players' progress in an SL Experience, it's preferable to have a central store than depending on the player's HUD.

Thank you, so much! I will definitely keep this in mind as I work through things! I've never messed with SL experiences before, so I'll have to look into them. Though, the way I have things set up, the central store is the NPC script, itself. The HUID only makes the rolls for the difficulty checks, and the NPC script sends out information to the HUD if stats need to be altered.

 

I am actually pretty much done with the basic quest system. I thought I was completely done, then realized I needed to put in a feature that let's people replay the quest if they want to. That should be simple enough. On touch at the end of the quest, reset the scripts. Oh, whoops! One other feature! Checking for quest prerequisites! Gotta put that in, too! Shoot. I wrote those down in my notes, and I still completely forgot about them. lol! Oof! I see what you mean about a formal Design Document! I think I'll need to make one so I can more easily figure out what I need and track what's been done so far. lol!

Edited November 21 by KeeperS Karu

[Quistess Alpha]

15 hours ago, KeeperS Karu said:

On touch at the end of the quest, reset the scripts.

That's another disadvantage of adding things 'piecemeal' without considering the whole system. If you implement one feature one way, like resetting the scripts, that may make it much harder to implement another feature (ex. if you want multiple people to be able to play the quest at the same time, what if one person finishes first and that destroys the other person's spot in the quest.)

[KeeperS Karu]

6 hours ago, Quistess Alpha said:

That's another disadvantage of adding things 'piecemeal' without considering the whole system. If you implement one feature one way, like resetting the scripts, that may make it much harder to implement another feature (ex. if you want multiple people to be able to play the quest at the same time, what if one person finishes first and that destroys the other person's spot in the quest.)

Yeah. My friend is going to help me write a GDD this Saturday. He's going to school to be a game dev, so he's heavily familiar with writing GDDs. He says he's going to help me make one, and hopefully, I'll be able to figure out what all I want as a whole for it.

 

UPDATE: I just tested my system with another person, and it looks like it isn't possible for more than one person at a time to enjoy the quest. That is, it looks like if one person clicks the NPC object and gets to a point, another person clicking the NPC object will be at the same point in the quest, rather than starting the quest, themselves. Which is fine for people playing it as a group, but if people are playing it individually, that might be an issue. Is there a way to set it up so that multiple people can play it without interfering with the others' progress?

Edited November 21 by KeeperS Karu

[Mr Amore]

There are multiple methods, in your particular scenario you could make use of Linkset Data (aka LSD).

In any case, the 'NPC object' must keep track of all players and whether they're part of a group. Then players need options to manage their groups to invite or remove players. And also whether they're agreeing to join or leave a group. Standard MMO grouping features.

As a group or individual makes progress through the quest, the NPC object can create a profile for them in the LSD and update their status.

Learning llJson is helpful too for communicating between objects and storing to LSD.

[VenKellie]

you should use a database outside of SL to store player progression which requires llHttpRequest and the http_response event.
If you know PHP i say use Laravel php framework with Mariadb or the default Sqlite3.

Edited November 22 by VenKellie

[KeeperS Karu]

Yeah! I'm having a lot of success with Linkset Data! Still a few bugs to work out, but I'm making progress.

[KeeperS Karu]

On 11/21/2024 at 4:43 PM, VenKellie said:

you should use a database outside of SL to store player progression which requires llHttpRequest and the http_response event.
If you know PHP i say use Laravel php framework with Mariadb or the default Sqlite3.

Thank you for the suggestion! I'm looking to set up the quest system so that it's not reliant on an outside database. That way, I don't need to pay for the costs of maintaining this database. Also, people can still write and play quests should I be unable to maintain an outside database any longer.

[KeeperS Karu]

Well, then! I seem to have accomplished my goal of allowing multiplayer capability! Each individual Player can now click on the quest NPC and go along their own routes without disturbing the progress of other players. I've also set up the system so that, instead of resetting the scripts to allow the Player to replay the quest, it simply uses the LSD to set the Player back to the starting line of the starting notecard. Everything seems to be functional at this point! I'll be working with a friend later today on a formal GDD so that I have a better, clearer idea of what I want out of the quest system. That way, I don't have to play the "Oh, I forgot this feature!" game that I've been playing the last few days. I'm looking forward to getting the GDD done and figuring out what further features my quest system needs.

 

I'm learning a lot from this project, and despite the hiccups, I'm quite enjoying myself! Thanks to everyone who's lent a helping hand in this, and to everyone in the future who will lend a helping hand!

[Nexii Malthus]

By the way, since you are using notecards, one interesting property of reading notecards is that you can read them as long as you know the UUID of it, it doesn't have to be in the inventory of the prim.

 

For example this might allow you later on to expand on this system, such as making a quest tracking hud for players and all you'd have to do is pass along the notecard UUID and progress.

 

Likewise this might even be setup in a way that can allow a quest to pass through multiple NPCs, by just sharing the notecard UUID with them automatically as the player goes around, without having to install the notecard on every NPC involved or find some other complicated way to transfer all the information (such as big JSON-based listen messages).

[Qie Niangao]

2 hours ago, KeeperS Karu said:

Thank you for the suggestion! I'm looking to set up the quest system so that it's not reliant on an outside database. That way, I don't need to pay for the costs of maintaining this database. Also, people can still write and play quests should I be unable to maintain an outside database any longer.

Very wise, even ignoring the (small) costs of database hosting. It's always so grim when a whole system dies just because nobody's paying the storage bills anymore. In theory the same could happen to Experience storage when the owner's Premium subscription expires but I doubt that ever actually happens as long as the storage is in active use.

The point of using Experience storage is that it's pretty huge by SL standards, plenty for keeping concise progress records for thousands of players. It's available to scripts grid-wide so the quest could even have outposts across multiple regions, and uses simple key-value pairs same as linkset data. The big difference is that access is asynchronous: results come in dataserver events instead of being a function's direct return value, which complicates the code. Also, sadly, no regex key query capability that can be so handy for linkset data.

[KeeperS Karu]

2 hours ago, Nexii Malthus said:

By the way, since you are using notecards, one interesting property of reading notecards is that you can read them as long as you know the UUID of it, it doesn't have to be in the inventory of the prim.

 

For example this might allow you later on to expand on this system, such as making a quest tracking hud for players and all you'd have to do is pass along the notecard UUID and progress.

 

Likewise this might even be setup in a way that can allow a quest to pass through multiple NPCs, by just sharing the notecard UUID with them automatically as the player goes around, without having to install the notecard on every NPC involved or find some other complicated way to transfer all the information (such as big JSON-based listen messages).

Oh, my goodness! I didn't realize that! That's definitely a feature worth considering! Thank you for pointing that out!

 

1 hour ago, Qie Niangao said:

Very wise, even ignoring the (small) costs of database hosting. It's always so grim when a whole system dies just because nobody's paying the storage bills anymore. In theory the same could happen to Experience storage when the owner's Premium subscription expires but I doubt that ever actually happens as long as the storage is in active use.

The point of using Experience storage is that it's pretty huge by SL standards, plenty for keeping concise progress records for thousands of players. It's available to scripts grid-wide so the quest could even have outposts across multiple regions, and uses simple key-value pairs same as linkset data. The big difference is that access is asynchronous: results come in dataserver events instead of being a function's direct return value, which complicates the code. Also, sadly, no regex key query capability that can be so handy for linkset data.

Oh, I didn't realize that about Experiences! That's definitely good to know and something to consider, though I was told that a downside of Experiences is that a script has to be modifiable in order for it to incorporate the Experience? And I'm wanting to make the scripts No Mod. So, that's something to consider, too. But I like being made aware of all my options open to me. Thank you for making me aware of this! I might still consider Experiences if it's a database I can make use of!

[Qie Niangao]

18 minutes ago, KeeperS Karu said:

Oh, I didn't realize that about Experiences! That's definitely good to know and something to consider, though I was told that a downside of Experiences is that a script has to be modifiable in order for it to incorporate the Experience? And I'm wanting to make the scripts No Mod. So, that's something to consider, too. But I like being made aware of all my options open to me. Thank you for making me aware of this! I might still consider Experiences if it's a database I can make use of!

The confusion here may be that to distribute a script for others to use with their own Experiences, that script must be modifiable so the new owner can recompile it with their Experience. In your case, you'd be using your own Experience in the scripts so you can make them no-mod for anyone getting copies of them. 

In case it's not known, an Experience must be owned by somebody with a Premium (or Premium Plus) subscription. Scripters can be designated as contributors to an Experience without needing to own that Experience, but that means the owner must trust the scripter not to get them in trouble with some evil griefing script or something, and the scripter's code must coexist with any other contributing scripters' code using the same Experience. Of course, if you're a Premium member, that's all moot.

[Nexii Malthus]

It's also possible to distribute scripts compiled to an experience, but others won't be able to recompile it with the same experience unless they have the contributor designation. This can be useful in some usecases with an open system so that it is easy to see how the link messages, listeners, linkset data, etc all work while relying on a common experience database shared with others. I've encountered this once and it's really neat, since I was able to take the script and build a new display around the information it had (a SLMC Region Board which shows the activity of regions in the community, others have the script in their sim for their own displays and such).

[KeeperS Karu]

6 hours ago, Qie Niangao said:

The confusion here may be that to distribute a script for others to use with their own Experiences, that script must be modifiable so the new owner can recompile it with their Experience. In your case, you'd be using your own Experience in the scripts so you can make them no-mod for anyone getting copies of them. 

In case it's not known, an Experience must be owned by somebody with a Premium (or Premium Plus) subscription. Scripters can be designated as contributors to an Experience without needing to own that Experience, but that means the owner must trust the scripter not to get them in trouble with some evil griefing script or something, and the scripter's code must coexist with any other contributing scripters' code using the same Experience. Of course, if you're a Premium member, that's all moot.

Ohhhhh! Okay! That explains a lot! Then it's definitely something to consider in future iterations of this system!

 

5 hours ago, Nexii Malthus said:

It's also possible to distribute scripts compiled to an experience, but others won't be able to recompile it with the same experience unless they have the contributor designation. This can be useful in some usecases with an open system so that it is easy to see how the link messages, listeners, linkset data, etc all work while relying on a common experience database shared with others. I've encountered this once and it's really neat, since I was able to take the script and build a new display around the information it had (a SLMC Region Board which shows the activity of regions in the community, others have the script in their sim for their own displays and such).

Ooo! That does sound neat! Again, that makes it so that using Experiences in future builds is definitely something to consider.

 

So far, I have the following features in my quest system:

1. Branching dialog system

   1. Branching dialogs are a form of dialog that branches out based on Player choices. Basically, a Choose Your Own Adventure or Visual Novel-type of dialog system

   2. The User is the writer of the quest

   3. The User basically writes the quest on a notecard, then includes this notecard in the the NPC inventory for the NPC Quest System Script to read

   4. I was thinking of making a way to read the notecards via UUID, but that will make the script more complex that I’d like at this time; this might be a feature in a future update, though

   5. Instead, the notecards for the main NPC object must be No Copy notecards to keep people from being able to read the notecards. This also means that the main NPC objects will be no copy, no mod, no transfer for the final user. They’ll have to be careful with their copy of these NPC’s

   6. Should a NPC be accidentally deleted, a redelivery of the quest pack will need to be requested, either through the Marketplace or the Vendor System of the Quest Maker’s choice

2. The ability to give item rewards

   1. Item rewards bestowed on the player are common

   2. The quest system should be able to bestow item rewards to the player for successful completion of the item

   3. This normally serves as a reward system, but with clever use, can be used to bestow deadly consequences to the player, such as DoTs.

3. The ability to alter player stats

   1. The ability to alter Player stats is important

   2. Normally, this would involve simply rewarding the Player with xp (Fate Points in the TSOAT system)

   3. However, the User can alter any stat, from Hit Points to Armor Value to Attributes

   4. This is working as intended, giving the User a wide variety of options for their story

   5. This is the first instance where the Quest System interacts with the HUD

4. The ability to make difficulty checks

   1. This is the second and final instance where the Quest System interacts with the Player’s HUD

   2. Here, the Quest System determines, from the notecard, whether a Difficulty Check needs to be performed

   3. If it does, the System determines, through the notecard, what stat the Difficulty Check is for (Reflexes, Melee Combat, etc.), as well as the Difficulty Number to meet

   4. The HUD takes this information, makes the roll, and sends back to the Quest System the following:

      1. Whether the DC passed or failed

      2. And what NextLineID to go to based on the Pass/Fail status

5. The ability to change to alternate notecards in the inventory for the dialog system

   1. There may be a reason for the User to want to switch notecards depending on what the Player chooses in the dialog options

   2. This could be a side quest

   3. This could be an alternate storyline

   4. Whatever it is, the User might need to switch notecards, so a system is in place to allow for that

6. The ability to track Player Progress in Quest Objectives

   1. The system needs to track where the Player is at in accomplishing the Quest Objectives, such as how many items gathered, whether the NPC escorted is still alive, and how many monsters to kill

7. The ability to allow multiple Players to play at the same time

   1. Code for this allows more than one Player to click the NPC and have their own adventure simultaneously while another Player is having their adventure

8. The ability to reset the Quest

   1. This allows the Player to replay the quest

   2. Resetting the quest basically puts the Player back at the starting line of the notecard

   3. Quest Item Starting Numbers, that is, the Starting Number of the Quest Item to be gathered (for example, does the quest need three flowers total?), is reset automatically when the player completes the quest, so these Starting Numbers should be good to go the next time the Player resets the quest

9. The ability to look for prerequisites to the quest (quests completed)

   1. Among the items given to the player at the end of the quest will be the Quest Completion Trophy

   2. This is not just decorative

   3. Rezzing this no copy, no mod, no transfer item and touching it in front of the Quest NPC will send a message to the Quest NPC confirming that a required previous quest was successfully completed

   4. If the Player accidentally deletes this object, the Player will need to play the quest again in order to gain a new Quest Completion Trophy

10. Different quest item types: Reusable items and single use items

    1. Reusable items can be clicked any number of times to get a “copy” of that item

    2. Non-reusable items can only be used once, then must be reset by the main Quest NPC in order to be used again

11. Notecard Protection Feature

    1. Make notecards No Copy to prevent them from being read

    2. can read notecards from the UUID listed in a copyable notecard; this allows the objects to be copyable without worrying about the content of the notecards being stolen; creator should still make their quest notecards No Copy just in case

I'm working on the ability to rez enemies based on where the Player is at in the Dialog. I'm trying to figure out how to rez several of the same object at once.

 

=====UPDATE=====

So, I figured out using a for-loop was the way to go to rez several of the same object at once. After a lot of testing, I got the object rezzing feature completed! Yay!

Now, I'm trying to figure out what else is needed for this system. I can't actually be done, can I?

Edited November 24 by KeeperS Karu