Things Happen in Particular

Coding Interactions II · 20 March, 2020

In this two-part project we were asked to identify & design for a highly specific situation using code as a form of prototyping. Specifically, designing a technology-based intervention around the notion of the personal, idiosyncratic & the highly particular.

Working with Arduino hardware, the brief involved designing for physical contexts.

For this second part of the project I chose to focus on my friend David & I; Two part-time followers of the tabletop game of Warhammer..

Warhammer Fantasy Battles

Book Worms

Besides the required financial investment, Warhammer rule books are the primary barrier to entry. Complex games regularly take multiple hours to finish. Forgetting rules or profiles may further deplete our precious free time.

Warhammer games involve players taking turns to perform actions. A player's turn loosely involves the following phases in order:

1. Moving.
2. Shooting.
3. Magic
4. Charging.
5. Combat.

During phases, a player may activate a unit in their army & perform an action. Unit profiles contain the neccessary information on how to perfom an action.

Unit profiles may be broken down loosely into the following abbreviations:

M	WS	BS	S	T	W	I	A	Ld
8	5	3	5	4	1	5	2	7

These abbreviated(for example "M" is movement, "BS" is balistic skill) characteristics are used to compare against the opposing player's unit characteristics in order to resolve actions. For example, shooting a crossbow to wound a unit.

These unit profiles are continuously referenced during a game. They are hard to keep track of when many miniatures are on the table. This leads to prolonged periods of reading.

This is where I chose to focus my attention. I began to ask how I might play a game of Warhammer & consult the rules as little as possible to spend more time chatting with my friends.

Reading the rules

Charts

During the shooting & combat phases, players must role a number of dice to hit & to wound. This is done by consulting multiple charts.

These charts take one unit's characteristic & compare it to another in order to know what the minimum value is for a dice roll to succeed.

From my research, this is easily the most annoying part of the game. It is neccessary to constantly check a variety of a unit profiles, referring to the rule books when doing so.

Actionable key insights may be summarised as follows:

• The shooting & combat phases share an forgettable chart.
• Players reference unit characteristics in every phase of a turn.
• Unit special rules are oftern forgotten or avoided to keep games simple.
• Hero units are often not used as they require larger armies with more units.
• Tabletop terrain is often used, but their rules are often forgotten or ignored to keep games simple.

Going forward, I felt it was best to focus on the shooting & combat phases as they both share instructions & take the longest to complete.

Rule book chart

Quickhammer

The next goal was to rapidly ideate solutions. Due to the physical context of Warhammer miniatures, my colleagues & lecturers pointed me in the direction of Near Field Communication(NFC) technologies.

Starting with the most promising idea named Quickhammer. The Arduino build involved the following components:

1. RFID tags to hold information on units in an army.
2. NFC shield to read the tags.
3. LCD screen to render required dice roll values.

Loosely, the solution was to attach tags to a unit & place them on the shield. The shield uses the unit's tag to load it's profile & perform a calculation to render the die roll.

Arduino with LCD screen & NFC shield

Arduino top down

Testing was straightforward:

1. The single shield was not effective enough to handle two units, often rendering incorrect unit profiles.
2. A clean visual divider between attacker/defender would prevent who-goes-first awkwardness.

RFID Upgrade

With a little help, I managed to get my hands on two seperate RFID readers. These readers were tempermental with their placement, needing extra space to work properly.

Testing the RFID readers

RFID readers need space

With a chosen layout & firm understanding of the readers, I began too code the Arduino to recognise the tags as army units. The minimum viable product included the ability to scan a tag & view it's unit characteristics.

The final layout

Next I added a button to switch between the unit's profile & the required die roll value. This extra mode incorporates the tedious charts from the rule book into the Arduino.

I then began to work on the product aesthetic. The initial idea was to blend in with the tabletop scenery. In reality, a product like this would be stuffed into a bag pack along with dice & tape.

To make it portable, a slim & simple shape was chosen.

Cardboard prototype

Laser cut prototype

Testing was recieved positively. The feedback can be summarised:

• No longer unsure about shooting & combat phases.
• The screen was too small.
  • Titles were not clear.
  • Rendering a profile should not clear on a timer.
  • Rendering the full unit profile would be useful.
• Left-to-right layout was good for gameplay orientation.

Recommendations going forward included:

• Install a larger screen.
• Include the entire profile of each unit.

David Testing Out the Reader.

Learning

This project really came together when the right tools for the job were suggested.

It's very important in scenarios like this to collaborate with colleagues & ask for their feedback. Often times they know more than you do; Even so far as suggesting entirely unknown avenues of investigation for you to follow. Such as RFID readers!