#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!