]]>
]]>
Der Statistikbildschirm ist fertig!
Hier sieht man einige der neuen Stadtgrafiken, die ich gemacht habe:
Das ganze Team, ein Glück hat die Kamera einen Selbstauslöser, sonst hätte man mich nicht sehen können.
Matthias ist schon ein Phänomen - während wir alle über wachsende Geheimratsecken klagen, scheint seine Haarpracht mit zunehmendem Alter immer praller zu werden!
Grüße auch vom ganzen Team,
Raphael
Wir gratulieren Jana zu ihrer gelungenen Diplomarbeit und bedanken uns herzlich für die Erwähnung! ]]>Das bekannteste Hobbyspieleentwicklerprojekt ist jedoch Die Verbotene Welt von Sechsta Sinn. Das Team aus 15 Mitgliedern arbeitet seit neun Jahren, sofern es die freie Zeit neben dem Job zulässt, immer mal wieder an dem futuristischen RTS-Spiel. Was dabei entsteht, kann sich sehen lassen und weckte ebenfalls Interesse für eine kommerzielle Veröffentlichung. Leider ist nicht ganz klar, ob und wann das Spiel fertig werden wird. Dafür haben Sechsta Sinn schon zweimal auf der Dusmania – dem wichtigsten Hobbyentwicklertreffen Deutschlands - den Preis für das beste dort vorgestellte Projekt gewonnen. Außerdem sind sie mit ihrem Spiel über die Grenzen Deutschlands hinaus bekannt.
Besonders wichtig ist dem Team, den Kontakt nicht nur online über einen eigenen Chatchannel aufrecht zu halten und so gibt es trotz der langen Entwicklungszeit und der Größe des Teams regelmäßige Treffen. Eine genaue Projektplanung existiert aber nicht:
„Die Erfahrung hat gezeigt dass z.B. Termine für ein Hobbyteam einfach nicht funktionieren.“, so Matthias Gall, leitender Programmierer von 6S.Zwar hat das Team die nötige Professionalität, Ideen für Missionen, eine ausgebaute Hintergrundgeschichte und die eigene Engine mit Missionseditor, allerdings fehlt die Zeit, das Projekt fertig zu stellen. Schließlich arbeiten alle Teammitglieder lediglich in ihrer Freizeit daran, was voraussetzt, dass Die verbotene Welt noch Spaß macht und das ist unter Zeitdruck selten der Fall.
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!
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. ]]>
Bald dann mehr in Form eines neuen YouTube-Videos. Gute Nacht und spaetestens bis zum naechsten Treffen! ]]>
]]>
 |  |
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. ;-)
]]>
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. ]]>
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. ]]>