Relaunch…

Ihr hab sicherlich gemerkt, dass mein letzter Blogpost nun schon einige Zeit her ist…. nun: ich habe mich entschieden das D&D game erstmal auf Eis zu legen. Zwar habe ich noch viel an dem Projekt programmiert und könnte hier auch wieder einiges berichten – doch habe ich gemerkt, dass ich nun doch eher kleinere Games programmieren will. Zur zeit experimentiere ich ein bischen mit der freien Prototype- 2D- Engine „LÖVE“ rum… dazu darf ich euch auch den gemeinsamen Blog von einem Freund und mir empfehlen: <a href=“www.masterlinux.de“>2DStudents</a>

Das nächste XNA Projekt wird ein 2D- shooter für die Xbox360 werden, das ich zusammen mit zwei Freunden für die Uni nächstes Semester programmieren werde. Sobald es in dieser Richtung weitere Entwicklungen gibt, werde ich auch diesen Blog wieder mit allerhand netter und nützlicher Facts über die Spieleprogrammierung füttern. Außerdem wird der Blog wohl ab dem nächsten Post auch international lesbar sein – sprich Englisch werden^^. Mal sehen, wie mir Google translate die bestehenden Posts übersetzt

Bis dahin: schaut mal bei <a href=“www.masterlinux.de“>2DStudents</a> vorbei!

-Dominik

die Felder werden gefüllt…

meine Lösung mit zwei Felder- Arrays hat wunderbar geklappt! Jetzt skaliert endlich alles wie es soll. Ich werde demnächst nochmal ein Video zum aktuellen look&Feel posten. Der Nachteil an zwei Arrays ist jedoch, dass ich in der Speilschleife jetzt nicht mehr nur ein Array sondern eben zwei durchgehen muss. Das drückt natürlich die Performance – ist aber für ein grafisch so anspruchsloses nicht schlimm und ich nehme es gerne in Kauf.

Nun muss ich mir jedoch überlegen wie es weiter gehen könnte… irgendwie müssen die Felder ja noch gefüllt werden -zu Testzwecken erstmal mit einem kleinen Monster – das Sprite dafür werde ich mir irgendwo in den Weiten des Netzes besorgen
Da ich ja jetzt zwei Arrays habe, müsste ich jetzt eigentlich zwei Versionen von dem Monster- Sprite haben – ein größeres und ein kleineres für jedes Array eins. Das wäre natürlich super- Umständlich. Daher entscheide ich mich dafür, dass jedes Feld- objekt nochmal auf ein „Feld-Inhalt“-Objekt verweist und sich ein kleines Feld und das dazugehörige große Feld ein FeldInhalt- Objekt teilen.

Demnächst gibts da mal ein screenshot zu

eine Schicht kommt selten allein….

wie befürchtet hat mein „rein Grafischer“ Ansatz nicht so funktioniert wie er sollte… letztendlich bestanden die gleichen Probleme wie vorher: die Felder zoomen nicht wie sie sollen… wenn man Felder im hineingezoomten Modus bewegt, entstehen komische Bugs beim Herauszoomen – so verschieben sich etwa alle Felder in eine Bestimmte Richtung, sodass nur noch ein Teil der Dungeon- Karte abgedeckt ist.

Also was macht der angehende Informatiker, wenn er ein bestimmtes Problem nicht lösen kann?….
Richtig! Er fügt eine weitere Schicht ein!

In meinem Fall habe ich mir überlegt, dass, wenn es so probleme beim Zoomen gibt, ich die Felder einfach GAR NICHT zoome….. nein! Natürlich wird es die Zoomfunktion weiterhin geben -  allerdings werde ich keine Felder mehr verändern. Vielmehr wird es nach meiner bisherigen Überlegung zwei verschiedene Felder geben – ein kleines für den Übersichtsmodus und ein großes für den herangezoomten Modus. Insgesamt also zwei verschiedene Felder- Arrays, die aber über die gleichen Koordinaten identifiziert werden können. Bei der Benutzung der Felder später wird es wahrscheinlich ein zusätzliches Objekt „FeldInhalt“ geben, das ich dann einfach an den „feld-Partner“ übergeben kann, wenn die Ansicht geändert wird.

Also….zur Realisierung werde ich wohl erst einmal sowohl die Dungeon- Klasse, also auch die Field klasse komplett neu Schreiben. Die Dungeon-Klasse bekommt dann zwei verschiedene Felder-Arrays – eins für große und eins für kleine felder.

….und weiter gehts!

und weiter gehts!

Soo….nachdem nun sämtliche Prüfungen geschrieben sind, kann ich mich nun endlich mal wieder dem XNA-D&D-Game widmen….. gedacht-getan: Rechner angemacht- C# gestartet…..und schon der erste herbe Rückschlag: ich hatte vor einigen Wochen meinen PC neu aufgesetzt… dummerweise habe ich eine ältere Version meines Quelltextes gesichert….somit muss(te) ich wieder einiges neu machen…. und Probleme wie das korrekte Skalieren der Felder, bei denen ich froh war sie nicht mehr als Problem zu haben….

Jedoch kamen durch die zwangs- Widerholung auch einige Fehler zum Vorschein. So hatte ich beispielsweise nicht bedacht, dass, wenn man auf der karte heranzoomt, die Felder ja immer ab der oberen rechten ecke gezeichnet werden. DH man zoomt zwar an die richtige stelle der Karte, jedoch nicht an die richtige Stelle der Felder.

Als Lösung zu diesem Problem hatte ich mir überlegt, einfach im „Übersichtsmodus“ die Felder in die entgegengesetzte Richtung zu verschieben. Jedoch erscheint mir das auch etwas buggy zu sein…weshalb ich nun eine andere Herangehensweise ausprobieren möchte.
Meine bisherige Idee bestand darauf, um den ZOOM- effekt zu suggerieren, einfach alle elemente des Bildschrims entsprechend zu vergrößern- d.h. die Felder in ihrer Länge/Breite und ihrer Position entsprechend zu verändern.
Nun will ich jedoch ausprobieren, ob es nicht einfacher ist, den gesamten ZOOM effekt auf das grafische zu beschränken.

die Draw-Methode des SpriteBatch bietet in einer Überladung einen Parameter für die Skalierung an.

public void Draw (
         Texture2D texture,
         Vector2 position,
         Nullable<Rectangle> sourceRectangle,
         Color color,
         float rotation,
         Vector2 origin,
         Vector2 scale,
         SpriteEffects effects,
         float layerDepth
)

Es geht um die beiden Vectoren origin und scale. Hierbei gibt Origin den Punkt innerhalb des Sprites an, von dem ausgehend das Sprite skaliert werden soll. (der „Pivot-Point“ für 3D- Grafiker ). der Scale-Vector enthält die Faktoren um den das Sprite Skaliert werden soll.

Der Nachteil an dieser Herangehensweise ist jedoch, dass hierbei weder die Feld- Attribute Länge/Breite, noch die Position der Felder verändert wird….ich befürchte also, dass das immernoch nicht des Rätsels Lösung sein wird, aber vielleicht hilft mir das dann schonmal ein bischen weitet…. „Vom Hirn in die Tastatur“ ist ja bekanntlich das beste Software- Entwicklungsmodell…

Zwangspause….

leider wurde ich von meinen Pflichten in der UNI eingeholt und muss mich erstmal um die Abgabe meines Flash-projekts kümmern. Wenn ich wieder mehr Zeit habe, werde ich natürlich in „alter Frische“ die arbeit am D&D Projekt wieder aufnehmen.
Was ich bis dahin noch loswerden möchte: Ich habe mich entschlossen, den Java- Editor zu einem kompletten Level- Editor zu erweitern. Man wird also nicht nur die betretbaren Areale markieren können, sondern auch Gegner setzen und deren Charakterwerte eintragen können. Wer die komplexen Regeln von D&D kennt, weiß, dass gerade das leichter gesagt als getan ist….
Auch können Felder mit Fallen, Schätzen oder Triggern für bestimmte Ereignisse (z.b. ein Teil der Höhle stürtzt ein und versperrt den Ausgang etc.)…aber das alles ist wie gesagt leider erstmal wieder Zukunftsmusik, da ja dieser blöde Flash- Film nach Fertigstellung ruft….

Java und die Layout-Manager…

nach all dem Kompfort in XNA hatte ich bereits vergessen, welche Probleme die GUI- Entwicklung in Java so mit sich bringt. Nach dem aneigenen eines Beispielcodes oder gründlicher Durchforstung der (extrem guten) Java- API ist es nicht sonderlich schwierig, sein eigenes Java- Fenster auf den Bildschirm zu zaubern. Jedoch vergeht die anfängliche Euphorie schnell wieder, wenn man auf die wohl dämlichste Erfindung in der Geschichte des Codens stößt: den Layout- Managern.
Diese sind eigentlich dafür gedacht, die Komponenten in einem Fenster automatisch in Größe und Position anzupassen und im Fenster anzuordnen. Und das dynamisch. So sind Layout-Manager unabdingbar, wenn die eigene Applikation eine variable Fenstergröße hat. EIn Layout-Manager kümmert sich hierbei um die konstant gleiche relative Anordnung und Skalierung der Komponenten (z.b. Buttons, Textfelder etc..) bei sich verändernder Fenstergröße.
Die Layout-Manager gibt es in den unterschiedlichsten Geschmacksrichtungen – je nachdem, auf welche weise die Komponenten im Fenster angeordnet werden sollen.
Leider ist die Dokumentation über die verschiedenen LayoutManager nur bedingt vorhanden – in der sonst so perfekten Java- API findet man lediglich beschreibenden Text und ein Tutorial (zeitaufwendig). Mal ehrlich – ein paar Skizzen, auf welche weise welcher LayoutManager die komponenten anordnet wäre nun wirklich nicht zuviel verlangt. So ist der name „GridLayout“ realtiv selbstbeschreibend, aber schon „FlowLayout“, „GridBagLayout“, oder „SpringLayout“ scheinen von der Superklasse „Bahnhof“ zu stammen

Jedenfalls produzieren diese Layout-Manager teils sehr merkwürdige und nicht nachzuvollziehende Resultate. Ich habe während der Entwicklung meines Java-Tools ein 2D- Array an JButtons errichtet und diese auch entsprechend ihrer Koordinaten positioniert (die meisten LayoutManager respektieren die „prefferedSize“ und „preferredLocation“ einer komponente und Skalieren und positionieren diese so, wie sie es „wünschen“). Jedoch wundere ich mich, wie ein solches Resulatat für den „letzten“ Button im Array entstehen kann:

Überall hat der standartmäßig eingestellte LayoutManager „FlowLayout“ die Größe und Position der Buttons berücksichtigt, außer beim letzten Button….WARUM??
Diese Frage hat mich nur so lange beschäftigt, bis ich eine Lösung gesucht habe, ganz ohne LayoutManager auszukommen. Das ist nur möglich, wenn man im Container (in dem Fall das fenster) setLayout(null); aufruft. Das das so einfach geht, ist leider auch wieder nur ganz versteckt in der API (wieder in einem Tutorial) zu finden…
Dennoch ergaben sich damit noch mehr Probleme….denn ohne LayoutManager wurde plötzlich das Dungeon-Hintergrundbild nicht mehr gezeichnet. Erst eine komplette Neustrukturierung des Codes (statt die eigene Klasse von JFrame direkt abzuleiten, habe ich die Klasse von JPanel abgeleitet und im Konstruktor ein JFrame aufgerufen und dem JPanel hinzugefügt – ein JPanel ist ein Container für Objekte)
hat dieses Problem behoben (Jedoch habe ich mich in dem Zusammenhang gefragt, warum die Methode zum repainten aller Objekte bei JPanel „paintComponent“ und beim JFrame „paintComponents“ (also im plural) heißt….naja…)
Dennoch brachte die neue Struktur leider das obige Problem mit dem fehlenden Button (dieser war übrigens nicht weg, sondern wurde nur gaaaanz groß skaliert und im Hintergrund aller Buttons angezeigt) zurück. Trial and Error hat mir dann eröffnet, dass mein Fehler darin lag, dass ich die Buttons dem JFrame direkt und nicht zuerst dem übergeordneten Container JPanel hinzugefügt hatte. Jetzt läuft die UI wunderbar. Dennoch zeigt mir der ganze HickHack mit den LayoutManagern und der nur schwer nachvollziehbaren Struktur von Containern, Components und LayoutManagern, dass Java in sachen UI bei all den coolen Features und Vorteilen, die die Sprache gegenüber anderen haben mag, wo doch noch offensichtliche Verbesserungen nötig sind.
Nichtsdestotrotz bin ich nun mit der UI fast fertig und will euch das vorab-Ergebnis natürlich nicht vorentalten. Die Dungeon-Map ist natürlich nur dummy und passt deshalb nicht recht unter die von mir erstellten Felder-Buttons.

ein Java-Tool erleichtert die Arbeit

den heutigen Tag habe ich damit zugebracht, eine Field- Klasse zu erstellen, die dann ein Kästchen auf der Dungeon-Karte (siehe Video von gestern) repräsentiert. Leider musste ich die Dungeon-karte vorzeitig aufgeben, da die kästchen, wenn man sie zum Bildrand fortsetzen würde, leider nicht Stoß-an-Stoß mit dem Bildrand abschließen würden, was aber nötig ist, da die Fields in meinem 2D-Array in der oberen Ecke des Bildes anfangen und das Ganze Bild bis zur unteren rechten Ecke abdecken. Also muss das ganze Bild in einer art Gitter strukturiert sein – und genau ein solches „dummy“ Bild habe ich mir in Photoshop gebastelt und nutze es als test- Hintergrund.
Nachdem die Felder erstellt waren, habe ich zum Test alle mit einem kleinen Sprite versehen, das den Rand eines Feldes markiert. Leider hat sich dann herausgestellt, dass die Felder (trotz dynamischer Berechnung abhänig von der Mapgröße) nicht überall auf die Gitterlinien meines dummy-Bildes passten. Nach ein paar Stunden rumprobiererei habe ich dann endlich die Werte für Abstände, Positionen und Größen der Felder gefunden, dass alles gepasst hat.
Ein weiteres Problem hat meine zoom- Funktion, die ja schon implementiert war, dargestellt. Denn ich muss ja die Felder dann beim zoom hochskalieren und nachher wieder runterskalieren. Außerdem müssen die Felder sich beim scrollen auch mitbewegen. Das Problem war allerdings, dass sich die Felder im „übersichtsmodus“ nicht mitbewegen sollten, sondern nur im hereingezoomten zustand. Also habe ich mich kurzerhand für zwei verschiedene Arrays an Feldern entschieden. Ein Array beherbergt die „kleinen“ Felder in der Übersichts-Ansicht, ein anderes Array managed die „größeren“ Felder in ihrem hochskalierten Zustand. Über den Datenaustausch (denn jetzt habe ich ja zwei verschiedene Feld- objekte) mache ich mir keine Sorgen, denn beide Elemente haben die gleiche Anzahl an indexen. Das Feld [4,3] ist also auch das große feld an der stelle [4,3].

Den nächsten Problempunkt stellt jetzt leider die Zuweisung der Felder dar. Momentan habe ich genau 625 Fields in einem Dungeon. Im reinen Programmcode gibt es keine Möglichkeit, ein Feld, das für Charactere betretbar sein soll von einem Feld, dass nur aus Fels etc. besteht, zu unterscheiden. Die einzige Möglichkeit ist also eine Zuweisung per Hand. Und das ist natürlich viel zu Umständlich. Gerade wenn dann mal andere Dungeon-Karten hinzukommen, sollte es eine Möglichkeit geben, die Felder auf eine einfachere Weise zu deklarieren…
Ich habe mich deshalb dazu entschlossen, ein kleines Hilfsprogramm zu schreiben, was mir ermöglichen soll, per Mausklick die Felder zu markieren, die zugänglich sein sollen. Das Tool generiert dann automatisch ein Array mit den richtigen Zuweisungen (beispielsweise ein 2D- Array aus einsen und nullen für „unzugänglich“ und „zugänglich“). Dieses Array kann ich dann durchlaufen und anhand der werte (eins oder null) dann das Feld an den gleichen Koordinaten entsprechend markieren.
Um das Tool zu entwickeln, werde ich Java benutzen, da ich in dieser Sprache schon die meiste Erfahrung habe und ich damit das Progrämmchen in zukunft vielelicht  sogar als Applet anderen Nutzern zur Verfügung stellen kann, sofern es denn ein erfolg wird…hehe…
In Zukunft werde ich hier also erstmal über die Entwicklung des Tools quatschen…dannach gehts mit C# und XNA weiter.

der heutige Fortschritt…

trotz des guten Wetters habe ich heute die meiste Zeit des Tages vor dem Laptop verbracht -.-
aber zumindest ist auch was ansehnliches bei rausgekommen.

Zunächst habe ich das grafik-Tablett zur Hand genommen und erstmal ein paar pixelige Sprite-Männchen gemalt, die vielleicht später im Spiel mal Verwendung finden werden…. aber ich denk ich mach mir da nochmal mehr Mühe. Trotzdem will ich euch diese künstlerischen „Meisterleistungen“ nicht vorenthalten.

Ich will nochmal anmerken, dass das natürlich nur erste (10-Mintuten-) Entwürfe sind. Die Finalen Charaktere werden natürlich besser aussehen. Allerdings will ich bei diesem kindlichen chibi- look bleiben, der hat mir auch in den alten Final Fantasy- oder Zelda- Teilen sehr gut gefallen.

Als nächstes hab ich mal ein bischen drauflosprogrammiert und ein kleines erstes Programm geschrieben, mit dem man eine Dungeon- Karte anzeigen lassen, hin- und her scrollen und Zoomen kann. Ich denke, ich werde die Grafik so abstrakt halten, da das (hoffentlich) noch im Ramen meines Könnens ist. Die Dungeon-Karte selbst stammt von www.wizards.com und wird natürlich im fertigen Spiel noch durch eine selbstgezeichnete Map ersetzt…wir wolln ja nicht in Lizenzschwierigkeiten geraten…hehe..

Das Scrollen war eigentlich leichter umzusetzen als ich heute morgen noch dachte. XNA verlangt in der draw()- methode in einer der 7 Überladungen zwei Rectangles. Ein Rectangle ist das „source“ und das andere das „destination“ rectangle. Also: welcher teil des Bildes (source) soll wohin skaliert werden (destination). Destination ist in dem fall immer der gesamte Spiel-Bildschirm. Source kann man im programmablauf jedoch verändern und z.b. die Koordinaten des Rechtecks auf knopfdruck (in meinem Fall die Tasten des D-Pads des Xbox360- Controllers) um einen bestimmten Wert verschieben oder das rechteck auf den ganzen Bereich des Bildes vergrößern (so funktioniert dann das zoomen).

Komischerweise war die Ausgabe der scroll- Pfeile am Bildschirmrand am kompliziertesten. Ich wollte nämlich unbeding das Design-Pattern „State“ dafür verwenden, um zu unterscheiden, in welche Richtung gescrollt wird. Beim State- Design-Pattern ist jeder mögliche Status ein eigenes Objekt. In dem Fall also „nach links, nach rechts, nach oben, nach unten“ scrollen. Über einen default-state kann man auch nachdenken. Ebensogut kann man aber auch eine zusätzliche bool- variable einführen und „currentState.draw()“ nur aufrufen, wenn einer der scroll-richtungen überhaupt verwendet wird.
Das State- Pattern hat den Vorteil, dass man die Objekte schnell verändern kann und sich nicht durch eine lange liste an if- Abfragen wühlen muss.
Im Code taucht dann auch nur ein Objekt auf, das auf den aktuellen State zeigt. Dieser Zeiger wird je nach Status verändert. Die einzelnen State-Objekte verfügen weiterhin über die gleiche Schnittstelle (hier: draw()), sodass im Code sonst keine weiteren Änderungen gemacht werden müssen.

Als nächstes will ich versuchen, auf die einzelnen Felder mit einem Cursor zugreifen zu können. Die Felder selbst werde ich mit Objekten umsetzen. Wahrscheinlich wird das ganze auf ein großes 2D- Array mit allen Feldern (auch da wo Fels ist) des Spielfeldes hinauslaufen. Das hat allerdings den großen Nachteil, dass es sehr lange dauert, alle Fels- Felder als solche auszuweisen, dann das müsste ich alles per Hand machen. Jedoch fällt mir momentan keine andere Möglichkeit ein…

wie es weitergeht….

natürlich war der kleine turret- shooter nur als Übung gedacht… jetzt werde ich das Spiele-Projekt beginnen, was mir schon seit langem durch den Kopf schwirrt: ein Dungeons&Dragons- RPG…. ich weiß! Das klingt jetzt ziemlich hochgegriffen…und das ist es wahrscheinlich auch, dennoch will ich zunächst versuchen, zumindest zwei Prototypen herzustellen: einen Charaktereditor, mit dem man einen D&D-Charakter erstellen kann (natürlich anhand der gültigen D&D-Regeln der Edition 3.5) und ein kleines Kampf-Spiel, in dem ein vorgefertigter Charakter sich durch einen kleinen Dungeon kämpft. Die beiden Prototypen will ich mehr oder weniger parallel entwickeln. Daraus erhoffe ich mir einen natürlichen Motivationsschub: gehts beim einen Projekt nicht weiter, wird am anderen weitergecoded….nunja….vermutlich ist das eher ein System zur völligen De-Motivation, wenns bei beiden nicht richtig weitergeht, aber was solls^^

Zunächst muss ich mir jedoch die D&D Regelwerke (ja! es sind mehrere und ja! Es sind wirklich „WERKE“ – also dicke Schinken!) nochmal zu Gemüte führen, da die letzte D&D – Session schon etwas her ist…
In diesem Sinne werd ich mich jetzt durch diverse pdfs….äh ich meine Bücher wälzen und dann geht die eigentliche Planung los!

das erste Spiel!

auf der Homepage des XNA Creators Club stehen viele Sprites und 3D-Models zum Üben bereit. Anhand dessen, hab ich ein kleines Spiel programmiert, dass dort auch innerhalb eines video-Tutorials entwickelt wird. Ich hab es jedoch komplett selbst programmiert, nachdem ich mir angeguckt hatte, wie es später mal aussehen sollte…mit ein bischen Programmiererfahrung ging das auch ganz gut. Allerdings war die Syntax für Vererbung und Aufrufen des Super-Konstruktors etwas anders als ich es aus Java gewöhnt war….so kann man beispielsweise nicht den Super-Konstruktor mit super() aufrufen, sondern muss den Sub-Konstruktor quasi vom Super-Konstruktor ableiten. Das sieht dann beispielsweise so aus:

public CannonBall(Texture2D _loadedTexture) : base(_loadedTexture)
{

}

aber nun genug geredet: hier seht ihr mein erstes kleines Spiel in Aktion. Bitte entschuldigt die miese Video- Qualität und -framerate. In Wirklichkeit läuft das Spiel absolut flüssig. Man kann das Game entweder mit einem an den PC angeschlossenen XBOX 360- Controller, oder mit der Tastatur steuern.