[Freeciv-Dev] Re: (PR#8632) Easy way to set map size with auto ratios (seteables if desired)

["Marcelo Burda" <mburda@xxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >

Le sam 05/06/2004 à 13:13, rwetmore@xxxxxxxxxxxx a écrit :
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> 
> 
> 
> Marcelo Burda wrote:
> 
> > <URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> > 
> > Le jeu 03/06/2004 à 09:16, rwetmore@xxxxxxxxxxxx a écrit :
> > 
> >><URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> >>
> >>
> >>Ratio is a bad concept that leads users to expect things they cannot get
> >>and the idea that this is a good way to give a map shape is misguided.
> >>
> >>The exact numbers of rows and columns in a map are dependent on a number
> >>of wrapping constraints and other low level details the end user also should
> >>not be aware of other than in ways in which they might change parameter
> >>input by adjusting an x or y value up or down a few counts. Fixups like
> >>this to user input need a simple informative message under non-verbose
> >>or information message category.
> >>
> >>The map view is a standard X x Y grid. Thus this is the simplest set of
> >>parameters to define it, has been considered just hunky dorey as the
> >>definition of ROWS and COLUMNS in TERM definitions for a dog's age, and
> >>means that complex math for computing rations to get back to this level
> >>of simplicity for grade schoolers is not required.
> >>
> >>Using simple parameter selections/defaults (e.g. 80x50) for standard maps in
> >>the non-advanced section of user input is fine and having a "bigger/smaller"
> >>button that allows one to choose a number of sizes with similar but adjusted
> >>shapes is also fine, but having the user say they want a map of 100 tiles 
> >>with
> >>a ratio of 1.6 is just not a usable concept, and was never from its earliest
> >>inception, as has been stated before.
> >>
> >>This should be considered a showstopper fixup.
> >>
> >>Cheers,
> >>RossW
> >>=====
> >>
> > 
> > hmmm. i understand your points
> > player are only asked, and player only ask, to set a size. little,
> > medium, big. that is the base concept. i think the size option is well
> > done.
> > set size 1: is a very little one and set size 30 is a very Huge one. 7y
> > old concept.
> > 
> > xsize and ysize are unneeded. and show simplest only if map as not ISO
> > coordinates. For iso coordinated this need to by hard corrected to get
> > the users want,  
> > if your really want set this info then we need to ask for natural size
> > and not for natives. to get the desired map. (but probably surprising
> > small)
> 
> Incorrect. xsize and ysize refer to native coordinates and are the 
> underlying dimensions of the map as stored. This should remain.
This is a patch about the way for user to select size of the map. the
information enter by users is converted in internal xsize/ysize. this
will remains!
> 
> Natural *might* be used as user input in a dialog, but get converted to and 
> stored as native for all internal use. But I think that native still makes 
> more sense for the rectangular GUI window that the user is describing and 
> will be more consistent across different types of maps. But if confined to 
> the input dialog, it is not a big deal to have a lot of confusing natural 
> flavours for different parameter coding to fold in as new topologies are 
> added. But the underlying storage system *must* be consistent and follow 
> standard rules across all the topologies.
> 
> Note a polar topology should still store xsize,ysize native dimensions even 
> though the topology has 100 rings of increasing squares.
> 
> > if we make maps with a another shape (as a hexagon map) this info is
> > really bad.
> 
> I agree, natural is bad. That is why native exists and is specifically 
> chosen in each case for internal and not GUI reasons.
> 
> > then i think a size variables in the only really good one.
> 
> Wrong. It has the wrong number of dimensions for a 2D map for a start. I 
> think you need to understand the logic of native which solves all these 
> problems if you use it as designed, rather than trying to reinvent it in a 
> broken way for your specific case.
> 
Size in mesure of area, then this is a relevant information for a 2D
map. if i as you about size of the USA what info i will get? Probably
the number of km². Nobody answer this question with the E-W size and the
N-S size! the more simple and more important information to select a
map. is the area.
Second, i remember you answer me. than (not in these words!) medium
users is too stupid to understand a ratio. now you say users are so
developed than can understand native coordinates in all topologies. :-o
> > about ratio this can be more difficult.
> > 
> > the best way to allow player to create a no default map is with a
> > boutons and a preview windows where players can view the ratio. but this
> > is a little too much work. probably this will be done. latter.   
> 
> The best way is to hardcode the default dimensions in a copy of the standard 
> structures that is presented as needed with the standard GUI dialogs just 
> like when filled in or changed. The same values can be added as rules that 
> overlay the hardcoded ones if present. The  user then gets to update these 
> as desired where allowed, or by changing parameters that cause multiple 
> changes to take place under program control (wizard rules for naive users).
that is, not in gui, than is proposed, auto ratio hardcode best default
dimensions. then these dimension are scaled to the select size of the
map. a medium user only need understand one concept: size (area).
the wizard user select the ratio. these user only need understand a
second concept: ratio, No user need to understand native coordinates
concept in all topologies!
> 
> > yes the code is a complex.(this only need to be writed one time, and
> > this will never see by users) but not the concept. any body know about a
> > 16:9 ratio of newer TV. or about 4:3 ratio of classic ones. this is not
> > a so complex concept. and this is only wanted to creator, not to
> > players!
> > players are asked to not touch this option. and this option is put in
> > internals not in geology to avoid this.
> 
> ROWS and COLUMNS is much clearer and involves less math or mental strain. 
> Since this is the current Freeciv system, There is no reason to change it 
> and risk new bugs or other maintenance issues.
? no bug, we only wor in input data by users, these data are transformed
by one function. map_init_topologie and these function calculate data
needed by the game. as map.xsize, map.ysize. no bug can be add these
way.
> 
> > i want think as you, but i not like at all the xsize and ysize for
> > players. that are really bad information.
> > size are simple.
> > ratio not so simple but exact. and players are not so stupid. (i think!)
> 
> But this is not for players, but coders as you say, it is hidden. That it 
> should be not only hidden but abandoned completely as it adds only a 
> different but in many ways unusable perspective is the next step.
> 
> Go back and understand the current Freeciv standards for this and do not 
> seek to change them or fold in presentation or GUI concepts that should not 
> be mixed with core mechanics of incremental topology development.
> 
what standard? plz, i am not a stupid man. 
this is not a question of standards, or understanding. if you think all
freeciv is a standard we can stop developing it now! (you too)

freeciv is a 2D game. all future topologies (complex or not) will be
basically 2D ones: overlapped maps, 3D structured map. still basically
2D. the size as a mesure of the total area of a map will be forever the
more basic and most important parameter to be choice.

in simplest topologies, no wrapped map or tildeables map ones, the most
important complementary parameters (after the choice of topologie) is
the ratio of the base map. (a another important parameter will be the
shape but today we only work in rectangular base maps)   
> > Marcelo
> 
> Cheers,
> RossW
> =====
> 
> 
>