This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Quoting mskala@ansuz.sooke.bc.ca:
I'd much rather be able to define images per-hex instead of per-terrain-type; that seems like it would serve the same goal and be much nicer.
To me this makes sense. This would mean that map attributes are defined in a
uniform array per tile. The _tile_ is the object. It then carries with it a
number of attributes such as terrain type, elevation, climate, etc.
Does this mean major changes to the Xconq code, Eric? Would we have to change the Xconq kernel or could we get away with doing this on the module side?
It would be really nice, too, if that one file could be just the direct image (possibly scaled to size), and then XConq smart enough to clip out hexagonal chunks in the right places. That would mean changing the read-from-image code to use a hex grid corresponding to the map instead of the current square grid, but it would mean eliminating an especially nasty cut-and-rearrange step in creating the file.
I agree. This way if Eligah wanted to create his "Lord of the Rings" map, he could simply do so starting with a Middle Earth map
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |