spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Danke Nox für die Aufklärung.

@Zero: Wie du siehst hatte ich damals RakNet einfach falsch genutzt.

Da die Umstellung schon ein Jahr lang läuft werden wir für Faudra keine (Netzwerk-) Lib nehmen.

Zu allererst Herzlichen Glückwunsch zu den tollen fortschritten ich hätt nicht gedacht das ihr es so weit schafft. Respekt!!
Was denkt ihr wie lang ihr noch braucht und wo kann man das Spiel einglich downloaden auf der website seh ich nähmlich nur patches ?
MfG Lennard und weiterhin Gutes gelingen !!!

Hallo Lennard007,
vielen Dank für deinen Beitrag.
Wie lange wir noch brauchen ist nicht abzusehen und wir vermeiden es uns auf wilde Spekulationen einzulassen. Derzeit steht kein Client zum Download bereit. Alle öffentlichen vorherigen Clients sind nicht mehr verwendbar (u.a. wg. der neuen Server) und können deinstalliert werden.

ahh danke könntest du mir vllt ne nachricht schiken wenn ihr einen clint zum donload freigebt der kompatibel mit den neuen servern ist ? wäre echt nett

Wie sieht eigentlich euer Netzwerkkonzept aus, weil ich habe mich damit seit einiger Zeit beschäftigt und bisher noch keinen Ansatz gefunden/gesehen der mich komplett überzeugt hat.
Verteilt euer Server die Nachrichten einfach weiter oder verschickt ihr die veränderten Spieldaten? Wie habt ihr die "Sichtbarkeitsüberprüfung" gelöst? Aktualisiert ihr die regelmäßig, oder immer nur bei Änderungen? Wie geht ihr mit der Sichtbarkeit an den Zonengrenzen um? Nutzt ihr multithreading für die verschiedenen Datenbereiche (z.B. Zonen)?
Falls ihr multithreading nutzt: wie habt ihr den zugriff auf die netzwerkebene geregelt/wie behandelt ihr den Datentransfer aus n-threads zu m-clients?
Falls ihr veränderten Spieldaten verschickt: Wie behandelt ihr die Fälle "neuer Client","neues Objekt","Client ändert seinen Zustand","Objekt ändert seinen zustand"? Wie stellt ihr die Änderungen fest? Welche Daten verschickt ihr bei der Änderung (diff von neu zu alt oder gesamte Objekt oder teile des Objekts)? Serialisiert ihr die Daten pro Änderung und pro Client oder nur pro Änderung?

Die Frage ist für mich jetzt etwas schwierig zu beantworten da ich nur den alten Server-Code, jedoch nicht den neuen kenne.
Ich habe mich jedoch bei Tyroxx (unserem Server Programmierer) schlau gemacht und hoffe die Frage richtig beantworten zu können.

Es gibt einen Hauptthread der über select() die Daten pollt und verarbeitet. Die Daten werden dann serialisiert und in die Sendepuffer der Clients geschrieben. Daten wie neue Positionen werden dabei nur einmal serialisiert und in die entsprechenden Puffer der umliegenden Clients geschrieben. Am Ende werden alle Daten der Clientpuffe an die Clients gesendet.

Soweit ich informiert bin werden in der jetzigen Form blockierende Aufrufe möglichst vermieden, was eine Verarbeitung in einem Hauptthread ermöglicht. Mir/uns ist jedoch bewusst, dass es späternicht mehr möglich sein wird, alle Informationen im RAM vorzuhalten. Hier werden später wohl noch Threads hinzukommen die für das Nachladen und speichern von Daten nötig sein werden.

Die Sichtbarkeitsprüfung ist an unsere Karten angepasst. Diese sind Tile basiert. Ein Spieler bekommt also nur die Informationen zu seiner Tile und zu den angrenzenden Tiles. Bei dem Wechsel einer Tile werden entsprechende Informationen gesendet. Also welche Spieler/Objekte sind neu, welche müssen gelöscht werden, da sie nicht mehr im Sichtbarkeitsbereich liegen. Ebenso werden andere Clients informiert, dass ein Spieler gelöscht/hinzugefügt wurde.
Desweiteren wird die Welt in mehrere Hauptbereiche aufgeteilt. Diese sind logisch so weit getrennt, dass der Spieler nie direkt wechseln kann. Hier sieht der Spieler einen Ladebalken wenn er diese Bereiche wechselt. Ein Server verwaltet ein oder mehrere dieser Hauptbereiche. So wollen wir die Last auf mehrere Server verteilen. Schön wären angrenzende Hauptbereiche zwischen denen der Spieler ohne Ladebalken wechseln kann. Hier stehen Aufwand und Nutzen jedoch in keinem günstigen Verhältnis für uns,weswegen wir das vorerst nicht versuchen werden.


Ich hoffe die Fragen wenigstens halbwegs beantwortet zu haben.
Sobald wir wieder soweit sind, dass die Spieler auf der Welt miteinander interagieren können (also kämpfen), werden wir den Client wieder zu Verfügung stellen und einen Termin für einen kleinen Lasttest angeben.
Gerade für mich wird es dann sehr interessant zu sehen wie gut sich der neue Server im Vergleich zu dem alten schlägt, da ich ihn ja geschrieben hatte
Ich hoffe der alte wird um Längen geschlagen.
Für diejenigen die es interessiert. Auch der alte Server hatte einen Hauptthread für die Verarbeitung der Netzwerkdaten. Diese wurden jedoch sofort verarbeitet und gesendet. Timer von Spells, sowie die Ausführung Dieser liegen wie die NPC KI in jeweils einem eigenen Thread.


Grüße Chriss

Okay wenn ich das richtig verstehe, habt ihr somit nicht das Problem worauf Syncsys hauptsächlich ausgelegt ist. Bin ja mal gespannt wie weit ihr Clientzahl+Objektdichte pro Bereich mit diesen Ansatz hochtreiben könnt .

Zitat von »Nox«

... habt ihr somit nicht das Problem worauf Syncsys hauptsächlich ausgelegt ist...

Welches Problem meinst du genau? Die Verteilung mehrerer Spieler/Verbindungen auf mehrere Threads und deren Synchronisation?

Jaein, mehrere Thread ist natürlich ein Punkt, aber wenn ich das richtig verstehe gibt es ja bei euch nicht das Problem, dass der Client gleichzeitig Informationen von mehreren Zonen erhält (zumindest nicht über ein und die selbe Verbindung). SyncSys habe ich mit dem Grundgedanken entwickelt, dass das Spiel wofür ich es entwickelte möglichst hohe Spielerdichten erreichen sollte, sprich möglichst viele Spieler im gleichen Interaktionsbereich. Somit entsteht die "Notwendigkeit", dass schon ein Interaktionsbereich aus vielen Zonen bzw. von vielen Threads aktualisiert wird. Nun wäre es ja eine legitime Option, dass man einfach pro Thread/Zone eine Verbindung aufbaut und somit den sync-Mist umgeht (eig hätte ich glatt mal testen sollen, wie gut das im Vergleich skaliert bzw. wie der Vergleich mit syncsys performancetechnisch ausfällt...).
Wenn aber alles über eine Verbindung soll, muss man ja die Daten von den Threads alle in die Verbindung hineinbekommen, was für wenige Threads noch unproblematisch ist, aber bei sehr vielen Threads dann schon schnell eng werden kann (starving etc.).
Dies allein würde aber die "Komplexität" von syncsys noch nicht rechtfertigen, aber das Spiel für das Syncsys entwickelt wurde, ist durch eine sehr tiefe Baumstruktur der Objekte geprägt, sodass die Sichtbarkeitsprüfung aus Performancegründen entlang des Baumes durchgeführt wird (was aber wieder auf Grund der vielen Threads in der Baumstruktur auch nicht so naiv gemacht werden sollte).
Natürlich kann syncsys auch wunderbar für kleine und wesentlich weniger komplexe Anwendungsfälle genutzt werden, aber die volle "Macht" von syncsys ist auf stark parallelisiert Anwendungen ausgelegt.

Ich habe grade mal auf eure Webseite geschaut und gesehen, dass seit Mai nichts mehr neueres gepostet wurde :?
Gibt es euch bzw. Faudra denn noch? Wäre sehr sehr schade drum!