Cube-Wars 2010

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

Worklogs Cube-Wars 2010

Neuer Debugger

Donnerstag, 25. Februar 2010 von Kernle 32DLL
Ich habe mir mal die alte Debug-Funktion der alten Engine Basis vorgeknöpft und sie auf das neue System angepasst. Das Ganze hat eigentlich nur kosmetische Zwecke.

BlitzMax: [AUSKLAPPEN]
(INFO) 16:24:05 - ClassDebug: TestLanguage(TLanguage) 8byte (40byte)
(INFO) 16:24:05 - ClassDebug: Hooked Instances: 2
(INFO) 16:24:05 - ClassDebug: #HELLOWORLD(TTranslation)
(INFO) 16:24:05 - ClassDebug: #PLAYERSAYSHELLOWORLD(TTranslation)
(INFO) 16:24:05 - ClassDebug: Hooked By Instances: 0
(INFO) 16:24:05 - ClassDebug:
(INFO) 16:24:05 - ClassDebug: HookList:TList = 0023FF20
(INFO) 16:24:05 - ClassDebug: HookedByList:TList = 00242530
(INFO) 16:24:05 - ClassDebug: Source:Object = Null
(INFO) 16:24:05 - ClassDebug: Name:String = "TestLanguage"
(INFO) 16:24:05 - ClassDebug: TranslationMap:TMap = 00242540
(INFO) 16:24:05 - ClassDebug: Version:String = "1.0.0"
(INFO) 16:24:05 - ClassDebug: Author:String = "Kernle 32DLL"
(INFO) 16:24:05 - ClassDebug: ReleaseDate:String = "TBA"
(INFO) 16:24:05 - ClassDebug:
(INFO) 16:24:05 - ClassDebug: #HELLOWORLD(TTranslation) 8byte (41byte)
(INFO) 16:24:05 - ClassDebug: Hooked Instances: 0
(INFO) 16:24:05 - ClassDebug: Hooked By Instances: 2
(INFO) 16:24:05 - ClassDebug: TestLanguage(TLanguage)
(INFO) 16:24:05 - ClassDebug: #PLAYERSAYSHELLOWORLD(TTranslation)
(INFO) 16:24:05 - ClassDebug:
(INFO) 16:24:05 - ClassDebug: HookList:TList = 00242550
(INFO) 16:24:05 - ClassDebug: HookedByList:TList = 00242560
(INFO) 16:24:05 - ClassDebug: Source:Object = Null
(INFO) 16:24:05 - ClassDebug: Name:String = "#HELLOWORLD"
(INFO) 16:24:05 - ClassDebug: TranslationSlices:Object[] = 00241540
(INFO) 16:24:05 - ClassDebug: ChangedSlices:Byte = 0
(INFO) 16:24:05 - ClassDebug: CachedValueMap:TMap = 00242570
(INFO) 16:24:05 - ClassDebug: Content:String = ""
(INFO) 16:24:05 - ClassDebug: Language:TLanguage = TestLanguage
(INFO) 16:24:05 - ClassDebug:
(INFO) 16:24:05 - ClassDebug: #PLAYERSAYSHELLOWORLD(TTranslation) 8byte (41byte)
(INFO) 16:24:05 - ClassDebug: Hooked Instances: 1
(INFO) 16:24:05 - ClassDebug: #HELLOWORLD(TTranslation)
(INFO) 16:24:05 - ClassDebug: Hooked By Instances: 1
(INFO) 16:24:05 - ClassDebug: TestLanguage(TLanguage)
(INFO) 16:24:05 - ClassDebug:
(INFO) 16:24:05 - ClassDebug: HookList:TList = 00242580
(INFO) 16:24:05 - ClassDebug: HookedByList:TList = 00242590
(INFO) 16:24:05 - ClassDebug: Source:Object = Null
(INFO) 16:24:05 - ClassDebug: Name:String = "#PLAYERSAYSHELLOWORLD"
(INFO) 16:24:05 - ClassDebug: TranslationSlices:Object[] = 0023F5E0
(INFO) 16:24:05 - ClassDebug: ChangedSlices:Byte = 0
(INFO) 16:24:05 - ClassDebug: CachedValueMap:TMap = 002425A0
(INFO) 16:24:05 - ClassDebug: Content:String = ""
(INFO) 16:24:05 - ClassDebug: Language:TLanguage = TestLanguage
(INFO) 16:24:05 - ClassDebug:

Was vermutlich auffält sind die ersten zeilen der jeweilig ge "debuggten" Instanzen:

TestLanguage(TLanguage) 8byte (40byte)
[ToString]([KlassenName]) [KlassenGröße]byte ([FeldInhaltsGröße]byte)

Alle Klassen meiner Engine sind darauf ausgelegt eine ToString Implementierung zu haben. Das hilft insofern, das man beim Debuggen nicht auf irgendwelche Speicheradressen, sondern (sofern richtig angewendet) den Namen oder ein sonstiges Merkmal der Instanz trifft. Das OBS System benutzt zudem die ToString Methode ebenfalls, was deutlich bei der Fehlersuche hilft.

Alle TGameData Instanzen haben eine Name Feld, das standardmäßig mit ToString ausgegeben wird, daher münden die Namen.

Den Namen der Worklog habe ich in Folge dessen das ich nunmehr vermehrt an der Engine gearbeitet Temporär geändert. Sobald ich wieder mit dem eigentlichen Spiel anfange, benenne ich sie wieder um.

Edit:
Debuglog zu BMax Syntax Box geändert, weil Quotes keine Tabs können, und Einträge noch ein wenig verändert.

Translations Runde 2.

Dienstag, 23. Februar 2010 von Kernle 32DLL
Heute will ich euch einen kleinen Enblick in das neue Translations System geben, und wie man es nutzt. Schauen wir uns folgenden Code an, und schauen was er tut:

BlitzMax: [AUSKLAPPEN]
Local TestLanguage:TLanguage = TLanguage.Create("TestLanguage")
Local hello:TTranslation = TestLanguage.CreateTranslation("#HELLOWORLD",["Hello World"])

Local saying:TTranslation = TestLanguage.CreateTranslation("#PLAYERSAYSHELLOWORLD",[""," says ","#HELLOWORLD","!"])
saying.RegisterCachedValue("PlayerName",0)
saying.ModifyCachedValue("PlayerName","Kernle 32DLL")

TestLanguage.BuildAllTranslations()

Print TestLanguage.TranslateCode("#PLAYERSAYSHELLOWORLD")

hello.ModifySlice(0,"Kaese")
Print saying.GetContent()


Zitat:
(INFO) TLanguage.BuildAllTranslations: Started rebuild of all translations
(INFO) TTranslation.BuildContent: Building content string for #HELLOWORLD
(INFO) TTranslation.BuildContent: Building content string for #PLAYERSAYSHELLOWORLD
(INFO) TLanguage.BuildAllTranslations: finished rebuild of all translations
Kernle 32DLL says Hello World!
(INFO) TTranslation.BuildContent: Building content string for #PLAYERSAYSHELLOWORLD
(INFO) TTranslation.BuildContent: Building content string for #HELLOWORLD
Kernle 32DLL says Kaese!


CreateLanguage("TestLanguage")
Erstellt eine neue Sprache (TestLanguage), die dann mit Translations gefüllt werden kann.

TestLanguage.CreateTranslation("#HELLOWORLD",["Hello World"])
Erstellt eine neue Translation in der Spracheklasse TestLanguage. Der "Code" (sowas wie der Name) ist "#HELLOWORLD" (das # ist nicht zwingend, hilft aber später Probleme vorzubeugen). Die Translation besteht aus einem Slice, und zwar einem String Objekt mit dem Inhalt "Hello World".

TestLanguage.CreateTranslation("#PLAYERSAYSHELLOWORLD",[Null," says ","#HELLOWORLD","!"])
Noch eine weitere Translation, aber diesmal besteht sie aus mehreren Slices. Einem Null-Objekt das als Platzhalter dient (dazu komme ich gleich), einem normalen String Objekt, einer Integrierten Translation in String Form, und einem weiteren String Objekt.

Das Null Objekt hat den Sinn, dass es später für CachedValues her hält. Man könnte dem Slice auch jetzt schon einen quasi "Startwert" geben (d.h. ein Objekt), aber darauf habe ich verzichtet um dieses Prinzip hier darstellen zu können.

"#HELLOWORLD" ist im Prinzip einfach nur ein String Objekt. Damit die Translation daraus eine Integrierte Translation kreiert (d.h. aus dem String Objekt eine Referenz auf die eigentliche Translation erstellt) muss die Sprachinstanz noch den Befehl ResolveTranslations() ausführen. Ich habe darauf verzichtet, da der später erläuterte Befehl BuildAllTranslations() diesen bereits selber ausführt.

Statt dem String Objekt hätte man natürlich auch die zu integrierende Translation direkt übergeben können:
TestLanguage.CreateTranslation("#PLAYERSAYSHELLOWORLD",[Null," says ",hello,"!"])

saying.RegisterCachedValue("PlayerName",0)
Registriert in einer der erstellten Translation (in der Variable saying zwischengespeichert) eine sog. CachedValue. Es sei anzumerken das CachedValues die weiterentwickelte Form von CachedVars sind. CachedValues zeigen auf einen Slice der Translation (hier, Slice 0, da die Translation nur aus einem Slice besteht), und sollen das Ändern der Translation in Echtzeit vereinfachen. Denn während sich die Anzahl von Slices bzw. Reihenfolge von Slices von Language zu Language unterscheiden kann, sind CachedValues immer "statisch", d.h. sie zeigen immer auf einen bestimmten Teil der Translation.

Beispiel: "Noch 12 Minuten übrig"

Deutsch:
Slices: "Noch " , "12" , " Minuten übrig"
CachedValue: RegisterCachedValue("Time",1)

Englisch:
Slices: "12" , " minuts left"
CachedValue: RegisterCachedValue("Time",0)

Sofern die CachedValues richtig definiert sind, kann man nun über die CachedValue "Time" in beiden Sprachen die Zeit ändern, ohne mit den Slices selber hantieren zu müssen.

saying.ModifyCachedValue("PlayerName","Kernle 32DLL")
Modifiziert den Inhalt (nicht ganz richtig, eher den Slice auf den die CachedValue verweist) der CachedValue "PlayerName" zu einem neuen String Objekt.

TestLanguage.BuildAllTranslations()
Der Kernpunkt der Sprache. Der Befehl veranlasst alle Translation dazu sich neu zu "bauen", d.h. ihren Inhalt aus den Slices voraus zu berechnen. Im Prinzip ist dieser Befehl nicht notwendig, da Translations sich bei Bedarf auch selber neu berechnen. Allerdings ist es sauberer alle Translations auf einen Schlag im Voraus zu berechnen, damit im späteren Programm keine Ruckler durch die Neuberechnung im Programmablauf auftauchen. Achtung: Der in dem Befehl integrierte Befehl ResolveTranslations() ist allerdings SEHR wichtig! Ohne diesen Befehl funktionieren Integrierte Translations nicht, es sei denn sie werden direkt explizit als Objekt übergeben!

Print TestLanguage.TranslateCode("#PLAYERSAYSHELLOWORLD")
Ein wrapper, der genau das gleiche wie der letzte Befehl tut (wrappt den Befehl GetContent())

hello.ModifySlice(0,"Kaese")
Verändert einen Slice direkt. Wie man der Ausgabe entnehmen kann, wird die Translation damit auch veranlasst sich beim nächsten Aufruf von GetContent() neu zu berechnen. Man hätte dies auch jetzt schon machen könnten, indem man als 3. Parameter noch eine 1 übergeben hätte (1 = Neuberechnung bei Bedarf / 2 = Neuberechnung erzwingen). Dabei ist zu beachten das bei einer Neuberechnung auch alle Translations neu berechnet werden müssen die diese Translation als Integrierte Translation nutzen (hier also "#PLAYERSAYSHELLOWORLD"). Dies sieht man auch gut an der obigen Ausgabe: Nach der Neuberechnung alle Translations tauchen nochmal zwei weitere "rebuilds" auf.

Print saying.GetContent()
Zeigt den Inhalt der Translation an. GetContent liefert dabei eigentlich nur den Vorberechneten Inhalt String, aber GetContent prüft auch ob eine Neuberechnung notwendig ist, und führt sie ggf. durch.



So, ich hoffe ich konnte euch einen kleinen, detailierten Einblick in mein neues Translations Konzept geben. Bisher funktioniert auch alles ziemlich gut. Ich überlege noch ob ich einen internen Konverter schreiben soll, um auch das alte Translations Format noch laden zu können. Theoretisch sollte es ja möglich sein.

Neue Konzepte

Montag, 22. Februar 2010 von Kernle 32DLL
Zwar ist die Entwicklung von Cube-Wars Offiziell gestoppt, aber das hindert mich nicht einige neue Konzepte und Ideen auszuprobieren. Im Folgenden gehe ich auf ein paar dieser ein, und erkläre was die Änderungen gegenüber dem alten Engine Gerüst sind.

Arrow TEngineBase (aka TEngine II)
TEngineBase ist die neue Grundklasse der Engine. Die Klasse wurde aufgeräumt, das OBS System genormt, und allgemein einiges performanter gelöst. Wichtigste Neuerung ist allerding der Wegfall der "Globalen Liste", die alle Instanzen enthielt. Für mein neues Konzept war diese Globale Liste schlicht Nutzlos, und in meinen Augen so oder so eine Grobe Verletzung des OOP Konzepts. Allgemein verzichtet, bzw. verbietet das neue Engine Konzept Eigenlisten. Werden Eigenlisten benötigt, müssen die Instanzen nun vom Programmierer selber gelistet werden (Oder es gibt Kapselungsklassen wie TLanguage)

user posted image

Status: Test Phase

Arrow TLanguage (aka TTranslation II)
TLanguage ist eine der angesprochenen Kapselklassen für das neue Enginekonzept. Da mein Translations System mit Eigenlisten steht und fällt, konnte ich sie nicht einfach rauswerden. Stattdessen übernimmt die TLanguage Klasse das jetzt, und kümmert sich gleichzeitig um die Minimierung von Translations Neuberechnungen (was nur bei Änderungen der Translation in Echtzeit passieren sollte, im alten Konzept aber bei jedem Aufruf der Translation passierte). Durch die TLanguage Klasse ist die TTranslationGroup Klasse obsolete und wurde entfernt. So oder so zeigte sich während der Entwicklung des Spiels nicht der erhoffte Effekt der Klasse.

Allgemein ist die TTranslation Klasse jetzt komplett neu aufgebaut. Anstatt andere Translations oder Variablen mühselig über Sonderzeichen einzufügen, besteht eine Translation jetzt aus sogenannten Translation Slices. Translation Slices sind im Prinzip nicht mehr als Teile eines Objekt-Arrays, aus dem TLanguage die eigentliche Übersetzung konstruiert. Damit wird vor allem der Bottleneck der ständigen Neuberechnung eliminiert, aber auch das System zum Modifizieren der Translation in Echtzeit wesentlich einfacher - das System ist jetzt nicht mehr auf eigenständige "CachedVariables" angewiesen, sondern funktioniert praktisch mit jeder Art von Objekt (sofern es eine ToString Implementierung hat).

user posted image
BlitzMax: [AUSKLAPPEN]
Local TestLanguage:TLanguage = TLanguage.Create("TestLanguage")
TestLanguage.CreateTranslation("#HELLOWORLD",["Hello World"])

Local saying:TTranslation = TestLanguage.CreateTranslation("#PLAYERSAYSHELLOWORLD",[""," says ","#HELLOWORLD","!"])
saying.RegisterCachedValue("PlayerName",0)
saying.ModifyCachedValue("PlayerName","Kernle 32DLL")

TestLanguage.BuildAllTranslations()

'Same effect
Print TestLanguage.TranslateCode("#PLAYERSAYSHELLOWORLD")
Print saying.GetContent()


Status: Test Phase

Arrow TGameData
Die GameData Klasse wurde ebenfalls dem neuen Konzept angepasst (Wegfall der Eigenliste), aber auch der Loader/Saver wurde optimiert. Der Speichervorgang geht nun wesentlich schneller, den optimierten Lademechanismus konnte ich noch nicht Testen da ich noch keine abspeicherbaren Objekte habe (TTranslation braucht noch ein wenig). Allgemein lässt sich aber sagen das es hier keine so großen Änderungen wie bei TTranslation gibt. Allgemein wird jetzt einfach alles ein wenig sauberer gelöst.

Status: Fertig (Loader ungetestet)

Arrow Debugger und TColor
Der Debugger wurde ebenfalls überarbeitet, und ist jetzt wesentlich Leichtgewichtiger und Übersichtlicher. Außerdem gibt es jetzt nur noch 2 Log-Typen, Info und Warning. Die Möglichkeit einen RTE durch einen Warning Eintrag auszulösen wurde entfernt. Ich spiele mit der Idee eine Throw/Catch Implementierung einzubauen, die dann wahlweise durch den Entwickler "gefangen" werden könnte.

Zitat:
(INFO) Debugger: DebugLog Activated // 22 Feb 2010 - 23:37:36
(INFO) EngineOBS: 024B0FE0(TTire) received test query no.2 from Car(TCar)
(INFO) EngineOBS: 024B23A0(TTire) received test query no.2 from Car(TCar)
(INFO) EngineOBS: 024B23D0(TTire) received test query no.2 from Car(TCar)
(INFO) EngineOBS: 024B2400(TTire) received test query no.2 from Car(TCar)
(INFO) GameSTDOUT: Instances before GC: 5
(INFO) GameSTDOUT: Instances after GC: 0
(INFO) Debugger: Debuglog Deactivated // 22 Feb 2010 - 23:38:07


TColor wurde genauso wie der Debugger entschlackt, und bietet jetzt die wichtigsten Funktionen direkt als Methoden an. U.A. Unterstützt die Klasse jetzt direkt einfache Hex und Integer Farbrechnungen. Außerdem macht sich das neue Engine Konzept hier sehr stark bemerkbar, da durch den Wegfall der Eigenliste Color Instanzen nicht mehr automatisch verteilt werden.

Status: Fertig?

Arrow TAnimationController
Die erste Klasse die auf das neue Konzept angepasst wurde. Die Hauptänderungen betreffen hauptsächlich Fehlerbehebungen und Performance Verbesserungen. So habe ich z.B. die Vorberechnung für den Prozentualen Abschluss der Animation entfernt (bzw. er wird jetzt bei Bedarf in Echtzeit berechnet), und konnte dadurch die FrameTiming Table endlich von Float zu Int umändern (das war mir von Anfang an ein Dorn im Auge).

user posted image

Status: Fertig

Arrow TImageData / TImageInstance
Neben der Anpassung an das neue TGameData Gerüst, wird TImageData wesentlich performanter im Hinblick auf das Laden, Speichern, und Zeichnen ausfallen. Dies wird dadurch erreicht das...

a) Ein eigener Lade- und Speicher Algorithmus benutzt wird der - sofern er funktioniert auch den Speicherverbrauch intern wie extern noch etwas drücken sollte
b) ImageData im Zusammenhang mit der neuen Grafikengine benutzt wird, und damit den "Max2D" Bottleneck umgeht

TImageInstance wird dabei besser auf TImageData abgestimmt, d.h. greift konkreter auf dessen Ressourcen zu (anstatt über viele Funktionen). Außerdem wird das Connector-System überarbeitet, um den Zeichenvorgang im Zusammenhang mit vielen Verbindungen performanter zu gestalten (OpenGL Spezifisches Konzept).

Status: Konzept


Soviel dazu für den Moment. Bis dann -
Kernle

Release der Kernle Engine I

Freitag, 12. Februar 2010 von Kernle 32DLL
Da ich die Entwicklung der sog. Kernle Engine beendet (man kann auch sagen aufgeben, wie man will) habe, veröffentliche ich sie nun hier. Mir ist durchaus bewusst das sie fast gar nicht dokumentiert ist, aber da ich mich nun schon relativ lange nicht mehr damit beschäftigt habe, kann ich das auch nicht mehr nachträglich erledigen. Immerhin, das Herzstück des ganzen, die Animation Controller Klasse, ist vollständig dokumentiert.

Die Engine kommt komplett vorkompiliert für Win32 (d.h. auch Debug und MT). Wenn ihr selber kompilieren wollt dann braucht ihr Axe's OGG Saver Modul, und die Desktop Extension von Chaos-Interactive.

Hier also die Downloads:
[ENGINE DOWNLOAD] (620kb / WinZip Archiv)
[CONTROLLER EXAMPLE DOWNLOAD] (383kb / WinZip Archiv)

Stop der Entwicklung

Montag, 8. Februar 2010 von Kernle 32DLL
Nach einiger Zeit ohne Einträge, melde ich mich hiermit zurück - leider mit keinen guten Nachrichten. Wie bereits im letzten Eintrag angesprochen wird Cube-Wars erst ein mal aufs Eis gelegt. Das hat folgende Gründe:

- Umfangreiches Praktikum ein Mai
- Persönliche Probleme
- Generelle Motivationslosigkeit

Wie in der überarbeiteten (leider nicht so stark wie es mir gewünscht hätte) Dokumentation nachzulesen ist, peile ich die nächste Release erst für Mitte bzw Ende 2010 an. Das liegt schlicht daran, dass ich frühstens Mitte 2010 wieder mit Cube-Wars weitermachen werde, und die geplanten Engine Änderungen nicht gerade maginal sind. Das Gute ist, dass ich durch meine Vorbereitung auf das Praktikum, bzw. auch im Praktikum selber, einiges an und über OpenGL lerne, was mir sicherlich auch in der nächsten "Phase" von Cube-Wars hilfreich sein wird.

Hier also die vorerst Finale Version des Funktionsprototypen für Cube-Wars:
[GAME DOWNLOAD] (ca. 10mb / WinRar Archiv)
[DOKU DOWNLOAD] (ca. 4mb / PDF Dokument)

So long,
Kernle

PS: Im Zuge dessen wird der Titel dieser Worklog - wieder ein mal - geändert.

Große und kleine Infos

Montag, 4. Januar 2010 von Kernle 32DLL
Wieder habe ich ein paar kleinere Verbesserungen an Cube-Wars vorgenommen. Allen vorran das neue Skalierungsmodell, was nicht nur einen kleinen Performanceschub bringt, sondern auch stufenloses Zoomen ermöglicht. Da man davon nicht viel sehen kann verzichte ich diesmal auf einen Screenshot.

Des weiteren habe ich mich daran versucht ein kleines Text-Precache-System zu schreiben, um Max2Ds lahme DrawText Funktion zu umgehen. Im prinzip funktioniert sie sogar schon, aber irgendwie arbeitet sie noch nicht so ganz mit Alpha-Fonts zusammen (es bilden sich schwarze Ränder), darum gibt es auch hier noch keinen Screenshot. Im allgemeinen lässt sich aber sagen das sich mit dem System (es stimmt ja nur etwas mit der Erstellung nicht) die Performance verdoppeln lässt. Somit bleiben die FPS immer im 1000er Bereich - ein echter Gewinn!

Da ich mitte diesen Jahres ein umfangreiches Praktikum in einer kleinen Spielefirma mache (wofür ich mich schon vorher einarbeiten muss), werde ich nicht mehr alt zuviel am Funktionsprototypen ausbessern, und dann das Projekt erstmal zu den Akten legen. Cube-Wars bekommt dann eine zwangspause von ca. 6 Monaten, in denen ich höchstens sporadisch daran arbeiten werde. Vielleicht nutze ich die Pause vom Programmieren und schreibe an der Story weiter - mal sehen.

Dementsprechend habe ich beschlossen das Soundmodul erstmal so zu lassen wie es ist. Ich bin zwar nicht so richtig zufrieden damit (okay, ich bin absolut UNZUFRIEDEN damit), aber mir fällt kein Lösungsansatz ein, ohne das komplette Soundsystem neu schreiben zu müssen (was zu viel Arbeit im Moment wäre). Ein vernünftiges Soundmodul kommt daher erst mit der in der Dokumentation beschriebenen Kernle Engine II.

Apropos Dokumentation, im Zuge der Speicherausbesserung im letzten Eintrag, sowie ein paar weiteren größeren und kleinere Ausbesserungen im Code, folgt mit der nächsten Version eine abermals überarbeitet Dokumentation. Die Überarbeitung betrifft vor allem TImageData, TImageInstance, und TTranslation. TGraphicalSet ist im Zuge der entwicklung aus der Engine geflogen, und macht Platz für weitere Ausschreibungen anderer Konzepte.

Hud-Update

Dienstag, 29. Dezember 2009 von Kernle 32DLL
Aufgrund des Feedbacks von verschiedenen Seiten habe ich mich daran gegeben das plumpe HUD etwas auszubessern. Der erste Schritt dazu war das ich ein paar essentielle Dinge als Quick-Info an den Mauscursor gehangen habe (Feldtype / Freund-,Feind-,Eigene- Einheit? / Besitzer?). Auch gibt es jetzt oben rechts eine kleine Spieleranzeige. Ganz zufrieden bin ich mit dem HUD aber immer noch nicht.

Des weiteren habe ich das murksige Speichermanagement bezüglich Bilddaten im Spiel korrigiert, und die Loader für Feld- und UnitElementChanges korrigiert.

user posted image

Im Moment arbeite ich intensiv daran das Soundmodul auszubessern, welches derzeit höchsten als schlechter TChannel Wrapper herhält. Ich plane das Soundmodul ähnlich wie Bilddaten in -Data und -Instance Klassenschichten zu unterteilen (Siehe Dokumentation). Mal schauen was daraus wird.

Ebenfalls experimentiere ich derzeit mit neuen Skalierungsmethoden, da die momentan angewandte Technik mir nicht richtig gefällt (es wird alles relativ zur Feldgröße berechnet). Das System erzwingt quasi das derzeit ALLES auf Feldgröße skaliert wird. Bei Einheiten macht das ja vielleicht noch Sinn, aber spätestens bei Sprites hört es dann doch auf.

Ein einfacher Lösungsansatz wäre, dass ich alles alles statisch zur Feldgröße gestaltet. D.h. eine Einheit mit 256x256 Pixel wird auf einem 128x128 Feld nicht skaliert, sondern wird wirklich so groß angezeigt wie sie ist. Im Hinblick auf die spätere 3D Umsetzung ist dies vielleicht tatsächlich sinnvoll. Darüber muss ich aber noch genauer nachdenken.

Zuguterletzt versuche ich derzeit ein kleines Performanceproblem von Max2D in den Griff zu bekommen. Wie man der Framerate des obrigen Screenshots entnehmen kann ist die Gesamtperformance etwas abgesoffen. Das liegt schlicht daran das ich ein "paar" DrawText Befehle mehr benutze als vorher. DrawText scheint übermäßig viel Leistung zu verbrauchen. Ich experimentiere daher momentan mit vorberechneten Textgrafiken, ähnlich einem Cache System. Ob das was ergibt, auch das wird die Zeit zeigen.


Insgesamt erwarte ich den ersten Patch Anfang bis Mitte Februar, da es doch einige Sachen gibt die ich erstmal in den Griff bekommen will. Dementsprechen verzögert sich auf die versprochene MacOSX Version.


Bis demnächst - Kernle

Kleines Update der Dokumentation

Freitag, 25. Dezember 2009 von Kernle 32DLL
Da hatten sich wohl noch ein paar Fehler in die Dokumentation eingeschlichen...
Die korrigierte Variante ist ab sofort hier downloadbar: [DOWNLOAD]

Fröhliche Weihnachten

Donnerstag, 24. Dezember 2009 von Kernle 32DLL
Fröhliche Weihnachten BBP!

Und endlich ist es soweit. Nach knapp 7 Monaten ist der Funktionsprototyp fertiggestellt. Und passend zur Bescherung bekommt ihr ihn auch endlich! Inklusive der 40 Seitigen Ausarbeitung.

Hier könnt ihr ihn ab sofort downloaden:
[DOWNLOAD] (10mb / WinRar Archiv)

user posted image

Für den Moment läuft das Spiel nur unter Windows, aber bis zum Ende des Jahres schiebe ich noch (vermutlich mit dem ersten Patch) eine MacOSX Version nach.

Ebenfalls fehlt dem Funktionsprototyp noch ein Programm um die config des Spiels zu editieren. Auch dieses programm schiebe ich sobald ich Zeit dafür habe nach. Im moment müsst ihr euch mit dem Batch Files bzw. den in der "TechnicalReadme" beschriebenen Kommandozeilen Parametern begnügen.

Jeder Art von Feedback ist erwünscht. Ob als Mail an die in der Readme beschriebenen Email Adresse, als PN oder als Kommentar in dieser Worklog.

Eine fröhliche Weihnachtszeit und frohe Festtage!

So long,
Kernle

Letzte Handgriffe

Dienstag, 10. November 2009 von Kernle 32DLL
Auch wenn der Funktionsprototyp eigentlich fertig war, und schon für vor 3 Wochen angekündigt war, gab es noch zu viele unstimmigkeiten im Code als das ich das ganze so hätte releasen können.

Die meisten dieser Unstimmigkeiten sind nun korrigiert. Ein kurzer überblick:

Arrow Der Massive leistungseinbruch durch den Glow Effekt wurde endlich behoben (nochmal danke an Dee aka D2006)
Arrow Sämtliche Externen Daten wurden in das Containerformat CGD (zur Erinnerung: Cube-Wars GameData) implementiert. Das umfasst nicht nur die eigentlichen Spieldaten wie Elemente, Legierungen, etc. sondern auch die Bilddaten, Translations, und und und. (dazu weiter unten mehr)
Arrow Bilddaten werden durch das CGD Format jetzt komplett anders geladen und gespeichert (im endeffekt schneller)
Arrow "Grafik-Offensive" ... Wasser und Lava Feldtexturen wurden dank Holzchopfs Wassertextur Generator durch animierte Exemplare ersetzt.

user posted image user posted image
Anklicken für größere Variante

Der Sinn dieser Zusammenfassung aller Daten in ein Containerformat hat einen interessanten Effekt. Damit habe ich quasi auf einfachstem Wege ein einfaches Modsystem realisiert. Denn, jedes der im Containerformat speicherbaren Daten hat einen Weg um überschrieben zu werden. Was heißt das im Klartext? Ich könnte einer Mod sagen das sie zuerst alle Daten des Hauptspiels laden soll. Und die eigentliche Mod selber besteht dann nur aus einer (oder mehreren, wie man will) CGD Dateien, die gewünschte Daten überschreiben.

Ein weiteres Anwendungsgebiet ist Translations. So könnte man z.b. realisieren das eine Deutsche Übersetzung bestimmte vorher gerladene Bilder (z.b. Schilder in Englische Sprache) mit Deutschen Equivalenten ersetzt. Die Möglichkeiten sind vielseitig, und das ganze Potential ist noch nicht ausgeschöpft.

Meine To-Do Liste bis zur release des Funktionsprototyp ist indess sehr klein geworden. Bis auf einen Punkt ist die Arbeit am Code fertig, es muss also nurnoch am eigentlichen Inhalt gearbeitet werden.

Arrow Soundfiles in mein CGD Format implementieren
Arrow Weiteres Revising der Grafiken (ich bin immer noch nicht zufrieden). Das Betrifft: Cube-Basen, Felder und Sprites
Arrow Englische Übersetzung erstellen

Wenn alles glatt läuft, und davon gehe ich aus, steht alles für eine Release des Funktionsprototypen als 40. Eintrag in dieser Worklog. Ihr dürft gespannt bleiben.

So long,
Kernle

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