This post is concerned with the structure of quests as it appears in video games. I'll present a conceptualization of questgraphs in The Witcher and will then continue to write down a specialized system for my game jam project Mikratheus.
The Structure of Quests in Video Games
The following abstract description is heavily based upon the radish quest editor documentation (Link) and the REDkit wiki entry to quest editors (Link). However, when looking at other games one finds that the overall structure is mostly the same.
Let's begin with my quest definition of old:
A quest is a series of connected events and goals, where subsequent event(s)/goal(s) are only revealed, when previous goal(s) have been reached or some event has happened.
With these words I tried to grab my intuition of a structure annotated with events and goals which is (usually) defined in the unplayed game and followed - experienced - by the player while he navigates the game world (which doesn't have to be a space).
We'll see, whether this intuition holds against the irresistible truth of practice. Here follow (slightly adjusted) quotes from the above mentioned docs:
"A full radish modding tools quest definition is more than a questgraph: it contains definitions for multiple, different game aspects (e.g. layers, communities, journals, etc.).
the questgraph [..] ties all these aspects together by controlling when and what asset is used in the player's quest progress"
More specific, on questgraphs and routes:
"A questgraph represents the possible progression of a quest by defining one or multiple static routes for a "signal""
"Routes are defined by directed connections between quest blocks."
Any route has to begin "in one globally defined startpoint" and end "in one globally defined endpoint".
End conditions:
"If the signal reaches any endpoint (no matter what route it took) the quest is finished and no further evaluation of the questgraph is performed."
Quest blocks and signal flow:
"There are different types of questblocks: some can trigger specific game actions, query information, pause the signal until conditions are met or initiate some other block-specific task."
"Multiple connections can point to the same block: no matter from where the signal originates a signal visiting a block triggers always the block-specific funtionality."
"However some blocks (e.g. subsegment-blocks, scene-blocks, ...) may define multiple different input- and output-sockets (called in-socket and out-socket) and behave differently depending on which socket the signal arrived."
"If the block-specific action does not pause the signal until some conditions are met it immediately exits the block and continues on its route. A signal exiting a block may branch and point to different blocks at once. In this case the signal continues in parallel to all the blocks the routes point to at the same time."
Summary:
"It is based on the idea that there is a signal, which starts in one place (Start
block), proceeds through connections between blocks and starts multiple
actions in the process. Signal can be diverted between multiple
connections, which means that it can be in two or more places
simultaneously. When any signal reaches End block, the whole quest ends killing any other signal that may still be going inside."
 |
| Image of a quest made with radish modding tools. |
Looking at my definition, I see that it originates from a player view. I feel like it would fit this technical view more and more if one added some contextual definitions/statements, because the current view - even though it captures all aspects - had to be formulated in a generic way and depends on a specific assignment of meaning to the words used.
I'll continue with a concrete questgraph design made for one of the games I participated in.
Further Reading / Inspiration
- Raddish Modding Tools on making simple Quests for The Witcher 3: Link
- Quest Design with the Creation Kit: Link
- A Video that makes you optimistic regarding the easiness of Quest Editor Usage (REDkit for Witcher 2, in this case): Link
- The mundane REDkit wiki catches the pragmatics of this field much better: Link
A Quest-System for "Mikratheus"
Mikratheus is a small god game, in which you play a god sitting in front of a computer, doomed to manage his followers. There are different planets on which he's got those, and every now and then a prayer for help pops up. He may the decide whether he has enough ressources to help, or if you wants to decline but possibly loose some followers. If he doesn't do anything about a plea, then he quite probably looses a lot of follower. It is thus essentially a game of balancing.
Instead of displaying pleas randomly per planet, a progression in pleas shall get in place. To get some variety into the playthroughs, every node contains a pool of pleas from which one is drawn when reaching the node.
The decisions per plea may lead to different nodes, so overall we've got a signal based quest system quite similar to the one above.
Central to the system I created is the event pool. It corresponds to abstracted quest blocks in the description above. An event pool is a node in the quest and contains possibly several events.
The basic unit of this system is the event, containing informations on the endings to which this event may lead, a list of nodes/event pools to which an ending might lead, a field to inscribe the event's "felt" intensity (it is planned to do some automatized selection of events based on an ideal pacing graph) and a reference to the parent quest. Events, too, correspond to quest blocks, and also contain the connectivity informations.
The quest class itself holds all pools and their event and manages initialization, event fetching and update, which can be summarized as progressing in the quest. Nodes/event pools, where the signal is, are marked as active and are hold in the currentPoolsQueue. Currently happening events are hold in currentEvents. When an event is updated to an ending, then the event pool belonging to that ending is added to the end of the currentPoolsQueue. When a new event is requested, an event is chosen from the first (= being the longest in the queue) event pool in currentPoolsQueue.
In the game, I let a class Plea derive from QG_Event and add three endings: "accept", "deny", "timeout". When a player hits e.g. "Accept" for a plea, then a method is called in Plea which updates the follower informtions etc. and calls an EventUpdate for this event on the quest it is assigned to.
In another place, the NextEvent method is called, whenever an apropriate amount of time has passed by since the last plea.
Ideas for Feedback
- Do you think my quest definition would fit to the technical description when contextualized? If so or if not so, why?
- Where could the system I designed be improved by "typical" quest features?
Conclusion
As the recurring reader might notice, this post didn't contain much of the much loved (by me, at least) theoretical rambling on my behalf, even though it would've been a very convenient opprtunity to do so. The reason why this could happen is two-fold, and invites for some thoughts:
- the words I found on this topic were of such kind that I couldn't have said them (much) better
- thinking of and writing down such ramblings is rather time-intensive in relation to the rest
Looking at the Witcher and Mikratheus quest system I am reminded and grounded in what quests are (literally!). Quests offer the opportunity of progression in a partially pre-defined series of events and goals.
Well, I'm sure there are yet some other quest definitions to come.
Until then - have a good time!
No comments:
Post a Comment