ZFX + Developia

Moin in die Runde,

ich habe mal wieder etwas Zeit und wollte mal wieder etwas neues ausprobieren.
Gleich vorweg das Ziel ist nicht unbedingt ein fertiges Spiel zu entwickeln sondern es geht eher um allgemeines Design und darum Erfahrungen zu sammeln und etwas zu lernen.

Ganz grob ist das Ziel einen Server zu schreiben und diesen per UDP mit den Clients reden zu lassen, das ganze wird in C# umgesetzt. Hier gibt es eine Reihe von fertigen UDP-Bibliotheken für die Netzwerkkommunikation, dürfte also kein Problem sein.

Mein gedankliches Problem ist folgendes:
Mein Server muss ja die selben Objekte kennen wie der Client und jeweils nur den Status über diese Objekte an den Client zwecks Darstellung senden.
Auf der Client-Seite wollte ich MonoGame verwenden, scheint ehemals XNA zu sein. Sollte also machbar sein.
Mein gedankliches Problem liegt auf der Seite des Servers.
Denn wenn ich die Objekte aus dem Framework für z.B. 3D Objekte verwende will ich ja auch die Objekte zur Collisionserkennung verwenden oder anders formuliert. So viel wie möglich was mir dieses Framework bietet ohne alles selber oder doppelt zu implementieren.
Nun scheint dieses MonoGame primär eine GrafikEngine zu sein.
Mein Server muss aber ja nichts rendern, er soll ja nur die Simulation ausführen und Zustände darüber versenden.

Haltet Ihr es für gut oder ausreichend den Server also ebenfalls mit diesem Framework zu entwickeln und im Server-Programmcode einfach nur nichts zu rendern, sprich die Draw-Calls weg zu lassen? Klingt irgendwie zu einfach finde ich. :)
Es handelt sich hier nur um ein Hobby-Ding, dennoch will ich nicht völlig in die "falsche" Richtung laufen.

Hi,

ich denke es kommt stark darauf an, wie du die Logik unterteilen willst und welche Art Spiel du machen möchtest.
Ich gebe mal ein paar (sehr grobe) Beispiele:

Strategie-Spiel: (z.B. AoE, 0ad, ...)
Hier braucht man Server-seitig kaum Kollisionsabfragen. Der Server muss hauptsächlich prüfen, ob eine Einheit die vom Client übermittelte Strecke in der angegebenen Zeit schaffen könnte.
Die Kämpfe der Einheiten hingegen werden meist auf dem Server berechnet. Deshalb sieht man unter schlechten Netzwerkbedingungen öfter bei solchen Spielen, dass eine Einheit meilenweit vorbei schießt, aber dann trotzdem trifft, oder ein Katapult anscheinend genau trifft, aber es irgendwie nicht zählt.

RPG: (z.B. WoW, ESO, ...)
Hier ist der Server selbst mehr oder weniger nur eine Datenbank. Cheaten kann daher theoretisch jeder - auf dem Server läuft jedoch ein Check auf die Position etc. des Spielers, ob das ungefähr hinkommt. Wenn nicht - kick und ban.
Bewegung und Kollisionsabfrage machen hauptsächlich der Client. Das Auslösen der Skills und die Schadensberechnung finden auf dem Server statt.
Wenn man eine schlechte Verbindung hat, kann man das sehen: Der Spieler läuft eine weile, oder clippt sogar durch die Wand, und wird dann später vom Server resettet.
Außerdem klickt man auf Skills, und es passiert erstmal nichts... bis der Server das Auslösen bestätigt, dann macht der Skill schaden und geht auf Cooldown.

Ego-Shooter: (z.B. Quake, Unreal)
Hier kann man dem Client überhaupt nicht vertrauen.
Der Server macht fast alle Berechnungen nochmal, übermittelt ganz akribisch nur Positionen von Gegnern an den Client, die er auch tatsächlich sehen kann (Anti-Wallhack), prüft ganz genau alle Kollisionen und Positionen der Spieler.
Das geht deshalb, weil auf einem Server nur eine sehr begrenzte Spieler-Anzahl ist.


Je nach Spiel kann der Server also je Bereich (Kollisionsabfrage, Überprüfung der Berechnungen der Clients) etwas weniger oder etwas mehr machen.

PS: Schon früher gab es auch immer Debatten darüber, ob UDP oder TCP... und dann kommt einfach World of Warcraft und sagt "scheiß drauf", bedient sich einer einfachen Portal-Engine und macht alles in TCP* mit hunderten von Spielern. Und es läuft einfach.
(* außer den Voice-Chat)

Wo soll die Reise denn ungefähr hingehen?

Die Reise soll irgendwo zwischen Deinem WoW, ESO und Quake bzw. Unreal Beispiel enden, allerdings 2D statt 3D.
Den Begriff Netzwerkspiel habe ich vielleicht unpassend gewählt, es ist damit kein lokales Netzwerk gemeint sondern schon das Internet, was bedeutet dem Client nicht zu trauen.

Ich glaube mein Knoten hat sich aber gelöst.
Ich hatte gedacht ich müsste aus MonoGame die Klasse "Game" verwenden, die kapselt im Grunde die Game-Loop weg und stellt dann Methoden wie Update/Draw zur Verfügung in der man seinen Stuff machen kann.
Ich muss diese Klasse aber ja überhaupt nicht verwenden, ich kann in meinem Server ja meine eigene Game-Loop haben und dennoch Teile des Frameworks verwenden (Kollisionserkennung, Mathe-Helper etc.).
So kennt der Server die Geometrie und ich verwende ein Framework bzw. die selben Klassen und Methoden.

Mir ist klar das TCP vermutlich ausreichend wäre und ich damit schneller wäre. Da das Ziel aber nicht ist etwas fertig zu bekommen sondern Fehler zu machen und etwas zu lernen habe ich mich bewusst für UDP entschieden. Vor allem weil ich in C# mal einen asynchronen UDP Socket Server schreiben will.

MonoGame habe ich im übrigen gewählt weil ich damit die Option habe den Client auch als App auf einem Mobilgerät zu testen.

Für Dich wahrscheinlich kein Ziel, aber auch zu bedenken wäre ein Headless Server. Also ein Kommandozeilen-Programm, dass keinerlei Fenster, Grafik, Sound, irgendwas hat, sondern halt nur... served. Kann gut sein, dass das mit Monogame gar nicht geht. Aber das ist kein Problem, Du wärst in guter Gesellschaft

Schrompf hat geschrieben: ↑13.06.2019, 08:26 Für Dich wahrscheinlich kein Ziel, aber auch zu bedenken wäre ein Headless Server. Also ein Kommandozeilen-Programm, dass keinerlei Fenster, Grafik, Sound, irgendwas hat, sondern halt nur... served. Kann gut sein, dass das mit Monogame gar nicht geht. Aber das ist kein Problem, Du wärst in guter Gesellschaft

Guter Punkt. Wäre natürlich schon schön wenn das auch als Windows-Service laufen könnte, oder wie Du sagst als Konsolenprogramm. DIe Projektstruktur habe ich mir angelegt und den Server erstmal als Konsolenprogramm erzeugt. Mal schauen was passiert. :)