Mark de Wever wrote: > Thanks for the post Eric, > > On Thu, Feb 18, 2010 at 07:05:43PM -0500, Eric Raymond wrote: > >> Mordante asked me to summarize some design goals arrived at in a >> recent IRC discussion of enhancing the map file format to >> contain static objects. >> > > Historical the map editor was intended to only edit map and nothing more > fancy. So I think we should first discuss, what do we want the map > editor to become or whether it should stay a map editor. > If we decide that we want to add features to the editor, we seriously > need to look at the gui before starting, the gui is already pretty full > and in fact already broken on 800x480 (--smallgui is needed for that > resolution). > Personally I think the map editor should stay a map editor and we better > start a separate scenario editor. This editor can be based on the > current editor code and remove the editor features and add the other > features, so something can be started quickly. Starting from scratch > will probably give a better result, but will take much longer. > > The map editor should stay a map editor. Some more advanced scenario editor would maybe be better implemented as an extra tool. But all use cases that have been proposed so far are very map bound from wml developers point of view. For all the issues I need to work with the map editor but translate some of it's output manually to the wml code the map editor is the right place. >> By "static objects" I mean three different kinds of things: >> >> > <reordered points> > >> * Named locations or areas (hexes or sets of hexes) that can be >> referred to by name from scenario WML. >> > > I think this feature is needed very nice to have and I also think that > if we implement this it should be done in the map editor. > > Right, I didn't thought about this use case but it turns out to be the one that gives the most improvement. >> * Text labels associated with a hex >> > > I think this isn't really required, especially not if a set of hexes can > have a id. At least not in the map editor, if we add a scenario editor > this objection no longer holds. > > Why do you want to do that with a second layer involved? Edit the map, assign id's, edit the wml and remember what id needs to be named "blah" for team a and "blub" for team b. This will most likely lead to the old problem again: You need to work with 2 applications at once to work on the same issue for no reason. >> * Scenery or item images. >> > > Idem. > To bring the placement of scenery or item images to the editor was *the* reason I started the project. If you don't see the need for that then try to arrange a map with several items and sound sources like it is done in IFTU for example.
Honestly, (please don't be offended) you need to have experience as a campaign designer to value what the new proposals offer. > >> 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.) > > Unit placement is ugly hard work especially for cutscenes. I think most campaign developers will agree on that. It's not only the coordinates that have to be set you also need to get the facing right. It's a constantly switching between three applications (the map editor, the game itself and emacs in my case). So placing units in the map editor is definitely a goal I would like to archive. >> B) Scenario WML should never have to speak numeric coordinates; it >> should always be possible to reference named locations instead, >> with the name-to-hex(es) mapping carried in the map file itself. >> > > I think this is a good goal. > Somebody at irc was afraid that this would disallow x, y placement, but > we can't. The save-games will still save units at an x, y position and it > would break backwards compatibility for no gain. > > Agreed, there is no need to abandon the old syntax. >> 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? > > >> II) Cases where editing scenario WML or its map in ways that can cause >> them to fall out of sync should be eliminated. Where they can't >> be eliminated, they should be detectable by automated checking. >> > > Agreed. > > >> Note: I don't think it's required that we be able to place entire >> events or active items in the map. As long as the map editor can >> handle representative images and location tags -- the parts that >> are actually visual - that's sufficient. >> >> Right, remember that the [item] tag does not much more than placing the image on the map. >> On the other hand, I think it *is* important that all the >> static-object annotations associated with a map live in its .map file. >> If they're separated from the map data, editing them and keeping >> the map and annotation parts in sync will get messy and attract bugs. >> > > As said on irc I think we should postpone discussing these details until > we get the design goals set. I'm quite hesitant about changing the map > format and see several cans of worms being opened here. If for example > we want to allow to place units as well the map format changes will be > too big so we better find another solution. > For example scenario foo.cfg gets > foo.map -> containing the map > foo.units -> containing the units > foo.label -> containing the labels > foo.icon -> containing the icons. > > To say it again and again: The map format (map_data) is not planned to be touched in any way. > But since the we haven't decided which goals we want to achieve talking > about the implementation details seems silly, so let's talk about what > we want the editor to do and whether it will get bolted on top of the > map editor or becomes a separate editor before diving in these details. > > 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. > > The editor is going to read and write the [map] tag. I believe that everything that is needed to do this is already in place. >> The roadmap needs to look like this: >> > > -1. Decide what we want the editor to be able to edit and do, not only > in a few weeks, but preferably what we want it to do in a few years. > > The editor should handle all location related issues. That means the placement of labels, items, sound sources, units, and named locations. Labels is already working in my branch, I plan to work on items and sound sources next. Named locations will be a little more problematic since this is a multihex issue. The hardest task will be the units, that will be done at last. > 0. Decide whether to bolt this on top of the map editor or that creating > a new editor is the better way to go. When we decide to do it in a > separate editor, the person doing the job should decide whether to start > from scratch or not. (I prefer s/he will, but it's his/her time to > spend.) > No, that is not a better way to go. It will lead to the same situation we have already: Multiple programs are involved in the same working process. That is like you have two programs for chatting in irc. One you can only write in and one you can only read from. >> 1. Design an enhancement to the map file format that allows it to >> contain annotations for the three kinds of static objects. >> > > 1. Decide which changes to the scenario and map files are required. > > Map files can stay as they are. The scenario files could be unmodified as well, but I don't want the editor to write into the human editable file directly. That is why everything can go into the new [map] tag. >> 2. Make the map editor able to display and edit these annotations. >> >> I am currently working on a framework to give every editor tool the chance of displaying editor labels for what have been done. >> 3. Enhance the WML engine so that scenario WML can aee the placed >> labels, scenery/item images, and named locations. This is not necessary, the engine already knows about labels, items, units and sound sources. The only thing that is missing is the named locations feature. But I don't consider this a hard task. _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
