This is mostly addressing Patrick's Parsing Problems, but anyone with an interest in UI might find it interesting.
When designing something, the most critical thing to know is what the thing has to do. Then you design it to do that task efficiently and beautifully.
The problem with UI design is that most people don't know what their UI is supposed to do. Not clearly. So they overdesign and go astray.
There are three kinds of UI: static, parsed, and reverse parsed. These are the only three kinds of UI anywhere in reality. There are no other options, although many UI are actually several UI wrapped together, often of multiple types.
Static UI are the most common in computer applications. These are usually an array of menus and icons. The user always has all the options, although they often have to dig deeply to find the particular one they are looking for. Static UI can be as opaque as a 3D toolkit or as transparent as a number pad on an ATM.
The primary joy of this system is that it is really easy to design, but at a more fundamental level, it is also very useful for complex systems in which you might be controlling several different aspects simultaneously - or need to be able to make new aspects immediately. It is also useful for systems which you use a lot, because you'll become very adept at navigating them. In a game design, however, this system is usually the most inefficient.
Reverse Parsed UI are essentially dolled up static UI. This interface only offers you the options that are directly applicable to the situation at hand. The most common reverse parsed interface is right-clicking on a Windows machine. Games also commonly use reverse-parsed interfaces - everything from the RTS game which shows you unit commands to the Sims, which uses a snazzy-looking right-click menu.
The primary strength in a reverse-parsed UI is ease and simplicity. It is exquisite for controlling diverse elements in a very easy and transparent manner. Because it typically wastes a click, it is slightly slower than static UI, but is easy for a beginner to use.
Parsed UI are more common than you might think. A parsed UI is any system which uses a complex multivariate input to conrol the situation. The most common parsed UI? A mouse. Of course, a mouse is a computer UI, and most programs use the mouse to interface with a static or reverse parsed program UI.
A parsed UI is useful for differentiating between at least a hundred nearly identical options. For example, which angle to fire a bullet at. Where to place a pit trap.
That is the only thing a parsed UI should be used for.
Now, that might sound zany. For example, a program is a parsed language. But when you build a program, you build something out of a million different, mostly identical pieces and aim them at each other very precisely. Functionally, a program is a set of objects which are picked and aimed carefully from a truly staggering number of options.
But the thing about a program is that you are actually using a static interface (plus a little reverse goodness with tab completion) to interface with this parsed UI!
How zany is that?
You're taking a parsed interface (your body), ignoring the other parsed interfaced (your mouse) in favor of a static interface (your keyboard) with which you use a parsed interface (the programming language).
Why? It's a matter of precision vs range.
A mouse doesn't work very precisely, or very quickly. But because it is a parsed system, it has excellent range, able to skip over huge numbers of identical options to pick roughly the option it wants. Buttons are large specifically because of the precision loss.
A keyboard is very precise, but is "local" - since it's a static UI, there's no way to get far from where you are short of typing additional letters. The more identical options, the more letters. But once you get there, you are there exactly.
Of course, a mouse is intuitive and a keyboard is not, and there's something to be said for that, as well. You could make a keyboard "jump" to specific menu locations using mapped keys (some games do this), but it requires more memorization.
Fascinating stuff.
Anyhow, does your game require choosing from a hundred nearly identical options? If not, you do not need a parsed system. And if so, you only need a parsed system for that part of your game.
Understand what your UI needs to do, and give the user the most efficient UI for the task. Choosing a UI because you think it's a kewl koncept is silly, and will piss off your players unless it is specifically serving a game purpose efficiently.
9 comments:
As usual Craig, you are thorough and comprehensive.
I think there is some incongruity in our respective usages of the word "parse". I meant it in the sense of a sequence of inputs being interpreted as a chunck value, for instance, the static interface of a keyboard lays down strings of text which are parsed into meaningful units, such as in a compilier or an IF interface. While its true that a full blown approach to the circle interface would classify as a parsed interface, where everthing has to be drawn in letter by letter, the mouse-to-draw-symbols template can also utilize static or reverse parsed schemes.
For example, a schema I didn't include in my post could address every ur-verb to one of the twenty symbols, making it a static interface, though as you point out that'd be much more elegant as an icon or menu system.
A reverse parsed schema would be the casual framework I suggested, here the mouse makes a lot of sense for its intuitivy, since degress of verb input are on the table.
Brenden and I were dicussing supplementing the full parsed interface with menus and icons earlier, and context sensitivity has been on my mind from the get-go. In light of this post, I'm considering having the full interface use more standard static interface conventions more heavily, with the parsed aspect reserved for selecting specific spells.
As you said, most interfaces use a combination of the three approaches. My idea was to layer schemas to accomadate players comfortable with different levels of complexity. I hope this idea passes the Perko Bullshit Filter (tm).
Worf Verification: dataz
Thats what cool kids use to mean plural data.
What does using a drawn interface get you that using menues doesn't?
Two things, first theres the mimicry effect of making phsyical motions in the same way the characters presumably do to cast spells and signal to each other. You could dismiss that as a gimmick, and thats fine, I suppose thats the "kewl koncept" on the table.
The other thing is that, as you said, using a mouse is much more intuitive, particularly to a casual player. The nature of the symbols synchs nicely to the vector/distance properties of the drag that determine the resulting symbols, and I think that is seductive enough that a casual player could get interested from tasting basic play. I'm not opposed to including menus in streamlining the full functionality of gossip, commands, complex tacticts ect, but I think having a fairly pure and simple interface concept at the core will make the game "travel" more.
I believe when it comes to a broad audience, up-front complexity kills.
I happen to agree: complexity kills the casual player.
But I think "complexity" includes having to figure out how to write twenty different symbols, and figure out what they do.
Plus, have you tried using a mouse to write these symbols? I can do it real fast with my stylus, but a mouse feels sloppy and unresponsive. You'll have to be very careful on the UI...
If you want examples of games using the mouse to draw spell symbols, it was used in both Black and White and Arx Fatalis, and in both they were pretty annoying. Arx at least allowed you to prepare spells ahead of time and "cache" them, making the whole "writing spell symbols" a bit more tollerable. In both they came off as "kool koncepts" that never really did what the designers hoped to achieve.
Here's an interesting concept though, a UI that "forces" you to draw symbols in your attempt to make letters. Stay with me here...
When you enter your spell making phase, you're given a menu of possible starting points for symbols that appear in the proper poitns on screen, with each starting point meaning something different. Once you click on a starting point, they all disapear, and other points appear in their place, in the location where they would be as if you were drawing the symbols on screen, and each of those points represents something different. From there, you continu doing this until you've built the whole symbol for a spell. As people get better at remembering where the menu buttons are located, they begin to "draw" the symbols by memory. It's a static / reverse-parsed UI that gives the feel of a parsed UI.
However, this wouldn't work in real time at all, so spell making would have to either pause the game, or take place at non-climactic points.
Heh, I was about to say, "yeah, you've turned your parsed UI into a reverse parsed UI", but you seem to have figured it all out.
Your argument is the basis for my essay: the only times I've seen it done with a mouse, it's been painful.
Interesting... the comments on Patrick's "gestures" being counter-productive as a casual UI are very much in line with what I've suggested to him through e-mail.
As I've said before, gestures with a mouse are not intuitive in practically every sitatution I've seen them deployed. I basically stopped playing B&W when gestures came into play.
I also think that "mimicry" is a lazy excuse for including gestures... kinda like making an RPG more "real" by requiring the player to actively feed his avatars regularly. It's fine in a game like The Sims which is specifically focused on "daily life management," but that's not what I'm looking for in an RPG... but I digress.
Grumble. Just so you know, this post gave me weird dreams last night. I ended up arguing with someone as to why they could control a certain interface better through buttons than an interpreted language built on a real-time parser. And I know it's entirely your fault.
The question is, are dreams parsed or reverse-parsed...
Post a Comment