TTS , transport tycoon clone

[Gil]

Spiff thanks for the new topic! Just wanted to let everyone on the corporate topic know about TTSD, didn't know everyone would start discussing it there!!

Second, glad we made some more people aware of TBOT and Baz's project, hope the attention inspires them to keep up the good work.

Third, can you guys (developers) give us some more specific ideas of the new features you're going to implement in TTSD (the 'etc' under Goals on your site ), or is it too early to ask?

[ChrisCF]

Or can we just use the thread we have already?

[Gil]

Ummmmmmm yeah whichever...........

Just some idea of the new features, don't mind where they get posted.

[ChrisCF]

Better still, for that, you might find out on their website.

[Gil]

Already did.

[TBOT]

Third, can you guys (developers) give us some more specific ideas of the new features you're going to implement in TTSD (the 'etc' under Goals on your site ), or is it too early to ask?

It's quite early to discuss all specific idea's. First we want to create a working game which looks and acts like TTD, after that we will start implementing new and improved features (of course anything which can be done in the progress quickly will be implemented directly).

For a little idea of what sort of features will be in I advise you check our forum (especially TTD -> General discussion -> Train type/class property, I personally like the idea very much).



(PS to the thread: long = undefined, we have absolutely no idea when we will finish something playable)

[krtaylor]

As far as future extensibility, the fact that we will have the source code is certainly the single most valuable thing. It sounds like they are being very object oriented also, which as long as it is all well documented, would help a lot too. My main concern would be the display engine, primarily how it locates and orients objects. It seems like that has been a perennial limitation in TTD (only so much information per square, so we can't have signals on bridges, trolleys on tracks on roads, diagonal tracks under bridges, switches or curves in tunnels, etc. etc. etc.) If the locating/orientation system is more powerful and flexible, then it would solve I think 90% of the "You just can't do that" troubles we've run into.

I'd also recommend a built-in way to add more vehicles, including a middleware layer where you can specify specific vehicles to be included for existing packages. I've been discussing this with Josef for the Patch and so far we have not come up with any way to make it work for TTD; this problem can be avoided in TTSD if it's designed in from the start. We KNOW there will be complete new environments; and also complete new vehiclesets that sit on top of existing terrain environments. We want to make it easy to install and run these. I'm thinking a little bit of MS Train Simulator here - people make whole new routes, copying elements from the existing MS routes, and drawing new trains as needed; they become a new environment that appears on the MS selection list when you install it. I'd like to see something like that.

As far as speed, the object orientation helps enormously. If you can figure out what the objects should be and how they should interact, then it might be possible to parcel out some of the "specs" of the objects to other volunteer programmers so it is more than just the two of you working on it. That's the way Linux works - Linus Torvalds wrote the core, but it was all clearly documented and code was available, so as people needed other plug-in modules (the ability to communicate with serial ports, ability to use different video cards, etc.) they could write them, test them, and they'd work and could be included. If properly designed and thoroughly documented, TTSD could support this, which would save a TON of time. If the two of you have to write everything it will take forever.

The fact that you aren't doing any graphics would certainly save a lot of time. It seems to me that it would be better to have something playable sooner, like in months, rather than the whole thing in years, because it will server to promote the project and more people will get involved to help, thus getting it done faster. Years from now who know what there will be? You can't do a tech project that lasts years, it never gets finished properly because the target is always moving.

[TBOT]

I'd also recommend a built-in way to add more vehicles, including a middleware layer where you can specify specific vehicles to be included for existing packages. I've been discussing this with Josef for the Patch and so far we have not come up with any way to make it work for TTD; this problem can be avoided in TTSD if it's designed in from the start. We KNOW there will be complete new environments; and also complete new vehiclesets that sit on top of existing terrain environments. We want to make it easy to install and run these. I'm thinking a little bit of MS Train Simulator here - people make whole new routes, copying elements from the existing MS routes, and drawing new trains as needed; they become a new environment that appears on the MS selection list when you install it. I'd like to see something like that.

Two words: Configuration files

As far as speed, the object orientation helps enormously. If you can figure out what the objects should be and how they should interact, then it might be possible to parcel out some of the "specs" of the objects to other volunteer programmers so it is more than just the two of you working on it. That's the way Linux works - Linus Torvalds wrote the core, but it was all clearly documented and code was available, so as people needed other plug-in modules (the ability to communicate with serial ports, ability to use different video cards, etc.) they could write them, test them, and they'd work and could be included. If properly designed and thoroughly documented, TTSD could support this, which would save a TON of time. If the two of you have to write everything it will take forever.

TTS is programmed in C. Though C isn't an object oriented language, some of the features of OO can be simulated (for insiders: using struct's, void pointers and casts).
Extending won't involve much of the object orientation (of course it depends on the kind of extension it is), most of the code is just plain C.

The fact that you aren't doing any graphics would certainly save a lot of time. It seems to me that it would be better to have something playable sooner, like in months, rather than the whole thing in years, because it will server to promote the project and more people will get involved to help, thus getting it done faster. Years from now who know what there will be? You can't do a tech project that lasts years, it never gets finished properly because the target is always moving.

We are not planning to make it last for years. And even if we do, the target is not moving. At the moment the level of technology is way beyond programming isometric games, we're not making a state-of-the-art game here.

The game will be open-source, but we want to program at least the core engine and functionality. When the game is in a state that it's easily extendable (according to us), then we will release the source. Until then you just have to be patient.

[ChrisCF]

When the game is in a state that it's easily extendable (according to us), then we will release the source. Until then you just have to be patient.

That, I believe, contravenes the Open Source Definition (http://www.opensource.org/). Therefore, if you took such a line, you are not entitled to call your program open source. If it's not open source, it automatically sucks.

[krtaylor]

Hey, hey, hey! No need to be rude! The Open Source rules don't require you to release code that isn't working, in fact they recommend that you don't. Linux Torvalds didn't release the core of Linux until it was working, that would have been silly. They are saying the do not want to release code until it works, which makes perfect sense to me.

[GoneWacko]

Frankly i'm kinda wondering what's up with you, chriscf, seeing as you've been p***ing off most projects that are currently being discussed on this forum :/ (In my eyes)

[nilsi]

Chris wrote:
If it's not open source, it automatically sucks.
So does TT in your opinion?

I am currently writing a tool for grf understanding,
but is not yet released.

If it works and (is open source) it is much better
than if it is open source but never actually worked.

So please be patient.

Nils

[ChrisCF]

It just really, really annoys me when people say "Oh yes, open source, good, we'll do that." and then don't do it properly. They do it in a way which defeats the point, or in a ridiculously contrived or tokenistic manner.

You can argue against this as much as you like, though the TTS line seems to be "It will be open source when it's finished" Finished, in beta, ready-to-run, whatever, makes no difference to the principle. This approach entirely defeats the point of open source - namely collaborative development, shorter turnaround time, less risk of abandonment due to desertion (trust me, even the most dedicated programmers can find themselves having to leave a project, I've seen it first-hand - case-in-point: has anyone seen rein lately?).

TE had a similar problem, only subtly different. The idea of open development in a closed team (an annoying contradiction).

That said, I've seen the other extreme as well (the contrived and/or tokenistic way). "Yes, this project is open source." You find a source tarball, but a licence that doesn't let you use it, or a source tarball full of uncommented, unindented, obfuscated, and generally unreadable code. Worse still, they (ab)use open source as their "token good deed", and put the source code somewhere entirely inaccessible, unless you buy the product.

nilsi: The advantage to open source is that in the event of it not working, instead of "it doesn't work", you get "given feature doesn't work - this is where it's broken - I think this attached code might fix it".

And finally ...
TT out of the box sucks a little. Applying conventional discrete logic, if it sucks a little, it still sucks. TTDPatch fixes most of that (multiplayer would be nice, but if MPS hadn't broken it beyond repair in the first place ...)

Anyway, back to the books - need to get refreshed on my C and Java (not really a good idea to tackle them at the same time, but needs must )

[krtaylor]

I respectfully submit that, under the circumstances, we should be grateful that someone is attempting to create a version of TTD that will eventually be open source, available to all. If someone else would like to start a "textbook" open source TTD clone project, well, that would be just great. Failing that, I'll take what I can get, and support it.

[TBOT]

Our term 'open source' doesn't refer to the 'Open Source Definition' in any way, I just don't know any other term for giving away the source code.

You talk about annoying releases of uncommented code, which imo is idd very annoying. Parts of TTS remain uncommented for the moment, just because they are bound to change a lot.
Specifications of the engine are also bound to change, rendering possible additions to the code at this moment unusable in a future version of the engine.

What we want to make clear is that an Alpha (or even Beta) stage engine just isn't fit to be extended. Besides that, parts of the engine aren't even finished yet (for example user interaction with the game model, early versions of rail-laying are just getting into shape).

At this moment the engine is also undocumented, leaving a huge uninterpretable mass of code (Think about it, you don't want to read the full engine source code if you just want to extend it). Clear documentation is a requirement for us to release the source, else people will only be confused.


And as for your statement that non-open-source (according to the 'Open Source Definition') 'sucks', I just have to majorly disagree. You can't program a game engine in a open development team, different idea's and different coding techniques/tools will just leave something hard to understand, and with very bad performance. It might speed up things in the beginning, at the end it will only slow it down. Extenders need a solid base to work on, not a mix of code snippets.

At the moment TTS is closed source, just to prevent the code from messing up big time. As soon as we think it's ready for it it will be open source (maybe according to the 'Open Source Definition', maybe not, it's all up to us). What you can count on is that the source will become open at some stage. Maybe when we decide to stop with the project (which we don't intend at the moment, but you never know), or when the code is ready for it.

If you think a game should be open-source from the very beginning, I suggest you try it yourself in a new project, but please don't bother us.
I hope I made our statement clear.

[spaceman-spiff]

I'm pretty bored with people wanting the source of every new project, why don't you make you're own

[Grunt]

Because they're too lazy to get off their arses and start a project of their own and simply want to steal the work of others who've already gotten a decent start on a project?

[Arathorn]

Quit the bullsh*t. TTS is their project, they'll do it as they like.
Who cares whether it's according to the "definition" of open source or not, as long as it works it's ok. It would be stupid to release the source at such an early state.

[spaceman-spiff]

That's pretty much what I wanted to say

[SHADOW-XIII]

I'd like to get one day source for private use