fishfolk
Level Editor Improvements
I made a file containing the current bugs in the editor, suggestions on what could be changed to improve it and a few things that Duck Game's editor did right and wrong to possibly get some inspirations. Editor Suggestion.pdf
Thanks for these!
Here are some thoughts on some of the points:
I
scrolling bug
This is not a bug but the way I intended it to work. The trigger zone for moving the camera is a lot more narrow than the menu, so it is possible to select tools without moving the camera. The alternative would be to put the trigger zone before the menu but this is not a good solution, in my opinion, as it makes things a lot more finicky, as you have to hit this zone exactly, in stead of just pulling your mouse all the way to the left to move the camera. The current implementation is also the most common way of doing this, in applications that uses similar navigation, at least in my experience; probably for that reason.
dragging and dropping
This is a bug that we will fix as soon as I get time to do some work on the editor. The actual bug is that when you have something selected and click it again, it will deselect it, even if you hold to initiate drag. So to work around this, in the mean time, you will have to deselect the object you wish to drag, if it is selected, and then click it again and hold to initiate dragging.
II
object placement
The objects are actually placed on the cursor (or grid, depending on grid snap setting) but the positioning follow the normal standard of origin being the upper left corner of the sprite. A simple way of addressing this, for the editor, would be to just offset the object by half sprite width, on the x-axis and sprite height, on the y-axis. The placement will probably never feel "perfect", though, due to how our animation system works, with all frames being the same size and some frames therefore having a lot of empty space on the edges. At the moment the latter can not really be fixed, unless we introduce an editor offset, or something similar, to our data model, which I personally think is a bit overkill for this. A better solution is, probably to offset by sprite height and half sprite width, as mentioned and to compensate, at least for y-axis offsets, by placing a bit above the intended position and letting gravity do its job when loading the map.
player spawn tool
Initially this was part of the object system (map spawn points were actually objects) but this is no longer the case. It might seem like a good idea to merge this with object creation at this point (I don't really agree, as this solution requires more work or, in other words, is a path of more resistance) but in the future, when we extend object creation to also include prototype creation and customization, I think it will be way less intuitive to have this hidden away in what will become a relatively complex part of the editor. It would need its own entry in the object type list, which will be populated further as we extend the editor, and I really don't see how this will decrease complexity. Quite the opposite, actually, in my opinion...
layer menu
I do not think we should hide the layer system for the user. In my experience, from working with similar tools, as well as tools like photoshop, illustrator, Autocad etc., the ability to hide and to lock layers is a very important tool when you build more intricate things. Especially as we extend our functionality with more hotkeys, like select all, to select all objects or tiles, of a certain kind, based on the layer you have selected, etc. This might be a workflow thing, but as a heavy user of CAD software, I would view it as a huge minus if my tool didn't have these features.
The rest are things that we should definitively work to fix/implement!
The editor was re-done with the Bevy rewrite so I'm closing this issue in favor of opening new issues if any of the old feedback is still applicable.
