Einheitensteuerung

[Jonathan]

Ich entwickle gerade einen kleinen Zombieshooter. Jetzt frage ich mich, wie ich am besten die Logik für die Zombies (und auch den Spieler) umsetzen soll.
Die Sache ist die, dass man zwar rum rumläuft und auf Zombies schießt, aber trotzdem sollen die Kämpfe relativ komplex sein. Zum Beispiel können Spieler und Zombies stürzen, (zum Beispiel weil sie getroffen wurden) und dann wieder aufstehen, oder in Falle eines verwundeten Zombies auch mal ohne Beine über den Boden robben. Zombies sollen den Spieler auch packen können wodurch er sich erst losreißen muss und so weiter.

Ansich ist das ja alles leicht zu programmieren, ich weiß nur noch nicht so ganz, wie genau ich es am schönsten machen soll. Es hört sich ja vielleicht ein wenig nach Statemachine an, man kann rumlaufen, angreifen, tot rumliegen und so weiter. Allerdings möchte man ja auch im Laufen angreifen können, aber eben nicht, während man gerade durch einige Treffen nach hinten taumelt. Es gibt also irgendwie eine Reihe an Zuständen beziehungsweise Aktionen, die man gleichzeitig oder eben nur exklusiv ausführen kann. Das ganze soll halt möglichst flexibel gestaltet sein, einmal wegen der übersicht und zum anderen, weil man bei einem so komplexen System ja bestimmt prima komsiche Bugs einbauen kann, bei denen dann plötzlich Dinge passieren, die eigentlich nicht möglich sein sollten.

Zur Lösung hatte ich jetzt verschiedene Ideen. Einerseits könnte es eine Trennung von Zuständen und Aktionen geben. Ein Zustände wäre dann etwas wie stehen, gehen oder liegen, Aktionen so etwas wie 'Auf Treffer reagieren' angreifen, 'Gegenstände aufheben'. Man könnte dann jeder Aktion zuordnen in welchem Zustand sie nur ausgeführt werden kann, und dann Zustands ober Aktionswechsel erzwungen oder normal ausführen (man kann sich während dem Treten nicht hinlegen, aber wenn man umgeschmissen wird, wird halt die Tritt-Aktion unterbrochenen und hat dann keinen Effekt mehr).

Eine andere Idee war es, für Aktion zu definieren, welche Arme/Beine/Hände gebraucht werden. Man bräuchte zum laufen also nur die Beine, hat also die Arme zum Angreifen frei. Wenn man am Boden liegt, kann man auf allen Vieren robben, und dann also nicht angreifen, bis man still liegt. Man könnte dann mit einer einhändigen Waffe mit der anderen Hand Objekte aufheben, mit einer Zweihändigen eben nicht. Der Vorteil dabei ist natürlich, wenn für jede Aktion die Benötigten Extremitäten bekannt sind, sollte man auch recht gut die Animationen überblenden können. Man bräuchte also keine LaufAngriff Animation, sondern weiß, dass man Laufen und Angreifen gleichzeitig abspielen kann, weil sie eben keine gemeinsamen Knochen benutzen.

Andererseits ist auch die Frage, ob man so etwas kleines wie Aktionen als eigene Klassen programmieren sollte. Im Zweifelsfalle hat man da manchmal doch nur 3 Zeilen Code, aber 2 Dateien mit 40 Zeilen nur um das ganze drumherum zu haben. Das ganze als einen quasi monolithischen Codeblock umzusetzen könnte schnell gehen und kompakt sein, die Frage ist halt nur, wie Erweiterbar und Bugfrei so etwas bleiben würde.

[Chromanoid]

Also ich hab mir mal ein State-System für ein Spiel gebaut. Das wurde ziemlich schnell unübersichtlich - vor allem weil ich auch Steuerung, Animation etc. damit gemacht habe und keine "Zwischenzustände"/"Router-Zustände", die nur zu anderen Zuständen im gleichen Schritt weiterleiten, eingebaut habe.

Auf der anderen Seite habe ich auch mal ein State-System gebaut, das mir recht gut gefallen hat. Dabei ging es dann aber um sehr einfache Steuerungsmechanismen. Bei den Übergangsbedingungen für die Zustände konnte man auch Zeiten angeben. Z.B. "Zustand Angriff: wenn Zeit-in-Zustand<0.1s & KEY_ANGRIFF dann Zustand DoppelAngriff; wenn Zeit-in-Zustand >=0.1s dann StandardAngriff-ausführen". So konnte man ziemlich schnell Tastenkombinationen wie aus einem Prügelspiel einbauen... Ich würde zu einer Mischung aus Zuständen und einfachen Bedingungen, die direkt Kommandos ausführen, raten. Woran du auch denken solltest ist, dass du mehrere Zustandssysteme haben kannst, also zum Beispiel eins für die Steuerung der Figur, eins für die Spiellogik der Figur etc. ich hab bei meinem ersten Versuch den Fehler gemacht, alles in ein System packen zu wollen.

[Jaw]

Also ich würd jetzt im einfachsten Fall an "Flags" denken, also einfach ne Kladde an boolean Variablen, und dann Abhängig davon sind eben bestimmte Dinge möglich oder nicht, bestimmte Animationen laufen, etc. Es gibt ein Decorator Pattern, wo man kleine Zusatzklassen auf etwas draufkleistert, das könnte auch eine Denkrichtung sein. Oder man entwickelt irgendwelche Masken, die man auf dein Objekt anwendet, durch Vererbung z.B. Es bildet sich quasi eine Kette von modifizierenden Objekten, die alle die gleiche Schnittstelle wie Spieler oder Mob (Zombie) selber haben, aber das Verhalten ändern. So Klassen wie KeineBeine, Angschossen, Hinken, Umklammert. Wenn mans richtig programmiert kann man jede davon auf die andere draufpappen und jede modifiziert das Verhalten der Methoden entsprechend. Und wenn eine Situation endet, z.B. nicht mehr umklammert, nimmt man den Modifikator wieder raus.

Is jetzt was wild und vage, vielleicht keimt ja ne Idee daraus.

Und sonst regieren wie immer KISS - Keep it simple and stupid und YAGNI - you aint gonna need it. Mach lieber ne funktionierende Lösung, und wenns viele booleans und ein großes if els oder switch case Gewusel wurd, und optimiere erst bei Bedarf. Eine einfache und weniger elegante Lösung könnte völlig ausreichen und sie ist dann zügig fertig und du kannst andere Dinge machen. Muss ja nicht alles Krone der Schöpfung sein, stets nur ausreichend.

-JAW