Cube-Wars 2010

Kommentare anzeigen Worklog abonnieren
Gehe zu Seite Zurück  1, 2, 3, 4, 5, 6, 7  Weiter

Worklogs Cube-Wars 2010

Dreidimensionale Spuren im Sand

Montag, 4. Oktober 2010 von Kernle 32DLL
Die letzten Wochen konnte ich mich Schulbedingt nur wenig um Cube-Wars kümmern. Der Pfadfindungs Algo muckt immer noch rum, und findet des Öfteren völlig unlogische, bzw. falsche Wege. Auch sonst hat sich spieltechnisch wenig getan, das meiste ist ja wie bereits erwähnt fertig.

Dafür habe ich mich sporadisch mit Irrlicht als 3D Engine für Cube-Wars auseinander gesetzt. Das Ganze war doch unerwartet schwer (gemessen an dem kleinen Endergebnis), und ich frage mich ob ich nicht nach einer Alternative suchen sollte. Vielleicht sollte ich auch mal den B3D-Like Befehlssatz von Irrlicht ausprobieren?

user posted image
Ein kleiner 3D Test, mit flachen Test Feldern (Debug Texturen)

Ich denke ich werde noch einige Zeit damit verbringen mich mit anderen Engines vertraut zu machen, um die optimale für Cube-Wars zu finden. Ich plane indes bis Ende des Jahres einen kleinen 3D Gameplay Test zu releasen. Ob ich den Termin halten kann hängt ganz davon ab wie schnell ich jetzt mit den 3D Sachen in die Hufen komme, aber ich bin doch recht zuversichtlich.

So long,
Kernle

Taking the next step

Donnerstag, 16. September 2010 von Kernle 32DLL
Diese Woche habe ich endlich mal wieder mehr an Cube-Wars gearbeitet. Zum einen habe ich mich, wie durch den letzten Eintrag angedeutet, ausgiebig mit den Felder Übergangen beschäftigt, und ich denke ich habe eine zufriedenstellende Lösung gefunden:

user posted image user posted image
6x6 Spielfeld, testweise in Milkshape 3D zusammen gesetzt

Des Weiteren habe ich auf dringenden Rat von mehreren Seiten die Elemente und deren Beziehungen untereinander überarbeitet. Diese sind nun wie folgt:

user posted image
Die 6 Elemente aus Cube-Wars, neu angeordnet

Funktional habe ich auch ein wenig gebastelt.

Arrow Neue Listener
Mittlerweile habe ich schon eine ganz beachtliche Menge an Listenern erstellt. Hier die aktuelle Liste:

Code: [AUSKLAPPEN]
=========================================================
 FIELD LISTENERS
=========================================================

TOnTouchListener
TOnStandingListener
TOnLeaveListener

--------------------

TOnCursorTouchListener
TOnCursorHoveringListener
TOnCursorLeaveListener

--------------------

TMoveUponCheckListener
TMoveAwayCheckListener

TSpawnUponCheckListener

--------------------

TOnMoveOrderedListener
TOnSpawnOrderedListener

=========================================================
 CUBE LISTENERS
=========================================================

TOnAttackListener
TOnAttackEndListener
--------------------

TOnBeingAttackedListener
TOnBeingAttackedEndListener

--------------------

TOnAttackOrderedListener

--------------------

TOnDamageListener
TOnDeathListener

=========================================================
 PLAYER LISTENERS
'=========================================================

TPlayerWinCondition


Einer der interessantesten Dinge die ich damit bisher realisiert habe, war ein Tor, das im 3 Sekunden Takt öffnet und schließt, und damit Cube Bewegungen erlaubt oder behindert.

Arrow Entfernung von TEquipment
Ich laufe meiner Entwicklung hat sich herausgestellt das es sinn frei ist diese Klasse zu behalten, da sie keinen Zweck mehr erfüllt. Cube Equipments sind jetzt Teil des Spielstands, und nicht des eigentlichen Kampfsystems. Stattdessen werden jetzt die benötigten Skripte beim Kampfstart in den Cube "kopiert".

Arrow Win & Loose Conditions
Erstmals in der Geschichte von Cube-Wars gibt es jetzt variable Siegesbedingungen, die über das bereits bekannte Skriptsystem realisiert werden (Gott, das wird eine Arbeit diesen ganzen Skriptkram auf Lua zu portieren).

Arrow Pausieren des Kampfes
Auch das ist eine Neuheit - Endlich lässt sich der aktuelle Kampf ohne großes rumgetrickse im Code (bis auf eine kleine Zeit Manipulation aller Skripte beim weiterlauf des Kampfes) pausieren. Genau wie beim Spielende, werden alle Skriptausführungen blockiert.

Arrow Pathfinding
Ich habe eine kleine A* Implementierung geschrieben, womit in Cube-Wars endlich erstmals semi-automatische Bewegungen möglich sind, statt die Cubes strikt an der Hand zu führen.

Arrow Spawnsystem
Das Spawnsystem funktioniert nun auch vollends. Besiegte Cubes werden in eine Liste gepackt, von der aus der Spieler sie dann einzeln auswählen und neu setzen kann. In Verbindung damit funktionieren jetzt auch endlich die sog. Spawnzones.


Auf meinem To-Do Zettel stehen im Moment nur noch folgende Dinge: Player2Player Logik, 3D Grafik, Code aufräumen und KI. Für letzteres muss ich mir noch was einfallen lassen, da ich noch nie mit KI Programmierung zu tun hatte. Vielleicht kennt ja jemand ein gutes Buch dazu?

Ich gehe davon aus das ich bis Ende des Monats eine Rudimentäre 3D Engine implementiert habe. Denn bis auf die Player2Player Logik, ist fürs Gameplay eigentlich alles da was man braucht (Minus komfortabler Bedienung)

Bis zum nächsten Eintrag,
Kernle

Von Feldern und Würfeln

Donnerstag, 2. September 2010 von Kernle 32DLL
Nach einer längeren Verzögerung, bedingt durch BCC und Urlaub, bin ich wieder bei Cube-Wars angelangt. Die Spielmechanik ist fürs erste fertig, so dass ich mich nun vollständig auf die Grafik konzentrieren kann, oder zumindest den Sprung in die dritte Dimension allgemein. Dabei eröffnet sich mir aber allen vorran ein Problem das ich im 2D Bereich noch nicht hatte: Wie gestalte ich die Übergänge zwischen den Feldern?

In meinem letzten etwas grafischer ausgelegten Test (siehe hier) habe ich das Problem gelöst indem ich einen "Button-Effekt" über die Felder gelegt habe. In der dritten Dimension funktioniert das nicht so gut. Erschwert wird das ganze noch dadurch, das ich damit spiele eine Tile-Engine in Cube-Wars einzubauen, so dass die Felder z.T. fließende Übergänge haben können. Hier mal ein paar Gedanken die ich mir gemacht habe:

Arrow Eigenständige Felder, die keine Referenz zu den Umgebenden Feldern nehmen, und deren Kanten immer auf der Höhe 0 enden

Arrow Integration einer Tile-Engine
Gedanken zur Realisierung sind vielzählig. Beispiele:

1. Laden von 3 Referenzmeshes, und generierung der benötigten Tiles in der Engine selbst (RPG-Maker Methode)
2. Vorgabe bestimmter Tile-Stücke zu Map bau (Keine Tile-Engine im eigentlichen Sinne, und nur sinnvoll für Manuell erstellte Maps)
3. Laden aller möglichen Tile Varianten (Viel zu hoher Modellieraufwand)

Arrow Eigenständige Felder, allerdings werden die Felder In-Game durch einen Rahmen (o.ä.) abgetrennt
Eventuell kann dieser Rahmen auch Halbtransparent sein.


Abgesehen von der Felder Frage gibt es auch bei den Cubes etwas neues zu verbuchen. Seit Anfang der Woche stehen auch endlich die Cube-Typen fest, die da wären:

user posted image

Die dazu gehörigen Felder stehen noch nicht ganz fest (Visuell wie namentlich), und auch andere, nicht Element Spezifische Felder sind noch ferne Gedanken.

Was denkt ihr? Hinterlasst eure Meinung doch als Kommentar.

So long,
Kernle

Befehlsqueue, Echtzeit, Spawnzonen und Spieler

Sonntag, 1. August 2010 von Kernle 32DLL
Und wieder bin ein paar Schritte weiter. Zum einen gibt es für jeden Cube jetzt einen funktionierenden Befehlsqueue, wie man dem unteren Screenshot entnehmen kann (der letzte gegebene Befehl ist unten). Das erlaubt rudimentäre Befehlsketten. Das System ist schon so weit das es unmöglich gewordene Befehle (z.B. den Angriff auf einen Cube, der sich in der Zeit bis zur Ausführung des Befehls bereits wegbewegt hat) automatisch löscht, und falls möglich mit dem nächsten Befehl weitermacht.

user posted image

Zum anderen gibt es jetzt endlich funktionierende Spawnzonen, einhergehend mit der Integration des dazugehörigen Systems. Im obigen Screenshot ist das zwar nicht zu sehen, aber die Meeres Felder sind der Spawnbereich des ersten Spielers, und die Feuerfelder die des zweiten Spielers. Natürlich sind mittlerweile die Cubes auch an Spieler gebunden.

Was ich im letzten Eintrag vergessen habe zu erwähnen ist, dass diese komischen Schwarzen Blöcke in der Mitte unpassierbare Felder sind (realisiert per Scripting). Auch wäre hier kein Spawning möglich (ebenfalls per Scripting). Ebenfalls vergessen habe ich zu erwähnen (auch wenn man es anhand der Skriptlog rechts vielleicht sich denken konnte), dass auf den Feuerfeldern ein Script läuft, das alle Cubes die nicht vom Typ Feuer sind, jede Sekunde um 100 CP verletzt. Und wo wir schon bei Skripten sind: Ich habe mal zum Testen ein Skript integriert, dass dafür sorgt das Cubes die auf Feldern ihres Elementes stehen (z.B. Wasser - Meer) jede Sekunde um 10 CP geheilt werden. Ob ich das ins letztendlich Spiel übernehme weiß ich noch nicht, den Taktischen Wert erhöht es auf jeden Fall.

Fast schon nebensächlich erscheint dabei zu erwähnen, dass dies alles erst dadurch möglich wurde das ich ein funktionierendes Echtzeitsystem integriert habe, was sich momentan noch als Zahl von 0 bis 100 unter den Cubes äußert, und später durch eine Zeitleiste wie man sie aus diversen Spielen kennt (z.B. diverse Final Fantasy Teile) ersetzt wird.

Das war‘s auch schon wieder. Ich denke ich werde jetzt erst mal den Code neu strukturieren, und dann vermutlich auch schon die ersten 3D Tests ausführen. Es ist beängstigend wie schnell diesmal alles geht, gemessen daran wie lange ich beim letzten Mal gebraucht habe.

So long,
Kernle

Introducing: TEqiupment

Donnerstag, 29. Juli 2010 von Kernle 32DLL
Und wieder gibt es eine neue Klasse zu bestaunen. TEqiupment. Die Klasse entstand in Anlehnung an das "Bauteile-System" von Cube-Wars 2009. TEqiupment beschreibt generell Ausrüstungsgegenstände, die einen Cube angehangen werden können (später baue ich da bestimmt ein Limit ein, aber für den Moment kann man so viele anhängen wie man will). Das System ist allerdings wesentlich simpler, und zugleich wesentlich vielfältiger als das letzte.

TEqiupment ist im Prinzip eine Sammelklasse für Skripte. Diese Skripte "simulieren" das Verhalten der Ausrüstungsgegenstände. Wie bereits angesprochen, lassen sich damit sehr simple Sachen realisieren (z.B. ein Ausrüstungsgegenstand der einfach Konstant die Kraftpunkte um 1000 erhöht), oder auch komplexere Sachen. Ein paar Dinge die ich bisher ausprobiert habe:

"Adaptiver Schild" (Defensiv)
Wird ein Cube angegriffen, werden seine Kraftpunkte temporär um 50% erhöht

"Seitentausch" (Offensiv)
Beim Angriff auf einen Cube werden nach der Schadensberechnung die Positionen der beiden Cubes vertauscht.

"Flucht" (Defensiv)
Wird ein Cube angegriffen, wird er nach der Schadensberechnung auf eine Zufällige Koordinate auf der Map teleportiert.

Abgesehen von der neuen TEquipment Klasse, musste ich ein paar kleine Modifikationen vornehmen. So haben Effekte jetzt neben ihrer normalen "run" Methode noch eine "kill" Methode, die aufgerufen wird, wenn der Effekt gelöscht werden soll. Das ist z.B. dann nützlich, wenn z.B. der Feld Bonus augenblicklich rückgängig gemacht werden soll (wichtig für Angriffe auf andere Cubes, wenn man von einem Feld angreift, dass dem eigenen Element entspricht). Ebenfalls wird diese neue Methode beim Element Bonus zwischen zwei Cubes wichtig, da der Effekt nach dem Angriff wieder sofort aufgehoben werden muss.

So long,
Kernle

Introducing: TCubeBonusEffect

Mittwoch, 28. Juli 2010 von Kernle 32DLL
TCubeBonusEffect ist die Basisklasse für Effekte die auf Cubes angewandt werden können. Das einfachste Beispiel eines solchen Effektes ist z.B. der Feldbonus wenn ein Cube auf einem Feld seines Elementes steht. Aber durch die Konzipierung der Klasse ist es auch möglich andere, komplexere Effekte damit zu realisieren, z.B. einen Heileffekt, der 4 Sekunden dauert, und jede Sekunde dabei 100 CP wiederherstellt.

Die Hauptattribute von TCubeBonusEffect:

TimeToFadeOff - Zeit in Millisekunden, wann der Effekt sich selbst vom Cube lösen soll (-1 = nie)
BonusAmount - Allgemeiner Hilfswert (z.B. um wie viel Prozent sollen die AP erhöht, oder CP regeneriert werden)

Da der TCubeBonusEffect von meiner Listener Klasse abgeleitet ist, hat er auch folgende Attribute:

ExecTimeIntervall - Zeitintervall, in der der Effekt ausgeführt wird (0 = bei jedem Frame)

-----------

Abgesehen davon geht die Entwicklung momentan angenehm zügig voran. Bis auf den Bonus den ein Cube beim angreifen eines ihm "nieder-elementareren" (z.B. Wasser -> Feuer) erhält, und einer Bindung der Cubes an einen Spieler, ist auch schon rudimentär alles drin was für das Spiel notwendig ist. Das umfasst:

- Kompletter Befehls Queue für Cubes
- Cubes bewegen und andere angreifen
- (Theoretisch) re-spawnen von zerstörten Cubes (es fehlt noch der Timer)
- Integration des kompletten Skriptsystems, bis auf die Skripte für Spielerbedingte Sachen

Wie im letzten Post angedeutet ist das alles noch sehr "Rau", und sobald ich sehe das alles korrekt funktioniert, programmiere ich das ganze nochmal "sauber" nach. Wenn ich das Tempo halten kann (Was, wie ich mich kenne leider sehr unwahrscheinlich ist), habe ich bis zum Ende der Woche einen kleinen Prototypen für das Kampfsystem fertig, den ich bei Interesse dann auch hochladen werde.

So long,
Kernle

Neues Konzept - Der Neustart

Dienstag, 27. Juli 2010 von Kernle 32DLL
Hallo erst mal. Lang lang ist es her seit dem letzten Beitrag. Einiges hat sich getan... und manches nicht. So ist Cube-Wars keinen Schritt weiter, bis auf einen kleinen HUD fix den ich kurz vor dem letzten NRW Treffen rein gehauen habe. Dafür habe ich über die letzten Monate eine wesentliche Erkenntnis gewonnen: Das Spiel ist zu komplex geworden. Nahezu niemand dem ich das Spiel präsentiert habe, hat das Spielprinzip auf Anhieb verstanden. Manche sogar gar nicht.

Für ein Spiel das eigentlich unkomplizierten schnellen Spielspaß vermitteln sollte, ist das natürlich ein sehr niederschlagendes Ergebnis. Nach einer umfassenden Analyse habe ich mich dazu entschieden das Konzept von Cube-Wars unter neuen Gesichtspunkten komplett neu zu Strukturieren, und dabei mehr zu den Wurzeln des Projektes zurück zu kehren. Dabei ist folgendes neues Konzept heraus gekommen.

Zitat:
Cubes bestehen nun nur noch aus einem Element (Feuer, Wasser, etc.), Kernpunkten (sowas wie Lebensenergie) und Kraftpunkten. Bei einem Kampf zwischen 2 Cubes errechnet sich der Kampfschaden am angegriffenen Cube durch die Differenz der Kampfkräfte (Hat der angegriffene Cube eine höhere Kampfkraft, schlägt der Angriff auf den Angreifenden Cube zurück, das nennt sich dann "Backfire").

Die Kampfkraft eines Cubes ist von folgenden Faktoren abhängig:

- Element des angegriffenen Cubes (Wasser Cubes erhöhen ihre Kampfkraft beim Angriff auf einen Feuer Cube)
- Element des Feldes auf dem der Cube steht (Meeres Felder erhöhen die Kampfkraft von Wasser Cubes)

Auch das Spielziel hat sich Grundliegend verändert. Jeder Spieler hat nun einen sog. Master-Cube, und beliebig viele Slave-Cubes. Zerstörte Slave-Cubes können nach einer gewissen Zeitspanne wieder auf dem Spielfeld platziert werden. Wird der Master-Cube zerstört ist der Spieler besiegt.


Wie man sieht ist das Konzept wesentlich kürzer diesmal. Nichts desto trotz wird das Spiel abwechslungsreich bleiben. Das liegt an der Tatsache das, inspiriert durch die "Listener" aus Android, ich ein kleines Skriptsystem (Aufbauend auf Listener Klassen) geschrieben habe. Das Ganze funktioniert bisher auch schon sehr gut, und bemerkenswert Fehlerfrei.

Vorstellen kann man sich das System wie folgt. Listener sind kleine Skripte, die durch ihre Basisklasse definiert sind wann sie ausgeführt werden sollen (siehe Liste unten). Praktisch das gesamte bisherige (Test) Gameplay ist durch solche Skripte realisiert. Vom Kampfsystem zu Element Boni bis zum Tod von Einheiten. Das Praktische an dem System ist das die Skripte (z.T. begrenzt) auf Funktionen und Methoden von übergebenen Objekten zurückgreifen können. So erhält der OnAttackListener z.B. den angreifenden und angegriffenen Cube als Parameter. Auch sehr wichtig ist das Skripte einen Einstellbaren Zeitrahmen haben, um ihre Ausführhäufigkeit zu limitieren. So kann z.B. ein Script erstellt werden, das sämtliche nicht-Feuer Einheiten auf einem Feld alle 2 Sekunden beschädigt (so in meinem Test integriert)

Eine Liste aller bisher integrierten Listener:

Zitat:
==========================
FIELD LISTENERS
==========================

OnTouchListener
OnStandingListener
OnLeaveListener
OnMoveOrderedListener (Maus Cursor über einen freien Feld, während ein Cube ausgewählt ist)
OnMoveFloatingListener

==========================
CUBE LISTENERS
==========================

OnAttackListener
OnAttackEndListener
OnBeingAttackedListener
OnBeingAttackedEndListener
OnAttackOrderedListener
OnAttackFloatingListener (Maus Cursor über einen Feindlichen Cube, während ein Cube ausgewählt ist)
OnDamageListener
OnDeathListener

==========================


Es ist noch ein weiter und steiniger Weg bis ich etwas richtig Spielbares habe, aber das Grundgerüst steht schon (auch wenn noch sehr dirty und inkonrekt). Zur Belustigung der Allgemeinheit hier einen Screenshot aus meinen Tests der letzten Tage. Rechts unten sieht man auch den Query der zuletzt ausgeführten Skripte.

user posted image
Edit: Auf anderen Webspace verschoben

So long,
Kernle

Shader rocken!

Donnerstag, 11. März 2010 von Kernle 32DLL
Vor ein paar Tagen ist ein Update für die Entwicklungstools für Android rausgekommen. Neben dem besseren Support für sog. Native-Code (in C vorkompilierter Code und dann in Java eingebunden) ist die für mich wesentliche Neuerung das Android jetzt, entsprechendes Gerät vorausgesetzt, auch Open GL ES 2.0 kann. Ein Grund mich endlich mal mit Shadern zu beschäftigen, mit dem Ergebniss das ich zu Lange die Wichtigkeit von Shadern unterschätzt habe. Ich weiß nicht wieso, aber Shader sind irgendwie an mir vorbei gegangen. Shocked

Das heißt Konkret dass ich jetzt anstrebe in meiner Engine einen (Rudimentären) Shader Support einzubauen. Ob das wirklich klappt hängt vor allem davon ab wie schnell ich meine Defizite in dem Thema aufholen kann, und wie Komplex das Thema allgemein wird. Was mich derzeit am meisten fasziniert ist Pixel-Lighting. Damit kann man viele tolle Sachen machen, unter anderem ist das auch die Basis für tolle Effekte wie Normalmapping. Ein ganz anderes Kaliber als Vertex-Lighting, wie es z.B. B3D benutzt.

Eine recht interessante Referenz für OpenGL Shader:
http://jerome.jouvie.free.fr/O...haders.php

So long,
Kernle

Auf in neue Gefilde

Samstag, 6. März 2010 von Kernle 32DLL
Nach langem (ca. 3 Monate) hin und her bin ich mir endlich einig wie ich den Grafikpart meiner Engine realisiere. Ich schreibe sie einfach mit Hilfe von OpenGL selber. Der naheliegest Grund ist der Lerneffekt, gekoppelt damit das BlitzMax mit dem Glew Modul in etwa die gleichen Befehle wie Android kann (Für Android programmiere ich im Praktikum), Ich also an beiden Fronten gleichzeitig etwas lerne. Der zweite Grund liegt am Aufbau der anderen Engines die in Frage kamen - MiniB3D und Irrlicht. Irrlicht war mir für meine Zwecke viel zu umfangreich (ich will doch nur ein paar Dreiecke zeichnen!), MiniB3D andererseits hatte keine passenden 2D Befehle (Rückfall auf Max2D).

Wie gesagt, ich schreibe die Engine nun kurzerhand selbst. Nachdem erst mal ein paar kleine Startschwierigkeiten überwunden wurden wollten ging es danach gut voran, und statt mich bei Hallo Welt aufzuhalten gibt’s direkt die ersten kolorierten Drei- und Vierecke zu sehen. Ich plane die Tage meinen Mesh Loader aus meinen bisherigen 3D-Tests für Android einzubauen, bzw. in mein GameData Format zu integrieren. Dann sehe ich auch erstmals wie performant meine Android Spielereien auf einem richtigen PC sind.

user posted image

Und so versucht Cube-Wars erneut den 3D-Sprung...

Translations Runde 3. // GameDataLoader 1.1

Mittwoch, 3. März 2010 von Kernle 32DLL
Endlich ist die TTranslation Klasse fertig. Seit dem letzten Eintrag hat sich einiges geändert. Zum einen ist die Kapselungsklasse TLanguage rausgeflogen. Es macht keinen Sinn mehrere Sprachen gleichzeitig im Speicher zu haben, und die durch die Klasse abgebildeten Metadaten lassen sich auch anderweitig einbinden.

Im Zuge dieser Entwicklung habe ich einen weiteren Punk meines Engine Konzepts hinzugefügt. Ableitungsklasse von TGameData (Translations, Images, Sound, etc.) dürfen Eigenlisten haben, um eine Übergreifende Bereitstellung der geladenen Daten zu gewährleisten. Parallel dazu habe ich das Translation-Resolving massiv eingeschränkt: Es wird nur beim verändern eines Slices (d.h. auch bei der Erstellung) geprüft ob eine neue Translation eingebettet werden muss. Manuelles resolving ist nicht mehr vorgesehen oder möglich. Der Grund dafür ist einfach der, das es unperformant ist ständig nach Translations zu suchen und ggf. diese einzubetten.

Auch neu ist der komplett überarbeitete GameDataLoader. Dieser speichert jetzt nicht nur doppelt(!) so schnell wie vorher, sondern auch wesentlich Platzsparender. Ersteres liegt an der neuen Schreibstruktur (kein Zwischenspeichern in einer Bank mehr), letzteres an der neuen Header-Struktur. Diese erlaubt jetzt mehrere Instanzen pro Header, was dadurch möglich ist, dass der Header (grob gesagt) nur den Namen des folgenden Datenblocks, sowie seine Größe angibt. Ein Größenvergleich einer extra dafür erstellten Datei (nähere dazu unten):

Alter Loader: 12,3 KB (12.653 bytes)
Neuer Loader: 5,82 KB (5.960 bytes)

Der neue Loader macht auch das schnelle Auslesen des Datei Inhaltes möglich, ohne dass konkret etwas geladen wird. Dazu gibt es jetzt die Funktion "FetchGameDataHeaders()":

BlitzMax: [AUSKLAPPEN]
(INFO) 17:25:43 - FetchGameDataHeaders: Fetched Data:
(INFO) 17:25:43 - FetchGameDataHeaders: ClassName: TTranslation
(INFO) 17:25:43 - FetchGameDataHeaders: StreamStart: 0
(INFO) 17:25:43 - FetchGameDataHeaders: HeaderVersion: 2
(INFO) 17:25:43 - FetchGameDataHeaders: HeaderSize: 54 Byte
(INFO) 17:25:43 - FetchGameDataHeaders: DataSize: 5064 Byte
(INFO) 17:25:43 - FetchGameDataHeaders: Instances: 107
(INFO) 17:25:43 - FetchGameDataHeaders: SaveDate: 03 Mar 2010 - 17:25:43
(INFO) 17:25:43 - FetchGameDataHeaders:
(INFO) 17:25:43 - FetchGameDataHeaders: ClassName: TTestData
(INFO) 17:25:43 - FetchGameDataHeaders: StreamStart: 5118
(INFO) 17:25:43 - FetchGameDataHeaders: HeaderVersion: 2
(INFO) 17:25:43 - FetchGameDataHeaders: HeaderSize: 51 Byte
(INFO) 17:25:43 - FetchGameDataHeaders: DataSize: 791 Byte
(INFO) 17:25:43 - FetchGameDataHeaders: Instances: 20
(INFO) 17:25:43 - FetchGameDataHeaders: SaveDate: 03 Mar 2010 - 17:25:43


Mir brennt es unter den Fingernägeln die GameData Klasse TImageData umzuschreiben. Leider macht das im Moment keinen Sinn, da ich mir erst genauere Gedanken zur Grafikengine machen muss, bevor ich zu viel Zeit in eine eventuell komplett Falsche Richtung investiere.

Mal schauen wo mich meine Entwicklung hinführt Wink

So long,
Kernle

Gehe zu Seite Zurück  1, 2, 3, 4, 5, 6, 7  Weiter