The Vorx

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

Worklogs The Vorx

22. Vom Dümpelframework und kleinen Erfolgen

Donnerstag, 15. Juli 2010 von ComNik
Guten Abend (:

Morgen früh gehts nach Florida, deswegen fasse ich mal die Ergebnisse dieser Woche in einem WLog Eintrag zusammen.

Anfangs fiel ich in ein kleines Motivationsloch, wohl weil ich schon an die 5 mal an der Aufgabe: "Kollisionsreaktion", gescheitert war...

Nun ja, heute war dann wieder der erste richtig produktive Tag, n-Halbleiter kam zu Besuch und wir haben einige Sachen geschafft.

Dazu muss man wissen, dass halbleiter auch an einem Framework arbeitet (ja für seinen Core Wink). Dieses hat er aus mir unerfindlichen Gründen "Dümpel - Framework" getauft <.<. Nach meinem vorletzten Eintrag über das CBES, hat er sich entschieden, sein Framework auch Komponentenbasiert zu designen und schlug mir vor, die eine oder andere Komponente des Dümpelframeworks in das meinige zu integrieren.
Gegen mehr funktionalität habe ich natürlich nichts, also stimmte ich zu und wir setzten uns drann.

Erfreulicherweise schien sich unser Komponentendesign zu bewähren und wir konnten erste Neuerungen ohne viele Probleme (ein kleines, mit lokalen Koordinaten, weil das Dümpel nicht auf Physik Engines ausgelegt ist) implementiert werden.

Es ist nun nämlich möglich, Entities (also eig. alles) an andere Entities zu "heften".
Das gestaltet sich sehr einfach:
BlitzMax: [AUSKLAPPEN]

Local player:TEntity = TEntity.Create(400,300)
'//Hier Komponenten hinzufügen

Local weapon:TEntity = TEntity.Create(0,10) '<-- wir initialisieren gleich schonmal mit lokalen Koordinaten
'//Hier Komponenten hinzufügen

'//Jetzt kommts:
weapon.SetOrigin(player) '//Rechnet die globalen Koordinaten von "weapon" so um, als wäre "player" der Ursprung


user posted image
(Das kleine Oval ist das nicht-physikalische Entity was an der physikalischen Box hängt...)
(Die weisse Linie ist ein Kraftvektor)

Das hat zur mehrere Sachen zur Folge: Man muss nur noch den Spieler rotieren, und die Waffe wird im richtigen Abstand mitrotiert. Allerdings darf das angehängte Objekt (also die Waffe) nicht physikalisch Simuliert sein, also einen TCPhysics Komponenten erhalten, da die Physik Engine direkt die globalen Koordinaten verändert und das Prinzip ad Absurdum führt. Bei dem Parent Entity ist das egal, da wie auch immer es sich bewegt, das angehängte Gadget sich mitbewegt. Natürlich können so viele Entities wie man will.

Das war natürlich schon mal erfreulich, weil ich mir so das blöde TImageAnAnderesImage Gefummel spare.

Weiterhin dazu gekommen (in Vorx.Util) ist eine FPS Counter Klasse, das war schon lange(!) mal nötig.

Dazu bin ich wieder zu SVN zurück, es ist einfach Windows freundlicher (aka für jeden Deppen (aka mich) verständlich).

Danach hat sich n-Halbleiter mal mit einem kleinen Script Parser angefangen, den wird er hier aber noch selber vorstellen Wink

Ich bin währenddessen an die Kollisionsreaktion gegangen und habe es immerhin soweit gekriegt, dass Impulse gewirkt und berechnet werden können. In erster Euphorie fiel mir dann allerdings auf, das manchmal unerklärlich bei leichtester Penetrierung, das Objekt geschätzte 200 Bildschirme weit weg flog (nicht verwunderlich bei einem Impuls Anstieg von ~300 zu 17500...). Aber immerhin..

Zudem wurde ein Bug im SAT Intersection Test gefixt, bei dem eine Kante nicht getestet wurde Rolling Eyes

Folgende Vorgehensweise:

1.) Richtige Kollisionszeit für Reaktion nutzen (das verringert schonmal die "Explosionen"
2.) An Masse, Inertialmoment etc rumspielen
3.) MPR Ergebnisse überprüfen
4.) Komplexes Debug System implementieren, was genaue Änderungen loggt (bei Impulsausschlag z.B)
5.) SAT Collide nochmal angehen und versuchen obs da besser wird.

Wenn das alles zu nichts führt springe ich übrigens aus dem Fenster.

Danach geht es an die Optimierungen. Ziel ist Release am Ende der Sommerferien (Laptop fliegt mit ins Ami-Land).

Für die anderen Teile des Frameworks hab ich heute reichlich Ideen sammeln können, so wird es z.B eine Kamera Komponente geben, die das Scrolling managt und zudem mit einer Physik Komponente kombiniert wird. Das würde dann eine "Shaky-Cam" bei Explosionen usw. erlauben Smile (Ich mag Explosionen ^.^).

Meine Internetverbindung ist noch nicht gesichert (also in den USA), aber ich wenn ich es schaffe die RIgid Body Komponente fertig zu stellen, werde ich vor Freude einen Weg finden...

Ansonsten alles gute und schöne Ferien noch,
ComNik

21. Dreh dich Viereck!

Freitag, 9. Juli 2010 von ComNik
Hallo aus den Ferien Smile

user posted image

Wie man dem (zugegeben einfallslosen) Titel entnehmen kann, geht es in diesem Worklog mal wieder um einen der beiden großen Ziele für The Vorx, nämlich die Physik Engine.

Kurz zum "organisatorischen":

Die komplette Game Engine wurde jetzt mal in einen Scope gegliedert "Vorx.mod"
Der enthält im Moment:

Arrow Vorx.Actor
Arrow Vorx.Animation
Arrow Vorx.Energy
Arrow Vorx.Engine
Arrow Vorx.Gui 'Eigentlich Zombie GUI
Arrow Vorx.Maps
Arrow Vorx.Physics ' <-- Da gehts heut drum...
Arrow Vorx.Renderable
Arrow Vorx.Util
Arrow Vorx.Weapon

Actor, Energy, Renderable und Weapon sind übrigens Komponenten für das CBES (siehe letzten Eintrag).


Nun ja, letzte Woche habe ich beim Testen der Physik Engine bemerkt, dass sich Objekte beim Kollidieren eigentlich nicht richtig drehen, es viele Stabilitätsfehler gab und das mit Reibung auch noch nicht so richtig geklappt hat.
Also habe ich mir mal vorgenommen, die Engine neu zu schreiben.

Im Moment bin ich eine Woche vor Zeitplan ( Smile ) und jetzt kommt erstmal unkommentiert eine Feature Liste.

[Simulation]
-> Simulation mit der Euler Methode
-> Simulation mit der erweiterten Euler Methode
-> Gravitation
-> Reibung
-> Bewegungen unter berücksichtigung von Masse und Inertialmoment (berechenbar)
-> Shape System (atm: TPolygon, TCircle, TBox, TParticle, eigene Möglich natürlich)

[Kollisions Erkennung (nur True/False Erkennung)]
-> Kollisions Erkennung mit dem Gilbert-Johnson-Keerthi Algorithmus
-> ...mit dem Minkowski Portal-Refinement Algorithmus (schnellster bis jetzt)
-> ...mit dem Seperating-Axis-Theorem
-> Kollisions Test für Primitive (circle-circle,line-line,rect-rect,ray-line)
-> AABB - AABB Test (BoundsIntersect(Körper1,Körper2)
-> "Punkt in Dreieck" Test
-> "In Reichweite" Test
-> Automatische AABB Berechnung wenn gewünscht^^

[Kollisions Erkennung (mit Kontakt Informationen)]
-> Kollisions Erkennung mit dem Minkowski Portal-Refinement Algorithmus
-> mit dem Seperating-Axis-Theorem (noch leicht verbuggt...)

So das sind die Features bis jetzt.

Zur Benutzung:

1.) Das globale VPhysics Objekt initialisieren/erstellen (wird später von einer Funktion übernommen)
BlitzMax: [AUSKLAPPEN]

'Vorx.Physics \physics.bmx
Global VPhysics:TPhysics

'Anwendung.bmx
VPhysics = TPhysics.Create(0.0,0.0) 'Mit Gravitation x,y initialisieren


2.) Das wars schon, im Moment kann man die Engine nur als Komponente für das CEBS nutzen, später gibt es vllt auch eine "normale" TRigidBody Klasse oder so.
Die Komponente für die Rigid Body Unterstützung heisst "TCPhysics".
In der VorxEngine müsste ein Rigid Body also so erstellt werden:

BlitzMax: [AUSKLAPPEN]

Import Vorx.Engine
Import.Vorx.Physics 'mehr Komponenten brauchen wir ja erstmal nicht

Global body:TEntity = TEntity.Create(x,y,masse,rotation=0) 'Alles ist ja ein Entity(siehe letzten Eintrag)
body.AddComponent( TCPhysics.Create( TBox.Create( 50,50 ) ) ) 'Rigid Body Komponent & Shape 'erstellen und hinzufügen


3.) Wenn wir jetzt genügend Körper erstellt haben, können wir erstmal in der Hauptschleife die Gravitation wirken lassen:

BlitzMax: [AUSKLAPPEN]

VPhysics.ApplyGravity()


4.) Nun können wir entweder eine automatische Update Schleife von VPhysics aufrufen, oder aber wir schreiben eine eigene (somit können wir auch bestimmen was passieren soll)
Eine Sache wäre zu bemerken: VPhysics ist ein sogenanntes Subsystem, es speichert also intern nur die Komponeten der Entities, weil es ja über die anderen Entities nichts wissen muss, das geht btw automatisch.

BlitzMax: [AUSKLAPPEN]

For Local phys:TCPhysics = EachIn VPhysics.entities 'Durchläuft nur Entities die auch TCPhysics besitzen
VPhysics.UpdateEuler(phys,timestep) 'oder natürlich VPhysics.UpdateXEuler(phys) je nachdem was man will
Next


Der Timestep ist im Moment noch fest implementiert, sobald die Schleife aber richtig angepasst wird, kann man da noch viel Performance rausholen (weil nicht alles 60 mal pro Frame gemacht wird...) - und das System ist skalierbar. Smile Natürlich kann man den Timestep auch frame unabhängig machen. Aber dazu mehr in einem nächsten Eintrag.

5.) Nur Updaten ist langweilig wenn nichts passiert (keine Gravitation). Also können wir ja mal den Körper mitsamt seiner AABB zeichnen lassen. Und wir könnten wenn die Maus gedrückt wird eine Kraft auf einen seiner Vertexe auswirken (sonst dreht er sich ja nicht wenn wir nur am Schwerpunkt ziehen...).

BlitzMax: [AUSKLAPPEN]

Import Vorx.Engine
Import.Vorx.Physics 'mehr Komponenten brauchen wir ja erstmal nicht

Global body:TEntity = TEntity.Create(x,y,masse,rotation=0)
body.AddComponent( TCPhysics.Create( TBox.Create( 50,50 ) ) )

Graphcsi(800,600,0,60)

While Not (KeyDown(KEY_ESCAPE) Or AppTerminate())
Cls

If MouseDown(1)
Local dist:Vector2 = ICreateVector(MouseX() - vex.pos.x, MouseY() - vex.pos.y)

body.shape.vertex[0].ApplyForce(dist.x,dist.y)
End If

VPhysics.ApplyGravity()
VPhysics.UpdateEuler(body)
body.shape.Draw()
body.shape.DrawBounds() 'zeichnet die AABB

Flip
Wend
End


Die etwas langen Methodenaufrufe werden noch gewrappt...

Nun kann man den Körper an einem Eckpunkt herumschleudern etc...

Das wars für heute, es folgt noch eine Kurze Liste der Dinge die noch rein sollen:

[Simulation]
-> Simulation mit der Range-Kutta Methode
-> Eine zweite Komponente für Verlet Körper
-> Richtige Berücksichtigung des Timesteps
-> Konkave Körper
-> Ein Joint/Spring System + IK Solver

[Kollisionserkennung]
-> UpdateGrid/Bsp Tree
-> Optimierung von GJK/Mpr (da ist noch einiges rauszuholen Wink)
(im Moment laufen alle Algorithmen übrigens bei 130 Objekten noch schön flüssig. Und das ohne BSP)

-> Continous Collision Detection (für sehr schnelle Objekte, erklär ich irgendwann mal...)

Das wichtigste als nächstes ist aber natürlich die Kollisionsreaktion.
Und die Funktionen alle mal schön wrappen...

lgund schöne Ferien noch,
ComNik

PS: Scrum rockt, probierts mal aus Wink

20. "Component Based Game Object System up and running&

Mittwoch, 9. Juni 2010 von ComNik
Guten Abend Smile

Ich habe meinen ersten freien Tag (mündliches Abi rocks!) heute mal nicht dafür genutzt Latein zu lernen, sondern die VorxEngine jetzt auch offiziell als Modul zu implementieren.

Und zwar nicht so wie bisher geplant, sondern mit einem neuen System:

Component Based Entity System nennt sich das Ganze und soll in diesem Worklog Eintrag am Beispiel der VorxEngine erklärt werden.

1.) Die Unterschiede

Komponentenbasierte Entwicklung unterscheidet sich ziemlich stark von der "alten" OOP-Hierarchie Methode.
Das möchte ich mit zwei Bildern verdeutlichen.

Hier die alte OOP Methode als Klassen Hierarche implementiert (völlig zufällige Namen btw):
user posted image

Wunderbar strukturier, eine schöne Basisklasse von der alles abgeleitet ist und es ist einfach irgendwie "natürlich" so zu coden.

Aber moment: "TVehicle und TCover sind in verschieden "Strängen" der Hierarchie! Was ist denn wenn ich mit meinem Cover System auch hinter Fahrzeugen in Deckung gehen will?!"

- "Na gut dann nehmen wir halt die Member aus TCover und fügen sie halt an TVehicle an, ist doch nichts dabei?"

Bei einem so einem Fall ist nichts dabei, aber bei viel mehr Klassen treten immer mehr solcher fehlenden Verbindungen auf -> doppelter Code, memory overhead, etc.. etc...

Wie sähe denn obrige "Klassengemeinschaft" als CBES implementiert aus?:
user posted image

Als erstes fällt einem auf: Keine Pfeile mehr?
Das liegt daran, dass die ganzen Klassen nichtmehr von der Basisklasse abgeleitet ist, sondern es in-game nur noch eine einzige Klasse für Objekte gibt: Die Basisklasse.

Alles in den grünen Ovalen sind "nur noch" Komponenten, zwar immer noch Klassen aber mit einer leicht abgeänderten Nutzungsweise.

Erstellen eines Objektes mit der alten Methode:
Code: [AUSKLAPPEN]

Global player:TPlayer = CreatePlayer(...)


player hat jetzt variablen für Position, Geschwindigkeit, Energie, Steuerung, Waffen, Items und noch viele mehr.

In einem CBES würde das Erstellen so aussehen: (TEntity ist die Basisklasse)
Code: [AUSKLAPPEN]

Global player:TEntity = CreateEntity(id,name,type)
player.AddComponent(CT_PHYSICS)  ' Player kann jetzt Bewegen, Kollidieren (z.B)
player.AddComponent(CT_VISIBLE)   ' Player kann jetzt gezeichnet werden (z.B)
player.AddComponent(CT_ACTOR)     ' Player kann jetzt Aktionen ausführen, gesteuert werden (z.B)


Das sieht jetzt umständlicher aus. Mag sein, dafür erstelle ich z.B einen NPC hinter dem man in Deckung gehen kann so:

Code: [AUSKLAPPEN]

Global npc:TEntity = CreateEntity(...)
npc.AddComponent(CT_PHYSICS)
npc.AddComponent(CT_COVER) 'Alle infos die das Cover System braucht
npc.AddComponent(CT_VISIBLE)
npc.AddComponent(CT_AI) ' Der Npc soll von der AI gesteuert werden


Wollte man sowas oder vergleichbares mit der Hierarchi realisieren, müsste man schon viel Code doppelt schreiben.

Mit eienem CBES ist das ganze aber pure Addition von Funktionen:

Code: [AUSKLAPPEN]

Steuerbares Licht = CT_LIGHT + CT_ACTOR
Normales Licht = CT_LIGHT
Kollidierende Partikel = CT_PARTICLE + CT_PHYSICS + CT_VISIBLE
Leuchtendes Auto? - CT_LIGHT + CT_VEHICLE
Leuchtendes, brummendes, steuerbares Auto - CT_VEHICLE + CT_PHYSICS + CT_ACTOR + CT_LIGHT + CT_SOUNDEMITTER


usw usw.

Klingt gut, oder?

Mich hat es überzeugt. Deswegen habe ich eine TEntity Klasse geschrieben, die jetzt flexibel durch Komponenten Klassen erweitert werden kann. Die einzelnen Komponenten müssen natürlich neu geschrieben oder aus bestehendem Code erstellt werden. Außerdem muss ein Template System erstellt werden, dass es ermöglicht viele Komponenten gleich zu initialisieren (merh dazu demnächst).

Nun noch kurz zu den negativen Seiten. Da Entities flexibel erweiterbar sind, kann eine Instanz nicht genau wissen welche Member sie alles hat.
Daher braucht es ein performantes Casting System, was die verfügbaren Komponenten schnell auch für externe Funktionen verfügbar macht. Auf diesem Gebiet expermimentiere ich noch, im Moment nutze ich eine TMap. Irgendwelche Anregungen zum Thema schnelleres als String IDs oder Map Strukturen? - Comments! Very Happy

Ich werde wohl noch öfter über das Komponenten Basierte Entity System schreiben, heute wollte ich nur einen groben Aufriss liefern, wer sich dafür interessiert, der sei herzlich eingeladen mir eine PN zu schicken.

lg und schönen Abend noch,
ComNik

19. Suche Dummygrafiker...

Donnerstag, 20. Mai 2010 von ComNik
Huhu,

Ich arbeite gerade an dem Steuerungs-Prototypen, und es klappt ganz gut bis jetzt. Ich muss halt gucken was gut geht etc... Natürlich wollt ich das ganze gern:
1.) So weit kriegen, dass alles drinn ist was nachher im Spiel gehen soll
2.) in ne Demo packen (oder wenigstens als Video) und dann hier releasen

Folgendes Problem: Im Moment komme ich noch super mit Cs2D und eigenen Dummy Grafiken aus. Aber nachher im Spiel sollen auch Aktionen wie eine Rolle (auch aus der Vogelperspektive natürlich!) oder vllt verfeinerte Animationen für schnelles Rennen mit der Waffe etc... Alles mögliche.

Doch schon die Rolle kriege ich in keinsterweise als Dummy Grafik hin. Ich könnte natürlich einfach irgendwas in die Frames zeichnen und nur gucken ob richtig abgespielt wird. Aber ich würde auch gerne sehen ob mein Animationskonzept flüssig aufgeht, daher:

-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
Ich suche einen Dummy-Grafiker (von mir aus auch gerne einen "normalen"...)

Es geht mir überhaupt nicht um brilliante Qualität, lediglich sollte erkennbar seien, um welche Bewegung es sich handelt...

Wäre super, wenn sich jemand findet.
ACHTUNG: Wenn sich jemand meldet, heisst das nicht dass er an dem ganzen Projekt beteiligt sein muss (er kann, wenn er will Wink), es ist nur diese eine Aufgabe


Kontakt:
E-Mail: comnik@gmx.net
oder PN

ICQ, MSN könnte mann dann vereinbaren falls benötigt. Alle weiteren Einzelheiten (Auflösung, Aufbau der Animation, etc..) wird dann so besprochen



Also, wenn ihr freie Zeit habt, einigermassen gut pixeln könnt (aus der Vogelperspektive) und mir sogar noch helfen wollt, dann meldet euch bitte Wink

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


Das war das eine.

Nun zur Steuerung (um hier nicht nur Stellenanzeigen zu posten...):

Erstmal allgemein. The Vorx soll natürlich actionlastig gesteuert werden, WASD + Mouse ist logisch. Normale Shooter Steuerung eben. Rennen, Benutzen, Links/Rechts "spähen", Zielen(ja zielen, siehe weiter unten) alles klar soweit, Tastenbelegung braucht hier noch niemand^^

Das Besondere allerdings wird die Funktion der Leertaste. Diese löst nämlich, je nach Umgebung eine spezielle Aktion aus. So z.B:

in der Nähe einer möglichen Deckung: Der Spieler geht in Deckung
erneuter Klick: Würde jetzt das gleiche auslösen, aber der Spieler ist schon in Deckung also: Sprung, gleiten über die Deckung hinweg auf die andere Seite.

Jetzt z.B einfach während dem Rennen in freier Umgebung: Hechtrolle, auf dem Boden entlang rutschen

Vor einem Behälter oder einem Charakter: Reden, öffnen

In der Nähe einer Granate: Hechtrolle weg von der Granate


All diese Aktionen müssen natürlich noch angepasst werden (nicht, dass man im Kampf plötzlich anfängt mit dem Verbündeten zu reden...)


Und wie funktioniert das nun?

Erstmal ein Schaubild:
user posted image

Der kleinere Halbkreis um den Spieler (das grüne Dreieck) herum, ist der kreativ benannte "Action Radius".
Aktionen können also nur ausgelöst werden, wenn der Spieler drauf guckt (ist ja auch logisch, man dreht sich ja beim Reden oder Öffnen von/mit Irgendwas/Irgendwem zu dem betreffenden Objekt...).

Dieser Halbkreis sagt jetzt bei jedem Aufruf der Leertasten Funktion, welches Objekt gerade mit ihm Kollidiert, beispielsweise ein Entity vom Typ TYP_ACTOR, aha weiss die Funktion, jemand mit dem der Spieler beim Drücken dieser Taste nur reden kann, also Rede().
Oder es "kollidiert" eine Kiste (TYP_COVER oder TYP_OBJECT). Aha, ein Objekt wir können uns dahinter verkriechen.

Nun ich hoffe das ist einigermassen verständlich. Jetzt zum großen Kreis. Der unterstützt das Deckungs System. Ich habe übrigens hier stark "geforscht" indem ich mir mal Gears of War angeschaut und "Wanted: Weapons of Fate" gespielt hab (Beides sehr zu empfehlen btw). Die Deckungssysteme da fand ich eigentlich genauso, wie ich das haben wollte: Sobald man in Deckung ist kann man sich entlang dieser fortbewegen. Kommt man jetzt an den Rand einer Deckung und späht da hervor, wird geguckt ob eine andere Deckungsmöglichkeit innerhalb des großen Kreises ist, und wenn ja wird beim Druck auf eine Taste (z.B Leertaste...) eine Hechtrolle zu dieser Deckung ausgeführt und automatisch wid dort "in Deckung gegangen".


Gestern habe ich dann noch das Animationssystem umgeschrieben, es sollte nun flüssiger zwischen Animationen wechseln können (Also von laufen zu rollen zu rennen etc...)

Mehr will ich garnicht sagen (nicht ohne Demo!).

Gute Nacht,
ComNik

18. Langsam aber sicher...

Samstag, 15. Mai 2010 von ComNik
... geht es voran Wink

Nach dieser coolen Überleitung erstmal ein Bild:
user posted image

Ich weiss, ich weiss todschick wie immer -.-

Wie dem auch sei, das ist nun "Body Lab", der Entity Editor für die Vorx³ Physics Engine. Auf dem Bild sieht man nun ein paar geladene .vphys Dateien in Form von (untexturierten) physikalischen Objekten.

Das elegant rot hervorgehobene Objekt ist das derzeit ausgewählte. Das lässt sich nun bewegen oder drehen, später dann eben auch noch mehr. Der kleinste Kasten (eig um die Maus, wird nur nicht mit gepastet...) ist das "mouse" Objekt, dass jetzt noch Debug gerendert wird und eigentlich nur für die Funktion "EntityPicked()" nützlich ist. Mit ebendieser lässt sich ein beliebiges (und dank GJK auch beliebig gedrehtes (Smile Objekt auswählen.

Speichern geht noch nicht, bzw geht aber durch eine kleine Eigenheit des Entity Managers wird alles in einem neuen File gespeichert und das will ich nicht immer...

Außerdem müssen langsam mal die Funktionen der Vorx³Physics Engine gewrappt werden. Ein "entityMng.collManager.GJKIntersect()" nervt halt schon ein bissl...

Heute hab ich dann noch einen lange irgendwie übersehnen Bug bzw Denkfehler gefunden. Objekte (vor allem Rechtecke) konnten nicht unterschiedlich hoch und breit sein oO

Naja und merkwürdigerweise hab ichs erstmal nicht hingekriegt.
Aber in Ruhe hinsetzen, Sinus und Cosinus Verschiebung aufzeichnen wirkt manchmal Wunder Very Happy

Alles in allem ein Recht erfolgreicher Tag.
Ich muss jetzt versuchen bei den vielen kleineren Fixes und Änderungen den Überblick zu behalten :/, aber das schaff ich schon.

Sobald ich Entities erstellen und Texturieren kann bin ich froh.

Das wars,
gute Nacht und lg.

ComNik

17. Der Datenwald lichtet sich

Dienstag, 11. Mai 2010 von ComNik
Moin moin,

ohne überhaupt content zu haben, ist das verwalten von allen benötigten Daten ziemlich komplex... Vllt sogar deswegen.

Ohne wirklich zu wissen, was später noch alles an Daten verarbeitet werden muss, wenn das Spiel in einem fortgeschritteneren Zustand ist.
Ich will schlieslich nicht alle paar Monate was neu schreiben müssen.

Gottseidank ist aber jetzt der größte Teil dieser Planung fertig (und sogar größtenteils Dokumentiert Very Happy)

Mehr um meine Gedanken zu sammeln (irgendwie wird dieser WLog ein wenig dazu missbraucht :/), schreibe ich hier einfach mal wie der TEntityManager
funktioniert. Er ist mit der wichtigste Manager, da er alle Objekte (sog. Entities) im Spiel verwaltet. Entities sind z.B der Spieler und alle anderen Charaktere/Monster, sämtliches (hoffentlich...) physikalisch simuliertes Gerümpel (Kisten, Rohre & anderer Schrott, Tische, Mauern und sogar die Wände in den Leveln). Im Grunde genommen ist alles ein Entity außer die UI Gadgets. Auch alle Partikel werden Entities sein (allerdings werden nicht alle auf Kollission überprüft...).

Also der Entity Manager hat zuersteinmal Funktionen um ein einzelnes Entity zu laden oder zu speichern. Dazu wird größtenteils Blade Runners großartiges Chaos Clone verwendet. Beim Laden wird nach der Initialisierung vom ".vobj" File aus, eine Initialisierungsfunktion aufgerufen, die einige Vertex informationen setzt, etc...

Die .vobj Dateien werden nach dem Schema Name des Entity + ".vobj" gespeichert.
Der Spielercharakter (z.B "ComNik") würde so gespeichert werden:

"ComNik.vobj"

Objekte ohne Namen werden einfach mit ihrer ID als Name abgespeichert. z.B "*kryptische Speicheraddresse*.vobj"

Zwar ändern sich die IDs bei jedem Start, aber das macht ja nichts, da der Speicher Pfad des Managers auch beim Laden aller Objekte immer rekursiv nach allen ".vobj"'s durchsucht wird.


Alle Entities, die er findet, fügt er zu der internen Entity Liste zurück, gibt ihnen eine ID. Entities können aber auch einfach so erstellt werden und dann dem Manager hinzugefügt werden.

So... mir fällt nichtsmehr ein.

Ich mach hier mal weiter und halt euch auf dem Laufenden Wink
lg
ComNik

Da mal ein kleines Bild meiner ersten geladenen Entities Smile :
user posted image

16. To Script, or not to script...

Samstag, 24. April 2010 von ComNik
Diese Frage stelle ich mir schon ne ganze Weile.
Heute unter der Dusche kam mir die Eingebung "To Script!".

Heikele Situation. Eigene Scriptsprache schliesse ich schonmal aus,
die Chance fertig zu werden reduziert sich da doch ziemlich drastisch...

Nächstliegende Alternative war natürlich Lua. Forensuche angeschmissen und auf LuaJIT gestossen.
Das hab ich dann natürlich mal installiert und geschaut ob ich die Dokumentation blicke. Die Stunden vergingen...

Wie dem auch sei, ich befürchte Lua wird noch ein bisschen Einarbeitungszeit brauchen, aber ich tendiere schon eher zum scripten.
Die Teile von The Vorx, die Scripte benötigen würden, kommen eh erst später.

Welche Teile wären das überhaupt?

Arrow Effekte. (".veffect") :
Effekte zu scripten würde bedeuten, Waffen, Items und besondere Aktionen modbar und natürlich
scriptbar zu machen. Das wäre dann recht nützlich...

Arrow eventuell KI - Verhaltensweisen

Arrow Trigger Actions (also einfach Skripte, die ausgeführt werden, wenn etc...)


Was gibts noch neues?

Arrow Physics Engine heisst jetzt Vorx³ Physics...
Arrow Physics Engine ist mit grundlegender Funktionalität (Lineare/Angulare Effekte, Simple Kollissionsauflösung) nun endlich implementiert. So langsam könnte also ein kleiner Entity Editor her

Mehr will ich auch gar nicht sagen. Außerdem hoffe ich das ich die Map Engine erfolgreiche einbinden kann.
Sollte das gut klappen, kann ich wohl endlich mal etwas in Bewegung sehen...

lg
ComNik

15. Struktur

Mittwoch, 21. April 2010 von ComNik
Guten Abend.

Der heutige Eintrag dient vor allem zum sammeln meiner Gedanken^.^'
Nachdem ich heute dies und jenes probiert, dies und das geschrieben hab, aber nicht wirklich weiter gekommen bin, muss ich jetzt erstmal ein wenig Ordnung reinbringen.

Fangen wir also an:

Das allergrundlegendste von allen ist natürlich die TApplication Instanz
Arrow Vorx:TApplication
Arrow Kontrolliert (im Moment) nur einen TAppState - TGame

Heute beschäftige ich mich mal nur mit dem.

Wir brauchen Systeme für folgende Probleme:
Arrow Speichern und Laden von jeglichem content (sei es grafik oder config file)
Arrow Verwalten von allen Spielobjekten
Arrow Darstellen von jeglicher Grafik und Effekte
... und natürlich die Gameplay Logik, aber die sprengt den Rahmen hier bei weitem Wink

Wie lösen wir(ich) die Probleme?

1.) Laden & Speichern
Zu beginn des Projektes, verfolgte ich noch den eher konventionellen weg: Jede Klasse hat eine Save() Methode und die werden dann schön alle aufgerufen. Inzwischen habe ich was besseres gefunden, nämlich Bruceys Persistence Modul (siehe auch Blades' Chaos Clone).

Damit kann ich nun alle Objekte in dem passenden Dateityp speichern.
".vconf": Konfigurationsdateien für Steuerung oder Grafikauflösung
".vobj": Entities (Spiel objekte) mehr dazu später
".veffect": Dazu in einem späteren Eintrag mehr
".vmap": Selbsterklärend...

Ebenso leicht kann ich die Objekte wieder initialisieren, nur Referenzen müssen danach gesetzt werden, da deren Pointer Addresse natürlich nichtmehr gültig ist.

Was Bilder und Sounds angeht, erwähnte ich ja schon, dass ich die von Fetze erdachte Konstruktion namens Data Provider nutze, um alle Bilder in Form von Pixmaps zu laden und zur Nutzung "aufzubereiten"...

2.) Verwalten von Spielobjekten
Das komplette Entity System wird (so habe ich heute entschieden) in WarpPhysics ausgelagert.
Klassen wie TPlayer müssen dann vom Spiel nur noch abgeleitet werden.
Die Verwaltungsinstanz ist der sogenannte "TEntityManager". Der registriert neue Objekte und versorgt diese mit einem Link (der sogenannten ID) auf ihre Position in der entity Liste.
So lassen sich Objekte schnell löschen oder finden. Ursprünglich wollte ich alles mit Int IDs und einem großen Array machen, allerdings mag ich Lists lieber und Links ermöglichen mir das ganze performant zu machen.

Der entity manager kann nun objekte initialisieren (De - serialisieren, mit Hilfe des Persistence Moduls) und löschen. Im Spiel selber können sich objekte dann anhand ihrer Links schnell identifizieren und Informationen austauschen.

Die Routinen zur "normalen" Kollissionserkennung sind übrigens schon eingebaut. Mit anderen Worten: Objekte können mit beliebig gedrehten oder sich bewegenden Objekten kollidieren und müssen nicht einfach durchlaufen...
Die Kollission wird zwar nur entlang der Normale aufgelöst, aber mehr braucht man ja erstmal nicht.

Später dann kommt die richtige Kollissions Reaktion dazu.

3.) Rendern
Im Moment liefert Max2D noch die Schnittstelle zu DX9, ich denke aber über einen Wechsel zu Avas Engine oder allgemein zu glMax2D (richtiger Name?).

Entities werden durch TModel Objekte repräsentiert, die einmal Platz für Grafik Daten bilden (Animationen, HUD Bildchen etc... und zweitens Physik Daten und Kollissions Modelle enthalten).

Durch die Trennung von Entity und Modell spare ich speicher, weil nicht jede Box Entity ein eigenes Box Modell braucht. Die Eckdaten werden einfach übernommen.


So das wars auch schon. Der Eintrag war jetzt ziemlich runtergeschrieben, da ich wie gesagt meine Gedanken ordnen musste... Aber eventuell findet der eine oder andere ja was nützliches oder lesenswertes darin.


Ich habe mich dazu entschlossen das State Management ein wenig zu entschlacken, um den Überblick zu behalten. Dann wird langsam mal die Physik Engine aus den Prototypen in das eigentliche Spiel übernommen. Wenn ich dann endlich mal mit Map Engine Rewrite (mehr dazu demnächst...) und diversen Editoren fertig werde, stehen die Chancen für erste Laufversuche gar nicht so schlecht Wink

Bis dahin,
lg
ComNik

14. Und wie gehts weiter?

Montag, 19. April 2010 von ComNik
Soderle ich dachte ich sollte auch mal wieder was von mir geben.

1. Keine falschen Schlüsse aus dem Titel ziehen, das Projekt lebt, ich arbeite (fast) jeden Tag dran.

Da das nun geklärt wäre...

Kommen wir zu Punkt 1:

"Zeitpläne":

Wie ich schon befürchtete hat sich mein Zeitplan als nicht einhaltbar erwiesen. Also eigentlich war er sehr ausgeklügelt, doch leider hab ich bei der Planung nicht bedacht, dass ich kein 50 Mann Studio habe :/

Son mist, naja, nach einer Woche Krankheit und 2 Wochen Urlaub war dann eigentlich nichtsmehr zu retten, also habe ich mich entschieden, dass ganze etwas unprofessioneller zu sehen und keinen Zeitplan zu machen. Ich habe das ganze durch eine große ToDo Liste ersetzt, die arbeite ich jetzt wies mir passt ab Smile

Und weiter gehts:
"Versionskontrolle":

Ja, The Vorx steht endlich unter der Obhut von Svn und ich muss sagen, dass war die bisher beste Entscheidung. In Kombination mit einem frischen neuen i7 Laptop steigert das die Produktivität doch ziemlich.


Was hat sich denn alles getan?

Nun, zu ersteinmal wurde die WarpGUI umgebaut. In der Praxis erwies sie sich als sehr sperrig (durch die unbedingte Bindung an Menus). Das neue Konstrukt nennt sich Zombie GUI (aus welchem böden Grund auch immer...) und gefällt mir bisher viel besser. Mehr dazu bald im WarpGUI Worklog.

Dann habe ich das Game State Management System (?) in eine externe TApplication Klasse abgeschoben und als Modul verpackt -> Code Umfang geschrumpft, Übersicht++

Im Moment besteht The Vorx aus mehreren simplen states: GS_INTRO, GS_MENU, GS_GAME, GS_OUTRO

Da werden aber noch ein paar hinzukommen (Mehrspieler etc...). Die dienen im Moment nur zum testen.

Gestern entdeckte ich Bruceys Persistence Modul. Ich hab heute also alle Speicherroutinen in den Müll geworfen und bin auf TPersist umgestiegen. Das klappt auch wunderbar und hat mir viel Arbeit abgenommen. Meine früheren Versuche, solch eine generelle Speicherfunktion zu schreiben, ist eher schlecht als recht gelungen...

Da ich mich somit elegant aus dem Speichern/Laden Dschungel herausmanövriert habe, konnte ich heute direkt die Klassen Hierarchie überarbeiten und das neue Entity System einführen.

Dazu ein kleines Schaubild:

*KLICK*

Wie man erkennen kann, ist unten was abgeschnitten, das liegt daran, dass die Klassen dadrunter nicht viel mehr sagen als die grund Einteilung (Physical, Item), die man auf dem Ausschnitt sieht.


Das ganze System ist also implementiert. Jetzt fehlt nur eine TModel Klasse, darin werden Informationen über physikalische Objekte gespeichert. Mehr dazu in einem der nächsten Posts.


So ich mach hier jetzt mal Schluss, sorry wenn ich jetzt auf nichts genauer eingegangen bin.
Das hol ich nach, ich bin nur gerade ziemlich müde und wollte einfach mal
ein Lebenszeichen abgeben Wink

lg
ComNik

13. Realistischer Projektilflug - Danke Gauss!

Freitag, 5. März 2010 von ComNik
Guten .. Nachmittag?

Naja wie dem auch sei, wieder ein kurzer Eintrag.
Gestern kam Game Programmin Gems 7 an *freu*.
Neben dem lehhreichen Artikel über den MPR war auch ein kleines Schmankerl für Shooter aller Art dabei.

Realistische Projektilflug dank Gauss'scher Zufallsverteilung

Wie wir alle wissen, haben Waffen einen Rückschlag und deswegen trifft keine Kugel genau ihr Ziel (auch mit Fadenkreuz nicht Wink) sondern streut bei größerer Entfernung um gut und gerne 5 Meter (mal von heutigen Waffen ausgehend). Auf mittlere Distanz (wie in einem Shooter ja normalerweise üblich, streuen die Projektile vielleicht maximal einen Meter bei ruhiger Hand und Waffe im Anschlag. Aus der Hüfte natürlich entsprechend mehr. Gut. Nur wie simuliert mann dieses Verhalten effizient und möglichst realistisch aussehend in einem Spiel?

Versuch 1: Rand(). Natürlich einfach zufälligen Wert zu X und einen anderen zu Y addieren. Vielleicht zwischen -10 und 10 Pixeln. Das dürfte schön fliegen. Ist aber total unrealistisch. Denn: Waffen verteilen ihre Kugeln nicht gleichmässig in alle Richtungen, streuen also nicht gleichmässig. Die höchste Konzentration von Projektilen sollte also möglichst nah am Ziel seien. Hierbei gibt es sogar eine ungefähre Regel. Unterteilt man den Bereich um das Ziel in 3 Kreise (Dartscheiben mässig) so ist die Wahrscheinlichkeit, dass die Kugel innerhalb des kleinsten (mittlersten) Kreises liegt ungefähr 61%. Die Wahrscheinlichkeit in einem der beiden mittlersten Kreisen zu liegen liegt bei etwa 95%. Alles andere kann als Qeurschläger gewertet werden und kommt nur sehr selten vor.

Das Problem mit Rand() ist, dass jede Zahl die gleiche Chance hat gewählt zu werden. Unsere 61-95 Regel wäre also eine 50-50 Regel. Das ist schlecht.

Hier kommt Herr Gauss ins Spiel:

Versuch 2: Gauss'sche Zufallsverteilung. Diese berechnet einen Zufallswer der aber auf einen bestimmten Punkt konzentriert ist. Dazu gibt es ein paar Formeln, die mann aber nicht braucht. Generell können wir sagen GaussRand(-10,10) sollte meistens Zahlen nahe der 1 bevorzugen. Einfach mal googlen ihr findet bestimmt was, wenns um die genaue mathematische Darstellung geht.
Problem: Eine exakte GaussRand() Implementation ist rechenintensiv und vor allem nicht nötig. Wir brauchen nur eine Approximation, solange der Spieler nicht nachmisst wie weit die Projektile streuen.
Die Funktion dafür ist schnell geschrieben, sie addiert einfach eine bestimmte Anzahl an (halbierten) Rand() Integern und liefert das zurück! Aüßerst Performant und sieht gut aus. Meine Implementation findet ihr im Codearchiv unter folgendem Link: *KLICK*

Mindestwert ist einfach der negierte Streuungswert, Maximalwert ist der Streuungswert selber.

Um eine Minigun zu simulieren könnte man den Zufallswert schon beim Ausstoss dazurechnen.
Bei einer normalen Kugel vllt zur Geschwindigkeit oder direkt zur Position, da muss ich noch ein gutes System finden, welches auch die Distanz mit einbezieht.

So das wars auch schon,
lg
ComNik

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