Fundamental programming considerations (important!)

[SHADOW-XIII]

If we put one vehicle in every ZIP file it will not be necessary cuz unqiue name will be name of ZIP file

[orudge]

Woudn't it be better to have something like this:

Code: Select all

<trains> 
    <train> 
     <uniqueidforthistrain>some kind of hash (md5?)</uniqueidforthistrain>
     <name>Collett Pannier Tank</name> 
       <speed>40</speed> 
       <power>500</power> 
       <sprite>collett.spr</sprite> 
     </train> 
    <train> 
    <uniqueidforthistrain>some kind of hash (md5?)</uniqueidforthistrain>
     <name>Collett Pannier Tank v2.0</name> 
       <speed>70</speed> 
       <power>1500</power> 
       <sprite>collett2.spr</sprite> 
     </train> 
</trains> 

Yes, we could have:

Code: Select all

<trains> 
   <train> 
      <id>1044396978</id>
      <name>Collett Pannier Tank</name> 
      <speed>40</speed> 
      <power>500</power> 
      <sprite>collett.tmg</sprite> 
   </train> 
   <train> 
      <id>1044397024</id>
      <name>EuroStar</name> 
      <speed>150</speed> 
      <power>8000</power> 
      <sprite>eurostar.tmg</sprite> 
   </train>
</trains>

where ID is a UNIX timestamp (seconds since 1970).

We could also store the ID in the graphic file, which could help avoid conflicts.

[uzurpator]

Why do you make it so complicated?

simply:
---- kirby.zip ---
kirby.mesh
kirby.jpg (the skin)
kirby.cfg
kirby.shader (if shaders will be used)
---- kirby zip ---

with kirby.cfg having format

name: Kirby Paul Tank
year: 1935
power: 400
speed: 64
accelmodel: steam (of plane/steam/diesel/electric/rveh/ship)
type: steam (of plane/steam/diesel/electric/rveh/ship)
life: 20
whateverotherdataneededtocompletethedescription: whatevervaluethisdatacanassume

Design only a proper folder structure like:

Code: Select all

TT2
\vehicles
\buildings
\buildings\stations\
\buildings\stations\airport
\buildings\stations\train
\buildings\stations\truck
\buildings\stations\dock
\buildings\other
\tiles
\trees
\whateverelese

all that has to be done is to put the correct structure into the archieve and the game would make the tree automaticly. Simplicity > Complexity.

[Lilman424]

[quote="orudge"]Right, first of all we need to decide on various fundamental programming things:

1. Language
C++

2. Portability
I agree

3. Extensibility
so....no limits!!

[SHADOW-XIII]

where ID is a UNIX timestamp (seconds since 1970).

We could also store the ID in the graphic file, which could help avoid conflicts

but what if ID will be the same .... !!
LIKE I SAID: ID's ARE USELESS ...

[orudge]

But the ID won't be the same, unless someone happens to generate the file at the very same time (second). We could use a GUID or MD5 hash if prefered.

[ChrisCF]

[And look who turns up ridiculously late ...]

Though XML seems overkill for something like this (remember that someone will have to draft a DTD or similar for it - not sure if it's required, but it makes it that much easier for XML parsers) it does have the added bonus of being (for all intents and purposes) infinitely extensible. It also makes creating a TTDAlter-like program for managing your vehicle data etc. considerably easier since validating the entry would mostly involve simply parsing the intended output using whatever definitions you've supplied. Something nice like an MD5 would be certainly better than UNIX time, for the reasons slready stated.

It's also well worth exploring some method of checking to make sure that the vehicle you just downloaded is correct, by means of MD5 checksums, or SFV or something. I know of nothing other than SFV that'll check a whole bunch of different files for MD5 sums, but there are probably many other ways I don't know about yet.

I have no knowledge of how it would work, but would we be in danger of seeing bugs as a result of people using different XML parsers? I would guess that this wouldn't be a problem, but if anyone with more XML knowledge would like to set the record straight with that, feel free.

Looks like if I want to help with the code, I'll have to go learn some C (That should be something of an experience). Anyone recommend any decent books? Preferably something I'd be able to get hold of online, or via a library (the most recent book I've found on programming in my local library is Knuth volume I 2nd ed. - just as a guide)

[CheeseNJamButty]

Look at another of the long running cult pieces of software, The Sims.
It's hard to be beaten for extensibility.Adding new functionality is as easy as adding files to one of its standard subdirectories.
If you can avoid the necessity for a user to install entries into a centralized file then dont do it.
It's very good OO practice, each object with a standard set of interfaces, properties, behaviours, sounds etc etc.
Initialization module and Savegames just store the way used building blocks go together.

[OBrown]

Using UNIX timestamps as an id puts a limit on how late into the game new vehicles can be introduced, no? Well OK, maybe not if the seconds from 1970 are days/months since the game started in say, 1880 or 1930. Heh.

And id's are useless yeah, unless you wanna keep a record of how many items are in a file, but optimally that method'd need standard intervals... 0, 1, 2, 3, 4, etc. or 1, 2, 3, 4...

Using timestamps as a unique id'd mean a bunch of search/find to make sure you're not using an id already in use, if you wanted to make a modification to the released, finished game. But using the seconds since 1970 = days since game start formula, a frontend program for such mods could "grey out" the radio button/whatever for any times not available.. example, 0-30 = random day in January first game year this thing is introduced, if there are vehicles/buildings/whatevers for 0-30, the 0-30 option is disabled, so on and so forth until the designated game endpoint or 2^31(-1?), whatever comes first.

Using an interval id would mean there could be up to 2^32 items in a file, if the ids are an unsigned long, with the date the object becomes available as a field in the database.

Just my 2 cents based on what little I know... heh.