spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wieso zum Teufel willst du den Server für ein Spiel, dass du in C# entwickelst unbedingt in Java geschrieben werden?
Mit C#+Mono kannst du auch Dedicated Server für Linux schreiben.

Der Server braucht offensichtlich die Geometrie-Daten der Welt auf der der Spieler herum läuft.

Andere Möglichkeit: versuch doch neben dem eigentlich Spiel auch den Server in Unity zu entwickeln. Der Vorteil daraus wäre, dass bereits alles notwendige (Level-Informationen, Physik-Berechnung, Skripte, ...) vorhanden wäre und im Grunde nur noch der Serverteil geschrieben werden müsste. (Ich hatte sowas bisher noch nicht probiert, umzusetzen, ich wüsste aber auf Anhieb nicht, warum es nicht funktionieren sollte.)
Bedenken muss man dabei, dass man dann beim Bauen des Spiel darauf achten muss, die richtige Konfiguration zu wählen, nicht dass der Client Szenen des Servers startet.

Ich würde es zwar grundsätzlich besser finden, wenn der Server Client nur das handhaben, was für sie selbst relevant ist (und nicht Code mitschleppen, der ohnehin nicht zur Ausführung kommen soll), allerdings hat man so einen weit geringeren Aufwand.

Zitat von »SatyPardus«

Die rede ist von einem DEDICATED Server. KEINEM im Spiel eingebauten. Ich benutze im moment Photon und der Server ist derzeit IM Spiel.
Da das aber viiiel zu teuer ist, möchte ich davon weg.

Ebenso möchte ich den Spielern anbieten auf Linux Servern das Spiel zu hosten. Und mit einem Grafischen fenster geht das kaum bzw. viel zu umständlich.

Deswegen standalone, raus aus dem Spiel.

Zudem soll nur der Server alles handhaben und kein Player, was aber im Spiel dann Theoretisch einer wäre wenn man es in Unity macht.

Anscheinend hast du nicht verstanden, was ich meine. Es wird zwar Unity verwendet, allerdings würde speziell für den Server ein Teil entwickelt werden, der dann auch separat exportiert und ausgeführt werden würde. Die "Kosten" des Servers kann man durchasu gering halten, indem er nichts darstellt (keine Kamera bzw. wenn, dann eine, die nur ein UI darstellt, nicht aber den eigentlichen Spielinhalt).
Bei anderen dedizierten Servern läuft es auch so, dass die gesamte Konfiguration vorher festgelegt wird und nach dem Start des Servers meist nur über Netzwerkkommunikation auch den Server zugegriffen wird. Bei dieser Variante wäre das nicht anders.

Ich habe diese Möglichkeit genannt, da man so ohne ein (kostenpflichtiges) Plugin für Netzwerkfähigkeit sorgen kann, aber dennoch die ganzen Features von Unity (bspw. Physik) nicht neu implementieren muss.

Mein Problem ist, dass ich mit Unity keine reinen Konsolenprogramme erstellen kann.
Der Server muss also über eine Grafikkarte verfügen...

Was ist für dich ein Spiel? Für mich ist das abhängig davon, in wie weit der Benutzer (bzw. Spieler) damit interagieren kann und nicht, welche Art von Berechnung durchgeführt wird.
Auch habe ich doch bereits geschrieben, dass eine Kamera gar nicht erforderlich ist. Wenn maneine grafische Oberfläche bieten will, könnte man es über eine Kamera lösen, die nur das UI und nicht den Spielinhalt darstellt. Und eigentlich sollte bereits verständlich geworden sein, dass der Server dann auch nichts anderes als ein Server ist und nicht selbst als Client auftritt.
Abgesehen von der Darstellen müssen alle Berechnungen Serverseitig durchgeführt werden. Da man diese deaktivieren kann, hat man in der Hinsicht also im Grunde keinen Overhead.

Konsole:
Warum muss es unbedingt eine Konsole sein, die bei einer SSH(/Telnet)-Verbindung nach dem Start des Servers offen bleibt? Genauso könnte man sich über ein separates Tool mit dem Server verbinden und so die Administration durchführen. (Oder eine solche Konsole ist im Spiel selbst eingebunden.)

1000 ms...
Ich hatte bereits bei mir daheim einen Rechner als Server für das eine oder andere Spiel verwendet und bei einer DSL 25000 Leitung gab es keine Probleme mit zu hohen Pings.

Auch wenn das scheinbar das einzige verbleibende Problem ist, solltest du das nicht unterschätzen. Um die Leveldaten zu bekommen, musst du "nur" die richtigen Dateien (*.unity) einlesen und auswerten. Allerdings ist nicht jedes Gameobject ein Teil der Umgebung. Es muss also darauf geachtet werden, welche Collider vorhanden sind. Es muss darauf geachtet werden, welche Scripte vorhanden sind, damit deren Verhalten auch beim Server nachgebildet werden kann. Bei den Collidern muss darauf geachtet werden, ob diese Trigger, kinematisch sind, welcher Layer diesen zugeordnet ist und ob sie gerade aktiv sind. Das Ändern der Aktivität würde wieder über Skripte stattfinden.
Wenn du unbedingt die Physik nachbilden willst, könntest du dir PhysX nehmen und das gleiche nachbilden, was Unity intern macht. Auch hier muss wieder darauf geachtet werden, dass nur die Collider verwendet werden, die aktiv und keine Trigger sind (bzw. Trigger müssen anders gehandhabt werden). Die Ebenen und die möglichen Kollisionen zwischen diesen muss berücksichtigt werden, Veränderungen durch Skripte müssen beachtet werden usw.
Und da das noch nicht mal die Spiellogik selbst ist, sondern nur die Engine-Funktionalität, müssen natürlich auch alle Skripte erneut implementiert werden und während der gesamten Entwicklung dürfen keine Abweichungen zwischen diesen beiden Implementierungen entstehen.