[Projekt]Dungeon of old Monsters: Geisterwelten

[Lord Delvin]

OT: Wenn du eine etwas andere breitere Nutzersphäre ansprechen möchtest, könntest du mal überlegen das ganze in AS3/Flash/Flex zu entwickeln.

Wann in denen gegen ne C lib linken kann, dann ist das kein Problem nen Client dafür zu schreiben, weil das Spiel an sich in ner lib entwickelt wird. Ist denk ich ungewöhnlich, aber scheint ganz gut zu funktionieren.

[Chromanoid]

ne das is leider nicht möglich :)

[Lord Delvin]

Hatte jetzt ziemlich viel mit Uni zu tun und war etwas demotiviert, weil ich feststellen musste, dass es einigen Overhead mit sich bringt, wenn man von anfang an mit threads arbeitet und ich glaub doch lieber erst mal was spielbares haben will, bevor ichs wieder parallel mach.
Meint ihr das is n guter Weg?

Gruß

[Chromanoid]

ja auf jeden fall! die meisten spieleprojekte scheitern doch genau daran, dass die leute sich zu viele technische features überlegen, die erstmal gar nicht gebraucht werden. der endbenutzer bekommt davon ja meistens eh nichts mit.

[Lord Delvin]

So, hab jetzt beschlossen, den Thread hier zu schließen und das Projekt komplett umzubauen:

Das Designdokument bleibt erstmal wies ist, wird aber erstmal nicht mehr angerührt, von der Ideeen Sektion mal abgesehen.

Die lib wird in drei Teile zerschlagen:

libmpl: Message Passing Lib, also was, was Nachrichten über Kommunikatoren verschickt. Etwas von MPI inspiriert, wird aber wesentlich funktionsärmer und ist eher auf smp als auf netzwerk ausgelegt. Geplant ist die lib dann für netzwerk und thread kommunikation gleichermaßen einzusetzen. Das würde denk ich den code in der core lib wesentlich schöner machen.
Diese lib könnte für andere hier vielleicht auch interessant sein, also falls interesse besteht könnte man das auch gemeinsam als GPL oder freier entwickeln, macht man weniger Fehler und hat mehr Spaß:)

libgw-core: Das was ursprünglich mal libgw sein sollte, ohne das Interface. Ich hab beschlossen, dass die Threads eigentlich unabdingbar sind, da sie spätestens wenn man Netzwerk hat keinen echten Implementierungsoverhead mehr verursachen. (Wir reden hier über C++ nicht über Java:P Ich bin ein Fan von transparenten Proxys und so nem Kram...Performance ist ja nicht so unglaublich wichtig, wenn man bedenkt wieviele rechenkerne vermutlich zur verfügung stehen werden. Und so wie ich das sehe verwenden die meisten freien Grafikengines keine Threads automatisch...aber selbst wenn wärs nicht so schlimm, Performance ist immer das allerletzte Problem)

libgw-interface: Das Interface zwischen core und lib. Das wird aus zwei Gründen rausgeworfen: Erstens hat Codeblocks momentan Probleme mit Klassen die gleich heißen, aber in unterschiedlichen Namespaces liegen; das is ziemlich nervig, aber nicht so richtig gut zu umgehen, weil man einfach die Map auslesen will und es intuitiv Map heißen muss und nicht irgendwie MapReader oder so ähnlich. Es ist aus sicht des Clients einfach die Map. Zum anderen bin ich mir noch nicht so ganz sicher wie genau das Interface aussehen sollte. Die erste Implementierung hat sich jedenfalls als etwas unglücklich erwiesen. Außerdem möchte ich den Code von nicht Interface und Interface noch strikter trennen als ich das bisher gemacht hab.

Der sfmlclient wird neu geschrieben.

Die neue Roadmap sieht ungefähr so aus:

0.1:
libmpl schreiben.
kleine chatdemo mit sfml mit je 2 threads und 2 clients.

dann ist der netzwerkspaß erstmal lange zeit fertig. das wird vermutlich in unspielbarem verhalten über internet resultieren, is aber wirklich erstmal nicht wichtig.

0.1b:
core:
Gamestates und Aktionen.
Ich glaub es ist sinnvoller von der Interaktiven Seite aufzubauen als von der statischen, da das Testen dann einfacher ist. Außerdem muss man dann den Testclient nicht dauernd anfassen.

interface:
Alles, was eben nötig ist um die Internen zustände von Testclient und core zu synchronisieren.

Wenn das fertig ist, dann sollte der Testclient im prinzip sowas wie ein Chatserver sein, der allen anderen "Mitspielern" mitteilt, was der Spieler grad für aktionen ausführen möchte. Außerdem sollte es Spielzustände für Lobby/Game running/Game paused geben.

Danach würde ich dann in der jetztigen Roadmap weitermachen, wobei Version 0.3 entfällt, da die ja quasi vorgezogen wurde.


Vielleicht kann mir irgendjemand mit Erfahrung sagen, ob das ne gute Idee ist das so zu machen oder nicht. Ich glaub jedenfalls, dass ich den Code den ich bis jetzt geschrieben hab eigentlich komplett in die Tonne treten will. Aber ist ja normal, war bei APE auch so und daraus is was nettes geworden danach:)

[Chromanoid]

OT: Wenn du eine etwas andere breitere Nutzersphäre ansprechen möchtest, könntest du mal überlegen das ganze in AS3/Flash/Flex zu entwickeln.

Wann in denen gegen ne C lib linken kann, dann ist das kein Problem nen Client dafür zu schreiben, weil das Spiel an sich in ner lib entwickelt wird. Ist denk ich ungewöhnlich, aber scheint ganz gut zu funktionieren.

ne das is leider nicht möglich

muss mich da korrigieren. du kannst dir mal adobe alchemy anschauen :)

und wie siehts sonst so aus? hast du schon ein von dir geplantes gameplay feature prototypisch testen können?

[Lord Delvin]

OT: Wenn du eine etwas andere breitere Nutzersphäre ansprechen möchtest, könntest du mal überlegen das ganze in AS3/Flash/Flex zu entwickeln.

Wann in denen gegen ne C lib linken kann, dann ist das kein Problem nen Client dafür zu schreiben, weil das Spiel an sich in ner lib entwickelt wird. Ist denk ich ungewöhnlich, aber scheint ganz gut zu funktionieren.

ne das is leider nicht möglich

muss mich da korrigieren. du kannst dir mal adobe alchemy anschauen :)

und wie siehts sonst so aus? hast du schon ein von dir geplantes gameplay feature prototypisch testen können?

Nich so gut. Uni war und ist ziemlich im Weg:-/

Ich hatte erst irgendwie versucht das von der Spielmechanik her aufzuziehen, aber ich glaub das funktioniert nicht; war da aber eigentlich ganz gut vorangekommen. Wenn ich mpl soweit hab, dass es über netzwerk funktioniert, werd ich den alten code da wieder reinmergen, dann wird man vermutlich relativ rasch was testen können. Allerdings sind mir noch erschreckend viele Dinge sehr unklar. Z.b. wie ich die Kreaturen eigentlich steuern will. Also wie genau man das mit der KI macht. Eigentlich hatte ich keine lust mich da selbst drum zu kümmern, aber ich glaube, dass es sonst auch keiner macht und das Spiel wird ziemlich schnell nicht mehr spielbar, wenn deine Kreaturen einfach nur rumstehen und nix machen.

Das mit dem Alchemy sieht eigentlich nett aus. Wenn ich die lib soweit hab, dass man ein Spielerlebnis hat, werd ich ma schaun ob ich jemand finde, der sich mit flash auskennt und mit dem zusammen einen client produzieren. Atm wirds aber einmal mehr sfml.

Ich glaub ich gönn mir heute mal ne Lernpause:D

[zwergmulch]

Hi, ist ja'n ganz interessantes Projekt mit guten Ideen auf dass man sich freuen kann. :)

Zu Flash/Flex/AS3/...: Du könntest einen Teil (vor allem bzw. nur die libMPL) ja auch in Java machen
und libGW-core und libGW-interface dann in C++ und die mit JNI linken.
So wäre das auch direkt in der Website als Applet einbettbar oder jedenfalls leicht verteilbar(Java Webstart oder anderes). 8-)
Netzwerkcode ist in Java so ziemlich das leichteste was ich kenn' und Performance sollte
imo nicht das Problem sein da das Netzwerk sowieso langsamer ist.

Darauf hoffend, dass meine Idee dir weiterhilft - zwergmulch

[Lord Delvin]

Netzwerkcode ist in Java so ziemlich das leichteste was ich kenn' und Performance sollte
imo nicht das Problem sein da das Netzwerk sowieso langsamer ist.

Darauf hoffend, dass meine Idee dir weiterhilft - zwergmulch

Das wäre ne durchaus gute Idee, wenn ich nicht beschlossen hätte meine gesamte synchronisation über mpl zu machen, also auch message passing für lokale threads.(Ich verwende sowas wie ownership als threading ansatz)
Und für lokale threads ist es vermutlich zu langsam (mindestens) zweimal durch die java barriere zu laufen bevor ich meine message zugestellt hab. So muss ich ja nur zweimal n pointer kopieren und n bisschen was in meinen magictrick listen einfügen. Das ist glaub ich im worst case schon schneller als einmal durch die java barriere, zumindest wenn man annimmt, dass der deamon nicht grad schlafen gegangen ist, weil keiner was geschickt hat.

Auuußedem kann ich dann nicht mehr so geile sachen machen wie das typeenum auf userseite zu erweitern oder ne get funktion als template, damit man bei jeder message get<const char*>() schreiben kann und man bekommt den inhalt als cstring:D

EDIT: Das mit mpl in Java schreiben hat im übrigen auch einen theoretischen Haken: Wenn ich pointer auf Objekte verschicken will, dann muss ich wissen, wie groß so ein pointer ist um ihn in eine Nachricht zu verpacken. In Java darf man das eigentlich nicht wissen können. Pointer übers Netzwerk zu verschicken ist natürlich nicht direkt sinnvoll, aber ich setze das ja wie bereits erwähnt auch lokal ein und da nutze ich das feature bereits.

Wenn ich demnächst mal wieder n paar Tage zuhause bin gibts glaub mal wieder n Screenshot und n update meines Designdokuments und einen kleinen Statusbericht. Ich glaub das 10.02 release verteil ich mal nicht, weil man einfach nix sieht als user, wäre die Mühe also nich wert.

[Chromanoid]

bin schon gespannt...

wenn es nur darum geht das ganze webfähig zu machen kannst du auch statt wie von zwergmulch vorgeschlagen gleich einfach dein komplettes Spiel in DLLs packen und diese dann von Java-Webstart/Applet aus starten. So aus der Hoffnung heraus, dass die Leute sich eher ein Java Applet/Java Webstart Programm runterladen als ein eigenständiges Plugin für den Browser. Letzteres ist ja auch nicht ganz trivial zu machen...
Die Leute, die "Making History II: The War of the World" entwickeln, haben das mit dem Java Webstart als Basis so für ihr "InBrowser-Game" gemacht:
http://www.gamasutra.com/view/feature/4 ... e_web_.php
Sie haben dafür zwar in dem gamasutra feature viel kritik geerntet, aber ich glaube sie fahren trotzdem ganz gut damit...

[Lord Delvin]

So hab endlich die Arbeit an den notwendigsten statischen Strukturen abgeschlossen. Damit ist für mich die Version 0.1 fertig und es geht über zur Version 0.2 in der ich beginnen werde dem ganzen Leben einzuhauchen. Ich denke, dass mir momentan auch langsam klar wird, wie ich die Kreaturen steuern will. Da ist mir bei der Implementierung aufgefallen, dass ich die ganze Zeit eigentlich garnicht wusste, was so ne Kreatur eigentlich machen soll.

An sich hab ich aber das Gefühl, dass das Konzept einer Gamelib aufgeht. Ich hab jetzt etwa 1400 Zeilen Code in libgw 100 Zeilen in libgw-interface und 400 Zeilen im sfmlclient. Wobei von den 400 Zeilen einiges mit Copy und Paste produziert wurde: der Rendercode für Gelände/Räume/Kreaturen ist fast gleich, ich fands aber irgendwie sinnvoll den zu trennen. Außerdem geht da noch einiges für Initialisierung drauf.

Und weils so schön ist noch ein Screenshot:

gw0.1.png

Sehr seltsam daran ist irgendwie, dass mir erst als ich das Bild gesehen hab feststellte, dass 12*16 Felder ganz schön weit rausgezoomt ist. Ich hab erst gedacht mein code ist verbuggt, weil ich den Arbeiter garnicht gesehen hab:-/

Falls btw. jemand denkt er kann besser malen als ich und sich berufen fühlt, darf er mir gerne schönere Tiles malen:D
Ich glaub aber dass die grafische Ausgabe meiner Clients immer eher symbolisch zu verstehen sein wird.

Wenn ich weiterhin etwa zwei Stunden am Tag dran arbeite, so wie ich das momentan plane, dann sollte das nächste release so in 3 Monaten fertig sein, vermutlich dauerts aber länger. Man vergisst irgendwie leicht wie viel Arbeit sowas dann doch ist.