> > I'm thinking about this mainly because there isn't really a good place > > to put something like team alliances that can be set before the game. > > Its certainly possible to implement this, but it would be yet another > > hacked in feature. I considered putting it into BaseTeam, only to > > realize BaseTeam was a static style object of the map, rather than a > > dynamic object of the game. > > I think easiest (but not best) thing would be to create an additional > file for maps and games, like: > "A_big_pond.game" and "A_big_pond.metainfo"
I'm strongly against this, we don't want to go into Apple_mails-like system with pet metafiles (sorry for my tone, but I hate external metafiles). imho, a much better way would be to have maps as zip (not tgz which require entire decompression prior to toc access) files, with content (map itself + any number of metafiles + some additional graphics) fused into glob2's virtual filesystem. This was my original design I never had time to implement. I think it would open endless possibilities. > > Backwards compatibility is really the only thing keeping me from > > starting fresh, deleting much of the old code like I did with the unit > > allocation system. In this case, If i'm not very carefull, all usage > > of previous maps could be eliminated. This is half the the problem, > > backwards compatibility is keeping us from implementing a completely > > new design. Glob2 is sort of a victim of its own success. > > I'm generally for creating new code if: > it fits the game better, > is well documented, > maintainable and extensible > so that the next generation of glob2 developers won't have to break > backward compatibility again. I agree, if the new format is really better we might consider breaking compatibility. Steph -- http://nct.ysagoon.com _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
