gabien-app-r48
gabien-app-r48 copied to clipboard
20kdc
Usability issues?
Scenario: adding an event command to show message
In RPG Maker 2000, I need to:
- Double-click on the command insertion point (
<>or a diamong sign) - Choose the first command, ‘Show message’
- Type message in a 4-line box
- Click OK
Total: 5 clicks
In R48, I need to:
- Click on Add @ 1 to the right of the
@pages - Click on an empty button to the right of
@pages:1 - Click on the [1] to the right of the
@list - Click on the Add @ 0 button
- Click on the newly-added ‘12310 End Event Processing’ command to the right of the 0 to change it
- Click on the ‘12310 End Event Processing’ type to change it
- Click on the ‘10110;Say’ to select a new type
- Click on the first line of
@textto enter the text - For lines 2, 3, 4, click on ‘Add to group’ and click on the next lines
Total: 8 for one-line messages, 14 for 4-line messages.
Why RPG Maker does this faster:
- The interface doesn’t force you to touch pages unless you need it. Many events are fine with just 1 page, and the page interface can be ignored before it’s not needed. It makes it easies to start adding commands, and also easier to explain.
- RM2k pre-creates the page 1 saving more mouse clicks. Events without pages are useless anyway (they have no graphics and no action, so what are they good for?), so it makes sense.
- RM2k combines creating an event command with selecting its type. In most cases you don’t need to change the type of the event command (frankly speaking, I can’t imagine a situation when I’d need it — fixing wrong data? adding custom event commands based on existing ones and sharing the same properties?), so this saves you a mouse click, too
- The event command selector in RM2k prioritises common commands. It shows one of the most common event command, Show text, first. Newer RPG Maker versions also group the commands into logical blocks, making selecting the relevant event command even simpler (see VX Ace screenshot, ignore the green highlighting, it was added for some tutorial). And R48 prioritises a rarely-used ‘12310 End Event Processing’ instead (although ‘Say’ is pretty high, which is good).
- RM2k handles the text lines as one textarea. R48 requires to add each line separately. Newer RPG Maker versions also allow a mass-input where you can enter several textboxes in one long window.
Will write about other scenarios later.
Planned order of implementation (at present):
- [x] Categorized commands ("1 - Text", "2 - Flow", "3 - Party", "4 - Map", "5 - Battle", "6 - Misc"?)
- [x] Navigate to command type automatically when adding a command
- [x] Make pages at-least-one (unsure if RPG Maker can create zero-page events, though - if it can, this means using special defaults)
- [x] (will probably be concurrent with at-least-one change) Change page UI - reorderable tabs similar to RPG Maker?
- [x] Group textboxes
- [ ] (maybe) Some sort of 'by default, add this' for commands?
Regarding textbox grouping (several textboxes in one long window), it's doable but unsure if recommended (using grouping prevents individual copy/paste)
One thing that makes navigating big If/Then/Else branches easier in RPG Maker is ability to click on the whole branch, have it selected and quickly see how far it goes. Here’s how it looks in RM2k:
Something for quickly identifying where the branch ends would be welcome in R48 (maybe something like folding indented branches?)
This'll be set for v1.2 given the nature of it. I'm trying to avoid anything too likely to create bugs in v1.1-1
I've committed an implementation of something like this to master. It also makes the selection stuff use a lot less buttons.
Some things that have been bugging me recently:
- When switching between L0 and L1 in R2k[3] mode, tile picker keeps its previously opened page. This makes sense when the page is actually contains tiles that are allowed on the newly-selected layer (e.g. switching between layers in RXP, or between L0/L1 in RVXA), but it’s not very useful when, after switching the layers, you end up on the
<X>(aka<DNU>, do not use) page. - When selecting something with Shift+Click, the position of the tile picker changes, and often covers the area on which I was drawing. It’s annoying.
- On Linux, clicking ‘Open’ in the file selector starts a map editor in my home directory. It would make more sense to start it in my project directory.
- Inconsistent ‘camera tool’: it’s off by default on the map editor, and on by default on the image editor
Solved points 1/2. Not done with 3 yet. 4 is weird because on map editor you default to having no tool selected, which replaces camera tool for this purpose, while image editor doesn't have any such mode. (EDIT: Point 3 solved. Still unsure what to do about point 4.)
Another things that is bugging me is the window for changing the grid in the image editor.
First, it’s just too small. Try accidentally entering a 3-digit number and you end up with this:
Second, I need to change grid way too often. Any time I edit character graphics. R48 knows what engine I use and file from which directory I’m editing, so it can pre-set the grid based on the folder of the file, thus eliminating the neccessity to change the grid size in most cases:
- RM2k ChipSet: 16x16 (or 8x8? 16x16 is useful for most tiles, 8x8 is useful for autotiles),
- RM2k CharSet folder: 24x32 (unless they start with
$and file size is not 288x256, then(fileWidth/3)x(fileHeight/4)— but that’s an EasyRPG addition so less important), - RM2k Battle folder: 96x96,
- RM2k3 Battle2 folder: 128x128,
- RM2k3 BattleCharSet folder: 48x48,
- RM2k3 BattleWeapon folder: 64x64,
- RMVXA and RMXP Graphics/Tilesets: 32x32 (or 16x16? 32x32 is useful for non-autotiles, 16x16 is useful for autotiles),
- RMVXA and RMXP Graphics/Animations folder: 192x192,
- RMVXA Graphics/Characters folder:
(width/12)x(height/8)for most files,(width/3)x(height/4)for files starting with$or!$, - RMXP Graphic/Characters folder:
(width/4)x(height/4).
Both the smaller grid thing and automatic grid guessing are now implemented for 2k/2k3/XP/VXA.
Minor annoyance: the ‘Change grid?’ dialog appears even when the old and the new grid is identical.
Other things:
- Camera tool clears the Copy selection. This makes it harder to do precise copies without a mouse, because you can’t position them precisely.
- When not in tile view, clicking outside of the image probably shouldn’t draw on the image. This is just confusing.
Some things that could be changed (but probably after the move events are sorted out! move events are more important, this can wait for 1.4):
In @common_events{N}, can we only show @condition_switch_id if @condition_switch is true? (Showing unused switch — with its name — is distracting: it seems to attract more attention than False above it.)
The default size of the Map Resize window (... > Resize) is too small:
First, it's too small so it's harder to point it with a mouse.
Second, if you enter a 3-digit number, it doesn't fit:
I suggest doing what you've done in the image editor, or something like that.
Help on event command is too small:
Maybe not save the opacity=0 when creating a new colour?
When you are creating a new colour in Image editor, the opacity of the previous colour remains.
This might be useful when you're drawing with semi-transparent colours or something, but if you're not using opacity (i.e. you just draw with 1 transparent colour + many non-transparent colours), this can be confusing at first: you're creating a new colour but it's not working.
Since having >1 colour with opacity=0 is a very rare use-case (because they look exactly same), maybe pre-set opacity to 255 when it's 0?
Help on event command size fix, and the map resize window size fix, are fixed and ready for v1.3-1. Mind confirming that the current state of master isn't... too broken? Everything seems fine here, but I tend to miss things.
The current state of master is good, as far as I can see.
Another small thing:
'Show Picture' event command has 'magnify' preset to 0, so the picture is not visible by default. Also, it has pictureId preset to 0 but it's an invalid value (it should be >= 1).
Regarding 'Show Picture', I believe we discussed that being fixed over IRC, so... dealt with, for now.