Spieler- und Animation-Klasse

D.J.

Hey,
ich habe angefangen ein 2D-spiel zu programmieren.
Bis jetzt habe ich die "Animation-Klasse" geschrieben, die einwandfrei funktioniert.

Nun wollte ich als nächstes die Klasse für den Spieler machen.
Der hat Eigenschaften wie Lebenspunkte,... und eine Animation.
Diese wollte ich durch vererben der "Animation-Klasse" hinzufügen.
(zumindest glaube ich, dass das so funktioniert)

Konstruktor der Animation-Klasse:
public Animation(ContentManager Content, string asset, float frameSpeed, int numFrames, bool looping, SpriteEffects Effect, Vector2 Standort)
        {
            this.frameTime = frameSpeed;
            this.numFrames = numFrames;
            this.looping = looping;
            this.Effect = Effect;
            this.animation = Content.Load<Texture2D>(asset);
            frameWidht = (animation.Width / numFrames);
            frameHeight = (animation.Height);
            this.position = Standort;
        }

Spieler-Klasse:
public class Spieler : Animation
    {

        public Spieler() : base(??Content??, "...", 90f, 1, true, SpriteEffects.None, new Vector2(200,200))
        {

        }

    }

Das Problem ist jetzt, dass ich für "Content" nichts eingeben kann,
denn soweit ich weiß ist der Manager nur in der Game.cs verwendbar.

Meine Frage ist nun, was ich falsche mache bzw. ist das überhaupt richtig wie ich das ganze angehe.

Danke

Th69

Komplett falsches Design! Ein Spieler ist doch keine Animation, also ist öffentliche Vererbung hier falsch.
Du schreibst ja selbst "Der [Spieler] hat ... eine Animation", also sollte Animation ein Member der Klasse Spieler sein. Auf der anderen Seite sollten aber die logischen Eigenschafen eines Spielers (wie Name, Lebenspunkte, ...) in einer eigenen Modell-Klasse abgebildet sein (und nicht in einer GUI-Klasse).

Wie sieht denn dein Klassenmodell generell aus?

D.J.

Ich soll also Animation des Spielers und sowas wie Eigenschaften und Attribute trennen?

Wie sieht denn dein Klassenmodell generell aus?

Meinst du das Klassenmodell der Animation?

Lupo4u2

Ja, das solltest du machen.
Stell dir mal vor, du hast für deinen Charakter mehrere Animationen, wie z.b. bei einem Adventure - eine 'gehen' bewegung, 'reden', 'nehmen', etc...
dann bekommst du probleme, die alle irgendwie in deiner Spieler Klasse mit aufzunehmen.

Dein Spieler muss ja nur die aktuelle Animation kennen und wissen ob sie abgespielt werden soll oder nicht.
Dein 'Animations-Manager' kümmert sich dann darum, die Animation deines Spielers entsprechend der Situation zu ändern.

Ist das verständlich?
P.S. hängt natürlich von deinem Spiel ab, wie umfangreich du das programmieren möchtest.

D.J.

Ja, das solltest du machen.
Stell dir mal vor, du hast für deinen Charakter mehrere Animationen, wie z.b. bei einem Adventure - eine 'gehen' bewegung, 'reden', 'nehmen', etc...
dann bekommst du probleme, die alle irgendwie in deiner Spieler Klasse mit aufzunehmen.

Dein Spieler muss ja nur die aktuelle Animation kennen und wissen ob sie abgespielt werden soll oder nicht.
Dein 'Animations-Manager' kümmert sich dann darum, die Animation deines Spielers entsprechend der Situation zu ändern.

Ist das verständlich?

Ja, Vielen Dank

Wie ist das denn, wenn ich, wie in meinem Fall mehrere Gegner "spawnen" lassen will.
Kann man ein Sprite als Array machen?

Lupo4u2

ich glaube dein Ansatz ist falsch.
Du machst nicht ein Sprite als Array, sondern brauchst am Ende ein Array aus Gegnern*...

* ein Gegner besteht sicherlich nicht nur aus einem Sprite, oder?

Ich würde dir empfehlen, nochmal über deinen generellen Aufbau des Spiels (Klassenmodel) nachzudenken, weil es sonst später sein kann, das du vieles nochmal umbauen musst, damit es vernünftig funktioniert.

hier ein Thread, der interessant für dich sein könnte:
http://www.c-plusplus.net/forum/273015-full

P.S. was für ein Spiel soll es denn werden? was können deine Gegner und was kann dein Spieler?

D.J.

ein Gegner besteht sicherlich nicht nur aus einem Sprite, oder?

Nein, natürlich nicht.
Die Eigenschaften der Gegner deklariere ich ja in einer Klasse.
Das sollte soweit kein Problem sein. Aber irgendwie muss ich den Gegner ja dann darstellen.

hier ein Thread, der interessant für dich sein könnte:
http://www.c-plusplus.net/forum/273015-full

Ich schaus mir mal an, Danke

P.S. was für ein Spiel soll es denn werden? was können deine Gegner und was kann dein Spieler?

Ein Spiel, bei dem ich von oben auf meinen Spieler schaue (top down) und um mich rum irgendwelche Gegner spawnen, z.b. Zombies oder Monster, die sollen den Spieler einfach nur verfolgen im und dieser kann sie abschießen.

Ich möchte für den Anfang aber erstmal hinbekommen, dass Spieler und Gegner vernünftig laufen und erscheinen.

TGGC

Ein sehr allgemeiner Ansatz kann sein, das ein Gameobject einfach nur ein Container ist, der eine Liste mit Eigenschaften verwaltet. Bei deinem Zombiespiel kann so eine Eigenschaft z.b. die Position auf der Map, die Grafik, der Kollisionsbereich, der Zustand der KI, die Hitpoints etc sein. Daraus kann man sich dann verschiedene Sachen zusammenbauen.

Zum Beispiel ein unzerstoerbares Haus hat nur eine Position, eine Grafik und einen Kollisionsbereich, waehrend ein Zombie die andere Sachen auch noch hat. Man brauch dann noch einen Moeglichkeit, wie diese Eigenschaften miteinander kommunizieren koennen, wenn z.b. die KI die Position veraendern will.

Ein Ansatz dazu ist Nachrichten zu verschinken, die dann von einem Manager immer an die passenden Eigenschaften weitergeleitet werden. Z.b. einen Positionsaenderung wird in der Liste der Eigenschaften nach allen gesucht, die das interessiert und weitergeleitet.

Der andere Ansatz ist, das eine Eigenschaft ihren Vater (das Gameobject) geziehlt nach einer anderen Eigenschaft fragen kann und diese dann bedient. Also die K.I. wuerde dann bei Gameobject nach der Positionseigenschaft nachfragen und wenn diese existiert die Position wie gewuenscht veraendern. Der Vorteil ist hier, alles passiert viel direkter und damit auch schneller, was aber durch physische Kopplung der Eigenschaften erkauft wird. Die K.I. Eigenschaft koennte z.b. kaputt gehen, wenn du an der Position was aenderst.