Hallo,

Ich programmier gerade eine kleine 3D-Engine, die ich vielleicht irgendwann in ferner Zukunft als Basis für einen kleinen Shooter benutzen will.
Ich habe mir schon eine Kamera Klasse geschrieben und wollte jetzt das Level aus einer Bitmap laden. Das Level soll aus einfachen Gängen und Räumen bestehen.
Ich bin mir nur noch nicht sicher, wie ich die Koordinaten der Wände für die Kollision mit der Kamera speichern soll, also ob ich ein Objekt für jeden Wandabschnitt erzeugen soll, oder ob ich einfach nur ein Array benutzen soll.
Außerdem bin ich mir nicht ganz sicher ob ich die Kollision in der Kamera Klasse oder in der Unit des Formulars behandeln soll.

Was würdet ihr mir raten?

In jedem Fall kleiner anzufangen. Von all den propangierten 3D-Shootern, habe ich bisweilen keinen einzigen gesehen. Auch macht es keinen Sinn den Grundstock einer Engine zu legen ohne das man weiß, wie man diese strukturiert. Am Ende wird stets eine unflexibele Masse heraus kommen, die letztendlich etwas für den Papierkorb ist. Von daher würde ich empfehlen ein Projekt anzustreben, was übersichtlicher ist. Ein Pacman mit 3D-Wänden von schräge oben würde wichtige Grundlagen enthalten ohne das man zu komplexe Mathematik begegnet. Meist kommen die Leute bei Ihrem Shooter nicht über die Kamera hinaus und scheitern bereits daran ein Objekt auf ein anderes auszurichten...

Die Kollision in die Kamera zu implementieren macht entsprechend keinen Sinn. Zumindest wird die Mehrzahl an Situationen wohl auch eine Kollision ohne Spieler vorsehen. Müßten etwaige Gegner nicht auch eine Kollision erfahren? Vermutlich ist es besser eine solche Überprüfung vor der Berechnung einer Bewegung durchzuführen und dort dann auch zu entscheiden, ob diese überhaupt für das Objekt durchgeführt werden muss (weg frei) oder diese durch ein Hinderniss nicht möglich ist. Die Art, wie die Kollisionsinformationen organisiert sind hängt davon ab, wie Du es realisieren willst. Ist die Welt rechteckig befinden sich alle nötigen Informationen bereits in den Geometrydaten, die Du zum rendern brauchst. BoundingBoxes und BoundingSpheres würden Sinn bei den entsprechenden Figuren machen.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Joa, kleiner anfangen wäre nicht schlecht, Pacman hört sich ganz gut an, aber dieses Thema reizt mich doch zu sehr.

Ich programmier immer einfach drauf los bis das Programm fast fertig ist, dann weis ich erst wie ich es strukturieren will und mach es noch mal neu (Ich weiß: sinnlos).

Ich hab mir jetzt nochmal gedanken gemacht über die Wände. Wenn ich für jeden Wandabschnitt ein Objekt nehmen würde, säh das ungefähr so aus:

Warum leitest du das Objekt eigentlich von TComponent ab? Bitte versteh das nicht falsch aber ich denke du solltest dich vorher erst einmal ein bisschen mit Object Orientierter Programmierung beschäftigen. Das ist nicht böse gemeint nur es macht auf mich den Eindruck, dass du die Vorzüge von OOP nicht kennst. Vieles lern man auch erst, wenn man beruflich programmiert.

Da ich aber auch mehr als "meckern" kann hier mal ein Vorschlag wie ich das machen würde. Das bitte nur als grobe Idee ansehen. Es ist ziemlich auf das Spielprinzip des Pacmans bezogen und viele Sachen fehlen noch.

Alle grafischen Objekte des Spieles wären von einem Basisobjekt abgelitten. Dieses hätte eine Virtuelle methode Draw und property die ein Boundbox (Maximale Größe) darstellen würde. Plus alle möglichen Eigenschaften die benötigt werden würden. Von diesem Objekt wären dann zum Beispiel die Wände, die Monster und die Items abgelitten.

Diese Objekte würden in einer Weltklasse verwaltet werden. Dafür denke ich wäre eine Art Quadtree ganz nützlich. Evtl auch eine Kombination aus vollständiger Liste und Quadtree. Dieses Objekt könnte dann noch die Kamera benutzen.

Je nach Kamera kannst du dann mittels Quadtree entscheiden welche Objekte sichtbar sind und welche nicht. Wichtige Geschwindgkeitsoptimierung. Und bei dem Weltobjekt hättest du denn auch wiederrum eine Methode Draw mit der du die Welt zeichnen könntest.



Das Prinzip ist folgendes. Alle sich in der Welt befindlichen Objekte stammen von TWorldEntry ab. Wenn TWorldEntry alles nötige als Methoden oder Eigenschaften zur Verfügung stellt, dann braucht TWorld gar nicht mehr wissen um was es sich dabei nun handelt. Es kann alles als WorldEntry ansprechen. Was die im Hintergrund machen ist primär erst einmal egal. Wichtig ist nur, dass du darauf achtest, dass jedes Objekt nur die Sachen erledigt die für es wichtig sind. Also in TWord darfst du nicht hergehen und eine Wand zeichnen. Das müssen alles die einzelnen Objekte erledigen.

PS: Falls dich der Quadtree verwirrt kannst du den auch erst einmal weglasen. Pacman wird ja generell nur von Oben gespielt, da wird eh immer alles gezeichnet.

PPS: Ich hoffe das war jetzt nicht zu viel für dich? Aber ein Tutorial würde ich dir dennoch mal ans Herz legen.

Man kann auch als Ausgangsbasis die Spriteengine von DelphiX verwenden und für seine eigenen Bedürfnisse umschreiben. So habe ich das bei meinem Projekt gemacht, allerdings ist das von der Spielmechanik nur sehr schwach 3D.
Kann auch gerne den Source von meiner Variante veröffentlichen, weiß aber nicht ob du damit viel anfangen kannst. (Verwendet keine DelphiX/DirectX Units)

Davon würde ich wiederrum abraten DelphiX hat seine besten Tage bereits seit vielen Jahren überschritten und ist eine absolute Dead-End-Technologie, da man dort gesammeltes Wissen nur sehr begrenzt weiter verwenden kann. Das Lernen einer aktuellen Schnittstelle DirectGraphics, OpenGL oder SDL werden langfristig eine bessere Lösung sein. Nichts desto trotz ist die Grafikprogrammierung im allgemeinen nur dann sinnvoll zu betreiben, wenn die entsprechenden Grundlagen gefestigt vorhanden sind. Ansonsten wird man sehr schnell viele frustrierende Erfahrungen machen. Als Einstieg eignet sich ein kleineres Projekt, dass leichter überschaubar ist. Es gibt im Netz einen freien 3D-Shooter namens (Cube bzw. Sauberbraten). Es handelt sich dabei um eine sehr kompakte flinke Engine. Wer den Source Code kurz überfliegt, wird schnell vom Vorhaben abkommen eine Shooter schreiben zu wollen...

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Ich sprach hier ausschließich von der Spriteengine, die in meiner abgespeckten Form nur die Verwaltung der Objekte übernimmt, aber an keine API oder an DelphiX gebunden ist.
Der Grafische Teil von DelphiX ist natürlich veraltet, kann aber imo bei kleineren 2D Projekten immernoch verwendet werden. Der 3D Teil von DelphiX ist dagegen unbrauchbar. Die sonstigen Kapselungen wie Sound und Netztwerk sind ganz ok, wenn man keine moderneren Features (3D-Sound etc) benötigt.

Außerdem ist ein kleiner Egoshooter durchaus machbar, wenn man sich an den richtigen Stellen einschränkt. Das sind insbesondere der Netzwerkcode und die Physik.
Die Physik würde ich durchs Levelformat vereinfachen: Das Level besteht aus 2 Highmaps, wovon eines die Decke und eines den Boden bildet, wodurch man sehr leicht feststellen kann ob sich ein Charakter in bestimmte Richtungen bewegen kann, und wie weiter er fällt sowie wie hoch er springen kann.

Den Netzwerkcode kann durch beschränkung auf LAN sehr stark vereinfachen, da man sich dann wenig Sorgen um Ping und Datenmengen machen muss, und den Clients mehr Verantwortung übertragen kann, in der Hoffnung dass die Mitspieler nicht cheaten (z.B. jeder Spieler bewegt seine Figur selbst und sendet den anderen seine Aktuelle Position,Richtung,Aktion etc und schickt direkte Befehle wie ErstelleSchuss(Typ,Position,Richtung,Zeit) an die Mitspieler.

Erst mal danke für die Antworten

Ich hab TWand von TComponent abgeleitet, weil ich noch keinen konkreten Plan hatte, was in mein BasisObjekt alles rein sollte (weiß ich ja jetzt ), und ich es in der Componentsliste haben wollte. Aber ich werde mal nach einem tutorial zu diesem Thema suchen, denn das mit der Worldklasse und so ist dann doch irgendwie praktisch...

Sauberbraten ist auch ziehmlich komplex. Ich möchte nur was ganz einfaches machen (erstmal eine Welt auf einer Ebene, mit Gegnern, die in den Ecken stehen und auf mich schießen, oder so. Netzwerk wollte ich eh rauslassen und die Physik ist auf einer Ebene nicht gerade schwer).

@delphix: In meiner Gegenwart ist DelphiX pfuipfui Ich habe selbst damit angefangen zu lernen und es liegt viele Monde zurück. Zwar hat sich mit UnDelphiX einiges zum besseren gewandt (die ursprüngliche Implementation von Hori war fehlerhaft bis zum...), aber die Technik selbst ist schlichtweg veraltet. Wenn man es kann... okay. Aber jemanden dies zu lernen empfehlen ist nicht gut. Dann lieber direkt die Header von DirectX verwenden, die sind fast genauso leicht zu implementieren.

Okay, dann liegt auch vielleicht ein Mißverständnis vor. Bei Shooter wird es normalerweise ein Doom667, wenn Du einen Plattformshooter meinst, ist das schon ein ganz anderes Kaliber. Mit nur eine Bewegungsebene kann man nämlich fast alles mit Schulmathematik lösen. Dennoch: Mache eine vernünftige Planung und nehme Dir anfänglich etwas kleines vor (ggf. Milestones). Immer dann, wenn Du nicht weißt, wie Du ein Ziel erreichen sollst, hast Du bereits zu hoch angesetzt, weil es immer wieder Probleme gibt, die man gar nicht bedenkt.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Download:
http://thewinner.th.funpic.de/maelstrom/spriteengine.zip
Verwendung:
eine Instantz von TSpriteengine erzeugen:

Objekte von TSprite ableiten und virtuelle Methoden überschreiben(müssen nicht alle überschrieben werden):

Neue Obekte z.B.so erstellen:

Im Loop dann ca. folgendes ausführen:

Erinnert mich irgendwie an den Zweiten Teil vom Tutorial_quickstart.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Beziehst du dich auf die Frameraten-unabhängige Programmierung oder auf zu große Projekte?
Durch passende Einschränkungen lässt sich so ein Shooter relativ schnell erstellen. (Er will ja auch auf Netzwerk verzichten und sich auf eine Ebene beschränken)

Was die Framerate-Unabhängigkeit angeht war diese in der ursprünglichen Engine enthalten, wurde von mir aber entfernt, da ich sie bei meinem aktuellen Projekt nicht verwenden kann. Es sollte aber kein Problem sein Move und DoMove um einen Parameter für die Zeitdifferenz zu ergänzen (Ich würde die Zeit in Sekunden als Single übergeben und beim Aufruf im Loop die maximale Zeitdifferenz auf 100ms=0.1 begrenzen)

@Phobeus: Das immer ungeahnte Probleme auftauchen musste ich schon oft erfahren..., deßhalb weiß ich deinen Rat zu schätzen

@Flash: Naja, möglicherweise, aber falls ich eine erste funktionierende Version fertig haben sollte, werde ich sie mal hochladen (Wird aber wenn überhaupt lange dauern), und ich weiß, dass das trotz der Einschränkungen noch ne heikle Angelegenheit ist.

@The-Winner: Ich wollte alles Frameraten unabhängig laufen lassen, ergänzen wäre auch kein Thema. Dasmit deiner Engine hört sich auch ganz gut an, werde sie mir auch mal genauer anschauen, aber "eventlog.dcu" konnte nicht gefunden werden. Ich habe mich jetzt auch noch nicht näher damit beschäftigt, deßhalb weiß ich nicht ob die wichtig ist oder so. Könntest du sie noch hochladen?

-steve

Kannst du einfach entfernen, wird in der unit nicht verwendet.
In SpriteEngine.pas "uses main;" entfernen und die Verweise auf "PositionInCode" ebenfalls.
Die functions_util.pas musst du wohl auch nen bisschen anpassen, die enthält auch noch mein Übersetzungssystem und mein Pseudo-VFS (Virtuelles Datei System). Der LoadLanguage('DE') aufruf dürfte bei dir z.B. nen Fehler wegen fehlender Sprechdatei erzeugen. also einfach auskommentieren.

Die zusätzlichen Methoden in TSprite sind hauptsächlich auf 2D ausgelegt, könnten bei deinem Projekt aber trotzem nützlich sein
Kannst dir die neue Version herunterladen (selbe Url), da sind die wichtigen Methoden/Eigenschaften mit einem kurzen Kommentar versehen

OK, dann werd ich mich mal ranschmeißen. thx!