Mark de Wever <ko...@xs4all.nl>: > Personally I think the map editor should stay a map editor and we better > start a separate scenario editor.
I understand the impulse. But, sadly, a general scenario editor is an unachievable mirage that would only get in the way of achievable improvements. I learned this the hard way on a different project. I once spent a significant amount of time over several years trying to figure out how to write a visual editor for heraldic achievements (coats-of-arms). A visual pick-and-place editor isn't hard, but heraldry has a parallel representation is a restricted dialect mixed from English on Old French called "blazon", which is (in effect) a structured declarative language. Here's an example of blazon: Argent, on a chevron gules between three leopard's faces sable three castles. It describes this image: <http://penelope.uchicago.edu/~grout/encyclopaedia_romana/britannia/anglo-saxon/flowers/images/blazoned.gif> Ideally you want your heraldry editor to simultaneously modify a visual representation and a structural description that can be used as a deep structure for generating blazon. In this case the blazon (or, rather, the structure tree representation from which one might generate blazon) is closely analogous to WML; the visual information is analogies to a map. The heraldry-editing problem is similar to but simpler than the problem of editing WML markup through a purely visual interface (that is, without cheating and opening a window on the textual WML representation). It's simpler because blazon blacks branches and loops (it does have something like variables, or at least backward references). I concluded with regret that there is no good solution. Gestures in a visual interface simply are not a rich enough primitive set to capture even the primitive structures of blazon. They would be even more inadequate to cover WML, which is Turing-complete. To see why this is in the WML case, imagine trying to express an if-then-else in the underlying WML using gestures over the map. You can't do it - just the sublanguage required for expressing the gaurd part is too hard. Thus, I believe design effort spent thinking about a general scenario editor is wasted, and any planning based on it is futile. We'll never get away from editing scenario WML at the markup level; the only realistic goal is to enable visual editing of the parts that actually do fit well into a point-and-shoot interface, and enhance WML so we can separate those parts out of the procedural markup but link them back to it. > > There are two main goals associated with these features: > > > > A) What *can* be edited visually *should* be, in the map editor, > > in order to reduce the complexity of (the quasi-procedural part of) > > scenario WML. > > Where does this stop? eg placing units can be done visually as well. (Not > meant sarcastically, but a serious question about what we want to > achieve to do visually.) It doesn't stop anywhere short of what is possible. This probably does include placing units. But, as I explained above, there are fundamental reasons that visual-gesture editing will *never* cover our entire problem domain. > > These design goals enable the following meta-goals: > > > > I) As much of the complexity of scenario design as possible should be > > moved from hand-crafted WML to representations that can be > > visually edited, to simplify the design task. > > How does this differ from point A above? Different emphasis. The meta-goals were intended an outside-in vuew from a content authors point of view, rather than centered on what developers know about the primitive objects in the system. Perhaps I didn't express this very well. > I think we should add an additional design goal instead. > Make it possible that the editor opens a scenario file to load all > related data and can write it properly back, without making a mess of > the WML. I don't want to try to go there. Designs that try to mix tool-centered editing and editing of the same data unit by hand are *notoriously* bug prone. One problem is that human beings have a pesky habit of hand-hacking the parts that the tool "owns" in ways that they don't realize violate the tool's expectations, leading to cascading damage when the tool is next applied. I think it's better to have a clean separation between things the editor owns (the .map files) and things that humans edit (the .cfg files). -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
