Ceptre: A Language for Modeling Generative Interactive Systems.
Chris Martens
2015
We present a rule specification language called Ceptre,
intended to enable rapid prototyping for experimental
game mechanics, especially in domains that depend on
procedural generation and multi-agent simulation.
Ceptre can be viewed as an explication of a new
methodology for understanding games based on linear
logic, a formal logic concerned with resource usage. We
present a correspondence between gameplay and proof
search in linear logic, building on prior work on generating narratives. In Ceptre, we introduce the ability to
add interactivity selectively into a generative model, enabling inspection of intermediate states for debugging
and exploration as well as a means of play.
We claim that this methodology can support game designers and researchers in designing, anaylzing, and debugging the core systems of their work in generative,
multi-agent gameplay. To support this claim, we provide two case studies implemented in Ceptre, one from
interactive narrative and one from a strategy-like domain.
Some choice quotes from the artice follow.
Simple examples of the rule language:
The meaning of A -o B
, to a first approximation, is
that whenever the predicates in A
are present, they may be
replaced with B
. One example of a rule is:
do/compliment:
at C L * at C’ L * likes C C’
-o at C L * at C’ L * likes C C’ * likes C’ C.
[...]
Note that because of the replacement semantics of the
rule, we need to reiterate everything on the right-hand side
of the -o
that we don’t want to disappear, such as the character locations and original likes fact. We use the syntactic sugar of prepending $
to anything intended not to be
removed in order to reduce this redundancy:
do/compliment: $at C L * $at C’ L * $likes C C’ -o likes C’ C.
A more complex rule describes a murder action, using
the !
operator to indicate a permanent state:
do/murder:
anger C C’ * anger C C’ * anger C C’ * anger C C’
* $at C L * at C’ L * $has C weapon
-o !dead C’.
(This rule consumes C
’s location, maintaining a global
invariant that each character is mutually exclusively at a
location or !dead.) Here we see a departure from planning
formalisms: four instances of anger C C’
mean something different from one.
Here we are using an emotion not
just as a precondition but as a resource, where if we have
enough of it, we can exchange it for a drastic consequence.
Whether or not we diffuse the anger, or choose to keep it by
prepending $
to the predicates, is an authorial choice.
Concurrency in narration:
Two rule applications that consume
disjoint sets of resources from the same state can be said to
happen concurrently, or independently. On the other hand,
a rule that produces resources and another that consumes a
subset of them can be said to be in a causal, or dependent,
relationship. Less abstractly, if resources represent facts associated with particular game entities or characters, then independent rule applications represent potentially concurrent
action by multiple such entities, and causally related rule applications represent either sequential action by a single actor,
or synchronized interaction between two entities.
Stages, and a larger example:
We would like to for some
of these rules to run automatically without player intervention. In our next iteration of the program, we will make use
of a Ceptre feature called stages. Stages are a way of structuring a program in terms of independent components. Syntactically, a stage is a curly-brace-delimited set of rules with
an associated name. Semantically, a stage is a unit of computation that runs to quiescence, i.e. no more rules are able
to fire, at which point control may be transfered to another
stage.
[...]
Additionally, we can test the design by “scripting” certain player strategies. For instance, we
could augment the two rules in the fight stage to be deterministic, fighting when the monster can’t kill us in one turn
and fleeing otherwise:
stage fight = {
do_fight:
choice * $fight_in_progress * $monster Size * $health HP * Size < HP
-o try_fight.
do_flee :
choice * fight_in_progress * $monster Size * $health HP * Size >= HP
-o flee_screen.
}
If we remove interactivity from this stage, then we get
automated combat sequences that should never result in the
player’s death.
Recent comments
17 weeks 8 hours ago
17 weeks 12 hours ago
17 weeks 12 hours ago
39 weeks 1 day ago
43 weeks 3 days ago
45 weeks 20 hours ago
45 weeks 20 hours ago
47 weeks 5 days ago
1 year 2 days ago
1 year 2 days ago