PROJECT: Source Code: Project Team

[Peter Triggs]

Thanks, Pyaray. I've been looking at SDL and find it really frustrating (and it's supposed to be easier than DirectX !). It's good to know that those of us who have been working with SLIC will have something to get hold of.

[Keygen]

Originally posted by Martin the Dane

My point was not to discuss the coding strategy used in CTP2 (I have not seen enough code to discuss that), but to suggest that the analyzing starts in kode that produces known output from known input.

Do you know which code would that be in CtP2 or speaking in general?

[Keygen]

Originally posted by WesW

I hope the optimists here are right about the structure and neatness of the code, but I would be somewhat surprised there.

I think the optimism was refering to the way that might had been used to name functions, classes, variables and others, not the structure and neatness of the code. And if I judge from Don's comments you included here and Pyaray's post we're probably going to have hard time with it

[Keygen]

Originally posted by Pyaray

When I worked in aerospace, the mission critical code got developed at a rate of about 1 line of code per hour. In the game industry, it's several hundred times that.

I've been on both ends of the spectrum, where getting it "perfect" was more important than getting it done. That's not how it works in the game industry. If it were, games would be bug free, but costs hundreds, or thousands, of dollars per copy, and take a decade to develop.

When I was in aerospace the largest program I ever worked on was 2 million lines of code. It took a team of 20 people 7 years to write it. And I assure you, it cost more than any game that has ever been written.

Pyaray, I am not sure if there is such program with hundred thousands lines of code that is bug free but yes, the more you work on it the less you will have for sure.

I can understand the timelines set in game industry though I get my hat off to gaming companies like Blizzard who can take up to 2-3 years to release a game in the best shape possible in an industry like that.

Only if there was a post-production support of games like CtP lasting for 2-3 years and a well organized QA system they could have a nearly bug free game patched.

[Martin the Dane]

Originally posted by Keygen

Do you know which code would that be in CtP2 or speaking in general?

I was speaking in general, but by the time the CTP2 code is released, we do have a few cases:

First we have the tile-related stuff. Martin and I (with the help of others) got most of that figured out. - Not the code, but the graphics part.

Secondly we have the sprite stuff, I have almost nailed that down. Getting the rest of that done should not be all that difficult, but it does take some time. Someone with a little more C/C++ knowledge than me, should be able to document that code using my notes and the comments in the released parts of sprite generator code. (CTPSpriteTool documentation)

The rest of the graphics stuff might not be to hard to figure out, since much of it is known from the tile- and sprite-format.

Finally there might be parts of the slic interpreter that some of the slic-people can figure out, but that's pure speculation

But yes I was speaking in general, so figuring out input-output is IMO a good start.

Martin

[Keygen]

Good point

And I guess some people will have some experience with the AI as well.

[Pedrunn]

Finally there might be parts of the slic interpreter that some of the slic-people can figure out,

You can count me in for this!

[kaan]

Hi folks

Im pretty sure that some of you guys still remember me so cheers to you all.

Well, im not going to make any big promise here, but if the source is released im definetly back on the CTP2 scene for good, this is too good to be true.

oh btw, i code in C++ so ill be glad to help out if it becomes relevant.

klaus

[Martin Gühmann]

It looks rather that the code is structured into lots of files, if you open the ctp2.exe with a text editor and searches for .cpp you will find 40 names of *.cpp files. And I don't think that are all files, if you read the description of the winner's file of Loki's Call to Hack contest, you will also find a bunch of other files like:

radarmap.cpp
turncount.cpp
global_enums.h
controlpanelwindow.cpp
controlpanelwindow.h
buttonbank.ldl
buttonbank.cpp
selitem.cpp
unitdata.h
unitdata.cpp
army.h
army.cpp
armydata.h
armydata.cpp
unitrec.h
unitrec.cpp
selitem.h
diplomacy_log.cpp
order.cpp
unit.h
unit.cpp
unitdata.h
unitdata.cpp
citydata.h
citydata.cpp
unseencell.h
tiledmap.h
tiledraw.cpp
armydata.cpp
allinonewindow.cpp
allinonewindow.h
ns_gamesetup.h
ns_gamesetup.cpp
profiledb.cpp

I think at least some of these files will appear in CTP2 source code again of course altered but not unused. And this list of files also suggests that there are also counterparts of the text files, too. So I am optimistic that there is something to start with.

-Martin

[st_swithin]

"You can either add features and add bugs or you can fix bugs and lose features. That's how programming works." -Joe B. Rumsey, aka MrOgre

[Keygen]

Originally posted by Pedrunn

You can count me in for this!

Originally posted by kaan

Hi folks

Im pretty sure that some of you guys still remember me so cheers to you all.

Well, im not going to make any big promise here, but if the source is released im definetly back on the CTP2 scene for good, this is too good to be true.

oh btw, i code in C++ so ill be glad to help out if it becomes relevant.

klaus

Any help, small or big would be great

[Keygen]

Originally posted by st_swithin

"You can either add features and add bugs or you can fix bugs and lose features. That's how programming works." -Joe B. Rumsey, aka MrOgre

Unavoidably true

You fix bugs, then you add features, then you fix bugs again, then... and so on. Isn't that the way it always works?

Unless of cource we are talking about adventures or console games.

[Leland]

Originally posted by st_swithin
"You can either add features and add bugs or you can fix bugs and lose features. That's how programming works." -Joe B. Rumsey, aka MrOgre

This only applies if either

A) you have a deadline to meet, or
B) you're incompetent.

[Pyaray]

Q: If the act of removing bugs is called debuging, what is the act of adding bugs called?

A: Programming.

Pyaray

[WesW]

I don't want to start a new debate, but just so everyone knows- Don was then a 41yo who ran his own, quite successful computer sales, service and consulting business, and had probably been involved in programming since the late 70's. The quotes were from a private email he sent to me, and perhaps the other two people in our AI-testing group. He was/is a very nice and polite man, and certainly not given to bombastic statements. I am certain from his overall comments, if not the parts I can remember, that he was quite experienced with game source code and what it normally looked like.
From my experiences with Richard Myers, and things like Winnnie's interview, I don't think anyone can say that the programmers didn't do the best job they possibly could given the constraints placed upon them. My purpose with the post was only to try and prepare people for what they may encounter when they start to try to understand the code.

I would like to add to the debate here that additional reasons to concentrate on debugging rather than enhancements or additions is that, if they can manage to implement some of the game's unused triggers, they will potentially enhance the game greatly. Also, some of the existing bugs or unused code could well keep new code from working properly.

Finally, I sincerely hope that Ray, Winnie and perhaps Joe will be here to help with understanding the code and to explain the general techniques and logic used for things such as trigger names. Their help could speed up the work by weeks or more.