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!

Klassen Struktur eines Levels

Werbeanzeige

spitzohr

Frischling

  • »spitzohr« ist der Autor dieses Themas

Beiträge: 24

  • Private Nachricht senden

1

29.05.2013, 11:54

Klassen Struktur eines Levels

Hallo Zusammen.

Mein Ziel für diesen Beitrag ist es eine Diskusion loszutreten.
Ich habe mir Gedanken über eine Klassen Struktur für ein Level gemacht und bin zu diesem Vorläufigem Ergebnis gekommen:

(Link)



Was haltet ihr von diesem Entwuf. Würdet ihr einen anderen Weg einschlagen? und wen ja welchen.
Ich denke das man mit diesem Entwurf die eine gute Kapselung für die Game Objecte erziehlen würde.
Grüsse Spitzohr.

FSA

Community-Fossil

Beiträge: 1 989

  • Private Nachricht senden

2

29.05.2013, 12:39

Der Entwurf ist nicht schlecht. Ich würde jedoch die Verwaltung von Objekten etwas anders gestalten. AddObject/DeleteObject/RegisterObject sollten alle in einen Szenenhandler geschrieben werden. Die Levelklasse bzw. bei dir Level-Factory sollte dann nur noch die entsprechenden Funktionen des Szenenhandlers aufrufen.

Zitat

Der RCCSWU (RandomCamelCaseSomtimesWithUndersquare) Stil bricht auch mal mit den veraltet strukturierten Denkmustern und erlaubt dem Entwickler seine Kreativität zu entfalten.

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

3

29.05.2013, 15:04

Ich bin mir auch nicht ganz sicher, ob diese Komponenten in das Level gehören. Was sollen die genau steuern? Sind die wirklich nur für das Level da? Also um das Level zu rendern, etc? Und Physik, Mechanik und KI, gehören die wirklich zum Level? Also geht es um Levelverhalten oder um Gegner- und Entityverhalten? Ich halte Enitäten normal nicht im Level selbst, sondern einer extra dafür vorgesehenen Komponente im Design. Diese können dann von außen auf das Level zugreifen, sind aber nicht Teil dessen.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

spitzohr

Frischling

  • »spitzohr« ist der Autor dieses Themas

Beiträge: 24

  • Private Nachricht senden

4

29.05.2013, 20:33

Da ich die Objekte die im Level vorhanden sind (Spieler,Monster,Scenery,Portale etc etc) nicht von einem Basistyp abhängig machen möchte sondern der Basistyp ein Container für Componenten im Spiel sind, kan ich mir genau die Componenten anfertigen die meine Objekte benötigen und schleppe nicht den unötigen Balast der Basisklasse run.(Ein Stein braucht z.b nicht die Animationen die ein Spieler braucht usw).Das Level selber hat nur Kentniss über die Basisobjekte(den Container) und nicht von den einzelnen Komponenten.
Die Idee die liste mit den Objekten auch in eine Klasse auszulagern war auch ein Gedanke von mir. Nur wo ist der Vorteil, die Liste auszulagern und dort update() und render() aufzurufen?

Grüsse Spitzohr

FSA

Community-Fossil

Beiträge: 1 989

  • Private Nachricht senden

5

29.05.2013, 21:23

Du kannst später die Objektliste/Szenenhandler auslagern. Dann kannst du ein Spiel und ein Editor zugleich machen ohne irgendwas doppelt zu nutzen.

Zitat

Der RCCSWU (RandomCamelCaseSomtimesWithUndersquare) Stil bricht auch mal mit den veraltet strukturierten Denkmustern und erlaubt dem Entwickler seine Kreativität zu entfalten.

Werbeanzeige

Ähnliche Themen