A big question about SDK

[Rabbit, White]

Yes. But this is not news. Or at least it shouldn't be... People are expecting the weirdest thing from this SDK. I always knew it was a poorly chosen name (as did Soren), but I never figured it would be this bad...

But UI devkit? What were you expecting there? All the UI code is already right there in the Python folder, AFAIK Firaxis didn't use much in the way of external tools... Same for animation viewer, I know absolutely zero about graphics but I would assume 3D Max has all the animation viewers and other graphics tools you could ask for, that's what Firaxis used (presumably -- again, graphics n00b here).

You're right, SDK is a bad name for it if they were always going to release only the source code - to me software development kit implies a collection of tools .

As for the stuff that I mentioned. Well let's see, the Animation Viewer is something that comes with gamebryo actually (or at least it did in previous versions, though I doubt they removed it since). It allows to test (animation blending for example), tweak and change some properties of animations (event calls, attached sounds, etc.) without having to load up the object in 3ds max, and more importantly without having to re-export it if there were some small changes made.

As for UI devkit, well I came up with it myself. I was hoping for some kind of a visual tool for creating/modifying the interface, something like visual basic, or at the very least DesktopX (slap in some graphics, attach some scripts/functions, done). Obviously I was expecting too much and it's not a biggy but then I gotta wonder why it's taking so long to release it. There's only so much cleaning up and commenting that can be done to the code, at some point you just gotta stop and release it. Hint hint, wink wink

 

[PeteT]

I gotta wonder why it's taking so long to release it. There's only so much cleaning up and commenting that can be done to the code, at some point you just gotta stop and release it. Hint hint, wink wink

I think that this is because they're going to release the most up-to-date code, i.e. the code that is used in the forthcoming patch. Once this is out of the way, they can concentrate on the expansion.

 

[Kael]

You're right, SDK is a bad name for it if they were always going to release only the source code - to me software development kit implies a collection of tools .

As for the stuff that I mentioned. Well let's see, the Animation Viewer is something that comes with gamebryo actually (or at least it did in previous versions, though I doubt they removed it since). It allows to test (animation blending for example), tweak and change some properties of animations (event calls, attached sounds, etc.) without having to load up the object in 3ds max, and more importantly without having to re-export it if there were some small changes made.

As for UI devkit, well I came up with it myself. I was hoping for some kind of a visual tool for creating/modifying the interface, something like visual basic, or at the very least DesktopX (slap in some graphics, attach some scripts/functions, done). Obviously I was expecting too much and it's not a biggy but then I gotta wonder why it's taking so long to release it. There's only so much cleaning up and commenting that can be done to the code, at some point you just gotta stop and release it. Hint hint, wink wink

You can't release source code if you are making changes to it. If you put out a patch (which of course updates the source) you will break everything everyone has done.

Edit: You are to fast for me Pete!

 

[Locutus]

Well let's see, the Animation Viewer is something that comes with gamebryo actually

Then it's probably not something Firaxis could release, seeing how Gamebryo is proprietary and all...

I gotta wonder why it's taking so long to release it. There's only so much cleaning up and commenting that can be done to the code, at some point you just gotta stop and release it. Hint hint, wink wink

It's not going to be released seperately, it will be part of a very big patch, one that includes Pitboss as well, and a whole host of bugfixes and performance improvements and what not. The patch is done, but it's up to 2K Games to approve it for release. Big wheel turn slow...

 

[I_batman]

That's not quite true. Often a lot of code is easy enough to read, but just crappy in quality. For one thing, easy-to-read code usually means unoptimised code and reversely optimised code is usually unreadable. If on the scale of million lines of code you don't optimise at all, you probably take a big hit on performance. And let's face it, when it comes to performance, Civ4 isn't gonna win any awards (although a lot of that is probably not in the SDK but in the graphics engine). More importantly, memory leaks are in my experience the #1 cause of software problems, most C++ code is rife with them. Clarity of code by no means guarantees absence of memory leaks (although it does make it easier to track them down if you want to, but often it's more of a time/money issue than anything else).

True enough about optimisation.
I think most people still don't realize this all boils down to 1's and 0's eventually when the program is processed by the CPU.

As for the memory leak issue, that has indeed been done to death, and Harkonnen has clearly nailed the initial problem.
One can only hope that Firaxis has found and fixed some glaring spots of this, and the game runs cleaner with the next patch. I think in this case, trouble-shooting the code for such leaks may be worth their while.

 

[J_Period]

For one thing, easy-to-read code usually means unoptimised code and reversely optimised code is usually unreadable

You must be an old school programmer (or was taught by one!) Modern compilers optimize your code (removing comments, extra spaces, etc) before running it. So there is very very very little slowdown if you make your code easily understood. Thus, you should always comment your code as much as possible, so others can understand and modify it (something fireaxis programmers apparently haven't learned~ my teacher would take at least a letter grade off of their XML and Python code )

Code can be good and easy to read-it doesn't have to be one or the other.

 

[Kael]

You must be an old school programmer (or was taught by one!) Modern compilers optimize your code (removing comments, extra spaces, etc) before running it. So there is very very very little slowdown if you make your code easily understood. Thus, you should always comment your code as much as possible, so others can understand and modify it (something fireaxis programmers apparently haven't learned~ my teacher would take at least a letter grade off of their XML and Python code )

Code can be good and easy to read-it doesn't have to be one or the other.

I believe when he says "easy to read" he means writing functions in a way that they are easily readable to human brains, but not as efficient from a computer processing standpoint. In that case "optomized" is a lot more than just being without comments. For example it would be easier for a human to deal with one continuous function that sequentially performs checks and applies changes, but from a computer performance standpoint it may be better to break it up into multiple complex functions which handle a variety of calls.

Thats just an example (probably a bad one). I don't believe he is refering to commenting.

 

[Locutus]

As for the memory leak issue, that has indeed been done to death, and Harkonnen has clearly nailed the initial problem.
One can only hope that Firaxis has found and fixed some glaring spots of this, and the game runs cleaner with the next patch. I think in this case, trouble-shooting the code for such leaks may be worth their while.

Oh, even a program that's been patched to death will probably still have plenty of memory leaks. A fine example of this is the CtP2 source code: that was pretty good code to begin with (it had plenty of bugs but seemingly no memory issues), but even after 2.5 years of pretty dedicated bug hunting the people working on improving it are still finding memory leaks. Of course those people aren't full-time paid professionals, but it's exactly because of that that I suspect the CtP2 source code is one of the most thoroughly investigated pieces of commercial code in existance: there's no money at stake, so they can take as long as they want and be as thorough as they can be. And fixing all those memory leaks has been an enormous boost to performance (someone reported being able to run it smoothly on a system with half the min specs of the original game) and solved all kinds of other weird unexplainable crashes and other problems. There's no reason to assume CtP2 is fundamentally different from a lot of other commerical software. It's just bad coding habbits and discipline from programmers, mostly as a result of time/money pressure (I've been there).

You must be an old school programmer (or was taught by one!) Modern compilers optimize your code (removing comments, extra spaces, etc) before running it. So there is very very very little slowdown if you make your code easily understood. Thus, you should always comment your code as much as possible, so others can understand and modify it (something fireaxis programmers apparently haven't learned~ my teacher would take at least a letter grade off of their XML and Python code )

Yes, modern compilers are pretty kick-ass when it comes to optimisation. BTW, removing comments and whitespace does not qualify as optimisation, that's a standard part of the compile process (in fact it's the first step: lexing, in which the code is broken up into tokens, everything that's not whitespace or comment becomes a token). However, a compiler is just a piece of software and can only do so much. There's a lot to be gained by optimising manually. A very simple example (yes, I blatantly stole this from wikipedia, so sue me ):

int i, sum = 0;
for (i = 1; i <= N; i++)
  sum += i;
printf ("sum: %d\n", sum);

Can be optimised (assuming no overflow) as:

int sum = (N * (N+1)) / 2;
printf ("sum: %d\n", sum);

This uses less variables, so it needs less registers in the CPU (which a good compiler can sometimes figure out by itself), and it also removes the for-loop, which obviously for a large value of N could become very expensive. That is something a compiler usually can't do. Of course, the unoptimised code is readable by anyone who can program a little, it wouldn't really need any comments to explain what it does. But the optimised code only a math guru can figure out without without having to run tests on it or getting a big head ache, so you'd better explain in the comments that it prints the sum of all integers from 1 to N...

 

[J_Period]

I believe when he says "easy to read" he means writing functions in a way that they are easily readable to human brains, but not as efficient from a computer processing standpoint. In that case "optomized" is a lot more than just being without comments. For example it would be easier for a human to deal with one continuous function that sequentially performs checks and applies changes, but from a computer performance standpoint it may be better to break it up into multiple complex functions which handle a variety of calls.

Thats just an example (probably a bad one). I don't believe he is refering to commenting.

I see what you mean, like a "for" loop is easier to read than a "while" loop, but the "for" loop is more limited (or can be) I was just recalling a person I knew who was anal about putting as much code on one line as possible, because he was convinced that this would speed things up

But I think that properly commented code is should be easy to understand for anyone who has the slightest knowledge of how these things work. (TheLopez's code for example I can read really easily) I'm kinda really annoyed at the programmers who did the XML/Python cuz they pretty much left it all up to us to figure out. Not nice. (And before you say anything else, I'll admit I'm not the best commenter ~ but then again, my work isn't distributed to millions around the globe)

 

[I_batman]

Oh, even a program that's been patched to death will probably still have plenty of memory leaks. A fine example of this is the CtP2 source code: that was pretty good code to begin with (it had plenty of bugs but seemingly no memory issues), but even after 2.5 years of pretty dedicated bug hunting the people working on improving it are still finding memory leaks. Of course those people aren't full-time paid professionals, but it's exactly because of that that I suspect the CtP2 source code is one of the most thoroughly investigated pieces of commercial code in existance: there's no money at stake, so they can take as long as they want and be as thorough as they can be. And fixing all those memory leaks has been an enormous boost to performance (someone reported being able to run it smoothly on a system with half the min specs of the original game) and solved all kinds of other weird unexplainable crashes and other problems. There's no reason to assume CtP2 is fundamentally different from a lot of other commerical software. It's just bad coding habbits and discipline from programmers, mostly as a result of time/money pressure (I've been there).

It shall be interesting to see exactly how much source code we will be exposed to when the SDK (I agree, lousy name) come out.
It will also be a testament to the Civ crowd vs CtP crowd to see how fine the comb will be that the Civ crowd will use on the source code.

I really do expect amazing things overall to start appearing, assuming access is not severely limited. I also expect they will take 6-18 months to appear in polished form, once the SDK is released.
Of course, at the pace Firaxis' evil owner is moving with this release, computer technology will have evolved to the point that SkyNet will exist and we will all be dead or slaves, with no time to code Civ IV.