Transport Tycoon Forums

I'm just curious about this project, so I have a couple questions.

1. Why C++ and not Java?

2. Can someone summarize what is going on and what has been accomplished?

train-a-mania wrote:2. Can someone summarize what is going on and what has been accomplished?

Loads of discussion, Design Document, Engine, Some graphical work, and loads of other discussion.

At least, AFAIK.

EDIT: + Website desing, meeting logs, meeting minutes.

train-a-mania wrote:1. Why C++ and not Java?

It is too slow, and needs extra software.

maquinista wrote:

train-a-mania wrote:1. Why C++ and not Java?

It is too slow, and needs extra software.

Isn't it a more well-known program, though?

What? Java more well known than C++?
Sure, there may be more "programmers" who know Java, but the real programmers all know at least two of C, C++, and Java, and several others besides.

Okay, that makes sense.

If you choose the programming language for software based on the popularity of the languages you really make a horrible mistake. You need to base the choice on software features.

Hyronymus wrote:If you choose the programming language for software based on the popularity of the languages you really make a horrible mistake. You need to base the choice on software features.

...and C++ offers more, I take it.

For this project it does but that's not the answer for every software development question. Look at Firefox, Azureus and OpenOffice i.e..

I also thought that C++ is more powerfull than Java too AFAIK.

Choice of programming language is a touchy subject, but there's usually a pretty obvious right choice.

For example, TTDPatch has to modify a precompiled binary, so it has to be coded mostly in assembly. OpenTTD aims for portability, high speed, and low memory usage. ASM is good at the second and third, but utterly usless for the first, so C is the language of choice.

But no one would ever write a build script in ASM, C, or C++; those are the relm of Makefiles, Perl scripts, and the like. Similarly, no one would ever write a game in Perl, shell scripts, or (entries to the IOCCC notwithstanding) the C preprocessor.

Personally, my usual language of choice is C++, because it gives me the convience of ignoring memory management when I want too, while still giving me the power to shoot myself in the foot if I so desire. Although I generally don't like shooting myself in the foot, if I can't do it, then there's probably something else I do want to do that I can't.

I suggest thinking about using a high level language.

Whilst C/C++ are preferable (so I heard) when it comes to getting the maximum speed/efficiency out of the hardware, the hardware itself got really powerfull lately. Still top of the edge 3D grafics (=most games) use C/C++ since they simply need the power. On the other hand most office-style applications are now written in abstract high-level languages or even interpreted languages.

What I'm aiming at: Does this project really need the vantages of C/C++ e.g. does it aim for the best grafics ever seen? Or would it be wiser to accept the fact (if), that the programmers and grafics artists won't have time/enrgy/knowledge/manpower to push such a big sized project?

Because thats were high-level languages introduce themself. They work less efficient with CPU, GPU and memory, no doubt about that, but they may significantly increase development speed and the fun in programming ("revolutionary" as they claim). Something a free-time project is heavily depending on.

I'm talking specifically about Ruby and Python. Both have OpenGL bindings and other interesting native game programming librarys.

Take a look at Panda3D for Python.


Phew. What an s*** article this developed to be...
BTW. I won't go for Java or Pearl also. But Ruby and Python seem to deserve to take a second look at em.
BTW2. Ruby and Python both have the ability to import C/C++ classes IIRC. Python is able to preprocess files or built exe-files also.

I think we stay with C++ as there has been decided to use C++ it is very unlickely that we'll switch to any other language. And since TRoS Engine is also writen in C++ without the support for any other language than C++ it is very unlickely that we (as TRoS devs) will port it so you can use any other language.
And any scripting language (as Ruby, perl, python etc.) are too slow to write an entire big game in IMHO. You are probably forgetting that we need fast pathfinding (YAPF vs. NPF for example) and will probably have quite an extensive economy which can also take quite some time.

Not everybody has top of the line pc's and I myself am a sucker for graphics. I think the choice for C++ was a good one when it was made back then, and too much of this project has suffered from endless decisionmaking already, so let's keep to our choice.

TossIB wrote:I suggest thinking about using a high level language.

I assume you are talking about more abstract languages, because even C++ is technically a high level language.

TossIB wrote:Whilst C/C++ are preferable (so I heard) when it comes to getting the maximum speed/efficiency out of the hardware, the hardware itself got really powerfull lately. Still top of the edge 3D grafics (=most games) use C/C++ since they simply need the power. On the other hand most office-style applications are now written in abstract high-level languages or even interpreted languages.

99.999% of the time, office-style applications are doing SFA. Its not like they are managing a world or performing pathfinding routines thousands of times a second. No argument about the power of computers will change the fact that it is ALWAYS better to produce efficient code.

TossIB wrote:What I'm aiming at: Does this project really need the vantages of C/C++ e.g. does it aim for the best grafics ever seen? Or would it be wiser to accept the fact (if), that the programmers and grafics artists won't have time/enrgy/knowledge/manpower to push such a big sized project?

Yes to the first part. I refuse to accept the second part.

TossIB wrote:...they may significantly increase development speed...

I'm sure if they did a study they would find that for small projects this is true, but for large projects it would be false. The de facto standard is to use a low level language to do the grunt work, and then have Lua or Python bindings to do the boring stuff (like scripting).

I've had many discussions about this with different people in the past. Just learn C++!!

id like to point out that this is grossly OT, although theres nothing else to talk about on topic so it probably doesnt matter.

aarona wrote: Just learn C++!!

may i ask you to point me in a direction to follow such advice?

M4rek wrote:may i ask you to point me in a direction to follow such advice?

The first place you need to go is a seminar on the usage of the shift and punctuation keys. I've never met with a good programmer that didn't use those keys properly.

The second place you need to go is to your local bookstore, and you need to leave with a copy of Accelerated C++.

DaleStan wrote:The second place you need to go is to your local bookstore, and you need to leave with a copy of Accelerated C++.

Or any other proper C++ book .

I suggested that one because it's suggested in #C++ on Quakenet. Feel free to use one suggested in any other #C++ channel.
"Proper", BTW, means basically anything without the words "for Dummies", "in 24 Hours", "in 7 Days", or "in 21 Days" in the title.

(Here's why.)