Operational Logics

xholonWorkbook.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--Xholon Workbook http://www.primordion.com/Xholon/gwt/ MIT License, Copyright (C) Ken Webb, Tue Jul 31 2018 09:53:32 GMT-0400 (Eastern Daylight Time)-->
<XholonWorkbook>

<Notes><![CDATA[
Xholon
------
Title: Operational Logics
Description: 
Url: http://www.primordion.com/Xholon/gwt/
InternalName: 8a7c63f995d078d37dcca00e072b7a8c
Keywords: 

My Notes
--------
July 23, 2018

Game Design

In this dissertation, I argue that projects in game interpretation and game design
science—whether performed by humans or by AI systems—ought to take operational logics
as their starting point. [2]

July 31, 2018
I've written some initial thoughts on Operational Logics and sent them to Joe Osborn:

Xholon and Operational Logics
Ken Webb
July 30, 2018

see: (1) http://www.primordion.com/Xholon/gwt/index.html
         https://github.com/kenwebb/Xholon

see: (2) Operationalizing Operational Logics, by Joseph C. Osborn
         https://users.soe.ucsc.edu/~jcosborn/ols-refined.pdf

This document has a few initial notes on how the Xholon project (my software) and specific Xholon apps make use of the concepts described in Joe Osborn's dissertation.
Each of the following sections is a Logic in Joe's dissertation, for example "Camera Logics".
I start each section with a quote from Joe's work, usually from his section 3.4 "The complete catalog".
Everything else is my own thoughts.
Joe is concerned with games, while Ken is concerned with modeling and simulating and exploring the real world (or sometimes unreal worlds, including game-like worlds).

1. Camera
   ------
"What the player sees is one of potentially several viewports onto a game world"[2]

Xholon uses the software development concept of Model-View-Controller.
A Xholon app usually consists of one model (= game world), although two or more models can be combined if desired.
In a Xholon app, there can be any number of optional views (0+) (cameras) into the model.

Default views include a number that display the model (statically and dynamically) in simple ways, for example:
 - an indented tree viewer (where everything is part of the same hierarchical structure rooted at "Application"),
  - http://www.primordion.com/Xholon/gwt/Xholon.html?app=HelloWorld&gui=clsc
 - a d3 circle-pack viewer (a universal viewer that can be used with any model),
 - a grid viewer (for models where space is laid out as a 2D grid),
 - an XML viewer (to see the details of any part of the model at any timestep),
 - a Graphviz viewer,
 - the out tab in the GUI (app-specific progress messages),
 - plus many other viewers.
 
Any app may have a custom viewer (ex: MeTTTa).
 - http://www.primordion.com/Xholon/gwt/Xholon.html?app=MeTTTa&gui=none&hide=xhtabs
Some apps have 2 or more d3 circle-pack views (ex: "Kidz Fun Finder" has a City viewer and a separate Calendar/days viewer).
 - http://www.primordion.com/Xholon/gwt/Xholon.html?app=ca00b929901de66fc721&src=gist&gui=none

2. Chance
   ------
"Events can play out in unexpected (“random”) ways."[2]

Xholon provides two different random number generators, one of which allows an initial seed to be specified.

3. Collision
   ---------
"An illusion of physical space is provided by the fact that some game objects occlude the movement of others."[2]

In Xholon, all nodes/objects exist in the same graph (tree structure).
Typically, two nodes can only interact if they are both co-located in the same parent node.
Two nodes moving within the same grid-cell, viewed by the grid viewer, would typically occlude each other.
But in the d3 circle-pack viewer or most other viewers, they would be shown next to each other, within the overall containment structure.
In Xholon I might define collision as "when 2 or more objects both have the same parent".
For example, in the Hello World app, the Hello and World nodes are both inside the parent HelloWorldSystem node:
 - http://www.primordion.com/Xholon/gwt/Xholon.html?app=HelloWorld&gui=none

4. Control
   -------
"Different entities are controlled by different inputs at different times."[2]

In Xholon, "Control" is the third part of Model-View-Controller.
The human user can control some things using a mouse or keyboard.
An Avatar is usually available. The human can use it to move around in and inspect and sometimes control the simulation world, through an app-specific avatar key map.
In some apps, all control is through active objects that include programmed behaviors, written in JavaScript or in Java (and compiled to JavaScript using GWT).
Avatars can be programmed using their own interactive fiction language (based loosely on Inform).
For example, I'm implementing parts of the Buffy app from Chris Martens' thesis on linear logic and Ceptre, trying to learn how to use rules:
 - https://xholon.meteorapp.com/Xholon.html?app=8e94a77fe8077659a80286f77a482b9a&src=gist&gui=none

5. Entity-State
   ------------
"Game entities act in different ways or have different capabilities at different times, intrinsic to each such entity."[2]

Hierarchical state machines are built into the core of Xholon.
Xholon was originally built as an implementation of the Real-time Object-Oriented Modeling (ROOM) software development approach.
A core concept in ROOM is "communicating state machines".
The Elevator model includes numerous separate state machines:
 - http://www.primordion.com/Xholon/gwt/Xholon.html?app=Elevator&gui=none

6. Game Mode
   ---------
"The game switches between different screens in which different controls, information, and actions are available."[2]

Although Xholon doesn't provide any direct support for game modes, there are underlying capabilities that could be used to do this.

7. Linking
   -------
"Some things, in some context, are related or connected to each other."[2]

Linking is a core concept in Xholon.
Every Xholon app consists of a tree structure (a place graph), with zero or more link graphs that dynamically connect things together using ports.
For example, a model of cell metabolism (hovering above a node will highlight other nodes it links to and nodes that link to it; although in this app most of the nodes are placeholders and don't link to anything else):
 - http://www.primordion.com/Xholon/gwt/Xholon.html?app=Cell&gui=d3cp

8. Persistence
   -----------
"Some things in the world stay the same, for example across sessions, between rooms, or when scrolled offscreen; while others change or reset."[2]

In Xholon, everything is in the same tree structure. Any subtree can be used to define a scope, where, for example, only objects within that scope get saved, moved, changed, eaten, viewed, etc.
If a Xholon model is run as a Meteor app, then changes made in one session can be restored from a database in subsequent sessions.
For example (this is a multi-player grid-based 2D game built using Xholon; it's part of a Cognitive Science research project at Carleton University):
 - https://xholon.meteorapp.com/?app=41dceb5cd5c809a49729bcc78ef332b7&src=gist&gui=none

9. Physics
   -------
"Physical laws govern the movement of some in-game entities."[2]

Some Xholon apps are intended as realistic models of simple physical systems, for example:
 - http://www.primordion.com/Xholon/gwt/Xholon.html?app=Brusselator&gui=none
And another example (wait for it to work through 1000 timesteps):
 - http://www.primordion.com/Xholon/gwt/Xholon.html?app=Train&gui=none

10. Progression
    -----------
"The content of a game and its behavior can change as the player makes progress through various sequences of goals."[2]

Xholon has no official concept of progression, other than timesteps.

11. Recombinatory
    -------------
"Some things are built out of smaller (recognizable) things."[2]

Recombination is used in many Xholon apps.
For example, in this model, an Avatar uses building blocks to make a final configuration:
 - http://www.primordion.com/Xholon/gwt/Xholon.html?app=d5c2b8f98a8f51213f07c03e5ac3ba53&src=gist&gui=none

12. Resource
    --------
"Generic or specific resources can be created, destroyed, converted, or transferred between abstract or concrete locations."[2]

I'm not sure how this is different from recombination.

13. Selection
    ---------
"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."[2]

Xholon supports mouse selection of multiple nodes using the Node Selection Service.
Nodes can be grouped using subtrees, arrays, sets, messages, ports and port arrays, etc.

14. Spatial Matching
    ----------------
"Arranging objects in certain ways can cause things to happen."[2]

Xholon makes use of Minecraft-like crafting rules, and I'm exploring various approaches to "recipes".
Often, as avatars and other active objects move around, things will only happen if other objects are in specific places.
For example, in a Peter Rabbit simulation, Peter can't get out of Mr. McGregor's garden if a malevolent human removes the gate once he's entered the garden.
 - http://www.primordion.com/Xholon/gwt/Xholon.html?app=04bef197a0cc61a5a31d&src=gist&gui=none

15. Temporal Matching
    -----------------
"Some sequences of events can have different effects when they occur with particular timing or in a particular order."[2]

Xholon state machines can enforce/specify a temporal pattern.

`end of initial thoughts on Operational Logics sent to Joe Osborn


References
----------
(1) https://users.soe.ucsc.edu/~jcosborn/ols-refined.pdf
    Refining Operational Logics
    by Joseph C. Osborn, Noah Wardrip-Fruin, and Michael Mateas
    Computational Media, Computer Science, University of California at Santa Cruz

(2) Operationalizing Operational Logics
    PhD thesis by Joseph C. Osborn, June 2018

(3) https://www.soe.ucsc.edu/departments/computational-media
    The Computational Media Department is dedicated to the creation, enhancement, and study of media forms that can only be made using computers.
    The department emphasizes the construction of technologies that make possible novel media experiences,
    while simultaneously embracing and engaging in theoretical and practical approaches from the arts, humanities, and social sciences.
    UC Santa Cruz hosts the Center for Games and Playable Media, the largest games research group in the world,
    comprised of the Expressive Intelligence Studio, Social and Emotional Technology Lab, Interactive Systems for Individuals with Special Needs Lab,
    Augmented Design Lab, and the Software Introspection Lab.

(4) https://games.soe.ucsc.edu/
    The Center for Games and Playable Media houses UCSC's five games-related research labs including the Expressive Intelligence Studio
    — one of the largest technical game research groups in the world.
    
(5) https://games.soe.ucsc.edu/eis
    The Expressive Intelligence Studio at University of California, Santa Cruz is dedicated
    to exploring the intersection of artificial intelligence, art and design.

(6) https://games.soe.ucsc.edu/biblio/author/7
    Wardrip-Fruin, Noah  publications

(7) https://games.soe.ucsc.edu/biblio?f%5Bauthor%5D=8
    Mateas, Michael  publications

(8) https://hal.inria.fr/hal-01110847/document
    Adapting Game Mechanics with Micro-Machinations
    Riemer Van Rozen, Joris Dormans

(9) http://deadpixel.co/gamedesign1/week%2012%20-%20read%20by%2011.29/AdvancedGameDesign.Ch1and4-excerpts.pdf
    Designing Game Mechanics
    chapter in a book

(10) https://www.amazon.com/Fundamentals-Game-Design-Ernest-Adams/dp/0321929675
    Fundamentals of Game Design (3rd Edition) by Ernest Adams, 2013
    "Now in its third edition, the classic book on game design"

(11) Defining Operational Logics, by Michael Mateas and Noah Wardrip-Fruin
    Much analysis of games focuses, understandably, on their
    mechanics and the resulting audience experiences.
    Similarly, many genres of games are understood at the level
    of mechanics. But there is also the persistent sense that a
    deeper level of analysis would be useful, and a number of
    proposals have been made that attempt to look toward a
    level that undergirds mechanics. This paper focuses on a
    particular approach of this sort—operational logics

(12) https://www.machinations.io/
    Design, visualise & simulate game systems
    Features:
     Interactive Diagram: map all game entities & currencies and visualise their flow
     Parameters: set the game flow parameters
     Balance your game economy parameters
     Run & Plot single or multiple simulations, instantly
    demo .xml files have "node" and "connection" tags
    UML
     "Although the machinations UML (unified modelling language) is abstract, the level of detail in a diagram depends solely on the depth and complexity you wish to craft."

(13) https://github.com/vrozen/MM-Lib
    C++, C
    Micro-Machinations Library (MM-Lib)
    Micro-Machinations (MM) is a game design language for describing economic game mechanics.

(14) http://www.sbgames.org/sbgames2016/downloads/anais/157015.pdf
    Game Mechanics Design: Applying Machinations to Eliosi’s Hunt
    Tiago Zaidan1, Daniel Zaidan, Luıs Fabrıcio W. Goes

]]></Notes> 

<_-.XholonClass>

  <!-- domain objects -->
  <PhysicalSystem/>
  <Block/>
  <Brick/>
  
  <!-- quantities -->
  <Height superClass="Quantity"/>
  
</_-.XholonClass>

<xholonClassDetails>
  <Block>
    <port name="height" connector="Height"/>
  </Block>
</xholonClassDetails>

<PhysicalSystem>
  <Block>
    <Height>0.1 m</Height>
  </Block>
  <Brick multiplicity="2"/>
</PhysicalSystem>

<Blockbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[
  var a = 123;
  var b = 456;
  var c = a * b;
  if (console) {
    console.log(c);
  }
  //# sourceURL=Blockbehavior.js
]]></Blockbehavior>

<Heightbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[
  var myHeight, testing;
  var beh = {
    postConfigure: function() {
      testing = Math.floor(Math.random() * 10);
      myHeight = this.cnode.parent();
    },
    act: function() {
      myHeight.println(this.toString());
    },
    toString: function() {
      return "testing:" + testing;
    }
  }
  //# sourceURL=Heightbehavior.js
]]></Heightbehavior>

<Brickbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[
  $wnd.xh.Brickbehavior = function Brickbehavior() {}

  $wnd.xh.Brickbehavior.prototype.postConfigure = function() {
    this.brick = this.cnode.parent();
    this.iam = " red brick";
  };

  $wnd.xh.Brickbehavior.prototype.act = function() {
    this.brick.println("I am a" + this.iam);
  };
  //# sourceURL=Brickbehavior.js
]]></Brickbehavior>

<Brickbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[
  console.log("I'm another brick behavior");
]]></Brickbehavior>

<SvgClient><Attribute_String roleName="svgUri"><![CDATA[data:image/svg+xml,
<svg width="100" height="50" xmlns="http://www.w3.org/2000/svg">
  <g>
    <title>Block</title>
    <rect id="PhysicalSystem/Block" fill="#98FB98" height="50" width="50" x="25" y="0"/>
    <g>
      <title>Height</title>
      <rect id="PhysicalSystem/Block/Height" fill="#6AB06A" height="50" width="10" x="80" y="0"/>
    </g>
  </g>
</svg>
]]></Attribute_String><Attribute_String roleName="setup">${MODELNAME_DEFAULT},${SVGURI_DEFAULT}</Attribute_String></SvgClient>

</XholonWorkbook>