-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.02.2010 12:04, schrieb Ilor: > On 21 February 2010 10:44, Mark de Wever <ko...@xs4all.nl> wrote: >> Can you please tell me what you exactly want to do in the editor and >> what not. > also responding to: >> <Ivanovic> personally i would love to see a list of *all* the stuff that you >> want in our "editor" (yes, i leave 'map' out of the name by purpose!) >> <Ivanovic> then we can add what the editor (the map editor) already has to >> do these days, since it is in fact more than mere "place tile at ABC" > > I hope I can accurately summarise what we have so far. > > What user tasks are currently possible in the editor: > 1) creating or editing a map by drawing terrain and other means, > 2) placing starting positions. > > That's pretty much it. Most of the features of the editor are > sub-items of 1 -- brushes, copy/paste, random map generation and all. > 2) is very close to 1) in how the data files look (it's also in the > map_data string), but logically I'd say it' separate. Maybe the > lighting settings previewer could be considered a separate task, but > it's a minor thing that doesn't affect what's written in the map files > anyway.
In fact the editor is used for a third important task, too: 3) are terrains and their transitions fine? Yes, this is *not* something that the common scenario designer cares about, but people working on terrain arts do care very much about it. This is basically the reason for the "refresh config" (or what it is called) option that we have which reloads the terrain definitions. In theory a scenario designer would probably be fine with a plain representation of "which terrains are where" (that is: no transitions would be required) when working on placing areas and all the other tasks that are part of the "not yet included" features. One problem is that the transitions make the (current map)editor not the fastest tool on earth. > Also, some of us strongly feel that it is important to try to avoid > having yet another tool for this, and to avoid having files that are > edited both by hand and by a GUI tool. I agree wholeheartedly with > that. It already takes three programs to work on a scenario (map > editor, text editor, game), adding more tools to be used all the time > won't help. By extension, adding more separate files to be managed > won't help either, so everything edited by the GUI tool should end up > in one file, and all the rest should be in the scenario file. The part "other tool" is always some question of the interface, right? Currently the game and the map editor are one binary. For testing you do need the game anyway since there is stuff that we will (probably) never add directly in the editor (eg "playtest this scenario"), even if a button was added to do this, the program would have to switch over to "game mode" and play it there, right? Following this line of thought, that there is always some switching and the likes required, why not go for a middle way between "completely seperate tools" (like the map editor once upon the time (before ilors rewrite) was) and "one tool that fits it all in one interface"? Personally I'd probably prefer to add "levels" to the editor that would switch a mode or the likes. One mode could be the current map editor that has transitions and all the "I want this map to look great" things. Another mode could be "okay, lets define some areas and other things that do not directly belong into the terrain view itself" where a plain "just show the tiles with overlays without any transitions and variations" view could be used. A third view could (a lot later!) be "switch over to the game and start this scenario". Somehow I currently think that there should/could be 3 files per scenario: 1) the current map file that only holds the terrains and their layout 2) a file for thing atop of the map (with a pointer to the correct map) that mentions stuff like areas, labels and whatever else the scenario designer can place in the gui tool 3) the "real" and hand edited WML file that just points to file '2' to get the map and "specific definitions" upon the map Yes, it would not really be possible to place units *directly* using this approach since units still belong into '3'. But you could place markers for "unit 1", "unit 2", ... in file '2' and just use those. Somehow we would also need some easy way to represent the labels, sound sources and whatever else we add in the view. I think in a "we edit the map and everything else directly in it" things will become unusable regarding what is shown on the map (imagine one hex that has a label since it triggers the area of a sound source, allows easily adding a unit there and is also part of two or three "other areas", how will this be shown with all the other stuff?). In general what you would load as content designer is either file '1' or file '2' (where '2' does directly load '1' for the "map editor view" and loads '2' to show it in the simplified terrain view). This way a plain map file can still easily be shared for several scenarios, since the *map* is still a plain file just defining where which terrains are, the rest would be separate and in file '2'. This would leave a hard separation between "hand edited" and "edited by gui", since '2' should only be edited with the "extended editor" and '3' is really just hand editable. Beside this to content designers it would probably not feel like they are using "various tools" just switching the currently available parts around, like it is common in other tools, too. Comments regarding this approach? Anyone else seeing a possible GSoC project here? ;) Personally I'd love to have a good design goal for planned changes to the editor, so that we do know what to expect and can think about the possible problems before they appear. And yes, I *love* to finally see some discussions on the ML again! Cheers, Nils Kneuper aka Ivanovic -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkuBG7kACgkQfFda9thizwVs6wCgonC28FANL+K31EXD9WKz3l9z 2mQAnR3XVB2zatvOJim/Pk7fEB5ktTin =Gky5 -----END PGP SIGNATURE----- _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
