[SUG][EDITOR] Resize upwards rather than downwards [RESOLVED-CAN BE CLOSED]

[WillLem]

It's in the title; resizing levels vertically downwards doesn't make any sense, because if you've spent time building a level and then you need a few pixels extra height, you have to move the entire level downwards.

The reverse is also true: if a level is too tall and you want to shrink it vertically, you have to move the entire level upwards and then resize.

[Dullstar]

Resizing levels vertically downwards makes perfect sense, and I actually do it quite often: sometimes you might want to increase the level size by raising the ceiling, while other times you might want to increase the level size by lowering the floor. As long as you can't choose which edge to add/remove length from, sometimes you'll have to move the level. For that reason, I don't think simply changing which side the change is made from would really fix anything.

It's also probably (slightly) technically simpler to move the bottom edge: many computer applications place y=0 at the top with y increasing as you go down; if the level is resized by moving the bottom edge, the y values remain valid, while if the level is resized by moving the top edge, the y coordinates would need to be changed (essentially, automatically doing what you're doing manually). While it would make sense to do this if it were always/nearly always the desired behavior, it makes less sense when both options are desirable some of the time.

[WillLem]

Resizing levels vertically downwards makes perfect sense, and I actually do it quite often... As long as you can't choose which edge to add/remove length from, sometimes you'll have to move the level. For that reason, I don't think simply changing which side the change is made from would really fix anything.

I see your point, but my experience of it is that I generally always want to raise the top edge rather than lowering the bottom.

Also, what you've said doesn't address the issue of wanting to shrink a level: if you do so without moving the terrain pieces first, they disappear off the bottom edge of the level. This absolutely wouldn't ever happen if vertical resize was top-edge dependent, even for those who design top-down; it's way more likely that, when shrinking from the top, it's either being done to remove empty pixels or to define the top edge having placed all necessary terrain and objects.

many computer applications place y=0 at the top with y increasing as you go down; if the level is resized by moving the bottom edge, the y values remain valid, while if the level is resized by moving the top edge, the y coordinates would need to be changed (essentially, automatically doing what you're doing manually).

Good point, but as I'd rather levels be resized upwards rather than downwards, I obviously think it would be worth doing this. Maybe a poll is needed to sort this one out.

I once again have to suggest that the best solution seems to be allowing a user-side option to determine this aspect of resize behaviour so that everyone's happy, but at least a poll would indicate what others' thoughts are.

Incidentally, when it comes to polls, if it turns out that I'm very much in the minority on a particular opinion/issue (which is often the case!), I find it a lot easier to accept the outcome knowing that I'm in the minority; whilst my views/ideas aren't always popular, I generally do want the majority of people to be happy.

[Dullstar]

Maybe something like this?



This is the canvas size dialog box in Paint.net; notice the "Anchor" settings. This determines where the current image should be placed in the resized canvas. A similar control could be included next to the level size option to determine where the existing portions of the level should go.

[IchoTolot]

I think extending a level upwards is just plain confusing and your main argument:

if you've spent time building a level and then you need a few pixels extra height, you have to move the entire level downwards.

doesn't hold up.

I, for example, tend to start my levels more on the upper side and build downwards rather than upwards. So it depends on the way a person is building a level. You mentioned shrinking, but it's again up to the person's creation style and to the level which side is more critical.

But by far the biggest problem with resizing upwards is:

EVERY program I know resizes downwards and to the right by default and everyone new who uses the NL editor would expect it to work the same here as well. I would even write a very long rant if I would be a new user and find out that the editor works this way.
Even in programming languages resizing matrices, vectors and stuff works this way.
So even if we would have more usecases where extending upwards would avoid having to move a level, going against common sense and ingrained user expectations would be very harmful.

Edit:
I would support it as an option though where the "normal" way is the default and you can change the way levels extend in the options menu to a non-standard way.

[Dullstar]

Resizing levels vertically downwards makes perfect sense, and I actually do it quite often... As long as you can't choose which edge to add/remove length from, sometimes you'll have to move the level. For that reason, I don't think simply changing which side the change is made from would really fix anything.

I see your point, but my experience of it is that I generally always want to raise the top edge rather than lowering the bottom.

Also, what you've said doesn't address the issue of wanting to shrink a level: if you do so without moving the terrain pieces first, they disappear off the bottom edge of the level. This absolutely wouldn't ever happen if vertical resize was top-edge dependent, even for those who design top-down; it's way more likely that, when shrinking from the top, it's either being done to remove empty pixels or to define the top edge having placed all necessary terrain and objects.

It absolutely wouldn't ever happen? What if the level has a ceiling, such as this one?

This level's vertical size is mostly simply due to the fact that the level provides a lot of stackers, and I wanted to ensure that they could not be used to make the fall into water safe (well, if you were to platform over the water, anyway). If I wanted to re-shrink it, however (suppose namida adds the downdraft object I suggested earlier and I wanted to change the level to use it, for instance - this was the level I was working on when I thought of the idea, after all, though at this point I'm used to its size and I'm not sure I'd change it back to its original size, but I digress), then parts of the level would go offscreen if I don't change the terrain first. Note that I haven't specified whether the change happens from the top or bottom: in this case, it doesn't matter - both options would cause parts of the terrain to go offscreen. This is true of any level that has a ceiling. It's not unusual for levels to have open-air ceilings, in which case the top boundary doesn't really have anything going on, but it's also not unusual for levels to have death pits of some sort at the bottom, either - in which case you might want to trim off the excess space at the bottom.



One of my more common use cases for extending a level is extending fall distances, whether to make room for a fatal fall, or for increasing the length of a fall such to make it harder to backroute the level with builders/stackers, if I didn't intend for the player to use them to break the fall. As such, the top-anchored components should maintain their current position relative to the top of the level. Of course, so should the bottom components in many cases. From a convenience standpoint, a simple way to choose the anchor point for the resizing is probably best: this way, we can choose whatever will cause us to have to move the fewest components. Of course, if you like having solid walls around all the boundaries like I do in a lot of my levels, then you're pretty much going to have to move some level components no matter what.


Suppose we want to make this level bigger, but keep the overall layout similar: no matter which edge you move to extend this level, something will have to be moved.

[namida]

Maybe something like this?



This is the canvas size dialog box in Paint.net; notice the "Anchor" settings. This determines where the current image should be placed in the resized canvas. A similar control could be included next to the level size option to determine where the existing portions of the level should go.

My current thoughts leans very heavily towards implementing something like this as a dedicated "Resize" submenu, while leaving the existing Width / Height boxes too with their existing behaviour. (But perhaps a button to open the more-detailed Resize menu could be next to those boxes.)

I absolutely agree that the downwards / rightwards extension is expected when there is no option to the contrary. In 3D things are a bit more arbitrary, but in 2D this is almost always the expected way for things to work. I also absolutely agree that there are cases where "some other behaviour" is more useful. Hence - the above proposal.

[WillLem]

Maybe something like this?

Yes, brill! +10,000,000,000,000,000,000,008 for this

My current thoughts leans very heavily towards implementing something like this as a dedicated "Resize" submenu

This would also work.

it depends on the way a person is building a level.

Good point, fair enough. Dullstar's example also consolidates this: I guess I hadn't thought of it that way, but you're right - it is dependent on preference and design circumstances. I tend to build upwards from the bottom of the level - maybe I should try it the other way around for a few levels, see if I come up with any new ideas!

everyone new who uses the NL editor would expect it to work the same here as well. I would even write a very long rant if I would be a new user and find out that the editor works this way...  going against common sense and ingrained user expectations would be very harmful.

You mean in the same way that some newcomers rant about lack of timed bombers and other expected features of Lemmings being missing from the game? Since when is the NeoLemmix community bothered about holding up to other people's expectations? Just sayin'

I agree, though; the Editor should behave as is most widely expected. I'm guessing that Dullstar's explanation that 0 is always in the top left corner accounts for this.

I would support it as an option though where the "normal" way is the default and you can change the way levels extend in the options menu to a non-standard way.

Cool. In that case, it's clear that the current behaviour is majoritively preferable, so maybe having a little resize menu or something along the lines of Dullstar's suggestion may come in handy for those odd times when you want to resize in a particular direction...?

[namida]

You mean in the same way that some newcomers rant about lack of timed bombers and other expected features of Lemmings being missing from the game? Since when is the NeoLemmix community bothered about holding up to other people's expectations? Just sayin'

In this case, the difference is that those are differences specific to Lemmings, with very strong reasoning behind them. Compared to this, which goes against a near-universal convention that exists far beyond Lemmings - almost any software that allows resizing (in 2D) without specifically choosing an anchor point, will use a top-left anchor like the editor does.

That's not to say even those kind of cases are outright unchangeable, but very, very strong reasoning would be needed. And if a "Resize" submenu like above would do the job, then I think that kills almost any possible reason to change the default.

[Simon]

Yeah, make it a menu.

Resizing is hard to imagine because it breaks mental anchors. With the menu, long-term, you can have preview. E.g., two bland rectangles that show the rough proportion of the planned resize.

Right is most popular side for extension. Top/down are equally less likely.

-- Simon

[WillLem]

if a "Resize" submenu like above would do the job, then I think that kills almost any possible reason to change the default.

Agreed. A submenu and/or something similar to Dullstar's post would be excellent, especially if the user can save their preferred setting as their own default!

Thinking about it, the ability to save level templates might also be good (I suppose this can be done manually). Or simply a "save current global settings as default"... I seem to remember suggesting this a while ago because of having to keep loading the Lemminas style for each new level...

[namida]

I seem to remember suggesting this a while ago because of having to keep loading the Lemminas style for each new level...

Modify your styles.ini file so that the Lemminas style will be first in the editor's list. You just need to change the "order" (or whatever it's called - might be "index", something like that) for the Lemminas style to a lower number than any other style. Negative numbers / non-whole numbers are allowed, if need be. It does not matter where Lemminas is listed in the styles.ini file; just that it has the lower number for the "order" (or whatever it's called) parameter and thus shows up at the start of the list in the editor.

Templates can easily be done manually and while I could consider some "UI sugar" to make it more convenient, it would be very low-priority. Configuring some of the default parameters might be more worthwhile, as could reconsidering what the default (or default default, if that becomes the case) settings are - the default level size is based on no-longer-applicable historical factors, while the default lemming counts and spawn rates are completely arbitrary, but while 40 lemmings would have once been considered normal or even low, these days it's often considered a bit on the high side if there isn't much reason for it. However, yeah, all of this is low priority.

[WillLem]

Modify your styles.ini file so that the Lemminas style will be first in the editor's list.

Brilliant, thanks for this. It will certainly come in handy when I get started on the sequel. I'm having a bit of a break from it all at the moment, but this is definitely handy to know for the (not too distant) future.

Templates can easily be done manually

For sure. I can't help but think though, if there was a way to open the editor directly from a .nxlv file, I'd almost certainly use several pre-made .nxlv files from which to load various project "types".

As it is, I generally just end up doing everything from scratch unless it's a remix level or one that's very close to an existing level. It's not a major issue though, tbf.

Configuring some of the default parameters might be more worthwhile

Agreed - if this can be implemented, it would definitely be more useful than templates.