Editor revamp design document

[Semphriss]

The current editor present several inherent flaws in its design; I would like to design a new editor from scratch. Given that I aim to cover the maximum amount of use cases possible, I'd like to request both the development team and the public to post any idea or request they have before I develop the document more.

---

Brainstorm

Things to improve in the editor:

• Increase cross-platform usability
  • Ensure it is usable with:
    • Mouse only
    • Keyboard only
    • Touchscreen only
      • Gestures? (one finger = scrolling, double-tap = place object/tile, two fingers = zooming, etc.)
    • Gamepad only
      • Navigation through the UI and inside the sector using the gamepad
• Increase ergonomy
  • Make sure all elements (UI, Sector, etc.) are large enough to be usable on phone screens
  • Add keyboard shortcuts for more stuff
  • Generally, avoid large mouse movements (e. g. requiring the user to move the mouse at several places on the screen that are far away from each other, only to accomplish a single task)
• Adds some fun "feeling" features
  • Add animations to:
    • The camera, when it moves/zooms (easing)
    • Tiles and objects spawning/despawning
      • Idea: Once a streak of tiles is placed and the mouse left button is released, have tiles bounce one by one quickly in the order they were placed
      • Idea: When sprited objects are placed, they should do a little bouncing animation (Similar to certain animations in Tux Builder)
      • Idea: When sprited objects are deleted, there should be a "poof" animation (shrinking to nothingness with a small dust animation left behind - usage should be similar to the explosion object)
      • Idea: When a badguy is deleted, fake a death animation
    • UI elements?
• Add features
  • Add zooming in sectors (and possibly other screens, like the particle editor, the scripting editor, etc.)
  • Object templates: let the user select a group of tiles and objects, and save them to another file that they can open easily in other levels
  • Particle editor: Add a toggleable background and the ability to place tiles (for the particles to interact with) and allow moving the camera or the particle spawn point(s)
  • Script editor: Allow syntax coloring, debugging, and possibly autocomplete
  • Canvas editor¹: Allow rendering objects to be rendered to custom canvases (normal, lightmap or user-defined)
    • Allow mixing canvases together using various blending functions (none, blending, additive, modulate, etc.)
    • Create a node graph to allow the user to state which canvas will be drawn to which other canvas, in which order, with which blending method
    • Allow rendering a custom user canvas to multiple different other canvases, at many different stages of the mixing (allows re-using tasks)
    • Enfore the existence of the normal and the lightmap canvases, and enforce the last link to be lightmap-to-normal with modulate blending
  • In-editor documentation: Allow users to find more information about the tools they use directly in the game, without needing to open external links
    • Problems with external links: Breaks immersion; Some users don't like switching windows; The version of the documentation online isn't always in sync with the user's personal game version
  • Allow autosizing sectors and tilemaps
    • Allow the camera to move away from the sector, and upon placing an object outside the sector, the sector will automatically resize accordingly; same applies for tilemaps (see SuperTux Meltdown example)
  • Allow hiding an object (tilemap, background, particles, or even regular objects like badguys) from the layer widget (currently at the bottom of the screen)
  • Allow grouping objects together, and maybe locking some (and hiding whole groups)
  • Add "Tip of the day" when opening the editor (and openable from the editor, possibly alongside documentation)
    • Possible tips should include information that is not obvious to the newbie level designers, such as:
      • Level design tips:
        • Make sure your level is 100%able
        • Don't forget to set a reasonable target time
        • Make sure the player never has to intentionally penalise themselves (no forced shrinking, no forced respawn at checkpoint, etc.)
        • Make sure the level is finishable with any powerup or no powerup at all (do not require a specific powerup to finish a level)
      • Engine quirks:
        • Coins in crates do not count to the total coins in a sector, whereas coins in bonus blocks do. Use that wisely!
        • Do not rely on the camera not being able to see a certain part of the level; magnification exists, different window sizes too, and soon multiplayer as well!
        • Magic blocks are affected by lanterns, but also by the ambient light. Be careful when choosing your colors!
      • General good practices:
        • A bonus block's color should match the amount of coins it gives: blue is 1, orange is 3, purple is 5
      • Accessibility:
        • Keep colorblind players in mind: if you use color to distinguish something, make sure to use something else as well!
  • Add possibility to create notes/comments on certain regions/parts of a sector
  • Allow rearranging the UI to the user's likings
  • Allow drag-and-dropping files from the OS file manager or desktop directly into SuperTux...
    • ...in object setting fields that take in a file
    • ...in the sector, which would then create an object corresponding to the file type (decal for images, generic object for .sprite files, AmbientSounds for sounds, etc. and if no pattern matches, show an error)
  • Show a confirmation dialog when closing the game (Alt+F4 or clicking the X in the OS window bar) and the level (or any asset) isn't saved
  • Allow playtesting directly in the editor view, to allow playing Tux and placing tiles/objects at the same time; this helps for situations like Tux can't get all four coins during the trampoline jump in the level "Entrance to the Cave" #2149, to find out easily how Tux would move in certain situations (e. g. jump pattern for coins, or the optimal height for a given platform)
    • Related idea: Have a small Tux that can be drag-and-dropped anywhere in the sector, which would spawn Tux at the given location
• Cleanup some existing features
  • New undo/redo system using transactions
    • Transaction: Object similar to a git patch, that holds just enough information to allow undoing/redoing an action on a given sector
    • Requires very good containment of the tilemap object, and make it hard for someone to actually allow editing the sector directly, to ensure that all edits pass through transactions
    • Prepare to make it usable with networking and online collaborative editing (each user should have its own undo stack to not undo someone else's work who's working at the same time, what to do if a local undo would conflict with someone else's action, etc.)
    • Upsides:
      • Much faster if well executed
      • Doesn't need to save the whole level on each mouse press
    • Downsides:
      • Sensible to corruption (Even more importance: Needs VERY GOOD containment of the sector object to ensure ALL edits are done through transactions!)
  • Better integration of autotiles
    • Revamp autotiles to support complex tilesets (crystal tileset, transition between tilemaps, terrain features spanning multiple tiles, corner autotilesets that don't necessarily fill gaps when possible, same thing for regular autotiles, etc.)
    • Write autotile configuration for all tilesets
    • Categorise tiles per theme (linked with "Better categories for tiles" below)
    • Allow an easy toggle of autotiles (linked with "Better support for tools" below)
  • Better support for tools (cloning, eraser, etc.)
    • Make sure the interface doesn't allow buggy combinations, like duplicate and eraser at the same time
    • Make the most useful features most prominent and visible
  • Complete the new UI system
    • Allow customisation of the theme from within the code
      • Also allow customising the theme for the users?
    • Make the theme in the editor look like the current UI
  • Fix object settings
    • Patch some buggy objects:
      • Path nodes: Disallow coexistence of the Time and Speed fields (only one at a time)
      • Dispenser: Allow setting properties to objects in the dispenser
        • Allow setting any arbitrary object?
      • Crystallo: Use intuitive units for all settings
      • Owl: Fix its carry mechanism
    • Add note/warning/error messages to objects in case some have an errorful state?
  • Better categories for tiles
    • Allow making hierarchies of folders (subfolders)
    • Group tiles from the same theme together, and separate each theme (e. g. don't put forest tiles and ghost forest tiles together, or background tiles, background trees and background bushes together)
  • Clarify licenses (explain the various CC licenses and offer an option)
  • Notify the user when the level saves/autosaves successfully
  • In the tilemap selection at the bottom of the screen, add a ghost "new" tilemap which can be selected, and when a tile is placed on it, it becomes a real tilemap and another ghost tilemap is created in replacement
• Accessibility
  • Option to disable all animations
  • Keep colorblind users in mind (don't make anything distinguishable only by color)
  • For touchscreen, do not have anything that requires more than 2 fingers on the screen at once

¹: Requires adaptation from the video engine: Requires support for user-defined canvases and allow custom render targets for all objects

[Alasdairbugs]

Not a fan of the following features:

1. placed objects doing a bouncing animation - this will get confusing when placing an object because you might want it in a certain position but if its bouncing and moving around it might get confusing as to what tile its placed on.
2. poof animation when objects are deleted - unneeded. this isnt mario maker, the editor should aim to be "clean-cut" and no funkiness. i personally wouldnt want unnecessary distractions
3. badguy is deleted fake a death animation - see above (also there are different death animations for the same badguy...)

i think thats everything i dont like. everything else is good. i also reccomend for "fix object settings" to remove arbitrary measurements such as "radius" in crystallo, etc. We should try to use standard units i think - they are the most intuitive.

[Semphriss]

It turns out I forgot to add the "Accessibility" section at the bottom, which does have a setting to disable all animations completely.

The animations are there to entertain the youngest users; they wouldn't be anything big like I did for STK a while ago, just small effects that would last at most a quarter of a second (perhaps even a single frame). But in any case, animations are meant to be entirely optional, and indeed I forgot to specify that in the document; I've fixed that now.

I'm also adding that crystallo setting in the document 👍

[mrkubax10]

There can be option for animations

[Semphriss]

Good catch; I wanted to add an option for accessibility but I forgot.

[cnub66]

Idea: an 'export sector as image' feature to aid in the creation of level maps (like this). May be more trouble than it's worth. File sizes would also be quite large so it would probably need compression (jpg instead of png?) or reducing tile size to 16px/8px in the final image

[Semphriss]

Although I'm aware of many games that allow "full screenshots" like that, I didn't think it actually had a utility; under which circumstances is such a feature usually used? (If it's more than just for fun/sharing)

[Grumbel]

That's mainly useful for walkthroughs and inspection, as it gives a quick way to look at the whole level without playing. Could also be extended to be used for diff'ing levels. Did something like that a long while ago for Milestone1 in Flexlay:

https://pingus.seul.org/~grumbel/tmp/supertux-levels/output.png

[Alasdairbugs]

I think this would be a redundant feature - you can just type a level zoom function into the console while in a level and use the in game screenshot system to give an overview of the stage