I haven't done a blog post in a while so I thought I'd catch everyone up...
I've been poking away at the new build wand slowly but surely. One of the reasons it takes so long (relatively speaking) is because it's fleshing out a lot of new stuff that may be utilized by different systems. For example, the radial selector, etc.. This is one of the reasons I didn't want to just tack in a "build mode" like before. Done properly, the build wand is just a specialized item/tool like any other. It just happens to be the most complicated one so far as UI goes.
The other side of it is that I'm making a concerted effort to make everything as pluggable and scriptable as possible. This started with the block types and has the follow-on effect to impact anything like a build wand that needs to know about all of the blocks and organize them in any useful user-friendly way. When the blocks that are available from world to world can change, the build wand needs to be able to intelligently adapt its menus.
More on the modding side in a sec but for now I will deal with the user-facing parts...
As some of you are aware from different posts, the general control scheme for Mythruna will be that (by default) the mouse, its buttons, and the mouse wheel will control whatever is held in the right hand. I say "by default" because these functions will someday be remappable. At any rate, the default set of inputs is for whatever is in the right hand. If you hold the control key then those same inputs will be sent to the tool in the left hand.
Within this, the general convention will be that the left mouse button is the "main" action and the right mouse button is the "alternate" action... while the mouse wheel is a rotator or selector. What is considered "main" and what is considered "alternate" for a given tool may be affected by general expectations. For example, the build wand is going to be backwards in my mind since "main" will erase and "alternate" will build... but that's what we've come to expect.
Other examples of where this might come up:
Hand: "main" is pick up, push, drag while "alternate" is the action menu for the object. Mouse wheel might rotate the object when held.
Sword: "main" is slash, "alternate" is stab. Mouse wheel might rotate the blade (flat versus edge).
Anyway, for the build wand, "main" is erase and "alternate" is place and the mouse wheel "rotate" will change the block type within a subgroup.
This part is different than it is now. Right now the wheel controls the overall category. That's going to change.
The build wand is what's considered a "two handed tool". When you equip it in the right hand then the left hand will display the selected block. You might imagine that the wand has a knob on the side that you can turn with your left hand. (A bow would be another example of a two handed object)
When you press "control" in the case of the build wand, ie: using your left hand, the radial menu will pop-up that will allow you to quickly navigate to a particular block category, for example "stone slopes". Once this category is selected and the control key is released, then the mouse wheel will select a block within that category. So in the case of "stone slopes", the mouse wheel will take you through the main full slopes and their corners... in order. North, North East, East, South East, and so on. Wedge, corner, wedge, corner...
Now I'm going to start to get a little more technical...
As you may remember, the block types are 100% script driven at this point. The various scripted block types are compiled together into an index so that the world will remember which block goes to which "number". The index kind of looks like this:
1 core-blocks:dirt
2 core-blocks:dirt-grass
3 core-blocks:sand
4 core-blocks:stone
5 core-blocks:rock-capped
6 core-blocks:rock
7 core-blocks:water
8 core-blocks:water-top
9 core-blocks:sqtrunk
10 core-blocks:shrub
11 core-blocks:waddle-daub
12 core-blocks:wood-planks-dn
13 core-blocks:w&d-wall-w
14 core-blocks:w&d-wall-e
15 core-blocks:w&d-wall-n
16 core-blocks:w&d-wall-s
17 core-blocks:wood-pillar-nw
18 core-blocks:wood-pillar-ne
19 core-blocks:wood-pillar-sw
20 core-blocks:wood-pillar-se
21 core-blocks:mud-stone-wall-w
22 core-blocks:mud-stone-wall-e
23 core-blocks:mud-stone-wall-n
24 core-blocks:mud-stone-wall-s
25 core-blocks:stone-pillar-nw
26 core-blocks:stone-pillar-ne
27 core-blocks:stone-pillar-sw
28 core-blocks:stone-pillar-se
....
In the case of the default block set, there are 400+ lines (and counting) like that.
Because that list can change, instead of hard-coding some menu structure, a set of rules can be created in scripts that let a particular block filter down into some part of the hierarchy. Tonight I finally finished the standard set of rules to sort all 400+ current blocks into a user-friendly tree structure.
The tree looks like this. Anywhere you see (types: ##) is a place where there are multiple blocks that are then selectable with the regular mouse wheel. In other words, rotations/variations of a particular block.
Material
Water (types:2)
Dirt
Cube (types:2)
Partial Blocks
Slabs (types:1)
Slopes
Full (types:4)
Half (types:8)
Half+ (types:8)
Sand
Cube (types:1)
Partial Blocks
Slabs (types:1)
Slopes
Half (types:8)
Half+ (types:8)
Stone
Cube (types:2)
Partial Blocks
Slabs (types:2)
Walls (types:4)
Posts (types:4)
Low Beams (types:4)
High Beams (types:4)
Slopes
Full (types:8)
Half (types:8)
Half+ (types:8)
Steep (types:4)
Steep+ (types:4)
Braces
Full (types:4)
Steep (types:4)
Steep+ (types:4)
Angles (types:4)
Round
Columns (types:2)
Spars (types:4)
Spikes (types:4)
Black Marble
Cube (types:1)
Partial Blocks
Slabs (types:2)
Walls (types:4)
Posts (types:4)
Low Beams (types:4)
High Beams (types:4)
Slopes
Full (types:8)
Braces
Full (types:4)
Angles (types:4)
Round
Columns (types:2)
Spars (types:4)
Spikes (types:4)
White Marble
Cube (types:1)
Partial Blocks
Slabs (types:2)
Walls (types:4)
Posts (types:4)
Low Beams (types:4)
High Beams (types:4)
Slopes
Full (types:8)
Braces
Full (types:4)
Angles (types:4)
Round
Columns (types:2)
Spars (types:4)
Spikes (types:4)
Mud Stone
Cube (types:1)
Partial Blocks
Slabs (types:1)
Walls (types:4)
Angles (types:4)
Cobble
Cube (types:1)
Partial Blocks
Slabs (types:1)
Walls (types:4)
Slopes
Full (types:4)
Angles (types:4)
Rock
Bare
Cube (types:1)
Angles (types:4)
Capped
Cube (types:1)
Angles (types:4)
Wood
Cube (types:2)
Partial Blocks
Floors (types:4)
Walls (types:4)
Posts (types:4)
Low Beams (types:4)
High Beams (types:4)
Slopes
Full (types:8)
Steep (types:4)
Steep+ (types:4)
Braces
Full (types:4)
Steep (types:4)
Steep+ (types:4)
Round
Columns (types:2)
Spars (types:2)
W&D
Cube (types:1)
Walls (types:4)
Glass
Cube (types:1)
Panels (types:4)
Thatch (types:8)
Shingles
Full (types:8)
Steep (types:4)
Steep+ (types:4)
Flora
Plants (types:9)
Wood
Trunk (types:2)
Branches (types:4)
Logs (types:4)
Spikes (types:4)
Leaves (types:2)
Pine (types:9)
Shrubs
Cube (types:1)
Slopes (types:4)
Under Slopes (types:4)
Angles (types:4)
Square Trunks
Cube (types:1)
Slopes (types:4)
Under Slopes (types:4)
Logs (types:2)
Light
Light (types:5)
Fire (types:4)
So far, no selection is more than three clicks deep and no menu level has more than 7 branches... with most having 6 or less. Flora is an odd one because of the square variations of things.
Also, since this is defined in script then it's possible for a mod to completely redefine it. It also makes it easy for me if I ever split the build wand into multiple separate tools or have a version without flora, etc..
For the would-be-modder, a little peek under the covers... this is a snippet of the groovy code that defines the hierarchy:
blockGroup( name:"Black Marble", pattern:"core-blocks:black-marble-?" ) {
inherit( "std-block-tree" )
}
blockGroup( name:"Glass", pattern:"core-blocks:glass-?" ) {
block( name:"Cube" )
blockGroup( name:"Panels", pattern:"panel-" ) {
block( pattern:"n" )
block( pattern:"e" )
block( pattern:"s" )
block( pattern:"w" )
}
}
blockGroup( name:"Thatch", pattern:"core-blocks:thatch-" ) {
block( pattern:"n" )
block( pattern:"corner-ne" )
block( pattern:"e" )
block( pattern:"corner-se" )
block( pattern:"s" )
block( pattern:"corner-sw" )
block( pattern:"w" )
block( pattern:"corner-nw" )
}
Block groups can inherit from other block groups. Each level can chop a little bit off the block name using a regular expression or let it pass on down directly. So in the above example, "core-blocks:glass-panel-n" gets chopped up as it filters down to "Glass" then "Panels" and then the first child entry. The nameless children are the ones that get grouped together for the regular mouse wheel spin.
Most materials will just inherit std-block-tree. It defines rules for all of the standard naming conventions. If a particular material doesn't have that block then that part of the tree doesn't get activated. Other groups like Flora required very specific customization.
One might wonder why I didn't support wild-carding at the child level... and the reason is simple: it is important to have a consistent ordering no matter what order the block types might have been defined in. You don't want stone slopes to start north and go clockwise while marble slopes start south and skip all over. It would suck.
Now the next step is to actually hook the tree to the radial selector to the build wand... so I can actually edit worlds again.
