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. > 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. > * 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. > * Scenery or item images. Idem. > 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.) > 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. > 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. > > 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. 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 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. 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.) > 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. > 2. Make the map editor able to display and edit these annotations. > > 3. Enhance the WML engine so that scenario WML can aee the placed > labels, scenery/item images, and named locations. -- Regards, Mark de Wever aka Mordante/SkeletonCrew _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
