Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Mär 29, 2024 03:14

Foren-Übersicht » Sonstiges » Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 5 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: SketchtowerWars
BeitragVerfasst: Fr Okt 02, 2009 19:52 
Offline
DGL Member

Registriert: Mo Aug 31, 2009 13:19
Beiträge: 151
SketchtowerWars (STW)

Willkommen zu meinem Projektthread zu SketchtowerWars. Ich werd mir Mühe geben, das Ganze hier einigermaßen sinnvoll zu gliedern und nach jedem Punkt kurz zusammenzufassen, wie der aktuelle Stand an der Entwicklungsfront ist, was in nächster Zeit noch ansteht und wo die Reise in ferner Zukunft einmal hingehen soll.

a) Spielidee
Die Spielidee hinter SketchtowerWars ist vermutlich jedem hier aus anderen Tower Defenses bekannt. Das Spiel spielt auf einer Karte, welche einen Eingang und einen Ausgang beinhaltet. Am Eingang erscheinen in regelmäßigen Abständen Gegner, welche sich zum Ziel gesetzt haben, den Ausgang zu erreichen. Das Ziel des Spielers ist es nun, durch das Platzieren unbeweglicher Verteidigungstürme die Pläne der Gegner (Creeps) zu vereiteln.
Der Spieler gewinnt das Spiel, wenn er erfolgreich alle Creeps getötet hat und verliert, wenn eine kritische Anzahl Creeps das Ziel erreicht hat. Für das Töten von Creeps erhält er Kapital, dass er in neue Türme oder Ausbauten investieren kann.

b) Kartendesign
Es lassen sich drei Möglichkeiten unterscheiden, wie die Maps einer herkömmlichen Tower Defense ausehen:
1. Die Creeps erscheinen bei A, versuchen B zu erreichen und folgen dabei einem festgelegten Pfad, auf den der Spieler keinen Einfluss hat. Der Spieler kann lediglich am Rand des Pfades Türme errichten.
2. Die Creeps spawnen bei A, versuchen B zu erreichen und bewegen sich dabei auf einer zu großen Teilen nach Belieben des Spielers bebaubaren Karte. Durch geschicktes Platzieren seiner Türme kann der Spieler den Pfad der Creeps also verlängern.
3. Die Creeps spawnen bei A und laufen auf einem Rundkurs, bis sie getötet werden. Der Spieler verliert, wenn die Anzahl der lebenden Creeps auf dem Rundkurs eine bestimmte Zahl überschreitet.

SketchtowerWars soll zum Kartendesign einen Karteneditor erhalten, mit dem es auf lange Sicht möglich sein soll, Karten aller drei Typen zu erstellen. Die Kartengröße soll dabei variabel sein.
Technisch gesehen ist die Karte ein im Wesentlichen ein 2-dimensionales Array, welches Informationen über die Begeh- und Bebaubarkeit der einzelnen Felder enthält. Dabei werden vier Zustände für ein Feld unterschieden:
1. Das Feld lässt sich weder betreten noch bebauen
2. Das Feld lässt sich zwar betreten, aber nicht bebauen
3. Das Feld lässt sich nicht betreten, aber bebauen
4. Beides ist möglich

Momentan wird auch das optische Erscheinungsbild eines Feldes noch lediglich von seiner Betret- und Bebaubarkeit bestimmt. Ein blockiertes Feld sieht also aus wie jedes andere blockierte Feld auch. Prinzipiell sollen hier noch unterschiedliche Texturen entstehen, um mehr optische Vielfalt einzubringen.

Entwicklungsstand
Aktuell:
- Die Testumgebung erstellt automatisch eine frei begeh- und bebaubare Karte mit variabler Größe, die lediglich einen vollkommen blockierten Rand erhält. Für Start und Ziel sind im Rand jeweils ein Feld in Zustand 2 belassen.
- Ein Feld im Zustand x sieht aus wie jedes andere Feld im Zustand x auch, unterschiedliche Texturen sind nicht möglich.
- Ein Karteneditor existiert bisher nicht,
Nahe Zukunft:
- Entwicklung eines Karteneditors, mit dem es auch möglich wird den Feldern unterschiedliche Texturen zuzuweisen.
Ferne Zukunft:
- Implementierung des 3. Spieltyps. Da das nicht nur den Karteneditor, sondern auch weiter reichende Änderungen an der KI und begrenzt Anpassungen am Code für das Spielobjekt, benötigt, ist das ein tatsächlich recht weit entferntes Entwicklungsziel.

Wegfindung und KI
Das Kartenobjekt speichert außerdem Informationen die wichtig für die Wegfindung der Creeps sind. Die Wegfindungsroutine ist eng an den Djikstra-Algorithmus angelegt und leistet gute (und ausreichend schnelle) Dienste, so dass ein Umstieg auf einen effizienteren Algorithmus bisher nicht geplant ist.
Die Wegfindung verläuft in drei Schritten:

1. Punkte finden, die prinzipiell auf einer sinnvollen Route liegen könnten (Knotenpunkte). Das sind all solche Punkte, die zwischen 4 Feldern liegen, von denen genau eins nicht betretbar ist. Wird ein solcher Punkt gefunden, legt der Algorithmus an seiner Position einen Knoten an. Die Position des Knotens wird dabei ein wenig vom nicht betretbaren Feld weg "geschoben", um zu verhindern, dass später zu sehr der Eindruck entsteht, dass die Creeps über die Ecken von Türmen laufen würden.
2. Jeder Punkt P erhält einen Wert abhängig davon, wie weit er vom Ziel entfernt ist. Ist das Ziel nicht direkt erreichbar wird überprüft, ob ein Punkt Q erreichbar ist der bereits einen Wert erhalten hat. Zu diesem Wert wird dann die Entfernung von P zu Q addiert und das Ergebnis als Wert für P gespeichert. Dies wird so oft wiederholt, bis bei einem Schleifendurchlauf keine Änderung mehr auftritt.
3. Vom Start aus werden die Punkte mit den niedrigsten Werten verbunden.

Dadurch, dass in den meisten Fällen von einem Knoten P aus sowieso nur zwei andere Knoten O und Q erreicht werden können, wobei O der Vorgängerknoten und Q der Nachfolger ist, hält sich der Aufwand bei der Routenberechnung sehr in Grenzen. Natürlich lassen sich Szenarien mit vielen Knoten und gangbaren Wegen konstruieren, wo der Algorithmus in die Knoten geht, ich bin aber zuversichtlich, dass das im "normalen" Spielbetrieb nicht passieren wird ;)
Trotzdem weißt das Verfahren noch ein Problem auf, dem ich bisher relativ machtlos gegenüber stehe. Das Problem liegt hier weniger im Verfahren selbst, als darin festzustellen, ob ein Weg zwischen zwei Knoten wirklich blockiert ist. Verläuft der überprüfte Weg nämlich so, dass ein Punkt genau zwischen vier Feldern auf dem Weg liegt und von diesen vier Feldern sind zwei diagonal zum Weg angeordnete Felder blockiert, so fällt diese Blockade nicht auf.

Ebenfalls zur KI gehört die Zielsuche der Türme.
Momentan ist es hier so, dass ein Turm der kein Ziel hat, aus allen Creeps die sich in seiner Reichweite befinden dasjenige herraussucht, welches ihm am nächsten ist. Dieses wird dann so lange beharkt, bis es stirbt oder außer Reichweite gerät. Klüger wäre es natürlich (meistens), immer das Creep zu beschießen, welches den kürzesten Weg zu Ziel zurückzulegen hat. Im fertigen SketchtowerWars soll der Spieler die Möglichkeit haben zwischen diesen zwei und vllt. einigen weiteren Möglichkeiten zu wählen - da das Ganze im momentanen Stadium aber völlig ausreichend ist, ist auch das ein fernes Entwicklungsziel.

Entwicklungsstand
Aktuell:
- Wegfindung funktioniert mit kleineren Macken
- Zielsuche der Türme ist auf einfachste Art und Weise implementiert
Nahe Zukunft:
- kleinere Macken in der Wegfindung ausbügeln - ich bin hier übrigens für Ideen offen.
Ferne Zukunft:
- Dem Spieler verschiedene Möglichkeiten der Zielauswahl seiner Türme (oder auch einzelner Türme) zur Wahl stellen.
- Möglicherweise auch direkte Steuerung einzelner Türme.

Technik und Benutzeroberfläche
SketchtowerWars ist vorerst 2D. 3D ist geplant, aber so weit entfernt, dass ich sicherlich eine fertige 2D-Version veröffentlichen werde, bevor ich mich an die 3D-Umsetzung setze.
Das Rendern der Spielszene erfolgt in drei Schritten (innerhalb eines Renderpasses) - Schritt eins ist das Rendern der Karte ohne Transparenz, darauf folgt das Rendern aller Spielobjekte mit Transparenz. Der letzte Schritt ist die Darstellung von Explosionen etc. welche mit einer bescheidenen Partikelengine umgesetzt wurden.
Beim Rendern der Spielobjekte wird von den Türmen lediglich das eigentliche "Geschütz" gerendert. Die Textur der Turmbasis wird durch das darunterliegende Kartenfeld dargestellt. Wer oben bereits aufmerksam gelesen hat kann sich vorstellen, dass ein blockiertes Feld demnach aussieht wie ein Turm ohne Geschütz ;)
Auch die Darstellung der Partikeleffekte macht mir noch ein wenig Kopfschmerzen - im Anfängerforum gab es vor ein paar Wochen einen Thread zu dem Thema von mir. Die dort gefundene Lösung funktionierte leider nur, bis ich angefangen hab auch andere Spielobjekte zu rendern. Diese weisen im Gegensatz zur Karte einen Alphawert von 1 (Karte: 0) auf - die "Lösung" meines Darstellungsproblems sorgt nun dafür, dass dort, wo die (prinzipiell ja viereckige) Textur der Partikel mit einem Spielobjekt überlappt, das Spielobjekt extrem aufgehellt wird. Was bei einer Explosion jetzt noch recht cool danach aussieht, als würde das Spielobjekt angestrahlt werden verliert bei einer Rauchwolke leider jegliche Möglichkeit sich aus diesem Darstellungsfehler rauszureden.
Die Partikel"engine" wird aber gerade sowieso einer grundlegenden Änderung unterzogen - mehr dazu in einem späteren Punkt.
Im Spiel lassen sich auch bereits Türme und Creeps auswählen und ihre Informationen lassen sich anzeigen. Die Auswahl ist mit Colorpicking, aber ohne Shader realisiert. Im Selectionmode wird also für jedes Creep und jeden Turm ein Quad in der Selektionsfarbe gerendert. Dies führt unweigerlich dazu, dass ein rundes Creep auch dann angewählt wird, wenn man leicht versetzt daneben klickt.
Während die Spieloberfläche (Karte, Creeps, Türme, Partikeleffekte, Projektile) vollständig mit OpenGL dargestellt wird, bediene ich mich für Bedienfelder (Fenster in denen Informationen zu angewählten Objekten angezeigt werden, die Auswahl des momentan zu bauenden Turmes etc.) noch der VCL.

Entwicklungsstand
Aktuell:
- 2D-Spielumgebung in OpenGL, Bedienfelder VCL.
- rudimentäre Partikelengine mit Darstellungsfehlern
- Colorpicking ohne Shader
Nahe Zukunft:
- Komplettes GUI in OpenGL realisieren (ein Punkt, der zwar für die nahe Zukunft geplant ist, dessen Zeitaufwand ich aber nur schwer einschätzen kann. Von allen in naher Zukunft geplanten Punkten ist dieser der letzte.)
- etwas ausgefeiltere Partikelengine, dann auch ohne Darstellungsfehler.
Ferne Zukunft:
- Colorpicking mit Shader (ich erachte das hier nicht als sooo unendlich wichtig, darum ist der Punkt nich für die nähere Zukunft geplant)

Türme
Momentan sind 6 grundlegende Turmtypen implementiert, zu denen sich noch 3 weitere gesellen sollen. Türme lassen sich nach dem klassischen Prinzip errichten: "Sage mir, welchen Turm du wohin bauen willst, ich färbe das Feld dann grün ein, wenn es möglicht ist - oder rot, wenn nicht. Klicke um den Turm zu bauen".
Die Rotfärbung indiziert hierbei momentan nur, ob ein Feld aufgrund seines Feldtyps bebaubar ist, oder nicht. Auf Creeps oder deren Pfad (es muss ja immer ein gültiger Pfad vom Start zum Ziel existieren) wird zum Zeitpunkt der Platzauswahl keine Rücksicht genommen. Das Spiel meckert allerdings dann beim Versuch den Turm tatsächlich zu errichten und meldet dem Spieler, dass das nicht möglich ist.
Die Werte der Türme sind im Moment (genau wie die der Creeps) in einer ADO-Datenbank abgelegt. Dieses Verfahren wird im Moment (gemeinsam mit der Partikelengine - warum sich das zusammenfassen lässt: Später) überarbeitet.
Der Ausbau der Türme erfolgt relativ stumpf: Aus Geschützturm Stufe 1 mache Geschützturm Stufe 2 mit etwas höherer Reichweite, Schaden etc. Auch das soll sich ändern:

Geschützturm Stufe 1 lässt sich für Geld ausbauen zu drei versch. Geschütztürmen, die prinzipiell etwa äquivalent gute Dienste leisten, aber:
- Geschützturm 2a verbessert lediglich die prinzipielle Idee des Turms (gleichzusetzen mit dem stumpfen Upgrade)
- Geschützturm 2b fügt in einem sehr kleinen Bereich Flächenschaden zu, besitzt dafür aber ansonsten nur geringfügig verbesserte Eigenschaften
- Geschützturm 2c verschießt Geschosse, die Gegner vergiften.

Wie gesagt, der Schadensausstoß soll für alle drei Möglichkeiten etwa äquivalent sein, aber für weitere Ausbauten sind nicht nur Geld, sondern auch "Erfahrungspunkte" (sollte ich noch anders nennen :D) nötig. Von denen gibt es drei Arten:
- Erfahrungspunkte aus Direktschaden...diese sammelt Geschützturm 2a, wenn er Creeps tötet
- Erfahrungspunkte aus Flächenschaden...gesammelt von Geschützturm 2b
- Erfahrungspunkte aus Schaden über Zeit...dreimal dürft ihr raten.
(Einige kennen das System vllt. von Fable)
Für die richtig ausgeklügelten Türme werden Erfahrungspunkte schon beim Aufbau fällig, sodass diese nur dann gut verfügbar werden, wenn man sich spezialisiert und keinen indifferenten Erfahrungspunktbrei sammelt.

Entwicklungsstand
Aktuell:
- Speicherung der Daten in ADO-DB.
- 6 Turmtypen implementiert
- stumpfes Ausbausystem
- "Buffplacer" bei Türmen (Vergiftung, Verlangsamung, etc. von getroffenen Creeps) noch nicht eingebaut
- Spezialfähigkeiten (Höherer Schaden gegen Luftgegner, etc.) noch nicht eingebaut
- lediglich Flächenschaden bereits implementiert
Nahe Zukunft:
- Speichern der Daten in ini-Files, die von einem Inireader ausgelesen werden (siehe weiter unten)
- 9 Turmtypen
- Implementierung von Buffplacern und Spezialfähigkeiten
Ferne Zukunft:
- Ausgefeilteres Ausbausystem

Creeps
Es gibt 12 verschiedene Creeps, die auch alle schon prinzipiell implementiert sind. Wie bei den Türmen auch gilt allerdings das ihre Spezialeffekte noch nicht greifen (ein Creep, das bei seinem Tot alle in der Nähe befindlichen Creeps heilt tut dies also noch nicht, etc). Auch die Creepwerte sind in einer ADODB gespeichert - wie bei den Türmen gilt allerdings: Das soll sich ändern.
Damit ein Creep mit Typ A auch am Ende des Spiels noch "konkurrenzfähig" sein soll, unterscheiden Creeps sich nicht nur in ihrem Typ, sondern auch im "Level". Creep mit höherem Level haben allgemein gesteigerte Basiswerte.
Ein kleiner Auszug aus dem "Plot", was die Creeptypen angeht:
- Standard: Das Normcreep - in allen Belangen normal.
- Läufer: Besonders schnell
- Sprinter: Nicht nur besonders schnell - solang es geradeaus geht wird er auch immer schneller.
- Gruppe: Füllt sich in Gruppen besonders wohl
- Mob: Füllt sich nicht nur in Gruppen wohl...wird auch aggressiv und beschädigt Türme, an denen er vorbeiläuft.
- Fliegend: Kümmert sich nicht um blockierte Felder
uvm.

Was die Creepabfolge angeht, gibt es im Moment drei Möglichkeiten:
a) Das Spiel erstellt automatisch eine Liste nach dem Schema A1 A2 B1 A3 B2 C1 A4 B3 C2 D1 (Buchstaben sind Typen, Zahlen Levels)
b) Das Spiel erstellt eine Liste mit zufälliger Typenfolge aber kontinuierlich steigenden Level. Prinzipiell diffiziler auszuschaltende Creeptypen haben hierbei ein Mindestlevel, können also nicht am Anfang schon auftauchen
c) Der Spieler bestimmt die Creepfolge.

Entwicklungsstand
Aktuell:
- 12 verschiedene Creeptypen
- Werte aus ADODB
- keine Spezialfähigkeiten
- Levelsystem zum Erhalt der "Konkurrenzfähigkeit"
- Drei Möglichkeiten zum Erstellen der Creepabfolge
- keine gemischten Creepwellen
Nahe Zukunft:
- Werte aus ini-Datei
- Implementierung der Spezialfähigkeiten
- Möglichkeit gemischter Creepwellen
Ferne Zukunft:
- Nichts.

Partikelengine
Zur Darstellung von Explosionen, Schockwellen, Rauch hinter Raketen etc. dient eine sehr rudimentäre Partikelengine, die nicht viel mehr kann, als Emitter erstellen die Partikel in zufälliger Richtung mit in Grenzen zufälliger Geschwindigkeit und ebenfalls in Grenzen variierender Farbe emittieren.
Das reicht für einfache Effekte - um etwas mehr Vielfalt reinzubringen existieren Pläne für eine etwas weiter gehende Engine:
Platzierbar sind nicht nur Emitter, sondern auch Manipulatoren, die auf Partikel in ihrer Reichweite ein anziehende / abstoßende Wirkung auswirken, die Farbe oder Größe von Partikeln in Reichweite ändern oder Partikel einfach verschwinden lassen.
Die Basiswerte der Partikelemitter (die Werte also, die einen Emitter für eine Explosion nach einer Explosion aussehen lassen) stehen momentan noch hardcoded im Programmcode - das soll sich ändern.
Btw.: Bemerkungen wie "Du programmierst doch schon das Spiel, nimm doch einfach Fireblade..." mag ich nich. Erstens macht mir die Entwicklung der Engine ne Menge Spaß. zweitens dient dieses Projekt für mich dazu, mich mit den OpenGL-Grundlagen entgültig vertraut zu machen, dafür ist das recht hilfreich. Und drittens: Ich befürchte Fireblade wäre mit Kanonen auf Spatzen geschossen. ;)

Entwicklungsstand
Aktuell:
- rudimentäre Partikelengine implementiert
- Werte für Emitter hardcoded
Nahe Zukunft:
- fortgeschrittene Partikelengine
- Werte für Partikelengine (ebenso wie die von Creeps und Türmen) aus Ini-Datei.
Ferne Zukunft:
- Nüx.

Ini-Reader
Ich will es nicht Scriptsprache nennen, denn es dient lediglich dazu, im Spiel Werte zu verteilen. Dennoch soll die Sache darüber hinaus gehen, Zeilen auszulesen, die so aussehen:
Code:
  1.  
  2. Hitpoints=120
  3.  

Und daraufhin einem Creeptyp 120 Basislebenspunkte zu verleihen, wobei mit einer Case-Anweisung geprüft wird, ob da jetzt "Hitpoints" stand oder "Speed".
Ich geb euch mal nen Auszug der Ini-File, an der ich den "Compiler" momentan teste und entwickle:
Code:
  1.  
  2. 1   IniFile Particles;
  3.  
  4. 2       Attractor(Attractor1);
  5. 4       Strength=   10;
  6. 5       Range=      400;
  7. 6       MinAge=     0;
  8. 7       MaxAge=     1.0;
  9. 8       End;
  10.  
  11. 9       Emitter(STW_Baseemitter);
  12. 10      EmissionInterval=   0.1;
  13. 11      ParticleLifespan=   1.0;
  14. 12      ParticlesPerEmission=   100;
  15. 13      TotalEmissions=     1;
  16. 14      MinAngle=       0;
  17. 15      MaxAngle=       360;
  18. 16      Range=          0;
  19. 17      Speed=          100;
  20. 18      ParticleSize=       5;
  21. 19      ParticleMass=       1;
  22. 20      ParticleTexture=    "Testtextur.tga";
  23. 21      ParticleFadeSize=   0;
  24. 22      ParticleFadeAlpha=  0;
  25. 23      ParticleTraceCooldown=  0;
  26. 24      Color(1.0, 1.0, 1.0, 1.0);
  27. 25      End;
  28.  
  29. 26      Emitter(STW_ExtEmitter);
  30. 27      inherited(STW_Baseemitter);
  31. 28      AddManipulator(Attractor1);
  32. 29      EmissionInterval=   Rel(2);
  33. 30      ParticlesPerEmission=   Add(50);
  34. 31      End;
  35. 32  End;
  36.  

Ich denke, dass Ganze ist gut lesbar, die Zeilennummern dienen nur der Illustration.
Trotzdem nochmal das, was der Partikelcompiler tut (tun soll), wenn man ihn mit der File konfrontiert:
Zeile 1:
Hallo, ich bin ein IniFile und heiße Particles

Zeile 2:
Es folgt die Definition eines Attractors namens Attractor1, also schau die die Klasse TSTW_Attractor an, und mach dich schlau, welche Eigenschaft sie published zur Verfügung stellt. Diese sind als Identifier in der folgenden Definition erlaubt - und lege einen Rohling für den Prototypen eines Attractors an

Zeile 3-7:
Festlegung der Werte des Prototyps Attractor1

Zeile 8:
Die Definition ist fertig, warte auf die nächste

Zeile 9:
Es folgt die Definition eines Emitters namens STW_Baseemitter, mach dich schlau, welche Identifier du akzeptieren solltest usw. (s. o.)

Zeile 10-23:
Werte festlegen

Zeile 24:
Weil ich nicht weiß, ob sich ein Record (speichere Farben in Records) irgendwie brauchbar aus der RTTI auslesen lässt, geh ich auf Nummer sicher und definier ein Keyword dafür.

Zeile 25:
Definition abgeschlossen.

Zeile 26:
Der nächste Definitionsteil

Zeile 27:
Fertige als Prototyp für STW_ExtEmitter eine Kopie des Prototyps von STW_BaseEmitter an.

Zeile 28:
Füge zum Prototypen den vorher definierten Manipulator Attractor1 hinzu

Zeile 29:
Multipliziere den Wert von EmissionInterval mit 2.

Zeile 30:
Addiere 50 zum Wert von ParticlesPerEmission.

Gerade die "Vererbung" im letzten Teil ist für mich der Hauptgrund, den Ini-Reader zu schreiben. Wie gesagt, ich will es nicht Scriptsprache nennen. Erstens wird nirgendwo Code erzeugt, zweitens läuft das Ganze nicht auf einer VM.
Der im Großen und Ganzen selbe Reader soll auch die Werte für Creeps und Türme auslesen können.

Herausragende Merkmale sind für mich:
- Zugriff auf Objekteigenschaften direkt über die RTTI und nicht über irgendwelche Case-Konstrukte oder so
- Vererbung von Objekteigenschaften
- Anlegen von Prototypen, d.h. die Ini-Files werden beim Programmstart einmalig ausgelesen, daraufhin werden nur noch Kopien der Prototypen angelegt.

Entwicklungsstand
Aktuell:
- Work in Progress.
- Syntaktische Überprüfung funktioniert.
Nahe Zukunft:
- Speichern der für einen Definitionsblock zulässigen Identifier
- Zuweisen der Werte an Prototypen
Ferne Zukunft:
- Nichts.

End.

Okeh, ist jetzt sehr ausführlich geworden, aber dafür habt ihr auch einen praktisch vollständigen Ausblick in mein Plot. Außerdem ist das seit langem nochmal eine Gelegenheit für mich gewesen, mein Plot "aufs Papier" zu bringen, was auch seinen Teil zur Ausführlichkeit beigetragen hat. Ich bin jetzt mal gespannt, ob irgendjemand den Thread in seiner Ganzheit liest und freue mich auf Feedback und Motivation.
Im nächsten Post gibts auch Screenshots aus der Testumgebung, die Probleme und Entwicklungsstand dokumentieren, versprochen.

Achja, zu meinem Zeitplan:
Es klingt vieles so, als würde es mich noch wochenlange Entwicklung kosten - bei den meisten Sachen ist das auch ohne Zweifel so (aber so ist das halt bei nem Solo-Projekt), gerade bei vielen Kleinigkeiten sind die Grunlagen im Code aber bereits gelegt, so dass ihre Entwicklung nicht mehr ewig dauern sollte. Ich arbeite jetzt seit knapp 5-6 Wochen ernsthaft an diesem Projekt, davor lag etwa die selbe Zeit an Codegeplänkel. Ich denke also, zumindest die Ziele in "Naher Zukunft" sind wirklich greifbar.
Ich muss allerdings auch gleich erwähnen, dass die Entwicklung sich in nächster Zeit etwas verzögern wird - für mich steht ne mündliche Diplomprüfung in etwa nem Monat an, da kommt jetzt langsam das Lernen ;)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Okt 04, 2009 17:33 
Offline
DGL Member

Registriert: Mo Aug 31, 2009 13:19
Beiträge: 151
So, wie versprochen kommen hier ein paar Screenshots...

Screen 1
Wie der Name schon sagt, sieht man hier, wie es ausschaut wenn der Spieler im momentanen Betastadium ein Creep anklickt.
Es werden noch ein paar Informationen angezeigt, die mich zu Debuggingzwecken interessiert haben, das ändert sich zum Release natürlich ;)

Screen 2
Der Screenshot zeigt einen Schockturm beim Feuern. Die Schockwelle ist mit meinem Partikelsystem realisiert worden. Am rechten und oberen Rand der Welle kann man auch erkennen, was mich im Moment noch daran stört: Dort wo ein Bereich eines Partikels, dessen Alphawert 0 ist mit einem Turm überlappt, wird der Turm "überbelichtet", auch wenn es sich hierbei natürlich nicht um einen Fehler im Lighting handelt - Lighting ist (bisher) nicht implementiert.

Nachtrag: Auch wenn man es übrigens auf dem Screenshot nicht erkennen kann - prinzipiell ist das ein recht cooler Effekt, der da versehentlich entstanden ist - das Problem ist halt, dass er von jedem Partikeleffekt hervorgerufen wird - auch von Rauchwolken, die leider nicht leuchten. In dem Fall ist der Effekt halt nimmer cool...

Screen 3
Im Großen und Ganzen: Siehe Screen 1, bloß, dass hier ein Turm ausgewählt ist.
Auf beiden Screenshots ist natürlich auch die aus VCL-Komponenten zusammenimprovisierte GUI zu sehen, die noch durch OpenGL ersetzt werden soll. Mein größtes Problem mit der VCL ist dabei nichtmal, dass es potthässlich ist - Ein Verschieben einer der kleinen VCL-Forms sorgt leider dafür, dass das Spiel angehalten wird, bis die Maustaste vom Verschieben wieder losgelassen wird.

Screen 4
Der Screenshot wurde mit aktiviertem Rendering der Mapknotenpunkte aufgenommen, sodass man sehr gut erkennen kann, wo die Wegfindung Knoten setzt und wo nicht. Knotenpunkte mit niedrigem Wert sind übrigens grün, solche mit hohem Wert rot gerendert. Der von der Wegfindung vorgeschlagene Weg wird nicht mitgerendert, aber ich kann euch versichern - es ist der kürzeste mögliche ;)

Screen 5
Zu guter Letzt noch wie versprochen ein Screenshot, der mein Problem mit der Wegfindung illustriert. Der momentan ausgewählte Knoten ist der obere, linke mit türkisem Kreis. Wer jetzt entweder meine dezente Linie richtig deutet, oder einen Blick auf das Auswahlfenster wirft sieht, dass die Wegfindung denkt, der Punkt unten rechts (Koordinaten sind 8.8 / 6.8, es ist also die Nr. 7 in der Liste) sei von dort aus erreichbar.
Das unheimlich photogene Creep, dass gerade genau zwischen den zwei Türmen auf der Linie sitzt, war so frei sich an der problematischen Stelle ablichten zu lassen.
Ich bin Hilfe zu diesem Problem keinesfalls abgeneigt...


Dateianhänge:
Dateikommentar: Screen 5
Screen-Wegfindungsproblem.jpg [92.29 KiB]
43-mal heruntergeladen
Dateikommentar: Screen 4
Screen-Wegfindung.jpg [97.23 KiB]
34-mal heruntergeladen
Dateikommentar: Screen 3
Screen-Turmauswahl.jpg [91.41 KiB]
29-mal heruntergeladen
Dateikommentar: Screen 2
Screen-Shockwave.jpg [73.42 KiB]
37-mal heruntergeladen
Dateikommentar: Screen1
Screen-Creepauswahl.jpg [89.79 KiB]
36-mal heruntergeladen
Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Okt 28, 2009 17:40 
Offline
DGL Member

Registriert: Mo Aug 31, 2009 13:19
Beiträge: 151
So, knapp nen Monat nach meinem Mammutpost gibts ein kleines Update zu meinem Voranschreiten.

1. Der Ini-Reader und die Prototypenfabrik
Das Auslesen von Dateien funktioniert mittlerweile bestens, auch das Erstellen der Prototypen funktioniert problemlos. Lediglich eine kleinere Kinderkrankheit hat der Reader noch, er spuckt auch bei syntaktisch korrekten Dateien einige Fehlermeldungen aus, ignoriert sie aber und erstellt die Prototypen mit den korrekten Werten. Alles in allem muss ich sagen, dass die Entwicklung dieses Teils von Sketchtowerwars das größte Zeitkontingent der vergangenen paar Wochen in Anspruch genommen hat. Wie man mehreren Threads von mir im Allgemein-Forum entnehmen kann war das eine ordentliche Hantiererei mit der RTTI.
Das größte Problem hierbei war es, Kopien von Partikelemitterprototypen zu erzeugen, da die Manipulatoren, die Einfluss auf das Verhalten der vom Emitter erzeugten Partikel nehmen sich in einem dynamischen Array befinden. Das Array weigerte sich, bis ich einem Denkfehler meinerseits auf die Schliche gekommen bin, vehement dagegen, korrekt via RTTI ausgelesen zu werden.
Bisher lassen sich nur Prototypen von Partikelemittern und -Manipulatoren erzeugen, es werden noch Creeps, Tower und Projektile folgen, bis ich eine SketchtowerWars-Version erstellen kann, die meinen Fortschritt auf dem Gebiet ausnutzt. Prinzipiell stellt das aber kein größeres Problem dar.

2. Das Partikelsystem
Hier gibts nicht viel neues zu berichten, außer das die Manipulatoren implementiert sind und ich nun Objekte erzeugen kann, die die Eigenschaften von Partikeln in der Nähe ändern. Ich hab noch nicht so sehr damit experimentiert, gehe aber davon aus, dass ich damit einige interessante Effekte erzeugen kann, die vorher nicht möglich gewesen wären.

3. Das GUI
Für mich selbst etwas überraschend war es, dass ich nun doch bereits damit begonnen hab, die Grundlagen für das grafische Benutzerinterface zu legen. Ich hatte damit angefangen, eine Entwicklungsumgebung für Partikeleffekte zu schreiben und wollte irgendwann die Möglichkeit schaffen, Emitter und Manipulatoren durch Drag & Drop zu bewegen. Das gab den Anstoss, die GUI-Entwicklung etwas vorzuziehen.
Ich wollte dabei der Prämisse folgen, den Kern der Anwendung von vornherein weitgehen von der GUI zu entkoppeln, um meine Flexibilität nicht einzuschränken.
Meine Idee war, die gesamte GUI-Verwaltung, also das Hinzufügen von Kontrollelementen, deren Freigabe und das Aufrufen von Eventhandlern einem GUI-Manager zuzuschreiben. Dieser beinhaltet also eine Liste mit allen GUI-Elementen (sichtbar und unsichtbar), Methoden zum Hinzufügen und Freigeben von GUI-Elementen und letztlich übernimmt er auch das Rendern und Aktualisieren der Elemente.
Beim Erzeugen des Managers übergebe ich ihm das VCL-Objekt auf dem der Renderkontext erstellt werden soll, und von welchem der GUI-Manager dann auch Benutzerereignisse wie OnClicks etc. entgegennimmt.
Tritt nun beispielsweise ein solches OnClick-Ereignis ein, führt der GUI-Manager ein Colorpicking aller sichtbaren Komponenten durch und ruft (falls er unter Mauszeiger ein Objekt gefunden hat) den OnClick-Handler dieses Objektes auf.
Der nächste Schritt wird jetzt die Implementierung einiger Kontrollelemente - konkret Labels, editierbare Textfelder, Buttons, Listen und Container für Kontrollelemente.

4. Wegfindung
Eigentlich das einzige, was direkt mit dem Spiel zu tun hat - hat die kleinsten Fortschritte gemacht. Konkret getan hat sich hier auch nichts, aber ich hab mich mit ner befreundeten Mathematikerin beraten und den ein oder anderen Lösungsansatz zu meinen Problemen gefunden.

Soviel zum atuellen Stand an meiner Front, nächsten Monat gibts die nächsten Neuigkeiten ;)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: SketchtowerWars
BeitragVerfasst: So Aug 22, 2010 23:58 
Offline
DGL Member

Registriert: Mo Aug 31, 2009 13:19
Beiträge: 151
*Thread hervorkram*
*Staubwedel auspack*
*Staubschicht grob wegpust*
*hust* *keuch*

Ähem...
Ja, lang ists her. Aber wenn ich noch ein wenig Zeit habe, dann tu ich auch immernoch was an diesem Projekt.

Fangen wir mal mit all dem an, was keine Fortschritte gemacht hat...

Das Partikelsystem, die kleingeistige Idee, irgendwas mit .ini-Files anzustellen und die dafür zu schreibende "Miniscriptsprache":

- Ein Partikelsystem wirds natürlich geben, aber ich denke nicht, dass ich das in der Komplexität einbauen werde, in ders geplant war. Generell bin ich etwas dazu übergegangen, das Projekt erstmal einfach fertig zu kriegen. Konkret heißt das für das Partikelsystem, dass es wahrscheinlich auf dem Stand bleiben wird, auf dem es in Version 0.1 schonmal eingebaut war - das heißt es wird praktisch eine Abschrift des Partikelsystems aus dem Tutorial.

- Die Inifiles: Weiß der Geier, was ich mir dabei gedacht hatte. Die Teile sind einfach unbequem zu handeln und bieten nur eine Ebene, was sie nicht gerade übersichtlich macht. Also: In die Tonne gekloppt und umgesattelt auf .xml (siehe unten)

- Die "Scriptsprache" recht offensichtlich hab ich mich hier auch übernommen. Ich spiele immernoch mit dem Gedanken, meinem GUI eine Scriptunterstützung zu verpassen, werde mich da aber (wenn es so weit kommen sollte - zu meiner Motivation zu dem Gedanken siehe unten) an einer bestehenden Scriptsprache bedienen. Manchmal muss man einfach zurückstecken.

Und nun zum eigentlich einzigen Teil, der Fortschritte gemacht hat: Das GUI und die Geschichte mit den .xml's:

Ich hab natürlich drüber nachgedacht, mich auch bei der GUI bei etwas Bestehendem zu bedienen, und STW einfach "erstmal fertig zu kriegen". Dabei bin ich aber zum Schluss gekommen, dass ein wirklich leistungsstarkes GUI allen kommenden Projekten auch zu Gute kommen würde und im Forum hab ich einfach kein GUI-Projekt gefunden, welches mich wirklich zufrieden gestellt hat (hab das Forum dahingehend allerdings auch nur überflogen).
Also hab ich mir Gedanken gemacht, was mein eigenes GUI so können sollte, und die wichtigsten Punkte waren:

  • Interaktion mit dem Benutzer durch Mausklicks und Tastatureingaben ist denke ich selbstverständlich - sonst wärs ja kein Interface
  • GUI-Elemente sollten prinzipiell in allen Formen (aber immer zweidimensional) möglich sein
  • Es sollte eine Möglichkeit bestehenden, GUI-Elemente nach WYSISYG-Manier zu entwerfen, zu speichern und im Projekt zu benutzen
  • Die gespeicherten Dateien sollten gut lesbar sein, damit ich Fehler bei der Erstellung dieser Dateien (auch wenn diese automatisiert geschieht) finden und nachvollziehen kann
  • Das GUI soll eine hierarchische Struktur ähnlich dessen aufweisen, was Windows zur Verfügung stellt - wir erstellen Fenster, in denen sich Buttons befinden... ihr wisst schon, was ich meine.

Diese Liste hab ich sozusagen von hinten aufgezäumt - ich hab mir zuerst Gedanken zur Datenspeicherung, der Lesbarkeit der gespeicherten Daten und der Struktur der GUI gemacht. Und die erste Erkenntnis, die ich während der Entwicklung hatte hab ich oben schon erwähnt: Vergiss .ini, nimm .xml.
Bei der Umsetzung der ganzen Geschichte war dann die RTTI und objektorientierte Programmierung sehr hilfreich - das Ganze kennt zwei Basisklassen:
  • TStreamable - Die Klasse ist abgeleitet von TPersistent und stellt zwei Methoden zur Verfügung, die alle publizierten Eigenschaften des Objekts in eine .xml schreibt oder aus ihr liest - dafür brauch ich die RTTI, wer hätts gedacht. Hiervon werden nur kleinere Hilfskomponenten, wie beispielsweise die Vertices der nicht-rechteckigen Kontrollelemente abgeleitet und natürlich auch...
  • TStreamableComponent - Hier spielt sozusagen die Musik für die GUI. Diese Klasse fügt zu TStreamable ein Array hinzu, welches andere StreamableComponents aufnehmen kann, außerdem Methoden um dieses Feld aufzuräumen, sowie die Eigenschaften "Name" und "ZOrder". ZOrder hier schon zu implementieren fiel mir etwas schwer, weil das eigentlich über die "Zuständigkeit" der Klasse hinausgeht, aber es war der einzige Weg, allen Komponenten meiner GUI die Möglichkeit zu geben, Tochterkomponenten nach ihrer ZOrder zu sortieren, was für den Einbau von Transparenz unabdingbar ist, um die korrekte Renderreihenfolge einzuhalten. Ansonsten erweitert die Klasse die beiden Methoden zum Schreiben und Lesen von .xml-Dateien noch um die Funktionalität, die nötig ist, um Tochterkomponenten mit in die Datei zu schreiben.

Bisher gibt es darüber hinaus bis jetzt nur noch:
- eine Managerklasse, die von TStreamableComponent abgeleitet ist und sozusagen die nullte Ebene der Hierarchie darstellt.
- eine Klasse, von der alle sichtbaren GUI-Komponenten abgeleitet werden und die abstrakte Methoden zum Rendern, Verschieben, Verzerren und zum Auffinden von Mausereignissen (schlicht: für alles, was jedes sichtbare Element irgendwie können muss) besitzt
- eine Vertexklasse, um die Eckpunkte nicht-rechteckiger Kontrollelemente zu speichern
- eine Klasse, die die Basis aller rechteckigen Kontrollelemente darstellt - kann nicht mehr, als sich zeichnen lassen und eine Textur haben. Und natürlich auf Mauseingaben reagieren (Click, Down, Up, Move, Leave, Enter)
- letztlich noch die Basis aller nicht-rechteckigen Kontrollelemente: Macht eigentlich alles genau so wie bei den rechteckigen, aber für ettliche Dinge muss man nicht-rechteckiges am Computer bekanntlich in Dreiecke zerlegen - genau das kann diese Klasse.

Das ist prinzipiell noch nicht viel, reichte mir aber, um die Entwicklung des Editors zu beginnen, damit ich die Chance habe, meine Fortschritte auch zu "sehen". Wenn ich schon was mit OpenGL mache, dann will ich das ja auch zu Gesicht bekommen - sonst schwindet die Motivation bei mir extrem schnell. Der kann auch tatsächlich schon so Einiges, beispielsweise stellt er die momentan bearbeitete GUI in einer Baumstruktur dar (Entschuldige Lord Horazont, aber ich bin bei TTreeView geblieben ;)), lässt die Bearbeitung von Elementeigenschaften "on the fly" zu, beherrscht Multiselection, Drag & Drop, Größenvariation von Kontrollelementen mit der Maus... Er macht tatsächlich schon einen recht mächtigen Eindruck, wenn ich mich hier mal selbst loben darf. Screenshots davon gibts noch, aber erst, wenn Texturen nicht nur prinzipiell möglich, sondern auch tatsächlich implementiert sind (dazu gibts demnächst wahrscheinlich noch nen Thread von mir) - nur farbige Kästchen auf dem Screenshot wären ja nun extrem langweilig.

Nun zu den Dingen, die die GUI noch nicht kann:
- Textdarstellung. Natürlich sehr, sehr wichtig, ich werd mich dafür bei Lossy's Textsuite bedienen, ich denke, die ist zu gut, um selbst irgendwas zusammenzuimprovisieren (kostet mich ja auch nur wieder Zeit)
- Mapping von Eventhandlern aus der .xml hinaus...

Das letzte ist der Punkt, der mich am meisten ärgert. Ich würde zu gern in die .xml sowas reinschreiben können wie "OnClick=glButtonOnClick", und wenn er die GUI läd sucht er im Projekt nach einer Prozedur "glButtonOnClick" und weißt den Callback entsprechend zu - leider ist mir dazu kein Mittel bekannt und irgendwie ist mir auch klar, dass das nicht so wirklich funktionieren kann. Andererseits können die delphi-eigenen .dfm-Dateien das auch, und es wäre für den "Benutzer" einfacher, als die GUI zu entwerfen, die Zuweisungen zu schreiben und im Projekt, wo die GUI zum Einsatz kommen soll nur noch die entsprechenden Prozeduren zu schreiben und fertig.
Andererseits ist es auch keine große Mehrarbeit, die Prozeduren im Projekt zu schreiben, sich über den Namen einer Komponente nen Pointer auf die Komponente zu holen (die Möglichkeit dazu stellt die Managerklasse zur Verfügung) und den Callback "von Hand" zuzuweisen.
Allerdings wäre es schön für einfache Dinge, wie Animationen beim MouseOver oder so, Scripte in der .xml zu "hinterlassen". Wenn es dazu kommen sollte, werd ich mich dafür allerdings bei ner vorhandenen Scriptsprache bedienen - wo genau weiß ich noch nicht.

Ich bin auch einigermaßen geneigt, die GUI, wenn sie verwendbare Formen angenommen hat, sozusagen als "Subprojekt" zu veröffentlichen - mal sehen, was draus wird ;)

So, sry für die Wall of Text, jetzt gehts ins Bett für mich :D


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: SketchtowerWars
BeitragVerfasst: Di Sep 07, 2010 15:06 
Offline
DGL Member

Registriert: Mo Aug 31, 2009 13:19
Beiträge: 151
So - nachdem die GUI-Entwicklung einigermaßen so weit ist, dass ich mit der GUI was anfangen kann und nur noch die Kontrollelemente implementieren muss, die ich brauche, bin ich dran gegangen, festzustellen, welche Elemente ich denn brauche. Und laut dem Artikel im Wiki zum Thema GUI gibts zu dem Zweck nichts Besseres, als erstmal einfach am Projekt weiterzutüfteln und zu schauen, was dabei so nötig wird.
Codemäßig hat sich jetzt noch nicht so viel getan, aber es steht schon eine Skizze für das Hauptmenü :lol:
Nein, im Ernst - es existiert ein Flussdiagramm dazu, wie das Map-Objekt aufgebaut sein soll und neben der Skizze für das Hauptmenü (die nicht spektakulär, und darum auch nicht veröffentlichungswert ist) auch neue Entwürfe für die Creeps.
Beides häng ich hier mal an. Zu den Creeps ist noch zu sagen, dass das wirklich nur Entwürfe sind - um dem "gezeichneten" Stil treu zu bleiben, werde ich die als "Schablonen" im GIMP benutzen und mit dem Grafiktablett die Geschichte freihändig nachzeichnen.

P.S.: Wer als erster im Meinungsthread alle fünf Creeptypen errät kriegt nen virtuellen Keks von mir ;)


Dateianhänge:
Dateikommentar: Die Creepentwürfe
Sketchtowerwars - Creeps.jpg [34.81 KiB]
Noch nie heruntergeladen
Dateikommentar: (grobes) Flussdiagramm zum Aufbau des Map-Objekts
Sketchtowerwars - Map.jpg [54.71 KiB]
Noch nie heruntergeladen
Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 5 Beiträge ] 
Foren-Übersicht » Sonstiges » Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 26 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.163s | 18 Queries | GZIP : On ]