[NTS] Entwicklung eines neuen TrainSims - erste Überlegungen

    Ein paar Leute haben offenbar Lust, über die mögliche gemeinschaftliche Entwicklung eines neuen TrainSims (NTS) zu reden. Jeder interessierte Entwickler ist eingeladen, hier Gedanken dazu auszutauschen. Bitte keine Diskussion à la "oh nein, lasst das, braucht doch kein Mensch", Danke!


    Hier eine erste, grobe Übersicht über die geplanten Features (wird aktualisiert):


    Internes Streckenbeschreibungsformat:
    - beliebig große Landschaft
    - beliebig viele Objekte
    - beliebige Fahrstraßen
    - beliebige Fahrpläne
    - fahrende Gegenzüge
    - bewegliche Objekte


    Sim:
    - realistische Fahrphysik
    - realistischer Sound
    - Sifa etc. modular abhängig von Triebfahrzeug/Strecke
    - Anfänger/Sandkastenmodus optional
    - performante 3D-Engine, die die Möglichkeiten von DirectX 9 nutzt (Schatten, Wetter, Bumpmaps, Wasser ...)
    - Führerstandansicht (3D oder 2D)
    - Außenansicht
    - Einblendung eines (Buch)fahrplans
    - Rangieraufgaben (d.h. Ab- und Anhängen von Wagen)
    - Dynamische Signale


    Benutzerinterface (Menüs etc):
    - leicht verständlich (z.B. eingeblendete Tastenkombinationen)
    - komplett in Direct3D, also ohne Windows-Knöpfe
    - Multilanguage (deutsch, englisch, beliebig erweiterbar durch einfache Sprachdateien)


    Editor:
    - WYSIWYG
    - Laden/Speichern von Teilstücken
    - Makrofunktionen für Objektpositionierung (so dass man z.B. nicht jeden Baum einzeln positionieren muss)


    Module:
    - Laden von BVE-Strecken und -Führerständen (BVE2 und 4)
    - Laden von Loksim-Strecken und Führerständen


    Zielgruppe:
    - Nurausspaßfahrer UND
    - Virtuelle Lokführer (d.h. Profis)


    Man sieht, dass der NTS einige Alleinstellungsmerkmale hat, die ihn von allen anderen frei verfügbaren Sims abhebt. Das gibt ihm die Existenzberechtigung.


    OpenSource-Entwicklung in C++ (3D-Engine, Direct3D 9) und C#.NET (Rest) oder ausschließlich in C++.


    Vorgesehene Entwicklungssysteme: MS Visual C++ bzw. C#. Die Express Editions sind hier kostenlos erhältlich.

    Bezüglich Engine:
    Meine 3d-Engine verwendet DirectX 9, kann zumindest die Basics (Models, X-Models, Sprites, Licht, Direct Input) und besitzt auch eine eigens geschriebne Non-Windows GUI-Engine (inklusive Skript-Parser, d.h. per Scripting können sämtliche Elemente erstellt werden sowie inkl. GUI-Editor-Tool), welche, glaube ich, am ehesten für das hier angeführt Projekt in Anspruch genommen werden könnte.
    Natürlich sind noch einige Teilbereiche nicht ganz fertig, das wird aber schon noch werden.
    Die Engine selbst soll ja auch noch wesentlich erweitert werden.


    Dummerweise ist das ganze in Delphi geschrieben, es wäre d.h. nur möglich alles per Dll für C++/C# zugänglich zu machen. Ist halt ein wenig Aufwand.


    Auf was ich eigentlich hinaus will:
    Man könnte ja, wenn man für die Engine eh Dlls verwendet, Teile meiner Engine und Teile von Alex's Engine "verschmelzen".
    Das würde sicherlich am meisten bringen, und da beide Engines in DirectX 9 sind (oder?) dürfte das kein Problem sein.


    Das war`s erstmal von der technischen Seite her. Ciao !


    PS: C# kenn ich zwar noch nicht, da es aber ja angeblich so wie Java ist mit welchem ich schon gearbeitet habe denke ich könnte ich mich damit schon abfinden.

    2 Mal editiert, zuletzt von Thomas Tschofenig ()

    Ja, was die Engine angeht, solltet ihr zwei euch kurzschließen. Vielleicht kann man das ganz gut kombinieren. Von Delphi nach C++ portieren sollte auch nicht das große Problem sein, da die DirectX-Aufrufe eh identisch sein dürften.


    Zu C# nur soviel: Wer C, C++, Delphi oder Java kann, kann automatisch auch C#. Man kann einfach drauflos schreiben. Probiert's aus.


    Das einzige, das da wirklich neu ist, ist die .NET-Runtime. Aber wer MSDN-Hilfen lesen kann, beherrscht auch das sofort.

    Zitat

    Ja, was die Engine angeht, solltet ihr zwei euch kurzschließen. Vielleicht kann man das ganz gut kombinieren. Von Delphi nach C++ portieren sollte auch nicht das große Problem sein, da die DirectX-Aufrufe eh identisch sein dürften.


    Naja, also alles 1:1 nach C++ zu übertragen das wäre schon relativ schwer, da C++ ja in Sachen Objektorientierung und vor allem in Sachen Strings doch ein wenig anders ist als Delphi.
    Aber ich denke man könnte zumindest kleinere Teilbereiche übertragen.
    Die DirectX-Aufrufe hingegen sind in der Tat fast absolut identisch.
    Die Übertragung der GUI-Engine halte ich zwar nicht für absolut unmöglich, es wäre aber sicherlich ein irrsiniger Aufwand da jene Quellcodedatei ca. 1200 Zeilen lang ist, mit vielen abstrakten Klassen arbeitet und da jene Engine ausserdem auch noch mit anderen Systemenverknüpft ist (Eventmanager welcher wiederum DirectInput braucht) sowie das Skripting (das ist ziemlich unmöglich zu Übertragen da es einen Haufen Stringfunktionen nutzt die C++ nunmal nicht kennt).
    Aber genug gefasselt, ich glaube ich werd mich da eher einmal mit Alex kurzschliessen.


    Mit Dot-Net (igitt *g*) hab ich übrigens auch noch nie gearbeitet, kommt mir aber auch so ein bissel nach Java-Nachmache vor...

    Moin - an der Stelle nur ein ganz kleiner Tipp, ich kann ja ganz grob abschätzen, was sowas bedeutet, da Zusi zumindest etwa auch die Anforderungsliste erfüllt.


    Insbesondere gut bedienbare WYSIWYG-Editoren zu programmieren bedeutet wirklich massiv Arbeit. Der Sim an sich ist gar nicht so wild und fällt dabei fast schon als Abfallprodukt mit ab.


    Viele auf den ersten Blick recht einfache Sachen werden am Ende doch hinreichend kompliziert. So muß man z.B. die Landschaft irgendwie sinnvoll zerlegen und strukturieren, um den Punkt "beliebig große Strecken" erfüllen zu können. Allein das dafür nötige Polgyonclipping ist eine hochkomplexe Aufgabe.
    Und wann man Weichen und Überhöhungen unterstützen will, kommt man eigentlich nicht drumrum, sowas in der Art hier umzusetzen:
    http://www.zusi.de/zusi3/zusi3weichen.htm
    Das sind jetzt nur 2 Punkte von ganz vielen.


    Ich bin nicht sicher, ob ich jemals mit Zusi angefangen hätte, wenn mir der volle Umfang bewußt gewesen wäre. Ich hab's halt durchgezogen, aber das erfordert wirklich konzentriertes Arbeiten über etliche Jahre hinweg. Wäre schade, wenn viel Energie in sowas gesteckt wird und der Umfang des Projekts unterschätzt würde. Da könnte sich die Sim-Welt vielleicht lieber über andere Werke freuen. (Was beim Loksim z.B. auch noch fehlt, wäre sowas wie die Ziegler-Tools für Zusi, also Zusatzsoftware mit der man digitale Geländemodelle und topogr. Karten benutzen kann)


    Das soll kein "oh nein, lasst das, braucht doch kein Mensch"-Beitrag sein - also bitte nicht mißverstehen. Ich würde nur dazu raten, das Konzept noch deutlich zu vertiefen und eine halbwegs belastbare Aufwandsabschätzung zu machen und erst dann anzufangen und programmiertechnische Punkte zu diskutieren.


    Carsten

    @Carsten: Ich glaube nicht, dass hier jemand den Aufwand unterschätzt. Erstens hat jeder bereits gewisse Anfänge erstellt und weiß daher um die Komplexität. Und die ist, zweitens, genau der Grund dafür, es im Team zu machen.
    Edit: Ich wage mal folgende These: Zusi 3 wäre schon fertig, wenn Du nicht alleine daran arbeiten würdest.
    Nochmal Edit: Zusi 3 erfüllt übrigens fast alle Wünsche an "unseren" NTS - außer, dass Zusi kommerziell und kein OpenSource ist. Die daraus ableitbare Grundsatzdiskussion können wir aber gerne unterlassen ;)


    Das Hauptproblem, das ich derzeit sehe, ist, dass offenbar mindestens drei unterschiedliche Anfänge vorhanden sind, die sich nicht zu einem gemeinsamen Anfang vereinigen lassen. Erstens wegen der verwendeten Sprachen und zweitens, weil die Interfaces nicht zueinander passen werden. Wahrscheinlich läuft es darauf hinaus, komplett von vorne anzufangen und vom vorhandenen Code nur kleine Teile zu übernehmen. Das ist natürlich recht unerfreulich.


    Die Frage ist, was besser ist: Drei unfertige, suboptimale Sims oder ein ganz neuer, fertiger.

    Also wenn der Arbeitsaufwand klar ist, umso besser. Ich kann ja nur lesen, was hier steht - oder was halt auch nicht hier steht.
    Mir persönlich kann auch relativ egal sein, ob und wie sowas klappt. Wenn gewisse Erfahrungswerte gewünscht sind, habe ich keine Probleme damit, was dazu sagen - kann meine Zeit aber auch anders rumbringen ;)


    OT: Ich hätte übrigens nichts gegen weitere Programmier-Unterstützung bei Zusi 3. Aber Leute, die die nötigen Fach- und Programmierkenntnisse, Zeit und Ausdauer mitbringen sind halt selten. So ist nur Roland Ziegler beim Thema Gleis- und Geländebau und Stellwerk mit im Boot, aber die Hauptlast liegt auf meinen Schultern.


    Carsten

    Ich hätte noch was für die Liste: (Dynamische) Signale ;-)

    Einmal editiert, zuletzt von Thomas Tschofenig ()

    Ich musste leider feststellen, dass man mit der kostenlosen Version von C++ Visual Studio Express keine win32-Anwendungen bauen kann, nur .NET. Das ist schonmal ziemlich hinderlich; man müsste sich also eine richtige Version des Visual Studio besorgen, was damit Kosten verursacht.


    Vielleicht zur Erklärung: Im Büro habe ich natürlich Visual Studio (c++), zuhause arbeite ich aber fast ausschließlich mit freier Software, z.B. Delphi Personal Edition und Visual Studio Express C#. Für das NTS-Projekt werde ich sicher keine weitere Entwicklungsumgebung kaufen.


    Damit sehe ich für das Projekt folgende Optionen:


    a) komplett C++ (dann mangels Entwicklungsumgebung ohne mich)
    b) komplett Delphi (Engine von Thomas vorhanden, aber Alex müsste dann umsteigen)
    c) komplett C# (scheidet wohl aus, da wir keine Engine dafür haben sowie vermutlich aus Performancegründen - es gibt aber eine OpenSource-Engine, die man anpassen könnte: http://sourceforge.net/projects/purplesharp)
    d) Framework in Delphi, Engine in C++ als DLL (dann brauchen nur die Engine-Entwickler Visual C++)
    e) Framework in C#, Engine in C++ als DLL (wie d, dann haben wir aber .NET am Bein)
    f) Framework in C#, Engine in Delphi als DLL (wie d, dann haben wir aber .NET am Bein, aber dann kann notfalls jeder die DLL kompilieren, weil Delphi frei zu haben ist)


    d) bis f) haben den Nachteil, dass das Interface der Engine-DLL bestens durchdacht sein muss, weil man da nicht einfach so etwas ändern kann. Es muss genau überlegt werden, was Aufgabe der Engine ist und was nicht, zudem müssen die Datenstrukturen kompatibel sein. Aus gutem Grund werden solche Hybrid-Lösungen in der Industrie vermieden, wo es nur geht ...


    Ich bin ein wenig ratlos, was nun zu tun ist. Insbesondere angesichts des bereits vorhandenen Codes, den wir nicht unter einen Hut kriegen.


    Was meint ihr?

    @Uwe: Es gibt derzeit schon recht gute Entwicklungsumgebung (auch kostenlos!):
    Nämlich Bloodshed Dev C++


    Das ist echt sehr ähnlich wie Microsoft Visual Studio.
    Ich habe damit auch auf der Uni damit gearbeitet.

    Da hast du recht Obelisk, da Dev C++ aber mit dem G++ Compiler arbeitet und der kein DirectX unterstützt, kommt das nicht in Frage.


    Allerdings kann man den Microsoft Compiler von Visual C++ 2003 Professional auch kostenlos downloaden. Dann fehlt eben die Entwicklungsumgebung, Win32 Dateien kann man aber natürlich damit erstellen.

    Dev Cpp verwendet G++ Compiler?
    Hmm den Unterschied ist mir nicht bewusst.
    Normalerweise ist doch der Compiler eigentlich doch gleich? (Es entstehen letztendlich ja ausführbare Programme)


    Hmm wenn doch nicht so gehen sollte, dann stellt sich die Frage, warum wir nicht dann OpenGl machen? Dann kann Alex ja mitmachen, da OpenGl auch mit Dev Cpp geht.


    PS: DevCpp kann auch mit DirectX arbeiten
    http://www.c-plusplus.de/forum…-is-1-and-start-is-0.html


    http://www.wer-weiss-was.de/theme158/article3009060.html


    http://nexe.gamedev.net/direct…elopment%20Using%20DevCpp

    Also ich habe eh das Microsoft Visual C++ 2003 .NET Standard und wie im Zügig2 Theard auch zu sehen, schon erste Bilder.

    DirectX ist meines Wissens deutlich moderner und besser auf aktuelle Grafikkarten abgestimmt als OpenGL. In dieser Hinsicht dürfte die Sache klar sein.


    Wenn Bloodshed Dev C++ mit dem freien MS C++-Compiler arbeiten würde, wäre das sicher eine Option. Klar kann man damit DirectX programmieren, dafür braucht man ja nur das DirectX SDK.


    Die Frage ist: Welche Probleme kriegen wir, wenn einer mit Visual C++ arbeitet und ein anderer mit Bloodshed?


    Ich werde mir das Ding mal ansehen.


    Edit: Hihi, der Bloodshed ist ja in Delphi programmiert ... 8)

    Also ich habe leider keine entsprechende Version von MS C++, den von Bloodshed kenne ich aber (geringfügige Unterschiede beim Syntax z.b. bei der Winmain-Funktion).

    Ich möchte nochmal kurz an meinen Vorschlag aus dem Vorgängerthema ("Zügig II") erinnern, besser einen bestehenden und bereits gut etablierten Freeware-Simulator weiterzuentwickeln, als das Rad neu zu erfinden.


    Meine Erfahrungen im Umgang mit Programmiersprachen liegen zwar schon einige Jahre zurück, aber wenn ich mich recht erinnere, liegt ein großer Vorteil objektorientierter Sprachen darin, dass jeder Entwickler seine eigene Objektklasse basteln kann, die ein anderer dann über Aufruf der entsprechenden Funktion ohne Kenntnisse interner Variabeln ect. benutzen kann. Dadurch müsste es möglich sein, dass ein Entwickler sich zB. auf die Grafikroutinen, ein anderer auf die Fahrphysik und ein dritter sich um Signalisierung und Zugbeeinflussung kümmert. Damit dürfte der Austausch bestehender Loksim-Grafikroutinen gegen von anderen Entwicklern weiterentwickelte kein Problem sein, wenn man sich über gewisse Eckdaten einigt (die hier schreibenden Programmierer mögen mich korrigieren, falls ich mich irre).


    Loksim3D ist weltweit der einzige Freeware-Simulator, der über Jahre hinweg einen hohen Entwicklungsstand und eine große Fangemeinde aufgebaut hat (sieht man einmal von BVE ab, dessen Weiterentwicklung in den letzten Jahren allerdings ins Stocken geraten ist und dessen Entwickler eine Kooperation mit anderen Programmieren, insbesondere außerhalb Japans, nicht wünscht), zumal sind die Entwickler hier im Forum präsent und es besteht eine relativ große Auswahl an Strecken, Objekten und Führerständen. Ich kann mir nicht vorstellen, warum die Loksimmer echten 3D-Führerständen, einer Importfunktion für BVE-Strecken (sofern das programmiertechnisch möglich ist; BVE unterstützt zB. keine Höhenlinien und einstellbaren Fahrstraßen, aber das müssten die Programmierer beurteilen) oder dynamischen Wettereffekten (sofern sie eine realistische Fahrphysik über die Rad-Schiene-Reibwerte nach sich ziehen) ablehnend gegenüberstehen sollten.


    Aber vielleicht kann sich Ralf Gryga zu dem Thema "mögliche Mithilfe an der Weiterentwicklung des Loksims", der Machbarkeit und den noch benötigten oder zu überarbeitenden Routinen einmal selbst äußern.

    @Rainer: Keine Einsprüche ;-)


    Wg. Entwicklungsumgebung, vielleicht ist "Eclipse" bekannt? Ich weiß nicht viel mehr, als daß es das gibt - ist eine kostenlose IDE, die alle möglichen Sprachen unterstützt. Ob es das Visual Studio für C++ in diesem Anwendungsfall ersetzen kann, weiß ich nicht...


    Carsten

    Zitat

    Original von Uwe Post
    DirectX ist meines Wissens deutlich moderner und besser auf aktuelle Grafikkarten abgestimmt als OpenGL. In dieser Hinsicht dürfte die Sache klar sein.
    [...]


    Nur Du kannst nur keine Programme nach Linux exportieren, da lobe ich OpenGL, denn es ermöglicht diesen Exportierung.
    Und Directx ist nicht wirklich moderner als OpenGl (es liegt schon eher, was man damit macht!)
    Aber gut, DirectX könnte funktionieren.


    Wegen VC++-Compiler für Bloodshed, das ist (siehe Links) nicht nötig. Deren Compiler kann auch.


    @Carsten: Eclipse ist mir bekannt, allerdings ist es ein wenig gewöhnungsbedürftig.