JLI Spieleprogrammierung

[Jonathan_Klein]

Tja, wunderbar OOP Programmier, alles schon gekapselt und von außen unsichtbar gemacht und dann kommt der Tag, an dem man doch mal an die inneren Werte muss.
Meine Situation: Ich programmiere gerade das ultimative RPG. Wie so viele andere auch.
Das ganze muss natürliche hyperflexibel sein, man soll jede kranke Idee in kürzest möglicher Zeit einbauen können. Daher habe ich mir folgendes ausgedacht:

Jede Aktion wird als eigene Klasse repräsentiert.
Eine Klasse laufen bekommt z.B: die Position eines Ortes und bewegt den Spieler dann dorthin, mit der aktuellen Laufgeschwindigkeit (diese ist in dem Laufenobjekt gespeichert).
Das ist wunderbar übersichtlich und sehr einfach zu erweitern. Man kann z.B: nicht nur ein Item aufheben, man könnte auch im Kampf gegen ein am Boden liegendes Item treten, damit es dem Gegner in den Kopf fliegt. Prinzipiell macht das keinen Unterschied.

Nun sollen aber diese Aktionen vollen Zugriff auf alle Charakterwerte haben. Und zwar direkten Zugriff, den sie sind ja quasi ein Teil der Charakterklasse. Man erweitert mit ihnen ja dynamisch die Charakterklasse, und ohne einen Charakter sind Aktionen sinnlos.

Eine erste Lösung war, eine Structur mit Charakterwerten einzuführen. Die hat jeder Charakter für sich privat und in dieser Struktur wird z.B. die Position gespeichert. Jetzt benötigt eine Aktion nur eine Referenz auf diese Strukturvariable und kann den Spieler schon komplett verändern. Andere Klassen können das nicht, da sie vom Charakter nicht diese Referenz bekommen.

Jetzt möchte ich allerdings ein Charakter von einem WorldObject ableiten, dadrin wären dann auch Dinge wie Items, Schalter, Projektile und so weiter. Das ermöglich an anderen Stellen wieder ein paar schöne Dinge.

Problem ist jetzt, Position und Größe würden in diesem WorldObject gespeichert. Daher wären diese nicht mehr in der CharakterWerteStruktur und daher kann ich nicht mehr so einfach auf die Privaten Teile des Charakters zugreifen.

Jetzt gibt es eine Menge Methoden, die mir alle nicht gefallen:

Get/Set Methoden: Ist mir zu unübersichtlich so viele zu schreiben, außerdem hätten dann ja alle Klassen fast vollen Zugriff und die paar die vollen Zugriff haben sollen, sollen direkten Zugriff haben

Alles Public: Eine einfache Lösung aber nicht wirklich schön. Wenig aufwand, direkter Zugriff, aber dann ist ein Charakter irgendwie so nackig.

Alle Aktionen sind friend: Soweit ich weiß kann man friend nicht vererben, hätte ich also 20 Aktionen müsste ich 20 Aktionen als friend deklarieren. Ne Menge schreibarbeit, dafür hat nicht jeder Zugriff und ich bekommen direkt Compilerfehler wenn ich ein friend vergessen habe.

Böses Casten: Eine zweite, identische Struktur bei der alle Elemente public sind. Ich könnte den Charakter casten und hätte so vollen Zugriff, dank cast wäre es schone in ziemlicher Eingriff, weswegen es etwas besser ist als alles public zu machen. Wenn ich allerdings etwas erweitere greif ich ganz schnell auf falschen Speicher zu, bekomme komische Werte und keine Compilerfehler. Ganz böse also, sowas will man nicht.

Viele Referenzen übergeben: Tja, wenn die Charakterwerte verteilt sind, kann man jeden Teil als Referenz übergeben. Ist allerdings umständlich und nicht so schnell zu erweitern.

Meine ursprüngliche Lösung mit der Struktur gefiel mir ganz gut, aber wenn dank Ableitung die Werte verstreut sind (was sich wohl nicht vermeiden lässt), dann funktioniert das nicht mehr.
Ich glaube ich tendiere Momentan zu der Methode mit dem Social Network (die Hälfte der Welt ist miteinander befreundet) da es relativ übersichtlich ist und ich nichts vergessen kann, da ich direkt Fehler bekommen würde.

Nur, gibt es jetzt vielleicht die eine ultimative Lösung dafür?
_________________
https://jonathank.de/games/

[fkrauthan]

Wie wärs mit Abstrakten Basis Klassen und Vererbung? Ich glaube das sollte dein Prolbem beheben. Schön das du wieder am RPG weiterproggst
_________________

"Die Codeschleuder" das Spieleprogrammierer Magazin

[Jonathan_Klein]

Ehrlich gesagt glaube ich nicht, dass das mein Problem behebt. Wenn ja versteh ich es nicht.
_________________
https://jonathank.de/games/

[GreveN]

Wenn du an der grundlegenden Struktur des Systems nichts ändern willst, dann halte in der "Transfer-Struktur" eben einfach Zeiger/Referenzen auf die kritischen Objekte.

[Hazel]

Wenn du das Spiel jemals fertigstellen willst, dann designe es vorher und überleg dir genau was für Features du brauchst. Weniger Bullshit, weniger unnötige Features. Wenn du weißt, was du brauchst, verschwendest du weniger Zeit mit architektonischen Krams, den du später eh wieder refactorst, weil dir eine bessere Möglichkeit eingefallen ist. :)

Zum eigentlichen Thema: Meine Lieblingsarchitektur ist eindeutig MVC http://de.wikipedia.org/wiki/Model_View_Controller. Ich modelliere meistens diese drei Packages unabhängig voneinander. Ins Model kommen alle wichtigen Daten, unter anderem auch die, die für das speichern und wiederherstellen von Spielständen unbedingt erforderlich sind... quasi die Datenbank des Spiels. Der Controller besteht aus vielen can? und do? Methoden. KANN ein Charakter eine Aktion ausführen (meistens eine logische Verknüpfung von Werten) und eine zugehörige Methode, die diese Aktion dann auch ausführt. Das hat meist das Werfen eines Ereignisses zufolge. View sollte klar sein... Graphische Darstellung deines Datenmodells.
Dazu ist noch zu sagen, dass Controller und View sehr eng zusammengehören. Je nach dem, was du mit der Datenbank gerade so anstellst, benutzt du ein anderes View/Controller-Pärchen (sprich: Level Editor, Game, KI Editor, Sandbox, ...).

Um die Kommunikation zwischen Model, View und Controller zu realisieren, benutze ich meistens das Mediator-Pattern, um Ereignisse im System aufzufangen und zu verteilen. Ist zentraler und übersichtlicher als das Observer-Pattern (jeder kann jedem Observerable "zuschauen").
Beim Mediator wird ein Event an den Event-Dispatcher geschickt... das enthält neben der Nachrichtenart auch einen "Kanal" und die eigentlichen Daten. Sub-Systeme können dann auf den Kanälen lauschen, die sie interessieren und auf Ereignisse entsprechend reagieren. Kanäle wären z.B. User Eingaben, KI-Ereignisse, ...

Mediator: http://de.wikipedia.org/wiki/Vermittler_%28Entwurfsmuster%29
_________________
*click* Dabuu!?
Twitter: http://twitter.com/Ollie_R

[Jonathan_Klein]

@Hazle
Klingt irgendwie sehr kompliziert. Könntest du mir evtl. n kleines Beispiel geben?
Also ich habe ja jetzt schon Aktionen in extra Klassen. Dann hab ich eine Modellklasse, für die Darstellung und halt meine Charakterklasse, die alle Werte speichert.
Der Player ist vom Charakter abgeleitet und guckt prinzipiell nur jede Frame ob eine Usereingabe vorhanden ist und startet danach die entsprechenden Aktionen.
Ki wird auch abgeleitet von Charakter und überlegt sich dann halt n paar kleinere Sachen.
_________________
https://jonathank.de/games/

[Hazel]

[fkrauthan]

was für UML software würdest du den für Linux empfehlen? Ich habe noch nichts gefunden was mich wirklich überzeugt.
_________________

"Die Codeschleuder" das Spieleprogrammierer Magazin

[Hazel]

[User_User]

Folgendes weißt du vermutlich bereits. Da mir beim Querlesen folgende C++-Befehle nicht íns Auge gesprungen sind, führe ich sie kurz auf:

Ich verwende in meinem Programm folgende Konstruktionen:

[Jonathan_Klein]

http://tutorial.schornboeck.net/friend.htm

[DirectXer]

[Jonathan_Klein]

Naja, ich fände es schon sehr gut, ein vererbbares friend zu haben. Optional. Ich meine C++ ist doch so designt dass man alles kann, aber nix muss.
Außerdem, wenn ich was vom Freund meines Vaters will, dann frag ich den einfach und dann krieg ich das

Naja, ich habs jetzt mit der Struktur gemacht. Mal sehen ob ich dabei bleibe Ich hänge noch halb bei der Lösung mit 20 friend Deklarationen.
_________________
https://jonathank.de/games/

[DirectXer]

[User_User]

Jonathan_Klein hat geschrieben: