Working on Lemmix again

[EricLang]

A little thought on the triggereffects in the game and the dos limitations.
A solution for a 'perfect' mapping of the trigger effects could be a layered approach:

for each pixel in the gameworld I could use an arbitrary number of 'layers'.
An approach could be:
For each pixel we create 8 layers for the trigger effects. This way we could have 8 overlapping triggerarea's.
When scanning we go through these 8 layers and determine if anything is there to be triggered.
Another approach could be to make the layers unlimited.

[namida]

Wouldn't it be easier to just check for every object, and perhaps create a temporary object for blockers / steel areas? (Well, not so temporary for steel.)

[Simon]

The lookup map in Lix has a two-byte word per pixel, all sorts of effects can overlap there.

If you hash everything in the end, the digest doesn't become longer, it might only be harder to compute. But hashing 1 MB = playing area of 1000 x 500 should still be fast enough.

The lookup map is most efficient during the game when only the type of object matters (water, fire, steam). But even when the particular object must be retrieved back (triggered trap that must run through its animation, goal that is associated to certain player), it's still an improvement over iterating over all objects every frame every lemming.

-- Simon

[EricLang]

I was wondering if I should release pre-versions of "Lemmix XL" to get feedback.
If I do so the first version will include
- a test database with Original Dos Lemmings
- a database explorer (view everything in it)
- a level viewer

Maybe the test database will contain L2 data as well. Working on that....
It is important that different platforms can be supported by the database.

[ccexplore]

Thanks. I would like to have information on Lemmings 2 (Tribes I hope you mean, because 3D is not Lemmings in my view) because they would be nice to import and play (already trying to create a plugin system for alternative mechanics).

I need to set some expectations here:  don't expect me to ever disassemble any L2 game-mechanics code like I did with L1, at least not anytime in the near future.  Going from 8 to 51 skills, plus the general greater complexity of the programming, and my time availability, means that it's just sort of all very impractical.  The best you can hope for is that people can potentially figure out some of the simpler skills/behaviors (classic 8 skills, platformer, stacker, etc.) through white-box observations+level tinkering alone (helped by the ability to frame-step Lemmings 2 in DOSBox as I explained sometime ago somewhere on the forums).  Anything substantially more complex like any wind or projectile skills, or even something like jumper, is probably not going to happen anytime soon other than rolling your own inexact version.

[EricLang]

I am not expecting L2 game mechanics. I am thinking about a plugin-system for alternative mechanics: something like procedures Game.Tick and Lemming.HandleTick and Lemming.ScanWorld during which the complete state of the game, map, lemmings and objects is can be retrieved and modified.
Not yet decided on the system. Tfere are so much options: DLL, delphi package, LUA to name a few. DLL seems the most flexible, although we have to stick with native datatypes then.

But let me first try importing, showing, editing this L2 stuff http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" />

[ccexplore]

Hmm, what's LUA?

Also, can you remind me on how portable or not portable Delphi is across different platforms (eg. Linux)?  I mention it because AFAIK DLL is Windows-only and would therefore probably be undesirable if portability is an important criteria.

[EricLang]

Well, LUA... I don't know anything about it actually http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" /> But I know World of Warcraft has extensions / plugins written in LUA, which work fine.
But it is a script language I believe, which I hate on principal.

Linux has died - I think - inside the Delphi product (called Kylix).
Platform targets in the newest version (Delphi XE5) are Win32, Win64, OSX and Android, I believe.

Another option could be to program the whole thing in FreePascal, which has more target platforms.

BTW: tips about what the most flexible system would be for a plugin are welcome. There is COM too...
When you program something in C / C++ how platform independent is that?

[namida]

I believe with those, it all comes down to what libraries you use.

[ccexplore]

Well, LUA... I don't know anything about it actually http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" /> But I know World of Warcraft has extensions / plugins written in LUA, which work fine.
But it is a script language I believe, which I hate on principal.

Interesting, but considering that much of the web now is built on technologies like Javascript and Flash (which uses ActionScript which is a derivative of JavaScript IIRC), I don't think scripting languages are something to be dismissed outright.

Fortunately in principle, you really only need to support one plugin system written with a general-purpose programming language, because the plugin can itself support the ability to host and run other plugins that are written in other languages.  For example, imagine that your plugin system supports DLLs.  I can then (hypothetically) write a plugin DLL that actually is a LUA interpreter, and can therefore be set up to actually carry out the game mechanics by running LUA script code.  And then a year later maybe I can add support for other scripting languages in my plugin DLL.

Anyway, with that in mind, perhaps it's sufficient to start with supporting DLL and Delphi packages (I'd start with Delphi packages as presumably it would be easiest for you to test the system with, seeing that you are developing the system itself in Delphi).  Or maybe both--no one says the system has to support only one option.

=====

Platform independence is, to be fair, a tricky matter in general.  Scripting languages do tend to be more platform agnostic in general.  Languages that must be compiled to native code are generally not as platform independent, and even when they are at source-code level, you still have the issue that the resulting binaries are always platform-specific.  Java is the only thing I can think of at the moment, that is not an interpreted scripting language, but also does not compile to native code, and is explicitly designed to be platform independent.  It does require the user to separately install the Java runtime for their given platform though.

[ccexplore]

To clarify, while supporting multiple platforms is a nice-to-have, for me personally I had no issues if your Lemmix only works on Windows. http://www.lemmingsforums.com/Smileys/lemmings/winktounge.gif" alt=";P" title="Wink-Tongue" class="smiley" /> Ultimately it's your choices and decisions.

[EricLang]

Packages in Delphi are very convenient, because they can directly use all stuff of the exe or other packages. But the great drawback is that they only work if the package has been compiled with exactly the same Delphi version. With Embarcadero releasing a new version each year packages seem impossible http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" />

[EricLang]

Almost ready with a first Lemmix XL alpha version. I will post a downloadlink here when ready.
Because I have to give a concert next week, there will be some delay. Let's say 2 weeks.
The version will have:
- a lemmings database explorer with which we can view all contents
- a level searcher
- a level editor which will not be able to edit yet http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" />

So the program is mainly a 'viewer' but I need some feedback as early as possible.
Nice feature is that we can edit multiple levels in seperate tabs.

P.S. a 'sticky' Lemmix thread would be nice for this.