Lemmini - Lemmings for Java - public Alpha

[0xdeadbeef]

Nightly update - let's see what I've broken this time :-?

Unfortunately, there appears to be some embarassing breaks, especially with the first two:
53) The sound of exiting lemmings is incorrect--in version 0.6 it's now the same sound as the trapdoor opening. ;D
[edit: it seems that there are many other screwed up sound effects as well. &#A0;For example, in Taxing 2 the bear trap has the sound effect of drowning, in Taxing 4 the rope trap has the sound effect of exiting, in Wild 15 the muddy water has the sound of something decidedly non-water, etc.]

54) Also, I'm not seeing trap animations anymore when they kill a lemming. &#A0;Although in one case, namely Havoc 10, when the leftmost trap is killing a lemming the animation is shown on the rightmost trap. &#A0;This is a serious problem because levels like Havoc 10 and Taxing 6 needs the ability of lemmings passing through a trap unharmed while the trap is operating (trap animation being played).

55) The title change in Fun 25 caused the same issue as when you changed Fun 9: &#A0;on the level's title screen the "Level 25: ....." is placed too far left with parts of "Level" cut off.

Hm, interesting. I have no idea how I possibly could have messed the sound effects in 0.60 as I didn't change a single line there. And the jumper was appended to the end resource wise...
Sure this didn't happen in 0.59? Anyway, I will have a look at it when I come home from work.

[Proxima]

I don't think there's anything wrong with configurable lemmings, especcially because it is a remake. It's just a some checkbox for highly advanced users: "Apply Steel Explosions Native Bug To Stay Compatible".

Obvious problem: that would cause havoc with user-created levels. Either you'd have to always check that your level was compatible with every setting (I say every, not both, because I guess there are other bugs that could also be turned on or off), or else the player would have an unfair disadvantage if he was playing a level with the wrong settings and didn't realise different ones were meant to be used. If this is meant to be distributed more widely than just this board, that's intolerable.

Oh, and please don't say "just an idea". Sorry, it's a bit of a pet peeve, but I hate that phrase. Explaining why I disagree with your idea -- even complete disagreement as in this case -- is not a personal attack and you don't need to get defensive about it.

[Mindless]

@ccexplore: I have no example of deep tunnels through steel . The "mining" a referred to was the "lack of masking" you described.

I don't think there's anything wrong with configurable lemmings, especcially because it is a remake. It's just a some checkbox for highly advanced users: "Apply Steel Explosions Native Bug To Stay Compatible".
Well it was just an idea.

If the option was implemented, it would be best to leave the option up to the level designer, not the user.

[Proxima]

Well..... better, yes, but not best. There would still be two severe problems: we'd have to decide which option to implement for the standard Lemmings and ONML levels, and whichever we chose would almost certainly be used as standard by level designers (how many levels does this really affect?). Worse, users from outside this board who don't know about all the bug discussion would be thrown by levels using non-standard game rules -- it would be radically unfair.

The best (and in my opinion the only) option is to do as ccexplore suggested, fix the bug as though it had never existed.

[ccexplore]

Hm, interesting. I have no idea how I possibly could have messed the sound effects in 0.60 as I didn't change a single line there. And the jumper was appended to the end resource wise...
Sure this didn't happen in 0.59?

Fairly sure no.  Certainly the exit sound effect was correct in 0.59, or it would've been noticeable right away.

Has anyone else tried 0.60?

[Proxima]

I have, and I get the same as you, the lemmings exiting make the "creak" sound effect.

Incidentally, the best thing about the instant release rate change facility is that now I can play with sound on without fear of crashing! Just so long as I don't nuke.....

[0xdeadbeef]

Fixes/changes 0.60/0.61
#  Fixed stencil after extending it from short to int (again). Partly short access led
   to wrong sounds being played, wrong trap behaviour and so on.
#  Eliminated trailing spaces on Fun 25 ("Lemmings Lemmings everywhere")

And about the explosion mask issue: it would be no problem to make this a level pack configuration like the safe fall distance. But to be honest, I don't like the idea.

[ccexplore]

Secondly, the codes given by Lemmini work for Lemmini. You couldn't expect more.

I just want to add here that because the levelcodes for Amiga Lemmings are calculated and validated algorithmically, in quite a few ports the same algorithms are ported verbatim, so the Amiga levelcodes (and all the possible ones for each level) actually work identically across several other ports including PC/DOS, Mac, and I think the Atari ST and WinLemm.  (And for the ports that uses different levelcodes, it's generally the case that they redesigned the levelcode system altogether, often due to hardware differences like lack of keyboards on gaming consoles.)

Which makes it all the more important to have substantially different levelcodes in Lemmini if they were only to work for Lemmini.

[0xdeadbeef]

Secondly, the codes given by Lemmini work for Lemmini. You couldn't expect more.

I just want to add here that because the levelcodes for Amiga Lemmings are calculated and validated algorithmically, in quite a few ports the same algorithms are ported verbatim, so the Amiga levelcodes (and all the possible ones for each level) actually work identically across several other ports including PC/DOS, Mac, and I think the Atari ST and WinLemm.  (And for the ports that uses different levelcodes, it's generally the case that they redesigned the levelcode system altogether, often due to hardware differences like lack of keyboards on gaming consoles.)

Which makes it all the more important to have substantially different levelcodes in Lemmini if they were only to work for Lemmini.

I must admit I don't see the point. You get a levelcode and if you enter this levelcode, you will get to the according level, though most people wil never use this anyway. As a bonus, the levelcode also works for the Amiga version.
To come up with and type in 200+ levelcodes just because someone might be disappointed if he entered an Amiga levelcode which doesn't work on Lemmini, seems a lot of effort for a little benefit ... especially since the situation is not improved at all: still the Amiga levelcodes wouldn't work.
And again: in a "closed" game which only supports a given set of levels, algorithmic level codes are a fine thing. However lemmini is supposed to be extended by custom level packs which are treated exactly like Lemmings and ONML. IMHO the best way to do this is to have fixed level codes which are part of the levelpack configuration.

[Proxima]

To come up with and type in 200+ levelcodes just because someone might be disappointed if he entered an Amiga levelcode which doesn't work on Lemmini, seems a lot of effort for a little benefit ... especially since the situation is not improved at all: still the Amiga levelcodes wouldn't work.

If you thought that would be too much work, I could easily write a program to generate 216 random ten-letter codes. There would be a benefit: the player who wasn't part of this board and hadn't followed this discussion wouldn't expect his Amiga codes to work after seeing that the first couple work perfectly and guessing that the rest will too.

[ccexplore]

I must admit I don't see the point. You get a levelcode and if you enter this levelcode, you will get to the according level, though most people wil never use this anyway. As a bonus, the levelcode also works for the Amiga version.

That's not much of a bonus. &#A0;Lemming has been around for so long, pretty much everyone who played the game already has at least a partial list of levelcodes, and Googling will easily get you to websites with complete lists of levelcodes.

To come up with and type in 200+ levelcodes just because someone might be disappointed if he entered an Amiga levelcode which doesn't work on Lemmini, seems a lot of effort for a little benefit ...

It's rather hard to take your phrase "a lot of effort" seriously given that you're a programmer. &#A0;Writing a program to replace the levelcodes should be a piece of cake compare with writing Lemmini. &#A0;I could probably do this myself once I figure out where you store the passwords.

especially since the situation is not improved at all: still the Amiga levelcodes wouldn't work.

I actually see this as an improvement. &#A0;You see, you're looking at this going in the wrong direction, the direction of getting levelcodes from Lemmini and possibly using them on the Amiga. &#A0;Given what I said earlier, this is an unlikely scenario.

On the other hand, since the Amiga/PC/Mac etc. versions of the game has been around long before Lemmini, for the end user, they are far, far more likely to try the opposite: &#A0;using the list of levelcodes they gained from the original games, noting that they work across multiple ports, and using them on Lemmini. &#A0;In fact, that's pretty much the first thing I tried after you implemented the levelcodes in Lemmini. &#A0;I wanted to go to a particular level without having to turn on 0xdeadbeef, lest there be bugs that only manifest themselves with 0xdeadbeef on/off. &#A0;And of course, the levelcode I have for that one level (Mayhem 5) didn't work in Lemmini. &#A0;It didn't help that after playing Fun 1, I got a levelcode for Fun 2 that not only looks very much like (but different from) the one I have, but in fact the Lemmini levelcode worked also in the original game.

Because multiple levelcodes are valid per level, one person's list of levelcodes will differ from another person's, including the one Lemmini uses. &#A0;So the end user will discover that some of their levelcodes work on Lemmini while others don't, a clearly confusing situation, especially since not everyone realize that the original games can give different levelcodes for the same level.

In the absence of having every such levelcode work on Lemmini, the other alternative would be for none of the Amiga levelcodes to work in Lemmini. &#A0;That way it is at least clear to the end user that they should not even bother trying to use the levelcodes they collected from the original game on Lemmini. &#A0;This would in turn lead them to do what you have in mind, to play the Lemmini levels in order to get the working levelcodes.

To make it even more clear to the end user of the difference, the Lemmini levelcodes can, for example, be of different lengths compared to the original game.

And again: in a "closed" game which only supports a given set of levels, algorithmic level codes are a fine thing. &#A0;However lemmini is supposed to be extended by custom level packs which are treated exactly like Lemmings and ONML. IMHO the best way to do this is to have fixed level codes which are part of the levelpack configuration.

I agree that for custom levels it's probably best for the level designer to decide the passwords. &#A0;However I should note that the algorithmic method is actually still applicable to custom levelpaks. &#A0;The algorithm used by the original games uses several inputs to generate a password. &#A0;One input is a constant string in the game executable; think of it as a sort of "seed" for the levelcode generator. &#A0;Indeed, the seed string is different for Lemmings and ONML. &#A0;They have to in fact, or you'll end up with basically the same set of passwords for both games.

From there, you can see how the algorithm method can apply for custom levelpaks, by having the level designer specify the seed string from which the passwords are generated. &#A0;Or, the level editor can calculate the seed string itself based on some hashing of data from the levelpak.

I don't see this method as particularly compelling myself either. &#A0;The point is simply that it is possible to extend the algorithmic system to custom levelpaks.

And besides, there's no reason why Lemmini can't support both. &#A0;Levels can either contain a stored password or no stored password, and when there is no stored password the program generates one via the algorithm. &#A0;With that system, the original levels will have no stored passwords, while user-created custom levels will always have stored passwords.

[Mindless]

I really don't see the big deal about the level codes anyway.  You'd have to use a some type of hash to avoid having multiple levels in different level sets having the same password.  And if the password is hard-coded into the level files, what will happen if two designers choose the same password?

Edit: I can ccexplore's point about having seeded passwords, but IMHO it's a lot of work that won't be extremely useful.  Perhaps when the game is nearly finished this could be added, but it doesn't seem important right now.

Edit, again: If the player is really that desperate to get to the level that he was on, he can hack the player file.  

[ccexplore]

I really don't see the big deal about the level codes anyway. &#A0;You'd have to use a some type of hash to avoid having multiple levels in different level sets having the same password. &#A0;And if the password is hard-coded into the level files, what will happen if two designers choose the same password?

Personally I can live with Lemmini having no levelcodes at all, especially since currently it is about as good as having no levelcodes--I have no clue which ones in my list would work in Lemmini.

But then when it comes to playing custom levels, there will be cases where the player wants to skip over a level they are stumped on (though, there are ways to support this without levelcodes or cheat modes).

As for avoiding levelcode collisions, that's a generic problem independent of whether the levelcodes are generated or specified. &#A0;Both can result in collisions. &#A0;So Lemmini will probably need to support some notion of "the current levelpak", and apply the given levelcode to the current levelpak only. &#A0;[edit:  or,  extend the levelcode entry UI to allow specifying which levelpak]  Anyway, that's something else for 0xdeadbeef to think about.

[ccexplore]

While we're on the subject of levelcodes and such, and of custom levelpaks, I want to throw in the following obvious observation:

When it comes to custom levelpaks, such as the numerous ones being discussed in the thread "CustLemm level list game", it's obvious that most people don't really try to solve the levels strictly sequentially. &#A0;At some point they inevitably ends up skipping a level or more, for various reasons.

Unlike later Lemmings game such as the Tribes, levels in Lemmings/ONML are independent of each other. &#A0;The ordering generally attempts to form some sort of a difficulty curve (often not a particularly successful one--just count the debates about level ordering in the original games alone...). &#A0;And since the original game introduced the concept of repeating a level later as a more difficult version, ordering is also needed there. &#A0;Other than that, there isn't much compelling reason for the level ordering, much less enforcing them on the player.

With that in mind, I propose that a more flexible system be in place in Lemmini. &#A0;At a minimum, it should support the case of a levelpak where the player can go to any level in the pak they want (like in Cheapo, and in CustLemm using levelcodes), and support the current system where, in lieu of obtaining the levelcodes via other means, you have to solve the levels in a levelpak/rating sequentially.

To introduce more flexibility, levelpaks can specify "unlock conditions". &#A0;A simple but useful form of an unlock condition could be something like:

levels A thru B is unlocked when levels C thru D are solved, or when levelcode Y is entered.

Then you can have things like, "you can solve the first 10 levels in any order, but you must solve them all before having the levelcode (and access) to the next 10 levels".

No doubt this is more complex, but if we are serious about supporting custom levelpaks, I think having this flexibility is better than the extreme of complete sequentiality or total open access.

[ccexplore]

Shifting the topic of the day, let me say that the jumper animation in Lemmini right now is not as bad as I imagined.  It looks reasonably okay when there's just a single step to jump up to.  Where it looks a little silly is when there's a steep slope (in effect, multiple consecutive tall steps).  The jumper graphics right now makes it looks like the lemming is flying up the slope. ;D

The main issue is I think because the lemming is leaning too much forward in the jumper graphics.  In the jumper graphics of the original games there is pretty much no leaning, the lemming is practically standing straight.

The important thing is, gone is the sudden jump from the bottom to the top of the step.  The main thing about jumper, and the reason why they bothered to implement it in the original games, is that it makes the lemming's walking speed look more constant even when walking up steep slopes and such.