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

[Keygen]

As already known to people involved with the project we are currently working on a patch. However it is not clear what this patch should contain and what it shouldn't.

It will certainly includes bug fixes but in what extend are we going to handle improvements and especially new additions?

I beleive that we should keep improvements and new features to the minimum until we release a patch that will fix the bugs. I would even recommend we make no improvement at all and certainly add nothing new unless it requires a small change in the code and does not affect other parts of the code.

One of the greatest wishes of the ctp/ctp2 community was a patch that would fix the bugs and make the game more stable. So I recommend that we stick with it. After we implement this dream we can do what ever is possible, make improvements and add new features in what extend we like, always within our abilities.

Each thing in its time...

[Maquiladora]

Just fixes but theres no harm in discussing balancing issues for later too, an imbalance in gameplay can be called a bug sometimes too, like Tanks for example!

[Locutus]

I'm pretty sure we discussed this several times already, but anyway...

The first patch(es) should fix bugs, easy as that. Minor new features like new map types and stuff are fine, but no real changes to gameplay. Fix known bugs, improve stability and improve overall performance, but don't touch the game itself.

Opinions on gameplay changes can vary widely and we don't want to shove anything down anyone's throat. New features and real changes to gameplay should only be released in later updates and as far as they are already being developed tested and released seperately until then.

[Keygen]

Yes Locutus, it has been discussed before but it is time we pass from generalizations to specific ones. For example, should memory leak fixes be included in the patch or not? What minor improvement actually means? Perhaps a seemingly minor improvement prove to be not that innocent after all. We will surely need some expert opinion on this.

To avoid confusion I should say:

a) Any restriction that will be set here will only apply on what will be included in the first patch (1.2) and not on what people are permitted to change in general regarding the code.

b) There is no such thing as: "A bug is a bug in some cases and not in other". Either it is a bug or not. If something was designed that way thus imbalance some aspects and was coded according to the design then it is not a bug. It is poor design or more proper in the particular case Maquiladora mentioned regarding imbalances, unpredictable unless play test intensively.

[Solver]

Memory leaks, dialogs not displaying proper information, corrupted saves, and such are surely bugs .

[Keygen]

Memory leaks are not bugs. But it is insufficiency of the code. A part of the improvement would be fixing the memory leaks as well.

[Locutus]

Memory leaks can destabilize the system, increasing the chance of a crash, and are therefore a bug.

[Solver]

Memory leaks are not supposed to occur in the game by design, but they do - therefore they're bugs. Or, they're bugs by Loc's definiton, too...

[Martin Gühmann]

In my opinion we have to offer the player something new, it must be clear that more is in the game than in the original game. And therefore he must be able to use options that were actual already there, for instance you want to start a new game on a flat so just open the userprofile.txt and set XWrap and YWrap both to No or just set YWarp to Yes and you have Noth-South warp instead of West-East warp and you can already generate these kind of maps by the cheat editor. And what is wrong with it to give the player the posibility to use an interface instead of just editing the userprofile.txt just to play with more than 8 civs, the game allows 32 players on a map including the Barbarians, and in the unpatched game you can play against 30 other civs, at least these civs aren't called Barbarians in the standart game I didn't tried to save and reload such a game, it looks like they screwed something up in the patched version.

And for userinterface extensions I can always remove buttons by removing the according entries in the *ldl files.

I consider also stuff that was present in CTP1 and was removed without reason a bug, missing tile improvement sounds takes away from the atmospere of this game, if you use franchises and you can't see how much they give you as income is not very good either, a missing pollution graph is not good either.

So far we didn't change any rhules that we can't change via the text files, basicly we fixed bugs, and added some minor stuff here and there.

And of course if my CTP2 is sloed down or crashes, because it just uses a lot of memory that isn't actual used anymore then this is a bug.

-Martin

[Keygen]

Originally posted by Locutus

Memory leaks can destabilize the system, increasing the chance of a crash, and are therefore a bug.

Originally posted by Solver

Memory leaks are not supposed to occur in the game by design, but they do - therefore they're bugs.

Originally posted by Martin Gühmann

And of course if my CTP2 is sloed down or crashes, because it just uses a lot of memory that isn't actual used anymore then this is a bug.

I'm not pretty sure on that but I doubt designers would put effort on defining wich memory address each pointer or reference should point at. That would be the programmer's job. Pointers and references are simply tools for the programmers to implement the design the way they think it would work. If it does work, nomatter how good or bad it does it, it is not a bug. If it doesn't do its work or prevents other parts of the code from functioning properly then it is a bug.

Memory leaks are bounded with the size of memory. If I have plenty of memory available then memory leaks will give me no trouble at all. If I have few to no memory available then it could crash not only the game but the entire system as well. If certain calls reserve memory addresses that are not freed when not used anymore and as far as these memory leaks do not crash the game or the system in a machine that fullfils the minimum system requirements set by the developer, and the game is the only program running apart from the operating system and its services, then it will never be treated as a bug by a development team.

If an experienced team like the one that programmed the call to power series didn't fix these leaks probably because of time restrictions then we shouldn't rush things up. Let's play it safe and put only known bug fixes in the first patch and in the meanwhile we can work on new stuff and improvements in a second patch, in parallel.

[Keygen]

Originally posted by Martin Gühmann

In my opinion we have to offer the player something new, it must be clear that more is in the game than in the original game. And therefore he must be able to use options that were actual already there, for instance you want to start a new game on a flat so just open the userprofile.txt and set XWrap and YWrap both to No or just set YWarp to Yes and you have Noth-South warp instead of West-East warp and you can already generate these kind of maps by the cheat editor. And what is wrong with it to give the player the posibility to use an interface instead of just editing the userprofile.txt just to play with more than 8 civs, the game allows 32 players on a map including the Barbarians, and in the unpatched game you can play against 30 other civs, at least these civs aren't called Barbarians in the standart game I didn't tried to save and reload such a game, it looks like they screwed something up in the patched version.

And for userinterface extensions I can always remove buttons by removing the according entries in the *ldl files.

I consider also stuff that was present in CTP1 and was removed without reason a bug, missing tile improvement sounds takes away from the atmospere of this game, if you use franchises and you can't see how much they give you as income is not very good either, a missing pollution graph is not good either.

So far we didn't change any rhules that we can't change via the text files, basicly we fixed bugs, and added some minor stuff here and there.

Well, I partially agree with you. Actually I fully agree with you with the only exception focused on the way we would present all these changes to the people. I recommend a patch (1.2) with safe changes like bug fixes and a second patch (1.3) with improvements and additions. Nothing prevent us from working these two patches in parallel. Then we can proceed in more drastic changes. That way we keep all people happy, those that only want the bug fixes and those who want new stuff and abilities. Then we can proceed in more drastic changes. In the rate we move it would be very likely to have both patches before Easter.

Note: If we can manage to make minor improvements that will not risk more bugs then we could include them in the first patch as well.

[Martin Gühmann]

Originally posted by Keygen
Memory leaks are bounded with the size of memory. If I have plenty of memory available then memory leaks will give me no trouble at all. If I have few to no memory available then it could crash not only the game but the entire system as well. If certain calls reserve memory addresses that are not freed when not used anymore and as far as these memory leaks do not crash the game or the system in a machine that fullfils the minimum system requirements set by the developer, and the game is the only program running apart from the operating system and its services, then it will never be treated as a bug by a development team.

For memory leaks I should give an example: I know that there is a memory leak concerning creating and disbanding armies. I did this with slic very extensivly to make shure the AI has properly grouped stacks, the result was that in the middle of the game the AIs had usually created and disbanded more then 10000 armies or 60000 I don't know by grouping and ungrouping units. Finally the game crashed on my computer and for that game 256 MB Ram and a hude hard drive should be enough especially if you consider that this also happened on a small map with maybe 8 players maybe also 10 or 12. So we should take memory leaks as serious and incoorporate at least fixes we already have.

Originally posted by Keygen
I'm not pretty sure on that but I doubt designers would put effort on defining wich memory address each pointer or reference should point at. That would be the programmer's job. Pointers and references are simply tools for the programmers to implement the design the way they think it would work. If it does work, nomatter how good or bad it does it, it is not a bug. If it doesn't do its work or prevents other parts of the code from functioning properly then it is a bug.

That's right designers don't need to program, except they are programmers, too. There job is to design the program the programmers task is to implement the design. Of course as bug free as possible and no designer intends to implement crashes on purpose. But we have here an unfinished product so we don't actual know what was exactly intended what parts of the design where sacrified for brevity. We all have here of course our own ideas of the original intended design in my opinion some little things like a sound when a tile improvement is constructed or a pollution graph like in CTP1 belongs to it. And also a flat map was planned, I find some unused code for it and actual this is only an interface issure nothing else. The game was able to generate a flat map before.

-Martin

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

[Martin Gühmann]

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.

It is actual something unfinished that should be finished, maybe adding Human to Human Diplomacy to PBEM could be a little bit much, that might be the only reason why we don't do it immediatly, but adding the in game option to play with more then 8 players is much easier, because it is just an interface issure, maybe PBEM Human to human diplomacy is also just an interface issure, but could also be more complicated. And having the option to play with more then 8 players is also already in we alter our userprofile.txt since the release of CTP2 to play with more then 8 players.

-Martin

[Keygen]

Originally posted by Martin Gühmann

For memory leaks I should give an example: I know that there is a memory leak concerning creating and disbanding armies. I did this with slic very extensivly to make shure the AI has properly grouped stacks, the result was that in the middle of the game the AIs had usually created and disbanded more then 10000 armies or 60000 I don't know by grouping and ungrouping units. Finally the game crashed on my computer and for that game 256 MB Ram and a hude hard drive should be enough especially if you consider that this also happened on a small map with maybe 8 players maybe also 10 or 12. So we should take memory leaks as serious and incoorporate at least fixes we already have.

That particular case you mention is a bug but we can't be sure that all memory leaks would crash the game. Memory leaks on their own are not bugs. You define a bug from its result. What concerns me about fixing memory leaks is that we can't be 100% sure that the point where we will free the memory address is the last reference to it. At list that is the impression I got about memory leaks. I don't suggest we don't take them seriously or not fix them at all. What I suggest is we keep a patch clean of any change that might add more bugs with minimum exeption fixing the already known bugs. Then add all the rest changes we might have in mind to another patch wich will include all bug fixes made in the previous patch. Those two can be done in parallel, e.g. fixing bugs in patch 1.2 while making improvements and additions plus all the bug fixes of patch 1.2 to patch 1.3. We will simultaneously work in patch 1.2 and 1.3. The difference would be that we should give priority in patch 1.2 and finish it before 1.3. That way we can have bugs fixed in a relative small period while keep patch 1.3 longer so we can do more improvements in it.

Originally posted by Martin Gühmann

That's right designers don't need to program, except they are programmers, too. There job is to design the program the programmers task is to implement the design. Of course as bug free as possible and no designer intends to implement crashes on purpose. But we have here an unfinished product so we don't actual know what was exactly intended what parts of the design where sacrified for brevity. We all have here of course our own ideas of the original intended design in my opinion some little things like a sound when a tile improvement is constructed or a pollution graph like in CTP1 belongs to it. And also a flat map was planned, I find some unused code for it and actual this is only an interface issure nothing else. The game was able to generate a flat map before.

-Martin

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.