Deutsches Simutransforum

Mein Plan für den Netzwerkmodus:

Stufe eins: Simutrans kann Dateien über das Netz lesen und schreiben. (3 Tage maximal)

Stufe zwei: Mit etwas zusätzlicher Logik gibt es einen kooperativen Server, bei dem man ein SPiel auschecken kann (während der Zeit is es dann gesperrt) und wieder einchecken kann, zusammen mit Mitteilungen für den nächsten Spieler. (Zwei Wochen)

Stufe drei: Echter Netzwerkbetrieb. Nach dem herunterladen einer Karte läuft Simutrans auf allen Systemen synchron. Dazu gibt es per UDP einen Beat mit dem jeweilig aktuellen Random-wert, um asynchronen Spielen vorzubeugen. Alle Aktionen gehen per (dank des neuen Werkzeugsystems sehr einfach) immer über den Server und werden dann erst lokal ausgeführ, wenn der Server sie zurückschickt. Wird vermutlich etwas ruckeliger, falls viele Schiff unterwegs sind (da sync_step und step dann nur noch abwechselnd laufen dürfen). Erste Funktion nach ca. zwei Wochen, die meiste Zeit wird das Erkennen von asynchronen Aktionen brauchen.

Was muss konkret gemacht werden:
- Sockets so ansprechen, dass dataobj/loadsave.cc auch auf Sockets schreibt.
- Ein GUI um von einem Masterserver (http://www.simutrans.com?) eine Liste mit Servern zu holen, die dann angeboten werden können. Direkte Eingabe sollte auch gehen. SOllte mit ipv6 und v4 zurechtkommen. GUI bekomm ich sicher recht schnell hin, wenn man den Rest soweit vorbereitet hat.
- Ein ganz bisschen zusätzliche Logik zu Verwalten (Begrenzung der im SPiel ablaufenden Zeit, kein schneller Vorlauf etc.)
- Für echte Netzwerkspiele ist simworld.cc so zu ändern, dass sync_step und step möglichst gleichmäßig abwechselnd laufen. Ist aber im FastForward modus schon weitgehend realisiert, nur ist das die Pause viel kürzer.
- simworld.cc so ändern, dass alle Klicks statt direkt auf das Werkzeug erst an den Server geschickt werden (bzw. das der Server solche Aktionen auch wieder an alle Client verteilt.) Dazu müssten vermutlich noch ein paar weitere Werkzeuge erstellt werden.

Der Plan ist schon zwei Jahre da, auch der Umbau des Werkzeugsystems ist im wesentlichen deswegen erfolgt. Wann immer ich was hinzufüge, denke ich an den Netzwerkbetrieb.

Wäre der erste Schritt nicht lokales Netzwerk?

Also das 2 oder mehr Rechner mit laufendem Simutrans gegenseitig miteinander können. Ggf. muss es eine extra Version geben, die auch als Server arbeitet.

Die Online-Servervariante hat nämlich einen Nachteil. Spieleserver müssen recht kurze Antwortzeiten haben, was Performance und Kosten nach oben treibt.

Und ich bin mir nicht sicher, ob sich recht viele finden werden, die so einen Spieleserver finanzieren.

Jede normale SImutransversion kann als Spieleserver dienen. Einige Aktionen werden halt 200ms Verzögerung haben. Das ist dann halt der Preis für Onlinegaming. Die Verzögerung kann man sicher einstellen.

OpenTTD macht es jedenfalls genauso (fast alle kooperativen Spiele müssen es so machen.)

Auf Wunsch der Benutzer aus diesem Forum ist dieser Thread als WICHTIG markiert und hat einen Sticky erhalten.

Hi,

ah... endlich tut sich etwas auf einem Gebiet, wo ich wirklich helfen kann... :-)

Oder zumindest teilweise. Prissi: Bevorzugst Du eher Eigenentwicklungen, oder wäre eine OS-Library wie z.B. die TNL ok? TNL wäre cross-platform, nutzt UDP, verzichtet auf (eigene) Thread-Nutzung und ist damit recht gut synchronisierbar. Sie unterstützt Rpc (z.B. für sync-Nachrichten) und Objekt-Replizierung via ByteBuffer (damit könnte man ein Savegame übertragen).
Ich kenne die Library selbst nicht, aber die Doku scheint vernünftig zu sein.

Was haltet Ihr davon?
jois3

Was spricht gegen Posix Sockets? Die funktionieren, und sind für fast alles von C64 aufwärts vorhanden, im Gegensatz zu Bibliotheken. Außerdem scheint zumindest BeOS nicht supported zu werden.

Außerdem ist TNL semiprofessionell und dürfte die zarten Bemühungen, SImutrans in Debian zu integrieren wieder konterkarieren und für die Dinge, die Simutrans braucht, ist TNL totaler Overkill.

(Angesichts der Größe von Savegames im MB-Bereich wird Simutrans ohne DSL eh nicht vernünftig funktionieren. Da ist dann Paketlaufzeit eh kein so ganz großes Problem, vermute ich.)

Ich habe mir die Routinen in OpenTTD angesehen, und das war eher wenig Aufwand. Nur umstricken für Simutrans war aufwendiger, als neu machen, bedingt durch die andere Architektur. Mir fehlt halt vor allem die Zeit.

Freerails hatte einen Netzwerkmodus, scheint aber schon lange tot zu sein:

http://sourceforge.net/projects/freerails/

Das war ganz früher mal ein Mitbewerber von Simutrans. Vielleicht kann man vom Code dennoch noch etwas lernen?

Naja, JAVA hat eingebaute Netzwerkfunktionalität ... Das ist bei der Frage welche Bilbiothek man nehmen könnte, leider nicht sehr hilfreich. Ansonsten denke ich, dass ein schrittweise Vorgehen am ehesten hilft. Und man kann ja immer sich auch von OpenTTD inspirieren lassen.

Ich dachte es gibt einen C++ client für Freerails. Aber Du hast recht, Java macht hier viles sehr viel einfacher -> daher auch mein Gedanke Simutrans noch mal neu in Java zu programmiren, was ich vor einigen Tagen in einem anderen Thread geschrieben hatte. Ist aber nicht wirklich sinnvoll.

Leider kenne ich mich mit dem von Dir favorisierten Netzwerkmodell weniger gut aus. Beruflich habe ich immer mit asymmetrischen Client-Server Systemen gearbeitet (Client nur als Anzeige, Programm läuft auf Server).

Im Prinzip kenne ich die Idee zwei (oder mehr) gleichartige Systeme übers Netz synchron zu halten, empfinde das aber als ungemein schwierig im Vergleich zum System, wo der Server all die Arbeit macht, und die Clients nur anzeigen. Allerdings ist Simutrans von der Architektur her dafür gar nicht geeignet, und die synchronisation der einzige offen stehende weg.

Fragen nach Sockets oder Netzwerbibliothen zeigen jedoch, dass viele das Problem an der falschen Stelle vermuten. Eine Datenverbindung ist schnell programmiert, aber das Problem ist es zwei (oder viele) Simutrans-Instanzen über diese Datenverbindung synchon zu halten. Da drin steckt der eigentliche Trick.

Ok, Sources von beiden habe ich und werde sie mir über's Wochenende mal zu Gemüte führen.
Ist es sinnvoll, für die Ausarbeitung und die Dokumentation der Netzwerkfunktionalität gleich das Wiki zu bemühen? Ich könnte dort dann skizzieren, was ich portieren/schreiben könnte bzw. wie das Interface aussieht. Oder lieber per svn?