It's far more subtle than you think.

2007, February 2nd 1:27 PM

User interface design is hard.

Not because it's hard to invent interfaces. Oh no, it's easy to invent interfaces. You can throw the suckers together in minutes once you've gotten a little practice. And not because it's hard to invent usable interfaces. That part is hard, actually, but with a little introspection and a lot of blind testing and a whole hell of a lot of agonizing and rewriting, you can make them work. No, the problem is to invent intuitive interfaces. Because intuitive interfaces are usually far, far more complicated than anyone would expect – since, after all, they're intuitive, and they look so easy.

Right now I'm designing a level editor. It's a 2d editor, used to create curves and paths. It doesn't have very many general classes of "thing" it has to deal with yet. There are paths which have centers. Paths are made up of nodes. Nodes may have curve controls on them. Lines connect the nodes in a loop, either curved or straight depending on the curve controls.

Fundamentally it's quite simple. Here's a screenshot, and I imagine most people feel they could jump right in and start moving points around easily.

Well, you're right. You could. You could grab a point, and drag it, and it would move (and, in fact, the point on the other side of the figure would move too – this particular path is set up with vertical symmetry, which the editor will happily preserve for you. Classy, no?) Note that one point is selected right now – the one that's red, in the upper left – but really that doesn't matter much, you can drag any node around at will, and if there are multiple nodes on top of each other you can just click multiple times until you have the one you want selected. You could also right-click a line to toggle it from "curved" to "straight", and the curve handles will automatically go away. And come back if needed. Pretty neat, huh?

You have no idea how complicated all this stuff is.

Imagine the actual code behind it. The user clicks on a node. The program must select this node. Now the user drags the mouse, and the node moves with the mouse. That's easy.

But what happens if the user clicks on the node again? I've mentioned that you can cycle through nodes by clicking, so we could just have it select the "next" node at that position, whatever that means. Sounds reasonable. Except then the user selects a node, and drags it coincidentally on top of a second node, and changes his mind, and drags it further . . . but whoops, he got the wrong node. The program changed to the next node when he clicked. That wasn't supposed to happen.

Instead, we could make it so the node change happens when the user lets go of the button. Only now we have a different problem – the user selects a node, moves it coincidentally over another node, and lets go . . . and it selects the other node. That's not the right behavior either! We shouldn't change nodes in that case. And, in fact, there's a further problem – if I select a new node that happens to be in a stack of three or four nodes, then let go of the mouse button, it will change to the second node in the stack when I let go of the button.

After some thought, you can come up with the following process to solve these problems:

  • The user clicks. If the currently selected item is not underneath the mouse button, it selects whatever is underneath the mouse.
  • The user may or may not drag the mouse. If they do, move the currently selected item.
  • The user releases the mouse button. If an item was not selected, and the user did not drag the mouse, and there is a second item under the mouse that can be selected, select that one instead.

Note that I still haven't defined "second node" or "next node" or anything like that. Oh, also, there's a bug in that process, which I'm not going to point out. (Find it! It's a challenge!)

But we're not even done. Remember, there's four things in this universe that can be selected – and lines aren't draggable! But you can right-click them to change if they're curved. Or you can right-click nodes to lock their curve controls to "straight", so there are no obvious angles to that node. But curve controls, or the path center itself, can't be right-clicked (even though they can be dragged.) And if the "add node" button at the top is selected, then clicking a curve creates a new node at that position. What happens if you click "add node" and then click a curve control? What if it's a curve control on top of a line? What if you right-click it?

And now I have to go, rip out a hundred lines of code, and rewrite it, because my current approach just doesn't work.

User interface design is hard.

  • Bejoscha

    2007, October 23rd 10:43 PM

    I love your threads. Just that I don't have enough time to read them all. But as I am doing (very) little programming myself and as I am (not as a programmer) develloping some software together with a friend of mine (TavernMaker), I can really understand your pain. And – hey man – you are working alone(!) – so where to put your frustration ? *evil grin*

    Anyway, I just wanted through in two points from other softwares which might be helpful:
    Maybe a mouseclick does something different when a certain key (SHIFT, OPTION, etc.) is pressed simultaniously? Sometimes using the "second hand" is more intuitive than rememembering certain "when is what done" features of the software….

    More importantly, but I am sure you thought about THAT – include a (quick and reliable) undo-function. That's usually what saves more time than hundreths of clever software-decisions.

  • Zorba

    2007, October 24th 10:43 AM

    I've thought of that, but I sort of avoid modifier keys just because I know how nasty those can get if they're not well-thought-out. That said, I don't really need them yet either – the editor isn't that complex, and what it currently does is sufficient for most cases. (Although there are a few tools I need to add.)

    It's got limitless undo/redo, which does indeed come in quite handy. The only standard features it doesn't yet have are copy-and-paste and multiple selections. I'll get those in eventually, I suppose.

  • Ming

    2007, October 26th 3:11 PM

    The best optimization…

    is to not do something if you don't have to.

    User interface design is hard. You might learn a lot doing it once or twice. But you're not going to get your game done if 1) You're working on the design interface rather than the game 2) the design interface is so difficult that only you can make levels rather than a designer.

    I recommend allowing artists or designers to lay our their levels in Maya or 3dsmax and then exporting the data. This will give artists and designers much more freedom in designing levels. They won't have the consistent symmetric shapes that you have now, but they will come up with other stuff— perhaps something that evolves and emerges from gameplay ideas.

    It is actually a lot less work to get this to work than what you've already done with the editor. If there is functionality in the editor that Maya or 3dsmax doesn't support, then you can import those functions that you've already written into those packages as a plugin for the artists.

    -Ming

  • Zorba

    2007, October 26th 6:25 PM

    I agree in principle :)

    One issue is that I flatly don't have either Maya or 3dsmax. They're expensive and I'm not sure they're worth it for a game which is strictly a 2d game.

    Second is that exact problem again – trying to shoehorn either Maya or 3dsmax into the admittedly odd requirements I have would be rather a bitch. I don't know exactly how powerful their plugins are, perhaps I could make an entire new set of primitives, but it would be tough. One nice thing about the editor I have is that, since it's the exact same rendering system I already have, I can just slap my existing text rendering and graphics rendering code in – that might be far harder in Maya/3dsmax.

    I completely agree for any game with full 3d level design, and it's not even an argument if you're talking about actual modeling. For a game with a very restricted 2d design, I'm not as certain, and the same goes for a game with, say, a tilebased 2d layout. Maya and 3dsmax are great for 3d modeling but I wouldn't want to use them as a tilebased editor.

    And finally is something which I admit sounds a bit odd, but I feel is important – doing this sort of interface work makes me a lot more competent in things like win32 programming. There are tools I've been avoiding putting together because I don't want to fight with win32, but now I have the skills to do them. You should have seen the previous editors before I went with a standard win32 interface – now those were awful.

    Now at least I'm competent enough to do better than those :)

  • Stephen

    2007, November 27th 12:53 PM

    I'll have to agree, I have seen some great games never make it out of ALpha/Beta stages because the Interface made the game unplayable. I have seen some very pretty and interesting games come to market and just tank, again because their interface makes them unplayable.

    I really like that as a dev you really appreciate the importance and I look forward to seeing more o fyour work develop.

    Also feel free to let me know i have done a great deal of beta testing for games and have no trouble doing the ame for you.

    good luck.

  • Anonymous

    2016, June 30th 8:46 PM

Leave a Comment

Subscribe without commenting