Feature: Soft time limit in singleplayer

[Simon]

Original post by ccexplore:

I wonder if Lix should soft-end time-limited singleplayer levels, rather than hard-ending them with a nuke like it is now.  That is, no auto-nuking and give the option for the player to continue playing even after time's up, with the obvious effect that the resulting solution will fail regardless of number saved.

That of course does nothing with the objection on having to repeat execution to coax an otherwise working and not-so-different solution into the time limit, but does at least address the objection about time limits interfering with player's process of solving the level.

Soft time limits: Very good idea.

That makes testing of multiplayer levels much easier. Authors will not forget setting overtime to something small after testing.

Triggering the nuke at exactly 5 seconds left makes for a longer time limit than the soft limit. Late-spawned lixes have extra time before they become exploders. Some existing levels must therefore be revised to fit the shorter time limit.

I have implemented this for the upcoming release.

Simultaneously, I have addressed another wish: Singleplayer should start quicker.

In previous versions, the nan-nan sound played at 1 second into the game, the hatch opened at 2 seconds, and the first spawn was at 4 seconds. Now, the first spawn is at 2 seconds -- unless it's a tutorial level or a multiplayer game. The sounds and hatch animations are shifted accordingly, it still looks pretty.

The first spawn is still in physics update #60, with 1 second equalling 15 updates. The game starts at update #30, to be compatible with older replays. Old replays have, upon loading, all replay action from updates [#0, #30] moved to update #31, the earliest possible update to use user input. (If you do something in update #n, it will affect update #(n+1), this has always been like this.)

A singleplayer time limit starts counting with/after update #30 instead of #0 as before. The update count is internal only, and printed in the replay file; it's never shown to the user. Therefore, the timer looks as counting normally down after entering the level. Similarly, the stopwatch on untimed levels counts from the point of entering the level, not from the now arbitrarily numbered update #0.

With the first lix spawning 2 seconds after level start, the game will give 2 seconds more than in previous versions. This offsets the nuke bonus of past versions: Late-spawned lixes could walk and exit after the first spawners had begun exploding at 0 timer. 2 seconds should be enough to keep all existing levels solvable without this nuke bonus.

When the timer runs out in singleplayer, a "no"-sign is displayed on all goals, and there will be no more collision of lixes with goal. If a lix is already exiting while the timer runs out, she will exit normally and count. This is no bonus, because an exploder has always been un-explodered upon becoming exiter.

What are your ideas on this, before it's released? Is 2 seconds of extra time too much?

tl;dr: First spawn at 2 seconds instead of 4, but no extra time after time limit (unlike nuke previously).

-- Simon

[Clam]

I like this change very much . The current 4-second wait is long enough that I try to fast-forward through it, with mixed results.

I'd prefer it if the goal stayed open, to make it easier to work out how many you would save given more time (by optimising your solution for time). What you might do instead is have the timer and lix count turn red (as opposed to the green when you pass the level) to indicate that you can't win any more. (Now that I think of it, you could also do this when you lose too many lix...)

The nuke bonus was always an anomaly and I won't really miss that. The autonuke did add a certain quirky personality to the game though . Multiplayer still has it of course.

2 seconds isn't too much IMHO. Time limits should give more leeway than that compared with the fastest-possible solution.

Of course, whatever change you make in this space is reduced in effect by the abundance of untimed levels


Also: How about that "TIME LIMIT RAGE!" warning when selecting the level in the menu?

[Simon]

Okay, if the timing change is good, then we can make a release.

What to do after time runs out can be amended later. I don't have to treat that as a physics change. Even if I leave the goals open, additional saved lixes can be ignored towards the solution. Both the interactive game and the automated replay checker would report the same number of saved lixes as in my current implementation. It doesn't matter what happens after time runs out to test whether a replay is a solution.

Let's see what others believe how to handle goals after the time limit. We can leave them open and even display the number of pseudo-saved lixes.

Notifying the player about the time limit is also not a physics change. It's simple though.

Currently, the overtime bell sounds upon running out of time in singleplayer. I'd like to change that, to prevent the false association of the sound -- in multiplayer, you must now hurry, in singleplayer, you can stop hurrying.

-- Simon

[Simon]

New implementation today: Lixes will enter the goal even after running out of time, but they are added to a second counter, different from the saved counter. The saved counter is displayed normally, and (saved + saved-too-late) is displayed instead of the 0:00-timer if saved-too-late is nonzero.

When exactly should we stop counting lixes to the normal saved counter? When they start exiting while time is remaining, or when they have finished exiting while time is remaining? Lix has done the former up to now, L1 does the latter.

The saving sound plays at the former moment, but the counter is updated at the latter time. For that, the lix remembers whether there was time left upon starting exiting.

Lix are scored when they start their exiter animation, not when they finish. At that time, they vanish from the count of active lix in the level. Singleplayer end-of-game will still wait until all exiters are done with their animation, as will multiplayer overtime.

-- Simon

[NaOH]

What are your ideas on this, before it's released? Is 2 seconds of extra time too much?

2 seconds isn't too much IMHO. Time limits should give more leeway than that compared with the fastest-possible solution.

If a level doesn't give enough leeway, that's a problem of the level. It's not something that should be retroactively fixed with a physics update.

"Don't Look Back" is an example of a level with a strict time limit but is still a very good puzzle and doesn't require much precision. I'm pretty sure 2 seconds of leeway breaks the puzzle.

Why not adjust the time limit such that the time interval between first spawn and game end is the same as the old interval between first spawn and first lix exploded? Although this is a slightly stricter time limit, as there isn't the advantage of some lix exploding later, the fifo ordering of lix nuking seems like a physics quirk that, while amusing, shouldn't be a priority target for backward-compatibility.

It's always seemed weird to me anyway that two lix can be fundamentally different because just they spawned at different times. I feel like lix should be as fungible as possible.

[Simon]

This is interesting enough to warrant another day of discussion with the other users. What does the public think?

Review of the possibilities: Every level has stored the game version under which it was built. I can check for the versions before the upcoming release and deduct 2 seconds, that will get the time limit in order with the old nuking of the first spawned.

I could also start the timer upon first spawn, possibly with deduction of 4 seconds from the old time limit.

-- Simon

[NaOH]

I could also start the timer upon first spawn, possibly with deduction of 4 seconds from the old time limit.

This option seems the most flexible if you're going to have version-dependent behaviour anyway.

[Simon]

[09:42] <geoo> SimonN: While I'm usually all for backward compatibility, I wouldn't go for version dependent behaviour, it'll just clutter everything up. I think there are few enough timed levels that they can be fixed.
[09:43] <SimonN> hmm, then what would you suggest?
[09:43] <SimonN> start timer at first spawn, or on level start 2 seconds before first spawn?
[09:45] <geoo> on level start
[09:45] <geoo> that's consistent with all other games I think, but I don't really care either way
[09:46] <SimonN> hm
[09:47] <SimonN> I'll post this chat into the thread and let's see what comes
[09:47] <geoo> I also wonder if it'd be cleaner to just still start counting at frame 0, and write a quick script to convert replays, but I mean lix already has a bunch of peculiarities like that I presume
[09:47] <geoo> use Occam's razor in your design decisions
[09:47] <SimonN> I want multiplayer to have the 4-second delay, and tuturial levels have it too
[09:48] <__> lemmingsforums.net: Ideas for Skills [Clam] <http://www.lemmingsforums.net/index.php?topic=2012.msg49135#msg49135>
[09:48] <geoo> I see the point in multiplayer, but for tutorial levels?
[09:48] <geoo> sounds like another dirty hack, and the levels are design in such a way anyway that the lix don't die if you neglect them for the first 20 seconds
[09:49] <SimonN> except the blocker tutorial
[09:49] <SimonN> therefore, the blocker tutorial sucks
[09:49] <geoo> can extend the walking range
[09:49] <geoo> but either way 2 extra seconds will barely make a difference in that regard
[09:49] <SimonN> the lixes die within the first 30 seconds, but you have enough so that it doesn't matter
[09:50] <SimonN> I'm a little sad that I'm using unsigned int for the update counter everywhere
[09:50] <SimonN> the design choice was that a signed 16-bit int will cover only 36 minutes, and some games might take longer >_>
[09:51] <Clam> "I think there are few enough timed levels that they can be fixed." <-- this is what I was thinking, but NaOH interpreted it rather differently
[09:51] <SimonN> a good method would be to start the singleplayer timer/clock at update #0, and load the level with a negative update
[09:52] <SimonN> deducting 4 seconds has another problem: if you edit the level in the editor for something unrelated, it gets the new built date, and therefore no deduction anymore when playing
[09:53] <geoo> yeah, again, sounds very dirty and misleading and defying all good design principles

-- Simon

[ccexplore]

the fifo ordering of lix nuking seems like a physics quirk that, while amusing, shouldn't be a priority target for backward-compatibility.

It's always seemed weird to me anyway that two lix can be fundamentally different because just they spawned at different times. I feel like lix should be as fungible as possible.

Well, at least in the case of nuking, there is no question that in the original game they purposely made the nuke assign the bombers to the lemmings one-by-one rather than all at the same time.  For the same obvious reason as why you wouldn't want to watch a fireworks show where they fire all of them off together at once.

Anyway, as for the point that ordering matters in the game physics, I think that actually tends to be pretty common in computer games, as it is usually more complex to try to program things to be 100% truly fungible.

[ccexplore]

Ok, I confessed to not having read through and think through most of the stuff here as they are totally independent of my original suggestion.  And I've never seen "Don't Look Back" much less played it.  That said, are you saying that "Don't Look Back" has such a ridiculously tight time limit that it actually relies on the lixes not exploding all at once during nuking?!?!?!  How can that be a good thing that we'd want to tolerate?

[Nepster]

"Don't Look Back" (Cunning 15) has three lix and 24 seconds time limit, so this level is easily fixed by changing the time limit. It is a very small level, where the only difficulty lies in fitting the solution into the time limit. So it is probably fine to leave the time limit for this level "ridiculously tight".

The only other Lix levels (that I can think of) that might get new solutions with the additional two seconds, is "No More Heroes" (Hopeless 22) and "Eyesis" (from the ongoing Lix contest).

If we start changing the time limit in all levels, then the majority of timed levels will have weird time limits like 4:58. So I second Clam and am in favour of leaving the levels unchanged (apart from modifying by hand the few ones, where it really matters).
The more important thing would be to keep backwards compatibility for replays. If we stay with the original suggestion to start the level at frame 60, then the only problem (that I see right now) are solutions that change the RR during the first two seconds.

About tutorial levels: Sorry, but I do not see the point of giving additional 2 seconds for the tutorial levels. If anything, then an inexperienced player will wonder, why the lix start coming so soon in normal levels.

[Ramon]

Gotta agree with Nepster/Clam on most of his points here; most levels have a pretty 'straight' time limit, would be really weird to see x:58 in most the levels. I thought the same thing about the tutorial levels.

Personally I still think that the time limit simply shouldn't be changed, and the few levels which really depend on the tight time limit should be adjusted accordingly - they're not many and that should be managable.

[Proxima]

Gotta agree with Nepster/Clam on most of his points here; most levels have a pretty 'straight' time limit, would be really weird to see x:58 in most the levels. I thought the same thing about the tutorial levels.

This makes it sound like you think Nepster and Clam are the same person 

I'm also in agreement with you three, and as regards my own levels, I'm happy for them to have an effective extra two seconds. Geoo's impressive last-second solution to The Hotel in Hell wouldn't be quite so tight, but the intended solution to the level has about 30 seconds to spare anyway.

[Simon]

Hmm, starting from 0:58 feels strange, even if the level browser was saying 1:00.

Replays with actions in the skipped frames will be amended internally. all such action will happen correctly ordered ASAP after start. This change won't be written back to the file.

Alright, more people like unchanged singleplayer time limits counting from level start (at 2 seconds before spawn) than changed/unchanged from first spawn. That agrees with my current implementation.

I will have tutorial levels start at the same time as normal levels. Thus, all singleplayer starts with 2 seconds before spawn, multiplayer at 4 seconds.

Thanks for the discussion -- there's a ton of possible solutions, picking one is hard.

Changelog for the upcoming version 2015-01-25

-- Simon