D/A5: Drop manual screen start

[namida]

Screen starting position will be determined automatically. I will drop support for setting a screen starting position per level. That wouldn't give a consistent view anyway, because the game can run in arbitrary resolutions.

That wouldn't give a consistent view anyway, because the game can run in arbitrary resolutions.

SuperLemmini handles this by defining the start position in the level data based on the center of the screen, not the top-left corner. I'm not sure if an automatic algorithm could account for every possible case? Since this is ultimately a cosmetic thing anyway, perhaps allow designers to specify it but make it optional; if not specified, use the automatic algorithm.

[Simon]

C++ Lix has automatic centering on the average of all hatches, with optional manual choice of start position. Result: People haven't used the manual starting position anymore. The automatic thing seems to have been good enough:

hatches
    .filter(only hatches of local player)
    .map(hatch => spawn point)
    .average
    .centerScreenOnThere

...with a reasonably smart averaging function, taking into account torus properties of the level.

Yes, the manual setting could specify a center point, not the top-left corner. Nonetheless, a manual setting remains complexity that can be removed both from level design, and from the program design. The existing culture suggests that this removal is a good idea.

Specifying a center is better than specifying the corner. Yet, due to arbitrary resolutions, there is no guarantee about what's visible.

-- Simon

[Nepster]

Having an automatic screen start is very good for most levels, espcially if there is only one hatch or if all hatches fit more or less within one screen. However there are a few levels where this would result in a screen start in the middle of nowhere, because two hatches are on different ends of the level. How about an algorithm, that ensures that at least the first hatch is always visible?
Here are two suggestions for such an algorithm (after filtering only for own hatches/exits):

Code: [Select]

Set screen_start_region = whole level

Loop through all hatches in spawn order
    Intersect screen_start_region with region_such_that_current_hatch_is_visible
    If Intersection == empty
        keep old screen_start_region
    Else
        set screen_start_region = Intersection

Perhaps do now: Optimize such that as many exits are visible as possible

Take center of (largest connected component of) remaining screen_start_region

or alternatively:

Code: [Select]

Compute average hatch position as currently done.

Set screen start inside region_such_that_first_hatch_is_visible at best approximation of this average

Of course I cannot really test how well these algorithms work, so take them with a grain of salt.

[Clam]

C++ Lix has automatic centering on the average of all hatches, with optional manual choice of start position. Result: People haven't used the manual starting position anymore. The automatic thing seems to have been good enough:

I always set the start position manually when the level is larger than one screen, or wraps. It didn't occur to me that other designers don't. I find it really annoying when the start position leaves just a tiny bit of the map off screen in one direction, so I manually set it to the edge of the map.

With the new variable resolution however, it doesn't make sense to set this manually, unless you want to test it on a bunch of different resolutions. The larger visible area reduces the need for it too. So I guess it can go

[ccexplore]

Yeah, wasn't it Simon who once said how he hates it when computer tries to be smart in guessing what the user wants and takes away the choice from the user? Or something like that.

Nonetheless, a manual setting remains complexity

Please don't abuse the word. Implementation cost by itself is not complexity.  Of course any feature will require code to implement, that in and of itself is not complexity.

I'm just not particularly convinced that in this particular case there is anything complex about it, relative to everything in the game that has already been implemented.  If anything, the automatic algorithm that has already been implemented seem to be the more complex thing compare to obeying a setting in the level.

======

Anyway, I was almost going to say that it's probably okay to drop it, and then I looked at my own levels.  Applying the centering algorithm to my Brickout level in 640x400 (or whatever the viewport's size is in C++ Lix), and I think it ends up with a small portion of the leftmost area of the level unnecessarily cut off.  It's certainly cosmetic and you can argue it won't happen anyway with a larger viewport that would be more likely given the typical display resolutions of today, but it does seem to highlight that sometimes it's nice to be able to override an algorithm.

I'll definitely agree that it's of lower priority, and because it's strictly cosmetic, you can most definitely get away with dropping it regardless of how people feel (ie. I'm pretty sure in the end, no one will refuse to make or release a level in Lix purely because of this; even I can live with the automatic algorithm on Brickout if that's how things land.)

Nepster's also makes a good point that the algorithm as stated seem to be not smart enough.  I think most can agree that it's desirable to help ensure the first lix out is not offscreen, so for an automatic algorithm, we probably want to keep the first hatch visible if nothing else.  Funny enough, this appears to add some complexity (well, at least more code) to the algorithm, complexity that one can replace instead by providing the option for manual override.  Hmm......

[Proxima]

I always set the start position manually when the level is larger than one screen, or wraps. It didn't occur to me that other designers don't.

I always do, and I said as much to Simon in the chat discussion prior to his posting this topic. However, I did also say that I'd had a quick look through a few of my levels and it looked like they would be fine with automatic start positioning, so maybe that's where the confusion arose.

Regarding Nepster's point, for levels like The Borderland / This lix is your lix (or, to cite an example we're all familiar with, Rendezvous at the Mountain)
it could be argued that starting the screen in the centre helps to notify the player they are dealing with a multi-hatch level, and avoids feeding them preconceptions about which hatch to work on first. It's also a nice aesthetic touch if the screen start contains the exit (though usually it won't centre on the exit).

[Simon]

Some interesting points -- will reply more thoroughly in the upcoming days!

-- Simon

[ccexplore]

Would it be fair to say that you don't really need to make a decision on this anytime soon?  It feels to me like even if enough people are upset now to actually make you relent, it'll still be the case that there are simply far more other important things to do in D Lix right now than adding this feature in.  So either way it is sort of postponed anyway basically.  And it doesn't seem like it'll be all that bad to end up adding it back in later versus now, if there is still enough resistance to leaving it out by then.  It feels to me like you can probably wait until like at least a month after D Lix got to a point where people are actually using it as their main/only version of the game for playing and creating levels.

[Simon]

he hates it when computer tries to be smart in guessing what the user wants and takes away the choice from the user?

Hnn. >_>

The computer shall not try to be smarter than the user.

Nonetheless, a manual setting remains complexity

Please don't abuse the word. Implementation cost by itself is not complexity.  Of course any feature will require code to implement, that in and of itself is not complexity.

I imagine 4 archetypes of Lix users:

• Level players -- who are hit by bad game design, and bad game UI.
  
• Level authors -- players who, in addition, get hit by bad editor UI.
  
• Pack maintainers -- authors who, in addition, get hit by bad abstractions and bad file formats.
  
• Programmers -- who are constantly hit by unnecessary or bad source code.

We can have complexity at any level here. I agree that complexity in the upper levels is worse than in any lower layer.

Icho was with me yesterday. He strongly suggests to keep the manual setting. A sloppy screen start can kill an otherwise splendit first impression of levels. He readily agrees that in 95 % of levels, the automatic setting would suffice, which is not enough.

The complexity introduced by manual settings hits mainly the programmer. Only in case of radical format changes, pack maintainers are hurt.

Meanwhile, level authors are happier about the extra functionality than confused about the extra button. And the player benefits for free!

Would it be fair to say that you don't really need to make a decision on this anytime soon?

Very fair. I have to revert one commit, so D Lix's pre-alpha editor will keep saving the starting position.

-- Simon

[Clam]

Icho was with me yesterday. He strongly suggests to keep the manual setting. A sloppy screen start can kill an otherwise splendit first impression of levels. He readily agrees that in 95 % of levels, the automatic setting would suffice, which is not enough.

I like this point. But can level authors do any better with a manual setting, given that they now have to contend with arbitrary resolutions, some of which they can't even test themselves? I suspect the answer is yes, but it's far from trivial to put into practice. Even now, looking over my levels in the default windowed resolution, I'm not convinced I've set the screen starts correctly – though whether the algorithm would do any better is another matter.

Anyway, regardless of which gives the "better" result (if you can even measure that), perhaps manual setting wins on principle:

The computer shall not try to be smarter than the user.

Related issues that have come up on IRC since this topic was started:

• Default zoom level: If the level fits twice over on your resolution, should the view be zoomed in by default? (Initial thought: no, for the sake of consistency – though it does look really odd having such wide borders around the level.)
• Wrap: Should sections of the level appear more than once? If not, how do you tell the player that the map wraps around at the edge? (Initial thought: no, and maybe you don't need to do anything special?)

[Simon]

But can level authors do any better with a manual setting, given that they now have to contend with arbitrary resolutions, some of which they can't even test themselves?

We could display in the editor a few screen start rectangles for arbitrary 4:3 and 16:9 sizes. Icho liked the screen start rectangle in Neolemmix's editor.

Default zoom level

I haven't thought about it deeply yet. Filling the screen with something nice is always better than blank placeholding.

Wrap: Should sections of the level appear more than once? If not, how do you tell the player that the map wraps around at the edge? (Initial thought: no, and maybe you don't need to do anything special?)

There's a suggestion by Ichotolot on github. Apart from that, I haven't thought about this yet, either. Torus maps are central to the design, but defy intuition. They need strong visual support.

-- Simon