glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] About maps backward compatibility


From: Kieran P
Subject: Re: [glob2-devel] About maps backward compatibility
Date: Tue, 17 Apr 2007 10:46:58 +1200

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/
reply via email to

[Prev in Thread] Current Thread [Next in Thread]