Conveying Game Information

All games are required to inform the players of the game state, available options and invalid moves. In traditional board games, this is done by expecting the players to read the rules and through game design (such as possible spaces being physicall marked or blocked). A technology enhanced board game has the potential to innovate on these requirements using digital components.

For our game, the requirements are to:

• Convey the state of the game. This includes
  • How many stakes have hit dracula.
  • The number of bites the players have received.
  • The number garlics have been used or are available (within each round).
  • The number of stakes a player has.
  • The number of lights the player has.
  • If a garlic has hit dracula.
  • If a stake has hit dracula.
  • When dracula bites, which player was bitten.
  • Which player turn it is.
  • When the game is lost.
  • When the game is won.
• Convey any rules violations, and ideally instructions on how to fix them.
  • A dead player moving on the board.
  • A player moving when it's not their turn.
  • A player casting light or throwing a stake to inaccessible locations.

Metrics used for each solution include:

1. Useable by the players.
2. Easy to implement.
3. Allows for flexiblity.
4. Minimal user interpretation.
5. Provides code for our git repository.
6. Can output multiple error states.
7. Scales well with game complexity.
8. Aesthetically pleasing.

Technical criteria that must be met in the rubric include:

• Assessment 2
  • "An exceptional justification of design and implementation"
  • "An exceptionally feasible product that meets the intent of the brief"
• Assessment 3
  • "The prototype has exceptional levels of usability, is easy to run and test"
  • "It is an outstanding prototype product"
  • "The team’s codebase is exceptionally well architected, demonstrates excellent software/IT development practice and quality"
• Assessment 4
  • "The student shows exceptional reflective thinking on how to design, deliver and evaluate a project based on a brief and on time.

Where the intent of the brief is:

• Problem space - "the game can offer enhanced interactivity, automate rule enforcement and scoring, provide dynamic content, and create a more engaging and immersive experience for players"
• "This project necessitates the development of a hybrid board game that combines traditional physical components with advanced technological enhancements."
• Must have "Physical board game components ... integrated with technological enhancements"
• Must have "An engaging and interactive user interface for the digital component, if applicable."
• Must have "Clear instructions and seamless interaction between physical and technological components."

---

Since users must be able to sense the information, we can broadly classify interactive feedback into the following categories:

• Alfactory. Not applicable.
• Taste. Not applicable.
• Tactile
• Visual
• Audio

Tactile

Game pieces and cards

• The shape and size of pieces can convey state information.
• Since part of the critiera is the use of these game components, these must be included in the game, but there is manufacturing overhead in designing differently shaped and sized game pieces.
• These may be appropriate for keeping track and conveying individual player state, but cannot be used for conveying any hidden information.

Metric	Score	Metric	Score
Usable	Yes	Easy to implement	No
Flexiblity	Yes	Easy to interpret	No
Codeable	No	Conveys errors	No
Scales well	No	Aesthetic	Yes

Vibration

• Vibration can be used to convey urgency and action, and requires hardware overhead for little gain.

Metric	Score	Metric	Score
Usable	Yes	Easy to implement	Moderately
Flexiblity	No	Easy to interpret	For simple information.
Codeable	Yes	Conveys errors	No
Scales well	No	Aesthetic	No

Visual

Position, shape and colour of the game board, pieces and cards

• Traditionally game pieces and cards are used to convey state through placement, proximity, and counting.
• Since part of the critiera is the use of these game components, these must be included in the game.
• These are appropriate for keeping track and conveying individual player state, but cannot be used for conveying any hidden information.
• The project brief specifies automation as a goal of the project, that should be done with computational elements.

Metric	Score	Metric	Score
Usable	Yes	Easy to implement	Yes
Flexiblity	Yes	Easy to interpret	Yes
Codeable	No	Conveys errors	Possibly
Scales well	Marginally	Aesthetic	Yes

LEDs

• LEDs can be turned on and off to convey boolean states, and can provide colour to introduce a high degree of change.
• These states require interpretation by the user and have mental overhead, and therefore do not scale well with complexity.
• For simple states LEDs can be aesthetic and easy to implement. For displaying error states or more complex information, user interpretation and scalability become an issue. This could be mitigated by providing adjacent information such as text alongside the LED, but is still not scalable.

Metric	Score	Metric	Score
Usable	Moderately	Easy to implement	Yes
Flexiblity	Yes	Easy to interpret	No
Codeable	Yes, but not complex.	Conveys errors	Only simple errors.
Scales well	No	Aesthetic	Depending on circumstance.

Digital Displays

• Digital displays are the most conventional solution to conveying state information.
• They are very flexible in the information they can convey with text, graphics, visual divisions and animation.
• Only code changes are required to change displayed information, with no physical redesign or movement required. This allows for faster iteration of designs, easy addition of new information, and time freed for implementing finer details.
• The available surface area of the display means any information can be displayed, that scales very well with game complexity. Displays are familiar with users, making them useable and easily interpreted (with appropriately displayed information).
• A display would require code to drive and show information that has overhead but also reduces the risk of under-allocating workloads.
• Appropriate graphics and symbols for information and error states is aesthetically pleasing, improving user immersion and engagement and seamless interaction between technological components.
• Contributes to all the above criteria rubrics and the project brief expectations.
• Another critical benefit of a display is easily conveying solutions to the error conditions, that all other methods cannot do, and is a project brief expectation.

Metric	Score	Metric	Score
Usable	Yes	Easy to implement	Yes
Flexiblity	Yes	Easy to interpret	Yes
Codeable	Yes	Conveys errors	Yes
Scales well	Yes	Aesthetic	Yes

Motorised manipulation

• A motor the moves the position of physical media can be used to convey state information.
• The physical implementation of this is the largest requirement, and requires more intricate design of electronics, power, current and voltage requirements (may require buckboost regulators, MOSFETs, etc), making it harder to implement.
• Does not scale well with game complexity, or number of errors.
• If done right, would be aesthetically pleasing.

Metric	Score	Metric	Score
Usable	Yes	Easy to implement	No
Flexiblity	No	Easy to interpret	No
Codeable	Yes	Conveys errors	Marginally
Scales well	No	Aesthetic	Yes

Electrical visualisation

Audio

Buzzers

• Buzzers are commonly used to indicate simple errors and events, such as the board game "Operation" that buzzes when you touch something you shouldn't.
• Would have electrical design overhead, and part ordering, but not too bad.
• Not very flexible since a buzzer typically has limited range.

Metric	Score	Metric	Score
Usable	Yes	Easy to implement	Yes
Flexiblity	No	Easy to interpret	Depending
Codeable	Yes	Conveys errors	Minimal
Scales well	No	Aesthetic	No

Speakers

• Similar to displays, speakers are the conventional option to convey information as audio.
• Speakers are highly usable by the players when producing verbal instructions and audio effects. Scales well with game complexity.
• They are aesthetically pleasing depending on sound design, such as music and atmosphere.
• Can output multiple error states depending on sound, but can be hard to interpret.
• Contributes towards all the
• Unfortunately hard to implement without prior experience.

Decision

In my opinion, we should use a combination of

• Game pieces, for user interaction (also tagged with RFID) and required by project brief.
• Display for all other state information for tracking, and to convey hints of hidden information.
• Maybe LEDs for simple information if appropriate, and contributes something more than display for the given context.

User interaction Design Process

Interaction Elements

Tokens and pieces

• Displays player position (but not necessarily aligned with game internal state - errors)
• Displays number of garlics available in a turn, because there are 4 garlic tokens
• Displays location of water/sunlight/players but does not show when those are accepted into the gamestate

LEDs

• Displays number of water/sunlight for each player
• Displays which player's turn it is using colour
• Displays effect of Dracula's actions on player pieces
• Could be used to (sommehow) give a clearer visual indication that a player's move has been accepted/an error has occurred
  • Could flash red for errors and some other colour (but not green) to show accepted moves
  • Should probably also be a distinct visual cue for when Dracula is found because that's kinda important

Buzzer

• Used to notify users of a successful piece scan, alongside LED lights

Display

• Displays updates to gamestate - outcomes of actions
• Displays error messages
  • Must display what the error is and how to fix it
• Displays dracula and player health

Questions

What is displayed all the time?

• Dracula and player health probably need to be displayed constantly
  • It is important info that should be accessible at all times and isn't shown anywhere else (currently)

What about temporary information like effects of Dracula's actions and if the players hit Dracula?

• If it gets displayed until the next message comes through, when do player turn prompts get shown?
  • Could just not be shown at all
  • Could be confined to a third area of the screen

Design ideas week 7

Information to convey:

• Player turn: LED tape
• Player health: currently LCD display, although could potentially be done on LED tape (or a new component for this specific purpose)
• Error messages: LCD display, remains there until the error is resolved
• Responses to actions: LCD display, remains there until the players take another action
• Visible response to player actions: Noise on buzzer, slight flash on LED tape
  • Important because it provides instant feedback that a player's action is accepted or rejected
    • Like when a button changes size briefly when a player clicks on it
  • Can also use different noises for Dracula being found or not being found
• Player resources: LED tape (center of side)