The next step in Cellular City’s development is designing a set of options for the text to speech voicing in the game.

I’m doing this for two reasons:

1. While I think the current setup is effective for someone who already knows how the game works, it doesn’t sufficiently support new players (hey look, a classic UX problem)
2. Me and some friends are starting development on a game for the Access All Summer Game Jam, which will also have voicing and potentially significantly more complex requirements for description, so thinking about the design process this seems like a good idea.

If you’re wondering why I’m focusing so much on accessibility now, rather than fleshing out more mechanics or narrative, my goal in building accessibility systems first is it reduces workload and ensures that I’m considering how each mechanic will be communicated while I’m designing it. (I’ll talk about this more in a future week when I’m looking at implementing double buildings or demolition into the game.)

Initial design thoughts:

I’m primary looking through the lens of information availability:

• What information does a player need to navigate?
• What information does a player need to progress?
• How can a player access information they might have missed?

There are four sets of needs which I think need supporting through system adjustments:

1. First time players
2. Returning players (currently best supported by current system)
3. Advanced players
4. Text-only players

Considerations:

Information speed

Different channels often deliver information at different speeds, and are good at delivering different kinds of information. TTS tends to be slower, as it has to deliver information in a specified order. This can lead to problems with time pressure and cognitive load.

Cellular City is turn based, which fortunately reduces time pressure concerns (although players still want to get on with things, so speech should try to be efficient.)

Long chains of speech also place a high cognitive load on a player, and makes it more difficult for a player to access a specific piece of information for a set of speech.

Existing designs?

Conventions are often used to reduce cognitive load in situations like this.

However, I don’t have the lived experience to identify effective conventions and there aren't widespread conventions within games which I could rely on a player being familiar with.

That being said, the part of the system I’m most confident in is the map reading, which takes design inspiration from the methods used for Chess (In essence I’m copying some of the work and playtesting done by the Braille Chess Association). 

Game feel

To me this is the current biggest challenge: Does the game maintain its feel when playing with a second channel? And is it actually fun?  

Cellular City is entirely driven by world feel and relies on that world feel to drive its narrative, so if that's lost for a player using access features then the mechanics might be accessible but the experience isn’t.

An example here is the difference between Cellular City and Monsters of the Greenwood, where the design originated. Cellular City starts by speaking out the whole map, where Monsters of the Greenwood doesn’t. You need the entire playspace to start considering a puzzle, but not describing it helps build a sense of mystery

(It also lets Monsters of the Greenwood have larger levels)

Current Design:

Breaking down the current voicing scheme:

• Start Screen: “Welcome to Cellular City, press any button to continue”
• Menu/Settings/Keybindings: 
  • On focus: “Item name + position and number of items in menu”
  • On pressed: “Option selected” (i.e. true, false, value)
• Levels:
  • On start: Tutorial text + “Describing city” + Level Layout (A1 is empty, B2 is Flats…) + Buildings to place.
    • This is the place I'm most concerned about cognitive load
  • On cursor move: Tile contents (B2 is Flats)
    • If the edge of the level: “Level edge”
  • On place: “Building name + placed + location”
    • Plays incorrect sound effect if impossible placement
    • Plays building sound on possible placement
  • Undo: “Building name + removed + location”
• Guide:
  • When opened, says each building in the level and its relevant likes/hates
• Buildings:
  • When prompted, re-lists the buildings to be placed
• Inspect:
  • When over a building, gives a custom description of that building

(more on these in a future devlog)

For example: "Brutalist streets in the sky. Always controversial with neighbours near and far"

• On level finish: “Score: some number + next level”

Key Question: Missing information

Returning to the initial design questions:

• What information does a player need to navigate?
• What information does a player need to progress?
• How can a player access information they might have missed?

Figuring these three out for the levels: To navigate the player needs their current cursor position

To progress the player needs the building they have to place, the neighbours of empty spaces, the hates of buildings.

Information can be replayed with cursor moves and the Buildings key.

For Menu navigation, one I feel is missing some information:

To navigate the player needs their current menu, position in that menu

To progress the player needs to know their current menu, the position in that menu, the state of the option they’re looking for, and when they move between menus.

Here we can identify problem: players aren’t told when they’ve moved between menus, might block progression.

Identifying these issues is a key part of playtesting, as it's really easy to miss missing information as a developer, afterall you know where everything is, you put it there! 

What the settings change:

This isn’t going to be exhaustive, in part because I think these are going to adjust with playtesting and with further iterations. The returning players category will still work for the current design, so I’ll describe each setting based on what each setting adds and removes.

First time players

The most extensive changes are focused here, because feedback from players suggests this onboarding is a bit painful. 

The first addition is a current open menu readout (this will also be added to the returning players menu), to help address the missing information we noted before.

The second addition is in back buttons, again addressing the missing information blocking menu navigation, by having back buttons voice where they will take the player to.

The final addition is the one I'm most likely to adjust: readouts of menu background images, such as the game's title page. This could also be handled by an extension of the "Inspect" button, making it a general purpose instruction for the game to describe the scene, however I also want it to run on first time start-up, so I'm not entirely happy with the player just having to know that they can inspect non-tilemap scenes.

Advanced players

The idea of this setting is to let players who are familiar with the menus further cut down speech (alongside settings for speech rate). 

Primarily it skips menu position readouts, alongside tutorial text on level replay.

Text-only players

This setting only reads menu text, supporting players for whom the zoom is a better way to view levels but find menu text difficult to read. The primary block on this is UI zoom on the building UI. At present the zoom only works in levels. While voicing the building menu could support this in the short term, that relies on building names and sprites being easy for a player to link, which isn’t very easy for folks not from Sheffield. 

Final thoughts

Tutorialisation needs a look, with many of the voicing options requiring players to input additional buttons and just listing these on the demo page isn’t ideal (nor is having players dig through keybindings to find them). This is probably fixed with a dedicated TTS tutorial.

You’ll also notice I brought up game feel as a concern in the beginning, but then didn’t really circle back to it outside of the inspector button. This is because I’ve not come up with an entirely satisfactory solution, and perhaps that solution lies in the rest of the game's soundscape. Rain certainly would make the game feel more like the north of England..

Further reading:

Braille Chess Association:

https://braillechess.org.uk/

Laura K Buzz’s review of Stories of Blossom’s audio description: https://laurakbuzz.com/2022/10/21/stories-of-blossom-nails-point-and-click-audio-descriptions-access-ability/