How do you decide on a design for your game's interface?

Authoring General Design Discussions
1

Let’s say you have a simple twine game, do you add any more css to it? Do you choose the colors based on the story, do you add any interface elements?

For parsers, do you add buttons for quick references and settings?

Looking back at my old projects, they don’t have any consistent features. Some have settings to switch between day and night mode, others try to add a top or bottom bar for arbitrary reasons. I’d like to learn more interface features that should be added to IF games while still keeping the story focussed charm.

Features like control over text size and background colors, or to turn on/off sounds are well known, what more do you generally add? What more would you like to add in your next projects?

2 Likes
2

I can answer for Twine :partying_face:
which is…

… depends on the project :joy:
But I almost always add stuff to the Stylesheet (unless we talk Bare-Bones Jam). Since I’ve learned how to use CSS, I can’t go back to the basic UI anymore. It needs to be all flashy and everything. /jk

I think editing the interface (whether completely or just changing colours) adds to the game’s vibe/ambiance. It can set up the mood or the setting even with some simple visuals. Like using a dark palette for a dark theme, or bright colours for a more light story.
It’s an important way to show/hide things from the player, imo.

But there is not need to be consistent between project. What one game need won’t be relevant for a different one.
The most obvious example I can think of is keeping the back button to rewinding the action. For some story, it works better not to have the back button.

Some of my examples for the interface design:
For the most interface edited: DOL-OS happens in a computer, so the interface was completely edited to look like an old computer. In The Thick Table Tavern, you mix drinks, so there is a shelf full of clickable bottles.P-Rix is on a ship, so I’ve tried to emulate a sci-fi ship screen.
Otherwise, I’ll fall back on a template (because they look sleek): Harcourt used nyehilism’s, SPS Iron Hammer used A.W. Morgan’s, and more recently, I use my own templates.

Essentially what I have in my setting templates (give or take the volume control, because I don’t always use sound): font family, font size, text alignment (not always), line height (not always), saves (name/autosave), animation toggle (if relevant), language (if I translated it), theme (if I coded a different palette).

EDIT: I just realised you asked for a Simple Twine game…
Collision → edited interface
The Dinner → not (and I won’t change it either, I think)

6 Likes
3

Thanks for the examples, checking out the games right now. :slight_smile:

3 Likes
4

So while I’m technically pushing toward parser-choice hybrids, I’m still technically using a parser system.

My process is I figure out the game mechanics, and then figure out what the player will need to plan to use them, which also tells me what info must be known.

From here, I try to come up with commands that streamline these mechanics as much as possible, and I come up with action reports that deliver the important information as clearly and concisely as possible. I also do a test to see if I can understand what is happening if the text is read aloud to me while I stare at a wall.

You are always going to have parts of your game that are awkward or take one too many steps, but the key is to not make the frequent/important parts of your game fall under that category.

5 Likes
5

Ultimately, I like to keep things simple. You’ve touched upon 2 different realms of interface design in your post: presentation and functionality. I’ll mainly talk about my process for the presentation of Twine games.

In the few half-finished Twine projects I’ve worked on, I designed the interface by identifying the main visual components. I open Inkscape and make a story screenshot encompassing all of those elements. So, yes, I do add more CSS.

My Twine designs usually cover these basic components:

  • Background Colour
  • Story Width, Background Colour
  • Story Font, Size, Colour (readability is key)
  • Game Title Font or Graphic
  • Chapter/Scene Header Font, Size, Colour
  • Divider (a horizontal line to separate content)
  • Button (used for non-story navigation: continue, restart, back, etc.)
  • Link (within story paragraphs - usually optional prose)
  • Choices (links below story paragraphs - critical decisions have more presence)
  • Information Font, Size, Colour (information conveyed outside of the story prose)

I use lorem ipsum text to help flesh out the design and all I’ve done is pick fonts and colours. I try to use background gradients and shadows sparingly, if at all. Sometimes a button looks cooler with a bevelled edge, but that’s about as frisky as I get. :wink:

It’s way easier to drag things around in Inkscape and change colours than to try and figure it out with code at the first go. Do it in PowerPoint if that’s what you know how to use.

Then I translate that look into CSS code and Bob’s your uncle.

I think it’s important to make an IF story have an identity. Using the default presentation always feels like only half the work was done to me. Having a legible story font is most important though. There are typically better ones than what is set by default.

Regarding designing the interface around the theme of a specific story, I don’t think it’s as useful as most people would think. I’d approach the design to that of an application. What would your ultimate default IF presentation look like. Colours can promote mood, but the less distracting to the story, the better. Neutral tones are best.

If you made IF that had a certain way to the presentation of all your stories, seeing that in future works would create a sense of familiarity. Think of it as a brand of sorts; an identity that feels unique to your stories.

As far as functionality goes, for a simple Twine game, you won’t really need any complicated settings. Less is more. The browser can zoom in to increase font size. The device has it’s own volume control (have a sound on/off though). Light / dark mode is pretty straight forward to do in CSS. Any other kinds of interface elements are more integral/connected to the game itself.

Interface elements should be unobtrusive and never present an inconvenience.

I guess I’m sharing more of a philosophy on the matter.

5 Likes
6

I will definitely try this for next projects. :sparkling_heart:

3 Likes
7

Thanks for sharing your design philosophy.

This is the element I am looking forward to, I plan to figure out a design with which I can update my old games so they share atleast some consistent features.

3 Likes
8

For my Twine (Harlowe) games, I usually start from a base template I’ve created that has a font size, passage width, and amount of padding that I like, and then pick colors, fonts, and backgrounds to match the mood of the game. Sometimes those features have added utility, too, like different background colors for different characters’ points of view.

5 Likes
9

That’s really clever! *puts that nugget of wisdom in his pocket*

One thing that I would love to be able to do is actual typography. A style of font to fit the context of a word; something that makes the words feel artistic.

Yeah, I think we’re on the same page.

Sometimes I imagine that my Twine story is built with my own engine. I try to make a one size fits all template of sorts. My goal is to make my game indistinguishable distinguishable from the chosen story format (within reason). Did they code it all by hand? Is this a new engine that I’m unfamiliar with? Nope, just a clever use of CSS to breathe some new life into an existing engine.

4 Likes