This hit the front page of Slashdot yesterday:

http://www.mobile1up.com/lemmings/blog/index-old.php

Impressive effort, but seriously what was he thinking? That by slapping the words "this is a tribute" next to a whole pile of copyrighted and trademarked artwork he gained diplolmatic immunity? And submitting it to the App Store no less, he's either koo-koo crazy or a manic optimist.

Hey guys. Happy new year et al. Anyway, if anyone's interested, please try this.
http://www.pygame.org/projects/21/352/

EDIT: the following instructions are now outdated; visit http://rebui.ld.net.au/software/tundra for up-to-the-second information

Requirements:
Any platform supporting Python 2.4, Pygame, PIL and PyXML (quite a lot)
At least a 1GHz computer machine
Gobs of memory (running Windows alone with <512mb of RAM is productivity suicide)
Graphics card with 32 bit colour (anything less and it becomes cranky and irritable)
A keyboard and pointing device

INSTRUCTIONS:
Run the game. If there isn't a ".tundra" configuration file in your home folder, the first-time setup will begin. Normally you'd need DOS Lemmings and/or DOS Oh No! handy, however to save time (just this once) I've bundled the data with the archive. If you delete the contents of the levels and/or styles folders, you'll be asked to rip them again from DOS Lemmings/Oh No.

After clicking "Game" on the title screen, you can reach the Level Select menu by clicking the "Classic - Fun - Level 1" title at the top of the window. Because this is a "fix the boneheaded mistakes" release, all levels will appear in the menu rather than merely the ones you've unlocked.


FEATURES:
- Preview release: please help me fix boneheaded mistakes!
- Written entirely in Python. So simple a small child could understand it.
- Human-readable layout of storage directories
- Support for level-contained visual themes
- Preliminary support for music playlisting
- Game can display chunky pixels or Scale2x smoothing
- Supports both 640x480 fullscreen, and up to 840x480 windowed widescreeen
- Import support (performs almost as good as it rhymes) for Classic and ONML
- Import support for upgrading DOS Classic to the Amiga extended Classic
- Points system! (Currently unused)
- And SO MUCH MORE!

BUGS:
- Probably several regarding movement mechanics, touching interactive objects etc.
- Bashers are a total shambles. Useable, but inaccurate as buggery.
- ALMOST works on Mac OS X, however there is a weird colourkey bug associated with subtractable terrain on a few levels.
- Options menu was cobbled together in an hour.
- Bomber countdown thingy is poorly positioned and occasionally doesn't disappear

STILL TO COME:
- Subversion!
- Explosions! (removed in this release due to bugs)
- Fast forward!
- Fractions or percentages: the ability to choose.
- Import support for CustLemm sets - probably some very cunning way of sorting around imported levels into game/difficulty categories
- More import support! (e.g. importing the original levelsets from Peter Spada's Copycat)
- .app build for OS X (note that the current source code release is mostly playable if you have Python + the Pygame libraries + PyXML + PIL) 
- Style-specific backgrounds (open to suggestions about what would look good without being distracting)
- Sound effects (still having a think about what the best way to go about this is)
- Method for changing the lemming colour scheme.
- Overhaul of the bitmap text system. Might even cave in for the regular, boring, unshaded TrueType kind.


QUESTIONS:

Q: Why is this neccesary? Lemmini and LemmixPlayer already exist.
A: Short version: They sure do, and you're free to use them instead of Tundra.
Long version: In 1991 terms, we're in the FUTURE! Why not try and build up on DMA Design's classic rather than merely photocopy it? Tundra was written on the basis that there are improvements that can be made without tossing the entire gameplay experience in the bin. After all, if you were looking for an exact replica, what's to stop you firing up UAE or DOSBox

Q: How come Tundra doesn't use Lemmini's level format? Isn't reinventing the wheel bad?
A: True, however Tundra doesn't follow the same design paradigm that Lemmini does. I wouldn't like changing the INI format around to contain extra information, therefore Tundra uses simple XML. Not only does it make the files human readable, it makes complex data insurmountably easier to get at from the code

Q: But... but... it's not compact! It's an abomination of code sprawl! Each level is now a factor of 40 BIGGER than uncompressed in the original game!
A: Lalalalalala not listening not listening lalalalalalala.
(oh come on, it's not too bad when all the level files are compressed)

Q: It won't play out of the box!
A: That's right. You need Lemmings and/or ONML for PC DOS, which Tundra will ask you for so it can nab the resources. You'll be given the option of converting everything to Amiga, which looks better, but some people enjoy a bit of nostalgia.

Q: DOS? Why not Windows? It has better graphics!
A: Windows is missing a whole bunch of levels, and the "better graphics" are sick-eatingly bad. No, no, no.

Q: You've buggered up skill x/The lemming should be y pixels to the left/Level z is unfinishable.
A: Tell me everything. I've only got this far by guesswork, observing DOSBox in slowmotion and the commendable hard work of fellow lemmingspotters. If you're feeling sinister, have a poke around in the src/skills folder for the lemming control scripts. Failing that, let me know where and what I've cocked up.

Q: I can see flickery things through terrain pieces when Scale2x smoothing is turned on!
A: Those would be animations. Pygame doesn't do a very thorough job of blitting graphics over other graphics, and there's a little bit of invisible colour loss. Sadly, the scaling algorithm isn't as good as your eyes, which is why there's a tiny bit of ghosting.

Q: When I bash through arrowed pillars, then build in the gaps, arrows don't appear over my bridge!
A: Due to the unique (read: dodgy) method of how overlayed animations are handled, being forced to fix this problem would make me very very sad. However, don't worry about gameplay; the resulting structures will act just as if the arrows were there.

You thought that picking skills up along the way died with All New World Of Lemmings. WELL IT'S BACK! Along with stylish safety helmets for the climbers (perhaps the Sony Megacorporatrox got too many complaints from parents of impressionable small children), and even a "Doom 3" inspired gameplay mode. Oh, and evidently the mighty spade can now dig through machine parts.

Hi all. I'm working on a clone in Python. As most of the internal data structures, global caches etc. have been written, I'm up to the bit of making the graphics start to work (the gui and the playfield, essentially). However, I'm a bit puzzled as to the correct order of adding terrain pieces onto a freshly-made playing field.

In my current system, I thought I had it nutted so that I only had to blit (simply put, pasting an image onto another) images, and not in reverse - that is, paste an image right behind another. For terrain pieces, this meant going through each piece in order, and either rendering it to a canvas if it was ordinary/black, or adding it to a list if it had the No Overdraw flag set. Afterwards, it reverses this list, renders these pieces in the new order to a second canvas, then blitting the first canvas on top of the second.

And it worked, in a roundabout way. Until I saw what happened with "If only they could fly"



For reference, here's how it should look:


After some thinking, I think the proper method of doing things is "go through pieces in order, if No Overdraw is selected simply blit underneath surface instead of on top".

This might account for really weird situations caused by the subtractive terrain handling, such as how a visible terrain piece can be in front of another visible terrain piece, yet with some layer changing the frontmost piece can be wiped out by a black piece stationed behind the two without affecting or appearing behind the second one.

Is this rendering philosophy correct? Also, is there a neater way of blitting images behind one another than, say, "take sample of the area about to be changed, position terrain piece on an area of the same dimensions, blit the sample area over the terrain piece, clear the changed square on the main image and blit in the new sample".