Ich wuenschte, ich haette hier was richtig spannendes zu erzaehlen und koennte so tolle Bildchen zeigen, wie sie Gregor und Raphael gerade vor mir und neben mir produzieren. Ich hab aber nur ein haessliches Pathfollowing-Testbed das ich in aehnlicher Form schon seit dem letzten Treffen nutze. Dementsprechend versuche ich immer noch dafuer zu sorgen dass Einheiten ohne zu murren rueckwaerts aus einem Nadeloehr herausfahren und erst dann einschlagen, um geradeaus weiterzufahren, usw. usf.; Bild siehe unten.

Gereon horcht inzwischen an der Matratze, hat aber heute z.B. daran gearbeitet, dass die Einheiten sich ordentlich an einer Frontlinie verteilen, ist dabei aber an Lua verzweifelt und wuenscht sich nichts sehnlicher als echte Pointer.

Meine lieben Kollegen aus der Programmierer-Fraktion, Christopher und Julius, vermissen wir schmerzlich. Chris hat diesmal leider keine Zeit und Julius ist krank ausgefallen - wir hoffen, ihn morgen noch hier zu sehen und wuenschen von hier aus gute Besserung!

Wieder einmal neigt sich ein sechsta sinn Treffen dem Ende zu. Obwohl wir wieder einmal in relativ kleiner Besetzung beieinander saßen (keine Grafiker z.B.), haben wir einiges geschafft.



Matthias hat wieder einmal grosse Fortschritte beim Pathfinding gemacht, unser Jeep parkt jetzt z.B. sinnvoll rueckwaerts aus. Ich selber habe mich weiter um das Laden/Speichern gekuemmert, wobei ich insbesondere ein paar fiese Bugs im Zusammenhang mit unseren LUA 4 KI Skripten in Zusammenarbeit mit Gereon behoben habe. Somit steht endgueltig das Grundgeruest fuer dieses wichtige Feature und es fehlen nur noch Detailkorrekturen (spezielle Statusvariablen von einzelnen Einheiten) damit auch alle Animationen beispielsweise nach dem Laden ohne Probleme weiter abgespielt werden.



Als kleine Entschaedigung an alle treuen Leser, dass hier in letzter Zeit so wenig los ist, haben wir mal einen groesseren Screenshot zusammengebastelt. Er zeigt einen ueberlegenen KPB Spieler und einen Bunkermenschen Gegner in den letzten Zuegen (Klick fuer volle Groesse):

Fuer unsere treuen Besucher gibt's hier einen ersten kurzen Statusbericht von der Front. Wie immer, seitdem wir alle ueber das Vordiplom hinausgekommen sind, treten wir nur mit halber Mannschaft an. Leider hat es kein einziger Grafiker zum Treffen geschafft - wir vermissen Raphael, Sebastian, Martin und Gregor schmerzlich - und auch Julius ist leider nur halb anwesend, da er sich die uebrige Zeit mit einem Pflichtenheft herumschlagen muss. Die uebrigen Anwesenden, Jochen, Gereon, Christopher und meine Wenigkeit, arbeiten fleissig an DVW.

Wie ihr bereits per Twitter gelesen habt haben wir uns zu einem Grossteil den aktuellen Bugs und Problemchen gewidmet. Jochen und Gereon arbeiten an Karten und KI und melden dabei allerlei Wuensche und Fehler an, mit denen wir uns beschaeftigen. Immerhin sind wir auch bei zwei groesseren Themen, naemlich Laden/Speichern und dem Pathfollowing, ein gutes Stueck weitergekommen. Einheiten fahren z.B. nun rueckwaerts aus einem Nadeloehr und auch komplexere Zustaende in der Lua VM lassen sich (de)serialisieren.

Das ist gerade bei Gereon's "ntroKI" wichtig, die ihre Aufgaben in verschiedenen States ueber Frames verteilt, um im verfuegbaren Rahmen von wenigen Millisekunden zu bleiben. Da sich DVW Renderlogik und KI einen Thread teilen koennen wir hier nirgends ueber die Straenge schlagen und muessen gerade komplexere Graphenalgorithmen, wie Gereon sie in Lua implementiert hat, kurz und performant halten.

Natuerlich planen wir auch ohne Grafiker, noch ein paar Kleinigkeiten als Bilder zu veroeffentlichen, also bleibt dran.

Es gibt noch einen Screenshot von der KI, den ich euch nicht vorenthalten will. Die KI ist nun in der Lage die vorhandenen Einheiten zu einer Verteidigungsfront zu organisieren. Dabei wird das Gelände berücksichtigt. Wie ich früher schon ausführlicher erklärt habe werden Engpässe gesucht und dort die Einheiten platziert.

Wow, schon wieder so viel Zeit vergangen seit dem letzten Posting. Neues gibt es seither leider nicht zu berichten, aber dennoch will ich hier mal ein Lebenszeichen hinterlassen. Wieder einmal befinden sich einige von uns in spannenden Lebenssituationen (Christopher schreibt seine Bachelorarbeit, Gereon und Jochen sind seit einiger Zeit im ersten Job,...) so dass für sechsta sinn aktuell wenig Zeit bleibt. Ich selbst habe keine andere Entschuldigung als die, dass die Arbeit derzeit sehr schlaucht... Aber wir planen das nächste Treffen und werden wenigstens hier wieder Fortschritte erziehlen. Mal sehen, ob 2012 realistisch bleibt... ;-)

Ich hatte ja versprochen, ein YouTube-Video nachzureichen. Here we go. Wenig spektakulär und keine atemberaubende Qualität inklusive Rucklern, aber man sieht, wo die Reise hingeht.

So, das Treffen ist schon wieder vorbei und ich habe wenig von mir hoeren lassen - das liegt hauptsaechlich darin begruendet, dass ich keine ordentliche Screengrabbing-Software fuer OSX gefunden habe, denn ich haette gerne etwas bewegtes gezeigt. Das wird ASAP unter Windows nachgeholt.

Soviel sei bereits jetzt schon gesagt: ein Meilenstein ist erledigt. Ich habe ja einige Pathfinding- bzw. besser Pathfollowing-Themen lange vor mir her geschoben. Heute habe ich endlich dafuer gesorgt, dass Radfahrzeuge realistische Kurven fahren, bei Bedarf zuruecksetzen und den Kurs korrigieren. Fuer einzelne Fahrzeuge klappt das bereits ganz gut und ich moechte euch das gerne in einem kleinen Video zeigen. Beschleunigung ist noch nicht integriert, aber es sieht auch jetzt schon ganz ansehnlich aus. Im uebernaechsten Schritt kommt dann wieder das Gruppenverhalten an die Reihe - hier ist es wichtig, dass sich mehrere Einheiten nicht in die Quere kommen. Der aktuelle Plan ist, dass sich hier Einheiten einfach lokal (d.h. direkte Nachbarn) abstossen und so den Bewegungsvektor korrigieren. Ausserdem moechte ich so Formationen realisieren: Einheiten bemuehen sich einfach, die Abstaende zu ihren Gruppennachbarn aufrecht zu erhalten, sofern moeglich. Nur wenn es z.B. durch ein Nadeloehr geht muessen alle Einheiten naeher zusammenruecken. Das Verfahren habe ich bereits in einem Prototyp implementiert und gute Erfahrungen damit gemacht - der schwierigere Part ist leider ohnehin meist die Integration in DVW, denn der "historisch gewachsene" Code ist nicht immer fuer solche Erweiterungen geeignet.

Bald dann mehr in Form eines neuen YouTube-Videos. Gute Nacht und spaetestens bis zum naechsten Treffen!

Ohne gro(esszett) Gelaber hier die neuen Grafiken die ich in den letzten Tagen fuers Spiel gemacht hab:

So ich bin auch mal wieder auf einem Treffen, während ich so einige Bugs beim Leveldesignen bemerke Frage ich mich insgeheim ob ich mich über Bugs eigentlich Freuen, oder unter ihnen Leiden sollte. Das ist eine tiefgreifende Philosophische Frage - in der tat. Die Schwächen des Programms hindern mich auf der einen Seite zwar an der Arbeit, auf der anderen Seite macht es tierisch Spaß die Programmierer des Teams mit ihren Fehlern aufzuziehen :D

Ah da fällt mir auf das ich in der Zeit wo ich diesen vollkommen Sinn- und Gehaltlosen Tagebucheintrag schreibe auch eine neue Grafik hätte gemacht haben können - oh zu viel Konjunktiv meint ihr nicht?

Auf jeden Fall ist es schön mal wieder auf einem Treffen zu sein. Ich habe beschlossen neben neuen Grafiken auch endlich mal vollwertige Skirmish Karten zu machen, damit aus diesem Projekt vielleicht auch irgendwann tatsächlich mal ein Spiel wird ;)
Bleibt dabei, es lohnt sich! (und ich verspreche es wird mindestens ein neues Bild nach dem Treffen zu sehen geben)

Um spezielle Punkte auf der Karte zu markieren, die für den Spieler von Interesse sind, haben wir zwei Möglichkeiten: einen pulsierenden Kreis auf der Minimap und seit neustem auch endlich eine animierte Markierung auf der Karte, die Raphael angefertigt hat. Unterstützt wird das durch Nachrichten, die am Bildschirmrand erscheinen, und die intern eine optionale Kartenposition hinterlegt haben, so dass man schnell auf Tastendruck (standardmäßig Space) zur Ereignisposition springen kann.

Ich habe Raphaels Kartenmarkierungen eingebaut, unten seht ihr die mittlere und große Version:

Eigentlich wollte ich die Bilder hier jetzt noch schön per Lightbox oder Lytebox darstellen, aber natürlich klappt das dank Frames nicht... ich hab dann also im Endeffekt die Standard-Popups genommen. Ach, egal, die Seite muss eh mal neu gemacht werden. ;-)

Erstmal ein Frohes Neues Jahr zusammen! Das Treffen ist zwar jetzt schon ein paar Tage her, ich wollte euch aber auch noch kurz mitteilen, was ich denn so getrieben habe. Wie schon auf den vergangenen Treffen habe ich mich mit dem Laden und Speichern von Spielen in DVW beschaeftigt, einem der letzten grossen Bloecke die noch komplett fehl(t)en.

Im Grunde war ein Grossteil der Funktionialitaet bereits vorhanden, da unser Missionseditor MissEd natuerlich auch Karten und platzierte Einheiten speichern kann. Da in unserem Editor aber kein vollstaendiges Spiel laeuft (da es einfach nicht gebraucht wird) war es aber noch nicht moeglich z.B. den Status der lua-VMs zu speichern, die wir fuer KI- und Missionsskripte brauchen.

Damit bin ich dann auf dem letzten Treffen endlich fertig geworden und konnte Sonntag morgen somit zum ersten Mal einen Spielstand speichern und danach auch erfolgreich laden, inklusive des KI-Standes, der Missionsziele und irgendwelcher Kartenveraenderungen (Krater verursacht durch Einschussloecher o.ae.).

Ein paar Fehler gibt es zwar noch, aber das sind meistens nur Animationsfehler der Einheiten nach dem Laden, da manchmal nicht alle verwendeten Statusvariablen serialisiert wurden.

Was jetzt noch fehlt ist ein bisschen Code "drumherum", so soll z.B. in Zukunft noch ein Screenshot des aktuellen Spielstandes mit in ein Savegame geschrieben werden.

Sobald dann auch noch Integration ins Hauptmenue abgeschlossen ist, sind wir der Fertigstellung wieder mal ein (kleines) Stueck naeher gekommen.

Nachdem ich auf dem letzten Treffen ja damit fertig geworden bin die Engpässe zu berechnen sollte man meinen, dass nach diesem Treffen die KI ihre Einheiten an die entsprechenden Stellen platzieren kann. Ganz so leicht ist das allerdings nicht, hier zu den Gründen und was ich "stattdessen" geschafft habe ;-)

Erstes Problem ist, dass bisher nur die engste Möglichkeit berechnet wurde Freund und Feind zu trennen. Diese Grenze ist natürlich aus beiden Perspektiven genau die gleiche. Wenn jetzt beide Gegner ihre Einheiten dort postieren werden diese aufeinandertreffen und sich sofort bekämpfen. Das hat also nicht viel mit Verteidigung zu tun, sondern eher mit der Verabredung eines Schlachtfeldes.
Es ist also nötig eine Stelle zu finden die zwar ein Engpass ist, aber gleichzeitig möglichst nahe an der eigenen Basis. Diese Änderung habe ich auf dem Treffen implementiert.

Ein weiteres und viel gravierenderes Problem ist jedoch die Laufzeit. Die Berechnung der Engpässe dauerte vor dem Treffen etwa 5 Sekunden (ohne die einmaligen Initialisierungen die nur zu Missionsanfang durchgeführt werden auf einem 2 GHz Rechner). Wenn ich diese also mitten im Spiel aufrufen würde um nach den aktuellen Gegebenheiten die Verteidigung zu platzieren würde das Spiel für 5 Sekunden stillstehen, bis die Berechnung fertig ist. Das ist natürlich für den Spieler inakzeptabel.

Um dieses Problem zu lösen habe ich einerseits versucht an den besonders teuren Stellen den Algorithmus zu optimieren. Das reicht natürlich bei weitem nicht, denn um eine Framerate von 30 Frames pro Sekunde zu ermöglichen darf die Berechnung maximal 30 Millisekunden dauern... und da ist noch nicht beachtet, dass der Rest des Spiels ja auch Rechenzeit benötigt... also 15 Millisekunden statt 5 Sekunden ca. 300 mal so schnell wie bisher.

Der große Trick um das hinzukriegen ist, dass die Engpässe ja nicht innerhalb eines einzigen Frames berechnet werden müssen. Der Algorithmus muss also so fein wie möglich in Einzelschritte aufgeteilt werden, so dass diese Frame für Frame ausgeführt werden können. Sowas ist in der KI auch bereits vorgesehen und wird für andere Teile der KI auch schon genutzt.
Den größten Teil des Treffens habe ich also damit zugebracht einen bereits funktionierenden Algorithmus in möglichst handliche Stücke einzuteilen.

Am Ende des Treffens kann ich sagen, dass ich viel geschafft habe. Der größte übrige Einzelschritt braucht auf meinem Testsystem "nur" noch 15 bis 16 Millisekunden. Das ist knapp an der Grenze und ich werde sicher irgendwann noch nachbessern müssen um auch auf langsameren Rechnern im Rahmen zu bleiben. Aber so läuft das ganze erstmal flüssig ... und die KI platziert ihre Einheiten immer noch nicht auf der ausgerechneten Front.

Also, wer's noch nicht bemerkt hat: aktuell ist wieder ein sechsta sinn Treffen. Ich bin diesmal wieder mit von der Partie, nachdem wir ELFrun erfolgreich abgeschlossen haben, und bemuehe mich diesmal zunaechst um den MissEd Port fuer OSX - denn: ich habe der Einfachheit wegen nur das MacBook Pro mit. Ich war noch nie bei einem Treffen so schnell startklar :-)

Aktuell versuche ich, die wxWidgets Bibliotheken zu bauen und ins Projekt zu integrieren. Ich generiere dazu kein Framework, sondern erstelle Bibliotheken, die ich statisch linke, wie das hier beschrieben ist. Ausserdem benoetigen wir weitere Extensions, z.B. das wxPropertyGrid und STC. Ich baue gerade zum fuenfundzwanzigsten Mal... Falls jemand mehr Erfahrung mit sowas hat, freue ich mich ueber E-Mail! Zumindest die Intel-Version laeuft, am Universal Binary hapert's noch: hier gibt's Unresolved Externals fuer wxGLCanvas, STC und wxPropertyGrid - wxWidgets an sich scheint also erfolgreich zu linken, waehrend ich fuer die uebrigen Libs irgendwas uebersehen haben muss. Hier ist ein Shot, wie's aktuell aussieht.

Wie man sieht, gibt's hier noch einiges zu tun: Umlaute funktionieren nicht ordentlich, die Button- und Fenstergroessen sind anders als unter Windows bzw. GTK,...

Ausserdem mussten wir hier heute wieder einmal schmerzhaft feststellen, wie wir dafuer bestraft werden, dass wir kein Design Document gepflegt haben. Von Anfang an waren zwei Dinge vorgesehen: 1. Der Spieler wird mit einer Grundmenge an Ressourcen ausgestattet, die zum Levelstart zur Verfuegung stehen. 2. Schrott kann nur in begrenzter Menge z.B. in der Schmelze gelagert werden, man benoetigt Lager um mehr Kapazitaet zu gewinnen; der Sammler transportiert eine begrenzte Menge Material und muss sich Nachschub an Schmelze oder Lager abholen. Julius implementiert diese Logik und ist dabei auf interessante Fragestellungen gestossen, die wir nicht von Anfang an bedacht hatten: wohin gelangt das Startmaterial, wenn noch gar nichts existiert, was dieses Material beinhalten koennte? Woher erhaelt ein gebauter Sammler oder eine Schmelze dieses Material? Wird es "magisch" beim Bau zugewiesen? Was ist, wenn es in einer Karte schon von Beginn an mehrere Sammler/Schmelzen/Lager gibt? Wird das "Startkapital" dort gleichmaeszig verteilt? Und, wenn Schrott also in Lagern liegt, dieser aber nur zum Gebaeudebau explizit abgeholt werden muss, woher nimmt eigentlich dann eine Einheitenfabrik ihren Schrott? Und, und, und...

Die Konsequenz ist: Schrott existiert nur "global" und wird auf alle Lager gleich verteilt. Benoetigt ein Sammler mehr Schrott, als in einem Lager verfuegbar ist, wird er "gebeamt", d.h. er kann an einem Lager bzw. an einer Schmelze das komplette, theoretisch verfuegbare Material abholen. Wird ein Lager zerstoert, reduziert sich der Gesamtbetrag um den Anteil eines Lagers. Schrott fuer Einheiten wird ebenfalls "gebeamt" und direkt vom Gesamtbetrag abgezogen. Damit bleibt die strategische Bedeutung der Lager erhalten, aber wir haben intern nicht so eine wilde Rumrechnerei. Insbesondere wird der Spieler damit nicht genoetigt, Schrott zwischen Lagern manuell zu verteilen. Urspruenglich war uebrigens sogar geplant, dass der Schrott in der Schmelze zu Halbzeugen verarbeitet wird und diese dann in die Lager gebracht werden... den Schritt haben wir uebersprungen, um den Bauprozess nicht voellig zu verkomplizieren.

Das war's fuer mich an diesem Abend. Morgen mehr.

Inzwischen sind einige Wochen ins Land gegangen, ein Treffen ist ohne mich vorbeigezogen und ich habe nicht ein bisschen an DVW getan. Wer hier eifrig mitliest und auch unsere "privaten" Blogs kennt, weiß längst warum, und für alle anderen erlaube ich mir, das sechsta sinn Tagebuch für Eigenwerbung zu missbrauchen: mattin und ich haben uns zusammengetan und an einem iPhone/iPod-Spiel gearbeitet. Schaut doch mal auf elfrun.net vorbei!

Nachdem ELFrun aber nun veröffentlicht ist, werde ich mich wieder DVW widmen. Auf dem Plan stehen u.a. immer noch das Pathfinding, der MissEd OSX Port und eine storylastige Missionskarte.

Vorsicht bei LIDL-Energy Drinks:

[20:29] * matt|6S|mbp kippt sich gerade einen billig-energy-drink vom lidl nach dem anderen rein... mal sehen was passiert ;-)


[20:32] * matt|6S|mbp has quit (Ping timeout)


[20:33] * matt|6S|busy has quit (Ping timeout)

Sven Gramatke, einer der Macher hinter Sorades, hat in seinem Blog einen netten Kommentar zu DVW abgegeben:

Ich denke, wenn DVW erst einmal fertig ist und es wirklich als reine Freeware erscheint, wovon alle außenstehenden ausgehen, dann wird es die perfekte Freeware sein. Ganz eigenes Konzept, eigene Engine, erstklassige Grafik. Ich gehe sogar so weit zu sagen, dass wenn das Gameplay nur halb so gut ist wie die Grafik auf den Screenshots, DVW ein Monument in der Freewareszene darstellen wird. Innerhalb der Szene wird es vielleicht sogar zu einer neuen Zeitrechnung kommen und nachfolgende ambitionierte Freeware Spieleentwickler werden sich daran messen müssen.