Eine Ressourcenverwaltung

Länger habe ich jetzt schon nichts zum Spielfortschritt geschrieben. Es ist halt ein reines Hobbyprojekt, da kann immer alles Mögliche dazwischen kommen.
Nun aber gibt es einen entscheidenden Fortschritt, und zwar ist eine Ressourcenverwaltung implementiert. Konkret verdeutlichen lässt sich dies anhand eines Beispieles:
So steht in der Objektdefinitionsdatei:

 <objekt id="s">
    <name>Stadt</name>
  [...]
    <produktion>
      <ressource trigger="Rundenende" name="Nahrung">
        <menge>3</menge>
        <braucht>
          <feldtyp>b</feldtyp>
        </braucht>
      </ressource>
   [...]
      <figur trigger="Rundenbegin" typ="b">
        <braucht>
          <ressource name="Nahrung">
            <menge>6</menge>
            <verbraucht />
          </ressource>
        </braucht>
      </figur>
    </produktion>
  </objekt>

Hierdurch gibt es im Spiel ein Objekt mit dem Namen Stadt, welches am Ende der Runde des besitzenden Spielers drei Ressourcen mit dem wunderhübschen Namen "Nahrung" produziert. Sind davon sechs vorhanden werden diese in eine Spielfigur vom Typ 'b' umgewandelt. Die Definition dieser Figur steht an anderer Stelle.
Sechs scheint nicht viel, und für ein Spiel dieses Typus reichlich wenig. Jedoch befinde ich mich ja in früher Testphase, und da will ich möglichst wenig Wartezeit haben, bis ich sehe, ob das auch funktioniert. Eine Runde Wartezeit brauche ich jedoch, da natürlich auch getestet werden muss, ob der Zustand "kann nicht produzieren" richtig erkannt wird.

Beim Programmieren der Figurenerstellung kam mir das Qt Framework entgegen, mit seinem Signal Slot Mechanismus. So kann ich beliebige Objekte Figuren erstellen lassen, ohne diese Pointer auf Karte und Spieler mitschleppen lassen zu müssen.
Ein Schönheitsfehler ist noch, das Ressourcen auf einem Feld gesamt gezählt werden, nicht objektspezifisch. Was aber vorerst keine großartig schädlichen Auswirkungen haben sollte.

Bleibt noch, eine nette Figuren und Objektdefinition aufzubauen, dann kann schon fast gespielt werden.

QtCreator: Erster Eindruck

Eher zufällig bin ich darauf gestossen, dass heute Version 1.0 der Qt Entwicklungsumgebung Qtcreator herausgekommen ist. Ich habe es mir nicht nehmen lassen, diese gleich mal anzutesten. Erster Eindruck: Durchaus positiv.

QtCreator lässt zunächst mal vorhandene Dateien weitgehend in Ruhe, was ein Blick auf "svn diff" bestätigt. Die Oberfläche orientiert sich an anderen IDEs, ist also recht intuitiv, wenn man mit so etwas bereits gearbeitet hat.

Der QtCreator hat mein existierendes Projekt mit mehreren Unterprojekten anstandslos eingelesen, und alles richtig zugeordnet. Da gibt's nichts zu mäkeln. Bisher werden qmake Projekte eingelesen, weitere Projekttypen sind nach Angabe des Herstellers in Arbeit.

Ein deutliches Zuckerl für jemanden wie mich: Der Editor besitzt einen vi Modus. Dieser ist zwar vom vim weit entfernt, aber zumindest habe ich nicht mehr ständig i j k V :w und Ähnliches irgendwo im Programm stehen. :w ist allerdings der einzige Komandomodus Befehl, der zufriedenstellend funktioniert. Nun ja, man kann wohl nicht alles haben. Allerdings funktioniert im vi Modus auch die kontextabhängige Befehlsvervollständigung. Die einzige Funktion, die ich im vim vermisse. Wenn der vi Modus nun noch vollständig funktioniert, bin ich restlos begeistert.

Der Debugger ist aufgebaut, wie man ihn von anderen IDEs kennt. Eine Macke des Buildsystems hielt mich jedoch von einem umfangreichen Test ab: Es ist mir nicht gelungen, das Working Directory zu ändern. Da das Projekt in mehrere Teile aufgeteilt ist, ist hier das Sourceverzeichnis des Hauptprogrammes voreingestellt. Ich bräuchte allerdings das Wurzelverzeichnis des Gesamtprojektes. So werden natürlich keine Plugins und Datendateien gefunden.

Alles in allem sieht das Programm sehr annehmbar aus, ich werde dessen weitere Entwicklung aufmerksam verfolgen.