next »

[Bezzy]

I did a lot of cleanup to the code in preparation for the next big step (allowing you to travel through arcs, rather than simply magnify). I've been given Prozac to ween me off Effexor, so I may be taking the next big step in a haze of smiles and fear and confusion. Until I make the jump, here's another Taster Here. Instructions are the same, but quoted below for the lazy.

Oh, and in addition:

f: Toggle Fog on/off.

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

[Bezzy]

Okay, so here's where I'm at right now. I've got the child-fill down hierachy stuff working, and every child node implicitly creates a "home" arc which basically just takes up room so that the user can navigate back to the parent from the child. Here's the debug graphics I've been making to help me figure this crap out. They show the "true position" of the arcs in space, before they've been "derived" into the deformed arcs which actually end up getting displayed.

Fig #1. Black/Red Chords are the original Positions of Arcs. The Derived positions in the background
The Red lines in Fig #1 just show the chords defined by the start and end of every arc. As you can see, the child set of nodes is built off of this chord - i.e. the parent arc and the child arc's "home" arc end up "sharing" a chord in true space... so as the red dot (the search cursor).

Fig #2. Nested Arcs (to the left) are not distributed evenly within their parent arc.
From this picture, and the one above, you can start to understand how the angles are derived from the "true" arc positions to the deformed angles - in your mind, draw a circle around the search cursor, and then project a shadow from the arc ends from a "light source" at search point.

You can see in the background how the nested children don't deform properly. This is because I need to use an alternate form of deformation for any node that the search cursor is not properly in. I can't use the same simple "shadow projection" like I can when the search cursor is inside a node, because the arcs' start and end shadows could be "flipped" while outside it.

Instead, I need to do... something else - perhaps set up a virtual light source for each node, which is never ever outside the chords defined by the arcs in that node. I liken it to the way everything under the surface of water looks a bit "flatter".

Still, it's tricky to get right.

[Bezzy]

Okay. I think I've just realized that I've been going down a bit of a cul-de-sac in terms of this hierachy layout. I post it here so that you can see one of the many slipups possible in designing this.

D@sher Prototype 3: Broken Approach 1

Try out this build, and you'll notice that it *kind of* works, but there are problems. The child arcs which are on the immediate left and right of the chord are closer than those in the middle of the set of siblings. That ain't right at all! Really, they should all be (somewhat) equidistant* when you pass over the threshold of an arc. So we need a kind of "moat" in the hierachical structure. Rather than having all these "bulbs" growing off the side of things, we need concentric circles - onion rings. But that presents its own problems, which I was originally trying to avoid  .

You see, if we do this concentric circle hierarchy, then as you get deeper and deeper into the hierarchy, the angle size of the arc gets smaller, and smaller. And smaller. And smaller. In fact, it only takes a few hundred (maybe less) generations before the values get so small that floating point precision errors start to creep in. And when we blow these tiny, erroneous arcs back up through the deformation process, they inheret the error, and come out badly mutated. Also, getting the search cursor's speed to slow down as it gets deeper and deeper is a real fucking nightmare, trust me.

Basically, I wanted to avoid the problems I had seen before with fractally organized hierachies by doing this "bulb" approach. The "Bulb" approach keeps all the arc angles pretty "pure" - unscaled. Whatever your arcs' angles are when you're "in" the arc, that's what the angles are stored as. They're shrunk down through the deformation process (by their parent's shrunken-factor), rather than blown up. That part is fine. The problem with the bulb approach, as I said earlier, is that the child arcs can often be right on the cusp of their parent's threshold, so you may jump instantly from grandparent to child if you attack an arc at its very edge.

The other problem is that when the hierachy fills down more than 2 or 3 generations, you start to get "overlapping cousins". If you're deriving the deformation from pure position, without registering which nodes you're passing through (we are), this can result in a kind of "super position"... your search cursor can be accessing more than one arc at one time, since the arcs overlap, sharing space. There are ways around this (recording which nodes you passed through in order to get to a space, thereby shrinking the OTHER super imposed arc into insignificance before you even get to the problem area), but they're not really very elegant.

So my brain wave last night was to essentially "Re-Zero" the hierarchy every time you pass over an arc's threshold. This means that when your search cursor passes over a chord, the hierachy is "re drawn" using the chosen node as the "center point". Your search cursor will do a "pac-man", wrapping around in real space (so that we don't have to worry about search speed in tiny, fractal arcs), we keep the arcs pure angles, and temporarily distort them - so no precision errors are introduced (or, if they are, they're introduced to the "scruntched down" arcs, which are so tiny that I stop drawing them anyway).

It's a fair bit of work, and I'm going to Salford tomorrow to look at a virtual reality center, so it may be a while until the next prototype.

*Another, small, benefit over regular dasher. If you pass over the threshold in the middle, then the objects in the extreme corners are further away from you than the ones in the middle of the set of siblings. Though, admittedly, it's not a big deal, and there still is some difference in the distances you have to cross, depending on where you pass over the threshold - just not as much as with as square approach.

[Bezzy]

No updates in a week or so. Sorry about that.

This is because I took the demo up to the University of Salford so that a friend of my dad's could have a look. He said that there's the potential for this become a fast-tracked PhD thesis (which I was rather shocked at - I didn't think my grades were quite up to it, since with my A-Levels and Bachelors, I basically ignored the syllabus and went auto dictum on game design and developement).

Anyway, recently, progress has been rather stunted because I'm getting to areas where I'm smacking my head against a brick wall again. I've made some progress  - arcs now work in "Parameter Space", which is derived into "Hierarchy Space", and then derived *again* into "display space".

My ideas about using "Chords" as the thresholds for arcs were a red herring, since if you enter a chord at its thinnest point, then you're super close to the child arc at the extreme left/right of the arc, and further away from children in the middle of the arc. Changing the "threshold" idea is not difficult, though. It's just a distance check of the search cursor from the center of the current node... if you're in the direction of an arc, and the distance is greater than that arc's inner radius, you're inside it.

The next big problem is figuring out how to re-configure a hierarchy every time you pass into an arc, so that the "Parameter Space" is derived into "Hierarchy Space" each time you pass over the threshold, but with a new hierarchy topology, where the arc which you're currently "In" is the "top" of the hierarchy, and every arc connected to it (including what was once a parent) fills down from it. I don't think that this is outside the realms of possibility to pull off, but because C# has a different way of dealing with pointers to c++ (which I don't get yet), I have to approach it differently to how I would have. My brain needs reconfiguring to C#, I guess. I might end up just using index lists, referencing a master list of arcs. Still, it makes my brain a bit sore, so I'm putting it off for a little while.

I've started working on a bit of parametric geometry (superficial stuff, really) just for a change of pace. This will make the inner arcs of the arc segments rounded for whatever arc you're currently in, or pointed at - so rather than a Sky Channel Three Logo Circular Segment thing, you get a sort of a "Petal" shape. The unselected arcs will remain squared on the inside edges. When you come to select something, the geometry will blend from one target to the other smoothly, also. Not that tough, really. Just a case of applied geometry.

[Bezzy]

Just a quick bump to say I'm still working on this. I finally broke through the problems I was having with deformation. They introduced problems with precision, but those are fixable.

I also have XML files propagating the hierarchy, so in the next demo, you'll be able to make your own trees to dive through - including recursive ones .

More later.

[MekanikDestructiwKommando]

Dear God I'm tired but reading arcs, letters, and universes just made my brain feel like you broke through a barrier.

[Bezzy]

I gave some friends a recent WIP build long before I probably should have (let's call it a "pre-milestone release"). Here's a shot from it:

As you can see, THIS IS A MESS. I've conquered a few hills (and found mountains on the other side) but I still feel pretty good about my progress. Now I need to tidy some thing up before continuing, or I'm going to get spaghett in the house.

But here's where stuff stands (sorry, this is going to be a bit of a self-serving check list for me):

• Hierarchies are loaded from XML. At the moment this only loads up to 3 tiers of hierarchy at a time. This is to stop recursive children being created infinitely.
• _{TODO: Load in grandchildren from XML as and when you enter a node, simultaneously culling nodes which are more than 4 tiers away from the node you just entered. This required quite a lot of work to do with render target disposal/creation. Each arc has its own little render target, but there's limited render target memory, so I will have to create a render management wrapper system to assign/un-assign fixed render targets to the little memory chomping bastards, rather than just creating render targets on the fly. Quite a lot of work, there, then.}
• You can now aim your input (mouse, keyboard, joystick etc) to select an arc immediate to your current hierarchy position. That arc will distort so that its inner edge is rounded - it's a bit hard to tell what I'm going for in the screenshots, but once I nail it, it'll all fall into place. All the nodes that you enter are supposed to have this same distortion, which makes the inner node look more like a cake with a bite mark, rather than a slice taken out of it. Having a receding bite mark, rather than the slice, gives a better impression of how deep into that node you are, and therefore, how far you have to move back to exit. The slice style makes you feel as if you could trip backward in the hierarchy faster than you actually can. So, although this is mainly a cosmetic thing, it is actually still visually informative, and will help hierarchical depth perception.
• _{TODO: currently, only the "pointed at" node, and the node you're inside of, use the rounded edges. All entered arcs, all the way up to the root node, need to have this effect so that they all nest nicely.}
• You can press "A" to autopilot toward the currently Pointed-At-Node.
• _{TODO: Make an equivalent "exit" feature when you press "B" so that you are pulled into the previous tier's space. For a d@sher based menu, this would be your "back" button. For a d@sher based text input scheme, this would be your "backspace" equivalent. What's nice about these is that they give you the choice of treating d@sher as discreet (like a normal menu - select an option, then choose it by pressing "A", then immediately be at the next choice junction), or as indiscreet (navigate with the analogue alone, making it feel more like a natural traveling process). Best of both worlds, yay!}
• _{ALSO TODO: get the autopilot working for every interface type I've endeavored to support (including the mouse one, which will be able to auto-pilot across multiple tiers, just by clicking on the arc you want, regardless of how far it is down the tier set - quite a lot of special case stuff for that, but it should be worth it!).}
• Bug: Well. Not a "bug", but an important fix needed: when you enter an arc, the child arcs ought to all be the same size (haven't implemented weighting yet). As it is, they're deformed through cursor-travel in the same way as their parents are.
• _{TODO: My dad tried it out on the mouse and on the joystick, and said he much preferred the mouse because he could see his cursor. I'm going to add a sort of compass to the center of the disk(used by all inputs) so that you have immediate feedback as to which direction you're diving. It's the sort of thing which becomes transparent and redundant to people who get used to diving through the arcs, but it's a necessity for the novice.}
• _{TODO: have the entire disc rendered to a render target, and THEN to the screen. This will make it easier for people to place the menu anywhere they like in their game/app, and allow me to hit the post-process effects I want (parent arcs blur/fading as you dive deeper and deeper - again, this helps people distinguish between active and discarded arcs, so it's more than just "fluff"). Ofcourse, a less processor intensive equivalent is probably desirable too.}

Criticism from friendly haowan says that I probably don't want to be concerning myself with the rounded edge stuff, since prototyping isn't about cosmetics. I'd normally agree, but working on this project has made me see the caveats to that idea.

If you're proving a game mechanic with a prototype, then, typically you only need blocks and circles etc. to get a point across. If you're prototyping a visual effect, well, then, you really need to get that effect up to a certain level of fidelity before you can say "okay! Proven!".

When you're proving an interface like d@sher, so much about proving it is about how well it handles (so I have to prove kinaesthetics and HCI shit), and how intuitively it gets across information (and since it's a Graphical User Interface, that means getting graphics nailed, to some extent, too). I have to do a fair amount of work, visually, to prove an interface, because without enough visual feedback (i.e. pure visual information, rather than fidelity), the metaphor of the interface is not "sold" to the user. In other words, it wouldn't suffice to go for a demo which just had super basic graphics, because the shape and position are part of the interface design. You don't have those nailed, and you don't have the intended interface.

Still, the rounded edges stuff is a lot of work, and I probably could have gone for anything simpler. I guess I wanted to make my dad (a nobleman in the field of parametric geometry) proud. *sigh*.

I could have kept the color scheme pretty monochrome, and use just one color as the "selected" color, but I wanted to do something on a different feedback axis - rather than rely on color alone to describe whether or not you're selecting, or whether or not you're IN an object (which, in my opinion, fails in the original dasher because you're confronted with a wall of color-noise). I wanted to use shape as well, which I still feel justified about... but now I don't feel justified in the amount of effort spent for this one small facet.

But hey, I'm not on a deadline, and no-one's paying me, and no-one's going to give a shit when I prove that nested radial menus are a waste of time and everyone hates them. So... fuck it!

[Bezzy]

Wow, sorry for the ugly formatting. I was trying to do sub-bullet points, and failed.

[JP]

I think the "don't spend time on visual effects in a prototype" wisdom exists simply in reaction to the obvious dumb thing of getting totally sidetracked making something look pretty when you're trying to prove the fundamental concept (and the work may have to be discarded multiple times anyway).

In practice though, almost all gameplay mechanics are dependent on audio/visual/haptic/smellovision feedback (exception might be Dwarf Fortress world generation, and actually they do let you see that happening).  Feedback feedback feedback.  Sometimes a grey cube is all you need to provide that feedback, but sometimes you need something that will have a cognitive impact similar to what the final vision will be.  UI is clearly one place where this is true.

I guess I try to subscribe to the programming idea of favoring functionality over "correct-ness" of implementation for prototypes.  It's easy to rathole trying to do something in the most robust way possible.

This is also why I like to separate significant visual challenges out into "aesthetic prototypes" where you ignore functionality as much as possible and just try to previsualize - like if you're creating a new art style for a game.  A single prototype that tries to solve lots of very different problems can eat up tons of time - that's more the definition of "vertical slice" (boo, hiss).

None of that's very relevant to what you're doing Bezz, sorry for the tangent.  Looking good.

[Bezzy]

A single prototype that tries to solve lots of very different problems...

... is the final product. SHIP IT!

[Bezzy]

Right, so. I was getting a bit tired of how overcomplex the parametric geometry had become, so I decided to take an alternate approach this morning.

Much to my surprise and epic joy, I managed to implement a Bezier (BEZZY-ERRR ROFL) curve approach within 2 hours! I used this book, which is expensive, but which my dad got for free, since he's into parametric CAD in a big way. The book has loads of excellent images and pretty easy to understand math, explaining how to describe a lot of shapes through math.

Here's the result:


Currently, this is all the code I need to define the shape of inner edge of the selected node.

Code:

BezierCurve2D InnerArcCurve = new BezierCurve2D(StartBezierPoint, EndBezierPoint, StartBezierControlPoint, EndBezierControlPoint);
Vector2[] InnerEdgeList = InnerArcCurve.GetLineVerts(StepSize);

Nice and simple, eh? That's actually the brain-dead implementation of the bezier setup (for a really basic start, end, controlpoint x2 curve). I also have it set up so that you can construct it with a Vector2D[] of any size (so you can have as many control points as you like - though more is going to make for slower processing, and, weirdly (because of how Beziers work) less control over the curve, in some ways - but that's what B-Splines are for).

I then just chuck the InnerEdgeList into the pre-existing TriangleStrip array (which makes up the arc), and I'm done! (Plus or minus some mesh target tweening so that the smooth arc blends into the jagged arc upon deslection, and viceversa.

I'm pretty pleased with how quickly the code came together (~2 hours from opening the book to finishing testing and implementation). It'll only need a few extras (tangents for a given point, normals at a given point) before it could be pretty useful for anyone wanting to use Bezier curves hardcore. And since B-Splines are basically just lists of Beziers (but with tangentially equal start and end points), it wouldn't be too hard to get those going, either. I guess I have to figure out C# interfaces if I'm going to make it an easy library type thing for people to use for XNA, but I'll probably post the full code as well. And I'll have to document it properly (diagrams and all), too, since it's worth understanding how Beziers are set up before you start messing with them. I could also do a sort of "quick Bezier" method, which just generates a list of Vectors on the line so that you don't have to do all the recursive lerps over and over (not that they're too expensive, but if you're calling it every frame, it's probably going to be quicker to find the closest two vertices on a list, and lerp between those for the difference).

If anyone's interested in having a Bezier Curve XNA library, just say, and I'll put some effort into that. Until then, I'm just going to beaver away at the prototype.

Back to work for me! I'm on a roll :D

[Bezzy]

Here's a build #5

Once again, it's not a finished thing - it's just my progress to date, in case you're masochistic enough to give it a go. I actually wrote a readme this time!

I am consigned to the ergonomic standard of Fitt's Law, bitches.

Also, Dasher is apparantly a Crossing-based interface as opposed to point and click. Whatdayaknow?

[Terry]

Hey, I gave this a try but unfortunately it just crashes (maybe an XNA thing)?

[Bezzy]

Yeah. It works for most people as soon as you install the XNA distributable thingies. Check earlier in the thread for links.

If that's not enough, then you need the directx developer redistributable.

This is the issue with XNA... all these extra downloads. Oh well. It's still very good for what I'm doing, which is prototyping, rather than making a final product (I'd do that in c++ and opengl/directx).

[Terry]

I installed that XNA thing, but unfortunately it still doesn't work.

Oh well. I'll be sure to check out the final version when it's ready

[Alex May]

You need XP Service Pack 2, .NET framework 2.0, the latest XNA Redistributable (there was a refresh recently), and an updated DirectX to at least 9.0c from October.

[Bezzy]

You need XP Service Pack 2, .NET framework 2.0, the latest XNA Redistributable (there was a refresh recently), and an updated DirectX to at least 9.0c from October.

Yeah, see, this is what i don't get about people's aversion to XNA. Why do people complain? You only have to download, like, 4 things, and make sure they're up to date, before you can run my crappy prototype!

GUYS, WHAT IS THE BIG DEAL?

[shinygerbil]

It's never worked for me, right from prototype 2. Maybe some kind of hardware issue? (My card does not do native DX9, maybe that's it?)

[Bezzy]

Ah, yeah. XNA requires a card which does DX9c, and technically needs shader1.1 support, but typically, requires shader2 support.

[Bezzy]

Now that I'm on broadband, the world is becoming my oyster. I've been doing some research after remembering about the eye/head tracking experiment used in d@sher. I've just been playing with this Head Tracking software: http://nipg.inf.elte.hu/headmouse/headmouse.html, which is a lot of fun if you have a webcam (I'm using an eyetoy, and it works just fine).

After playing around for a bit, I came to a little conclusion. Using head/eye as an input falls down with conventional interfaces, because every button is so damn small, and it's a pain to make precise movements with your neck muscles (your hands are far more adept to this, having evolved the ability over a long course of time). Macro movements are fine, but as soon as it comes to precision, you see real hits in speed.

So, when you combine it with d@sher (or regular dasher, for that matter), it's lovely to use, because as you move in a general direction toward an option in dasher, the area of the option increases! Rather than having to become MORE accurate the closer you get to your target, you are allowed to be less accurate.

And, alright, this is just a sort of pointless exercise in messing about, but it shows that d@sher can be used to really bridge the shortcomings of low-fidelity inputs (as pointed out in the Dasher presentation on the first page, actually). So... the noise and jitters you get from Wii controller's signals, or the PS3's six-axis could really benefit from this sort of... "Fitt's Dampening" effect of a gradually growing target area.