Cube-Wars 2010

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

Worklogs Cube-Wars 2010

TVersion

Samstag, 25. April 2009 von Kernle 32DLL
Seit dem letzten Beitrag bin ich mittlerweile etwas weiter gekommen. Cube-Wars soll ja komplett modbar werden. Also muss ich schon bei simplen Sachen direkt weiter denken wie ich sowas in ein Modsystem implementieren könnte.

Der erste Schritt dahin war eine Möglichkeit zu suchen um zu prüfen ob eine Mod noch mit der Aktuellen Spielversion kompatibel ist. Gesagt getan, TVersion und TVersionBundle waren geboren.

Was ist der Sinn dahinter:
TVersion unterhält eine Liste mit Einträgen, wobei jeder Eintrag für eine Version steht. Eine Version hat einen Namen, einen Status (Komaptibel / Inkompatibel / Unbekannt), und wahlweise einen Statustext (z.b. um zu erklären warum die Version nicht mehr kompatibel ist).

TVersionBundle ist schlicht nur eine Vereinfachung. Sie enthält einen kompletten Versions-Satz (Bundle eben), der so komplett prüfbar ist ob kompatibel oder nicht. So lassen sich z.b. Bundles pro Spielversion erstellen, und die Engine muss beim laden einer Mod nicht erst noch jede Version einzeln raussuchen, sondern kann schauen ob es nicht schon ein Bundle mit den gesuchten Versionen gibt.

Außerdem ist es komfortabler einen gazes Bundle zu prüfen ob es kompatibel ist oder nicht... Ein Befehl *gg*

Sobald ich die Sachen mit den Versionen fertig habe, schreibe ich die Ansätze meines Modsystems weiter. Denn erst dann kann ich mich wirklich um Einheiten, Felder und dergleichen kümmern.

user posted image
Wink

Von Beziehungen und Typen

Samstag, 18. April 2009 von Kernle 32DLL
Es geht vorran... Zwar nicht so zügig wie ich dachte, aber ich erweitere das was ich bisher geschrieben habe aber auch immer wieder um neue Funktionen (OOP 4tw).

Also bisher ist folgendes schon lauffähig:

- Spieler (inc. "Relations" untereinander die automatisch generiert werden)
- Cube-Typen (inc. eines Systems das definiert wie stark welcher Typ gegen welchen ist)
- Ein Rudimentärer Anfang der Feld-Typen

Des weiteren habe ich schon einen Haufen Kleinkram implementiert, u.a. z.b. auch ein (wenn bisher auch noch recht nutzlose) TColor Type Razz Erster Einsatzort dafür ist der Spieler.

Auch recht interessant ist das ich für alle bisherigen Dinge auch immer "Remove" Funktionen geschrieben habe. Das ist insofern wichtig, das mein System komplett auf Listen aufbaut. Ist ein Objekt, z.b. ein Spieler, nicht in einer solchen Liste ist er für mein System kein valider Spieler, egal was da komme. Und daher brauche ich die Remove Funktionen, da der GarbageCollector sonst nie aufräumt, da ja immer noch die Verweise in den Listen vorhanden sind.

Außerdem bin ich ein Fan des explizit zu löschen, und nicht nur freizugeben.

Also, bis denne. Ich bleib dran.

PS: Der aktuelle Anlauf heißt einfach simpel "Cube-Wars 2009", ergo heißt jetzt auch der Worklog anders...

Wir leben noch

Sonntag, 5. April 2009 von Kernle 32DLL
Hallo Leute,

uns (bzw mich o.O) gibt es immer noch. Und auch Cube-Wars. Nachdem mich das NRW-Treff dazu bewegt hat mich wieder aufs wesentliche zu konzentrieren und kein Megaprojekt zu erschaffen, geht Cube-Wars in die "was weis ich wie vielte" Runde.

Ich versuche mich diesmal an Bmax da ich seit meinen Programmierereien mit C++ OOP nicht mehr missen mag. Ich habe vor bis zum Ende der Osterferien hier in NRW ein paar Dinge zu realisieren.

Genaues kann ich dazu nicht sagen, da ich mich quasi auch erst in Bmax einarbeiten muss (was aber bisher erstuanlich gut lief). Ich halte euch auf dem laufenden.

So long,
Kernle

BCC#19 Pause

Sonntag, 14. September 2008 von Kernle 32DLL
Infolge meiner Teilnahme am BCC#19 sind die Arbeiten an Cube-Wars bis zum 27. eingestellt. Vielleicht mache ich zwichendurch ein paar kleine Sachen, aber meine Hauptkapazität stecke ich die nächsten Wochen in meinen BBC Beitrag.

So long,
Kernle

Und es wart eine MTex-Demo...

Samstag, 13. September 2008 von Kernle 32DLL
Da ich unerwartet schnell mit der normung des Codes, sowie mit der implementation des "Reverb" Animationsmodus fertig geworden bin, habe ich mir gedacht es wäre vielleicht interessant eine kleine "MultiTexture Demo" rauszubringen. Sozusagen um endlich bewegte Bilder zu liefern ^^

Ich muss mich nur dafür entschuldigen dass das Programm ewig lange zum starten braucht. Das Problem liegt daran, das ich die letzten beiden Texturen Programmintern erstelle - undzwar ziemlich langsam :/

Naja, ich hoffe trotsdem das ihr Spaß an der Demo findet... Wenn ihr lust habt könnt ihr mir ja auch mal eure "Rendertime" Werte per PN schicken. Ich habe mit deaktiviertem "VSync" und "RenderPictures" einen Rendertimewert von etwa 6ms... mit ab und zu spitzen um die 12ms (muss ich noch erörtern woher die kommen).

Genug geredet, hier der Download:
Cube-Wars MultiTextureTest 0.2
Edit 04.05.09: Link Replaced

So long,
Kernle

MultiTexturing - Animation Control

Samstag, 13. September 2008 von Kernle 32DLL
Nachdem ich gestern Abend mich wagemutig an die AnimationControl gab - und ziemlich müll gecodet habe, habe ich die AnimationControl heute neu geschrieben, und dabei das Animations Timing komplett überarbeitet. Es ist jetzt möglich jeder MultiTextur-Animation beliebig zu Stopen und dann weiterlaufen zu lassen. Der Stop wirkt dabei eher wie eine "Pause" Funktion. Eine Funktion um die Animation einfach wieder zurückzusetzen gibt es auch schon.

Zu guter letzt habe ich 3 AnimationsModi eingebaut, Loop, Once1 und Once2. Loop sollte selbsterklärend sein. Once1 und Once2 spielen die Animation jeweils einmal ab, und bleiben dann entweder beim letzten Frame (Once1) oder springen auf den ersten Frame zurück (Once2). In beiden Fällen wird nach Abschluss der Animation die Animation auf "Pause" gestellt.

Ich überlege noch einen 4. AnimationsModi einzubauen, nämlich "Reverb". Also das die Animation abwechselnd Vorwärts und Rückwärts läuft. Allerdings habe ich da ein paar kleine Probleme aufgrund meines simplen AnimationsTimings. Mal schauen was daraus wird.

Nachdem ich die AnimationControl soweit fertig und Bugfrei habe, werde ich wie im vorherigen Eintrag angedeutet erstmal den Funktionssatz kompletieren. Im moment muss man noch sehr oft auf die eigentlichen Variablen des MultiTexturing Type-Contaienrs zugreifen. Später soll man alle Relevanten Werte über Funktionen erhalten können - bzw. falls notwendig verändern können.

Außerdem habe ich das gefühl das ich meinen Code neu normen muss. Z.b. ein einheitlicher Fehler-Return der über Konstanten läuft. (z.b. ERRORCODE_MULTITEXTURE_DOESNOTEXIST).

Ich halte euch auf dem laufenden Very Happy

So long,
Kernle

MultiTexturing - Es läuft

Freitag, 12. September 2008 von Kernle 32DLL
Endlich - Das MultiTexturing funktioniert endlich ^^ Zwar funktionieren hier und da noch ein paar Funktionen, und der Code ist auch noch weder genormt noch optimiert, aber... ES LÄUFT xD

Also was kann mein MultiTexturing im moment:

- MultiTexturing Rolling Eyes
- HotSwap der MultiTexturen
- Animierte MultiTexturen
- Von der Framerate komplett unabhängige Animationen

Das ist noch geplant:
- AnimationControl (möglichkeit einzelne Animationen zu stoppen, etc.)
- Dot3 Mapping
(- evt. CubeMaps)
- Komplettierung des Funktionssatzes (so könnte man im moment damit nicht arbeiten Wink )
- Normung und Optimierung des Codes

Hier also ein paar Bilder:

user posted image
Einfaches MultiTexturing:
Plane: 1 Textur
Würfel: 2 Texturen

user posted image
Animiertes MultiTexturing:
Plane: 2 Texturen
Würfel: 2 Animierte Texturen

user posted image
Erweitertes MultiTexturing:
Plane: 2 Animierte Texturen
Würfel: 4 Animierte Texturen mit unterschiedlichen Geschwindigkeiten

Anmerkung zur letzten Textur:
TexturTeil 1 -> Cos / Sin/ Sehr schnell
TexturTeil 2 -> umgekehrter Cos / Sin / schnell
TexturTeil 3 -> XStarr / Sin / normal
TexturTeil 4 -> Cos / YStarr / langsam

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

Schönes Wochenende Razz

So long,
Kernle

Experiment #3

Sonntag, 7. September 2008 von Kernle 32DLL
Das Wochenende habe ich mich vermehrt mit verschiedenen Problemen meines MultiTexturing Funktionssatzes beschäftigt. Zum einen sah die Type-Definition bisher etwa so aus:

Code: [AUSKLAPPEN]
Type MultiTexture_Kind
   Field ID%,ID2%
   Field Texture[7],Image[7]
   Field TextureFrames[7]
   Field TextureCurFrame[7]
   Field TextureAnimSpeed[7]
   
   Field MeshBank%
End Type


Also ziemlich schlecht... Zum anderen blieb bis heute für mich die Frage ungeklärt, wie ich die MultiTextur wissen lasse auf welche Meshes sie angewandt wurde, und ob diese Meshes noch existieren. Das Problem ist, das ich schlecht einfach eine "MeshBank" führen kann, da dann bei einer löschung des Meshes zwar das 3D Objekt weg ist, die Variable in der Meshbank aber immer noch einen Wert hat (z.b. 28573248), und ich nicht rausfinden kann ob das Mesh jetzt noch "lebt" oder eben nicht :/ (B3D hat leider keine Funktion wie EntityExists(Entity) Sad )

Der Grund warum das so wichtig ist liegt klar auf der Hand: Animierte Texturen. Um Animierte Texturen auch wirklich animiert auf ein 3D Objekt zu bringen, muss konstant per EntityTexture die selber Textur mit einem anderen Frame auf das Objekt gebracht werden. Und das geht nunmal schlecht, wenn man nicht weis, auf welches Objekt man die Textur bringen soll, oder das Objekt halt einfach gelöscht wurde (MAV).

Nach langem grübeln, Forum durchsuchen und Hilfe durchforsten fand ich die Lösung:

Code: [AUSKLAPPEN]
;--------------------------
;Cube-Wars Experiment #3
;--------------------------
;Intelligente Verfolgung und Überwachung von Meshes durch
;einen Type Container, mithilfe von "Parents" und "Childs".

;Grund: Dynamisch verwaltete und animierte Multitexturen
;--------------------------

Type Type_Test
   Field Parent%
End Type

;basical graphics init
   Graphics3D 800,600,32,2
   SetBuffer BackBuffer()
   SeedRnd MilliSecs()

;creating a new type thingy
   MTex1.Type_Test = New Type_Test
   MTex1\Parent% = CreatePivot()

;creating our dummy meshes
Dim DummyMesh(9)
For I = 0 To 9
   DummyMesh(I) = CreateCube()
Next

;--------------------------
;Was soll passieren ?
;--------------------------

;Die DummyMeshes werden der MTex1 Instanz
;als Child hinzugefügt, überprüft und
;ausgegeben. Danach werden zufällig Meshes
;gelöscht, und die Type Instanz muss selbst-
;ständig herrausfinden welche Meshes noch
;existieren

;--------------------------
;Ausführung...
;--------------------------

For I = 0 To 9
   EntityParent DummyMesh(I),MTex1\Parent%
Next

Print "DummyMeshes:"
For I = 0 To 9
   Print "    DummyMesh("+I+") = "+DummyMesh(I)
Next

Print ""
Print "Attatched DummyMeshes: "+CountChildren(MTex1\Parent%)

;break 1

Print ""
Print "-------------------------"
Print ">> Deleting Meshes Now <<"
Print "-------------------------"
Print ""

For I = 0 To 9
   If Rnd(0,9) > 1 Then FreeEntity DummyMesh(I)
Next

Print "DummyMeshes:"
   For I = 0 To 9
   Print "    DummyMesh("+I+") = "+DummyMesh(I)
Next

Print ""
Print "Attatched DummyMeshes: "+CountChildren(MTex1\Parent%)

;break 2

Print ""
Print "----------------------------"
Print ">> Meshlist By MTex 1 Now <<"
Print "----------------------------"
Print ""

Print "DummyMeshes:"
For I = 1 To CountChildren(MTex1\Parent%)
   Print "    "+GetChild(MTex1\Parent%,I)
Next
If CountChildren(MTex1\Parent%) = 0 Then Print "    Oooops, we deleted ALL meshes :/" : Stop

;break 3

Print ""
Print "As we can see, we lost track of what child-mesh is what dim-mesh."
Print "But we still know wich meshes are 'alive', and thats all that matters :D"

Stop
End

;--------------------------
;Ergebnis:
;Alles funktioniert wie erwartet...
;Animierte Texturen über diesen Weg
;sind möglich !
;--------------------------


Ich denke der Code ist selbsterklärend. Aber in Kurzform kann man sagen, das jede MultiTextur einen Pivot erhält, der als Parent für alle "hinzugefügten" Meshes fungiert. Und da CountChildren(Entity) nur Children auflistet die auch wirklich existieren, bin ich auf diese Weise abgesichert, dass ich wirklich nur eine Liste von Meshes habe die auch wirklich "da sind". Damit sind MAV's aus dieser Richtung nahezu ausgeschlossen Razz

Damit ist mein MultiTextur Funktionssatz fast fertig. Es müssen nurnoch ein paar kleine Funktionen geschrieben werden, und ein paar ältere optimiert werden.

Alles in allem bin ich weit hinter meinem ursprünglichem Zeitplan, aber was solls, dafür bin ich in anderen Teilen des Spiels schon weiter xD (MultiTexturen sind was tolles ^^)


So long,
Kernle

PS: Wers noch nicht weis, MAV steht für "Memory Access Violation", der Standard Fehlermeldung von BB wenn auf Objekt zugegriffen werden die nicht exestieren, o.ä. . Eben eine Speicherverletzung Razz

Von Erkältungen, ID2's und MultiTexturen

Montag, 1. September 2008 von Kernle 32DLL
Dank meiner Erkältung die Freitag letzter Woche anfing, und noch immer andauert, hinke ich mit meinem Zeitplan relativ stark zurück. Naja...

Mir ist in den Sinn gekommen das es vielleicht lustig wäre mal etwas mehr über das System hinter Cube-Wars zu erzählen. Eine Nette Spielerrei ist z.b. das "ID & ID2" System. Klingt seltsam, ist es auch. Der Sinn dahinter ist Funktionen im Programmcode Dynamisch arbeiten zu lassen (ID), und als Script Statisch (ID2).

OK, was heißt das genau:

Code: [AUSKLAPPEN]
;Funktionsparameter:
;MultiTexture_Init(GivenID2%=0)
;MultiTexture_Load(MultiTextureID%,Texture$,Slot%=0)
;Tipp: Parameter die = 0 sind heißen meistens das sie automatisch gesetzt werden)

;So würde man die Funktion "klassisch" in BB schreiben:

MultiTex1% = MultiTexture_Init()
MultiTexture_Load(MultiTex1%,"BlaTex.png")

;-------------------------------------------------------------

;Aber das geht auch:

MultiTexture_Init(4)
;Damit wird dieser MultiTex eine Eindeutige ID2 (4) zugeordnet, die IMMER eindeutig ist. Das ist
;praktisch für komplexe Abhängigkeiten, da so garantiert ist das die Abhängigkeiten immer zutreffen.
;In alle Funktionen sind üprigens auch "Abfangfunktionen" eingebaut, die Verlinkungen zu nicht
;exestierenden Objekten (normalerweise Absturz/MAV) verhindern :P

MultiTexture_Load(MultiTexture_FindID2%(4),"BlaTex.png")

;Überall wo ID2's angewandt werden gibt es die Funktionen "FindID2" und "GetID2".
;"FindID2" liefert die ID aus der ID2, "GetID2" liefert die ID2 aus der ID

;Achja, wird keine ID2 angegeben, hat das Objekt auch keine ID2 ;)


Im obrigen Beispiel werden sich bestimmt einige gefragt haben was die Funktionen mit dem Präfix "MultiTexture" bringen. Ganz einfach. Ich schreibe momentan ein "MultiTexture" Include, das alles wichtige zum Thema Multitexturing mit ein paar einfachen Befehlen möglich macht. Die Grundidee dahinter ist wiefolgt:

Zuerst wird ein "Texturen Sack" erstellt, das geht einfach mit "MultiTexture_Init()", der dann mit Texturen gefüllt wird ( MultiTexture_Load(MultiTextureID%,TexturName$) ). Diesen "Texturen Sack" kann man jetzt ganz simpel per "MultiTexture_Apply(MultiTextureID%,Mesh)" auf ein Mesh anweden Very Happy

Der Trick dabei ist, dass damit nicht nur MultiTexturing sehr einfach wird, sondern auch Animierte Texturen einfach zu verwalten sind (da automatisiert) -> "MultiTexture_LoadAnim(MultiTextureID%,TexturName$, Frames%, etc. ...)".

Wie, und ob das in der Praxis funktioniert wird sich noch zeigen. Eine schöne Spielerrei ist es auf jedenfall jetzt schon Wink. Da ich morgen Schulfrei habe, werde ich mich morgen endlich den "ModUnit" Bereich fertigstellen. Dann kann ich mich endlich um die eigentliche Spielmechanik kümmern Razz

So long,
Kernle

PS: Im Moment schaut der Game-Startup wiefolgt aus. Durch diese Befehl wird die gesammte Lademechanik gesteuert und in Gang gesetzt Razz

Code: [AUSKLAPPEN]
Mod_GetMods()
Mod_Debug() ;useless ?

Engine_Init() ;graphics, etc.

ToLoadMod% = Mod_GetIDByFileName(Engine_DefaultMod$)
Mod_LoadContent(ToLoadMod%)

;...
;ein paar unwichtige Debug Prints (siehe Link oben)
;...

Mod_MasterClear() ;free up the whole memory
End

Weitere Planungen

Montag, 25. August 2008 von Kernle 32DLL
Da bin ich wieder Wink

Die letzten Tage hat sich eigentlich nicht viel getan Sad. Im moment hänge ich noch immer am "System Part", d.h. der Teil des Spiels, der sich ums laden und verwalten der Units, Fields, Unittypes usw. kümmert. Besonders kopfzerbrechen bereitet mit der "ModUnits" Bereich (darin sind die "Blaupausen" für alle im Spiel befindlichen Units gespeichert). Außer dem "ModUnits" Bereich muss ich noch den "Field" und "FieldTypes" Bereich schreiben, und dann ist der "System Part" abgeschlossen.

Nach dem "System Part" geht es an den "Game Part". Der Teil des Spiels, der die eigentliche Spielmechanik enthält. Ich hoffe mit dem "System Part" bis Ende des Monats fertig zu sein (August), bzw. mit dem "Game Part" Ende September.

Ein Überblick über die einzelnen Parts, oder auch "Meilensteine":

Hauptspiel
Arrow "System Part" - Laden und verwalten der Hauptspiel relevanten Daten (fast fertig)
Arrow "Game Part" - Die eigentliche Spielmechanik
Arrow "GUI Part I" - Allgemein Spielgrafik mit GUI, etc. (Hauptspiel)
Arrow "Sound Part I" - Integration eines Soundsystems (Hauptspiel)
Arrow "Beta Test" - Erste (öffentliche ?) Beta zum Testen der Spielmechanik

Storymode
Arrow "S-System Part" (System Part II) - Laden und verwalten aller "Storymode" relevanter Daten
Arrow "S-Game Part" (Game Part II) - Der "Storymode" allgemein
Arrow "GUI Part II" - Allgemein Spielgrafik mit GUI, etc. (Storymode)
Arrow "Sound Part II" - Integration eines Soundsystems (Storymode)
Arrow "Demo I" - Evt. eine Demo des Spiels (steht jetzt noch nicht fest)

Spiel Inhalt
Arrow "Story Part" (Content Part I) - Die Story des Spiels
Arrow "Graphics Part" (Content Part II) - Alle Grafiken des Spiels
Arrow "Sound Part" (Content Part III) - Sound, Musik und vielleicht auch vertonung des Spiels

Arrow "Release"

(Der Name in der Klammer steht für den Alternativnamen des Parts)


Ich halte euch auf dem laufenden Wink

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