Spiel - Für jeden Angriff eigene Klasse?

Terrenay · Hält's aus hier Beiträge: 15

Hallo, ich programmiere schon seit bald 3 Monaten ein Rollenspiel mit XNA und bin auch schon ziemlich weit. Jetzt geht es mir aber langsam um die Frage, wie ich Angriffe genau verwalte. Bis jetzt kann ich zwar alle möglichen Angriffe mit einer Zeile Code implementieren, die sind schlussendlich jedoch alle irgendwie gleich: Es erscheint ein Bullet, der sich auf die Maus zubewegt, und wenn er trifft, explodiert er und schadet dem Gegner. Ich will aber auch Angriffe wie "Erschaffe Bereich, in dem die Zeit stillsteht und wo sich bestimmte Monster nicht mehr bewegen" oder "Teleportiere den Spieler da und da hin". Ich hab das jetzt so im Kopf dass ich eine Basisklasse Spell habe, die Cooldown oder Casting-Time speichert. Davon erben könnten dann Klassen wie zB "Feuerball" oder "AoE" oder "DoT". Also halt Gruppen von Angriffen, die alle ähnlich aufgebaut sind. Dann könnte ich sowas wie

markieren

C#-Quelltext

1:	SpellList.Add(new AoE("Name", Effektradius, Schaden, Schadensdauer, Animation));

Würdet ihr das auch so lösen oder sollte ich es noch weiter verfeinern, also dass jeder EINZELNE Zauberspruch/Angriff eine eigene Klasse hat? Das wär glaub ich zu übertrieben. Vor allem würde es wahrscheinlich auch die Performance killen, oder nicht?

lg und Sorry für die vielleicht seltsame Frage :)

Moderiert von Th69: Topic aus C# - Die Sprache verschoben am Do 22.05.2014 um 18:41

Th69 · Verfasst: Fr 23.05.14 18:23

Hallo,

deine Frage ist aus der Ferne nicht einfach zu beantworten.
Für ein kleines Spiel ist die Vorgehensweise mit einer hierarchischen Vererbung wohl noch umsetzbar, jedoch hat diese ihre Grenzen. Du mußt ja bei jeder neuen Angriffsart statisch entscheiden, von welcher sie erbt, d.h. wenn du beispielsweise einen Flächenfeuerball entwickeln möchtest: ist das nun ein Feuerball oder ein AoE-Angriff? Da es in C# (im Gegensatz zu C++) keine Mehrfachvererbung geht, könntest du es aber mit Interfaces umgehen - bedeutet aber auch einen höheren Aufwand.

Viele moderne Spiele setzen daher auf das komponentenbasierte Design (component based game design), so daß eine Entität intern eine Liste von "Komponenten" (ich selber benutze dafür lieber den Begriff "Funktionalitäten") hält (so daß diese dann auch dynamisch wechseln kann bzw. über eine Konfiguration festgelegt werden kann).

Und gerade für Spells oder Angriffe mit erweiterter Funktionalität - so wie du sie beschreibst - kommt es ja auch auf die Benutzung an (d.h. irgendwo im Programm müssen ja dann bestimmte Abfragen vorgenommen werden). Du müßtest m.E. dann auch so etwas wie Schadensarten (bzw. ganz allgemein: Aktionsarten) definieren, die dann abgefragt werden (anstatt auf konkrete Spells bzw. Angriffe zu testen).

Das beste wird wohl sein, du versuchst mal einige unterschiedliche Spells auszuprogrammieren, um dann per Refactoring zu schauen, wie du den Code allgemeingültiger machen kannst (also so daß relativ einfach weitere Angriffsarten hinzugefügt werden können).

IhopeonlyReader · Beiträge: 600 Erhaltene Danke: 23 Delphi 7 PE

ich hatte es in einem towerdefense spiel mit den towern ähnlich...

ich hatte eine klassse TTower und in ihr war ALLES gespeichert
z.B:
Range, Dmg, Splash (Boolean), Aoe, Schussgeschwindigkeit, Dauerschaden, Dauerschadendauer, Dauerschadenschaden....

anschließend bin ich die Liste der Tower durchgegangen, habe geschaut welche mobs anzugreifen sind (range), bin dann mob für mob durchgegangne und habe dann sowas hier gemacht

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:

//for schleife in der alle mobs durchgegangen werden
begin
derMob.Hp := derMob.HP - Dmg;
if derTower.Dauerschaden then
 begin
 dermob.dauerschaden := derTower.Dauerschadenschaden;
 dermob.dauerschadendauer := derTower.dauerschadendauer;
 end;

//der ganze rest..
if derTower.splash then
 //gehe zum mob vor/hinter dem aktuellen mob
 //greife ihn mit (1-Range/Gesamtrange)*Dmg

//mit aoe so ähnlich,,
end;

ich hatte also eine klasse mit vielen vielen variablen !
ein neuer tower war relativ einfach, ich musste auf seinem create button nur alle parameter angeben.
eine neue fähigkeit war sehr aufwendig ! (z.B. gift oder slow) da man in der procedure immer an der richtigen stelle etwas neues schreiben musste...
die update routinen waren nnicht pro tower sondern vom startpreis und lv abhängig.. somit konnte ich mir da einiges ersparen, wie aber welcher tower die werte erhöht bekommt war ebenso mehr aufwand...
eine eigene klasse hätte den vorteil, dass man immer die selben proceduren hätte (also abstrakt gestaltet) und einen neuen tower einfach eine neue klasse erstellt die dann diese procedure aufruft -> übersichtlichkeit und einfacher.. aber für den ersten Turm mehr arbeit!

_________________
Sucht "neueres" Delphi

Wer nicht brauch was er hat, brauch auch nicht was er nicht hat!

Terrenay · Hält's aus hier Beiträge: 15

@Th69: Das heisst, ich werde es wohl mal so ähnlich probieren, wie ich es vorgeschlagen habe

@IhopeonlyReader: So hab ich das bei einem gaanz alten Spiel von mir (5 Monate xD) mal gemacht, aber ich mag das Prinzip einfach nicht.. zu unübersichtlich, finde ich. In meinem eigenen Tower-Defense-Spiel hab ichs dann trotzdem auch wieder so gemacht, aber ich fand es nicht gerade der Hit

IhopeonlyReader · Beiträge: 600 Erhaltene Danke: 23 Delphi 7 PE

sonst ganz allgemein immer eine neue klasse anlegen... aber dann wirds mit dauerschaden etc schwer...

_________________
Sucht "neueres" Delphi

Wer nicht brauch was er hat, brauch auch nicht was er nicht hat!

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme