Lemmix

[EricLang]

I gathered the following lemmingstates for Lemmix. The states 0..127 will be reserved. The states 128..255 will be "free" for addons.

These are the names which will appear in the editor, when editing a "LemmingDefinition".
If anyone has remarks on these names or finds omissions I would be glad to hear.

Code: [Select]

  DefaultLemmingStateMap: array[lsNone..lsTwister] of TIdentMapEntry =
  (
    (Value: lsNone;            Name: 'None'),
    (Value: lsWalker;          Name: 'Walker'),
    (Value: lsJumper;          Name: 'Jumper'),
    (Value: lsDigger;          Name: 'Digger'),
    (Value: lsClimber;         Name: 'Climber'),
    (Value: lsDrowner;         Name: 'Drowner'),
    (Value: lsHoister;         Name: 'Hoister'),
    (Value: lsBuilder;         Name: 'Builder'),
    (Value: lsBasher;          Name: 'Basher'),
    (Value: lsMiner;           Name: 'Miner'),
    (Value: lsFaller;          Name: 'Faller'),
    (Value: lsFloater;         Name: 'Floater'),
    (Value: lsSplatter;        Name: 'Splatter'),
    (Value: lsExiter;          Name: 'Exiter'),
    (Value: lsVaporizer;       Name: 'Vaporizer'),
    (Value: lsBlocker;         Name: 'Blocker'),
    (Value: lsShrugger;        Name: 'Shrugger'),
    (Value: lsOhnoer;          Name: 'Ohnoer'),
    (Value: lsExploder;        Name: 'Exploder'),
    (Value: lsArcher;          Name: 'Archer'),
    (Value: lsAttractor;       Name: 'Attractor'),
    (Value: lsBallooner;       Name: 'Ballooner'),
    (Value: lsBazooker;        Name: 'Bazooker'),
    (Value: lsBomber;          Name: 'Bomber'),
    (Value: lsClubBasher;      Name: 'ClubBasher'),
    (Value: lsDiver;           Name: 'Diver'),
    (Value: lsFencer;          Name: 'Fencer'),
    (Value: lsFiller;          Name: 'Filler'),
    (Value: lsFlameThrower;    Name: 'FlameThrower'),
    (Value: lsGluePourer;      Name: 'GluePourer'),
    (Value: lsHangGlider;      Name: 'HangGlider'),
    (Value: lsHopper;          Name: 'Hopper'),
    (Value: lsIcarusWings;     Name: 'IcarusWings'),
    (Value: lsJetPack;         Name: 'JetPack'),
    (Value: lsGapJumper;       Name: 'GapJumper'),
    (Value: lsKayaker;         Name: 'Kayaker'),
    (Value: lsLaserBlaster;    Name: 'LaserBlaster'),
    (Value: lsMagicCarpet;     Name: 'MagicCarpet'),
    (Value: lsMagnoBoots;      Name: 'MagnoBoots'),
    (Value: lsMortar;          Name: 'Mortar'),
    (Value: lsParachuter;      Name: 'Parachuter'),
    (Value: lsPlanter;         Name: 'Planter'),
    (Value: lsPlatformer;      Name: 'Platformer'),
    (Value: lsPoleVaulter;     Name: 'PoleVaulter'),
    (Value: lsRockClimber;     Name: 'RockClimber'),
    (Value: lsRoller;          Name: 'Roller'),
    (Value: lsRoper;           Name: 'Roper'),
    (Value: lsRunner;          Name: 'Runner'),
    (Value: lsSandPourer;      Name: 'SandPourer'),
    (Value: lsScooper;         Name: 'Scooper'),
    (Value: lsSkimmier;        Name: 'Skimmier'),
    (Value: lsSkater;          Name: 'Skater'),
    (Value: lsSkier;           Name: 'Skier'),
    (Value: lsSlider;          Name: 'Slider'),
    (Value: lsSpearer;         Name: 'Spearer'),
    (Value: lsStacker;         Name: 'Stacker'),
    (Value: lsStomper;         Name: 'Stomper'),
    (Value: lsSuperLem;        Name: 'SuperLem'),
    (Value: lsSurfer;          Name: 'Surfer'),
    (Value: lsSwimmer;         Name: 'Swimmer'),
    (Value: lsThrower;         Name: 'Thrower'),
    (Value: lsTwister;         Name: 'Twister')
  );


[Clam]

I think the "jumper" for lemmings going up a small step could be renamed to "ascender", as in L++/Lix, to avoid confusion with the Jumper skill. There's also Tumbler for lemmings that get knocked away by an explosion or fall too far after jumping, and Crawler for lemmings that get stuck in walls in L2.

Additionally, there are a few extra states associated with the Runner:
- Running lemmings jump (without the use of a skill) when they reach the end of a platform. This is different to the Jumper skill, since they don't jump as far as a regular Jumper.
- Jumpers, Spearers and Throwers (and possibly some other skills as well) are carried out differently by Runners - Jumpers jump further, and Spearers/Throwers take a run-up before throwing. These could be named 'RunningJumper', 'RunningSpearer' and 'RunningThrower'.

[EricLang]

Ok thanks. Sometimes it's difficult to make the distinction between skill and state. I'm not that familiar with L2.
"Ascender" seems a good idea. "Runner" is maybe a state as well as a skill. Like "climbing".

[Simon]

I'm in favor of consistency with L++/Lix of course. Or does L1 call the ascender "jumper" somewhere internally? If not, then it may be worthwhile to indeed call it something not conflicting with any other game. Also note that L2 doesn't have ascenders.

Skill, state... there's actually 3 distinct things to separate: skill in the panel, permanent ability, and current activity. Climber can mean all three. By state, you probably mean what I tend to call ability. There's no commonly used word for either ability or activity, though.

-- Simon

[ccexplore]

I gathered the following lemmingstates for Lemmix. The states 0..127 will be reserved. The states 128..255 will be "free" for addons.

I think you already used close to half of your reserved space.  Is it really necessary to use a single byte for states?  If not maybe you can just a 2-byte value and then you can have up to 32768 reserved states and 32768 free states, which should be plenty enough.

=================

I think it's important to get a little more context into why this is coming into discussion.  Basically Eric is trying to make styles as fully customizable as possible, so part of this involves being able to customize the lemmings animations for the various actions.  And in order to do so, it's necessary to try to identify all the actions (ie. Simon's "current activity") a lemming can be involved in.  The textual name can be used in the style definition, and perhaps also to display on screen.

I think trying to cover all aspects of Lemming 2 actions at this point may be too much to handle, especially since no one (me included) have a definitive understanding of all the numerous actions possible in Lemmings 2.  (Remember that in addition to skills, you also have more types of traps and contraptions in Lemmings 2 as well, as well as additional behavior pointed out like flinging and stunning.)  Since we already have a notion of reserved states, we can just start off with doing the Lemmings 1 behavior we're most familiar with, and then gradually extend it by adding more and more from Lemmings 2 using currently unused reserved states.

It may also be good to allow animation styles defined that don't cover all possible states/actions.  The idea would be that if a level tries to use a particular animation style, and also a skill that is not fully covered by the chosen animation style, the editor will catch this and produce an error saying that the chosen animation style do not have sufficient graphics to handle the skill in question.  That way a user-created animation style (eg. Egyptian or whatever) can be usable without having to include graphics for the many numerous actions a lemmings can do, especially adding in Lemmings 2.

[EricLang]

Still thinking about if I have to bind a lemmingstate to the animation or decouple it....
But there's progress! I have created my first mixed style level.

[EricLang]

Ok the new levelpack file format is ready.
Now it seemed a nice idea to me to add "challenge" packs which refer to a levelpack. The basic idea is to make challenges for an existing level.
The ideas I have in mind now are the simple ones:

- change the number of available skills
- change the time
- change the number of lemmings
- change the number of lemmings to be rescued
- change the frametime of the game

- maybe: not allowing pausing

Any ideas to add?

[Simon]

Modify the initial release rate.
Maybe an upper limit for the rate?
A free-text field to display additional requirements of the challenge author?

You shouldn't deprive the player of a tool like the pause in a singleplayer game. Such no-pause challenges will rely on honesty anyway. If you are going to do something in this direction, warn the player at some point, but let him have the last word.

For precision levels, you can consider giving the player even sharper tools -- assigning during pause, action replay, and savestates. Maybe even interactive editing of recorded solutions, but this would be extremely advanced and difficult to make usable.

-- Simon

[Clam]

There are a few more challenge types, some of which we've done on the challenges board:

- Add a "checkpoint" that one or more lemmings has to pass through on the way to the exit, which forces unorthodox solution methods like ceiling routes
- Limit the number of skill assignments per lemming, or the number of lemmings that can be assigned skills
- Limit skill assignment to lemmings facing left only or right only (unworkable on some levels, but interesting nonetheless)

You shouldn't deprive the player of a tool like the pause in a singleplayer game. Such no-pause challenges will rely on honesty anyway.

I think the idea here is to let players complete challenges in-game without having to send someone a replay to check. It wouldn't be too difficult to enforce the challenge rules by tweaking some mechanics, or (preferably) have the game check that you've met the challenge criteria.

For precision levels, you can consider giving the player even sharper tools -- assigning during pause

To be consistent with DOS, if you're going to allow skill assignment during pause, you need to advance by one frame after a skill assignment (if the game is paused), since the original mechanics don't allow multiple skill assignments in a single frame. Another very useful precision tool is frame advance (press some key to advance the game by a single frame).

[EricLang]

Thanks for the ideas so far.

Release rate can be adjusted of course.
Maximum release rate is a nice idea.
I lke the checkpoint idea! Adding rectangular area's to the challenge is doable.
Disabling pausing is probably not a good idea.
@Clam Spammer: Limiting skill assignments to the way not very difficult to make, but I doubt the value of it.
I think I will stick to the maximum of one skill assignment per frame, but assigning during pausing I will take into consideration.

Btw: I added a random 64 bit number to the levels. I tested it and there can be made several 100.000's of levels without creating duplicates.
I will probably change the levelcode to 10 characters + 2 digits.
With the random number system it is very easy to link a replay file to a level.

I saw this guy on youtube solving 30 mayhem levels within 1 hour, and got the idea of "watching a movie" with Lemmix: take a bunch of replayfiles and replay them with Lemmix including pre- and postview screens to see the results. Not very difficult to make either. Better quality than youtube http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" />

The new levelpackformat is quite easy to understand. It will be possible to add any number of sections and any number of levels.
Included will be some author information of course.

[Simon]

What's the intended use of that random number?

You sound like you want to hash each level, and map replays to levels using the hash value. In that case, you don't want a random number, but a deterministic hash function. This will double as a level verification in replays, since the hash cannot be arbitrary per level, while a random number is.

-- Simon

[EricLang]

It's not a hash function but just a random number. When opening a replay file Lemmix will search the header of each available levelpack to find the correctlevel (in case there are many levelpacks Lemmix could create an in-memory cache).
Also the random number is used for creating a levelcode.

[Simon]

Hmm, why you prefer the random number over a deterministic hash then? The hash does all of this, and even more.

The only pitfall with hashes appears to be if the user changes a level, but wants to preserve the level code. Why do you need level codes in the first place? Older replays should indeed fail due to a hash mismatch in that case.

-- Simon

[EricLang]

I don't see why i should make a hash function. When a level is created a random number is assigned to it.
What added value could a hashcode give? And how would you hash the level?

[Simon]

Additional advantages of hashing:

• Level versioning, people can manually verify they're using the same level.
  
• Automated consistency check that a replay indeed uses the exact level it claims. The system immediately catches different versions of the level, since the hash will change completely. Since the random number could be arbitrarily set for the level, people can circumvent the automated check. This looks like it gives more security, and indeed it does, but that isn't the main point of it. The main point is comfort -- trustable skipping of the hassle that is manual level version verification.
  
• Same hash everywhere for same modification. I can tell people to set builders to 0 and record a replay -- instead of either transferring them my level file for such a trivial modification, or telling them to set builders to 0 and additionally the random number to xyz.
  
• Easy way to associate replays to challenges. A challenge is a patch for a level. The hash of a challenge can then be defined to be the hash of the patched level, even if this modified level is never written to disk.
  

Disadvantages:

• Breaks the possibility of setting the same random number for different versions, thus changing level codes. (need different feature for this if we want this)
  

IMO, we should knowingly get rid of this possibility, due to the above gains in comfort.

If you really want to preserve the possibility to assign the same password to possibly changing versions of a level, then you can let the author make up a password for each level. This has the advantages that they'll be easier to memorize, and they can involve humor. Such things are then independent from single levels and should only go into the pack's meta information.

In addition, I do not believe level passwords are good in the first place. Packs should be freely playable, since the format is human-readable anyway, and players who wish to play the pack linearly can still do so. Offer support to track progress or highscores on the levelpack's levels instead of controlling access to later levels.

Reason I'm so persistent: This design decision seems unnecessary hard to change later. If one does, then one still has to support the older way of mapping replays to levels, or drop support for those replays.

Edit: How to hash a level: Make it a large sequence of bytes, according to any fixed protocol you choose, and then run SHA-1 or SHA-256 on it. Decide what goes into the message (the to-be-hashed sequence) of a challenge-patched level. If you feel like you will be changing the challenge possibilities in the future, consider hashing the challenges separately from the levels (in contrast to benefit point #4 above), or all old replays will assert hash mismatches.

Important is that you don't save the hash of a level into the level file itself (or if you do, don't use it unchecked), since that'll break the purpose. Loading a level from disk/pack takes a bit of time anyway, so computing the hash afresh is not a bottleneck operation at this time. Saving the hash into a level is just a matter against bit corruption on loading a level (so one has a hash to check the level against, similar as a replay specifies a level hash to verify that it fits).

-- Simon