[SUG] New Lemming type - Rivals!

[WillLem]

SuperLemmix probably won't ever get a 2-Player mode, unfortunately, but I wonder if this might be the next best thing...

We can create a pseudo-2-Player mode by adding a new Lemming type: Rivals.

Rivals will behave exactly like normal Lemmings, but with the important difference that they have their own dedicated Exit. If a normal Lemming reaches a Rival Exit, the save count will be decreased by 1, and vice-versa. So, to meet the save requirement for the level, normal Lemmings must reach a normal Exit, and Rival Lemmings must reach a Rival Exit.

The main purpose of this is to make the OG 2-Player levels a bit more interesting to play on a singleplayer system, but I believe this could also prove to be a very interesting source of new and unique puzzles.

This feature is currently very likely to join the Batter and Propeller skills in 2.8, which won't be out for a while yet - 2.7 took a lot of work to get together so I'm probably going to take a break from SLX development for a bit and concentrate on other things. So, we do have some time to bash through ideas on this one.

[WillLem]

Giving this a bump as it will most likely be the flagship feature of 2.8 and there are a few things that need to be discussed before the feature is fully implemented, which doesn't tend to take long according to my track record so far!

I'm currently thinking that rival lemmings should wear red instead of blue tunics:



"Rival red" is a good alleritative way to remember this particular recolouring scheme, and traditionally red and blue teams tend to be direct rivals (examples: Mario and Sonic, Coke and Pepsi, Manchester United and Manchester City).

The question then becomes: what colour should selected lemmings' tunics be recoloured to? Currently, the defaults are recoloured to red from blue, and we could apply the same in reverse to Rivals, but this would almost certainly become confusing if a group of normal and rival lemmings become bunched together.

Perhaps purple could work, as it's a mix of blue and red. Ideally, this scheme would be applied to both normal and rival lemmings, but then the obvious problem is that it still wouldn't be clear from the recolouring alone whether the currently-selected lem is a rival or a normal. We can prepend the status display in the panel with "R-" (as in the current N- for Neutrals and Z- for Zombies), but that means the player would have to always check this status; ideally, the recolouring alone should be enough.

This is where my preference for shades of the same colour to distinguish between states may come into its own! My proposal, then, is that we adopt the following scheme:

Middle shade: Normal lemming (as it is currently)
Darker shade: Athlete lemming (as it is currently)
Lighter shade: Selected lemming

Then, selected lemmings in each group will always simply be a lighter shade of whatever the default colour is, and athletes will always be a darker shade. I'm currently about 90% sure this is the way to go. Here's how it could look:





Again, user-side mods would remain possible for all states, so if people don't like the defaults they can always change it to something else entirely in their own copy of SLX.

Thoughts on this?

[Proxima]

[Simon]

More state that a lemming carries around. How does it relate to existing such state? Can you be a neutral rival? Or are you exactly one of regular, rival, neutral, etc.? How do neutrals count in the different exits?

Do you have different skillsets per such tribe? Clones had this; it's an elaborate feature, but again with unique level design possibilities. Neutrals would dissolve nicely into this idea, too; neutrals are then yet another such tribe that never gets skills.

Take care with using only color to mark things. Blue athletes are now harder to differentiate from the red athlete.

There is a natural burden on this feature. You must make it pull its weight. It's not enough to play existing 2-player levels; most of those are boring in singleplayer by design. For perspective: Even zombies feel like they're not pulling their weight; their complexity weighs a lot, see our nuke/exiting worries from last month. Neutrals have been more lightweight than zombies.

-- Simon

[WillLem]

All good questions Simon, thanks.

How does it relate to existing such state? Can you be a neutral rival? Or are you exactly one of regular, rival, neutral, etc.?

At present, the plan is to not allow a lemming to be both a Neutral and a Rival. If a designer somehow manages to assign both (for example by using a text editor to input both properties), the Rival state will be preferred.

Rivals will be zombified as normal upon contact with a Zombie, but then at this point their Rival status will essentially be void anyway (and, will likely be removed code-side to prevent bugs).

How do neutrals count in the different exits?

They will count as +1 in either exit, in the same way that Zombies will count as -1 in either exit.

Do you have different skillsets per such tribe?

No, that becomes too complicated. At present, the idea is as simple as each team having its own exit; where skills are concerned, the interest will come from having to divide the skills between the two teams as well as making sure that one team doesn't follow the other as a result of previous skill actions.

Take care with using only color to mark things. Blue athletes are now harder to differentiate from the red athlete.

Athletes will still be marked as such in the skill panel status display. Additionally, Rival Athletes will have "R-" prepended to their status (e.g. "R-ATHLETE"). The recolouring compliments this.

It's not enough to play existing 2-player levels; most of those are boring in singleplayer by design.

I disagree with the first part. It's because the 2-Player levels are boring in singleplayer that the feature is worth pursuing: suddenly, these become much more interesting levels. IMO, that's enough. As a Bonus, we also have another unique design feature that has puzzle potential and which can't be simulated using existing features.

Even zombies feel like they're not pulling their weight; their complexity weighs a lot, see our nuke/exiting worries from last month

Right, but bear in mind that we were working on NeoLemmix which (IMO) hasn't fully fleshed out the potential of Zombies.

A NeoLemmix Zombie:

* Removes the lemming
* Cannot receive skills
* Infects other lemmings
* Can interact with traps
* Retains any permanent skills

A SuperLemmix Zombie does the same, plus:

* Can exit (counts as -1 towards the save requirement if they reach an exit)
* Can interact with buttons
* Walks more slowly
* Eats pickups
* Can be killed by Spears, Grenades and Lasers
* Has a dedicated Talisman (Kill All Zombies)
* Has their own sound scheme (trivial, perhaps, but adds more depth to the feature)

So, I'd also have to disagree that Zombies don't pull their weight. Even in NL, Zombies are a unique feature in that they're a moving (and growing) trap, something that the game didn't have previously. There are some very interesting Zombie levels in NL, despite the feature not being developed as far as it could have been.

The SLX augmentations afford Zombies a much more prominent and textured effect on gameplay. These features have added maybe 100 or so extra lines of code and a small handful of additional assets, so Zombies don't "weigh" too much more in SLX but do have greater gameplay value.

With that said, I recognise the wisdom in what you're saying - the more I work on SLX the more I'm learning that some features just aren't worth the effort that they require and the amount of code they end up touching; this is actually a lesson I learned quite early on, but it's having more of an effect on my decision-making lately.

With that said, Rivals definitely seem worth the effort to me. We do of course need to address the specifics, hence why I'm glad you asked the questions you did. This helps a lot!

[WillLem]

Made significant progress with this. The feature is working a treat so far, including recolouring (which took some doing to get everything to line up, but it seems to be playing along nicely).

A few concerns have arisen, which will need to be addressed before I'm happy to release this feature:

1) How should Rival exits be marked?

This is where those decorative flags might finally come in handy for something. It would be fairly arbitrary to design a different-looking exit (which to all intents and purposes would still just look like... an exit!). There are also cases where a Rival exit would need to behave like a normal exit code-side anyway (more on this later). So, how about this for starters (note that these lems are going to their correct exits!)?



For the default ohno/orig Rival Exits, the red flag can be baked in to the animation. This should prompt designers to manually apply the blue flag for Normals.

There may even be a way to detect the presence of the flags within a certain radius of the exit's trigger area, and enforce this code-side if the level contains Rival lemmings. That does seem a bit drastic, though. Let's hope that designers choose to mark the exits appropriately if they're creating a Rivals level, and give them a nudge in the right direction if they choose not to or genuinely don't realise that they should.

2) What should happen when a level has only Rival lemmings but only Normal Exit(s) (or vice-versa)?

This one should be fairly easy to deal with: if there is only one type of lemming (Normal or Rival), then any exits present behave like regular exits for that lemming type. The way that Rivals code has been implemented so far could easily support this, and it would mean that people could make legit levels featuring only Rival lemmings should they wish to do so, whilst also preventing troll levels/genuine mistakes.

In the absence of any better ideas, that's how I'll probably solve this one.

3) What should happen when a level has a mix of Rival & Normal lemmings but only Normal or Rival Exit(s)?

This one is more difficult. At present, it would be possible to create the following level:

20 Normals + 20 Rivals
Save requirement of >20
0 Cloners in skillset
1 Normal exit

Such a level would be impossible to complete, and this is a scenario which could come up fairly innocently. So, it feels like it should be handled code-side. I can see 3 possible solutions:

Solution A would be to default the save requirement to the amount of Normal lems. That way, the Rival lems could still be used as part of the level's solution, it would just be necessary to divert them away from the exit.

Meanwhile, the more complex Solution B would be to subtract the number of Rivals from the current save requirement, and have the resulting figure be the new save requirement. So, for example, in this scenario...

20 Normals + 20 Rivals
Save requirement of 25
0 Cloners in skillset
1 Normal exit

...the save requirement would become 5. This would essentially completely disregard the presence of Rivals in the level. So, if the solution requires that 15 lems be sacrificed, those lems could be either Rivals or Normals and it would still be possible to meet the save requirement.

Meanwhile, Solution C would be to change the Rival lems to Normals. This would be the cleanest code-side, and would at least allow the level to be loaded and played.

Note that in any of the proposed solutions A, B and C, the same logic would apply vice-versa for (mixed lems + Rival exit).

Finally, Solution D would be to not load the level at all unless there is at least 1 Normal and 1 Rival exit, in the case that there is a mixture of Normal and Rival lemmings. This is probably my preferred solution out of all of them as it bypasses Rivals being used for unintended purposes and keeps the feature clean, but it does mean that the potential puzzle benefits of solutions A and B are discarded.

Thoughts? Could do with some feedback on this as either solution requires a fair amount of commitment to that solution before plowing ahead.

[WillLem]

OK, Rival Exits will be assignable in the same way as pre-placed Lemmings/Hatches; simply check the "Rival" checkbox to designate the property to the selected Exit in the Editor.

As for adding flags/markers, for now let's rely on the existing helper graphics system to show when an Exit has been designated as a Rival Exit; this isn't an ideal long-term solution though, because it doesn't help when in Classic Mode.

I'm going to experiment to see if there's a way to detect the presence of an Exit-marker (e.g. the flag), and automatically add one if it isn't found. If this is too difficult though, then other options will need to be explored. That's for another day though.

Some thoughts on this would also be much appreciated if anyone has time to reply.

[WillLem]

Just giving this a bump. Any suggestions/thoughts/comments will be most welcome, having some problems deciding exactly what to do.

Marking the exits is a tough one as well. Do we (a) require an Exit Marker in order to make the Exit a Rival Exit? (b) automatically place a Marker when an Exit is designated as Rival? or (c) hope that level designers place Markers themselves?

[mobius]

I'd say a rival exit/exits should automatically get marked in some fashion. I say don't count on level designers always doing things right but also people can just forget things.

on the matter of creating incorrect/incomplete stats with and unusual number of entrances/exists; solution A seems best to me. Still using the rivals; having them play a part (hindrance in this case) is interesting.

As I said in the other topic this is all tentative atm. Unfortunately I haven't been able to playtest with SuperLemmix at all lately . I still want to, just finding time is a difficult atm.

[WillLem]

Thanks for the comments, mobius. It's helpful to hear back from others even if it's just a few mostly-on-instinct comments.

I'd say a rival exit/exits should automatically get marked in some fashion. I say don't count on level designers always doing things right but also people can just forget things.

Agreed, this is ideally what should happen.

So far so good: in the Editor, we can add the relevant markers automatically (and even place them over the correct exits) with a single click! Furthermore, the Editor will check the level's theme for custom markers before applying the defaults. If any Exit is changed at any point, the markers are all replaced accordingly - all good.

The only issue is that the custom pieces must be named "exit_marker_normal" and "exit_marker_rival" in order for this to work. This might not seem like such a big deal, but it means that (a) it isn't possible to have more than one of each marker per-style, and (b) if a style does have its own markers, they are placed alongside the existing default ones in the piece selection window rather than replacing them.

Neither of these are necessarily bad things, though: limiting the number of these markers that a style can have might not be the worst idea, and designers may wish to select the default markers even if a style presents custom ones - as it is, it's currently easier to do just that.

Meanwhile, the next step will be for the SLX Player to delete all existing markers and replace them; the idea here is that markers will then only be useful for the level designer whilst in the Editor, and the player whilst in the Player. This is about as much as I can do code-side to make sure that the feature is as clear as possible.

on the matter of creating incorrect/incomplete stats with and unusual number of entrances/exists; solution A seems best to me. Still using the rivals; having them play a part (hindrance in this case) is interesting.

Again, agreed. Solution D, then Solution A, seem best to me personally. Since you're the only person who has replied and you've shown support for A, I'll look at going down that route.

Anyone else?

[Simon]

1) How should Rival exits be marked?

Avoid all possible mismatch, as mobius recommends.

If tribe alignment is a property of the exit: The exit is now responsible for showing tribe alignment, all by itself. E.g., add special cases near the code that draws exits during play.

It's possible to solve this by introducing extra tiles conditionally when the game constructs the level from a level file. But this feels unnatural. If you solve it with extra tiles, don't allow another way of adding these tiles; the only way must then be by setting exits' tribe alignment.

If tribe alignment is a result of overlaying two tiles: The overlapping tile is now responsible for showing alignment.

the idea here is that markers will then only be useful for the level designer whilst in the Editor, and the player whilst in the Player.

Assuming you make tribe alignment a property of the exit (and not a result of overlaying two tiles): Avoid reliance on human-placable marker tiles in the editor. The editor should render the exit as it will appear during play, or show other equivalent information on the exit.

Downside of introducing extra tiles conditionally when you render the map: The editor can't naturally show these tiles and not put them into the level.

At present, the plan is to not allow a lemming to be both a Neutral and a Rival.

Do you have deneutralizers? What happens when you neutralize a rival, then deneutralize him: Will he be regular lemming or rival?

-- Simon

[WillLem]

If tribe alignment is a property of the exit: The exit is now responsible for showing tribe alignment, all by itself.
---
It's possible to solve this by introducing extra tiles conditionally when the game constructs the level from a level file. But this feels unnatural. If you solve it with extra tiles, don't allow another way of adding these tiles; the only way must then be by setting exits' tribe alignment.

This is kind of what I'm aiming for. The Editor auto-draws the tiles when the property is set. It also re-draws them if the property is changed at any time (I still need to make it so that all markers are auto-removed if no Exits are marked as Rival).

Assuming you make tribe alignment a property of the exit (and not a result of overlaying two tiles): Avoid reliance on human-placable marker tiles in the editor. The editor should render the exit as it will appear during play, or show other equivalent information on the exit.

*Ideally, the markers should remain in place, anchored to the Exit, and be non-editable. That way, they appear exactly as they will appear in the Player. This is on the to-do list.

For now, they can be edited and moved around. A band aid would be to simply call the marker-adding method upon saving the level (the method first removes all existing markers), but this obviously isn't ideal.

EDIT: Another possible method would be to add the helper graphics to the Editor and draw these wherever they are relevant, in the same way that placeholders are used for pickup skills in the Editor. This should probably happen anyway, since the Editor currently has no way to visually represent pre-assigned hatches, lemmings, etc. I did take a quick look at this yesterday and found that it would take some doing, but it might ultimately be worth it for more than just the Rivals feature.

Downside of introducing extra tiles conditionally when you render the map: The editor can't naturally show these tiles and not put them into the level.

If I can achieve the above^*, then re-introducing the tiles at map rendering will make them appear exactly as they appear in the Editor: from a user point of view, nothing has changed. We still need to do it simply because the level file can be edited in Notepad; the only way around this would be to somehow bake the animations together in the Editor, which I'm not sure is even possible (and certainly wouldn't be worth the time and effort it would take when we can simply re-draw the markers in the Player, achieving the same result - this is how Secondary Animations are handled).

Do you have deneutralizers? What happens when you neutralize a rival, then deneutralize him: Will he be regular lemming or rival?

This is a good question with no easy answer.

Instinct: they should keep the Rival tag.

Then, I remember that I don't want to have to recolour Rival-Neutrals a different colour to regular Neutrals, so these lemmings become only a source of confusion.

So, I then think that Rivals should simply ignore Neutralizers. This would at least be consistent with code-base behaviour (since Rivals cannot also be Neutral at any other time), but could seem odd to players.

So, I then think that SLX shouldn't feature both Rival lemmings and Neutralizers. The latter is essentially just another trap to be avoided anyway, which makes them mostly uninteresting. De-neutralizers have much more gameplay and puzzle potential, and can play nice with Rival lemmings.

[WillLem]

TL;DR in skyblue bold type.

Markers can be automatically added to Exits in the Editor, and can also be swapped whenever the Normal/Rival status of the Exit is changed. This works very nicely, but ultimately still feels somewhat redundant and unfinished because the Marker pieces need to be non-editable, and the Player will also need to auto-draw them anyway.

I've tried grouping the Exit & Marker as a single piece with no luck. The closest I can get is to automatically select the Marker when the Exit is selected (and vice versa) - nifty, but ultimately doesn't stop the pieces being added manually anyway. It also doesn't work when selecting multiple pieces at once - this would require further tinkering, and it's already fairly messy as it is.

Then, I looked at the possibility of harnessing the way Pickup skill placeholder images are added - it would be great if we could add similar images to Hatches, pre-placed Lems and Exits depending on the object's properties, but this is no easy task. I'm not even sure I 100% understand the way that the Pickup placeholders are added. They seem to be drawn in as the style data is loaded... but then, how can this be if they are later swapped when the skill properties are swapped? (A close look at the skill flag setting methods yields nothing of use)

So, maybe what's needed is a totally new method. The only problem there being that I'm not even 100% sure what it is I'd be trying to do. Draw a helper over the Hatch/Lemming/Exit to show the pre-assigned skill/property - sure. But then what if that object is moved? We still need a way to anchor the graphics to the object, which so far has proven to be very elusive. There is no clear existing logic that can be followed or harnessed for use here, so it's difficult to know where to even start.

I don't want this to inhibit the Rivals feature, so it might be that we'll ultimately have to settle for the checkbox being the only visual feedback in the Editor for Rival Exits (this is currently the case for pre-assigned Hatches and Lemmings, and we've managed so far with that limitation), and the Markers will be automatically added to the level during map rendering in the Player.

Hopefully, I'll figure out how to draw Hatch/Lemming/Exit helpers in the Editor some other time - it will of course come in handy for more than just Rivals, and should really be a standard Editor feature anyway. If anyone has any suggestions as to how this might be done, please feel free to shout. The Editor is written in C#.

[WillLem]

Very happy to report that drawing object helpers in the Editor is coming along very nicely, so it looks like Exit marking will be completely automatic after all.

Here's how it'll work:

The Exit flags will be removed from the default style's "objects" folder and placed instead in the "effects" folder. They will no longer be decorative objects, and instead will mark Exits as Normal (blue) and Rival (red). (We could maybe use the green one for Zombies, but that's for another day! ).

When an Exit has the relevant property, it will be marked using an overlaid icon in the Editor (as shown here but with much better graphics), and a flag in the Player (style creators will be able to customise their own Exit markers by placing a graphic with the same name in the style's "effects" folder - this means that there can only be one marker per-lem-type per-style, which is a good thing!).

All level creators need to do is check the "Rival" checkbox on Hatched, Pre-Placed Lems, and Exits. The Editor and Player will do the rest between them

[WillLem]

OK, Exit markers are becoming quite a difficult thing to implement. I could do with some help.

We need 3 items:

1) The animation image, in .png format
2) X/Y values for drawing the animation relative to the Exit
3) The number of frames in the animation

We also want to only allow one set of markers per level. If we allow more than that, it quickly gets out of hand for obvious reasons. The easiest way to achieve this is to choose the markers based on the level's theme; if the theme's style has custom markers, we use those. If not, we use the defaults.

All simple enough so far, but it's currently necessary to place the above 3 items in 3 different places:

1) The image is stored in styles/(style)/effects, along with the Balloon pop graphic, Grenades graphic, and incidental lemming overlays that aren't sprites (I'm considering moving countdown digits to this folder as well, but that's another story).

2) The X/Y values are stored in the Exit's .nxmo - this is the most sensible place to put them because it means that if a style has multiple Exits, each can have its own set of marker X/Y co-ordinates (whilst still using the same marker animation).

3) The marker frames value is currently stored in theme.nxtm - this isn't the ideal place, but it does the job of making sure that we only use 1 set of marker frames values per-theme (and, therefore, per-level). The only better place I can think of would be storing it in a text file alongside the markers themselves in the "effects" folder, but... well, that then means more bits of paper floating about.

Any ideas/suggestions here would be very welcome at this point. Even if you suggest something that can't be done or that I've already tried, it may help move towards a decision.