From: John A. T. <ja...@ja...> - 2006-07-09 12:51:04
|
Erik Vos wrote: >>Yes, but how does that change my suggestion to calculate them >>based on >>the drawing of the tile rather than to store them in the XML and then >>have to back-calculate the center point of the city structure for >>drawing the tile? >> >> >I agree with your suggestion, which I had not noticed before. >(A few posts ago I asked whether you intended to calculate >slot spots bases on city drawing, and I didn't notice a clear >answer to that. Apologies if I missed it.) >I never intended to suggest back-calculation. > > Also, the drawing of tokens (as opposed to hit detection) could be done by the tile object as well (indeed the home token locations are done as annotations in the token slots already), taking advantage of the minimum size checking code to be built in -- ie, if the scale is small enough, just use a colored circle rather than the actual token herald. >I was not talking about the tiles database (now Tiles.xml), >but about the amount of tiles per game and the location >of the preprinted tiles on the map, all of which are now in >TileSet.xml, together with the upgrade rules and any per-hex >tile laying restictions. > >I made that distinction on purpose: Tiles.xml is generic >(although there is now a subset per game, but that subset is >not essential indeed, only a speed-up), >and TileSet.xml has anything that is game-specific regarding the >usage of the tiles. >I hope you don't intend to mix up that distinction. > > No, just as in my database I have a tiles table (and various join tables) containing the actaul tiles, and game_tiles (and others) which contain the information about the set of tiles in a given game. However, collectively I am calling all of these the tile database as these tables all contain information about tiles. >(BTW, I generate the per-game Tiles.xml from the generic Tiles.xml >and the per-game TileSet.xml, this is done by the stand-alone >class util.MakeGameTileSets. >No manual work except running this class!). > > Ok, that is what I was arguing for -- there is only one authoritative list and the others are all generated on demand (preferably with make if the master changes rather than having to manually run it), and the generated file is never edited. >In general I agree, but in this case the saving of code by >not having to sort out all the default upgrades and then apply >any exceptions IMO far outweighs the extra effort to specify all >upgrades beforehand. I'm not going to write *that* code! >In other words, feel free to add categories but I won't use these. > >However, a stand-alone program to fill up a skeleton TileSet.xml with >the default upgrade rules, which then can be edited manually >would be very nice as a contribution from your side! >Or perhaps a program to expand a TileSet with inclusion >and exclusion upgrade rules to one that fully specifies all allowed >upgrades. But I can live without any of these. > > As Dave Mitton pointed out, finding legal upgrades is actually quite simple if you have keep the connectivity bitvectors per tile -- you can even get the various orientations of legal upgrades for free as well. You just take a candidate upgrade, rotate it through all six orientations, and any that have all the bits set that were set in the original are a legal upgrade. -- John A. Tamplin ja...@ja... 770/436-5387 HOME 4116 Manson Ave Smyrna, GA 30082-3723 |