Re: Re: [glob2-devel] About maps backward compatibility

[donkyhotay]

I agree with kieran, as someone that works in the code I would greatly 
appreciate a rewrite that makes it less confusing. I'm not familiar enough with 
the way the maps are processed in game to know for certain but to me it seems 
like it wouldn't be too difficult to write a small program that reads old glob2 
maps and writes them as new glob2 maps. Most of the code would have already 
been written (old read code and new write code) with a little bit extra for 
translation. The loss of the old maps seems to be the only serious downside to 
this and I'll admit I would prefer to keep them if we can but in the long run 
fixing all the flaws is much more important. Otherwise glob2 development will 
probably stall. While there's been a recent surge of development this past 
month there hasn't really been anything major for past few months previously. 

From: Kieran P <address@hidden>
Date: 2007/04/16 Mon PM 05:46:58 CDT
To: Globulation2 development mailing list <address@hidden>
Subject: Re: [glob2-devel] About maps backward compatibility

Maps are long to make.
Not really, we just don't have enough people working on them. I could make a 
map in about 30minutes.

Good maps are rare, and we already have few. It is completely silly to 
eliminate backward compatibility for the sake of it.
Elimination BC is not the end of the world. We just make newer, compatble maps. 
And if the new core is more than just a rewrite, it should make playing and 
loading slightly faster, and less buggy. It would also allow things like 
recording games (full games which can be played back) hopefully.

It destroys hours of work of many people that did the maps.
True, but someone can just remake them, nearly exactly like they were, with the 
original authros name as the maker, and I bet they couldn't even tell the 
difference (who really plays all the maps there?).

It forces us to get a new set of maps
Yes, or remake the old ones, which will be as simple as having two comp, one 
running the old map, the other with the map editor open, and someone copying 
what they see (thats what I'll be doing)

It serves no purpose as basically you can perfectly have a new and old map 
format: you only need a filter.
But as Bradley has already said, the filter would require a lot of work. Its 
just not worth it. Better to rewrite it, than write it with lots of bugs. 

It introduces new bugs where there weren't (make no mistake, all code is buggy, 
and there is no reason a rewrite will be less buggy than the original)
True, the new system will be buggy. And true,  a rewrite for just this one 
thing seems pointless, but dont forget what else it opens. The new core will 
allow for lots of new features to be easily coded, and bug fixes applied. Isn't 
that the main purpose of Glob2? Not to be bug free all the time, old code, and 
be content, but to have new features, increase gameplay, and give players more 
options (even if it means releasing bug fixes every week) :P

if it ain't broke, don't fix it!
Ah, but it is broken. In the code. Maybe not from where a player sees, but for 
devs, its a nightmare. The better the code, the better the game. 

network play needs to be flawless, and if that takes a rewrite, so be it!
That is true. Yet I managed, despite lag because of my dial up, to have a quick 
game with fingers (IRC nick), and host, and join his. All it really needs is a 
better compression to send data over the net faster and the ability to open 
just one port and be able to host/chat, and use yog (current 12 ports need 
opening :S). 

Because make no mistake: having good maps (or having maps at all) is _way_ more 
important than saving five minutes by not implementing a filter.
Lol, if you think it would take 5 minutes to implement the filter, you dont 
know the code well enough. It would be a major hassle. Two major maps systems 
in one game shouldn't be done. Not only would it makes releases bigger, longer 
to compile, and buggy, but also makes it harder for devs to implement further 
features. 

PPS and from a development perspective, rewrites of subsystem should be done in 
separate branches and merged when well-tested and feature-complete.
Not when the source is pretty much complete for alpha23. Once the bug fix is 
released, no development of the code in HEAD would be done for  months if 
Bradley used a branch. Its better to keep it in HEAD, so people can download 
and help report bugs when the system is in place and being tested.

-- 
Kieran.P
http://qlwiki.linuxsolutions.co.nz/

_______________________________________________
glob2-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/glob2-devel