enigma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enigma-devel] New level format


From: Johannes Fortmann
Subject: Re: [Enigma-devel] New level format
Date: Fri, 21 Feb 2003 14:12:09 +0100


Am Freitag, 21.02.03 um 12:34 Uhr schrieb Daniel Heck:

I spent some time yesterday playing with a new level format.  The old,
procedural way of describing levels has done a fairly good job so far,
but it has serious limits:

* You need some programming skills to use it;

* It's unwieldy for describing complicated levels; the many renderLine()
variations remedy that problem to a certain degree, but most of  them
are particularly easy to use either;

* A procedural description is very unsuitable for automatic generation
and  (particularly) interpretation by a level editor.  The description
should essentially be data, with optional Lua code for customization and
special effects.

I had a little discussion with Martin about this a while back.  At his
suggested, I did some experiments with an XML-based level format, but
the results did not convince me.  There is not much nested structure in
Enigma levels, so XML's syntax gets in the way, as does indentation as
soon as you include Lua code; parsing XML would probably have to be done
in C++, which is at best annoying; we would need to include another
third-party library etc.

So back to Lua.  Here's what I came up with last night.  It's still a
little rough in places, but all in all I like the result. It simplifies the current renderLine implementations, it's data-based and easy to read
and write from the editor, you can still include arbitrary Lua code in
the PreCode and PostCode strings, etc.

I'd like your feedback, though, before I start programming and
unwittingly end up with another format that doesn't quite cut it.  So,
what do you think?

Cheers,
Daniel

Hmmm, do I know that format? Attached is "per.oxyd4.lua", a level from my level converter. Personally, I don't like the fact that with this system, you are not able to simply write your level code anymore. So all our levels would have to be changed. Of course, the new levels should be easily parseable: execute the whole file, and look at the environment. What definetely needs to be changed is the length of the grid tokens (i.e. {"+", kind="fl-samba"}); we can only use the standard ascii set without much hassle, and those would be roughly 100 different grid types. Here I propose two-character tokens.

Greetings,
Johannes

Attachment: per.oxyd4.lua
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]