Lemmini - Lemmings for Java - public Alpha

[Proxima]

Well, I'll have to take your word for it..... that's disappointing. I really thought I had something there....

The "floater method" really only works I think because:

1) the way you used it on the levels you mentioned, the lemming you assigned floater to comes out late enough
2) the area where the crowd is milling about is large enough
3) you assign the next skill to the floater soon enough (so that there aren't that many, if any, lemmings following or otherwise being too close to the floater).

OH! When I read this bit I was thinking "wtf, the floater isn't any more likely to be a lemming that comes out late", but of course that's not true, because when you select the floater priority will be given to a lemming that comes out late. (Which I think might mean that the opposite of your second is true -- it works best when the area the crowd are confined to is as small as possible. But it's hard to calculate exactly.)

So the method does work but not with certainty as I originally thought. Still worth knowing, I think (or hope). Thank you!

[ccexplore]

OH! When I read this bit I was thinking "wtf, the floater isn't any more likely to be a lemming that comes out late", but of course that's not true, because when you select the floater priority will be given to a lemming that comes out late.

That's right.

(Which I think might mean that the opposite of your second is true -- it works best when the area the crowd are confined to is as small as possible. But it's hard to calculate exactly.)

It's been a while since I remembered your method.  I was thinking you assigned the floater at the moment it appears out of the entrance, rather than after it already fell into the crowd.  In your case it would indeed be better that the crowd is confined to a small area instead.

If you do assign the floater before it merges into the crowd and the floater you assign and start tracking right at that point, then it should make sense that, by either making the floater be as late as possible, and/or by making the crowd area larger (so the floater is less likely to run into a later lemming, with the extreme case where if the area is large enough so that the crowd density is very low, you can more or less tracked the lemming by direct visual without using the floater), you get more accurate tracking.

----------

I also want to add that after some thought, perhaps Lemmini doesn't have to be 100% compatible with the way skill assignments are handled in DOS Lemmings, which, now that I've written it down, does have some "unusual" corner cases.  Especially since in usual play you mostly run into simple cases (mostly those involving just one lemming being under the cursor), so the way it works now in Lemmini is "almost good enough" most of the time.  One could even consider expanding the selection method to support Cheapo extensions like selecting only certain facing directions and true tracking of a single lemming.

[Proxima]

I also want to add that after some thought, perhaps Lemmini doesn't have to be 100% compatible with the way skill assignments are handled in DOS Lemmings

Probably not, but any discrepancies that actually make the level harder to solve should definitely be got rid of. Like the bug I noticed to begin with and still don't know if it's fixed or not, that if you had two lemmings under the cursor, one a builder, sometimes it would look at that lemming and think "already a builder so can't assign builder skill" and not even consider the other.

I was thinking you assigned the floater at the moment it appears out of the entrance, rather than after it already fell into the crowd.

Because I didn't know what I know now about skill selection mechanics!    In fact, I think I can use this to provide a method that really does give certainty:

(1) Make last lemming a floater as it leaves entrance
(2) Hold cursor just touching edge of crowd confinement area and wait for floater to appear
(3) Calculate when floater will be in the centre facing the right direction

Similar to what you were saying, but you see that it doesn't depend on "tracking" the lemming from the time it leaves the entrance to when you're ready to release the crowd.

[0xdeadbeef]

Damn, ccexplore's vacation is already over  :-/  ;D

[Jazzem]

Better start sleeping in the office!

[Proxima]

Damn, ccexplore's vacation is already over &#A0;:-/ &#A0;;D

Whether that's a good or a bad thing depends on which he has more time for -- finding more faults with Lemmini or getting back to work on my MIDIs!  

[ccexplore]

Whether that's a good or a bad thing depends on which he has more time for -- finding more faults with Lemmini or getting back to work on my MIDIs! &#A0;

Hmm, and I was thinking getting bugs fixed is a good thing for Lemmini...... &#A0;:

Anyhow, some of you might have noticed that I have finished verifying and crossing out almost all of the bugs on my old buglists, so things have definitely improved in Lemmini, and no doubt this means the buglist will expand more slowly than when it was before my vacation.

And now [ominous music begins... ], bugs for version 0.59:

43) The password system needs to be rewritten. &#A0;In the real game (Amiga, PC, Mac version at least; probably also true about WinLemm), the passwords are actually calculated algorithmically, based on how you did on the preceding level. &#A0;(See also this thread.) &#A0;One unfortunate result is that there can be multiple valid passwords for any given level. &#A0;Whereas it appears that Lemmini uses a fixed password list, with exactly one valid password per level.<snip>  (discussed...)

44) There's something wrong with being able to switch players while you are playing a level. &#A0;For example, say I completed Fun 1-2 on Player 1, and then at the title screen or actual level of Fun 3, I use the menu to switch to Player 2. &#A0;The completion of Fun 3 would then cause Player 2 to be updated as having access to Fun 4, and Player 1 is not updated as such.

It seems to me that the logical solution would be to go back to the game's title screen whenever you switch players, so one player cannot "steal" the progress of another as described above.

45) On a similar note, right now player progress appears to be saved for only the current player, and only when the game is exited, whereas I'd think it should either be saved at every level completion (the ideal solution, in case the game crashes at some point), or at least also be saved during a player switch.  Fixing. [smiley=mikecool.gif]

46) Fun 25's title is incorrect (it used its repeat's title). &#A0;The correct title is "Lemmings Lemmings everywhere". &#A0;I've also checked every Lemmings levels' titles, and this is the only incorrect title found.  Fixed! [smiley=thumbsup.gif]

47) Strange behavior with blockers turning builders: &#A0;pick a level, say, Taxing 1. &#A0;Have the first lemming out build immediately upon landing. &#A0;Then have the second lemming out be a blocker immediately upon landing. &#A0;Even though the second lemming out would be slightly to the left of the first, and the first is building to the right, nevertheless the first lemming immediately turns around and builds left.  Fixed! [smiley=thumbsup.gif]

48) Steel/one-way-wall detection for miner needs to be revised. &#A0;For example, see this screenshot from Fun 23:



This is the last stroke before the miner is finally stopped by the steel. &#A0;I would think he should be stopped a little sooner, certainly before half his body has already sunken into the steel.

49) In Fun 9, do nothing and wait until the crowd starts approaching the grinder on the left, and more than 1 lemming has been killed. &#A0;Move the cursor to be as left as possible while still highlighting lemmings (basically, highlight the lemmings that are being killed). &#A0;You will find that the lemming type text will often read " 4" or the like (ie. a blank followed by a number).  Fixed! [smiley=thumbsup.gif]

(cont'd)

[ccexplore]

50) This has already been pointed out, but I kinda like to see it fixed so I'm repeating it here: &#A0;the jumper. &#A0;I know there is currently no graphics yet for the jumper. &#A0;So for now, just pick one of the animation frames for the walker to stand in for the jumper, or perhaps just continue on with the walker animation during jumping. &#A0;The important thing is that on a step of 3-6 lo-res pixels tall, the lemming (at least in Amiga/PC/Mac etc. Lemmings) does not instantaneously jump to the top of the step, instead it moves up vertically by up to 2 lo-res pixels per lo-res frame until it reaches the top of the step. &#A0;Note also that jumpers are not eligible for skill assignment, so you can't for example have it start bashing before it finishes jumping.  Fixed! [smiley=thumbsup.gif]

51) I know a while ago, for compatability's sake, you decided to make exploders behave like the real game, where all terrain is taken out when the bomber is standing on steel, and no terrain is taken out when the bomber is not standing on steel.

However, since Lemmini is still masking out steel and one-way-walls when bashing and mining (unlike the original game), I think Lemmini might as well break compatability for exploders also. &#A0;That is, go back to the masking approach rather than testing where the bombing is standing.  Done. [smiley=thumbsup.gif]

52) Lemmings can walk thru walls that are only 1 hi-res pixel thick. &#A0;You can get this to happen on Fun 20. &#A0;After building to the platform with the poles, send a climber up to the first pole. &#A0;Then have it build one brick while on the top and then dig down. &#A0;If done right, you can have the digger leave undisturbed the leftmost column of hi-res pixels of the pole. &#A0;Have the digger dig all the way down the pole and then stop digging. &#A0;You've now created a wall only 1 hi-res pixel thick, and lemmings can walk through it.

Since this is clearly a hi-res only issue, I need to install WinLemm to test out what happens there. &#A0;I suppose if WinLemm exhibits the same behavior, I think I can live with it, weird as it obviously is.

[EricLang]

About the passwords. There are indeed many valid passwords for a level. Maybe it would help if a we collect a list of valid passwords for a level and try a little "reverse engineering". Try to see what's the same about these strings...

[Proxima]

49) In Fun 9, do nothing and wait until the crowd starts approaching the grinder on the left, and more than 1 lemming has been killed.  Move the cursor to be as left as possible while still highlighting lemmings (basically, highlight the lemmings that are being killed).  You will find that the lemming type text will often read " 4" or the like (ie. a blank followed by a number).

I think that's because there is no name yet for a lemming that's being killed in the manner shown in Fun 9.  I don't know of a standard name myself.  You can also choose not display anything for this case, since after all, right now you would get " " without even the number anyway, if only 1 lemming has been killed.[/color]

I think the logical solution would be to follow Cheapo -- the lemming being killed isn't actually a lemming any more, it's part of the trap animation. So cursor should say "WALKER 1" if there's one other lemming under the cursor and be blank if he's the only lemming under it.

[ccexplore]

About the passwords. There are indeed many valid passwords for a level. Maybe it would help if a we collect a list of valid passwords for a level and try a little "reverse engineering". Try to see what's the same about these strings...

That's a good idea but there's no need.  The lengen.zip I mentioned above already contains the information for encoding a password.  So it's mainly just a matter of understanding the encoding process in order to come up with the inverse, the decoding process.  Understanding the encoding process is also useful if we make Lemmini imitate the real game better when giving out passwords, by giving out a generated password (like the real game does) rather than a password stored in a list.

Also, some people did make an effort to try to reverse engineer it by looking at the codes only; see this thread I mentioned earlier.

[ccexplore]

I think the logical solution would be to follow Cheapo -- the lemming being killed isn't actually a lemming any more, it's part of the trap animation. So cursor should say "WALKER 1" if there's one other lemming under the cursor and be blank if he's the only lemming under it.

Is that how things works in Cheapo? &#A0;Remember that the trap in Fun 9 is a so-called "constant trap", meaning it kills lemmings continuously no matter how many are already in the process of being killed. &#A0;This is why you could even get multiple killed lemmings in the same position in the first place, which is the cause of the "<blank><number>".  This is in contrast to the type of "non-constant" traps like the squasher trap in Taxing 6 (compression method 1). &#A0;Being a constant trap also means the lemming being killed is not part of the trap animation.

[Proxima]

Is that how things works in Cheapo?

Oh -- you're right that I confused the two types of traps, but I was still at least half right. Turns out that with constant traps, Cheapo doesn't decrease the number of lemmings IN until the death animation is over, but just as I said, as soon as the animation starts the lemming no longer counts when counting how many are under the cursor.

[ccexplore]

Turns out that with constant traps, Cheapo doesn't decrease the number of lemmings IN until the death animation is over, but just as I said, as soon as the animation starts the lemming no longer counts when counting how many are under the cursor.

That seems reasonable to me, regardless of how it worked in the real games.

[ccexplore]

Regarding the lemmings selection algorithm, here's a revised version that's slightly different from the game, but is IMHO more consistent compared with the real game:

1) Find candidate P, the most recently entered prioritized lemming.

Prioritized lemming can be defined as in the real game, namely one of oh-no-er, blocker, basher, builder, miner, digger, shrugger. &#A0;On the other hand, since you can't assign any skills to an oh-no-er anyway, one might as well take that action off from prioritization.

2) Find candidate N, the most recently entered non-prioritized lemming.

Non-prioritized lemming can simply be defined as the negation of prioritized. &#A0;Or, one can refine it by excluding lemmings that shouldn't be able to receive any skills, such as drowning lemmings etc.

3) Again, make first choice be P (if exists, and not in non-prioritized selection mode) and second choice be N (if exists). &#A0;Remember that non-prioritized selection mode needs to be implemented!

4) Try to assign the skill to first choice, invoking all the necessary tests (ie. lemming not already performing the skill that is being assigned, steel and one-way-walls, etc.).

5) If failed, then try to assign the skill to the second choice, invoking the exact same tests as one would for the first choice. &#A0;(This is where the real game differs, but I consider the difference a bug in the real game.)

------------

As a variation that makes selection slightly easier in special cases:

For candidate N, redefine it as follows:

The most recently entered lemming that is non-prioritized as explained above, plus the additional condition that it is not already performing the currently selected skill, or having that permanent skill (such as "climber") already assigned.

This new definition is intended to deal with the case of, for example, when there are a whole lot of crowded lemmings under the cursor, and you want to be able to assign all of them as climbers, say, without needing to carefully move the cursor so as to not cover lemmings that were already assigned that skill. &#A0;Note again that this variation is not supported in the real game, but as far as I know it doesn't lead to solutions that shouldn't be possible. &#A0;It's just a nicety for skill assignments.