Mythruna

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:

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.

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:

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.  :)

For fun, here are some images in my radial tester that mimic the menu structure...

(http://i.imgur.com/4c5ycBF.png)

Click

(http://i.imgur.com/T0P5FkG.png)

Click

(http://i.imgur.com/zWFKLFu.png)

It's also important to point out that even if you don't drill all the way in, a default child will be selected based on where you previously were.  So if you came from Stone and back out to select Marble, the same shape will be selected by default because both of those materials have the same shape.

Also note: the final version will have graphics in addition to the words... but the words are functional and the cursor-bubble in the middle of the screen will be showing the current child selection anyway.

Budehgong likes this.

When the game will have the "survival" mode, how the build wand will work? I mean, will we have to consume energy to create the objects from nothing or we'll have to collect materials before we use them (for example I take a block of stone from the mountain and then I can place 1 of each object that are made out of stone [slopes, half blocks...])? Or maybe you have another brilliant idea that I didn't mentioned here?
In any case it seems great to me :)

The build wand in this incarnation is for the intermediate phase... it replaces "build mode".  Eventually only "creative" will have this particular build wand.

The one in the real game will work a bit differently though may have similar qualities.  It will have a storage limit on materials and may only be able to make certain types of blocks... and no flora at all.  I don't want to go into it too much right now, though.

+1 like a mofo

Thanks for the update. Lookin good.

Yes, thanks for the update. I like the progress you're making, good job!

Hah, why does it feel like a hassle to go through it just to find that one block? I'm sure It'll feel better when I'm actually using it.

You mean as compared to now?!? :)

Hahaha, maybe! I remember the pattern of where a certain block was and scrolled really fast to it. :)