Tag: user interface
Maybe I write too much about text-based games, but in my defense the written word is awesome. It’s the closest you get to a digital medium without actual computers (what, with letters and words being discrete symbols by definition), and one of the most flexible as well. Communication doesn’t get more pure than a stream of symbols flowing back and forth; you can write them down on paper, ticker tape, or walls, going left or right, up or down, and even lay them out in three dimensions, as the Ancient Egyptians amply demonstrated. You do have to pick one path when reading, but hey, that’s what we call hypertext nowadays.
Early computer games, from Hamurabi (Doug Dyment, 1968) to Adventure (Will Crowther, 1976) were limited to a linear stream of text, simply because they had to run on teletypes. For the same reason, input was also limited to typing words on a keyboard. But that limitation also meant you exchanged words with the computer from equal footing — what people in the real world call a chat.
And so, a command line remained the defining way to interact with text adventures, helpers like a clickable compass rose notwithstanding. Oh, there were always a few games that tried to emulate the pick-a-choice interface popularized by gamebooks in the 1980s. But those were hardly on anyone’s radar until 2009, when Twine swooped in. At which point it became impossible to ignore all the people shouting that the emperor is naked.
Seven years ago, I discovered MUSHes and MUCKs, also known as text-based virtual worlds. I stayed for the community, but what drew me to them in the first place was online building: the ability to build text adventure settings interactively, in the same environment and in the same way one navigates the same settings: by typing commands at a prompt.
Since then, I dreamed of bringing that unique quality to interactive fiction somehow, but could never think of a way to make the concept compelling enough, especially compared to the sophistication of modern authoring systems. So the idea stayed in a corner of my mind.
Fast forward to this spring, when I had an idea for a kind of text-based RPG with interactive fiction elements. As explained nearly a month ago, part of that failed concept found new life in a Twine game prototype. But then I got around to playing Robin Johnson’s Detectiveland, and something clicked. This! This is what I was looking for: interactive fiction with a proper world model, except with a button-based interface instead of a parser (which just isn’t friendly to touchscreens… or attention spans). And because this UI is equivalent to a two-word parser, the simplified world model of MU*s would be a good match instead of a letdown. Moreover, Detectiveland has been incredibly popular, revealing a demand for retro, stylized text adventures closer to classic Scott Adams titles than baroque Inform 7 epics.
This spring, a friend of mine came up with an excellent gamebook made in Twine (now also on itch.io). At the time I appreciated not just the story itself, but also the way it worked around engine limitations to offer the player a character sheet at appropriate moments. And Kris isn’t the only one making RPGs in Twine, as I started to notice more recently. Which is a bit of a problem when using an authoring tool designed to display one passage at a time from a choose-your-own-adventure story, and not much else.
But what if I told you Twine has another face, one that allows you, with minimal effort, to make games with all the usual bells and whistles:
- a proper save dialog with multiple slots;
- more generally, a modal dialog system;
- graphical user interface elements;
- a fully customizable sidebar;
- toolbars and status lines.
It’s called SugarCube, and it’s as well-documented as it is powerful. Also heavyweight, which is why Twine 2 ships with the older, less capable branch in the package. For some reason, however, its capabilities aren’t well-known, even though plenty of Twine-using authors prefer it to the default Harlowe.
Funny how much morale matters in game development. While this weekend I was in no condition to work on Laser Sky, the game was in a condition to be seen by a few early testers, and that gave me the energy to go on. Not that the feedback was so great: everyone’s first reaction was to call it sluggish and unresponsive. It didn’t feel that way to me, but when three people say you’re drunk…
So the first thing I did on Monday morning was to make the player’s ship accelerate just a little faster. Which, to my surprise, improved the game balance, and subsequent testers merely remarked the game is slow-paced. In other words, exactly as intended. Success! Most of them also praised the graphics, though one tester was put off by the same “paper airplane” enemies another loved. There’s no accounting for taste. And hey, both of them recognized the inspiration despite the abstract shape. Go me.
Anyway, as predicted last time, the rest of the day was spent adding sound effects. They’re from the same Creative Commons pack I used for Attack Vector, except a different selection (twice as wide, too), and with no additional sources. So the two games ended up sounding nothing the like. Couldn’t locate any suitable music, but a friend offered to help with that, and from what we discussed it seems we’re on the same wavelength. So this should be great.
Hello, everyone! After bringing the desktop port of RogueBot to a playable state, I went back and redid the original online edition as well, to make it look better and bring it more in line with the new version. And while the results aren’t perfect, it’s a good time to take a break and give another project some love.
In the mean time, we have an interview with two Greek game developers about adventure games, and a feature about the founders of Id Software now that they moved on. In the way of hands-on gamedev articles, you can read some musings on making failure fun, and some more on the subtle differences between user interfaces. And while the latter uses examples from interactive fiction, the lessons it teachers are widely applicable.
(Since I mentioned interactive fiction, it’s worth nothing that the XYZZY Awards ceremony was last night, and Birdland, a Twine game, basically took all. Haven’t played it yet, but it’s at the top of my wishlist.)
And from the same Emily Short, who is active as always, stay tuned for the upcoming Bring Out Your Dead game jam, an event where you can show off your works in progress that never went anywhere, but you think are worth seeing anyway. Amusingly enough, another very similar jam is running right now, and I already entered my visual novel intro Before the Faire, that I made two years ago but couldn’t finish, despite a good start.
Last but not least, lately I’ve been circling a nice little gamedev platform called sdlBasic, that I hope to use in an upcoming project. While lurking on their forums, I found a link to this list of art asset resources, unknown to me until now. One link in particular grabbed my attention: game-icons.net, a sizable repository of monochrome vector icons with a variety of possible uses.
But I have to look more closely into it first. Have a great week.
Born of technical limitations, parser-based interactive fiction has proven to have enduring qualities. Fans of the medium invoke the natural feeling that you’re simply having a conversation with the computer, as well as the impression of freedom — that for a while you can suspend your disbelief and pretend you can type anything at all at the prompt. Myself, I like how you can easily see what you did a moment ago, so there’s less to remember, and just as easily repeat a recent command, with or without changes, no matter how complex it is.
The downside to that, of course, is that the illusion of complete freedom shatters all too easily, and that presumes you were able to enter “the zone” in the first place. Which just isn’t for everyone. Commands have to be learned, you can’t just stumble upon them like in a graphical game, and despite many attempts at tutorials, both interactive and less so, beginners still struggle. Perhaps because tutorials can teach you the form, but not so much the mindset — the method behind the madness, that you need in order to intuit new commands by yourself. The latter is something you must figure out alone. And sooner or later, you will have to.
Because, you see, not only does interactive fiction partly rely on discovery — on making some possible actions non-obvious — but there are way too many commands to teach them all outright. If I’m not mistaken, top-tier authoring systems each provide about one hundred default verbs, of which three quarters will be completely irrelevant to any particular story. But you still have them at your fingertips, and unless the author takes great pains to steer you away from all that fluff (an undue burden, considering how many other details they need to take care of), you’ll be left to navigate a maze of fake options in search of whatever nuggets of meaningful interaction are sprinkled throughout.
It’s one thing to gently weave a consensual illusion, and another to actively mislead the player, then shrug and smile when they call out your lie. (continue reading…)
Used to be, games didn’t need a proper Graphical User Interface the way applications do. They’d show a title screen, you’d press fire, the game would start. After game over, they’d show you the high score list and that was that.
Nowadays expectations are a little higher. Any game needs at least push buttons or some sort of menu, so you can see the credits, choose your language or turn off sound. As a next step, you’ll also need a dialog pane, textbox control and image control so you can depict an NPC speaking, for example. By the time you move on to strategy games, we’re talking sliders and spinners in addition to the lists you need for, say, an RPG — practically all the controls in a full-blown GUI toolkit. And that’s a problem, because the latter aren’t easy to make at all.
But what if you could make a game using a general-purpose GUI toolkit, say Swing, or Gtk+?
That wouldn’t fly for a lot of games, mind you. Regular GUI toolkits are too slow to render in real time, and they don’t render to OpenGL anyway, as a general rule. They also don’t have visual appeal as a primary design consideration. (Unfortunately — I’ve talked to many people who think they should. But see below.) Still, that leaves plenty of open possibilities, as I’ll explain in a moment.
I’ve been wondering as of late if it would be useful to make a hierarchy of games by the level of user interface technology they require. For instance, the original Adventure only requires a teletype for output (and input, see below). Rogue already needs a character-addressable display, say a videoterminal. Once you can work with pixels, you can make anything from Dizzy to Doom. And then you have the vector displays arcades experimented with for a while, back when CRTs were still a thing.
Beyond that, things get more blurry. I mean, obviously most modern games require 3D acceleration, but that’s only a matter of quantity, not quality. It’s entirely conceivable that future CPUs will be able to render in software games we can only run on expensive GPUs right now. But for now the distinction may still be meaningful. Or is it?
Or we can look at input. Much has been written about single-key games, but what about games that can be played with only a D-pad and one action key? (Think feature phones.) Games that can be played with just the mouse? Never mind what can be played with the keyboard alone — that covers everything from the aforementioned Adventure and Rogue all the way to *Master of Orion*. But gamepad support on PC games is such an uncommon feature nowadays to warrant its own tag in various catalogs.
The question is, what could such an analysis teach us outside of a better historical understanding of how computer games evolved?
It’s a week with no links again, so if you don’t mind I’ll take the time to rant on a topic that’s been obsessing me for a long time now. Be warned that this is only tangentially related to games.
But first, a signal boost.
I’ve never played Glitch, but I heard of it closing down when they released their assets into the public domain (a great initiative), by virtue of hanging around with the Open Game Art crowd.
Turns out, a friend of mine seeks funding to create what she’s describing as a text-based prequel to Glitch. And while I dunno about the project, Generic Geek Girl‘s portfolio is enough of a recommendation for me. Take a look.
Now, on to the main topic for today: graphical user interfaces. Fasten your seatbelts.
I’ve been playing a bunch of old DOS games as of late (instead of working on a game I might add). As you might expect, they’re a mixed bag, and that’s not because of their age. But even in games that are still fun to play — and trust me, there are quite a few — I couldn’t help but notice certain problems that show up again and again. Worse, they show up before I even get to play the game proper. It makes you wonder, didn’t they play each other’s games back then?
And then I realized why these problems seemed so familiar: because I still routinely encounter them, e.g. in Flash games.