Re: [glob2-devel] Reverse Compatibility

[Kai Antweiler]

> I'm looking to do some major re-designing in code related to
> SessionGame and SessionInfo (the map and game headers). This isn't
> particularly easy, the Session code is at the core of the Engine and
> file-save format.

> So I'm looking at peoples opinions related to reverse compatibility.
> If we want a new, clean coded engine, at some point we are going to
> break reverse compatibility. Remaking map and game initialization code
> would be one of those things. All previous game saves and maps would
> be rendered useless.


Will your changes only influence loading and saving data?
If so, you'll might preserve an option to load old games in addition
to load/save in new game format.


> It should be possible to do a conversion (somehow), but allot of this
> engine code will be refactored, and the end-user probably won't be
> able to easily convert his/her games.

If we can cleanly specify the old and new game format, we'll could
ask our comunity to design a converter.  It would not need to be in C++,
and some people that have created a few maps have a motive to help us.


> 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"


> 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.

This is annoying, but always having to work with old standards is
frustrating.

btw: Savannah is testing git repositories and darcs has experimental
support for git repositories.  Maybe we can switch to something good
and get rid of cvs soon.  I'll look into this after our next release.
Git for unix people, darcsgit for windows users.  There also is one
to one (as far as I know) translatability of git and mercurial repositiories.
http://savannah.gnu.org/support/?105808
http://www.mail-archive.com/address@hidden/msg00774.html
http://darcs.net/DarcsWiki/DarcsGit



> Anyhow, I just want to gather some opinion on the subject before I
> begin anything drastic.

A break in backward compatibility must show in the version number.
A user would be supprised when "glob2-0.8.23" breaks what was standard
in "glob2-0.8.22".

I would say do it.  But discuss things on the mailing list.
e.g.:  We recently had support to save a timer or certain victory
conditions that we might invent should be part of the format.
Or support for race customization, even if this will take years until
someone implements it.

Being able to read the script state also would be nice for debugging
of campaigns.  Though this is not part of the file format, implementing
this might be easiest while doing the rewrite.


Last remark:
If you think you'll can live with current headers, and think It'll take
a lot of time, ask yourself whether there are other things you might
want to work on.  Hard work isn't automatically better than easy jobs.

-- 
Kai Antweiler