Graphic sets is something I'm going to start coding for very soon, so any ideas you have for it in particular, get 'em out in the open now!
Some thoughts I'm considering:
Some objects will no longer be inherently part of a graphic setThe obvious case here is pre-placed lemmings, which will be an inherent feature without requiring a graphic set to explicitly contain a "pre-placed lemming" object. After all, the graphic set's "pre-placed lemming" object is only even used by the editor; the game itself just places a lemming at that point (and doens't use the actual object sprite).
That aside, I'm also considering the same for some other commonplace objects such as pickup skills and one-way arrows. In these cases, the most likely setup will be that default graphics for these exist, with each graphic set having the option to override them with custom ones. This removes the need to especially design these items for graphic sets (or insert them in converted sets that don't contain them), while still allowing graphic sets to customize the appearance of them if desired.
Windows and exits are a tricky issue, especially given that a single graphic set may have more than one of each. The obvious option here is to have "default" ones, which are always usable, while also allowing a graphic set to have its own custom ones (which would generally be the preferred option to use if they exist). Another option may be having a "generic" graphic set which can be used alongside another one (since I plan to support multiple graphic sets in a single level), in cases where a graphic set might not specifically have these objects. Of course no such graphic sets
currently exist, but especially in the case of windows, custom graphic sets often don't feature a custom window at all, or if they do, it's just a recolor. As such, a setup that provides a default one might make sense.
Distinguishing between types of objectsCurrently, NeoLemmix simply distinguishes between three types of pieces in a level's map - objects, terrain, and steel areas. I'm wondering whether it might make sense to take that one step further, and treat different types of objects seperately. This could have advantages not only for organising, and finding specific object types in the editor, but also with efficiency while running.
BackgroundsSupport for selectable background color is requested fairly often. Support for background
images less so, but I have seen questions about it, and we've seen levels (for example, in Lemmings Reunion) where no-effect objects are used to replicate the effect of a background. Having some kind of inherent support for these, rather than hacky workarounds being used, not only is likely to be more efficient, but it can also allow for user options relating to disabling custom backgrounds, which may also be preferable in some cases.
ResolutionAt the moment, I'm leaning towards allowing of multiple resolutions in a single graphic set file. In the case of high-res graphics not being present, the low-res ones would simply be zoomed if the user has hi-res settings (perhaps with a filter applied? That could probably be an option rather than a fixed behaviour). In the case of low-res graphics not being present, they would be downsized from the high-res ones in exactly the same way NX1 does. (It should be noted that the low-res image would be important even when using high-res, due to that physics will still work in low-res.) I'll also make sure to futureproof this to potentially allow even higher resolutions at a later date; though initially such will not be supported. Ideally, a graphic set should at least have low-res images, even though support would be there to autogenerate them (perhaps this should be done at creation / conversion time, rather than at runtime?).
Future additions?If you have an idea that probably doesn't belong in the initial version, but might be considered in the future, it could still pay to drop it now. If there's interest, then even if I don't plan to implement it right away, I can possibly design in such a way it'll be easier to implement it in the future.