Missions and Quests FAQ

Jump to: navigation, search

How do I add missions/quests to my game?

The engine itself does not have a Quest/Mission system, as it is something that you implement supporting the capabilities your game design requires The Hero's Journey Quest system (which you see in your evaluation world) is incredibly powerful and flexible allowing for the creation of virtually any imaginable quest all through a series of GUIs.

However, the HJ Quest System achieves that power by tying into countless game specific systems (i.e. systems that are specific to Hero's Journey):

   * Creatures
         o AI
         o specifications
         o spawning
   * Items
         o Treasure List Specifications
         o Item Specifications
   * Abilities
   * way of specifying "locations" of interest
   * use of the Area States System for many of its game objects
   * Combat
   * the way HJ manages areas
   * Story Tokens (the way HJ tracks quest progress and generic events of interest in a character's development)
   * etc

Since it is not part of HeroEngine, there is no documentation available for it.

How would I persist the state of a quest for a user?

By using:

   questNode as NodeRef of Class MY_Quest = CreatePersistedNodeFromClass("MY_Quest")

in MY_QuestSpecClassMethods

A persisted node will be persisted in the database, however there is an important additional step involved if you want to load that node (for example when the character loads, it probably makes sense to have his quest information load too). You must associate persisted nodes to a valid root (account, character, area, arbitrary root node) via a hard association (generally "base_hard_association") for that node to load with the root.

See: Data storage options

If you are using the area root node as the "owner", it is important to ensure your persisted nodes are being added in the edit instance....as play instances do not persist changes.

If you fail to associate your persisted node to a valid root node, the node is persisted in the database but HeroScript has no way to take the database to load it into memory. This creates what we call a "orphaned" node, and you can run a database cleanup routine to purge them.

How do I implement a timed quest?

You absolutely should not send a remote call to update the client's display every tick of a server timer. There should be no need to send any more than a single remote call that initializes an object on the client (whether the GUI itself or another object doesn't matter) the client object can have a timer.

The server timer should generally be set up so it ticks a single time, when the quest is expired (i.e. fireRate = 3 minutes for a quest that has a 3 minute time limit). Additionally, depending on your design you may not need a timer at all since a timestamp (i.e. a datetime calculated by taking SYSTEM.TIME.NOW + 0:03:00.00) allows you to write a simple if check to see if when the client submits "completed quest" whether or not it was done within the time limit.

   if SYSTEM.TIME.NOW <= quest.expiresAtTime
     // success
     // failed, current time exceeded the quests expiresAtTime value

The recommended way to architect this would be:

   * Quest object is factoried from a spec and added to the player's collection of quests
         o Quest is "started"
         o questExpiresAt (datetime) is initialized to be SYSTEM.TIME.NOW + allowedTimeToCompleteQuest
         o either via a remote call, or by virtue of the quest object being introduced to the client via replication a client 
side object (I'd use the introduction of the quest object to the client personally) + timer started on client object, each tick raises an event + GUI control is instantiated and "subscribes" to the client object to recieve tick notifications o When "completed" is sent to the server, I would validate that the time had not expired based on the timestamp I had
stored. + If you want to be really nice, you might toss in a bit of slop to account for transmission latency client->server

If you expected to have quests with long term expirations hours/days/weeks etc, you should instead use a timer set up to expire based on experienced "gametime" rather than "realtime" (timers have a property called (realTime).

Personal tools