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
_______________________________________________ Enigma-devel mailing list Enigma-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/enigma-devel
