Argax Project:: Dissertation: A Rough Draft Node

Node Status: COMPLETE

Scenes

Marlinspike leaves the details of scene content to the implementing game. As shown in Chapter III, a Marlinspike scene is little more than two functions: canPlay and play.

I initially considered a design in which a scene listed its preconditions as event objects to be matched. However, some scenes may have special requirements, such as requiring that a matching event occur only within the most recent three events. Additionally, some scenes have preconditions that are not event-based, such as a world or character state values. Since not all world state changes have a corresponding event in the event history, this approach would not work.¹ So I went with the simpler canPlay approach: Each scene is polled through a simple function call. The scene is then free to do whatever checking it needs to do within this canPlay function. This simplified Marlinspike, but left a lot of work to the game author.

Similarly, each scene is played by calling a single play method. These monolithic play methods often became very complex to author.

As far as Marlinspike is concerned, scenes are single events of no duration, much like an action. However, this is not true in practice of longer scenes, which might be comprised of multiple sub-events and even other sub-scenes. The first problem that arises from this is that any NPC action events used to represent parts of the scene's details are not executed until after the scene is complete. For example, if an NPC affronts another NPC at the beginning of the scene, the effect of that affront won't take place until after the end of the scene.

Also, sometimes scenes should take longer than a single turn to perform. For example, in Demeter, the exploration of a GoParty should perhaps take a number of turns equal to the number of deeds required of the NPCs to actually perform the exploration. Instead, their exploration happens in a single turn. On the other hand, sometimes it is desirable to be able to skip quickly through a number of scenes. For example, if the PC loses unconsciousness and wakes up again a couple hours, or even if they simply choose to Wait, it would be nice to be able to "fast-forward" through any GoParty exploration in single turn.

Finally, any world-state changes made within an early part of a scene can actually violate the preconditions of later parts of the scene. For example, it is possible for a violent PC to be knocked unconscious by an NPC as part of a reaction at the start of a scene. However, since the preconditions are not automatically checked again before continuing the scene, the scene continues as if the PC were still conscious and aware of the action.

All these problems result from the conflict between Marlinspike's view that a scene is a single atomic event and an implementing author's need to have more than one event occur within a scene. This is something that needs to be addressed in future versions of Marlinspike.

Reactions

A component of nearly every Demeter scene is NPC reactions, which brings us to handling NPC reactions in general. When the player interacts with an inanimate world object, it responds immediately. If a player opens a door, it opens. If the player passes through that open door, she arrives at the other side. If she picks up an item, the items moves into her inventory. In certain story-specific situations, it is possible for Marlinspike to interrupt such deeds before they complete. But otherwise an action in the world leads to an immediate result. In short, a player deed is atomic.

NPCs exist in the world and so are subject to player deeds just like props and other world objects. However, the results of affecting an NPC is not atomic. Instead, the player affects the NPC, and then the NPC responds as a separate event. This is because the response of an NPC is not a single, predictable success-or-failure outcome, as is the case with most objects. For example, if you slap an NPC, there is a number of possible responses: The NPC could stare at you in disbelief, or strike you back, or start to cry, or turn and run from the room. And this action may prompt other NPCs in the room to also react. For example, a different NPC may come to the victim's defense, either verbally or physically. Or perhaps the bystander NPC may even side with the PC and starts slapping the victim NPC too! But all of these reactions need to be coordinated in some way. If the bystander NPC decides to slap the victim too, but the victim flees the room before this can happen, then the bystander's selected reaction cannot be played after all. Also, because NPC behaviors are story-level events, they need to be managed by the drama manager to ensure the best fit in the ongoing story. This is especially true in the current design, where NPCs can only respond through played scenes.

I long struggled with the problem of coordinating NPC reactions in the design of Marlinspike. I considered some sort of reaction sub-system, but it was not clear how it would best be implemented. For example, NPCs should be given a chance to react after every deed. However, sometimes those reactions are so significant that immediately segueing into another scene that is not directly related would be jarring. That is, if reactions are significant, the player should be given a chance to respond first. Also, sometimes NPCs will want to react to each other during a scene.

Since I saw no clean, obvious solution to this problem that would work for all situations in all games, I left the decision to the implementing game. Demeter solves this problem by using a fairly complex NPCs_React scene. As described in Chapter IV, this scene manages thirteen possible NPC reactions. It determines which NPCs will react based on who was most affected by the current action. It also determines how many reactions will be played based on the import of the current action and the import of the resulting reactions. For example, if the PC is violent to an NPC, this is a significant action that warrants a high degree of reaction from bystanders. However, if an NPC decides to attack the PC in return, this is also a significant reaction. This means any remaining NPCs will tend to react to a lesser degree, such as by calling from the sidelines for an end to the violence.

NPCs_React does a decent job of coordinating NPC reactions. It determines which reaction is most appropriate for a given NPC as well as coordinating reactions between multiple NPCs. It can be called at the start of most other scenes to provide an appropriate degree of reaction to the current event before continuing the story. It can also be called within a scene to cause NPCs to react to each other. However, implementing NPCs_React side-stepped another problem that was more serious: NPCs need to react immediately to certain actions. But the initial Marlinspike design that selected the next scene based solely on reincorporation measures did not accommodate this well.

==>

Notes

This is something I would like to see changed in the next version of Marlinspike. A number of actions used in Demeter--such as the different kinds of affronts and assaults--exist simply to indicate different degrees of change to character affinities, rather than to mark significantly different kinds of story actions in themselves. A better approach would have been to have a subclasses of action for different kinds of state changes, such as WorldStateChange or AffinityChange. Then each different kind of action--such DEFY or ASSAULT or INSULT--could use a separate AffinityChange sub-event to represent the resulting effect of this action. In this way, every significant change of state in the game would be discretely represented in the event history as an event object. This would simplify authoring certain scene preconditions, as it is often desirable to search for effects rather than specific actions. For example, an author may want to know what event had the greatest negative affinity impact on a particular NPC, regardless of the nature of the causing action.