[SUG] The re-introduction of Timed Bombers

[WillLem]

OK, so I've noticed that quite a few SuperLemmini users like the idea of the return of Timed Bombers to the game.

Personally, I enjoy both; Timed Bombers present a real-time challenge to enhance the puzzles and amplify the chaos; Untimed Bombers of course remove the trial-and-error and are also a satisfying bit of popping good fun so, they both have their merits and ought to be included in the game together, one way or another.

It's therefore worth discussing exactly how this might be done. I can see three possible options:

1) Implementing Timed Bombers as an additional, separate skill, so that both Timed and Instant Bombers would still be available on the panel. They'd each have their own button, with the Timed ones including a clock graphic overlaying the explosion (or similar). As far as I can see, this is the most preferable option since it opens the game up completely, allowing content creators to use both in their levels, and removing the need for them to be mutually exclusive. The only issue I can see with this option is that it would involve adding the extra button and potentially messing up players' existing skill hotkey configurations, particularly if they like the hotkeys to match the panel positions.

2) Implement both as a mutually exclusive player-side option. So, the user themselves could choose whether to always have Timed, or always have Untimed, regardless of the level design. In both the editor and in the in-game panel, Bombers would simply appear as "Bombers", keeping things simple for both creators and players. Whilst this is perhaps the most elegant and seemingly simple option, it does present a very significant problem. Untimed Bombers would necessarily have to be unassignable to each lemming for the first 5 seconds after they spawn, otherwise those who have selected "Timed" bombers would not be able to play any level requiring a lemming to be a Bomber during that time. As well as placing this limitation on level design, imagine an RR99 level with the lemmings dropping straight into a tight pit which needs to be bombed out of: you'd have to make sure you were selecting a lemming that had been in the level for at least 5 seconds from within the bunch... basically, things could get very messy in spite of the supposed simplicity of this option.

3) Implement both as a mutually exclusive creator-side option. So, creators would choose editor-side whether they wanted the Bombers in their level to be Timed or Untimed (the OGs would be Timed, of course). This is by far the simplest way to do it, since the in-game panel would only need the one button, and it once again opens up the design options. However, it means that you could never have both in the same level, and also ignores the preference of the player; since SuperLemmini is already fairly niche, it would be no good if someone avoided playing your levels because you happened to design them using the "other" type of Bomber than the one they'd prefer to use. One potential way around this would be to present the option for the player to either always have Untimed Bombers regardless of level design, or always default to the level author's choice. This would perhaps be a decent middle-ground, presenting Untimed Bombers as essentially an "Easy" mode that can remain a player's default if they so wish.

Thoughts?

[Ron_Stard]

Thank you for showing interest in this feature. I think the third option is the best for preserving the legacy of the original game, but also offers the possibility of designing levels with no timed bombers at all. The check option for the player of having always no timed bombers instead of timed ones (even when the designed level requires timed ones) may put an end to these controversy; to each his own.

Perhaps you could create a poll about this. I'd vote for the third option.

[Simon]

RR99 level with the lemmings dropping straight into a tight pit which needs to be bombed out of: you'd have to make sure you were selecting a lemming that had been in the level for at least 5 seconds from within the bunch... basically, things could get very messy in spite of the supposed simplicity of this option.

The answer to this is better UI: While bomber icon is selected, the cursor should only consider lemmings that are old enough. The cursor already prioritizes lemmings based on different things, this would be a natural extension under your new game rules.

In general, the program should offer the best possible UI for its chosen own physics/philosophy. It's okay to make the physics first and improve the UI later. Existing UI shouldn't be a concern for game design. Complicated future UI that supports pyshics can be a concern, e.g., player confusion, why doesn't the cursor open over this new lemming?

Interesting design problem of (2): What will you write to the replay? You'll want recorded assignments to replay with the same physics, no matter whether the player's option is timed or untimed bomber.

-- Simon

[LanaAndCo]

Ummm... I gotta say that I prefer the third option as well. I think that having it tied to the level's integers is the best to avoid inequalities. Instant bombers are cool but they aren't just making some puzzles easier, they also reduce some to just a walk in the park. I'm with Ron_Stard on this one, we have more or less the same arguments I think.

And doesn't Lix have something like that with its two types of exploders?

[Forestidia86]

Interesting design problem of (2): What will you write to the replay? You'll want recorded assignments to replay with the same physics, no matter whether the player's option is timed or untimed bomber.

I at first thought that the physics update of the explosion should be written into the replay but then again you could then cancel the skill after you've assigned it in the timed bomber's case.

[Proxima]

And doesn't Lix have something like that with its two types of exploders?

It's a little bit similar in that there are two types of exploder and a level can only have one and it's entirely the creator's choice.

But in Lix, both are untimed, and the physics are different enough (different shaped craters, and one type flings nearby lix) that it has to be creator's choice, otherwise you would not be playing the puzzle as it was designed, and it might become impossible or trivial.

[WillLem]

Perhaps you could create a poll about this. I'd vote for the third option.

Thanks for your input, I've added a poll.

The answer to this is better UI: While bomber icon is selected, the cursor should only consider lemmings that are old enough

This is a neat idea, but it could confuse the player if they are unable to assign a Bomber to a lem who has only just spawned, which is one of the reasons why option (2) is my least favourite. You also mention that player confusion could result from the cursor not opening on newly-spawed lems; I'd ideally want to avoid this sort of thing as much as possible.

What will you write to the replay? You'll want recorded assignments to replay with the same physics, no matter whether the player's option is timed or untimed bomber.

Hmm, good question. I suppose that the replay file would have to consider the player's choice, and write the replay accordingly. The simplest way that I can imagine:

In the case of Timed: the replay file waits 5 seconds before recording the assignment of a Bomber. Then, when playing back, the engine shunts the assignment backwards 5 seconds. That way, the .rpl would be compatible with either option.

In the case of Untimed: it remains as-is, with the assignment being recorded at the time & place of the explosion. Again, though, if the same .rpl is played back with Timed bombers selected instead, the engine shunts the assignment back 5 seconds.

I can imagine this being a lot of very tricky code that I currently wouldn't have a clue how to do, but a solution is there somewhere... it's probably in the same ballpark as backwards framestepping.

I at first thought that the physics update of the explosion should be written into the replay but then again you could then cancel the skill after you've assigned it in the timed bomber's case.

Wait, hang on - this is a good idea! What do you mean about cancelling the skill?

Ummm... I gotta say that I prefer the third option as well. I think that having it tied to the level's integers is the best to avoid inequalities

I agree, and option 3 is definitely a close second for me. I prefer option 1 generally because I like the idea of completely opening it up so that both can be used in the same level. But, if option 3 turns out to be the most popular then I'd happily focus on that implementation. I'm really only offering option 2 as lip-service, I think making it player-side is far too complicated, restrictive and UI-messy.

the physics are different enough (different shaped craters, and one type flings nearby lix) that it has to be creator's choice, otherwise you would not be playing the puzzle as it was designed, and it might become impossible or trivial.

If option 3 gets the most votes and we end up going with that, it'll be interesting to see if SL users prefer the idea of allowing the author to specify which type of Bomber is used in a level, and remove the notion of a player-side option entirely. That way, both exist in the game but it's always up to the author which appears in any given level. Given that the SL user-base seems to mostly enjoy Timed Bombers, I can imagine that this might end up being the best and simplest way to go.


A quick reminder: this is all theory at the moment, I absolutely do not have the technical/programming knowledge to actually go ahead with anything at this point, it's just good to have the discussion and see if there's interest. There have been a healthy number of replies, which is encouraging, and I myself would like SL to have Timed Bombers, so... maybe this will provide me with the spur of motivation that I need to persevere with it.

[ericderkovits]

I voted for Option 1, as I would like to have both be availiable in levels. Also not only walkers, jumpers and platformers(wishful of course) as added skills. It would be cool to also have Zombies availiable in levels.

[Crane]

I would go with the third option personally.  Let it be the level or pack creator's choice.  Timed bombers, besides the execution difficulty, have some tactical differences in how it interacts with other skills - for example, the Cloner, since if the lemming has the countdown when cloned, the clone gets the countdown too.

[Forestidia86]

I at first thought that the physics update of the explosion should be written into the replay but then again you could then cancel the skill after you've assigned it in the timed bomber's case.

Wait, hang on - this is a good idea! What do you mean about cancelling the skill?

I thought from a Lix perspective, that you can rewind and replay with cancelling on every phyu. So it would be possible with the timed bombers to cancel them after they have been assigned since the replay entry is for a later phyu. It would maybe be even possible without replaying or rewinding.
One could maybe think of an extra assignment entry that is ignored when replayed with untimed option.

[WillLem]

I voted for Option 1, as I would like to have both be availiable in levels. Also not only walkers, jumpers and platformers(wishful of course) as added skills. It would be cool to also have Zombies availiable in levels.

Whilst Walkers, Jumpers and Platformers could be considered on the basis that they aren't radically different from the classic 8 (and would provide an extra construction skill), Zombies will absolutely not be appearing in any version of SL that I'm working on, for 2 reasons:

1) They're a NeoLemmix thing, and should remain so

2) Code, bugs, code, bugs, code and bugs. Oh, and code. And bugs

I thought from a Lix perspective, that you can rewind and replay with cancelling on every phyu. So it would be possible with the timed bombers to cancel them after they have been assigned since the replay entry is for a later phyu. It would maybe be even possible without replaying or rewinding.
One could maybe think of an extra assignment entry that is ignored when replayed with untimed option.

I still don't understand

If you tie the replay entry with the explosion (rather than the assignment of the bomber itself), then cancelling the bomber assignment will also cancel the explosion... won't it?

[Forestidia86]

I thought from a Lix perspective, that you can rewind and replay with cancelling on every phyu. So it would be possible with the timed bombers to cancel them after they have been assigned since the replay entry is for a later phyu. It would maybe be even possible without replaying or rewinding.
One could maybe think of an extra assignment entry that is ignored when replayed with untimed option.

I still don't understand

If you tie the replay entry with the explosion (rather than the assignment of the bomber itself), then cancelling the bomber assignment will also cancel the explosion... won't it?

The cancelling of the explosion at an unwanted time is the problem. I have how Lix works in mind.
In Lix (the tweaker left aside) every assignment or clicking in the air cancels all assignments that are later than the current phyu.
If you assign the timed bomber the entry is only created for a much later phyu. If you then assign something inbetween the explosion assignment would be cut away. This must somehow be prevented.

example (Lix physics):
(15 phyus=1 sec, 5 sec timer)

You assign the bomber at phyu 100 and then the entry for the assignment (explosion) is at phyu 175. Then you assign a builder at phyu 150. This leads to cutting away all entries after phyu 150 including the explosion assignment. So in this case there is no explosion.

And doesn't Lix have something like that with its two types of exploders?

There is a difference between multiplayer and singleplayer as well next to the difference imploder and exploder. In singleplayer ploders are untimed and in multiplayer they are timed. The replays stick to this then as well though  (singleplayer ones untimed, multiplayer ones timed).

[WillLem]

You assign the bomber at phyu 100 and then the entry for the assignment (explosion) is at phyu 175. Then you assign a builder at phyu 150. This leads to cutting away all entries after phyu 150 including the explosion assignment. So in this case there is no explosion.

Ah, I see what you mean now.

Whilst Lix and NeoLemmix have "Replay Tweaker" features, SuperLemmini does not (and nor will it ever, probably). Since SL is more focused on classic-style gameplay, Replay Tweaking features would somewhat go against this idealogy. I also want to keep the engine as simple as possible (yes, I've thrown the idea of adding new skills into the mix, but in all honesty this most likely won't happen).

So, as far as I can imagine, entering the assignment at the point of explosion should work just fine. That is, in the case of Untimed Bombers the replay handling would be exactly as it is now. For Timed, the engine would account for it by delaying the assignment by 5 seconds. In either case, if the player restarts the level into Replay mode and then cancels the Bomber assignment, the explosion* doesn't happen and so the assignment doesn't get recorded.

*Incidentally, it would probably need to be the 'Oh-noer' state which triggers the assignment, since both Timed and Untimed Bombers feature this state before the explosion occurs.


I'm beginning to lean more towards (3), without having "Always Untimed" as an option. This would mean that there would be no need for extra "replay differentiating" code, with the added bonus that the current level editor (1.43) could still be used in the event that I never get around to making a level editor for SL.

So, the way this could work is that the level author adds a line of text to the level file along the lines of

timedBombers=true

and then the engine selects the correct Bomber type upon loading the level.

Granted, this could also work for option (2) but this is by far my least favourite option, since it means restricting the assignment of Untimed Bombers in the first 5 seconds of every level, as well as messing around with the UI. Besides, if players were so inclined, they could always run a RegEx to change all instances of timedBombers=true to timedBombers=false anyway, thus effectively making this an option for just their experience of the game. Doing so would of course invalidate their replays, but that's on them.

And, option (1) not only involves messing with the UI (i.e. by adding the extra button) but could only practically work with the presence of a dedicated Editor which can be used to assign either type of Bomber to a level. I'm far more inclined at this stage to leave it as the classic 8 skills and as traditional an experience as possible, given that this is the main draw of SuperLemmini for people migrating over from Amiga and Windows Lemmings.

So, expect that option (3) will likely be the way it'll happen (potentially minus the Player-side choice to have Always Untimed, although I'll probably poll this if and when the time comes).

[WillLem]

Brainwave!

Code-wise, I wonder if it's possible to implement Timed Bombers via the Nuke feature (as mentioned by Pooty and Proxima over on Discord).

So, the game knows what "Nuke" is; there may be a way to basically say:

if timedBombers=true {apply Nuke to selected lemming only} else {run normal code for Bombers}

[Simon]

You assign the bomber at phyu 100 and then the entry for the assignment (explosion) is at phyu 175. Then you assign a builder at phyu 150. This leads to cutting away all entries after phyu 150 including the explosion assignment. So in this case there is no explosion.

Ah, I see what you mean now.
Whilst Lix and NeoLemmix have "Replay Tweaker" features, SuperLemmini does not

The problem has nothing to do with replay tweaking or framestepping. The problem arises even if the engine supports only (restart with replay) and (interrupt replay to take over).

So, as far as I can imagine, entering the assignment at the point of explosion should work just fine.

It works when you special-case erasing assignments from the replay:

• Engine decides to record bombers always at oh-no-phyu (because it must record them at some phyu), not necessarily at assign-phyu, and leaves timed/untimed up to the user.
  
• User X chooses option for timed bombers.
  
• During normal play, at phyu 100:
  
  • X assigns bomber.
    
  • Replay receives the bomber assignment for phyu 175.
    
  • Graphics see the assignment in the future and draw countdown.
    
• Then, at phyu 130:
  
  • X clicks into the air.
    
  • Replay doesn't erase the bomber assignment at 175 even though it's in the future, and even though clicking the air erases future assignment.
    
• X restarts level. Replay begins to play.
  
• X lets replay play to phyu 90.
  
  • Were X to click the air here, the replay would erase the bomber assignment at 175, like any future assignment.
    
• X lets the replay play to phyu 120.
  
  • Graphics again see the future bomber assignment and draw countdown.
    
  • X clicks into the air to interrupt the replay.
    
  • Replay erases all future assignments, but special-cases for the bomber assignment at phyu 175, and keeps this bomber assignment despite its future phyu, for the sole reason that X wants timed bombers.
    

There is an equivalent story for (engine decides to record bomber assignments at the phyu where a timed bomber would have to be assigned, and user Y chooses option for untimed bomber). Again, the code would have to special-case when it comes to cutting bomber assignments from the replay, but now it would have to cut extra earlier bomber assignments for Y.

option 2 as lip-service, I think making it player-side is far too complicated, restrictive and UI-messy.

Yeah, you can reject 2) for complexity/player confusion. 2) seems to bring special-casing to several different parts of the program. Interesting design problems, thanks for sparking the discussion.

When you're a beginner with software development, you don't want daunting tasks. The architectural risk here is manageable even: It's possible to fit 2) on top of 1) or 3) in a year. It would merely be nice to see that you had the right picture in mind if you now reject 2).

[WillLem and Forestidia discussing]

This subthread has evolved exactly as I feared yesterday night. :-P WillLem jumps onto some side note (some engine's ability to tweak the replay) and doesn't continue to analyze what part of the underlying problem still applies to SL.

And Forestidia must drill ideas into people's minds even more cleanly, separating any side notes. :-P

-- Simon