enigma-devel
[Top][All Lists]
Advanced

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

[Enigma-devel] Enigma editor, again


From: Petr Machata
Subject: [Enigma-devel] Enigma editor, again
Date: Fri, 15 Jul 2005 05:58:01 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050119 MultiZilla/1.7.0.1j

Hi everyone

Sorry for the lengthy mail, I just can't stop myself once I'm in flow;)
I know people seldom reply to such a prose, but I had to write it all
down so that it at least stays archived. Of course I'd like to hear some
talkback, that's why I'm sending it on the mailing list.

There are currently three alternatives for more-or-less comfortable map
editing: BlackBallEd, that noname editor by H. Eilts, and hand-hacking
files with support of a lua library. The lattest is what I have created
my maps with, and the other two options are rather obscure to me. Having
linux-only box, I tried them under wine emulation, but that's too harsh
an environment to work in. No commandline etc., you know I felt somehow
lonely ;)

Well, why am I bugging you at all: I have certain editor idea, and I'd
like you to drop a few comments, if you have any.


It came to me when I was playing with xml format for enigma levels. It
led me to three interesting concepts of level editing:
 1) Objects.
 2) Filters.
 3) Links.

Objects. The thing is, that in editor, you are drawing *objects*. Not
stones, not items, but rooms, pools, walls. Under such a setting it's
simple to drag-and-drop things without messing unrelevant parts of map.
You can do basic geometry just like in vector drawing program: you can
drag lines, set thickness, insert points, draw curves, circles, squares.
They are just shapes, with no tiles, pure abstract beings. Shape just
defines where there should be atoms drawn, but it says nothing more. It
defines *places*.

[Fresh idea: ownership of objects. If you move the logical place, all
things contained in the place move along. Room contains its items. But:
you don't have to want to use it, there are situations where this
behavior can be a real PITA.]

Filters. It pretty much resembles commandline pipes, but it's two
dimensional, and filters places, not characters. Each filter can do one
of two things: change the set of places; and attach some atom to the place.
With changing the set of places you can do things like making the box
filled/hollow, making the wall perforated, chessboarding, etc. These are
generally not strictly useful things, but the concept might show up
useful. Filtering the things out could be scriptable, so that you could
define the places to be filtered out/included.
Attaching atoms to place will take each unfiltered place, and define
stone, floor, actor(s), and/or item that should be drawn in that place.
This would be scriptable, too.

[Fresh idea: tree of filters, rather than stack. Each filter can define
zero or more sets of output places. Making chessboard under this setting
would be very cool: chessboard filer just divides whole area to two
sets, and you can draw each set independently. But I'm not going to do
it just because it makes chessboard creation orthogonal :) ]

Some things fit very nicely into this concept: for example, beveled
floors. Trivial with script, that just takes set of places, and computes
best bevel approximation. And you know what? If you change underlying
logical information, the thing will recompute all by itself. The same
pays for puzzle stones. Just draw a shape and let the filter compute
everything for you. You don't like the shape? Well, just change it.
Cloning, mirrorring, rotating. Rarely useful, but very simple to do with
such a tool. [ Aha, grouping objects. Related to earlier idea. ]

Some things aren't nice. E.g. marking which (set of) switch(es) opens
which (set of) door(s), which actors are rubber-banded and how, which
wormhole you'll end up in after entering this one, which witch watch
which swatch watch (um... sorry, couldn't help it) etc...
So there is third, quite obvious concept. The link. If you know Abuse,
that's it. If you don't, links are oneway pointers, that set up some
relationship between the linked atoms.

Even with this tool in hand, you still need to fine-tune level atoms.
You can. Adding a stone into a map is just adding a set that contains
single place, followed by immediate attaching of the stone to that
place. Aggresive editing of filtered places should be possible: by
erasing or moving single places or groups thereof, you would effectively
add more virtual layers to filtering mechanism. So you can just point to
the desired stone, move it to new position, and new filter that makes
this possible will be added transparently by the system.
Making broken-up puzzle stone is then quite simple: draw a shape, add a
puzzle filter, and grab individual places and move them wherever your
hearth desires.
The editor should contain lots of such a functional sugar on top of core
concepts, to make editing simple and intuitive. User wouldn't *have* to
know that there are some stacks of filters. He would learn, eventually,
as it would make his editing better, but random one-time users wouldn't
have to learn obscure functional interface just to draw a square with
marble and two oxyds.

Interesting issue is saving the metainformation for editor, as
translation to level file is inevitably lossy. I'd like everything to be
stored directly in level, so that there are not three files per level
(thumbnail is the third), but I don't think it will make much
difference. There will be extra translation pass anyway, this
description is a little bit too high for direct processing. Good news is
that we can have xml format for metalevel format, and keep good old
debugged lua interface for object level format.

The other issue, much more interesting, is editing lua files. For
certain levels this would be possible, but using anything
turing-complete inside would make it extremely difficult to parse the level.

Well... thanks for patience ;)
Petr Machata

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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