Ross Dalziel
Artist who sets up activity, events & makes systems to explore how knowledge is produced and shared.
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
- ROM Hacking of Earthbound
- Minecraft of course lord of the mods!
- Text Adventures with Inform and Twine
Moddy Game Systems
Minecraft
CloudMaker
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
- 3D Printing with Printcraft
- Homeostasis
- The Internet Of Things
- Or the Whitworth Art Gallery
- Or Water and Electronics (not usually a good idea)
RF-Craft
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
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
ThroughPage(
uid="firstLanding",
goalBoxUid=entranceBox.uid,
page=introText,
nextNodeUid="landing",
)
ThroughSequence(
uid = "landing",
change = SackChange(
reset=story.startSack
),
goalBoxUid = paddockBox.uid,
nextNodeUid = "yardArrive",
#23456789012345678901234
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
engine.
* 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
Interactive Non-Fiction Workshops
Somebody Elses Problem
By Ross Dalziel
Somebody Elses Problem
Thinking about all the game systems I've used and made!
