Visual indicators of select parameter values for placed events

[Seren-35]

In layer view, much like JCS, MLLE displays three properties of events at all times: their name, difficulty, and whether they have a generator or not. Although sufficient, this system has always had its shortcomings. For example, systems of sucker tubes and triggers are unnecessarily hard to construct and read. It's common to make mistakes where one particular sucker tube event is facing the wrong direction, or one trigger zone has the wrong ID, and such errors can go undiscovered until much later. In SPACE ISLAND LEVEL WITH ISLANDS by EvilMike, a small error in this area allows players to manipulate triggers into warping them to a more advantageous area when they fall into the warps below.

You can imagine this would've had a slightly better chance of being caught in advance if the layer view of the area looked like this instead.

And much better if it looked like this.

As a kid I always struggled to remember what parameters to input for sucker tubes to go in a particular direction. Ideally they would have little direction indicators so you can see what's going on.

Recently, for my level in Holiday Hare 24, I came up with an event whose sole function was to delete the event directly below it. This enables a fairly natural expression of normally impossible adjustments based on difficulty level. For example, this section has 1 spike ball when playing on easy difficulty, 3 on medium, and 4 on hard.

Obviously sometimes you may want to delete an event that already has another event above it, so ideally this would support a direction parameter, but without clear direction indicators that again becomes very hard to read very quickly.

Other examples where some sort of indicators could be highly beneficial include winds and belts (where the event name can be an outright lie), anything that has an ID (such as warps and rolling rocks), path events, bouncer crates now that they can contain any other ammo type, anything that permanently sets the level of something (water, ambient light, echo), hurt events now that they can face any direction, and no fire zones now that they can set other player properties.

The exact form of those indicators, and how configuration files should define them, are worth discussing. I think that:

• Adjacent events with identical parameters should be visibly grouped together in some way, which can be a powerful visual aid as I've hopefully shown above.
• Anything that has a direction vector should be accompanied by a flat arrowhead or multiple (e.g. for hurt events), which can be arbitrarily rotated (e.g. for sucker tubes). I believe parameters for such events usually use one of three approaches: a set of Booleans, each corresponding to a predefined direction (hurt events), an X and/or Y value (sucker tubes, winds, belts), or an angle value (path events). It should be moderately easy for configuration files to support all three by using dedicated letters to indicate semantics, similar to how checkboxes are implemented, although for the path approach in particular, one might want to allow for a different origin than horizontally right, and a different direction of rotation than clockwise.
• For anything with an ID, I believe the ID should be part of the event's displayed name. This can be indicated with some special character sequence in the declared displayed event name, e.g. $WarpID$ means "insert the value of the parameter named WarpID." This is highly flexible.
• For anything that can turn something on, off, or toggle it, I'm tempted to suggest some sort of Unicode characters, e.g. ◉, ○, ◑, again as part of the name. How this should work is not obvious. Something worth considering would be allowing simple if-else tests as part of the display name, e.g. for trigger zones this portion of the name could be something like {$Switch$?◑:$Set to$?◉:○}. So coupled with the previous point, the complete name of the trigger zone event could be configured to Trigger|$TriggerID${$Switch$?◑:$Set to$?◉:○}. (The syntax is proof of concept and should be given more consideration.)
• For events that can entirely change meaning depending on parameters, such as bouncer ammo boxes and no fire zones, the whole name should change. This can be done with the same approach as shown above but extended to support numerical values, e.g. {$Var$==0?No Fire:$Var$==1?Grav:$Var$==2?Invis:Error}|Zone.

[Seren-35]

Additional note on color: currently MLLE uses colored event names exactly as JCS does, to indicate difficulty. However, there are significantly more battle uploads than single player uploads on J2O, not to mention other multiplayer game modes. And then, many single player levels don't actually use the difficulty system to a worthwhile extent. This suggests that most levels gain little to no benefit from highlighting events placed at different difficulty levels, but could perhaps benefit from the use of color for other purposes, such as making pickups stand out from modifier events, or highlighting key objects such as powerups and carrots. A trigger-heavy level might even want to show on-triggers as green and off-triggers as red. All of this could be done if the displayed name configuration fields could, in addition to the above, contain a color specifier.