Re: [Enigma-devel] Enigma editor, again

[Petr Machata]

Karen Pouelle wrote:
> I have been creating levels in XML by hand.
> As I noted before, the data-centric concept need not
> limit the type of expressions of that data. For example,
>
>   <floors>
>     <fill kind="fl-concrete"/>
> ...
>
> The "fl-" prefix is required, which seems inconsistant with
> the rest of the tags which know by context which object
> prefix to assume.
>
> In LUA, fill can specifiy a rectangular range,
>
> fill_floor("fl-concrete", 6, 3, 2, 3)
>
> but not in XML.
> This sort of thing can only currently be done with multiple
> row tags:
> <row y="3">-6 concrete 1</row>
> <row y="4">-6 concrete 1</row>
> <row y="5">-6 concrete 1</row>
>
> But as you see, it's much more verbose.  Additionally, row
> doesn't take an x parameter (does it?)  Wouldn't it be nice
> to create tagged sections which have an x offset?

Xml format, if I understand it correctly, was created as simple for
machines to process, as possible. For this reason, there are no high
level constructs, such as logical objects, fill areas, etc. Machines
don't need them. Actually machines don't /want/ them, as using them
programatically is more difficult than simply dumping atom-per-atom to
level file. Main reason is that editors prepare data for game, and in
game you need atoms, not abstractions. And editors make the mistake of
mimicking that.

> And what about a tag for when one is trying to make
> checkerboard patterns exclusively in XML format
> with only row tags?
>
> What would be nice is to create objects - data objects.
> They are still data-centric, just more complex.
> For example, the same rectangle could be an
> object that's easily translatable:
>
> <object name="start block" x="6" y="3">
>   <row>concrete 1</row>
>   <row>concrete 1</row>
>   <row>concrete 1</row>
> </object>
>
> Or even better:
>
> <object name="start block" x="6" y="3" width="2" height="3">
>   <fill kind="concrete" />
> </object>
>
> Now that these are objects, they can be manipulated
> by the editor more easily as a group.  Also, they can
> be translated by just changing the object's parameters.
>
> An editor would be useful to me if it could manipulate
> this data format to do simple translations to selected
> objects and areas, such as slide, flip horizontal/vertical,
> and turn counter-clockwise/clockwise/twice
> (for 180 degree turn).  Currently, I text-tag the XML
> sections I wish to translate and run it through a script
> to do such translations - or just edit the row entries by hand.
>
> And what about tiling with an object?
> <fill object="start block" x="0" y="0" width="77" height="13" />
>
> The last four parameters could be optional.
> If either width or height parameters are missing, then
> the level width or height (respectively) is assumed
> (from tag <level width="77" height="13">).
>
> If x or y were missing, then of course 0 would be assumed
> respectively.
>
> Believe me, a graphical editor would be nice, but it must
> be able to do useful things that would normally take me
> longer to do by hand - otherwise I'll still be using the text
> editor.

And that's the point. What you talk about -- if I understand it correcly
-- is VERY similar to my intention. Most of what I'm talking about is
just a representation. Nothing more. The editor would simply make it
simple to edit the representation for anyone, not just überhackers that
can cite xml standard in half-sleep. You want handcrafted levels? Most
probably translation from that high level format to pure lua or xml will
be ready sooner than sexy and usable GUI. Most orthogonal way of
translating levels is of course xslt, but hey... we have some ordinary
users out there...

I had a mail from Daniel recently. His basic point was that I'm doing a
meta level editor, rather than level editor, and that this can turn out
to be very difficult. But I strongly believe that we need rich editor. Why?

1) We need an editor. As a matter of fact, all serious games come with
editor, external or internal. Current external editors aren't better
that hand hacking lua and xml, and forcing enigma people to hack lua and
xml isn't the way we want to go. There are clever people out there, who
could contribude levels of unseen quality, if only there was comfortable
way to build them. (And contribute, but that's another issue. Anyone
volunteers to implement zip levelpacks?)

2) We want internal editor. There was a ton of work put into enigma
display, behavior, cross-platformity and performance. The people behind
those other editors are reinventing it from scratch. Keeping in sync
with those editors would be a pain, if only someone wanted to keep that
sync at all. And if it was possible -- only one of the editors is open
source.

3) Most importantly: we want to make editing simple. You are quite
right: hacking text is still the fastest way to edit levels. If you want
to move door, your adjust two coordinates, and all state stays intact.
But look: in editor, you could just drag the door and drop it somewhere
else. If you dragged the turnstile, its arms would simply follow. If the
pool of water turns out to be too big, just grab the edge and shrink it.
That's what I have in mind when I say "rich editor".

Most work in level, in my opinion, is tweaking. Yes, there is base idea,
core puzzle or something. It won't work without one. But then you have
to really build the level, which inevitably includes a lot of tweaking,
trial and error, etc. XML allows it. But editor has to *support* it.

> I hope those ideas are useful. I think others would appreciate
> a data-centric, yet robust format also.

Thanks for your response, it was an inspiring read.

> Karen

PM

signature.asc
Description: OpenPGP digital signature