spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

@Saik0: Dankeschön

Zitat von »TrommlBomml«

@ LInsoDeTe: Womit habt ihr eure Client-Server Architektur aufgebaut? Lidgren? Wäre interessant

Nein, da kam kein Framework ins Spiel, das ist gutes altes handgemachtes TCP, mit System.Net.Sockets.TcpClient und System.Net.Sockets.TcpListener

Das liegt aber auch daran, dass Server und Client selbst nur stumpfes senden und empfangen erledigen und die empfangenen Sachen dann per Callback einfach nur weiterleiten.
Das Parsing der empfangenen Infos übernimmt dann eine MapManager.dll, die sich um alles kümmert, sprich Spielerinfos übertragen, Blöcke verwalten, Chunks laden, speichern, entladen, neues Terrain generieren... (insgesamt 5 Threads).

Auf diese Weise kann ich die MapManager.dll sowohl im Singleplayer, als auch im Multiplayer verwenden und muss nicht alles doppelt implementieren. Im Singleplayer werden die Strings dann direkt an die DLL geschickt, im Multiplayer steckt eben noch eine stumpfe 1:1 TCP Übertragung dazwischen.

Zitat von »Schorsch«

Parsen erledigt bei euch der MapManager? Wäre es nicht sinnvoller dafür eine Zwischenschicht zu implementieren? Die könnte ja parsen und dann die jeweiligen Befehle weiterreichen. Doppelt müsstest du da eigentlich auch nichts erledigen.

Da habe ich mich bewusst gegen entschieden, da ich auf diese Weise auf Clientseite nicht unterscheiden muss, ob ich online oder offline bin. Das Spiel produziert nur Befehle in Form von Strings und gibt sie an die Clientklasse weiter. Diese entscheidet dann, ob sie es direkt an den MapManager sendet, oder per TCP verschickt. Der Server pflückt nur den TCP Stream auseinander und reicht die Stringbefehle seinerseits an den MapManager weiter. Genauso erhält die Clientklasse die Antwort entweder über den TCP Stream oder direkt vom MapManager lokal.


Bei einer Zwischenschicht müsste ich im Spiel selbst unterscheiden, ob ich Befehle ausführe, oder verschicke. Das erledigt jetzt die Clientklasse, da die Befehle immer per String kommen.


Ein weiterer Vorteil dieses Ansatzes ist, dass ich das komplette Handling in einer Klasse mit Multithreading liegen habe (Da sind insgesamt 5 parallele Threads am Werk). Gerade wenn es z.B. um das Generieren von Terrain geht, was recht rechenaufwändig ist, habe ich hier beim lokalen Spiel einen enormen Performancegewinn, als wenn der MapManager direkt angesprochen würde. So hatte ich es nämlich vorher und das war echt übel...

Und PS: Auf diese Weise ist es später auch sehr leicht, ein lokales Spiel ebenfalls z.B. als LAN-Spiel zu öffnen.

So, mal wieder ein kleines Update Wie ihr sehen könnt, ist unsere Asteroidenbasis fast fertig

Desweiteren ist auch ein erheblicher Teil der Wirtschaft jetzt fertig. Auf dem Screenshot seht ihr, wie der Miningtower Nuggets produziert. Der Typ der produzierten Nuggets hängt von den Rohstoffvorkommen im Boden unter dem Turm ab (auf dem Screenshot ist es Gold). Diese können dann als Items per Drag & Drop auf Schiffe geladen werden (Schiffmenü links). Das komplette Item/Blöcke Drag & Drop Prinzip funktioniert mit jedem Gebäude, das Ressourcen-Interaktion erlaubt (z.B. das Ressourcenlager, oder die Gießerei, die aus den Nuggets Blöcke macht) sowie jedem Schiff, das Ladeplätze hat (dazu müssen im Schiffsdesigner Laderäume platziert werden, ein simples Kampfschiff ohne Laderäume hat natürlich dann auch keine Item Slots) und ist vollständig fertig implementiert.

Als nächstes stehen auf der ToDo Liste: Die Funktionalität der Gießerei fertig machen (d.h. Nuggets in Blöcke umwandeln, ähnlich wie der Ofen in Minecraft, sowie das Produzieren von Items wie Antennen, Bojen etc. aus bestimmten Rohstoffen), ein paar mehr Sektortypen in den Terraingenerator einbauen, sowie die Integration von Sonnen und Sonnenkollektoren. Wenn das fertig ist, soll die erste öffentliche Alpha steigen. Was hoffentlich am Mittwoch der Fall sein wird. Hoffe, viele von euch sind dabei :-)