Quests as inventory items

[piqey]

• The item can be traded
• Quest progress is tracked on the item
  • Carries over when traded
• The item has an expiration date, so players can’t hoard the same type of quest over time and complete them all at once
• Encourages trading
  • Players prefer specific quest types
  • Players can obtain multiple of the same quest type via trading, to complete them at the same time
  • Quest items with a lot of progress are worth more
• Different rarities of the same quest type, each rarity having more requirements and higher reward

See below

[piqey]

Quests (sub-roadmap)

• Quest Objectives

  • [ ] Item Collection
  • This can be simple collection quests (e.g., gather X amount of a specific item) or scavenger hunts where players need to find a specific list of items in a certain area or throughout the map
  • We would need to be careful with this objective, as one of the principles we're rolling with is that changing Zombie Survival gameplay is bad, but only adding on top of it is good
  • [ ] Player Interactions
  • Have quests that require players to interact with each other in different ways
    • Trading certain items (even the Quest item itself), teaming up to complete a challenge or even engaging in friendly competition
  • [ ] Kills
  • Classic kill quests can also work well, especially in a zombie survival context
  • These quests could vary from killing a specific number of zombies, killing zombies with a particular weapon, or even killing a special, stronger type of #zombie
  • [ ] Exploration
  • Encourage players to explore the map thoroughly by placing objectives in hard-to-reach or hidden places(?)
    • Again we raise the problem of affecting the normal Zombie Survival gameplay, but it's worth brainstorming around the idea
  • Visit a specific set of maps, do a specific thing on a map a specific number of times, visit X unique maps
  • [ ] Survival Challenges
  • Set challenges that require the player to survive under specific conditions, such as:
    • Without using certain types of items or weapons
    • As the last surviving human (escape after wave 6 when all other humans died before escaping)
    • This should only work if there is at least 3 or 4 or 5 other "human" players in the game (not bots), discuss number later
  • [ ] Cading
  • Require questers to successfully use specific props, e.g., couches, bedframes, etc. in their cades (track this by how much damage they cumulatively blocked with that prop)
  • Require questers to use props with specific material surface properties such as Wood_Box/Wood_Plank/Wood_Panel, Metal, Plastic, Rubber/Rubbertire (these would be grouped together under more general titles, the games released in the Orange Box had many surface properties exclusive to one game only and their usage varied)
  • Require questers to repair a set amount of prop damage
    • The problem with this one is we don't want to influence player behavior on a server-wide scale; the blend between players doing DPS and players building and maintaining cades is vital to making it past wave 6, so we might want to place limits on how quickly or how easily you can complete this one

• Quest Generation

  • When it comes to combining quests procedurally, the key is to design a system that allows for a mix and match of various quest objectives while still maintaining a coherent storyline or theme
    1. Quest Objective Pool
       • Create a pool of small quest objectives from the above categories
       • Make sure these are general enough to be reusable in various quest lines but specific enough to add unique flavor to each quest
    2. Rarity-Based Scaling
       • The rarity of the quest can be used to determine the number, difficulty, and type of objectives
       • A common quest may have only a few simple objectives (kill 10 zombies), while a rare quest may include multiple objectives of varying difficulty (kill 50 zombies, collect 20 rare items, survive for 10 days without a certain type of weapon)
    3. Objective Linking
       • Develop a system where some objectives can only appear after other objectives are completed
       • After killing a certain number of zombies, the next objective could be to collect a rare item that is only dropped by the killed zombies
    4. Randomized Rewards
       • Randomize rewards based on the quest's rarity and objectives
       • This not only makes each quest feel unique but also gives players a sense of unpredictability and excitement
       • Give rewards related to the procedurally generated objectives in that Quest instance

• Implementing Objectives

  • There's a general way we ought to do this

    1. Data Structure for Quests
       • The Quest item class ought to hold its name, description, list of objectives, reward, rarity, and status (e.g., in-progress, completed)
    2. Storing Progress
       • For each quest that questers own you need to store the progress for each objective
       • This can be a simple counter that is updated whenever the player takes a relevant action
       • This data must also be stored and loaded as players leave and join the server

    3. Event Hooks

       • You'll need to hook into various game events to track quest progress
       • Take a quest to kill 100 zombies for example; a quester kills a zombie and an anonymous function generated by the Quest item instance hooked to GM:HumanKilledZombie compares the killer to the player directly (no iteration, just equivalence unique to that particular anonymous function) and calls whatever functions necessary to reward quest progression and eventually award quest completion
       • This would decrease load on the server significantly when there aren't any active quests, and load on the server when there is multiple live Quest instances would decrease as individual quests are completed
         • It might also be worth looking into the gmod_lanes module and its potential for multi-threading server-side components of the project
       • For performance, I don't think we should approach this situation by hooking into the game at runtime and consequently waste time indexing or looping through large tables/arrays like player.GetHumans every time an important game event happens

       • We should use the IHookMixin module or something similar to it to both add and remove those hooks as anonymous functions on a per-quest, per-player basis to avoid looping through tables any more than they historically have been

         @piqey's opinions

         For a `Repair` ***`X HP`*** `in prop damage!` quest, the anonymous functions would be something like this: ```Lua local quest -- (Quest) The quest object hook.Add("PlayerRepairedObject", [...], function(ply, _, repaired, _) if ply == quest:GetOwner() then quest:AddProgress(repaired) end end) ```

         ---

         Too random, and the quests can feel disjointed and meaningless. Not random enough, and players can feel like they're just grinding through similar quests. Good luck!

         Additional thoughts

• [ ] Streak Quests
  • Maybe there'd be quests that are always tracking a particular action and resetting if you did another action
  • Survive 10 games without using a Tier 4 weapon, or Survive 3 waves at Lighthouse without taking damage
  • These quests would be constantly updating their counters; as soon as you no longer match the criteria, their counters would reset to 0 and the quest would lose its existing progress