Endlich ist es mir gelungen meine TTranslation Klasse zu perfektionieren. Die Klasse kümmert sich um die Speicherung und Verwaltungen von Übersetzungen. Wie funktioniert das? Es werden sog. "Codes" (z.b. #GUI_SAYNO) definiert, die je nach geladener Spracheinstellung einen anderen Wert haben (hier z.b. Nein, No, usw.). Das hat den Vorteil das man im Code bzw falls gegeben in Scripts nur mit diesen Codes arbeitet, und den eigentlichen Inhalt extern definiert.

Aber die Klasse kann noch weit mehr. Zum einen gibt es das sogenannte TaT, kurz für TranslationsAtTranslations. Dahinter steckt die Fähigkeit Translations in anderen Translations wieder zu verwenden. Ein Beispiel dafür wäre z.b. "Wählen sie jetzt $#GUI_SAYYES$ oder $#GUI_SAYNO$". Daraus würde dann z.b. "Wählen sie jetzt Ja oder Nein". Die $s definieren hierbei wo die Namens- (bzw. Code-) definition anfängt und endet.

Die Konsequente Weiterentwicklung davon nennt sich CachedVar. ChachedVar erzeugt wie der Name vermuten lässt temporäre Variablen in einer Translation. Wie kann man sich das vorstellen? Wir wollen z.b. eine Translation für die Lebensanzeige einer Einheit. Da sich der Lebenswert aber ständig ändert, kommt eine TaT nicht in Frage. Und hier kommt CachedVar ins spiel. "Noch §HP§ Lebenspunkte üprig" würde so eine solche Translation mit CachedVar Nutzung heißen (§ markiert hierbei den Anfang und Ende des Variablen Namens). Die Translation erzeugt automatisch eine Variable "HP" die nur über die Translation (also lokal) erreichbar und veränderbar ist. Und als besonderes schmankel kann man auch einen Startwert vorgeben wenn man möchte: "Noch §HP=100§ Lebenspunkte üprig".

Natürlich ist es möglich ein "normales" % oder § per %% bzw. §§ wie man es vom ~~ in BMax gewohnt ist erzeugen. CachedVars könnten also auch z.b. Käse§Fuß (Käse§§Fuß als Translation) heißen.

Sobald ich die Zeit finde, werde ich das ganze System umschreiben (TEngine Abhängigkeit entfernen) und das ganze ins Codearchiv updaten. Kommentare zum System wären (sofern zu diesem Zeitpunkt möglich) toll.



Edit 17.08.09:
Mittlerweile habe ich auch den Lade- und Speicher- Mechanismus an TaT und CachedVars angepasst, und somit gleich mal versucht einen 2. Übersetzungsfile (Englisch) zu schreiben und ihn zu laden. Was auch funktioniert hat. Die Tage werde ich, sofern ich dazu Zeit finde, einen kleinen Editor für Translations schreiben. Aber das hat keine Eile, das kopieren eines vorhandenen Files und nachträgliches Übersetzen geht relativ einfach. Und es gibt noch genug andere zu tun. So arbeite ich z.b. gerade effektiv an TGraphics Object bzw dem darin inbegriffenen TImageObject und TModelObject. Lasst euch überraschen...

Und ja, ich weis das auf dem Bild "UpdateChachedVarValue" und "üprig" falsch geschrieben sind...

Ich bin zurück aus dem Urlaub... Ohne Ergebnisse

Ich habe zwar ein paar Zeilen geschrieben, aber es ist nichts nennenswertes dabei. Ein paar optimierungen hier, ein paar neue Sachen da. Im Prinzip fange ich jetzt mit dem Klassengerüst für das an was später mal die Einheit im Spiel präsentieren wird. Für Grafische Dinge und Scripting Zeugs habe ich im moment Platzhalter im Code, die ich zu gegebener Zeit ersetzen werde.

Baldmöglichst werde ich Programmierarbeiten wieder aufnehmen. Wie bald ich aber wieder was zu Berichten habe steht in den Sternen. Wie erwähnt werde ich mich jetzt erstmal um die eigentlichen Einheiten des Spiels kümmern. Danach kommen noch ein paar kleinigkeiten, und dann bin ich auch schon das eigentliche Kampfsystem von Cube-Wars an der Reihe.

Dank meiner Erfahrungen von den beiden letzten Anläufe (einmal Runden-, und einmal Echtzeitbasiertes Kampfsystem) sollte es diesmal recht zügig gehen, aber das werde ich noch früh genug sehen.

So, und jetzt noch schöne Restferien die sie noch haben.

Bis zum nächsten Eintrag 8)

Der ein oder andere wird es bereits gemerkt haben, mein angekündigter Eintrag zum Kampfsystem von Cube-Wars lässt auf sich warten. Das hat den simplen Grund das ich mir vorgenommen habe ersteinmal eine Art Prototypen für das Kampfsystem zu erstellen, bevor ich tiefer auf dessen Funktionsweise gehe.

Leider bin ich noch nicht soweit etwas antestbares rauszugeben. Ich bin immer noch in der Phase in der ich die Datentechnische Grundlage für das Spiel schreiben muss (D.h. Klassen, usw.). Doch sobald diese Phase abgeschlossen ist (ich rechne im idealfall mit 1 Monat), sollte es den ersten Funktions Prototypen zum selber antesten geben. Meine weitere Planung sieht vor mich danach um das Grafische Gerüst von Cube-Wars zu kümmern. Momentan tendiere ich stark zur Irrlicht Engine, aber das steht noch keineswegs fest.

Kopfzerbrechen bereitet mir momentan vor allem die implementation von 3D-Modellen ins Spiel. Ich hatte vor viele Grafische interessante Dinge und Spielereien zu integrieren (Animierte Texturen z.b.), aber ich weis nicht wie ich das mit dem Ladevorgang eines klassichen Models in einklang bringen kann. Animierte Texturen müsste ich z.b. aus dem Code herraus auf das Model auftragen, aber was ist wenn das Model bereits Texturen hat (Oder sogar mehrere)? Eure Meinung zu dem Thema wäre sehr hilfreich.

Ich schließe diesen Eintrag mit einem Bild aus der Entwicklungsumgebung ab.



Die Debuglog zeigt (auch wenn man das so nicht sieht), zum einen dass das Translations System funktioniert (die Ausgabe besteht nur aus TranslateCode() ), zum anderen das Element, Typ und Legierung schon vollständig integriert sind. Der Bunte Kreis des eigentlichen Fensters stellt den Bewegungsradius eines bestimmten (noch unbenannten) Typs da. Rot = Angriff / Grün = Bewegen / Gelb (nicht im Bild) = Angriff & Bewegen

Bis zum nächsten Eintrag

Meinen heutigen Beitrag möchte ich mit der Vorstellung eines weiteren Charakters aus Cube-Wars eröffnen. Sein Name ist "Prof. Dr. Albrecht Braun", und ist einer der Schlüsselfiguren des (übrigens nur begrenzt spielbaren) Prologs von Cube-Wars. Er legt quasi den Grundstein für die gesamte Story.

Weitere Charakter sind zwar bereits skizziert, aber es soll ja noch was von der späteren Story übrig bleiben, also dazu später mehr

Stattdessen schreibe ich über das komplett Grunderneuerte Kampfsystem zu Cube-Wars. Das alte Echtzeit-Kampfsystem ist in Rente geschickt worden, und durch ein neues, äußerst Taktisches System ersetzt worden.



Nach reichlicher Überlegung ist uns aufgefallen das die Cubes, das Herzstück des Spiels, eigentlich völlig langweilig und uninteressant inszeniert sind (Einfach nur Würfel mit einem Typ, sowie einem Angriffswert und Lebenspunkten). Darum haben wir ein System implementiert, das etwas an das besonders von jüngeren Lesern allseits bekannte "Beyblade" erinnern dürfte: Stacking

Cubes werden aus 6 Einzelteilen zusammengesetzt, die die Gesamt-Kampftauglichkeit maßgeblich verändern. Die Einzelteile sind:

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

Kern:

Der Kern definiert den Typ des Cubes. Der Kern gibt Aufschluss darüber, wie die Bewegungs- und Angriffsradien eines Cubes sind. Ein Schütze hat einen recht kleinen Angriffsradius, dafür aber den größten Bewegungsradius, ist also sehr mobil. Der Artillerie Typ ist das genaue Gegenteil. Große Angriffsreichweite (KEIN Nahkampf!), aber dafür winziger Bewegungsradius.

Hinweis: Die Bezeichnungen der Typen sind nur Temporär

Kernhülle:

Definiert das Element des Cubes, und damit seine Generellen Stärken und Schwächen gegen andere Cubes. Stärken und Schwächen werden Prozentual von der Gesamtangriffskraft addiert bzw. subtrahiert. D.h. ein Wassercube erhält z.b. 50% Bonus auf seine Angriffskraft wenn er einen Feuercube angreift (nur ein Beispiel, balancing steht noch nicht fest). Ebenfalls beeinflusst der Typ das Verhalten des Cubes auf den verschiedenen Feldern (ein Feuercube nimmt z.b. im Gegensatz zu allen anderen Typen keinen Schaden auf einem Lava Feld).

Körper-Basis:

Die Körper- Basis bestimmt die Grundmenge an Lebenspunkten des Cubes. Die Körper- Basis ist ein typisches Beispiel für "Zahl mehr, bekomme mehr". Außer der Grundmenge der Lebenspunkte bringt die Körper- Basis keine weiteren Veränderungen mit sich. Eine bessere Basis heißt also schlicht mehr Lebenspunkte.

Kanten:

Kanten bestimmen die Grundmenge an Angriffspunkten des Cubes. Auch wenn das bisherige Konzept nur von "Kanten" spricht, ist es durchaus nicht nur darauf beschränkt. Die Kanten sind der einzige noch wacklige Punkt des Konzepts. Möglicherweise läuft es aber auf eine ähnliche Ausarbeitung wie bei der Körper-Basis hinaus.

Legierung:

Legierungen bilden die Ergänzung zu den Cube-Elementen, gelten aber entgegen der Elemente nur für den Cube der Angegriffen wird. Legierungen machen den Cube entgegen bestimmter Typen Resistenter (d.h. der eigene Angriffswert wird bei einem Angriff prozentual, sagen wir um 25% erhöht), macht ihn aber ebenso gegenüber anderen Typen verwundbarer.

Slots:

Jeder Cube besitzt 3 Slots, die er mit speziellen Fertigkeiten bzw. Boni laden kann. Das Konzept für die Fertigkeiten ist noch nicht ausgereift, aber einer der Boni ist z.b. eine Prozentuale Angriffssteigerung gegen alle Typen um 15%. Diese Fertigkeiten und Boni werden als einziger Teil der Cubes im Spiel nicht kaufbar sein, d.h. müssen gefunden werden.

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

Soooo, das war es für den heutigen Worklog Eintrag. Morgen werde ich noch mit dem neuen Kampfsystem ins Detail gehen, und genau erklären wie die neuen Kämpfe in Cube-Wars ablaufen. Bis dahin..

So long,
Kernle

Hiermit löse ich mein Versprechen des letzten Worklog Eintrags ein, und führe die Arbeiten an Cube-Wars fort. Es gibt auch durchaus ein paar neue Dinge zu berichten.

Momentan "modernisiere" ich meinen Code mithilfe einer von mir entwickelten Klasse namens "TEngine" (der ein oder andere wird sich erinner, ich habe dazu in letzter Zeit viel im Forum gefragt). Was ist der Sinn hinter TEngine?

TEngine liefert eine Basisklasse mit einen Haufen von nützlichen Funktionen, Methoden und Feldern, sowie eine vom Oberserver-Konzept inspiriertes Konzept zur Klassenkommunikation.

Besonders über dieses, ich habe es momemtan OBS-System (Observe) genannt, möchte ich jetzt hier etwas schreiben. Der Grundgedanke dahinter ist folgender: Stellen wir uns eine Objektinstanz einer Einheit vor. Diese Einheit hat Objektverweise auf einen EinheitenTyp, einen Spieler, eine Farbe, etc...

Und was passiert nun wenn z.b. einfach der Spieler gelöscht wird (z.b. durch einen Programmierfehler)? Es gibt einen Memoryfehler der je nach komplexität des programmierten kaum nach zu verfolgen ist. Darum habe ich mein OBS System entwickelt. Wird der Spieler (vorrausgesetzt richtig ins System integriert, dazu später mehr) nun gelöscht, meldet der Spieler das an die Einheit, was diese wiederrum mit einer treffenden Fehlermeldung quittiert.

Und da dieses System komplett in TEngine integriert ist, müssen die Klassen des Spiel nurnoch von TEngine abgeleitet werden, und dieser Funktionssatz steht allen Klassen zur verfügung. Doch wie wie sieht die Technische umsetzung jetzt genau aus? Hierzu Codeschnipsel der die Create-Funktion von TPlayerRelation zeigt:

Code: [AUSKLAPPEN] [EINKLAPPEN]

Das Herzstück ist hierbei die Methode OBS_HookObject(). OBS_HookObject() bewirkt folgendes (erklärt am Beispiel von Player1):

_Player1.OBS_HookObject(_PlayerRelation)

Die soeben erstellte Spielerrelation wird an den Spieler gekoppelt, d.h. der Spieler kann jetzt nicht mehr einfach gelöscht (kill) werden, da immer noch Objekte "ge-hooked" sind. Würde man es trotzsdem versuchen, würde Player1 eine "kill" message an alle ge-hookten" Objekte (u.a. also auch PlayerRelation) senden, was selbige wie bereits erwähnt mit einer Fehlermeldung quittieren würde.

Ein anderes Codebeispiel, diesmal die Create-Funktion von TPlayer

Code: [AUSKLAPPEN] [EINKLAPPEN]

Das Herzstück ist hier zweifelsohne _Color.OBS_HookObject(_Player). Ein Löschversuch von Color würde Player mit einer Fehlermeldung quittieren.

Insgesamt ist das OBS System so nun vollständig nutzbar, aber ich will noch ein paar Sachen ausfeilen die mir noch nicht optimal erscheinen. Mommentan werden unzulässige kills einfach mit einer Fehlermeldung quittiert. Aber es gibt auch Situationen bei denen soetwas unnötig ist, und man ggf. einen Programmabsturz abfangen kann. Dafür müsste die entsprechende Klasse einfach die Methode "OBS_ReactMessage()" neu definieren, was mir noch nicht so recht gefällt.

Kurz noch, neben dem OBS System gibt es bisher noch folgende nützliche Methoden: Debug() und ZeroMemory(). Debug() gibt alle Felder mit ihren Wertem im Stil des Debuggers von BMax in der Konsole aus, ZeroMemory() löscht alle Felder der Klasse (bzw. setzt die Verweise auf Null). Letzteres löscht auch die gesammte OBS-Liste des Objekts, ist also recht sinnvoll zum löschen des Objekts.

Bis zum nächsten Eintrag In diesem werde ich vermutlich detailierter auf die Story von Cube-Wars eingehen.

So long,
Kernle

Hallo, leider gibt es diesmal im Gegensatz zu den letzten Einträgen nichts gutes zu melden. Im Grunde ist Cube-Wars mit sofortiger Wirkung bis mitte des Monats auf Eis gelegt. Zu den details...

Kurzfristig hätte ich Cube-Wars eh auf Eis gelegt, da ich meine Ernergie auf den vor kurzem gestarteteten BCC 27 konzentrieren will. Der Grund warum Cube-Wars jetzt bis mitte des Monats, und vielleicht sogar bis Ende des Monats auf Eis liegt ist etwas schwer zu erklären. Was ich sagen kann ist, das es auf Private Probleme im Real Life zurückzuführen ist, die direkt mit Cube-Wars zu tun haben (ich rede hier nicht von Motivationsschwächen und dergleichen, sondern von ernsten Problemen).

Sobald sich etwas tut, werde ich es euch wissen lassen. Und denkt daran: Cube-Wars ist nur auf EIS, es ist nicht wie die vorherigen male "tot"! Das Projekt wird sobald es irgendwie möglich ist weiter geführt.

So long,
Kernle

Ich habe zwar noch immer nicht mit dem Einheitensystem angefangen, aber ich glaube das wird so bald auch nicht sein. Es gibt einfach noch zuviel vorher zu tun. Statdesse habe ich (wie vorher auch) am GameMod System weiter gewerkelt, und u.a. >endlich< funktionierende Routinen um, wie ich sie selber getauft habe, "Depth-Problems" und "Bi-Dependencies" zu finden.

Depth-Problems:
Ist eine Mod nicht ladbar, so sind alle Mods die von ihr abhängig sind (direkt und indirekt [z.b. über eine andere Mod]) auch nicht ladbar. Alle Mods die indirekt mit der Ursprungsmod verknüpft sind haben nun ein sog. Depth-Problem.

Während bei einer direkten Verknüpfung einfach ein Beziehungsproblem gemeldet wird, wird bei einer indirekten Verknüpfung jetzt korrekt ein Depth-Problem mit Verweis auf die verursachende Mod gegeben

Bi-Dependencies:
Im Grunde gilt der Begriff Bi-Dependencies übergreifend für ein generelles Problem das mit der implementierung der Mod-Beziehungen aufgetaucht ist: Kreisbeziehungen. Aufgrund der Art wie mein Code prüft ob eine Mod ladbar ist (es werden geprüft ob seine "Dependencies" auch ladbar sind), führt eine solche Kreisbeziehung zu einem MAV (oder wie man das auch immer bei BMax nennt ).

Ich musste wirklich lange daran tüfteln wie ich eine solche Kreisbeziehung finden konnte ohne selbst einen Absturz zu verursachen. Aber jetzt funktioniert die Routine richtig, und meldet ganz ohne Absturz einen Bi-Dependencie Fehler


Im Gleichem Abtemzug sollte ich eventuell erwähnen das ich mittlerweile ein kleines smartes Debug-System für Cube-Wars geschrieben habe. Man kann sich das ganze als eine massive Erweiterung des Debuglog Befehls vorstellen. Ein Beispiel für eine dadurch entstandene Deugliste findet ihr hier (ist schon etwas älter, mittlerweile habe ich die vielen Rechtschreibfehler *hust* korrigiert)


Aber auch an der Non-Coding Front hat sich was getan. Die ersten brauchbaren Konzeptzeichnungen (d.h. mehr als nur kritzeleien über spielideen) zu Cube-Wars sind fertig. Eine davon, die 3 Charaktere aus dem Spiel zeigt, möchte ich euch nun zeigen:


Anmerkung: Die Zeichnungen stammen nicht direkt von mir, sie wurden von jemand anders für Cube-Wars gezeichnet. Mein Zeichnerisches Talent ist... Begrenzt

Bis zum nächsten Eintrag

Statt endlich wie im letzten Beitrag beschrieben mit der Realisierung von Units under der gleichen beginnen zu können, habe ich mich die gesamte letzte Woche weiter mit meiner Mod-Grundlage rumgeschlagen.

Zuerst habe ich wie geplant die gesamte Prüfungsstruktur ausgelagert und überarbeitet. Parallel dazu habe ich hier und da noch ein paar kleinigkeiten geändert und verbessert. Als ich mich dann dem Laden der Mod zuwenden wollte, fiel mir auf das ich die "Dependencies" (=Beziehungen) zwischen den Mods völlig falsch implementiert habe.

Nachdem ein paar Nächte drauf gingen, hatte ich zwar eine vernünftige Struktur, aber eine nette Endlosschleife die ich beim besten Willen nicht umgehen konnte (Es ging um die Validätsprüfung einer Mod im zusammenhang mit ihrer Beziehungen). Nachdem ich dieses Wochenende ENDLICH auch dieses Problem aus der Welt schaffen konnte, funktioniert jetzt endlich alles wie es soll. Mods werden korrekt im Speicher erstellt, verwaltet und miteinander in Beziehung gesetzt.

Aber wofür dieser Beziehungskram eigentlich? Cube-Wars soll ja komplett Modbar sein, und daher braucht das Spiel auch eine solide und Funktionale Basis zum modden. Die Beziehungen spielen dabei die essentielle Rolle, zu garantieren das bestimmte Mods vorhanden sind damit die zu benutzende Mod auch korrekt funktioniert. Ein Beispiel dafür ist z.b. eine kleine Mod die nur ein paar Einheitentypen hinzufügt... Eine solche Mod würde natürlich nur funktionieren wenn das Hautspiel miteingebunden wird. Aber auch Mods für andere Mods sind so möglich.

Am liebsten würde ich jetzt endlich mit den Units anfangen, aber in meiner "Idle-Time" (Busfahrt, usw) habe ich weiter Ideen, Gedanken und Probleme aufs Papier gebannt. Und damit kam die Erkenntniss das ich erst noch ein paar andere Dinge fertigstellen muss, weil ich sonst mich nacher wieder im Kreis drehen muss um dies und das hinzuzufügen. Genaueres kann ich dazu auch noch nicht sagen, da das bisher auch erst alles mit kryptischen Bezeichnungen auf Papier steht Dies berücksichtigend ist der neue Termin für meinen Einheiten-Meilenstein jetzt für Ende Mai angesetzt. Das mündet daher das ich zum einen die neuen Teile erstmal programmieren muss, und diese dann auch erstmal auf Praxistauglichkeit prüfen muss. Denn wie ich am Modsystem selbst erlebt habe, was auf dem Papier gut ausschaut, muss nicht zwangsläufig auch in der Praxis so funktionieren.

So long,
Kernle

Es hat mich den ein oder anderen Nerv gekostet, aber die Grundlage für das Cube-Wars Modsystem ist gelegt. Es fehlt praktisch nurnoch eine Funktion namens "Load", die baue ich aber erst ein sobald die Strukturen für den eigentlichen Mod Content vorhanden sind (Units, Fields, Translations). So oder so würde die "Load" Funktion nur die Load Befehle für Units, usw. bündeln, d.h. das ist keine große Arbeit mehr.

Ich denke ich muss die Funktion "SetCurrentMod" (sie macht momentan u.a. auch die Prüfung auf ladbarkeit) nochmal neu schreiben, da das ganze etwas messy geworden ist. Mit den Return Werten bin ich auch noch nicht ganz zufrieden. Aber prinzipiell, "hey, es funktioniert!"

----

An der Unit / UnitType Front hat sich auch was getan. Ich habe mich jetzt endlich entschieden wie ich welche Daten speichere, und auf dem Papier ist die gesamte Datenstruktur zu Units, Fields und allem was dazu gehört bereits ziemlich fertig. Ich denke ich verfeinere das ganze noch etwas, und dann gebe ich mich an die Umsetzung.

Mein Aktuelles Ziel ist das Units-System (beinhaltet Fields) bis Ende nächster Woche fertig zu haben (abzüglich Grafiken-Laden). Dieses Wochenende habe ich leider zu viel zu tun um mich darum zu kümmern.

Das Units-System ist einer der Schlüsselelemente des Spiels, und mein quasi erster "richtiger" Meilenstein. Und da ich meine Worklog nicht sinnlos vollschreiben will, wird der nächste Worklog Eintrag erst folgen wenn das System funktioniert.

Also, bis dann

So long,
Kernle

PS: Korrektur zum obrigen Statement: Evt. schreibe ich die Tage mal einen kurzen Eintrag was eigentlich Units, Fields, usw. in Cube-Wars sind (Ist teilweise nicht umbedingt selbsterklärend)

Und wieder sind ein paar Tage rum, und ich habe nichts wirklich nennenswertes geschafft. Dennoch habe ich lust einen Eintrag zu schreiben und erkläre warum ich nicht weiter gekommen bin.

Das Problem liegt darin das ich momentan viel vorraus planen muss, damit ich nicht später immer wieder zurück gehen muss um Teile des Spiels neu zu schreiben. Dreh- und Angelpunkt des ganzen ist das Mod-System. Ich kann mich einfach nicht auf bestimmte Dinge festlegen, was aber nötig ist um ordentlich weiter programmieren zu können

z.b. soll die UnitBase (quasi eine Blaupause für Units) die Modelinformationen beinhalten, oder soll das komplett auf den UnitType ausgelagert werden? Dadurch würde ich Code und Speicher sparen, aber auch ein Stück Flexibilität.

Gleiches gilt für Felder und Feldtypen, also geht es auch da nicht weiter. So blieb mir die Tage in meiner Leerlaufzeit die ich sonst zum programmieren nutze nichts weiter üprig als weiter an meinen Version- und den Spielertypes zu feilen, und die dazugehörende Funktionssätze zu komplettieren... Zumindest etwas.



Ich hoffe dass ich bis zum Ende der Woche meine Gedanken sortiert habe, so das ich endlich weiterarbeiten kann.

So long,
Kernle