 |
| |
|
|
Keygen
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
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!
|
|
| |
|
|
|
Keygen
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
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.
|
|
| |
|
| |
|
|
|
Keygen
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
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.
|
|
| |
|
|
|
Martin Gühmann
|
 |
Berlin, Germany
Mar 2001
time: 06:32
|
|
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
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
quote:
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
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
quote:
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
|
|
Berlin, Germany
Mar 2001
time: 06:32
|
|
quote:
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
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
quote:
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.
quote:
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.
|
|
| |
|
| |
|
|
|
Solver
|
|
Apolyton Duke Of Something
|
 |
Latvia, Riga
Sep 2000
time: 07:32
|
|
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.
|
|
| |
|
|
|
Keygen
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
quote:
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... 
|
|
| |
|
|
|
Keygen
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
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
|
|
Berlin, Germany
Mar 2001
time: 06:32
|
|
quote:
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. 
quote:
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
|
|
Lubbock, Tx USA
Jan 1970
time: 23:32
|
|
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.
|
|
| |
|
|
|
Keygen
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
quote:
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
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
quote:
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.
quote:
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
|
|
Athens, Hellas
Jan 2000
time: 07:32
|
|
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.
|
|
| |
|
| |
All times are GMT. The time now is 05:32.
Apolyton Time is 00:32. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
22-12-2003 06:53
.
|