Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Verschiedene Typen von Objekten bzw. Gegnern

  • 1
  • 2

Werbeanzeige

Noxum

Frischling

  • »Noxum« ist der Autor dieses Themas

Beiträge: 35

  • Private Nachricht senden

1

18.08.2013, 15:37

Verschiedene Typen von Objekten bzw. Gegnern

Moin moin,

bin gerade noch ein wenig in der Planungsphase für ein einfaches 2D Game und bin nun auf eine Frage gestoßen welche ich mir sonst noch nicht gestellt habe.

Und zwar geht es um folgendes: In dem Spiel soll es verschiedene Typen von Gegnern bzw. Objekten geben, mit verschiedenen Bewegungs- und Aktionsmustern. Nun ist das Problem, wie implementier ich dies am besten bezüglich der Editierbarkeit und Codemenge ?

Ich hab jetzt erstmal 2 verschiedene Möglichkeiten im Sinn.
1) Ich schreib eine Klasse welche Gegner allgemein beschreibt (Sprite,Position, Move() etc.) und erstelle dann für jedenen neuen Gegnertyp eine Unterklasse welche die allgemeine Gegnerdefinition erweitert.

2) Eine Klasse welche alle Gegner mit deren Logik etc. beinhaltet und mittels Switch/Case die entsprechend richtigen Aktionen ausführt.
Bsp: Ich erzeuge einen Gegner und übergebe dabei den Typ: Gegner g1= new Gegner(GegnerType.Boot); und wenn ich dann für g1 eine Funktion aufrufe, wie zum Beispiel shoot(), dann wird in shoot() mittels switch(GegnerType.Boot)
der Code für das Schießen eines Bootes ausgeführt.

Allerdings sehe ich bei beiden Varianten Probleme, bei 1) habe ich eine gute Übersicht über alle Gegner und Fehler können schnell gefunden werden, allerdings habe ich unmengen an Klassen und oft auch doppelten Code.
2) Ist Zwar von aussen gesehen übersichtlich aber extrem Fehleranfällig und innerhalb der Klasse furchtbar überladen.


Wie macht man es denn am besten ? Ich mein Rollenspiele haben ja auch unmegen an unterschiedlichen Typen, die werden ja auch nicht für jeden eine eigene Klasse geschrieben haben.
Habe mich auch schon ein wenig durch "component based entity systems" durchgelesen, weiß aber nicht ob das die Lösung ist. Habe auch hier im Forum schon eine ähnliche Frage gefunden, allerdings wurde diese dort nicht konkret beantwortet.

Wie managed ihr denn diese Aufgabe ?


Grüße,
Noxum
Why so serious ?

DeKugelschieber

Community-Fossil

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

2

18.08.2013, 17:59

Ich würde eine Klasse für renderbare Objekte (Sprite, Position, Größe, blabla) anlegen, davon dann Gegner ableiten und für jeden Gegner eine Klasse erstellen.
Was bringt OOP wenn man dann am Ende doch keine "realen" Dinge nimmt und sie als Objekt darstellt?
Für die anderen Objekte hängt es natürlich etwas davon ab was sie können sollen. Du kannst statische Elemente haben, Items die man aufheben kann, Objekte die sich bewegen usw. Aber da macht es auch Sinn eine gemeinsame Basis zu haben (die renderbare-Objekt-Klasse ist in meiner Vorstellung sowieso Basis für alles), Bewegungsmethoden oder ob man das Objekt aufheben kann oder nicht lässt sich ja gut in einer einzigen Klasse lösen (wenn sich das Objekt nicht bewegen kann wird die "move()" Methode die du dann pro Frame aufrust leer überschrieben).

Aber frag 100 Leute und du bekommst 100 Meinungen... Also ist das hier nur eine Lösung.
Grüße, Kugel

GitHub Meine Firma Pirsch Analytics

Renegade123

Alter Hase

Beiträge: 494

Wohnort: Berlin

Beruf: Certified Unity Developer

  • Private Nachricht senden

3

18.08.2013, 18:57

Ich würde es mit Komponenten lösen. Finde die Herangehensweise von Unity da sehr schön. Anstatt alles von einem renderbarem Objekt erben zu lassen könnte ein Objekt doch auch eine Renderkomponente haben. Ebenso verhält es sich mit Bewegung und anderem Verhalten. (Literatur hierfür: Game Coding Complete Chapter 6 Game Actors and Component Architecture, oder im Web unter "component based entity system" suchen)
Liebe Grüße,
René

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

4

18.08.2013, 22:50

Ein paar Gedanken, die mir beim Durchlesen da spontan kommen: Was genau sollen diese Gegner so können? Ist es wirklich sinnvoll, ein Sprite in die Basisklasse zu packen? Haben wirklich alle Gegner, die es jemals geben wird, genau ein Sprite? Lässt sich wirklich für alle Gegner, die es jemals geben wird, genau eine Position definieren? Ist das Konzept einer Position oder gar von Move() überhaupt relevant für das Gegner Interface? Wenn ja, warum?

Auf jeden Fall würde ich mich eher darauf konzentrieren, für Konzepte wie "Gegner" sinnvolle Interfaces zu definieren, Vererbung im eigentlichen Sinn, mit Basisklassen mit Datenmembern und so, ist unbedingt seeehr sparsam einzusetzen.

Von Variante 2) würde ich auf jeden Fall abraten
m4studios

Noxum

Frischling

  • »Noxum« ist der Autor dieses Themas

Beiträge: 35

  • Private Nachricht senden

5

20.08.2013, 10:01

Hey danke schonmal für eure Antworten!

Ich denke mal ich werde es wohl erstmal mit Interface etc. machen, da sich bei diesem Projekt die Anzahl der unterschiedlichen Typen noch reeeelative in Grenzen hält.

Allerdings finde ich die Idee von component based entity system sehr interessant und würde es ansich ganz gerne benutzen, aber ein paar Dinge sind mir da noch nicht ganz klar.
Folgendes Szenario: Anngenommen ich habe 100 Verschiedene NPC's welche alle verschiedene Bewegungen, Aktionen, etc. benötigen, dann hätte ich bei der "normalen" Methode mit Basisklasse/Interface ja eigentlich genau 100 Klassen, welche alle jeweils einen NPC darstellen. Gut, und bei component based entity system müsste ich doch dann eigentlich viel mehr Klassen schreiben oder? Also so wie ich es verstanden habe, ist ja jede Komponente eine Klasse, und dann bräuchte ich doch um diese 100 verschiedenen Bewegungsabläufe und Actionen zu definieren, jeweils eine neue Komponente. Daraus würde dann ja folgen, dass ich mindestens das Doppelte an Klassen hätte.
Gut man könnte Komponenten schreiben, welche dann das Bewegungsmuster übergeben bekommen, aber das hängt ja auch immer nen bissel vom Spiel ab.


Hat einer von euch vielleicht irgendwo noch einen Beispielcode wo component based entity system verwendet wird, am besten in Java/C++? Das was ich bis jetzt über Google gefunden habe hat mich zwar ein wenig Schlauer gemacht, allerdings bin ich immernoch etwas verwirrt und habe bis jetzt noch keinen Code gefunden der die Verwirrung beseitigen konnte :D
Why so serious ?

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

6

20.08.2013, 12:21

Zitat von »Bambi«

Änder mal eine klasse wo andere sicj durch vererbung dran bedienen. Die subklassen werden dabei vermutlich ungewollt beeinflusst.

Wenn das passiert, hast du Vererbung falsch benutzt... ;)
m4studios

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

7

20.08.2013, 19:29

Nun ja, wenn man ein Auto in ein Jagdflugzeug ändert, macht auch das Cabrio nicht mehr so viel Sinn ;)
Das kann also auch bei korrekter Anwendung passieren.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

birdfreeyahoo

Alter Hase

Beiträge: 756

Wohnort: Schorndorf

Beruf: Junior Software Engineer

  • Private Nachricht senden

8

20.08.2013, 22:51

Ich würde, wenn man es schon mit Komponenten löst, Unity nachmachen und eine Transform-Komponente erzeugen.
Die ACtor-Klasse muss die Komponenten dann nur noch verwalten.

Renegade123

Alter Hase

Beiträge: 494

Wohnort: Berlin

Beruf: Certified Unity Developer

  • Private Nachricht senden

9

20.08.2013, 23:38

Zitat von »Noxum«

Hey danke schonmal für eure Antworten!
Allerdings finde ich die Idee von component based entity system sehr interessant und würde es ansich ganz gerne benutzen, aber ein paar Dinge sind mir da noch nicht ganz klar.
Folgendes Szenario: Anngenommen ich habe 100 Verschiedene NPC's welche alle verschiedene Bewegungen, Aktionen, etc. benötigen, dann hätte ich bei der "normalen" Methode mit Basisklasse/Interface ja eigentlich genau 100 Klassen, welche alle jeweils einen NPC darstellen. Gut, und bei component based entity system müsste ich doch dann eigentlich viel mehr Klassen schreiben oder? Also so wie ich es verstanden habe, ist ja jede Komponente eine Klasse, und dann bräuchte ich doch um diese 100 verschiedenen Bewegungsabläufe und Actionen zu definieren, jeweils eine neue Komponente. Daraus würde dann ja folgen, dass ich mindestens das Doppelte an Klassen hätte.
Gut man könnte Komponenten schreiben, welche dann das Bewegungsmuster übergeben bekommen, aber das hängt ja auch immer nen bissel vom Spiel ab.


Nein du musst deshalb keine 200 verschiedenen Klassen schreiben. Gerade durch die Komponenten wir das ganze "entschlackt". Du kannst eine Render-Komponente später für jeden Akteur wieder benutzen. Genau so verhält es sich auch mit anderen Komponenten.

Schreibe eine Akteur-Klasse mit einer Position und einer einzigartigen ID die über eine Liste mit Komponenten verfügt. Beim Start des Akteurs kannst du dann über alle Start-Funktionen in der Liste der Komponenten iterieren. Zum Updaten iterierst du über alle Updates der Komponenten und so weiter. Schau dir dafür am Besten mal an wie Unity damit umgeht.

Es ist zwar anfänglich ein größerer Aufwand, aber es wird sich lohnen. Gerade die Erzeugung wird dir später leicht fallen. So könntest du dein Programm mit einer XML füttern die sagt, welche Akteure welche Komponenten erhalten sollen.
Liebe Grüße,
René

Renegade123

Alter Hase

Beiträge: 494

Wohnort: Berlin

Beruf: Certified Unity Developer

  • Private Nachricht senden

10

21.08.2013, 01:43

Zitat von »Bambi«

Hab selbst in c++ ein komponentensystem gemacht. TransformComponent ist bei unity fedter bestandteil jedes gameobjects. Spri h jedes gameobject hat immer teine transformComponent. Eine MeshRenderConponent ist nützlich. PhysicComponent. Particlesystemcomponent. Particleemittercomponent. Lightcomponent. Logic kannst du leicht mit componenten implementieren. Die update methode innerhalb der componete wird per frame aufgerufen.

Ietzlich ist aber auch noch ein message system ins compinentensystem uu implementieren. So können componenten leicht miteinanderbkommunizieren. Klar man sie auch direkt aus der componente ansprechen aber ein message system schickt nachricht raus und alle componenten die es interessiert koennen darauf reagieren.dadurch hat man eine sehr loose kopplung zwischen den einzelnen komponenten. Hoffe das verwirrt nicht alzu sehr. Vllt erstmal eon komponentensystem bauen. Du wirst es lieben.


Meine Güte. So viele Tippfehler!
Liebe Grüße,
René

Werbeanzeige

  • 1
  • 2

Ähnliche Themen