Pietro Giorgianni wrote:
> i'm not sure i'm understanding your questions; please tell me if i'm
> missing the point.
> "Ryan Richard Faith" <ricfaith@...> writes:
>> 2) To ref these TileTypes, you'd need to use an identifier of some
>> kind. Either a string to match the ref or name field, or an integer,
> i think we can easily avoid the use of string identifiers during the
> game, and the use of "magic" integers inside the specification.xml.
> so, specification.xml should define "highSeas", wherever it wants, and
> not "11".
> for me, there are two acceptable solutions:
> a) when reading specification.xml, we fill some integer variables (or
> maybe some integer arrays) with the right indexes, so that, say,
> return getType() != UNEXPLORED;
> return getType() != mandatory_types[UNEXPLORED];
I'm not sure I agree that "unexplored" should be a tile type rather than
an attribute of a tile.
> b) a specification.xml is an abstract specification and isn't
> concerned with the internal representation of data; this means
> that, when reading specification.xml, we renumber things as we
> like best, placing mandatory types at the beginning, so that we can
> still directly use UNEXPLORED, HIGH_SEAS (which of course should
> not be 11, buy maybe 2).
I'm also not sure if I agree that "high seas" needs to be a mandatory
type. The only thing that is special about the high seas is that they
allow you to move a ship to Europe. A user might wish to remove tiles
with this feature and reduce the movement cost of ocean tiles, for
example. This would still allow ships to set sail from the map borders.
And the current map generator ensures that this will always be possible.
> in both cases, we should always use integers during the game, and
> should also write integers in our save files. in case b, we should
> also save the relation between names and integers, but, after all, i
> think that loading a saved game with a different specification.xml is
> hardly possible, or at least the specification.xml must define all the
> things used in the saved game.
Maybe the save game should include a copy of the specification used when
the game was started. This would avoid any problems with changed
specifications. This copy might well be in a different, more efficient
Although integers are certainly more efficient for saving the game, and
similar purposes, I think methods should be passed types rather than
integers or strings whenever possible.