BlitzBasic Portal Worklogs - ChaosRacer 2

Ganz vergessen...

D2006 — Tue, 26 May 2009 21:15:40 +0200

es ist schon eine Weile drin, aber ich wollte es mir für den nächsten, größeren Worklog-Eintrag sparen. Gestern hab ich es aber vergessen, deshalb nen kurzer Eintrag:

Wie unschwer zu erkenne ist, befindet sich nun in der rechten oberen Ecke eine kleine Minimap, welche die ganze Strecke zeigt und den Spieler (sowie später die Gegner) als Punkte darstellt. Diese kleinen Bildchen werde ich auch zur Streckenauswahl im Spielmenü später benutzen. Sie werden übrigens vollautomatisch beim Speichern einer Karte mit dem Streckeneditor erstellt... wie sollte es anders sein.

An dieser Stelle Dank an d-bug, der mir bei Pixmap-Formaten und dem PNG-Export geholfen hat.

Nachtrag (27.05.):
Die Minimap sieht nicht so schön aus, dass fiel einigen und mir ja auch schon auf. Da fehlt eindeutig AA. Gesagt, getan. Aber es war mal wieder ne schwierige Geburt und abermals muss ich mich bei d-bug bedanken, dass er mir das Brett vorm Kopf wegnahm. So sieht es nun aus, ihr könnt es ja mit dem obigen Bild vergleichen:

krach

D2006 — Mon, 25 May 2009 23:35:26 +0200

Solche Geräuche mache ich, wenn ich derzeit beim Testen in eine der neu implementierten Reifenmauer rase. Ich darf freudig berichten, dass diese nun eingebaut sind und damit der Stand von ChaosRacer 1 endgültig eingeholt wurde *freu*. Dazu ein Bild:

Drei-stufiges Kollisionssystem

Kollisionsprüfungen geschehen dreistufig. Das ist vorallem dazu da, um unnötigen Rechenaufwand zu sparen, den man braucht, wenn man mit Reifenmauern eine Kollisionsprüfung macht, die kilometerweit weg sind. Die erste Stufe ist - naheliegenderweise - das bereits vorhandene Sektorensystem. Es werden also nur die Objekte (können später noch mehr als nur Reifenmauern sein) auf Kollision geprüft, die im gleichen oder sehr nah angrenzenden Sektor sind wie unser Fahrzeug. Die zweite Stufe ist ein BoundingBox-System, welches man auch gut auf dem Screen erkennen kann. Die nicht-gedrehten Rechtecke um das Fahrzeug und die Reifenmauern sind automatisch errechnete BoundingBoxes. Ob zwei Rechtecke kollidieren, ist nur eine längere IF-Abfrage, also eine äußerst billige Berechnung, weshalb sich dieses System durchaus lohnt. Denn nur wenn die zwei BoundingBoxes überlappen - und das tun sie nur, wenn sich Fahrzeug und Objekt start nähern - wird noch genauer geprüft. (Anmerkung: im Bild ist die eine BoundingBox rot, weil sie halt gerade mit der BoundingBox des Fahrzeugs kollidiert) Und zwar in der dritten Stufe mit genauer Linienkollision. Dazu werden die abermals automatisch errechneten Linien nacheinander auf Kollision geprüft. Allerdings wird da noch mal aussondiert: Ist das Fahrzeug auf der falschen Seite der Kollisionslinie, wird die Kollision ignoriert. Das heißt, dass man jeweils nur von "außen" mit einer Reifenmauer kollidieren kann. Dann wird noch geschaut, ob sich das Fahrzeug gerade wegbewegt. Da dies eintritt, wenn bereits eine Kollision erfolgte, werden so Fehler vermieden.

Falls nun eine Kollision erfolgt, wird anhand einer sehr komplizierten Formen errechnet, welche Auswirkung dies auf die Fahrphysik unseres Autos hat. An dieser Stelle ein riiiieeeesiges Dankeschön an unseren Mathehelden Noobody, der die dazu nötigen Formeln ausspuckt, als hätte er sie damals, kurz nach seiner Geburt selbst entwickelt.

Übrigens: Wie schon mehrfach angedeutet, geschiet dies alles automatisch. Im Streckeneditor kann man nun einfach per Klicken neue Reifenmauern hinzufügen. Aber um Kollision muss man sich da einen Dreck scheren. Den Winkel einer Reifenmauer legt man mit dem Mausrad fest, dann einfach die Maus an die gewünschte Stelle bewegen und klicken. Wenn man Mauern entfernen will, einfach auf das Mülleimer-Symbol drücken und alle vorhandenen Reifenmauern bekommen ein kleines Rechteck, welches bei Klick die Entfernung auslöst.

Ich bedanke mich recht herzlich für die Aufmerksamkeit.

Psychedelisch...

D2006 — Sun, 10 May 2009 21:53:13 +0200

mag auf den ersten Blick folgendes Bild wirken:

Aber das ist auch nur eine Debug-Ansicht. Was sich dahinter verbirgt: Es ist eine Art Tilemap, die bestimmt, wo welcher Untergrund ist. Grün ist Gras, gelb Kies und rot offensichtlich die Straße. Das ganze wird automatisch berechnet und muss nirgends vorbereitet werden. Pro Tile stehen 8x8 Felder zur Verfügung. Dies mag zwar nich sehr genau wirken, es ist aber ein Kompromiss zwischen Speicher- und Rechenzeitverbrauch. Jedes Mal zu berechnen, welcher Untergrund gerade anliegt, wäre zu aufwendig. Und für jeden Pixel dies vorzuberechnen, wäre zu speicherintensiv und auch völlig unnötig. Nun wird es für 8x8 Pixel große Rechtecke berechnet. Wozu das ganze? In eine der nächsten Version wird von jedem Auto jedes Rad bei jedem Berechnungsdurchgang den Untergrund ermitteln und entsprechend die Bodenhaftung berechnen.

Startplätze

Nun kann man auch im Editor auswählen, von wo die einzelnen Teilnehmer denn ins Rennen starten. Hab jetzt (vorerst) festgelegt, dass bis zu 6 Gegner antreten werden. Auf den folgenden zwei Bildern sieht man einmal die Auswahl im Streckeneditor und dann die Auswirkung im Spiel. (Dem Spieler wurde offensichtlich der zweite Startplatz zugewiesen.)

Weitere Schritte

Bei vielen Punkten - zB der erste hier zulesende - hab ich den Vorgänger längst eingeholt. Um aber genau den letzten Stand zu erreichen, fällt noch ein entscheidendes Merkmal: Hindernisse und Kollision. Das wird also die nächste Aufgabe sein, die guten alten Reifenmauern wieder einzubauen, die zusammen mit der untergrundabhängigen Fahrphysik dem Abkürzen endgültig einen Strich durch die Rechnung macht.

Das war's erstmal, ich bedanke mich für die Aufmerksamkeit.

Im Kreis fahren...

D2006 — Sun, 03 May 2009 20:55:43 +0200

... ist nun möglich. Die Maps werden nun auch im Hauptspiel geladen. Da man nun seine Runden drehen kann, sollten selbige auch gezählt werden. Dafür muss aber das System wie im alten ChaosRacer herbei, dass dafür sorgt, dass man Runden nicht abkürzen kann. Weiterhin ist es nun möglich im Editor die Start- und Ziellinie festzulegen, sowie die Kollisionslinie, die zum konrekten Überfahren genutzt wird, anzupassen. Und als das dann funktionierte, war es ein leichtes nen Rundenzähler einzubauen und die bisherigen Rundenzeiten zu speichern.

Für das Beweisbild muss ich noch anmerken, dass ich das Rechteck mit einer nicht-finalen Autografik austauschte:

Tot geglaubte leben länger...

D2006 — Fri, 01 May 2009 23:04:05 +0200

Über die lange Sendepause verliere ich keine Worte, konzentriere mich lieber auf die schönen Dinge:

~Der Editor~
Der Streckeneditor hat die wichtigsten Funktionen und ist somit produktiv einsetzbar. Es ist der zweite Anlauf, nachdem ich vorher einen mit MaxGUI-Unterstützung bauen wollte und dieser Versuch ganz schnell meine Motivation auffraß.

~Sektoren~
Hier kann man die Sektorenkarte bearbeiten. Die Ausbreitung ist in jeder Richtung einstellbar, damit man die Karte nicht neusetzen muss, wenn man links oder oben mal fix mehr Platz braucht.

~Rennstrecke~
Dieser Teil brauchte extrem viel Mathe, aber es hat sich gelohnt. Die Strecke kann nun mit der Maus derart einfach und schnell zusammengeklickt werden, dass später sicher viele Rennstrecken für das Spiel verfügbar sein werden. Man kann mit dem Mauszeiger exakt zeigen, wohin das nächste Teilstück verlaufen soll. Ein Klick setzt es und das nächste Teilstück ist dran. Zum Schluss einfach die Maus auf den roten Punkt halten und das letzte Teilstück schließt die Strecke perfekt passend ab. Alles Dank Vektorrechnung und Bezierkurven kein Problem. Da ich bei der Umsetzung aber schon welche hatte, möchte ich an dieser Stelle Noobody, Hyde, BtbN und allen Vergessenen danken.

~Tiles~
Dieser Bereich hat mir Kopfschmerzen bereitet, die ich nie vermutet hätte, weil's eigentlich simpel ist. Man setzt entweder Gras- oder Kiestiles, wobei die Ränder automatisch angepasst werden ... sollten. Sie tun es, aber es gibt noch einige Probleme, die sich vermutlich nicht beseitigen werden lassen, so dass es am Ende mal "halbautomatisch" geschehen wird. Die Rennstrecke wird in diesem Modus sozusagen "wireframe" dargestellt, damit man nicht blind die Tiles setzen muss, weil man dank der Strecke nicht viel sieht oder dank fehlender Strecke gar nicht weiß, wo der Kies hin muss.

~Datei~
Hier lassen sich Strecken speichern und laden. Auch sieht man nochmal die kreierte Strecke in voller Pracht. Guter Zeitpunkt um darauf hinzuweisen, dass sich dieser sowie die zwei vorher beschriebenen Bereiche stufenlos von 2facher Vergrößerung bis 3facher Verkleinerung zoomen lassen.

Ich bedanke mich für die Aufmerksamkeit.

Von Tilemaps und DirectX

D2006 — Thu, 15 Jan 2009 10:42:38 +0100

DirectX

Es funktioniert zwar schon seit mehr als einer Woche, aber ich kann ja trotzdem freudig berichten, dass Dank der tollen Hilfe von BladeRunner das Spiel nun unter OGL und DirectX laufen wird! Damit ist also auch gewährleistet, dass ältere Hardware, welche allergisch auf OGL reagiert, mit dem ChaosRacer 2 zurechtkommen wird.

Tilemaps

Inzwischen sind die Konzepte zum Sektor-System ausgereift und ich hab schon mit der Umsetzung begonnen. Ein Sektor wird eine Kantenlänge von 512 Pixel haben. Jeder einzelne wird eine Tilemap der Größe 8x8 haben, wodurch sich *rechnerechnerechne* eine Tilegröße von 64x64 px² ergibt. Wobei die schon eher feststand, weil ich für den Anfang die alten Tiles aus dem Topdown Racer wiederverwenden werde. Da hab ich also schon Gras und Kies sowie die Übergänge dazwischen abgedeckt. (Bild aus dem alten Projekt mit den Tiles)

Tiles

Allerdings sind die einzelnen Tiles nicht alle in einer Datei, weil ich sowas leicht unflexibel und nervig finde, wenn man später Tiles austauscht. Deswegen hab ich mir Gedanken gemacht, wie man Tiles aus mehreren Dateien nutzbar machen kann. Die kleinen Bildchen werden im Spiel nun von einer Klasse verwaltet. Die sieht im Groben so aus:

Code: [AUSKLAPPEN]

Type TTiles
Field tiles:TImage[ 42 ]

Method load()
   'hier werden die Tiles geladen
End Method

Method getTile:TImage(index:int)
   Return tiles[ index ]
End Method

Global _instance:TTiles
Function getSelf:TTiles()
   Return _instance
End Function
Method New()
   _instance = Self
   load()
End Method
Function get:TImage(index:int)
   Return _instance.getTile(index)
End Function
End Type

Nun braucht es zu den Beginn des Spiels bei der Initialisierung einfach nur ein New TTiles und schon wird alles geladen. Beim Zeichnen der Tilemaps braucht's dann einfach nur noch ein DrawImage TTiles.get(tilenr), x, y. (Dieses Prinzip nennt sich übrigens Singleton) Aber wie geht es nun, dass jedes Tile eine eindeutige Nummer hat, egal aus welcher Datei sie kommt? Ich extrahiere einfach bei AnimImages die einzelnen Frames, sodass sie eigenstädige TImages sind. Das geht so:
Code: [AUSKLAPPEN]

frame = LoadImage( image.pixmaps[ i ] )

Wobei image das animierte Image ist und i für den Frame steht, den wir gerade haben wollen (an dieser Stelle Dank an Suco-X und DC für die Hilfe). Recht statisch und unflexibel sieht's dafür aber bisher in der load-Methode aus. Inwiefern dies später dynamischer wird oder gar Strecken eigenen Tilesets haben können, steht noch nicht fest.

So, dass waren erstmal die Einblicke in meine kleine Gedankenwelt,
ich bedanke mich für die Aufmerksamkeit.

Und es wurde hübscher...

D2006 — Sun, 04 Jan 2009 20:35:45 +0100

Heut gelang mir ohne große OGL-Kenntnisse das Umsetzen meiner Idee, genauso wie ich es mir vorstellte. *freu* Gleich ein Bild zum Beweis:

Die Straße wird nun fein texturiert gemalt und zwar nicht wie ursprünglich als Triangle sonder als Quad, aber das soll mir recht sein. Ob die Textur final bleibt ist zwar unwahrscheinlich, aber sie sieht für den Moment erstmal passabel aus.

Gedanken zum Speichern der Strecke

Unterdessen machte ich mir Gedanken, wie ich die Datenstruktur der Streckenteile am besten hinkrieg. Eine Tilemap fällt klarerweiser aus, da die Straße ja wie beabsichtigt kreuz und quer im jeden Winkel verlaufen wird. Trotzdem braucht es eine schnelle Methode, rauszukriegen, welche Teile der Straße denn gemalt werden müssen, da natürlich nicht alle immer gezeichnet werden können. Auch eine simple Liste reicht nicht, da man trotzdem immer beispielsweise 1000 Einträge durchiterieren muss, um 20 zu zeichnen.

Mein Plan ist es daher, die Strecke in Sektoren zu unterteilen, die ihrerseits jeweils eine festgelegte Kantenlänge haben und alle Streckenteile (später auch Hindernisse und sowas wie Reifenspuren) speichern, die sich in ihnen befinden. Ob ein Sektor gezeichnet werden muss, kann dann einfach ausgerechnet werden und man spart sich allerhand Arbeit. Wie effizient das ganze dann wirklich ist, hängt natürlich auch von besagter Kantenlänge ab. Die darf weder zu klein noch zu groß sein, aber ganz so entscheidend wird das nicht sein.

Das war mein Wort zum Sonntag,
ich bedanke mich für die Aufmerksamkeit.

1. Eintrag

D2006 — Sat, 03 Jan 2009 18:23:18 +0100

Hiermit möchte ich den Start eines neuen Projekts verkünden und den interessierten Teil der Community Einblicke in die Entwicklung eines Rennspiels gewähren. Vor Jahren hatte ich schon eins geschrieben, damals noch in BlitzPlus. Nun fang ich von Grund auf neu an und diesmal in BlitzMax, weshalb ich als Arbeitstitel für das Spiel "ChaosRacer 2" wählte.

Was ist geplant?
Im Grunde erstmal nicht viel. Das ist ein richtiges Hobbyprojekt, in welches ich bei Lust meine spärliche Zeit investieren will. Es ist nicht geplant, dass ein superduper Spiel draus wird. Geplant ist demnach, was ich umsetzen kann. Und wenn ich nun schon gern vollmundig einen Mehrspielermodus sowie eine superintelligente KI "mit dem Gehirn eines Planeten" versprechen würde, ist das wohl zu unrealistisch. Allerdings versuche ich so abgekapselt mit den tollen Boardmitteln von BMax zu programmieren, dass es später nicht allzu schwer fallen wird, es vielleicht doch noch einzubauen.

Grundlegendes
Das alte Projekt hieß nicht mal "ChaosRacer". Sondern nur "2D Topdown Racer" (der Thread sollte im Projekteforum noch auffindbar sein, allerdings sind keine Downloads mehr online. Mal sehen, vielleicht werde ich im Verlauf dieses Worklogs wieder was online stellen von dem alten Gerümpel.) Aber da war Name Programm und ähnlich will ich es wieder machen. 2D und aus der Vogelperspektive. Durch die schöne Hardwarebeschleunigung von BMax wird es somit von Haus aus schonmal schöner aussehen. Das Auto war damals ja doch arg pixelig, weil es mit RotateImage gedreht wurde.

Erste Fortschritte: Fahrphysik
Das Spiel wird eine völlig andere Physik haben als sein Vorgänger. Für jeden Reifen werden einzeln die Kräfte und Wechselwirkungen zum Fahrzeug berechnet. Das System dazu steht bereits und macht schon Spaß, allerdings wird es schwer sein ein brauchbares Balancing zu finden. Mal bricht der Wagen zu früh aus, mal fährt er um enge Kurven wie auf Schienen. Die Physik wird zwar allemal realistischer sein als vormals, aber damit der Spielspaß bestehen bleibt wird sie nicht 1:1 realitätsgetreu.

Der Workloganlass: Streckenführung
Da ich noch ein wenig mehr haben fertig haben wollte, ehe ich einen Worklog anfing, hab ich erstmal weiter überlegt und heute angefangen die Datenstruktur für die Streckenführung auszuarbeiten. Im Vorgänger gab es auch schon freie Streckenführung, aber zu einem hohen Preis: die Straßen-"tiles" wurde einfach gedreht auf ein großes Image gemalt, dieses wurde dann gekachelt und diese Tiles dann immer gezeichnet. Das war zwar schnell, verbrauchte aber viel Speicherplatz und war somit arg ineffizient. Das neue System wird sich der sowieso schon benötigten 3D-Beschleunigung bedienen. Die Strecke wird aus Polygonen bestehen, welche dann texturiert werden. Das ist aber noch insofern Zukunftsmusik, als dass ich dafür noch eine BMax-Lösung suche, die das auch kann (sowohl für OGL als auch für DX).

Beweisbild

Hier sieht man halt ein Fahrzeug mit seinen vier Reifen, von welche die beiden vorderen stark lenken. Die Strecke wird hier quasi als "Wireframe" angezeigt. Sichtbar sind also die einzelnen Polygone. Später werde ich vermutlich optimieren, dass gerade Strecken weniger Polygone brauchen.

Das war's erstmal zur Stunde,
vielen Dank für die Aufmerksamkeit!