spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Huhu,

es würde mich sehr interessieren was aus eurem Projekt geworden ist. D.h welche
Fortschritte ihr gemacht habt, an was ihr zurzeit entwickelt und vielleicht ein
paar neue Screenshots verlinken.

Liebe Grüße Toa

Hi Toa!

Momentan sind wir noch dabei die neuen Server und den angepassten Client auf den alten Stand zu bringen.
Als Ziel für dieses Jahr haben wir uns dabei gesetzt diesen Prozess abzuschließen und unser geplantes Minigame umzusetzen.
Da das Minigame schon alles können muss was das spätere Spiel können soll würde dies bedeuten, dass wir ab diesem Punkt anfangen könnten den eigentlichen Inhalt umzusetzen.

Server
Die Server wurden bzw. werden komplett neu geschrieben.
Der Anmeldeserver ist seit längerem fertiggestellt und auch online.

Der ursprüngliche Spielserver wurde nun aufgeteilt in einem Hauptserver und dem Weltserver.
Der Hauptserver verwaltet die Character, koordiniert den Chat und verwaltet die Weltserver.
Dieser Hauptserver ist soweit auch schon fertiggestellt und online. Was hier noch fehlt ist der Wechsel der Zonen von einem Weltserver auf einen anderen.

Ein Weltserver verwaltet das Spiel. Es ist nun so angelegt, dass es aus mehreren Zonen bestehen kann. Ein Weltserver kann ein oder mehrere solcher Zonen verwalten. Derzeit ist ein Weltserver online. Mit der nächsten Veröffentlichung wird es erstmal eine Zone geben auf der das Minigame läuft. Später werden nach und nach Zonen dazu kommen.

Intern sind alle Server neu organisiert und auf viele verwendeten Bibliotheken wurde verzichtet (bsp. RakNet und mysql++). Tyroxx (unser Server-Programmierer) hat die Funktionalität dieser Bibliotheken selbst implementiert. Das Netzwerk basiert nun nicht mehr auf UDP sondern TCP.

Client
Der Client wurde an das neue Protokoll der Server angepasst. Auch die Datenstruktur der Spielwelt wurde überarbeitet, sowie das Interface.
Dalon (unser Client- und Tool-Programmierer) hat sämtliche verwendeten Bibliotheken aktualisiert und viele Verbesserungen wie Shader für weichere Schatten hinzugefügt. Das Interface kann nun unabhängig von CPP Code entworfen und programmiert werden. Ob wir dies nutzen um Spieler das Anpassen der Oberfläche zu ermöglichen, wissen wir noch nicht.

3D Modelle
Zu den bisherigen Modellen hat sich noch eine neue Menschenfrau hinzugesellt. Da ihr noch keine Kleidung verpasst wurde kann ich aus Jugendschutzgründen kein Screenshot von ihr veröffentlichen. Ich hoffe ihr versteht das.
Andere Modelle wurden in ihren Animationen überarbeitet. Sie bewegen sich jetzt etwas natürlicher.
Zudem wurden mache Modelle überarbeitet. Ziel ist es im späteren Spiel Variationen anzubieten. Also verschiedene Frisuren und Variationen durch Ausrüstung.

Musik
Hier hat sich nichts getan. Das liegt jedoch daran das wir von Sebastian mit so viel guter Musik versorgt wurden, dass wir damit problemlos das erste Kapitel des Spiels musikalisch untermalen können.

Tools
Alle Tools wurden weiter entwickelt und immer mehr davon wird von C# auf CPP portiert. Angefangen hat es mit dem Spieleditor. Ogre3D für C# konnte das was wir brauchten einfach nicht so gut wie die CPP Version. Daher wurde der Editor nun von Dalon mit wxWidgets und Ogre umgesetzt.
Derzeit wird er zum Gestalten der Levels genutzt, später sollen mit ihm noch Spielinhalte gesetzt werden können.
Tools wir unser Archivmanager wurden weiterentwickelt und werden derzeit auf CPP mit wxWidgets portiert um von C# los zu kommen.



Für dieses Jahr haben wir uns vorgenommen wieder mehr zu veröffentlichen und den aktuellen Client heraus zu geben. Verständlicherweise warten wir damit noch bis wir wieder etwas an Inhalt haben den wir präsentieren können. Das heißt wir werden zumindest das Scriptsystem für die Spells wieder zum laufen bringen und den Level des Minigames in seinen Grundzügen gestallten.
Termine haben wir uns keine gesetzt ich hoffe jedoch das wir es ende Q1 bzw. Anfang Q2 schaffen werden.

Screenshots wird es vorher noch geben.


Ein frohes neues Jahr euch allen!


Grüße

Chriss & das Faudra Team

Das geht ja richtig gut vorwärts bei EUch! Mit einem laufenden Server und einem verbindungsfähigen Client seid ihr ja schon Meilen weitergekommen als die meisten sonsten MMO-Projekte. Nur eure Bestrebung, Fremdbibliotheken rauszuwerfen und bestehende Tools selbst neu zu implementieren, halte ich für unschlau. Das riecht für mich sehr nach NIH-Syndrom. Und das kann man sich bei einem so gigantischen Projekt wie einem MMO eigentlich nicht leisten.

Viel Erfolg.

Zitat von »Schrompf«

Nur eure Bestrebung, Fremdbibliotheken rauszuwerfen und bestehende Tools selbst neu zu implementieren, halte ich für unschlau. Das riecht für mich sehr nach NIH-Syndrom.

Danke erstmal für das Lob und die Wünsche.
Im Grunde hast du da vollkommen recht. Wir verwenden daher auch vieles was wir frei verwenden können.
Bei RakNet war es letztendlich die Lizenz warum wir darauf verzichtet haben.

Bei den Tools kommt es darauf an was es gibt. Die GUI basiert auf CEGUI und hierfür verwenden wir fertige Tools.
Bei Archiv- und GameEditor haben wir zu speziefische Anforderungen als das wir etwas fertiges nehmen können.

Grüße Chriss

Das "NIH-Syndrom" ist nur dann negativ zu betrachten wenn es um Profit geht, btw.
Und bis jetzt rieche ich nichts, was mit "Profitgeilheit" oder so einhergeht .

Von daher... es kann nicht schaden, es so zu machen. Muss halt jeder selbst wissen, ich finds jedenfalls gut, dass es tatsächlich Projekte derartiger Größe gibt, die nicht einfach so im Nirvana verschwinden.

Vielen Dank für das informative Update!

Finde es super dass ihr nach wie vor dran seid, so wird das was

Hmm es ist in sofern interessant, dass wir nun auch schon seit mehreren Jahren dran sind und gerade die Selbstentwicklungen in einigen Fällen eher hinderlich waren (wobei die meisten Selbstentwicklungen zu einem Zeitpunkt stattfanden, wo die verfügbaren Lösungen leider das Anforderungsprofil nicht immer komplett erfüllten und daher notwendig waren. Nur da unser Projekt schon eine weile läuft gibt es schon einige Lösungen, während unsere Selbstentwicklungen eher Sackgassen sind; Beispiel: xml-bib die unicode nativ unterstützt; Fanden damals keine, gibts heute aber wie Sand am Meer).
Sprich ihr macht eher eine gegenläufige Entwicklung . Interessant finde ich euren Schritt weg von UDP hin zu TCP. Ich selbst nutze auch TCP aber auch nur deshalb, weil unser komplettes Netzwerkkonzept auf reliable transport basiert.
Mich würden ja die Gründe für den Wechsel von UDP zu TCP interessieren. Und der Schritt weg von Netzwerklibs, weil Netzwerk abseits von einfachen Chatanwendungen ist nicht gerade trivial, bzw. birgt viele "Angriffsstellen". Könntet ihr da so ein paar Beweggründe preisgeben?

Das wir nichts fertiges für das Netzwerk nehmen ist eigentlich keine große Sache. Die alte Servergeneration hatte die lib nur aus Komfortgründen genutzt. RakNet war einfach bequem da es mir nur vollständige Pakete lieferte und im entsprechenden Modus zuverlässig wie TCP war.
Mit der Zeit hat sich herausgestellt das wir alle Pakete als reliable vesand haben. Einzige Ausnahme waren die Bewegungsdaten.
Aber gerade hier war es eigentlich unklug, da diese nicht wie bei Schootern gesendet wurden, sondern mehr wie Wegpunkte waren.
Da die Wegpunkte in der richtigen Reihenfolge abgelaufen werden sollten ist auch hier die Reihenfolge entscheidend. Da TCP zuverlässig und sortiert ist hat es hier große Vorteile. Bei anderen Paketen ist die sortierung für uns zwar nicht so wichtig, stört jedoch nicht.
Dalon und Tyroxx haben die TCP Klasse von Tyroxx mit meiner Verwendung von RakNet verglichen und keine spürbaren Geschwindigkeitsunterschiede festgestellt.
Ich muss zugeben, dass ich damals vermutlich RakNet einfach falsch verwendet habe. Bei meiner Art der Nutzung und wie es jetzt mit der TCP Klasse getan wird können wir leicht selbst entscheiden welche Positionsänderungen an welche Spieler weitergeleitet werden sollen. Bei RakNet war mir das in den Beispielen nicht so ersichtlich (also wie ich Clients ausschließe).

@Nox ich habe mir mal die von dir verlinkte Lib (SyncSys) angesehen (eigentlich nur die Featurelist gelesen) und mir ist gleich eine Frage zu Kopf gekommen.
Ist es dort möglich festzulegen wann ein Objekt synchronisiert werden muss oder nicht? Z.B. basiert die Welt von Faudra aus riesigen Tiles. Jedoch sind nur das Tile des SPielers und die umliegenden Tiles interessant. D.h. wir erzeugen Objekte beim Client nur wenn sie für ihn interessant sind. Ebenso senden wir nur Bewegungsdaten an Spieler der gleichen bzw. angrenzenden Tiles. Ist es möglich solch ein Verhalten mit dieser (oder einer anderen Lib) festzulegen?
Mir ist bisher nicht bekannt, dass es geht, weswegen wir uns u.a. dagegen entschieden haben.

Chriss wo besteht das Problem bei Raknet wenn du Daten nur an bestimmte Spieler schicken willst? Also ich sehe das Problem nicht, das geht doch ohne Probleme?

Also es ist definitiv möglich bei RakNet festzulegen an welche Clients/Gruppen ein Paket gesendet wird, aber RakNet kann ich dennoch nicht empfehlen (persönliches Empfinden). Begründung siehe http://networklibsbenc.sf.net .

@chriss ich hoffe ich habe deine Fragen richtig verstanden, aber was du da beschreibst nennt sich bei vielen Libs "visibility" und ist integraler Bestandteil von vielen Libs (nach meiner Kenntnis gibt es sowas bei jeder "höheren" Lib). Bei syncsys ist es definitv möglich die "Sichtbarkeit" zu beeinflussen. Im Prinzip arbeitet syncsys auf Serverseite in 2 (bzw 3 wenn man den TCP Transport mitnutzt/rechnet) Ebenen:

1. Objekte (NetEntity)
2. Clientrepräsentation auf dem Server (SyncServerClient)

Die Sichtbarkeit wird bei syncsys per NetEntity::ClientNeedsUpdates(SyncServerClient*), welche man überladen kann, geregelt. Dabei kann man per 8 bit Flag genau definieren welche Daten vom Client empfangen werden soll. Welche Daten zu welchem Flag gehören entscheidet der Programmierer.
Entscheidender Unterschied von syncsys zu anderen libs ist, dass anders als z.B. RakNet nicht "pro Client und pro Änderung" die Daten serialisiert werden, sondern die Serialisierung nur einmal im Falle einer Änderung geschieht. Nach der Serialisierung werden die Daten bei allen SyncServerClients, welche die Daten "sehen" können, hinterlegt. Der Server wiederum updatet die SyncServerClients im einem einstellbaren Intervall, packt die angesammelten Updates für die Objekte zusammen und schickt es als ein "Paket" an den repräsentieren Client.

-Vorteil keine n Serialisierungen pro Änderung (n=Anzahl Clients, welche die Daten brauchen)
-Nachteil keine supergenaue Anpassung der Daten an den Client möglich

Hauptaspekt bei syncsys ist halt, dass es gut mit der Anzahl der Threads skaliert. "Sichtbarkeit" können eigentlich alle soweit ich weiß.