PROJECT: What a patch should contain. Where to draw a line.

[Keygen]

Originally posted by Solver

Keyg, the "if it works, it's not a bug idea" is flawed. PBEM in CtP2 also "works", just without turns progressing and diplomacy - that's a bug.

Does human-human diplomacy works in PBEM in CtP2? No, it doesn't and that's a bug. Don't confuse things here

[Solver]

Yeah, but PBEM works, diplomacy is part of it. Likewise, the game works, but proper memory management is part of it.

Also, again, bugs are in software, by definition, things that happen, but they should not, by design. And - by design doesn't mean exclusively the game design document. By design, the game needs to be as stable as possible, run as fast as possible and use as litte memory as possible - memory leaks don't help that.

[Martin Gühmann]

Originally posted by Keygen
Does human-human diplomacy works in PBEM in CtP2? No, it doesn't and that's a bug. Don't confuse things here

That confuse me espeacilly in combination with this:

Originally posted by Keygen
Well, they might had lot of things in mind but what it matters is whether they finally decided to implement them or not. They obviously decided to drop lot of things and rush the game. Therefore we should treat those originally-designed-but-dropped-after features as new additions to the code. That is my recommendation.

PBEM was in the original design but they didn't finished it they dropped it.

-Martin

[Keygen]

What is the confusing thing? My definition of a bug? What by design means? Both?

I've been trying to sort things out here, decide what should be included in the first patch, suggested alternative solutions and we end up playing with words...

[Keygen]

Originally posted by Solver

Also, again, bugs are in software, by definition, things that happen, but they should not, by design. And - by design doesn't mean exclusively the game design document. By design, the game needs to be as stable as possible, run as fast as possible and use as litte memory as possible - memory leaks don't help that.

Sorry Solv, I'd been a professional tester for 2 and a half years but never heared that definition before. It must be a new one...

[Martin Gühmann]

OK let's try to claer out things: The PBEM diplomacy stuff is probably a huge task otherwise they wouldn't removed it, so in a first 'official' patch we can do what they did just disable the according screen buttons, we can't fix the Neptun world properly we can also disable the button and so on, but as long as these additions are small like adding some interface options we already have in the userprofile.txt then we should do, even if we disable these interface options for a patch 1.2 later, by modifieing the *.ldl files. The memory leaks that Fromafar fixed are also little additions no huge changing in the game engine, that is just tidying it. I thing if there is something wrong with illigal pinters then you should notice on the very fisrt use of these windows. A change in the game engine would be adding startegic ressource, well we could add some stuff to the text files for it for later implementation.

Basicly what a huge and a small new feature is lies in the eyes of the beholder in that case the person who implements it. If you have to change a couple of 10 or 20 files then it is a big change, but if you just have some files maybe 4 or 5 then it is a small addition.

-Martin

[Keygen]

Well, that is what this thread is for. To define what is a minor change and what a major, whether we should consentrate mainly in fixing bugs or adding new stuff or both, how many new stuff should be added per patch, what improvements should be made and many more.

Again, this is a discussion on what should the patch(es) include and where we should give priority and in no way restrict people from making beneficial changes in the code, fix something they bumped into it or even work on their own on what ever they'd like.

[Martin Gühmann]

Originally posted by Keygen
Well, that is what this thread is for. To define what is a minor change and what a major, whether we should consentrate mainly in fixing bugs or adding new stuff or both, how many new stuff should be added per patch, what improvements should be made and many more.

Well at least I would like see some minor changes in the interface in the first patch like they are already posted.

Originally posted by Keygen
Again, this is a discussion on what should the patch(es) include and where we should give priority and in no way restrict people from making beneficial changes in the code, fix something they bumped into it or even work on their own on what ever they'd like.

So you mean if someone is able to add a new feature then he should do it. I think in the end we should decide whether it is in the patch or not, preferably the change should be disabled and enabled easily so that we can remove it in the case of doubt without much effort or readd it.

For interface options that is not a problem, at least if the interface gives more options, if it just looks differently then it shouldn't be a problem at all.

-Martin

[MrBaggins]

I'd just like to say that I agree with the essential sentiment of all of this. I've been participating in some game balance discussions, but I wouldn't suggest that they need to be included in a patch just yet. I think that *eventually* we should include some form of rebalanced text files, along with whatever executable.

I think that a comprehensively tested and tweaked rebalance, including the later ages, might take some time, and simultaneous play testing shouldn't be an issue.

I agree that bug fixes are what should happen first, and they should include little, if any extension of whats in the code at the moment.

[drulius]

I would like to suggest that a small change might span 10, 20 or more files, if it could easily be farmed out to a jr. programmer. After the problem is discovered and the fix found, carrying out the actual code change could be tedious for a more experienced programmer, but might be a valuable learning experience for a less experienced programmer (or two).

Closer to on topic, Is there a list posted somewhere of "known bugs" that was originally meant to guide Activision's next patch? Once there are a few people familiar with the code, it should not be too difficult to go over such a list and roughly define which fixes will be big (many discovery and fix writing/implementing hours) and which will be small (few discovery and fix writing hours, possibly many fix implementing hours). Of course that is separate from whether the first patch release should be held off until certain big problems are fixed.

Actually on topic, I think that there should be not two but three concurrent developement lines. One that just fixes Activision's CTP2, another one that implements Apolyton's enhanced CTP2, and one that makes the game "best in show". IMO things like extra world or map options, new tile imps, more civ options, belong in the Apolyton enhanced version. Also things that were dumped in developement like, PBEM, belong in the Apolyton enhanced version. A person who originally enjoyed CTP2 but quit playing the game because of the bugs should be able to install the plain vanilla repaired Activision version and enjoy the same game experience they originally enjoyed minus the bugs. The enhanced version should stick fairly close to this, but would include, for example, in game buttons for changes that can be made in text files, extra world shapes, higher max civ limits, etc. PBEM and repaired SLIC should go in the enhanced version, also optimzed AI. But here is where another line should be drawn between enhanced CTP2 and mods/scenarios, and I don't know what side of the line AI changes should go. Anything that drastically changes the game, (like a culture layer or bringing back the space game, or revamping the trade model, or reworking the tile imp to building imp relationship), should be considered a Modded game.

So maybe there is room for three developement paths? The vanilla repair, the optimized repair, and the Apolyton "source project" Mod. Most likely all of the vanilla and optimized changes would also be made in the Mod version, and most of the optimized changes that don't go in the vanilla patch should be easy to control by commenting out or using # if defined. The differences between the three versions should mostly end up being choices made when compiling binaries. But that is just a (barely) educated guess.

We're just talking about the naming convention for version control and version definition of binary releases, anybody can do whatever they want with the code (subject to the EULA). But, I think this three tiered approach, being open ended, is close to a best approach. Anyone who has the desire should be able to start with the Enhanced or the Mod version and create their own "best in show" mod, theoretically they should be able to start with the vanilla version too, but then they would be stuck with the unfixed SLIC.

[Pedrunn]

I vote for include slic additions. After all it does not change the game at all.

[Keygen]

Originally posted by Martin Gühmann

So you mean if someone is able to add a new feature then he should do it. I think in the end we should decide whether it is in the patch or not, preferably the change should be disabled and enabled easily so that we can remove it in the case of doubt without much effort or readd it.

Yes, that's the spirit.

[Keygen]

Originally posted by drulius

Closer to on topic, Is there a list posted somewhere of "known bugs" that was originally meant to guide Activision's next patch?

If you mean a post from the CTP2 team, I don't think so but some other people around would be more appropriate to answer that. If you mean a post from the players I can link you to three of them, here, here and here.

Originally posted by drulius

Actually on topic, I think that there should be not two but three concurrent developement lines. One that just fixes Activision's CTP2, another one that implements Apolyton's enhanced CTP2, and one that makes the game "best in show".

That is what I suggest too more or less. a) Release a patch (1.2) with fixes of known bugs, b) a second one (1.3) with improvements, minor additions and fixes of any newly discovered bug, which patch will last for a longer period and will be tested thoroughly and c) major improvements and additions and radical changes in design that will make up an add-on, expansion set or CtP3 depending on the amount of changes.

[Keygen]

To keep all people happy I suggest the following:

a) Keep making changes in the code at will, independendly of any patch we might release, and include them in an archived file (development release archive) posted in a weekly basis, the way we're doing currently.

b) Release a patch (1.2) that will include fixes to known bugs and possibly very minor improvements and additions from the above mentioned archive (development release archive) but will not included further improvements and additions.

c) Release a second patch (1.3) that will include further improvements and additions or any newly discovered bug fixes from the archive (development release archive) and will be thoroughly tested.

d) Release an add-on, expansion set or completely new version (CtP3) with major improvements and additions and radical changes in concepts and the design itself, depending on the progress of the project and the size of the changes.

[SMIFFGIG]

I think the first patch(es) should also contain small new options like
being able to pick what colour you want to be
allowing more than 8 civs in a game (say 16)
having new option of Flat Maps

allowing an option to make use of the .ddl that makes climate zones around the map
and other small options ingame that are in the userprofile.txt etc (old ctp move style) or watever it is etc.

These are not gunna change the actual gameplay in anyway, but are simply basic options that should be accessable to the standard user

I dont wanna be Blue all the time
I dont wanna be only against a max of 8 civs
and i wanna play on flat maps with the temperate rings when i want

and im sure 99% of people dont wanna have to go editing files to get these small options

P.S. Goody huts should have more and/or changed images :P

-SMIFFGIG