Ideas for UI in the context of unlimited regions

Started by Crimson Wizard, Wed 26/06/2013 09:34:05

Previous topic - Next topic

Crimson Wizard

I've been working on removing limits meanwhile, and I've met following problem.

At the moment the number of room hotspots/regions/walkable areas and walkbehinds (I'll call them simply "regions") is constant. User may set name and properties / write event handlers for them even if they are not yet drawn (and even if they never will be).
Interesting thing is, that this opens unusual possibility to have "hidden" (unpainted) regions and still call their interactions with script (e.g. hotspot[20].RunInteraction(eModeTalkTo) or whatever).

Now, assuming that the limit will be removed, or rather increased to technical maximum (which is 256, because the regions are defined with a 8-bit mask graphics), question arises: should their number be still a constant or a variable?
Of course 256 is not 2147483647 (maximal number to store in the "int" variable) nor 4294967295 (unsigned int), and it won't take that much extra memory (the mask bitmap is still only one for all regions, regardless of their count), but it still will take extra memory.
Also it might be pretty confusing for user: how many hotspots does he actually have: the 3 he painted over room or 256?

The actual problem with the variable number of regions is that the current Editor interface is not fit to handle them.
There's no means to define real number of regions (hotspots, etc) and there's no means to add/remove them. You may erase a region from the room background, but the element itself will stay (and may be referred from script, as noted above).

Furthermore, current interface is very inefficient to work with large amount of room elements, in my opinion. Except for using a graphical "picker" to select a region there is a combo box that will become really annoying if you will have, for example, 100 walkable areas.
Though, this issue is far minor relative to the first one.

Does anyone have good ideas how to change the editor interface to allow addition/removal of regions?

Billbis

#1
Quote from: Crimson WizardSo far I can only imagine adding +/- buttons on the topmost panel of Room Editor, as a temporary solution for Alpha version.
Not that bad, specially if you try to combine these +/- buttons with that kind of region selection interface. At start, only the + button is available. When adding new regions, colorful buttons with number will start appearing. Right-clicking those button could display a new "supress region" option. Large number of regions will trigger the appearance of an horizontal scrolling bar.
  ;)

Crimson Wizard

Quote from: Milhouse on Fri 28/12/2012 12:44:53

Hmm, this gave me different idea.
What if there's only one button displaying current selection, but pressing that button will show a "floating" palette, which closes as soon as you choose another item or click elsewhere? This way we don't need to put everything on toolbar.

tzachs

My suggestion:
1. Instead of a combo box make it a list box (with vertical scrollbar).
2. The properties pane will show the selected region in the list box instead of the combo box.
3. In the list box itself you can put the color of the region, along with its name/id.
4. The list box, plus add & remove buttons should all be placed in a content document, which means it can be floating or docked, whatever the user wants to do with it.
5. As a default I would place it in the right top pane above the properties.

Crimson Wizard

tzachs, if I understand you right, what you say sounds like a simplified version of my old suggestion:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46483.msg625473#msg625473

;)

Crimson Wizard

I want to tell one idea of mine, for I am not yet sure whether I will be working on this UI stuff soon (in the worst case I can just increase Regions, Walkable Areas and Walk Behinds to 50, same number as Hotspots, and leave it for now).

First of all, I think we should note that every editor component is a separate thing, and it is even more true now when you can dock them around as you like, or even hide ones you don't want.
Therefore it is not something extraordinary if there's object selection in two panels at once. For example, we may select hotspot on Properties pane, or in the Room Editor. So, I don't really want to remove the combo box from Properties: it may be useful in some cases too, and it does not take much space. It also has its own logic telling which items to display.

C# is a very interesting language, it's a pity I haven't used it for a long period. I found there's an Attribute that tells whether the class should have extra page (Events or Interactions) when displayed on Properties pane.
This gave me another idea. What if there will be some kind of "Object Group Type" meta class, that will define available object selection in the Properties list.
Like "Room hotspots", or "Palette color", or "GUI parent and child controls" (like it does now). Now, if we have this "meta-class", we may apply an Attribute that will tell what kind of object Selector(s) the Property pane should have.

For example, for regions and palette colors there could be an extra control near combo box (or replacing combo box), something like I mentioned above: a simple button, which, when being clicked, displays a temporary window with palette-like selection of items, represented as colored rectangles with numbers (IDs) drawn over them. This way the selector will allow to see much more items at once, but won't take much space when closed. Something like extended combo box, but looking like a big icons view.

SMF spam blocked by CleanTalk