JLI Spieleprogrammierung

[DirectXer]

[User_User]

DirectXer hat geschrieben:

[DirectXer]

[Hazel]

[Hazel]

@Jonathan_Klein: Ich habe mir deinen Post vom Anfang nochmal durch den Kopf gehen lassen.

Dein Hauptproblem ist anscheinend, dass du Probleme bekommst bestimmte Werte zu teilen, bzw. in der Ableitungshierarchie nach unten zu geben.

Was hälst du von folgendem Vorschlag: Anstatt mit vielen Ableitungen zu arbeiten, definiere dein SceneObject, bzw WorldObject als eine Art leere Kapsel.. eine leere Entität. Um ihr Leben einzuhauchen kannst du dann aus verschiedenen Bestandteilen wählen, und sie dort hineinstecken. Wie du dein Problem damit lösen kannst?

Nehmen wir an, du hast eine Klasse Scavanger.. diese fiesen Schnabeldinger. Ein Scavanger ist eindeutig ein fester, "anfassbarer" Bestandteil deiner Welt, also könntest du ihm die Komponente AvatarComponent geben. Diese verwaltet die Darstellung des Monsters in der Welt... Attribute wären Model/Animationen, BoundingBox und natürlich Position und Geschwindigkeitsvektor. Neben dieser AvatarComponente wird er vermutlich auch eine AIComponent besitzen, die vielleicht einen einfachen endlichen Automaten implementiert, da Scavanger vermutlich nicht sonderlich schlau sind. Damit die KI jedoch korrekt funktionieren kann wird sie sicherlich auch wissen wollen, wo sich der Scavanger befindet. Diese Informationen befindet sich jedoch in der AvatarComponent. Problem...
Um dies Lösen zu können, braucht jede Komponente einen Zeiger auf ihren Besitzer.. nun kann die Komponente ihren Besitzer fragen "Hey, hast du zufällig eine AvatarComponent?". Falls ja, prima, falls nein kannst du einfach eine Warnung ausgeben, dass AIComponent ohne AvatarComponent nicht arbeiten kann.

Ein großer Vorteil ist, dass du dich nicht in großen Ableitungsbäumen verstrickst.

Ein weiterer Vorteil dieses Modells ist, dass du später im Level Editor einfach neue Objekt-Typen zusammenwürfeln kannst. Man könnte den Komponenten auch noch Parameter geben, die man im Editor oder per XML konfigurieren kann... :)

Naja, hoffe das Hilft vielleicht dabei eine andere Herangehensweise an dein Problem zu finden... eine mit der man weiter kommt und das Spiel fertig kriegt! ;) Nix ist frustrierender als sich am Anfang gleich über Softwarearchitektur den Kopf zu zerbrechen und den eigenelichen Sinn des Spiels -> Spaß!, aus den Augen zu verlieren. :)

Gruß,
Ollie
_________________
*click* Dabuu!?
Twitter: http://twitter.com/Ollie_R

[Hazel]

Anscheinend keine gute Idee für dich? ;)
_________________
*click* Dabuu!?
Twitter: http://twitter.com/Ollie_R

[Fallen]

Viel zu viel Text und viel zu wenig Bilder über Bienchen und Blümchen du Schuft!

Ich finde die Idee gar nicht mal so übel, der einzige Nachteil den ich nun noch sehe ist das man Objekte ohne eine ID nur schwer voneinander zu unterscheiden kann (muss allerdings Nichtmal gewollt sein).

Ebenso könnte es problematisch sein das man für zusätzliches verhalten eine neue Komponente schreiben muss (dies hat wiederum den Vorteil das man so eine höhere Vielfalt erreichen kann).

Btw zum Thema HL-Code: Sobald Hacks angewendet werden ist der Spass vorbei und Makros an unnötigen Stellen verschlechtert die Wartbarkeit sowie den eigenen Codestil, ansonsten hast du schon recht, verachten sollte man die Nachteile dennoch nicht

[DirectXer]

[Hazel]

Kommt halt drauf an wie man Makros einsetzt... die sind immerhin ein Bestandteil der Sprache. :) Bei der Entwicklung von PlugIns sind sie mir damals sehr zugute gekommen.

Und zu HL..da muss ich dich korrigieren, das ist eindeutig C++. Der Code wurde damals von Quake( -> C ) nach C++ portiert.

Beispiel: http://hosted.planethalflife.gamespy.com/fixxxer/hltuts/hl_weap1.htm
_________________
*click* Dabuu!?
Twitter: http://twitter.com/Ollie_R

[Hazel]

[DirectXer]