Sigil Reader (Field) post-mortem

This was my first entry into the IFComp, and I’ll be honest: ideas for improvement proliferated as the comp went on and as I read reviews.

This game started as a purely exploratory game (like Staying Put), and Inform 7 remains one of my favourite tools for creating spaces. To get people to explore these spaces, though, I needed a story. The first thing that occurred to me was something along the lines of ‘something terribly wrong has happened here, you need to figure out what’, which… tends to be my go-to. For some reason.

A lot of what I learned from the reviews (and from my beta-testers) was basic storytelling and writing principles, and a few of these are highlighted below. There is much I have yet to learn.

The good:

  • setting
    • There are what I hoped would be distinctly Singaporean/Southeast Asian flavours to the setting (the calendar, the pickles), with an extra layer of weirdness (the rabbit skull).
    • There were comments that it had a definite sense of place, which was what I was angling for.
    • However, an office space suggests routine and mundanity – not great for a game! Sigil Reader didn’t allow players to do sufficiently un-office-like things (I’m thinking of Michael Gentry’s Little Blue Men and Arcane Intern (Unpaid)) to make the setting an efficient starting point for an urban fantasy story.
  • Juxtaposition of the urban mundane with the ~~magical~~ stuff.

The bad:

  • SPAG and technical errors
    • I should have done much more proofreading. That is all.
    • There were a handful of synonyms that I didn’t anticipate, and added on in an update early in the comp.
  • Links between objects the player needed to interact with and story progress
    • This game makes frequent use of events which were triggered by changes in stats (which themselves change when the player examines or does certain things). When these were announced to the player, they seemed incongruous: the event seemed unlinked to the action that triggered it.
    • I’d say this is due to poor signposting – a failure of communication.
  • Lawnmowering
    • Some players complained about having to go through every room and comb through objects, in a bit to find the one which would unlock the next part of the story. Again, this was a failure of signposting.
  • Ignoring the most novel thing about this game
    • The sigils, that is! Days before the deadline, this was only 10% implemented, and I realised that this would most likely involve designing a few new puzzles, something I struggle with.
  • It was hard to establish emotional stakes
    • The PC is emotionally very attached to Station 31, in no small part because the staff of the Station see each other all the time, but it was hard to communicate this to the player, especially since there were barely any NPCs, so the PC never gets to act out these relationships.
    • We meet the PC as a ghost, so at the start of the game the PC has no influence over the fate of our co-workers or the setting; the PC acts purely for themselves.
  • It was hard to signal progress to the player
    • I used a numeric indication in the status bar, showing three domains in which the player could grow in knowledge (namely: the PC’s relationship with their colleagues, the PC’s knowledge of the past and the PC’s knowledge of sigils.) I found this distracting, though, and didn’t want it to lead to lawnmowering. Not that removing the numerical progress markers changed things…

What I learned:

  • the importance of signposting – it took lots of ironing out from beta testers to figure out ‘blind spots’, or spots where I’d expected the player to read my mind. I fear it may have become too obvious in parts.
  • There is an extraordinary demand for puzzles in parser games. Puzzles are a way to gate story content, but here I did not intend for them to part of the appeal of the game; I wanted the appeal to be the revealing of memories. But then there were reviews from what were obviously experienced parser players who were unsatisfied with the simplicity of the puzzles.

Plans:

  • Sigil Reader (Field) suffered for its under implementation (despite everything!) so… either set parameters clearly, laying out what is unimportant to the player and testing, testing, testing.
  • Link important objects to events so that it’s clear how the player’s actions are affecting the game world and their progress
  • Letting the player >INSCRIBE and >INSPECT
    • I want the player to be able to play around with the sigils; the PC is, after all, the only one in the station who knows how to handle these with dexterity
  • Greater customisation of playthroughs depending on the PC
    • I liked the idea of having multiple, distinct set PCs to add flavour to the experience, but this wasn’t implemented much in the comp game.
  • Creating puzzles and making them flow is still something which unreasonably puzzles (ha) me. I’d like the puzzles to make sense in the context of the story. A bit of reading is in order…

TL;DR: made some silly mistakes, post-comp version will probably take much longer than expected!

Open That Vein

By Chandler Groover. (Parser; IFDB)

viewgame.jpg

(Cover art: background image of vein; foreground: OPEN THAT VEIN/Chandler Groover)

This game was written for Ectocomp 2015.

It’s simple: you have to open that vein. But the vein is just the start of your troubles: you’re chasing… something.

[Warning: this game contains gore/body horror.]

Open That Vein worked impressively within its self-imposed constraints, since the PC could only interact with any noun in very limited ways. Even more impressive knowing that all this was coded in three hours.

The game is linear, with extensive use of cutscenes at important points, and this is what lets Groover’s descriptive, evocative writing shine. The details he gives home in on the visceral. He gives glimpses of images, gorgeous vignettes, though they didn’t immediately make sense to me. There’s a lot of mention about things ‘feeling right’, which I’m still trying to parse.

As with Midnight. Swordfight, this work also makes use of a limited verb list, but the game also supplies suggested verbs without prompting, so a player new to parser IF should not have a problem playing it. This design decision adds an example to the ongoing discussion of how to make parser IF more accessible to new players. Groover solves this by telling the player what to type, and by moulding the game environment around the constraints of the limited verb list. A limited simulation like this works well for short works, but one wonders if this couldn’t be extended to more open-format/sandboxy works – maybe with a gradually expanding verb list? Commands you can ‘discover’?

The procrastinator speaks

A personal reflection after attending the Ada Lovelace Evening Exchange event, in which Emily Short (!!) was the speaker. (Of course I was much too socially awkward to talk to anyone)

This is the blog of a doyenne of procrastination. I procrastinate so much. I start loads of projects and never finish them. I have uncounted numbers of IF works-in-progress waiting to be finished. Yet, tonight a group of friends produced a rather rough-hewn but nevertheless complete work of IF in record time! How is this?

(Apologies if this is all familiar stuff to you.)

1. Start by thinking about the ending.
Usually, I start with a high-level idea – a monster-hunting story with red tape – which is, after all, how story prompts are structured. That peters out very quickly, because there’s no central spine. These ideas never have specific endings in mind, so it becomes ridiculously hard to continue after the initial burst of inspiration.

In this event, though, I think we were supposed to start writing to practice how we could implement different story structures, so we started with the end in mind – no words, no fancy ideas, just plot. I found this really helpful in distilling the skeleton of the game, and in the end it was surprisingly easy to write!

2. Don’t get attached to ideas.
This slows me down so much. At the start of a new project, I can become absolutely consumed with the possibilities – which are endless- for the game. I think of branches and all that. But as the story goes on, there are paragraphs which I like – and which aren’t necessary to the plot – or there’s a moment which I can’t bear to throw out – retaining sentiment for useless parts ultimately bogs the game down. Now, I try to maintain a ‘cutting floor’, where aesthetically pleasing but pointless bits go, and hopefully this will keep me focused on a good structure.

3. Test only after implementing another section of the story/another idea
Testing too often slowed me down a lot. While this is very helpful for catching out basic problems (especially if you’re new to the language), this made me focus a lot more on how it looked and the flavour text rather than the game in the big picture. For my future writing, I’ll try to only test once I’ve completed a chapter/part of a major chapter, to make myself continue writing the actual content instead of fiddling with little bits.