Screen size slightly below level size

[Simon]

(The area of the Lix window that shows level during play) can be slightly smaller than default level size. View can appear like a view on the complete level, yet can obscure important ledges. Problem observed on Flopsy stream (topic with all Flopsy plays lemforum pack).

A good solution to this shouldn't assume any particular values. At best, have threshold ratios.

Designing smaller levels shouldn't be the answer. You'd merely move the problem to a different screen size.

First Idea: When screen size in one direction is between 70 % and 100 % of level size in that direction, scroll level based on mouse position? As if some really slow RMB-scrolling were always active. Can well become annoying.

Minimap? Weird application of a minimap, because the minimap's main use is to overview huge levels. Minimap feels safe to ignore when 80 % of the level is on the screen anyway, thus doesn't help much. Minimap solves a different problem.

Zoom to fit level? I assume that non-integral with nearest-neighbor looks dumb, any other filter obscures pixels. But haven't experimented.

Related issue: Zoom 1.5x, would it look good?

-- Simon

[namida]

Perhaps some kind of indicator for "you can scroll further in this direction" is a solution? I don't know exactly how this should be implemented, though.

[ccexplore]

Any solution to this needs to be balanced against the workaround of "just let the user learn this once and then they will know subsequently to always confirm the boundaries by scrolling".  I don't feel like this is such a pervasive problem (that a level happen to of a particular size, and also have elements obscured but also not obvious that something is getting cut off), so the bar for an acceptable solution should be set higher accordingly.  Frankly, it seems like "survey the entire level, making sure you have indeed seen the entire level by scrolling" is an obvious good practice that should be learned early and become second nature, and something you'd generally want to do as one of the first steps of level solving.  (Disclaimer: I haven't had the chance to watch the video yet.)

One possibility could be to display flashing scrolling indicators (like little arrows) near the edges of the screen, for the first few seconds or so after the level has started, and then off afterwards (so it doesn't get too distracting).  You'd probably also want to avoid doing this on level restarts and so forth to further minimize the distracting aspect.  Maybe you can only enable this based on the level size being close to the screen size, although it may then become confusing why the indicators aren't always shown even when scrolling is possible.

Another idea is to display some sort of screen transition when the level starts, where for levels where scrolling is possible, we first display the level slightly zoomed out, and the transition is to zoom into the default zoom level, thus hinting that the level is scrollable.  Since it's purely a transition and not the final zoom level, it's okay for pixels to be slightly obscured (ie. blurred) due to zoom.  I haven't quite decided if this is better or worse than the flashing scroll indicator idea above.  I do know Simon will probably at least object to the time-wasting nature of screen transitions, and I will admit that this seems more work to implement than the flashing arrows above, for something that's not clearly better.

[ccexplore]

Still haven't watched the video yet, but have to ask:  so the level preview in the level browser isn't able to clearly display those "important ledges" that were missed?  Granted, I understand that people don't necessarily pay that close attention to the level previews.

Can you really make any decisions based purely on the difference between level size and screen size?  I mean, say we extend the problematic level with decorative terrain further out.  This could potentially artificially extend the level size beyond your proposed thresholds, yet you will end up with the same initial view in-game, so presumably wouldn't the user still have the same problem?  The only difference is that it will be more obvious when comparing the level preview against the initial in-game view, but that assumes the user ever paid attention to the level preview to begin with, hence my question/comment above.

Anyway, having thought about it a little more, the flashing arrows idea probably works better than a zoom-in screen transition, since the latter becomes less effective the closer the level size is to the screen size.  The "always active RMB" idea might also be okay, it will have to be tried out to see.

[namida]

Hungry Software's "Ducks" used (by default; there was an option to change this to a more Lemmings-like system) a scrolling system that could be considered to an always-active RMB. I felt it worked quite well, really. However, one critical difference here - Ducks did not have a clickable skill panel; selection was done via keyboard or mouse wheel. The presence of a clickable skill panel is likely to cause issues at least with the downwards direction if taking that route.

[Simon]

Thanks for the resourceful ideas from both of you.

I have vague feelings about each idea, but not enough to make a qualified post. I got too sidetracked and should focus on reallife much more.

-- Simon

[NaOH]

I like CCX's idea for a zoom-in transition. Every level (that is larger than the screen size) could start with a zoom-in. In worms (1995), every level starts with a zoom in: https://youtu.be/IWDhUAK6N0k?t=20s . I think it could be cool if you stylized it the right way.

Alternatively, levels could start by panning in.

Minimap? Weird application of a minimap, because the minimap's main use is to overview huge levels. Minimap feels safe to ignore when 80 % of the level is on the screen anyway, thus doesn't help much. Minimap solves a different problem.

Minimap is something that is missing from Lix, and might be very helpful both in single player and multiplayer. With the added screen real-estate from supporting higher resolutions and different aspect ratios, it could make for a very good addition to the UI. However, it probably wouldn't help solve the problem; If I remember correctly, some levels of the original lemmings I couldn't solve when I was young because I didn't realize the level scrolled. The minimap didn't help. (Maybe I am misremembering, though.)

[Simon]

Download D Lix 0.6.21

Inspired by the Worms-ish from full level view at the beginning, I've implemented nonintgeral zoom values. Proxima has suggested that last year, and I've always put the testing on the backburner. Now it's in.

But I don't zoom in on level start. Instead, I fit the level height to the screen height. If the level is wide, then we still have horizontal scrolling. Exception: If the level is merely a tad wider than the screen, then I fit level width to screen width, and have a small dark border at the top.

Screenshot 1
Screenshot 2

When you zoom in, you'll be at integer zoom again, and have crystal-clear pixels.

I should use this for a while, to see whether blurry initial zoom is annoying. I find myself zooming in often now, to get a better view.

-- Simon

[ccexplore]

So both screenshots have nonintegral zoom?  I have to admit I can't quite tell from a quick glance, so maybe that's a good sign?

When you said fitting level height to screen height, I assume you just mean only when level height is less than or up to "merely a tad taller" than the screen?  Otherwise you would start off quite zoomed out with a tall skinny vertical level (ie. several screens tall, one screen wide or less).

[Proxima]

That is an unfortunate consequence of the current algorithm -- really tall, narrow levels like Adventure Playground and Metal City Mayhem start off squashed. Not sure what the best way around this would be -- it's not enough to establish an arbitrary cut-off based on level height, because for example Goblin City (large in both height and width) also shrinks to fit on the screen, and this looks good. Maybe the algorithm should stipulate that if the level wants to shrink, it can't shrink to less than 640px width?

[Simon]

So both screenshots have nonintegral zoom?

Yes!

Otherwise you would start off quite zoomed out with a tall skinny vertical level (ie. several screens tall, one screen wide or less).

That is an unfortunate consequence of the current algorithm -- really tall, narrow levels like Adventure Playground and Metal City Mayhem start off squashed.

Yes, 0.6.21 fits tall levels' height to screen height. This was bad, even though only a few levels were problematic.

Maybe the algorithm should stipulate that if the level wants to shrink, it can't shrink to less than 640px width?

This is progress, but I've been reluctant to choose absolute numbers. Instead, 0.6.22 matches level-width to screen-width if the level is taller than wide.

0.6.22 zooms onto the mouse cursor, it will point to the same pixel before and after zoom. This is surprisingly crucial for my user experience. Mouse wheel in and out, whee.

Download Lix 0.6.22

-- Simon

[Nepster]

Upon playing a bit with V0.6.22, I must say that I am not really happy with the automatic non-integral zoom. The two main reasons are:
1) With the usual zoom I know where to start builders and platformers so that they finish at the intended position. But the with the non-integral zoom, I never seem to get it right. If the alternative zoom would always be 70%, then I could learn how far builders stretch there, too. But given that the zoom value varies with the exact level size, I more or less have to learn a new bridge size for every single level.
2) The normal lix size is large enough to easily select single lixes, even in a hurry with slightly inexact mouse positioning. But with the reduced size of roughly 70% (or perhaps even less?), it happened several times that I clicked only next to the lix, not on it. The target was simply too small for the mouse.

If you keep this zooming out on slightly too large levels, I would like to have either an option to disable this completely, or that when changing the zoom in-game, the zoom snaps to 100% instead to some other non-integral zoom.

[Simon]

Lix 0.6.23 considers fewer zoom values as equal, therefore snaps to closer values. If this doesn't help, I have to think about the entire algorithm again.

-- Simon

[ccexplore]

It sounds like for someone like Nepster, they would probably end up just doing this all the time:

When you zoom in, you'll be at integer zoom again, and have crystal-clear pixels.

In fact I kind of wonder why he didn't seem to be doing that already when trying 0.6.22 out, I guess he's purposely trying to stay with the initial zoom level and see how much he can get by without zooming back into a normal integral zoom level?  I don't see any amount of tweaking of the algorithm will change the fundamental fact that Nepster seems to be more used to integral (in particular 100%) zoom levels, and that the non-integral zoom levels are creating new gameplay issues that aren't making it desirable for him to use in most cases.

It would make sense to have a user option to only do integral zooms (including the initial view thus effectively disabling the new "feature") if it sounds like for some users, they'd just end up doing the above anyway.  I've always felt like Flopsy's case to be a bit of an edge case anyway, and here we seem to be trying to solve an edge case with a feature that has pervasive global impact outside of the edge cases being addressed.  (That's not to say there aren't other good reasons to support non-integral zoom, but it seems clear that at least for Nepster so far, there aren't cases where the pros would outweigh all the cons he seems to be actively experiencing.)

[Nepster]

In fact I kind of wonder why he didn't seem to be doing that already when trying 0.6.22 out, I guess he's purposely trying to stay with the initial zoom level and see how much he can get by without zooming back into a normal integral zoom level?

The problem is that in 0.6.22 there is nothing between the 70% (or similar) and 200%. And 200% is too much zoom and not enough level area for my taste.