Fundamental programming considerations (important!)
Moderator: Transport Empire Moderators
-
- Tycoon
- Posts: 14275
- Joined: 09 Jan 2003 08:37
- orudge
- Administrator
- Posts: 25148
- Joined: 26 Jan 2001 20:18
- Skype: orudge
- Location: Banchory, UK
- Contact:
Yes, we could have:lumted wrote: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>
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>
We could also store the ID in the graphic file, which could help avoid conflicts.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
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:
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.
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 art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Re: Fundamental programming considerations (important!)
[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!!
1. Language
C++
2. Portability
I agree
3. Extensibility
so....no limits!!
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction. - Albert Einstein
-
- Tycoon
- Posts: 14275
- Joined: 09 Jan 2003 08:37
[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)
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)
Bugzilla available for use - PM for details.
-
- Engineer
- Posts: 3
- Joined: 16 Feb 2003 09:48
- Location: Manchester, UK
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.
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.
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.
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.
Who is online
Users browsing this forum: No registered users and 9 guests