Open Source Version von TpF

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


  • Als Train Fever veröffentlicht wurde, hatte ich auch schon mal versucht ein eigenes/offenes TF zu machen, weil viele Sachen in TF nicht gut umgesetzt waren und ich dadurch schon nach 20 Stunden Spielzeit keine Lust mehr hatte. Glücklicherweise wurde in den nachfolgenden Monaten noch einiges nachgebessert, wodurch ich das Projekt wieder eingestellt habe und zu TF zurückgekehrt bin. Bei TpF geht es mir jetzt zwar wieder ähnlich, aber auch da hoffe ich dass sich da die nächsten Montate noch was verbessert. Aber grundsätzlich finde ich die Idee gut und kann mir daher auch vorstellen dazu beizutragen.

  • Aber grundsätzlich finde ich die Idee gut und kann mir daher auch vorstellen dazu beizutragen.

    Mir würde es riesig helfen, wenn du mir mal deine Ideen für die Grundlage offen legen würdest. Momentan schaue ich mir diverse Techniken und Entwicklungsumgebungen an.
    Schwanke momentan zischen der Unreal Engine und ner Zusammenstellung von OpenSource Tools.


    Für die Unreal Engine spricht, dass viel Optisches einfach umzusetzen ist und dafür kaum Entwickelt werden muss. Was mich aber stört ist, dass die meisten Engines darauf ausgelegt sind, dass man statische Maps erstellt. Auch ist es nicht unbedingt darauf ausgelegt, dass man einfach 3D Modelle zur Laufzeit lädt. Es ist mit Sicherheit irgendwie umzusetzen, dann aber auch nicht einfacher, als wenn ich mit OpenSource Tools arbeite.


    Gegen die OpenSource Tools spricht, dass es kaum eine Vorgabe gibt, wie der Code zu strukturieren ist. Auch muss vieles selbst entwickelt werden.


    Ersten Beitrag angepasst: Edit5



    Internet geht seit gestern wieder und das schneller als zuvor *gg* speedtest.PNG

    4 Mal editiert, zuletzt von SalamiTier ()

  • Hmm, bei mir ists 1,3 und 0,5 xD


    Zu schade, dass mein altes OpenGL-Projekt mitsamt der alten Platte den Heldentod starb. Kam bisher nicht mehr wirklich dazu das neu aufzusetzen :/ Eventuell wirds aber bald was wenn ichs mal zur Bachelor-Arbeit schaff. Da geht das Thema dann wohl in Richtung Vergleich OGL/Vulkan ^^

  • Mir würde es riesig helfen, wenn du mir mal deine Ideen für die Grundlage offen legen würdest.

    Anfangs hatte ich auch mal gekuckt, was es so an Engines geben könnte, die evtl. geeignet sein könnten. Dabei habe ich mich allerdings auf reine Renderengines beschränkt, da ich für andere Sachen wie Physik keine Notwendigkeit sah. Mehr als einen Blick darauf werfen ist aber auch nicht daraus geworden. Genauer gesagt habe ich es am selben Tag wieder sein gelassen, weil ich keine Lust hatte mich in all diese Engines einzuarbeiten, ohne zu wissen, ob so ein Spiel mit all den Wünschen die man daran hat überhaupt realisierbar ist.
    Daraufhin habe ich dann entschieden mich erstmal auf die Spielmechanik zu kenzentrieren und die Engine später drum herum zu bauen. Somit habe ich dann großes zufallsgenierertes Straßennetz erzeugt und verschiedene Wegsuchverfahren getestet, oder mich mit der Berechnung von Fahrzeugbewegungen auf krummen Straßen/Schienen beschäftigt. All das dann aber erstmal nur mir Primitivgrafik (Punkte und Linien).
    Das ganze habe ich auch mit verschiedenen Sprachen (C, C++, C#) gemacht, um mal zu sehen wie der Performanceunteschied ist. Hierbei habe ich festgestellt, dass die Codestruktur den größeren Einfluss auf die Performance hat als die Sprache an sich.

  • Ich entwickle da immer dran, wenn ich morgens mit dem Zug zur Arbeit fahre. Die Fahrt dauert ca. 13 Minuten. 6 Minuten davon braucht mein Laptop zum Hochfahren, 2 Minuten zum Herunterfahrten. Bleiben effektiv 5 Minuten Arbeitzeit. Mit Rückfahrt 10 Minuten Arbeitzeit pro Tag bzw. 50 Minuten pro Woche. Für das fertige Spiel sind geschätzt 10000 Stunden nötig. Also könnte ich vorraussichtlich im jahr 2247 was liefern. Evtl. gibts aber 2180 schon eine Early Access Version. :D

BlueBrixx