\noindent What the player sees is one of potentially several viewports onto a game world, and our viewport can pan, zoom, rotate, etc. On-screen and off-screen parts of the world might act differently, and the player might see several viewports at once.

\noindent Moving or altering the shape or position of a camera's projection; mapping this onto other surfaces, e.g., a sub-region of the game screen.

• Alter the world position of the camera or other aspects of its transform (e.g., pan, zoom, rotate)
  • Potentially performing some camera wipe or other transition
• Choose whether or not to draw certain objects on certain cameras

• Show the viewport on the game screen where the player can see it
• Project the viewport onto something in world space

• World coordinate space

• Camera views

\noindent Events can play out in unexpected ("random") ways.

\noindent Sampling from stationary or nonstationary event sources, along with analysis of probabilities, expected values, etc.

• Check/alter the likelihood of an event occurring.
• Cause an event to happen (perhaps from a pool of events) with some likelihood.
• Make a random draw from a stationary or nonstationary source

• Show probabilities like success rates as textual percentages or as discrete symbols summarizing their probability
• Show expected values as ranges between minimum and maximum possible values
• Highlight extremely unlikely outcomes with visual effects
• For nonstationary sampling as in sampling without replacement (e.g., from a shuffled deck of cards), show the upcoming picks or the remaining size of the bag

• Types of random events

• Chances, for example success rates or expected damage value

\noindent An illusion of physical space is provided by the fact that some game objects occlude the movement of others.

\noindent Detection of overlaps between subsets of entities and/or regions of space and the automatic triggering of reactions when such overlaps occur.

• (Alter/Check) which entities could be said to collide with which other entities or regions of space (e.g., collision layers or flags, or hurt vs hit boxes)
• Check if two entities or regions are overlapping or touching
• (Alter/Check) the region of space taken up by an entity (e.g., grow or shrink an entity or change its collision polygon)
• Enumerate the entities or regions overlapping or touching an entity or region
• Separate the positions of two or more entities or regions such that they touch but do not intersect
• Determine how far an entity could move towards another entity or region without touching or causing an overlap
• Whenever a combination of the above checks becomes true (or remains true, or becomes false), perform some abstract operation of this or another operational logic involving the objects considered in those checks

• Shapes or images for each entity or region of space, whose extents and appearance correspond to the extents of the corresponding entity, and whose positions on screen correspond to their positions in space
• Sound effects or visual effects indicating collision when particular objects or re- gions of space begin/continue/cease to touch or overlap
• Textual descriptors detailing the sizes or shapes of entities and whether they are touching or overlapping
• The presence or absence of textual descriptors of entities when describing a region of space
• Textual messages describing the event when objects begin/continue/cease to touch or overlap

• Entities and their positions
• Space

• Collision
• Overlapping
• The extents of objects in space

\noindent Different entities are controlled by different inputs at different times.

\noindent Map button inputs, AI intentions, network socket messages, etc onto high-level game actions, possibly grouped onto specific loci of control like characters according to the event source.

• Change which character the player (or another event source) is controlling
• Change the mapping between low-level inputs and high-level actions
• Determine the available high-level actions at a given time for a given actor

• Show a graphical indicator like a triangle or colored circle around the character being controlled (perhaps mapping colors to event sources).
• List the available moves for an actor in a menu overlay.
• Show a picture of e.g., a keyboard or a controller with labeled lines illustrating which buttons perform which high-level actions.

• High-level actions
• Event sources/actors
• Loci of control (e.g., game entities)

• Available actions for a given actor
• Which actor controls which locus
• Which actors are present/active

\noindent Game entities act in different ways or have different capabilities at different times, intrinsic to each such entity.

\noindent Governing the finite, discrete states of a set of game characters or other entities. Updating states when necessary. Conditioning the operators of other logics on entities' discrete states.

• (Alter/Check) the discrete state of an entity according to a given (fixed) transition system.
• Whenever an entity's discrete state changes, perform some operators of this or another logic.
• Synchronize state changes between several entities.

• Change an entity's sprite, animation, or visual effects according to state.
• Textual or icon labels/descriptors to indicate state.
• Audio/visual/text effects on state change.

• Entities
• Condition predicates for making transitions

• Entity states
• State transitions and related events

\noindent Note that an entity may be attached to several concurrent transition systems, and these must be composed somehow. In this document, I use "discrete state" to refer to an entity's overall, combined state, e.g., "jumping while ducking" or "poisoned, hasted, and confused". Concurrent Hierarchical State Machines provide one possible semantics.

Also note that resource logics may also involve discrete state (e.g., number of health units), but this seems somewhat ambiguous with entity-states (e.g., current set of power-ups; in a Metroid example, whether the Varia suit upgrade has been obtained). The key guidelines for whether such a piece of state is a resource or an entity-state are:

1. If the statistic "feels" more categorical than numeric (even if an ordering could be given), entity-state is likely more appropriate.
2. If the statistic is numeric and is ever "spent", or if it acts as a cap on a numeric resource which is spent, or if it otherwise engages with a resource economy in a similar way, it is likely a resource and not an entity-state.

In particular, RPG character statistics are usually best thought of as resources, whereas status effects are more like entity-states.

\noindent The game switches between different screens in which different controls, information, and actions are available.

\noindent Set up, activate, suspend, and clean up different game modes (potentially in parallel) like title screens, save/load screens, navigation versus menu or battle modes, etc.

• Activate a new game mode, optionally deactivating the old mode
• Determine the currently active game modes

• Change the visual layout of the screen, the background, or some text to illustrate the active mode
• Play a transition visual or sound effect to highlight a change in mode

• A set of game modes and conditions under which they might change

• Which game modes are currently active

\noindent This will often work in concert with persistence logic so that while the player is in the in-game menu or pause screen nothing changes in the world.

\noindent Some things, in some context, are related or connected to each other.

\noindent Maintain, enumerate, and follow/activate directed connections between concepts.

• Determine/alter which links are available potentially according to operators of other logics
• Perform some action when a link is activated or traversed
• Enumerate or perform some action on all the objects linked to another object

• Show a laid-out graph of links between concepts.
• Highlight links which are available to traverse/activate or hide those which are unavailable
• Scroll smoothly when moving between connected spaces, if connections have a "side"
• Play a screen transition when moving between connected spaces

• Things to be linked together
• Types of links and attributes of those links

• Networks of linked objects
• Current "positions" in those networks

\noindent This can be used for spatial links between rooms, for dialog trees (navigating an abstract space), for character progression systems like Final Fantasy X's Sphere Grid, and for a wide variety of other uses.

\noindent Some things in the world stay the same, for example across sessions, between rooms, or when scrolled offscreen; while others change or reset.

\noindent Determining which entities, assets, and variables are in a particular scope (e.g., saved-game scope, current-level scope, visible-area scope) and persisting or resetting those as the scope changes.

• Determine or alter which persistence scopes are active.
• Set, clear, or restore the facts associated with a particular scope.
• Trigger an action of another logic when scopes change, are saved, or are restored.

• Give audiovisual feedback when scopes change or when variables have been reset.
• When the player is about to leave a scope, give textual descriptions of what data will be preserved and what will be lost.

• Abstract objects and facts governed by scoping rules.
• A set of possible scopes.

• Active and inactive scopes
• Save and reset events

\noindent This is generally how a game addresses concepts like "bullets disappear when they go off-screen" or "remember opened treasure chests and defeated bosses but not regular enemy health/positions".

\noindent Physical laws govern the movement of some in-game entities.

\noindent Update and honor objects' physical properties like position, velocity, density, etc., according to physical laws integrated over time.

• Alter the physical properties of objects (mass, moment of inertia, coefficients of friction, etc).
• Apply impulses, continuous forces, heat, etc., to objects.
• Integrate physics forward (or rewind it backwards) for one or more objects.
• Determine an object's physical quantities based on terms from some other logic (e.g., character-state, resource).

• Map physical quantities like energy or mass onto visual qualities of the objects
• Show changes in physical quantities with visual or sound effects

• Game entities, including their positions, shapes, and extents
• Physical properties of entities and the world

• Physical quantities and behaviors

\noindent This is nearly always in simulated continuous time and space.

\noindent The content of a game and its behavior can change as the player makes progress through various sequences of goals.

\noindent Track and check measures of progress (potentially on multiple fronts).

• Update or reset progression on some front, or track some flag.
• Check whether the player has progressed past some threshold, or whether something should be available.
• Parameterize operations of other logics based on progression.

• Pop up an achievement or other notification (e.g., a title card) when game progress takes place
• Show story events in a logbook or as a network of events
• Write text so that non-player characters refer to earlier stages of progression

• Types of progress

• Current status on progress measures

\noindent This can be used for things like quests and chains of quests, for in-engine cutscenes and scripted events, and to gate some content based on other content.

\noindent Some things are built out of smaller (recognizable) things.

\noindent From a fixed set of (possibly parameterized) atoms, build a structured object (a room, a dungeon, a description, a magic item) according to some rules and constraints (possibly conditioned on operators of other logics) with some optional post-processing.

• Generate an object or behavior out of some set of atoms with some parameters
• Enumerate valid outputs for some given constraints

• For text which is filled in a "mad libs" style, underline or otherwise highlight the dynamic part of the text
• Show a seed value identifying the generated object

• Atoms to be recombined
• Conditions governing valid combinations

• Object/behavior generators
• Parameters and measures associated with generated objects

\noindent These can be used for procedural content generation or for monster formations or even for monster combat scripting, text generation, etc.

Diablo rooms come from a fixed set and are connected arbitrarily through doorways; Rogue rooms come from a fixed set and are connected by gluing passages between them; Markov-chain text uses fixed characters and chooses the next according to the current character and some probabilities encoded in a Bayes network; Eliza produces a new string by picking a template based on whether key words were found in the input string by a pattern matching logic, with the templates parameterized by rooted or transformed versions of the input to the pattern matching logic.

These can roughly be characterized in terms of how complex the choice structure is, how many or how fine-grained the intermediate structures produced by the operators are, and how much post-processing is done to ensure consistency or otherwise "fix up" the generated stuff. I suspect that constraint-solver-based methods would live in here too.

\noindent Generic or specific resources can be created, destroyed, converted, or transferred between abstract or concrete locations.

\noindent Creating, destroying, and exchanging (usually) discrete quantities of generic or specific resources in or between abstract or concrete locations on demand or over time; triggering other actions when these transactions take place.

• Check if a transaction involving some units of certain resources is possible for some given locations.
• Perform a resource transaction.
• Perform an action of another logic when a transaction occurs.
• Perform an action of another logic when the quantity of resources within a location crosses a threshold.

• Resource types are icons or text, quantities are numeric labels, locations are distinct regions of the screen (Or, in textual logics, separate lines or sections of the text)
• Resource types and quantities have intertwined representation, e.g., ten units of resource R appear as ten identical grouped icons or text labels communicating R; again, distinct regions of the screen express location (Or, in textual logics, separate lines or sections of the text)
  • This refers to e.g., Zelda "hearts" if the "capacity" of the location is also shown; this could also apply to health bars or other indicators where the length or color of a bar is a proxy for resource quantity
• As in the previous case, but different quantities of the same resource map onto different iconic representations
• Transactions may be described as lists of prerequisite resources and quantities (as above) and lists of result resources and quantities (again as above, but not necessarily in the same way). The interface elements affording the execution of that transaction may be dimmed if the transaction is not allowed, or the individual prerequisite resources if they are not present, or the result resource indicators may be dimmed. (Where dimming may be broadly construed as affording non-interaction)
• An attempt to perform a disallowed transaction may be met with graphical, textual, or aural feedback
• When a transaction occurs, text labels indicating the resource and quantity (via color, size, text content, etc) may appear for a time on screen (perhaps near the locations the transaction took place) or more permanently in a log, possibly along with aural feedback or animations
• Locations with spatial semantics may be communicated as appropriate for those semantics, with resources assigned individually or in groups to "physical" objects in those spaces. Common examples include "inventories" in adventure and especially role playing games. In any event the communication is somewhat deferred to the other logics which provide the spatial model; often this spatial view is not used in (for example) crafting systems of the same game, where aggregate counts are used instead

• Resource types
• Locations for resources
• A way to enumerate and count resources in those locations, e.g., to map a Diablo inventory onto a crafting system
• Ways to remove resources from and add resources to locations

• Resource transactions (available, allowed, and disallowed)
• Resource quantities and thresholds

\noindent In many cases there will be only one location, or resources of a given type will only be created, etc. The generic/specific language used here distinguishes e.g., "Minerals" from having more than one "Copper Sword." The two types of locations are ones which cannot be physically located in the game (abstract) and those which can (concrete).

Cellular automata are a special case, especially since they are often communicated by mapping cells/locations onto physical space in a metric way, and quantities onto a dimension of space/color/etc

\noindent The player can mark a subset of items out of a larger set as "selected", and there might be several currently active selections with different semantics.

\noindent Remember sets of selected objects out of larger sets, and pass around or enumerate those sets for other logics.

• Add or remove an object from a selection
• List the objects in a selection, or which could be selected
• Perform some action when objects are selected or deselected
• Constrain the maximum or minimum size of a selection

• Highlight the selected item graphically, by putting an icon next to it, or by altering or annotating its text label
• When a selection changes, play a visual or sound effect or have the selected/deselected item play an animation

• Things that can be selected and types of selections

• Selected object identifiers and measures on selection sets

\noindent These are often used for menus or for RTS control (interacting with control logic), but also show up in crafting systems and many other places. Sometimes there are several selection categories which can be active at once, e.g., "the item slot the player selected for 'from' and the item slot the player is about to select for 'to'".

\noindent Arranging objects in certain ways can cause things to happen.

\noindent Analyze the positions of objects and trigger events when they enter or leave particular layout patterns.

• Determine whether a set of objects is arranged in a particular pattern
• Perform some action when a pattern is matched
• "Click" or automatically align objects into a particular arrangement

• Highlight objects which partially or fully satisfy a pattern with visual effects

• Things to be analyzed for pattern matching
• A space in which those things are laid out

• Matched patterns
• Slots in which objects can be arranged

\noindent In a point-and-click or parser adventure game, situations like "use HAMMER on ROCK" or "put FISH in OCEAN" could be seen as cases of spatial matching. This also covers puzzle games like Tetris or Bejeweled as well as certain puzzles in RPG dungeons and potentially the minigames seen in e.g., golf games.

Some crafting systems also use spatial pattern matching logics.

\noindent Some sequences of events can have different effects when they occur with particular timing or in a particular order.

\noindent Observe sequences of events to recognize when a pattern is matched and trigger an action when this occurs.

• Trigger an event when a temporal pattern is matched
• Determine which, if any, temporal patterns are currently under consideration/partially matched
• Determine how well a new event matches any pattern currently under consideration

• Give the player feedback on how well their input lines up with the temporal pattern
• Provide visual or audio feedback when a temporal pattern is satisfied
• Show the sequence of actions under consideration to the player in a textual or pictorial representation

• Types of events to be matched
• Streams of events

• Matched patterns
• Timing quality

\noindent Music/rhythm games are often based on temporal pattern-matching logics, as are time-sensitive mini-games and special moves in fighting games.