Deque System of Representational Game State

Abstract

A system that allows direct manipulation of numerical parameters while playing games. Vertical columns of physical units are formed into deques that each represent between one and three parameters of the game state at a given time. The game's mechanics are defined as a set of state transitions, each of which map a configuration of units/deques, along with a nonnegative integer input, to a new configuration of units/deques. This new configuration directly represents the resultant game state and parameters thereof, and is naturally subject to further systematic manipulation.

Claims

1. A system that encapsulates game state and mechanics comprising: (a) vertical columns of physical units that function as double-ended queues (“deques”), (b) a set of designations for subsets of the units, (c) a set of deque definitions, and (d) a set of state transition functions that transfer units between deques, whereby players of games are afforded a means to directly manipulate and account for the numerical parameters relevant to them.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

[0015] FIG. 1—Introduces the physical components of the invention. q is a pool queuing units; a is a pool of auto-stacking units; s is a pool of stacking units; D is a deque of s, a, and q units.

[0016] FIG. 2—Shows the Example in some initial configuration. q is the pool of queuing “health” units; a is the pool of auto-stacking “armor” units; s is the pool of stacking “mana” units; u is the pool of queuing “energy” units; H is the “Health” deque; E is the “Energy” deque.

[0017] FIG. 3—Shows the take-damage( ) transition of the Example. n is the number of units popped from the “Health” deque.

[0018] FIG. 4—Shows the heal-damage( ) transition of the Example. n is the number of units popped from the “health” pool.

[0019] FIG. 5—Shows the consume-mana( ) and consume-energy( ) transitions of the Example. n is the number of units popped from the “Energy” deque.

[0020] FIG. 6—Shows the restore-mana( ) transition of the Example. n is the number of units popped from the “mana” pool.

[0021] FIG. 7—Shows the use-mana-shield( ) transition of the Example. n is the number of units popped from the “Energy” deque.

[0022] FIG. 8—Shows the use-blood-tap( ) transition of the Example. n is the number of units popped from the “Health” deque. k is the number of units then popped from the “mana” pool.

[0023] FIG. 9—Shows the use-rejuvenation( ) transition of the Example. n is the number of units popped from the “Energy” deque. k is the number of units then popped from the “health” pool. j is the number of units then popped from the “health” pool again.

DETAILED DESCRIPTION OF THE INVENTION

Overview

[0024] The present invention, here referred to as the “Deque System,” consists of three ingredients: Units, Deques, and state Transitions. Each ingredient has a well-defined schema, and is instantiated with respect to a given game. Here, the schema for each component of the Deque System will be defined, followed by a simple example. Then, a complex example (the Example) will be given by constructing an instance of the Deque System for a state typical of role-playing games. First of all, the main terminology used throughout this section is introduced below.

[0025] <Terminology: unit> A “unit” is any discrete, stackable, and distinguishable physical object. Here, distinguishable means that individual units can be colored, marked, or otherwise made to be clearly partitioned into mutually exclusive subsets of all units in use.

[0026] <Terminology: unit type> A “unit type” is a unique designation assigned to an exclusive subset of all units in use.

[0027] <Terminology: deque> A “deque” is a double-ended queue. Here, it specifically refers to a vertical column of units, which may be extended by placing new units either on top of it, or underneath it, and which may be reduced only by removing units from its top.

[0028] <Terminology: pop> The verb “pop” means here the act of removing a unit from the top of a deque. Units always pop; they are never removed from the bottom of a deque.

[0029] <Terminology: stack> The verb “stack” means here the act of adding to a deque from the top. A deque's stacking unit type always stacks onto it.

[0030] <Terminology: auto-stack> The verb “auto-stack” means here the act of stacking all units back onto a deque at the end of any transition in which they were popped. A deque's auto-stacking unit type (if it has one) always auto-stacks onto it.

[0031] <Terminology: queue> The verb “queue” means here the act of adding to a deque from the bottom. A deque's queuing unit type (if it has one) always queues into it.

[0032] <Terminology: game state/mechanics> The Deque System primarily models the dynamic parameters of a game that players track as it is played. The specific configuration of all such parameters at a given time is a “game state.” The rules by which the game state is allowed to evolve in time are the “mechanics” of the game.

[0033] <Terminology: state transition> A “state transition” is a function that maps a given nonnegative integer, implicitly along with a game state, to another nonnegative integer, implicitly along with a new game state. State transitions operate on arbitrary state, and reference only the unit types and deque definitions known a priori. Thus, a game may start in any initial configuration of Units and Deques, and evolve through a series of state transitions, which are always well-defined, with the following proviso: transitions immediately resolve when they require a unit to pop from a deque that is empty.

[0034] <Schema: Units> Exactly one unit type is defined per numerical parameter of the game state. The number of units of a given type is set by the numerical constraints on the parameter that the unit type represents. These constraints must correspond to a finite range over the nonnegative integers. The set of all unit types is the first ingredient of the Deque System. For example: [0035] Units:={“health”, “mana”}

[0036] <Schema: Deques> A deque is defined by a 3-tuple of unit types. The first element of the tuple specifies which unit type stacks onto the deque being defined; the second element specifies which unit type auto-stacks onto it; and the third element specifies which unit type queues into it. The first (stacking) element must refer to a unit type. The second (auto-stacking) and third (queuing) elements may optionally refer to null, to indicate that there is no such unit type for the deque being defined. The set of all deques is the second ingredient of the Deque System. For example: [0037] Deques:={Health[ ], Mana[ ]} [0038] Health[ ]:=(“health”, null, null) [0039] Mana[ ]:=(“mana”, null, null)

[0040] <Corollary: pool> Given the definitions for Units and Deques, it follows that each unit type “C” implicitly defines a deque: C[ ]:=(“C”, null, null). This implicit deque represents the finite source, or “pool,” of “C” units. It is assumed that exactly one such pool exists per unit type. In the state transition definitions that follow, any given pool will be written as the unnamed deque “[ ]”, where the specific pool it represents can be inferred by the type of unit interacting with it. The notation “@[ ]” will be used for the pool of a unit that is temporarily stacking onto it, before auto-stacking back onto the deque whence it popped.

[0041] <Schema: Transitions> State transitions are defined as either: (a) exactly one statement of the form “count <unit type> while pop <nonnegative integer> from <deque> where <stacking unit type>.fwdarw.<deque>, <auto-stacking unit type>.fwdarw.<deque>, <queuing unit type>.fwdarw.<deque>”; or (b) the composition of two (or more) state transitions. The auto-stacking and queuing clauses may be omitted when their respective unit types are null. The count clause determines which unit type to tally as it pops, and the function shall evaluate to the total tally to resolve the transition. The set of all state transitions is the third and final ingredient of the Deque System. For example: [0042] Transitions:={take-damage( ), consume-mana( )} [0043] take-damage(n):=count “health” while pop n from Health[ ] where “health”.fwdarw.[ ] [0044] consume-mana(n):=count “mana” while pop n from Mana[ ] where “mana”.fwdarw.[ ]

EXAMPLE

[0045] Consider a game whose players are concerned with following numerical parameters: health, mana, energy, and armor. Additionally, the game mechanics stipulate that: health is decremented by damaging effects (Sheet 3); health is incremented by healing effects (Sheet 4); armor protects health from damage and is never depleted (Sheet 3); mana/energy is decremented by effects that consume them (Sheet 5); mana is incremented by effects that restore it (Sheet 6); mana-shield: mana may be decremented to protect health, but is then decremented by damage (Sheet 7, Sheet 3); blood-tap: damage may be taken so that any lost health is converted 1:1 into mana (Sheet 8); rejuvenation: mana/energy may be consumed so that any lost energy is converted 1:2 into health (Sheet 9). The basic objective of this game might be to prevent health and energy from decrementing to zero. Now, the following instantiation of the Deque System captures all stated parameters and mechanics, and allows them to be tracked and directly manipulated by the players. [0046] Units:={“health”, “mana”, “energy”, “armor”} [0047] Deques:={Health[ ], Energy[ ]} [0048] Health[ ]:=(“mana”, “armor”, “health”) [0049] Energy[ ]:=(“mana”, null, “energy”) [0050] Transitions:={take-damage( ), heal-damage( ), consume-mana( ), restore-mana( ), use-mana-shield( ), use-blood-tap( ), use-rejuvenation( )} [0051] take-damage(n):=count “health” while pop n from Health[ ] where “mana”.fwdarw.[ ], “armor”.fwdarw.@[ ], “health”.fwdarw.[ ] [0052] heal-damage(n):=count “health” while pop n from [ ] where “health”.fwdarw.Health[ ] [0053] consume-mana(n):=count “mana” while pop n from Energy[ ] where “mana”.fwdarw.[ ], “energy”.fwdarw.[ ] [0054] restore-mana(n):=count “mana” while pop n from [ ] where “mana”.fwdarw.Energy[ ] [0055] consume-energy(n):=count “energy” while pop n from Energy[ ] where “mana”.fwdarw.[ ], “energy”.fwdarw.[ ] [0056] use-mana-shield(n):=count “mana” while pop n from Energy[ ] where “mana”.fwdarw.Health[ ], “energy”.fwdarw.[ ] [0057] use-blood-tap(n):=restore-mana(take-damage(n)) [0058] use-rejuvenation(n):= [0059] heal-damage(heal-damage(consume-energy(n)))