Jump to content

Subtle differences with XCOM 1?


Slythe

Recommended Posts

I guess they wanted the dye grenade to simulate the dye spreading outward in the water rather than have it start off with a dense cloud. I wonder if the fact that the particles get weaker as they disperse was ever accounted for?

 

By the way, it's often said that a pulser provides a better immediate screen, but has this ever been confirmed?

 

The more we learn about TFTD, the more it's starting to look less like a re-skin of UFO. Much of it is still the same, but lot of fiddling has definitely gone on.

 

- NKF

Link to comment
Share on other sites

TFTD actually does have two different particle sets, the new one being appended to the SMOKE archive. It's denser and has a sort of greeny-yellow tint to it. I never got around to working out under which circumstances it was used, but once you've seen the two sets side by side it shouldn't be too hard to tell them apart in battle

Well I'll be darned! Do you think you could extract those images so we can have a look? Now we have to find out where the underwater/on land code is located in the exe to fix the particle types. :)

 

Nice fix Zombie, It would have been better if there was a file to download in the files section! :D

(Just been there, but it says there is no file to download)

Sorry Thunder_Gr, with the recent server move we did at StrategyCore some of the permissions were messing with uploads. It should be sorted now though. Check again. :)

 

I guess they wanted the dye grenade to simulate the dye spreading outward in the water rather than have it start off with a dense cloud. I wonder if the fact that the particles get weaker as they disperse was ever accounted for?

 

By the way, it's often said that a pulser provides a better immediate screen, but has this ever been confirmed?

 

The more we learn about TFTD, the more it's starting to look less like a re-skin of UFO. Much of it is still the same, but lot of fiddling has definitely gone on.

See, that's what I was trying to get at: I doubt the programmers/developers took the thinning of the cloud into consideration if they made the power 10 on purpose. Otherwise they would have realized that they would need to completely rewrite the spreading code to curtail the size increase both initially and in later rounds and yet keep the density code the same. :laugh: Funny thing is, in real life, a Dye Grenade wouldn't really work at depth. There are no waves down there to spread it around and most oceanic currents are too sluggish to propagate the dye anywhere but in a long sinuous ribbon. The only thing which might help are the eddies created from passing fish or possibly bubbles.

 

Grenades such as the Sonic Pulser do provide a larger initial cloud of smoke than the Dye Grenade. However, the particle density within each tile is low which makes it less effective than a similarly sized cloud produced from a DG. Might work in a pinch, but I prefer my fix more. LOL

 

Aye, I completely agree with you there NKF. I've tried to maintain that TFTD isn't the same as EU. There are a lot of tweaks and changes made to it. Unfortunately, the actual application of these tweaks were not thought out much and thus created lots of bugs. I suppose this is the biggest difference between the two, though EU has it's share of them too. :D

 

- Zombie

Link to comment
Share on other sites

Thanks Zombie, I hope you din't mind the little tease..

As for the DG, I think they should work at depth, just like the squid's ink.

The initial release force is what makes the ink spread, not the current or the waves.

 

And, of course, TFTD is diffirent in many aspects from the UFO-EU. Everyone can see that, except for those that purposingly want to bash the company.

Link to comment
Share on other sites

Yeah? Well I've recreated a decent part of the game engine, it looks pretty similar to me. Just lowering the power of the dye grenade fails to impress me. :laugh:

 

Nor does the fact that they changed pretty much all the fonts to one colour and reused a bunch of backscreens by taking advantage of the fact that they look quite different under TFTD's palette (though certainly not different in a "good" way).

 

The many bugs don't count as "positive changes", either. Keeping in mind that in my mind, all the changes they made to the tech tree system should count as bugs, not just the ones that really didn't work.

 

That said, the map/graphic designers had their work cut out for them. They did a marvelous job. That game has so many individual sprites it's just not funny, and when you consider how much data gets attached to those sprites (eg the 3D models)... Phewee. Of course, it's still the exact same "system" as in UFO, but the amount of work it must've been to create all that tile data...

 

See, the amount of "real new stuff" in terms of "game engine code" that I can think of consists of larger map support, working melee weapons (as opposed to the hard-coded stun rod of the original), and a few extra bytes in the unit tables that I don't even know what they do...

 

Kinda got busy today and never got around to grabbing those images. I'll post 'em tomorrow. Use PCKView if you like.

Link to comment
Share on other sites

Yeah? Well I've recreated a decent part of the game engine, it looks pretty similar to me. Just lowering the power of the dye grenade fails to impress me. :laugh:

 

Nor does the fact that they changed pretty much all the fonts to one colour and reused a bunch of backscreens by taking advantage of the fact that they look quite different under TFTD's palette (though certainly not different in a "good" way).

 

The many bugs don't count as "positive changes", either. Keeping in mind that in my mind, all the changes they made to the tech tree system should count as bugs, not just the ones that really didn't work.

 

Hmmm, you seem to be in a sarcastic mood today...

 

That said, the map/graphic designers had their work cut out for them. They did a marvelous job. That game has so many individual sprites it's just not funny, and when you consider how much data gets attached to those sprites (eg the 3D models)... Phewee. Of course, it's still the exact same "system" as in UFO, but the amount of work it must've been to create all that tile data...

 

At lest the artist department gets their credits :D

 

See, the amount of "real new stuff" in terms of "game engine code" that I can think of consists of larger map support, working melee weapons (as opposed to the hard-coded stun rod of the original), and a few extra bytes in the unit tables that I don't even know what they do...

 

Well, i guess the uniqness of the aquatic environment and the adaptation of a great portion of the code to it does not really count.

In addition, the ability to have two-stage missions is also something that needed to work for.

 

Keeping the same mechanics as the first game was not really a downside from my point of view, because this is what was really liked by the people(and that Apocalypse failed to keep).

 

What was really a downside, from my point of view, is that I was expecting to begin with some of the knowledge of the previous war. I expected to start with laser weapons, even if only for surface use(assuming they were not suitable for underwater environments). I, expected to start with some kind of armor this time, even if only for surface use.

And similar things. I also expected that, this time, there would have been no bugs(after all, a great deal of the code was already there).

So, what I am saying is that, even though the game is similar to the first, it has its unique aspects. Not that it couldn't have been better :D

Link to comment
Share on other sites

Hmmm, you seem to be in a sarcastic mood today...

I'm always in a sarcastic "mood". In fact I spend most of my time biting my tongue.

 

But I assure you, none of that was "sarcastic".

 

At lest the artist department gets their credits :laugh:

Yeah, 'cause they did at least half of the work. Them and the map designers would probably account for about 90% of TFTD's development, maybe more.

 

Well, i guess the uniqness of the aquatic environment and the adaptation of a great portion of the code to it does not really count.

Correct. It doesn't. All that involved was the addition of a few extra palettes (art department), and making it so that certain guns wouldn't work if the depth flag happened to be set to "on land". Oh, and the ANNOYING bit about stopping you from intercepting USOs over land.

 

I'm not sure what "great portion of code" you're referring to.

 

In addition, the ability to have two-stage missions is also something that needed to work for.

Nope. Ripped directly from UFO, that was, and believe me when I say we're talking very simple code. Only they did a half assed job of it and had to release a patch to make it work properly.

 

(The half-assed approach worked fine in UFO 'cause the only two stage mission was the very last one. Whether you won or lost, the game ended afterwards, so what happened to the loot from the first half didn't matter).

 

Keeping the same mechanics as the first game was not really a downside from my point of view, because this is what was really liked by the people(and that Apocalypse failed to keep).

I'm not calling that a downside. But you can hardly credit Microprose's people for work that was done by Mythos.

 

(Keeping in mind that Mythos made UFO and Apocalypse, but apparently did not work on TFTD. Though Drewid's posts, and the art style, make me think that at least some of the developers must've been the same people despite this - If you read this, Drewid, I'd find any clarifications on the matter quite interesting!).

 

What was really a downside, from my point of view, is that I was expecting to begin with some of the knowledge of the previous war. I expected to start with laser weapons, even if only for surface use(assuming they were not suitable for underwater environments). I, expected to start with some kind of armor this time, even if only for surface use.

Granted this doesn't "make sense" from a story perspective, but I can forgive them this on the basis that the game would just be far, far too easy (and hence boring) if you still had your lasers and alien alloys to play with.

 

(But still, guess to what extent the object definition tables were extended in TFTD - Yeah, that's right. They weren't. A few gaps were plugged and that was it).

Link to comment
Share on other sites

Now, about that Microproce - Mythos issue... Which I guess is the real thing behind the non-uniqueness of TFTD arguments:

 

Of cource Mythos did the hard work for creating the Original game. And it is that work that was credited in TFTD, also. The game machine is the same, just the game is enhanced in many ways, making game experience better(well, if you don't count the bugs).

 

The lasers could have been made to have the same effect like those "dart guns", or perhaps a little better, since these are "different aliens" and the lasers wouldn't have "that much effect on them". There are many ways to make a story look good and keep the balancing of the game...

 

Anyway. Mythos did a good work, but it was a pitty that apocalypse lacked many things from the original game. I wish someday, some company, will decide that a sequel should be an echanting experience of the original, not a cut-off of it.

On this prespective the UFO-AS was nice(although they practically crippled the Tactical movement of the units, which was great in the UFO-AM, and cutted the fighter interception, but in a story fitting way), while UFO-AL was a cut-off of UFO-AS, just to make a "unique" mechanic...

 

I hope you understand what I mean.

Link to comment
Share on other sites

Thanks BB. The dye particle set is at the end, correct? :laugh:

 

What was really a downside, from my point of view, is that I was expecting to begin with some of the knowledge of the previous war. I expected to start with laser weapons, even if only for surface use(assuming they were not suitable for underwater environments). I, expected to start with some kind of armor this time, even if only for surface use.

And similar things. I also expected that, this time, there would have been no bugs(after all, a great deal of the code was already there).

So, what I am saying is that, even though the game is similar to the first, it has its unique aspects. Not that it couldn't have been better :D

The other day I received 11 issues of Computer Gaming World magazine from 1995. In one of the issues, the author mentioned the exact same things you did (lasers, armor not carrying over). So it's nothing new, and I'd guess we would all still hope that eventually a UFO/TFTD remake would be made to tie everything together properly. The quick turnaround time for TFTD probably prevented the producer and programmers from developing the storyline completely. :)

 

On another note, I was looking at those magazine back issues and noticed MicroProse advertised heavily leading up to TFTDs release. After that, it advertised other games. So you can see how interested they were in pushing TFTD. That was in spite of the positive reviews too. You just have to wonder how big the game could have got if MicroProse put it's full support behind TFTD and the X-COM series. :D

 

- Zombie

Link to comment
Share on other sites

Thanks BB. The dye particle set is at the end, correct? :laugh:

No idea. For all I know, only one of those animation sets are actually used in the game. I simply haven't bothered to check. All I know is that there are two of 'em in the file.

 

Note that sprites 56-67 in TFTD's "smoke" file are the same as 8-19 in the UFO file, and graphics in TFTD change colour depending on what depth you're at (the examples I posted are above sea level).

Link to comment
Share on other sites

The other day I received 11 issues of Computer Gaming World magazine from 1995. In one of the issues, the author mentioned the exact same things you did (lasers, armor not carrying over). So it's nothing new, and I'd guess we would all still hope that eventually a UFO/TFTD remake would be made to tie everything together properly. The quick turnaround time for TFTD probably prevented the producer and programmers from developing the storyline completely. :D

 

Now, as BB already pointed out, most of the code was already in place. It would need less than a day to come up with a nice follow up. It would need less than half a day to correct certain issues that never bothered to do it. So, I find it difficult to believe it was so much time-consuming. Besides, XCOM-EU had the art for the carryovers ready..Anyway, it isn't really anything new, although I haven;t read that magazine. It is just my feelings on the issue...

 

On another note, I was looking at those magazine back issues and noticed MicroProse advertised heavily leading up to TFTDs release. After that, it advertised other games. So you can see how interested they were in pushing TFTD. That was in spite of the positive reviews too. You just have to wonder how big the game could have got if MicroProse put it's full support behind TFTD and the X-COM series. :laugh:

 

- Zombie

 

Now,now, if this can be true about TFTD, what to say about Apoclypse? No lack of time or lack of support. Mythos clearly stated that they started working on it at the same time Microproce decided to work on TFTD, and they released quite a few years later....

 

In addition, they did have patch 2.0/2.1 released, which fixed none of the so-easy-to-fix-when-you-have-the-source-code issues. They did not even bother to add an encoumberance indicator on the soldier equipment screen FGS!

Link to comment
Share on other sites

Now, as BB already pointed out, most of the code was already in place. It would need less than a day to come up with a nice follow up. It would need less than half a day to correct certain issues that never bothered to do it. So, I find it difficult to believe it was so much time-consuming. Besides, XCOM-EU had the art for the carryovers ready..Anyway, it isn't really anything new, although I haven;t read that magazine. It is just my feelings on the issue...

I think it would entail little more than a half a day. (Heck, most people really don't get moving till 2 in the afternoon). :D Just remember that adding laser weapons to the game would mean the programmers would need to expand the size of obdata.dat to accept them. (UFO had some unused slots so this would have been possible, but TFTD used those slots for the blades and the ammo for the Gauss weapons). Adding another armor set would again require more entries into obdata.dat for the corpses. Then they would need to add the stats to the exe, program the suit to only work on land missions and possibly some code to swap armor types automatically. So it's not quite as simple as most would believe (and I probably only glossed over the work involved). Surely the bugs could have been fixed though. The TFTD team should have known about the ones in EU to have worked out a fix for some of the problems and applied them to TFTD. Then again, look what they did to the issue of mind controlling large units... it's worse than it was before! :laugh:

 

Now,now, if this can be true about TFTD, what to say about Apoclypse? No lack of time or lack of support. Mythos clearly stated that they started working on it at the same time Microproce decided to work on TFTD, and they released quite a few years later...

Well, they were splitting their resources between two games at the time which I think was a huge mistake. Not only did they screw up TFTD but they also managed to make the TB option in Apoc nearly unplayable (beside the myriad of other issues). So they were not focusing their efforts on the task at hand, and instead zeroed in on capitalizing on UFOs good fortune. This lead to two rather lackluster titles instead of one great one. I really believe that with the right combination of leadership, focus for details, dedication to quality (and of course some more time), that the TFTD team could have made this a superb game worthy of the X-COM title. Don't get me wrong TFTD is a good game, but it could have been so much better. :D

 

- Zombie

Link to comment
Share on other sites

I think it would entail little more than a half a day. (Heck, most people really don't get moving till 2 in the afternoon). :D

 

Now, that explains many things! I can now see the lack-of-time issue... :laugh:

 

Just remember that adding laser weapons to the game would mean the programmers would need to expand the size of obdata.dat to accept them. (UFO had some unused slots so this would have been possible, but TFTD used those slots for the blades and the ammo for the Gauss weapons).

Well, now. Having a data file to be fixed size is bad programming tactics anyways. It would have helped them improve their data managing code. Even without it, "expanding" is just "adding more records". Since they were using a DOS-Extender they had no memory limiting issues.

 

Adding another armor set would again require more entries into obdata.dat for the corpses.

So? What is so difficult about it?

 

Then they would need to add the stats to the exe, program the suit to only work on land missions and possibly some code to swap armor types automatically. So it's not quite as simple as most would believe (and I probably only glossed over the work involved).

 

Having stats in the .exe is a headache, anyway. They shouldn't rely on it in the first place.

But, again, I cant see how a copy-paste from another armor type and editing of the stats would be more than 2 minutes work...Can you?

 

In addition, they did not include automatic substitute of weapons or anything similar. A simple check for any surface-only equipment used in subwater missions and vice-versa would have been nice. I would really like a message "your troops carry equipment not suitable for the mission. Lauch anyway?", when I have that Torpedo-tank included for a surface mission. But, of course, no matter how simple it is to do it, it was never included....

 

The suit wouldn't have to be "programmed" to work on land-only. It would have a land-only flag and it souldn't allow you to take it on sub-water missions. Very simple really. One loop block iterating the assigned aquanauts with an if statement to show the message that the equipment is not allowed, and return the call. Or, if they wanted to be mean enough, use the if to replace the armor with "none", and say nothing. Not so much of a work, now...Is it?

 

Surely the bugs could have been fixed though. The TFTD team should have known about the ones in EU to have worked out a fix for some of the problems and applied them to TFTD. Then again, look what they did to the issue of mind controlling large units... it's worse than it was before! :D

 

Again so easy to fix when you have the source code and they didn't fix it in 2.0! It is as simple as checking in the mind-control function if the target is a large unit, and, if it is, have the attack take place on the top-left quarter instead. It is just an if statement block checking a byte and moving the pointer. Things like that don't take more than 5 minutes(testing and debugging included).

 

Well, they were splitting their resources between two games at the time which I think was a huge mistake. Not only did they screw up TFTD but they also managed to make the TB option in Apoc nearly unplayable (beside the myriad of other issues). So they were not focusing their efforts on the task at hand, and instead zeroed in on capitalizing on UFOs good fortune. This lead to two rather lackluster titles instead of one great one. I really believe that with the right combination of leadership, focus for details, dedication to quality (and of course some more time), that the TFTD team could have made this a superb game worthy of the X-COM title. Don't get me wrong TFTD is a good game, but it could have been so much better. :)

 

- Zombie

 

Mythos stated they did not take part in the development of TFTD...but some say some programmers did...Anyway, It is sad that TFTD is not what it could have been, but even sadder the fact that Apocalypse came out a worst game when it had to be an enhanting experience.

 

What is even more sad, is that they still keep the source code without improving it and releasing a patch, and I cannot make TFTD what it should have been myself! :)

It would be so easy with so much hard work already done, that it drives me crasy, sometimes...

Link to comment
Share on other sites

TFTD was done in-house if I remember correctly, while Mythos worked on Apocalypse. Probably some crossover with the people involved.

 

Apocalypse, though not the masterpiece everyone wishes it to be, still turned out pretty playable and does have its moments. Could be better. Definitely all the games could be improved in many ways. Yet why is it we still enjoy them so much? That's the secret ingredient that I think a lot of games just don't have anymore.

 

Well, now. Having a data file to be fixed size is bad programming tactics anyways. It would have helped them improve their data managing code. Even without it, "expanding" is just "adding more records". Since they were using a DOS-Extender they had no memory limiting issues.

 

Well, they could've, but developer PCs were generally monsters compared to your basic home PCs. The target PC (at the time) probably only had 4Mb or RAM to play with, so adding everything else in (and what was used by the OS. Then there were those foolish enough to run it through Windows 3.11 (or lesser)), then you wouldn't have a heck of a lot to play with. Lots of additions here and there would also stack up.

 

None of this is relevant today - with gigabytes of memory and processing power at our fingertips.

 

On slightly less related note: UFO's target PC was a 386 (and even worked on an 80286!), they upped it to a 486 for TFTD, but that was woefully under specs by my reckoning - at least my 486 really struggled with it. Plenty of sandwich breaks. :laugh:

 

 

 

Adding another armor set would again require more entries into obdata.dat for the corpses.

 

So? What is so difficult about it?

 

Not too much. But let's see.

 

1 extra set of sprites for the armour (a whole man_x.pck/tdxcomx.pck). 1 extra corpse. A few extra lines in obdata.dat for corpse information. Another screen for the ufopaedia image. 1 extra image for the inventory screen. Extra text entries for the description in the ufopaedia file. Some extra lines in the buy/sell screen to accomodate it. One extra entry into the damage modifier table (unless they cheat and share the same stats as another unit). If manufactured or researched, extra lines in their respective files. Some code would have to be thrown in to handle whether it can be worn underwater or what (if any) abilities are disabled.

 

If we threw in the flying variant, a lot of the above can be reused.

 

The new graphics would've probably have been the most time consuming part - unless you just recycled the UFO graphics, maybe with an extra snorkel or iron lung. Have to address the whole alien alloys melting in sea water bit though in the ufopaedia text.

 

Having stats in the .exe is a headache, anyway. They shouldn't rely on it in the first place.

But, again, I cant see how a copy-paste from another armor type and editing of the stats would be more than 2 minutes work...Can you?

 

Agreed there - though they never intended the game to be modded, so hard coding stats right into the exe is the easiest (if not most robust) way to approach it. I guess most of the external data files that we got were files they tweaked a lot, while those that got hard coded into the executable remained fairly constant.

 

- NKF

Link to comment
Share on other sites

TFTD was done in-house if I remember correctly, while Mythos worked on Apocalypse. Probably some crossover with the people involved.

 

Apocalypse, though not the masterpiece everyone wishes it to be, still turned out pretty playable and does have its moments. Could be better. Definitely all the games could be improved in many ways. Yet why is it we still enjoy them so much? That's the secret ingredient that I think a lot of games just don't have anymore.

 

Certainly this. However, although I did buy apocalypse and play it until completion, I never felt the urge to reply it the way I do for the EU and TFTD. Too many elements lacks, many twisted badly, the few improvements never made up for the rest that were sacrificed on the altar of "a different game"...

 

Well, they could've, but developer PCs were generally monsters compared to your basic home PCs. The target PC (at the time) probably only had 4Mb or RAM to play with, so adding everything else in (and what was used by the OS. Then there were those foolish enough to run it through Windows 3.11 (or lesser)), then you wouldn't have a heck of a lot to play with. Lots of additions here and there would also stack up.

 

None of this is relevant today - with gigabytes of memory and processing power at our fingertips.

 

On slightly less related note: UFO's target PC was a 386 (and even worked on an 80286!), they upped it to a 486 for TFTD, but that was woefully under specs by my reckoning - at least my 486 really struggled with it. Plenty of sandwich breaks. :laugh:

 

I know, I had bought it then, and played it on a 386 with the huge amount of 4MB RAM. The changes needed/discussed are not CPU or Memory Intensive. So, a few more data records do not effect game speed in any way, although they do effect memory consumption if you load them all at once in memory. However, since not all equipment/all Aliens are used in each mission, they shouldn't need to stuff up the memory with the complete file(as they do now) and still include the few things required to get TFTD consistent, bug free and less cryptic(Namely, I have to mentaly calculate the strength/equipment weight relation in order to figuer out if my soldier will be encoumbered or not. Obsurd things like unconsious aquanauts reported MIA at the end of a mission even if won or in the XCOM craft etc etc)

 

And those that wished to run it through windows <=V3.xx, should have been warned in the game's box, not to!(i.e. a fat text reading "NOT COMPATIBLE WITH WINDOWS")

 

Not too much. But let's see.

 

1 extra set of sprites for the armour (a whole man_x.pck/tdxcomx.pck). 1 extra corpse. A few extra lines in obdata.dat for corpse information. Another screen for the ufopaedia image. 1 extra image for the inventory screen. Extra text entries for the description in the ufopaedia file. Some extra lines in the buy/sell screen to accomodate it. One extra entry into the damage modifier table (unless they cheat and share the same stats as another unit). If manufactured or researched, extra lines in their respective files. Some code would have to be thrown in to handle whether it can be worn underwater or what (if any) abilities are disabled.

 

If we threw in the flying variant, a lot of the above can be reused.

 

The new graphics would've probably have been the most time consuming part - unless you just recycled the UFO graphics, maybe with an extra snorkel or iron lung. Have to address the whole alien alloys melting in sea water bit though in the ufopaedia text.

 

The initial discussion is about having included a starting armor and I said "even if only for surface use". So, not researchable, but manufacturable. The amount of code needed I already described in my previous post. The art would have been a recycle of the EU art, so nothing time-consuming or difficult here.

It could have been easily done, in less than a day's work in order to come out with a nice follow-up set-up from the first game. I still think that. Everything was practicaly ready. And the code that should have been written, very easy and required even without these items. Again, just starting the mission and discovering that you have forgotten that Torpedo tank on a surface mission is...well...disapointing.

 

Agreed there - though they never intended the game to be modded, so hard coding stats right into the exe is the easiest (if not most robust) way to approach it. I guess most of the external data files that we got were files they tweaked a lot, while those that got hard coded into the executable remained fairly constant.

 

- NKF

 

I have to disagree with you on the "easiest" and "most robbust" parts.

Hard-coded data should always be avoided, regardless of the intention for the game to be modable or not. It is hard to maintain, hard to correct and hard to expand. All in All, it is just "bad". In addition, having data mixed with code is, at least, annoying from a programming perspective.

The difference between a "modable" and "non-modable" game is regarding the Data structure itself, not the data values. Thus, I never said TFTD should have had the data structures taken from an external file(like Civ4 and-in some extend- UFO-After* series), I said that the database should have been kept at an external file, and that they should have implemented the structures as linkedlists instead of Arrays, so that it should be easier to expand/correct/maintain.

It is much more difficult to start the compiler IDE and search through the code files to find the value for the e.g. personal armor, correct it, then recompile the .exe, in order to just balance the front armor value, than it is to open a text file, find the armor entry, change it, finish...

 

Assuming that a data value/list of values will remain constant is "bad thinking". A programmer should always assume every bit of data/data list length will change at some point after release, and program with this in mind.

Of course, this is common practice these days, did not think that way 15 years ago, still, they were professional programmers, so, still, they should have done it that way, IMO.

Link to comment
Share on other sites

I have to disagree with you on the "easiest" and "most robbust" parts.

Hard-coded data should always be avoided, regardless of the intention for the game to be modable or not. It is hard to maintain, hard to correct and hard to expand. All in All, it is just "bad". In addition, having data mixed with code is, at least, annoying from a programming perspective.

The difference between a "modable" and "non-modable" game is regarding the Data structure itself, not the data values. Thus, I never said TFTD should have had the data structures taken from an external file(like Civ4 and-in some extend- UFO-After* series), I said that the database should have been kept at an external file, and that they should have implemented the structures as linkedlists instead of Arrays, so that it should be easier to expand/correct/maintain.

It is much more difficult to start the compiler IDE and search through the code files to find the value for the e.g. personal armor, correct it, then recompile the .exe, in order to just balance the front armor value, than it is to open a text file, find the armor entry, change it, finish...

 

Assuming that a data value/list of values will remain constant is "bad thinking". A programmer should always assume every bit of data/data list length will change at some point after release, and program with this in mind.

Of course, this is common practice these days, did not think that way 15 years ago, still, they were professional programmers, so, still, they should have done it that way, IMO.

 

 

Heh, hold a second there. You've just misinterpreted me and have repeated what I was trying to say in just a few short words. I never said it was good practice! :laugh:

 

The easiest part here about hard coded the data is that it required little effort to implement. Just throw in a value into the code and be done with it. Since little had to be changed, they just left it in there. Maintaining it is where it lacks in robustness. It would be a terror to trawl through the code to look for some constant you set (unless they declared all of them at the top of source - again not something I like very much myself, but certainly the simplest way of doing things).

 

- NKF

Link to comment
Share on other sites

Heh, hold a second there. You've just misinterpreted me and have repeated what I was trying to say in just a few short words. I never said it was good practice! :D

 

The easiest part here about hard coded the data is that it required little effort to implement. Just throw in a value into the code and be done with it. Since little had to be changed, they just left it in there. Maintaining it is where it lacks in robustness. It would be a terror to trawl through the code to look for some constant you set (unless they declared all of them at the top of source - again not something I like very much myself, but certainly the simplest way of doing things).

 

- NKF

 

Hehe..well, the easiest and most robbust did have more influence than the agreed part, it seems.. :laugh:

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
  • Create New...