#19 Quest Structure, Definitions & Mikratheus

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

In a sense, this is a way for me to provide some theoretical perspective without having to delve spend too much time on that - which is exactly the point of this project to begin with and which has been difficult for me at times. I simply like to re-think things when they seem flawed to me. On the other hand, I'll probably not often have the luck of finding such gems, where I don't feel the need for adjustments.

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!

#02 On Unplayed Games (and Stardew Valley)

The following has been decided by the high council of decision-makers (me): We shall examine the difference between the computer game as (almost) unchanging object and its running form, where it is played by a player. The investigation is continued in order to see how quests are related to this matter.

In the second part, behold! a quest design for Stardew Valley will be created. A wonderful thing to start with in 2021, I think.

But first, a little discussion of feedback.

Feedback and its Implications

Three short notes were given to me. The first was concerned with gameplay: Seeing post #00, they were concerned that I might forget the rule-mechanisms when designing quests/theorizing about them. Another point was on NPCs and how they have the potential to take on an important role in a quest.

In the last post I stated that computer game quests have two core elements (events/goals), which are defined based on the game world and possible player actions. So gameplay and NPCs will definitely have a place in my constructions.

The last note was a hint for doing game world design: To think about three differences between your game world and everyday life. I will keep this note in mind and pick it up in a future post on game worlds.

Unplayed Games

We are now discussing the difference of an unplayed game in opposition to a game as it appears in the process we call "play".

The unplayed game is an object in physical reality. An unplayed board game usually is a collections of atoms: a box with a board, pieces and a booklet consisting of written words within. An unplayed computer game might be a specific configuration of an electrical circuit in a computer's hard drive: There usually are several sections of programming code, maybe some textures and audio files. An unplayed child's game might consist of neural representations in the child's head (I don't know enough here) and other objects in reality: The rules are known by the kid and maybe a ball and other children are also a part.

Several (more or less interesting) remarks can be made:

1. An unplayed game does not have a player.
   Even though there might be a person that interprets or knows it, an unplayed game is not played.

2. An unplayed game is interpretable as a game.
   In particular, it has to be possible to obtain knowledge of the context and rules which are needed to play the game.

3. In order to be played, next to an unplayed game and a willing player further physical set-up might be needed.

4. An unplayed game is carried by a physical medium.

5. An unplayed game is usually authored by the game designer.
   Whether the played game and the corresponding player experience is also (in parts) authored by the game designer - on that I will write another time. 

An unplayed game is made of instructions and data. I am not yet entirely sure how to describe both properly, but I'll just give it a try here anyway. Procedures are series of instructions, where each instruction determines what should happen when it is executed. Data is the plural of datum, which can be seen as a sign that is interpretable to human, animal or computer.

Funnily enough, every procedure can be data, since all procedures may be input for another procedure. However in many procedural languages, not all data is a procedure: There is no way for the number 42 to be interpreted as an instruction in, say, the C programming language.

Now, how do quests relate to this?

Quests in Unplayed Computer Games

In the last post (#01) I defined quests as collection of interdependent goals and events. As this writing evolves, I notice that the word connected should be added. Otherwise we could take random interdependent events/goals from different interdependent quests and call this new collection a "quest". By requiring a connection I thus mean that the quest is interpretable as a connected series.

If a quest is part of a computer game, how then are its goals/events and their dependencies and connections represented by procedures and data?

Goals. Since goals are only in a player's head, they aren't actually part of the unplayed game. Instead, a game has things of interest to the player in it and sometimes even concrete proposals, which the player adapts as goal. These "things of interest" I call goal-inducers.They are mostly data constructed by procedures (e.g. a marker played on a map).

Events. With events I mean anything player-perceivable that happens on the side of the game while it is played. Events, like goal-inducers are data constructed by procedures: If a NPC enters a room, then this is a complex construction of visual data by procedures.

Dependencies. The dependencies between various goals and events are essentially encoded as data in some way: One might imagine a data structure in which the changes made in the game world are listed in a linear order.

Connections. How do events/goals feel connected? I think this is mainly due due to spatial/temporal/logical closeness. Whereas spatiality and temporality are created by the execution of the game's procedures, logical connections are based on the semantics of the created game objects.

I come to the conclusion that quests are in large parts defined by the manner in which the game's procedures construct game objects.

A "Stardew Valley" Quest: A Beautiful Garden

Now to a good game: Stardew Valley. I had the following in my mind: A small quest, which is more than one of the many collect and deliver missions. Thinking of the game's peaceful atmosphere and remembering a quest very dear to me (Be it ever so humble...) I wanted to devise an mid-end-game quest that is about creating a wonderful garden and inviting someone there.

In accordance with The game's rather simple missions, I had just a few goals and events in mind:

1. After some play-time in the same world (maybe 150h?) and after the completion of some beginning quest chains the quest simply appears in your journal. (To symbolize a time of resting after many years of hard work.)
2. Goal 1: Have a bench directed westwards, 20 adjacent flowers, 20 adjacent vegetables, two fruit trees and water in your garden.
3. Goal 2: Invite someone dear to you into your garden. (NPCs with a good relationship to the player can be asked.)
4. If invited, player and NPC are teleported to the player's home with the NPC walking to the bench and sitting on it. Time of day is set to afternoon.
   
5. Goal 3: Sit on your bench and watch the setting sun.
6. If done, the camera switches into a view where the bench is seen from behind, with the sunset in the center. Avatar and NPC talk about the happenings so far and fall silent. A gentle music is played and while the sun vanishes, the image fades out.
7. It is close to midnight, the NPC is gone. There is no further quest reward.
   

I wanted to create a gentle atmoshpere, in which resting and creation of beauty is possible. Since I do not have enough time, further exploration of this idea shall be delegated into the future.

Ideas for Feedback

• Does my concept of an "unplayed game" make sense to you? Where could it be improved?
  
• Should I maybe not teleport player/NPC in my quest design?
  

Conclusion

Exploring what "unplayed games" are in relation to their played counterpart was indeed interesting to me. I think it is an important concept if one intends to understand at which exact point the various stakeholders have influence on the play experience.

My attempt to place quests in the unplayed game showed that my definition of quests approaches the term from a playing perspective: The words "event", "goal" and "connected" all describe things the player perceives. It furthermore showed, that just having the unplayed game in front of you usually won't help much when you want to understand its quests: While the ordering of events/goals might be found somewhere as a data structure, the goals and events themselves are deeply rooted in the game world, which is typically generated by procedures and thus not easily readable when just looking at the unplayed game.

I am very fond of my quest idea for Stardew Valley - I always felt a lack of more cohesive, connected quests in the game. However I clearly spent to much time on the theory part of the blog, which is why my quest design did not get the care it needed. I aim to change that - after all this is mainly about designing quests, not building theories!

With these words I shall end this post.

I wish you a pleasant day and hope to see you another time!