[Suggestion] Saving Terrain Groups and Using Groups in Styles

Started by Dullstar, August 16, 2020, 09:18:24 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dullstar

From the components present in a NL style, it is often possible to build up much more complex pieces using combinations of blocks and erasers, such as the numerous vertical/horizontal to diagonal bar transitions in this level:
(yes, I keep re-using the same level images I have lying around if they happen to demonstrate my point)

Now that we have terrain grouping, I can see that it has useful properties when working on these sorts of combinations: not only do they become easier to select, any erasers that are included to make up the piece are absorbed completely into the group and essentially become a private member of sorts: it exists to the pieces inside the group, but the surrounding pieces only see the net result of the combination of pieces and don't have to worry about implementation details like what erasers were necessary to make the block possible. In that sense, the terrain block thus functions exactly as a piece provided by the style. You can even use it as an eraser or as part of another terrain group - that's right, nesting terrain groups works exactly how you would expect, and they ungroup cleanly one nesting level at a time.

So, what's the suggestion?


These are two closely related but also mostly independent suggestions, though if both are implemented the implementation of 1) may have implications for the best way to implement 2).

1) Allow user to save commonly used terrain groups. They could then be lumped in with a style's terrain or as an additional groups tab to go with objects and terrain... well, most of the time. But sometimes styles get mixed, and then how should that be handled? Should the piece be shown in the groups tab for each contributing style?

2) Allow style developers to provide pre-built terrain groups. To simplify dependencies, it might be best to require all pieces come from the style the group is defined in. These could then be displayed either as regular terrain, or in a separate groups tab as described in 1). Many styles already feature distinct terrain pieces that are essentially just concatenations of smaller components (e.g. pillars and longer pillars in orig_pillar; bars and longer bars in orig_marble); while this wouldn't necessarily replace that for backwards compatibility reasons, it would be an option for new styles going forward.




Since terrain groups are simply groups of other terrain, levels wouldn't need to be aware of whether the user used a saved/pre-built group or built one from scratch like you can do currently, since it would all look the same in the level file. Therefore, in addition to convenience, it would allow more flexibility in updating styles without introducing breaking changes, as pieces provided as terrain groups can safely be modified or even completely removed from the style without breaking levels that use them as long as the underlying component pieces are left unchanged.

namida

Good ideas. During the initial discussions around piece grouping, it was even debated (at least between myself and Nepster; not sure if it became public) whether groups should be an attribute of the level, the style, or their own thing altogether.

Given that the "store it in the level" still allows these other options to be useable as editor features, without relying on the end-user actually having the standalone group files, there is definitely potential to do these.

Counter-argument though, especially in regards to #1 - once copy/paste between editor instances is implemented, it would be very feasible for a user to simply have a "groups templates" level that they copy / paste from, rather than having to implement a specific functionality for this. This to some extent even works with #2, but a bit less cleanly.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

WillLem

Quote from: Dullstar on August 16, 2020, 09:18:24 AM
1) Allow user to save commonly used terrain groups. They could then be lumped in with a style's terrain or as an additional groups tab to go with objects and terrain... well, most of the time. But sometimes styles get mixed, and then how should that be handled? Should the piece be shown in the groups tab for each contributing style?

Good idea, and yes - I think what you've suggested is the best way to handle mixed styles. Particularly because it's often the case that a particular style has a particular shape that's handy as an eraser, and it would be good to be able to access it from either style.

Also, it means that once you've gone through the slight rigmarole of using the eraser/No Overwrite/layer trick to create new shapes, you can potentially save it as a group and not have to do it again each time.

Just the one counter-point: there is something satisfying about knowing how to rigmarole. Maybe a grouping-saves feature would make people forget how to do it.

namida

Quoteonce copy/paste between editor instances is implemented, it would be very feasible for a user to simply have a "groups templates" level that they copy / paste from, rather than having to implement a specific functionality for this.

Speaking of this, copy/pasting terrain groups between editor instances is implemented in commit 3ea828c and will be included in the next update.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)