Somebody Elses Problem:

Using existing game systems & your own

Why Existing Game Systems?

Big Game Love

  • Existing community
  • Low threshold to participate
  • Fast to develop
  • Games I can actually make affordably

Moddy Game Systems


How Minecraft took over

my art practice.

Read why minecraft is any



CloudMaker was an AHRC ITaaU funded project exploring Minecraft as a social learning platform. It's *not* actually, but it is an ecosystem that you can learn some things in like


RF-Craft was a system built with Patrick Fenner for radio controlled minecraft games to augment the spaces of Wray Castle for the Ok Sparks! project

The lack of WiFi in the castle made me rethink how you could augment a game; bringing elements of the game into the physical world

Text Adventures

  • They're one of the earliest kind of computer game.
  • No Graphics
  • They're the first games I tried to make age 12 using The Quill

# The Hobbit
"""Thorin sits down 
and starts singing 
about gold

Adventures in Text

With text you can present things very simply and clearly; it does not even have to be an adventure in text: you can just use it to just frame something you want to like Walter Benjamin or  logical rationalism

# The Hobbit
"""Thorin sits down 
and starts singing 
about gold

Go Off-Grid!

Playing games in your house can be boring.

Playing them somewhere else is not

Why Off Grid?

Simple really I like the idea of visiting a forest to play a game about the forest or play a game about a Castle but you'll need to visit the castle: Explore and play in a mixed reality and learn stuff

Pocketmining Forests

Prototype minecraft server that you could play in Grizedale forest with iPad & android phone; map based on microscopic images from forest floor slime mould for a workshop about bacterial communication DeadWood


WhitCraft was a pocketmine server for The Whitworth Art Gallery


They wanted mobile devices to be able to explore the gallery in game and in the space in a Mixed Reality stylee

Fiction to non-fiction

Interactive Fiction is what's left of the Text Adventure: Text based  games.

I'm interested in the Text Adventure but making the adventures about real places like Wray Castle so hence non-fiction

Fiction to non-fiction

What if the text in the game didn't just respond to the player but other kinds of information like from sensors?

The temperature is 24.0

What would you like to do? > north
You Walk to the North. It gets a little colder
Your thermometer says 24.0

What would you like to do? > north
You Walk to the North. It gets a little colder
Your thermometer says 20.0

What would you like to do? > north
You Walk to the North. It gets a little colder
Your thermometer says 16.0

What would you like to do? > north
You Walk to the North. It gets a little colder
Your thermometer says 12.0
Its getting chilly, only 8.0 degrees!

Adrian McEwen and I made a simple way for posting temperature data from a Dallas DS820B waterproof sensor to minecraft for  OK Sparks! and then for Text Adventures made with Twine.

Fish Detectives

Beba Me|Drink me

We used the cocklecraft-of-things so Hwa Young could potentially make a text adventure in Twine from freshwater sensors in Brazil.

We set up a Pi that would serve the game and post the temperature plus her own text  'observations' that the game could draw on

MileCastles was an artwork commissioned for the Hadrian's Cavalry Exhibition a project for  museums along Hadrian's Wall

It was a chance to take another form of augmenting a space with a game.

We liked how reading is already like a virtual space.

But we didn't really like having to carry a tablet or phone around to read it.

What if we made simple text displays and used RFID tags to store the game state?

With connectivity an issue at almost all the museums this way you dont even need a phone to play

Just a cheap tag that is like something you'd buy in a museum gift shop

Each box had a nice backlit LCD screen, an RFID reader and an ESP8266 board running micropython and AVATAP designed by Cefn Hoile of ShrimpingIt

Despite this simplicity building 25 game boxes for each museum and fitting it all on the constrained memory of the board was a huge challenge.

AVATAP was a system that allowed us as non-programmers to author games for each museum

Twine games are not really text adventures but something more like choose-your-own-adventure books.

So with no text input only a tag and a screen, choices in the game depend on which box you visit next.

How do you make and play a game with AVATAP?

We wrote up the game content and it's logic following Cefn's system, then we could test and emulate how it would play out and feel with pyglet


            uid =           "landing",
            change =        SackChange(
            goalBoxUid =    paddockBox.uid,
            nextNodeUid =   "yardArrive",
            sequence = [
                """You are stationed at the
                coastal fort of Senhouse
                You watch for attack
                from the sea!""",
                """You must also care for
                and breed horses for the
                cavalry and pay tribute
                to the gods with
                offerings & libations
            missTemplate = """Your adventure is over.
            Epona will favour {{sack.eponapoints}}
            of your horses.
            Mars awards {{sack.marspoints}} gold pieces
            for the afterlife.
            Return to {{node.goalBox.label}}
            to respawn.""",

Making Games for Hardware You've Not Finished Yet

AVATAP is a really lovely system for authoring even though it makes artists used to friendly GUIs to make their games in JSON

    Avatap provides a model for text adventures in which players travel between distributed stations
    with lo-res screens, tapping in at each station with an RFID card containing their 'game state'. 
    On the card is 
    * a storyUid - identifying which Story they are following
    * a nodeUid - identifying their position or Node in the Story
    * a sack - containing accumulated game state in the form of key:value pairs
    Nodes only represent story structure and temporary data used for screen-rendering logic. The only 
    persistent state remains in the player's RFID card. Game input takes place purely through the act 
    of tapping a station. 
    The basic load and render cycle (visible within engines.Engine) is as follows...
    *   The card is read, and the box, card, story, and sack are made available as attributes of the 
    *   The current node is set as engine.node
    *   The node's activate() routine is called, passing the engine reference. If activate() returns 
        a new current nodeUid, the activated node gets a deactivate() call, and the previous step is repeated.
    *   The final node in the chain (which did not redirect to a different node) will get a render() call
        causing a template to be generated and sent to the screen
    *   At this point, the RFID card is rewritten with the new game state, the node gets a deactivate() call
        and all state related to this player and tap is lost
    Processing all story logic through transient state within the lifetime of a single tap imposes 
    substantial limitations on the interaction model available compared to, for example, the Twine framework.
    The design of this API has focused on guiding authors who are not expert programmers to create their
    own stories using the primitives of Boxes and various specialised Story 'Nodes' and 'NodeOperators'
    which respect the fundamental limitations of this unusual medium.
    In particular, the syntax for authoring is comprehensible, consistent and exposes no python language 
    structures other than keyword arguments and dicts (lookup tables). 
    This approach is enriched by certain values being interpreted as python expressions accessing API objects. 
    A consistent set of entities is made available using python identifiers within Story templates, routing 
    and trigger conditions, (recorded in milecastles.signature), currently "engine, story, box, node, card, sack"
    The core components you need to master to create a story are the following three Node types and one NodeOperator...
    ConditionFork   - Immediately redirects to one of two Nodes in the story, according to whether its 'condition' evaluates to true or not
                      [Typically this condition will check for the state of things in the sack]
    NodeFork        - Guides the player to choose Nodes hosted at different Boxes. When you choose a Box, redirects to the corresponding Node
                      [Story validation failes if your choice nodes don't have different goalBoxes]
    ThroughPage     - Guides the player to a specific Box. On arrival at the Box, renders a page, then redirects to a specific Node in the Story 
                      [the ThroughSequence procedure creates a ThroughPage chain in which Box guidance is not normally triggered; they are at the same box]
    SackChange      - If the trigger condition is True (or omitted) the player's sack is changed according to named sets of name:value pairs
                      ['assign' - sets the values, 'plus' adds them, 'minus' subtracts them, 'reset' must be used on its own and replaces the sack completely]

One of the features of the game was the chance to engage with the context of each game box.

So in the game you could tell people to "CARRY THE STONE" or "TAKE A SELFIE". Naturally the gameboxes don't know if you do it but kids (and artists) are pretty happy to oblige

Psychogeography and Validation

The game boxes don't get in the way of the landscape: here Glenn's hamming it up on a roman street; you do the augmenting: you don't need VR.

It's a bit like exporting the game from micropython to an incredibly complex and fast neural network on a biological substrate. Your brain.

Psychogeography and Validation

We loved James Medd's Awkward Arcade cabinets which included the beautiful "Queers In Love At The End of the World" Twine game.


Twine games need an arcade of their own!

Interactive Non-Fiction Arcade

Getting data from sensors is one thing but there's a tonne of of data on the internet that our games could be responding to...

Like the text from the Vindolanda tablets on Hadrian's Wall we could display on our screens

Interactive Non-Fiction Arcade

Interactive Non-Fiction Games

So we made some games that would respond to data we found online with a domestic flavour

 We have been running workshops to help people to work out how to make these kind of artworks. We'll be using API basics, javascript, node-red and a bunch of resources


Latest Workshops

Interactive Non-Fiction Workshops

Somebody Elses Problem

By Ross Dalziel

Somebody Elses Problem

Thinking about all the game systems I've used and made!

  • 258
Loading comments...

More from Ross Dalziel