[Top][All Lists]

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

Re: [Enigma-devel] Enigma editor, again

From: Karen Pouelle
Subject: Re: [Enigma-devel] Enigma editor, again
Date: Wed, 20 Jul 2005 00:57:37 +0000

On 7/19/05, Petr Machata <address@hidden> wrote:
> I will begin with the most basic stuff possible. You can expect basic
> usage long before work on any highlevel mumbo jumbo even begins.

Throwing down some floor, items, and stones within a user-defined
rectangular section seems to be a good start - the ASCII-based
input that ant.lua accepts is fairly popular for nearly-WYSIWYG
editing - press save, toggle to Enigma and select the level again
from the levels menu to load the changes - is the best available
level editing from what comes directly with an Enigma install.
So anything above that is gravy!

> As for the XML debate... what good will XML bring, anyway? How will
> reading it be simpler than just letting the (LUA) script run and setup
> editor state programatically? (Presumably with functions like
> add_filter, add_shape, etc.)

Any editor would eventually write an Enigma-readable file so the
level can be played.  There's currently two choices. Pure LUA
script (with or without the use of helper functions) and XML with a
LUA tag area for scripted functions and additional details that
the data-centric XML portion can not express.

Why continue with the XML at all?  Well, it's been developed this far
to be functional to the degree that I've been creating levels with it.
I believe there's two XML levels distributed with Enigma at this point.
It has the advantage of being human-readable and machine-parsable;
it's a better-known standard so external editor authors are much more
likely to be familiar with it and have tools available to read and write XML.
It still allows for LUA scripting for everything that can't be expressed in
the more pure XML sections of the file.

Also, I've created a few tools for doing transformations on rows and 
columns of XML-based levels.  I'm certainly willing to throw away
those tools for a graphical editor that can do the same - but that's
part of the  "highlevel mumbo jumbo"  that hasn't begun yet. I'm
willing to set aside a few dozen lines of script to do sectional
transformations when it does happen.  The two XML levels are
simple enough that they can be remade, as well.

This progress in XML and LUA within it need not end - it can
eventually be the output format of an editor or remain parsable
by Enigma.

Intermediately, I don't care at all what format the up-coming editor may
use.  Furthermore, if the editor doesn't save in XML, I can adapt. If XML
development isn't continued in Enigma, I can learn new things, re-write
old things, and perhaps use a graphical editor exclusively to make
Enigma levels.

No consideration should be given to the fact that I'm hand-writing XML
levels - The hand-scripted LUA levels were around long before I knew
of Enigma.  But I doubt they would be loadable into a new editor, however
because XML is fairly strict about its format, the sections I've written in 
XML would be loadable.   For the simple structural content, it seems 
that XML does currently have an advantage - the LUA sections make
the current XML format extensible, and no editor should bother with
the LUA scripted sections in the same way that no editor can read
hand-scripted 100% LUA files.

As for the XML debate... it should probably start by answering the
question, "Why did Daniel move in this direction in the first place?"

Karen  "Pretzel"

reply via email to

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