next »

[Bezzy]

Some of you may have heard of dasher. It's this really pretty cool interface which allows you to type relatively quickly using a 2 axis (or even 1 axis [or even binary]) interface.



You write in dasher by zooming into a box which has a letter in. When you get inside the box, you see that there are more boxes inside, of different sizes, with different letters of the alphabet in. Here's the neat part: the size of the boxes depends on a predictive model they use. So if you fly into "T" then "h" is a pretty big box, since lots of frequently used words which start with "T" have "h" after them... "The", "then", "than", "them", "their", "there" etc.

You can still use the system to write "garbage" words, but the point is, you are encouraged to write the predicted (i.e. correctly spelled) words, and discouraged from writing the unrecognized/incorrectly spelled words. In a sense, you're bending a very free possibility space so that the more useful paths are easier to walk along... nice analogy for game design in general, that.

I feel like if there's any justice in the world, we'll be using dasher (or something like it) instead of some of the more crappy virtual keyboards on consoles (PSP's virtual mobile TXT interface, I am looking at you. Jesus Christ  ). Maybe even mobile phones! It's not necessarily faster than the speediest predictive text user, but it has a much quicker learning curve, and is just more fun to use!

I think part of the reason people can't seem themselves switching to dasher is because it has been built with the most hardware in mind - which is smart.. noble even! Unfortunately. That means it can't really afford to do much with swanky graphics.

The thing I want to do with this it to basically sexify it. I want to show what the system COULD look and feel like on a decent PC, or on a console or whatever. I'm not asking for much power, really... just more than the most basic mobile can provide. I think this may win some people over to it (but also, it might give them the same mind-gasm I had when I considered what an amazing generalized concept this idea of "predictive hierarchy diving" is!)

I call this project "D@sher", because it's literally "Dasher with a twist".

I've been writing about my progress so far on my blog, but I also wanted to give a heads-up here, to get feed back from you smarty guys. Here's the basic idea:



Instead of diving into the right of a page, you dive into these concentric circles and arcs. As you dive into them, they expand to reveal more arcs. To get "out" of an arc, you basically just dive back the way you came - however, so that you don't have to duck and weave and remember your way back, I've made it so that all the "discarded" arcs get crushed into one cardinal direction... so moving "up" the arc hie racy is just a case of moving "left". But it doesn't necessarily have to just be "left", either. I've just today added a way to use a "stirring" gesture to change the overall rotation of the dasher disk so that your "exit" direction can be whatever you want it to be. In regular dasher, moving anywhere "left" exits the hierachy. By twisting space around the center point, D@sher is very simply trying to improve the use of screen/interface space, so that everything between 180 and 360 degrees isn't dominated by the "Back" functionality. This might make it faster/more intuitive to use! Maybe! I'll have to do proper testing things later to see!

I think, from a "sexified" dasher, it's easier to get people thinking in the dasher mind-set, and thinking of ways in which D@sher could be used to make some kind of game. I have a few ideas already:

• Standard Menu: Just a different way to explore your front end. Each arc in the system is linked to its own shader and render target, so you could even have your "start game" equivalent button be a sort of "window" into the game, which you physically move into to seamlessly start the game. I'm also working on ideas for standard menu options, remixed to work with d@sher - like radio buttons, check buttons, sliders etc.
• Toy Language Interface: Chris Crawford has been trying to create a really cool way to play games where you're not just performing actions, but *talking* about the actions you're performing to characters who can understand what you mean in the context of the game. This is possible thanks to a very strict grammar (made up of verbs and nouns derived from the core game play, and meta-verbs like "tell", which would allow you to "Tell <Terry> '<I> <Killed> <Josephine>'". It's called a "Toy Language" because of its cut down scope. When you play games, you can't talk about things outside the scope of the game (like "the Eiffel Tower") and expect an AI to know what you mean (unless there's an object called "the Eiffel Tower" in the game - but even then the AI won't know what you mean by "The REAL Eiffel Tower"...). A toy language essentially allows you to converse with the game characters by only allowing you to submit sentences that they can understand. That might sound restrictive, and might force you to start thinking in THEIR terms, but it's a good start to this area of games. Because it's a strict grammar (essentially a hierarchy with elements of recursion) d@sher would be an ideal... by diving into each of the words you want, recursively, to build up a sentence, you'd not only see the legitimate words allowed next - you'd also have prediction help you by making the "better options" weighted bigger on the screen. So the above example of "Tell <Terry> '<I> <Killed> <Josephine>'" would probably make <Josephine> very small in the dasher interface if Josephine happened to be Terry's lover.
• "BeetRootJam": Maybe the first thing I'll do with this game is try to create, not a word, or toy language predictive model, but a musical prediction model. In essence, D@sher will become a musical instrument which helps you to keep in rhythm, and choose the "Best bet" note. It'll still allow you to play "jazz" (i.e. not conform to the music theory model), but it'll encourage and help you to not play notes which sound like they're in the wrong key. At first this may be a bit of a bauble, but I can see a game being developed around it... a kind of non creatively restrictive version of Frequency or something?

In essence, any game which has some aspect of hierarchy exploration, or predictive recursive models might be able to use D@sher as an interface into it.

Right now, I feel like I've just figured out a key part of the drawing system - converting a fixed hierarchy into a distorted "zoomable" form, using only one 2D vector as a distortion seed. Tommy and me tried doing this for the menu for goo, but it was a big problem area, and I guess we didn't have time to do a fancy menu, AND an interesting game.

I'm going to start on the parametric geometry distortion tonight, and should hopefully have a few screen shots tomorrow. Soon after that I'll put out a prototype demo so you can actually feel it in action. Everything I've been doing on this project has been XNA based, which has been VERY kind to me, I have to say!

[Alex May]

Can't wait to try this out. I think there are games in here too, somewhere.

[Bezzy]

Another thought for how it could be used:

Say you're making an RPG with pretty standard JRPG combat mechanics. You get into a fight, take some hits, and now your health is low. You decide to look in your inventory for a potion, and want the one which will get you closes to max health without actually healing you fully (tends to be the best bet, tactically). In cases like these, where there's a clear, no brainer "best strategy", you can make the potion which has the best "fit" for this problem be the biggest option, helping you to navigate to it more easily, but not taking away the ability and freedom to choose something else.

Or, in the same kind of example, if you come across a foe who you've learned has a weakness for electrical attacks, and you've been using the same zap-attack over and over to kill this kind of creature, the menu will "learn" that you've learned this, and the "zap attack" sub option will adapt to be larger when attacking that kind of animal.

[Tommunism]

I'm looking forward to trying this out. I really like the diagram you made for Beet Root Jam. It definately has some potential for some rockin interface stuff...though I'm not conviced on Dasher for text input...it's kinda gimmicy to me but I think this translation could be damn useful.

For the record though, Goo's menu did use one 2D vector (was the pilot) to determine which the zooming of portals, how their children reacted etc. The reason it was back burnered was simply a matter of time (Implementing the art to make it look like Goos would have easily taken a few months) and the fact that doing stuff like realtime skin selection just wasn't very elegant and got extremly crowded when lots of skins were displayed. Without doing some sort of categorization of skins (which would have made it a bit more confusing to the user to select a skin) it became a huge clusterfuck...other than that though it worked like a charm. There were some bugs...but I really only spent about 5 days on it.

[Bezzy]

Well, the geometry deformation for the head of the hierarchy works, and my mum tried it and said it's "Very Sexy". I felt like the king of the world after figuring it out. Apparently, it was a pretty easy solution, but it had me stumped for ages.

It works by deriving your fixed set of arcs (radius taken to be "1.0") into deformed ones by finding the angle between your "search cursor" and the start and end of the arcs. Sorry, I'll try to explain in simpler terms.

Imagine that the cursor is a candle in the center of a circle of poles sticking out of the ground. Each pair of poles is a start and end of an arc. Outside the circle of poles is a circular wall, which moves as the candle moves. The candle casts the shadow of the poles onto this wall.

To find out where the derived start and end of your angles should be, you simply  move the "candle". The shadows land on the wall, and you find the angle of the shadows from the candle. That gives you the new start and end of your arc.

So, if your candle (the search cursor and center of the circular wall) is in the center of the circle of poles, the result is that you get no deformation.


Fig #1. Centered "candle". Source angles equal Derived angles. Note Search Cursor co-ordinates are (0,0) - centered.

If you move the candle/search cursor to the right, the shadows from the poles you're moving toward start to diverge, while the shadows from the poles you're moving further from start to converge.


Fig #2. Search Cursor moved to the Right. Distortion apparent. Right hand arc grows, left arcs shrink.

If the search cursor passes outside the circle, the illusion is lost, because the "shadows" start to come into alignment, and then cross each other on the wall, and you get mess ups like this:


Fig #3. Break down of distortion when moving outside the circle. (Note that Search Cursor Length is greater than the radius of the circles (1.0), and therefore is outside the circle.

I've also made the width of the arcs change depending on how much angle they take up. When you pass over the chord line (the line between the start and end of the arc), the derived arc will be exactly 180 degrees. I make sure that the inner radius of the displayed arc, at this point, is zero (so the arc is a perfect semi circle), so that you can tell that you've "passed the threshold".


Fig #4. Crossing arc's "chord" == PI radian swept arc. This is the "threshold" for entering a new arc.

I'm having trouble with UV mapping, but that's not exactly high priority at this point. All questions of prettiness are having to be left to the back of my mind, but if anyone feels like doing any kind of target art for this, that'd be really appreciated! Each arc has its own render target and shader, so I can do all sorts, when the time comes.

More important is unwrapping the nested arcs. I'd like to be able to derive their shape in the same way as I have the first arc (by projecting out their relative angles onto a circle), but it gets tricky knowing how to place their "true" position in the search space.

I'm going to try creating the "child" arcs within the arc bounds of the parent arcs. In essence, traveling the hierarchy is a case of getting closer and closer to the edge of the circle, but never quite reaching it. you can't be allowed to reach the edge, because it's at that point that the illusion starts to break (Fig #4).

And I know from experience that it's really hard to get the search cursor's speed to slow to the correct "fractal speed" as you get deeper and deeper into the heirachy- you're multiplying down sizes over and over, and all of a sudden, you lose precision, and things go faster or slower than you ought to.

Therefore, when passing into or out of a threshold, I may have to "rescale"/normalize the current node we're in to maintain precision and get the correct speed. That can have feedback effects, though (like if your path down the hierarchy starts to spatially overlap with "cousins". I'm not sure yet, though. It's a bit of a brain hurter.

This is basically where I got stuck when making the Goo version. The top layer's easy. The geometry hasn't been too tough. It's the nested geometry and navigation which are really easy to botch since every little thing fills down the hierachy, and doesn't suffer problems of precision lightly. I'll have to think on this a while. Any suggestions would be most welcome.

[Alex May]

OK, with the successive layers thing, I don't think you should be going "deeper and deeper", more like "along and along".

If you imagine each set of options as taking up a whole arc, then the top level is the same except the arc to which it belongs is always as big as it can possibly get (i.e. the whole circle).

You have your hierarchy in memory - that's where you go deeper and deeper. But for rendering the thing, you only need to think about the local area where the cursor is - the path through the hierarchy it took. So you start say one branch up (the last menu choice), render that (it'll be almost the entire circle if not all of it). Then you follow the cursor down one branch, render that set inside the arc you just drew. Then you can draw the next set of options available to the user in the various arcs that you just drew.

Rather than thinking of it in terms of rendering from the top of the menu right down to where you are, think about it in terms of where the cursor is in the tree of options that you have dynamically created for the user.

[Bezzy]

Yeah I get you. That means that passing into an arc, you make a modal switch from one space to another. I can see that working. The only thing is, Dasher prides itself on not using that kind of modal switch, so I need to figure out a way to translate your position when entering a chord into that arc's sub-space... and vice versa when you exit it.

Which, when I think about it, shouldn't be impossible. Thanks hao!

[Alex May]

I guess. I wasn't really thinking about it in terms of which space you're in as you're always in the hierarchical space. I'd draw a picture but I'm at work. Maybe later!

[Bezzy]

I use XNA, so you need this to run this first version. Clearly not finished yet (no nesting as such), but feel free to have a look. Here's the controls so far:

I have to stress that these are not the final controls. You can't even "dive" into a nested thing yet. Right now, you can just "magnify" toward arcs and "stir" to rotate the camera. I am, however preparing to "simulate" lots of different interfaces to show that this system can be used even with non-analogue interfaces.

Mouse
Right Click : Start/Stop the menu (as if you're opening a right click menu and then closing it)
Move : Magnify in a direction

360 Controller:
Left Stick Direction: Magnify in a direction (this will become "travel")
D-Pad: same as left stick, but digital.
A : Open Menu in "360 mode"
B : Close Menu while in "360 mode"

Right Stick Click : Open menu in "iPod mode"
Right Stick click while deadzoned while in iPod Mode: Close menu
Right stick: Move to magnify
Right Stick Click + Direction : Magnify more


Keyboard
Space : Open menu in "Crappy Mobile Phone mode"
Space without cursor keys while in "Crappy Mobile Phone mode": Close menu
Cursor Keys: Magnify.
Space + Cursor Keys: Magnify More

All Modes:
hold 'W' for wire frame
'Back' on 360 pad exits.

In ALL modes, if you make a constant clockwise or anticlockwise movement, you can begin to "spin" the disk to your preferred orientation. This feature will make more sense when diving is implemented - essentially, you'll one one consistent direction to dive out of, and you may want to choose what that direction is (by "stirring" the disk).

Download Microsoft RunTime thingy
Download D@sher Prototype #1

[Gravious]

very interesting, would like to check it out when theres a bit more flesh on the bones

[Bezzy]

Haha. Yeah, it's skinny for sure, right now. But XNA is pretty fast, and this is just a prototype, so it may not be toooo long before it gets interesting.

[bigbossSNK]

Here's another program that incorporates probability spaces and highlighting. It's a tool for creating 3d models of trees, through manipulating over 100 variables.
(reference article)

[ravuya]

I remember going over zooming user interfaces in my human-computer interaction course. Wish we had done something with it instead of yet another windows app because that's all the ta could do.

[Bezzy]

BigBoss - excellent find! I'm looking for all kinds of examples of things where this could be useful, and that's an excellent one. I guess, by extension, it'd be a great way to navigate any kind of hierarchy generated by genetic algorithms.

Any hierarchy i guess... and not necessarily just basic tree topologies. This can allow you to navigate recursive bits of hierarchy, and "cousin" connections etc.

The question is, in what ways is this system going to be useful to navigation hierarchies? What kind of information is best suited to perusal through D@sher? Clearly, it's not going to be best suited to things where you want an overview of the hierarchy (since you're essentially zooming so close that you only get to see child/grandchild/siblings/parents. So hierarchies where the immediate choices at each node are important.

I was thinking you could do a "choose your own adventure" game using this, but then I remembered how much I hated "choose your own adventure" games. At the very least, it'd make them easier to navigate, and less illusory about the choices you have (since you'd be able to see your choices up front). I even did a pencil sketch for one, which I'll upload at some point.

[Bezzy]

Another shot for your perusal. I've just been messing with nested arcs. Halfway through smart culling (don't draw arcs which are small or children of arcs which are too small to be drawn).



Unfortunately, I'm getting one of those crashes where it works, in release in the IDE, but mysteriously crashes outside of it, so I can't happily offer people another build. I think it might be something to do with derived classes' constructors, but I'm not sure yet.

Also, this is still using the "magnification" approach -  there's still no real "travel" into the arcs yet. That's going to be tricky.

[Bezzy]

Just for shits and giggles, added some old school fog.



Don't worry, clarity fans! It can be turned off super easily (press "f" to toggle fog).

I will definitely need art direction on this at some point. Just not until it definitely works!

[Melly]

Apparently, it was a pretty easy solution, but it had me stumped for ages.

The 'obvious' enjoys the interesting ability of being imperceptable.

Something a biology teacher/army lieutenant I once met said.

Other than that, looking SEXY. I wanna try this out eventually.

[JP]

This is good stuff buddy.

One nuance of this interface paradigm is that it's actually best suited to letting you navigate non-spatial things, spatially.  The radial footprint means that our normal orientation and position memory doesn't work the way it does in most interfaces.

Only other place I've seen something vaguely like this are interfaces that let you navigate mutations on data - there's a Linux prog called Evolvotron and Photoshop's "Variations" feature for tuning an image's histogram.  Again, changes in non-spatial (actually quite complex) parameters presented spatially.

Also, a more minor feedback thing: the color saturation increasing as a slice dominates focus is cool, but it also means that non-dominant slices get increasingly hard to see because they get smaller and less saturate - in game design terms it's multiplicative negative feedback.  Color is one thing humans can sense pretty well in peripheral / outside our attention locus, so I'd say try keeping the saturation the same, and maybe highlight the focused one by increasing its luminance.  Or do an outline that's visually connected with the candle?  I dunno.

Eager to see how this develops.

[ravuya]

Sausage Software's Reptile also has a similar navigation interface for changing the parameters of their texture generation.

[Bezzy]

I've been ill for a couple of days. Tried to take some exercise after a long period of being very sedate, and triggered a migraine. Although the horrible "blind spots" have come and gone, it feels like it's robbed me of a bit of the fidelity in my peripheral vision. Oh, and then I got *another* cold. So, the momentum I had built up was stopped very suddenly... but if I'm honest, I would have needed to take a break anyway, to keep me sane.

I've been sitting on an idea for getting the node-travel to be completely seamless. At this point in time, the search cursor does not actually travel into sub-arcs. It only travels inside the top level hierarchy. The next step is to fix that.

I've already mentioned that passing across the chord defined by an arc's start and end angle results in a derived arc of 180 degrees. Passing across the chord is the threshold into the sub node - like passing through a portal. When this happens, the parent node's deformation fixes, as if the search point is on the very threshold of the chord, and the child arc's deformation starts. In every node where there is a "parent" to the node, a "home" arc is automatically created. This home arc's chord matches the parent node's arc which it was created from. So this "home" arc is just your portal back to a higher level. You won't actually be able to see it. It will be represented by the "pacman" shape disk, which used to be the arc which you were currently in. Move toward the pacman "mouth" and the mouth will open until the sub-arcs are no longer deforming (since you've moved out of there node) and are nested inside the arc you just came out of.

Yeah, hard to explain. I barely get it myself. I think at this point I'm stuck until I actually take a stab at it and see how well it goes.

Also, a more minor feedback thing: the color saturation increasing as a slice dominates focus is cool, but it also means that non-dominant slices get increasingly hard to see because they get smaller and less saturate - in game design terms it's multiplicative negative feedback.  Color is one thing humans can sense pretty well in peripheral / outside our attention locus, so I'd say try keeping the saturation the same, and maybe highlight the focused one by increasing its luminance.  Or do an outline that's visually connected with the candle?  I dunno.

Oh yeah, it's not meant to be that way at all. I think that was just another quick "shits and giggles" thing to keep me occupied. As I suggested in the first design drawing, the arc that you enter will become blurry, desaturated etc. and the current pertinent arcs will be sharper, brighter etc.

Oh, wait. I re-read what you said. You mean that desaturating AND shrinking the "discarded" arcs might be bad, because, well, you can't see them, while it's easy to see the one you're currently in? Hmm. That's a good point. Unfortunately, at some point the ignored arcs WILL have to be shrunk down to nothing, and fade out. But certainly in terms of the immediately selected arc getting too many visual buffs... you're right. I'll use the outline approach, probably...

I was already planning to do what I did with Goo's menu - have an outline over the thing you're currently pointing at so that you can auto jump to that object if you press "A" or whatever. That, I feel, bridges the gap nicely between people's learned expectation of discreetly navigated menus (press a button to select an option/change page) and indiscreetly navigated menus (the constant zooming of dasher). But also, it solves your issue. It highlights that arc, but on a separate axis to color (which, itself, should really be concerned solely by the idea of "hierarchical pertinence").

Anyway. Hopefully I'm well enough to work tomorrow and I can have a stab at this, properly.