spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Vielleicht würde als erste Verbesserung ein Dictionary, dass einen GameplayButton auf eine actionToBeTriggered/ToogleWindowById mappt, helfen.

Als große Verbesserung könnte sich vielleicht eine Variante des Commandpatterns anbieten.

Naja eine erste Verbesserung wäre die && Abfragen in einzelne Funktionen umzuwandeln mMn. Also anstatt

folgendes


Ich verwende für sowas gerne folgende Begriffe:
Pressed -> 1. Frame in dem die Taste unten ist
Down -> Mindestens 2. Frame in dem die Taste unten ist
Released -> 1. Frame in dem die Taste oben ist
Up -> Mindestens 2. Frame in dem die Taste oben ist

Danach könntest du noch schauen, ob du Die Tastenabfragen selbst iwie gruppieren kannst (Systemkombinationen wie z.B. Alt-F4, GUI-Abfragen und Figurbewegung). Dadurch hättest du zumindest eine bessere Übersicht. Alles andere würde ich erstmal außen vor lassen, da du sonst unter Umständen viel Aufwand in etwas steckst, was das eigentliche Programm aus Nutzersicht nicht verbessert.

Irgendwo müssen diese Abfragen leider gemacht werden.
Für InputHandling speziell bei Spielen gibt es aber zum Beispiel ein schönes Command Pattern. http://gameprogrammingpatterns.com/command.html
Das kann man dann auch wunderbar erweitern und in einer Event Queue einbauen. http://gameprogrammingpatterns.com/event-queue.html

Das Command Pattern scheint mir totaler Schwachsinn für diese Aufgabe, speziell so wie auf der Seite erklärt. Die if Kaskade, die man aufwendig pflegen muss hat man so trotzdem noch. Plus zig Klassen mit Ableitungen rundrum. Und dann baut man sich auch noch eine Einschränkung ein, die einem in einem echten Projekt wahrscheinlich sofort um die Ohren fliegt. Command* InputHandler::handleInput() kann genau ein Command zurueckgeben, was ist wenn ich schiessend nach links laufe und dann springen will. Dann baue ich ein Command das genau die 3 Sachen macht und dann auch noch eins für alle 2^n Kombinationen meiner n buttons?

Was sich bei mir in jahrelanger Praxis bewährt hat, ist ein simples Array, das die Infos zu allen Aktionen hält. Der Index lässt sich am einfachsten über Enums/Konstanten abbilden, so in der Art enum Action {left, right, jump, shoot}. Der simpelste usecase ist dann eine Funktion keyPressed(left), die man direkt dort im Code aufruft, wo sie gebraucht wird. Die Funktion schaut dann in das array, da steht drin welche Taste konkret hinter left steht, schaut nach ob die gedrueckt ist und gibt die Antwort. Angenommen ich hab Top Down Steuerung, das könnte dann so ausshehen:


Mach das mal mit dem komischen Pattern, da schreibt man 4 Klassen und braucht noch zig temporäre Variablen bevor man den Vektor sinnvoll zusammengebaut hat.


Fehlt noch der zweite usecase, der ist nuetzlich für Menus oder so Shortcuts wie Waffenwechseln. Mit dem Pattern da oben muss man sich irgendwie merken das man grad Waffen gewechselt hat, sonst wechselt man nächsten Frame wieder die Waffe. Was man eigentlich will: ein Event, wenn eine Taste gedrueckt oder losgelassen wird. Kann man natürlich einfach irgendwo global eine Funktion aufrufen, welche dann wieder die if Kaskade drin hat oder eleganter sein switch über das enum mit Aktionen. Noch schöner ist wenn man einen Callback registrieren kann: registerkeyDown(changeWeapon, OnWeaponChanged()); registerkeyUp(select, OnPauseMenuOpen());. Noch cooler wirds natuerlich wenn man Sachen wie OnWeaponChanged() aus eine Scriptsprache aufrufen kann und man dann im Config File diese Zuweisungen tätigen kann ohne. So kann das auch ein Nichtprogrammier recht leicht anpassen, wenn man ihm die Liste mit Befehlen gibt.

Zitat von »TGGC«

Das Command Pattern scheint mir totaler Schwachsinn für diese Aufgabe, speziell so wie auf der Seite erklärt. Die if Kaskade, die man aufwendig pflegen muss hat man so trotzdem noch. Plus zig Klassen mit Ableitungen rundrum. Und dann baut man sich auch noch eine Einschränkung ein, die einem in einem echten Projekt wahrscheinlich sofort um die Ohren fliegt. Command* InputHandler::handleInput() kann genau ein Command zurueckgeben, was ist wenn ich schiessend nach links laufe und dann springen will. Dann baue ich ein Command das genau die 3 Sachen macht und dann auch noch eins für alle 2^n Kombinationen meiner n buttons?

Da muss ich dir komplett widersprechen. Das Command Pattern ist in dem Fall sehr sinnvoll. Das Command kapselt einzelnes Verhalten und ermöglicht diese sequentiell zu verarbeiten. Ich zitiere: "Encapsulate a request as an object, thereby letting users parameterize clients with different requests, queue or log requests, and support undoable operations." Dafür benötigst du lediglich ein Command für jede Art des Inputs und nicht für jede Kombination. Sollten in einer Execute mehrere Inputs abgearbeitet werden, dann werden sie das eben in einer Queue. Deine Variante führt zu unflexiblen Code und folgt nicht der allgemeinen Regel statischen von veränderlichen Code zu trennen. (Clean Code - Uncle Bob) Ggf. bitte nochmal das Pattern in "Design Patterns - Elements of Reusable Object-Oriented Software" von der Gang of Four nachlesen oder hier von Bob Nystrom als aufgearbeitetes Beispiel für Games.

Zitat von »Renegade«

Das Command kapselt einzelnes Verhalten und ermöglicht diese sequentiell zu verarbeiten. Ich zitiere: "Encapsulate a request as an object, thereby letting users parameterize clients with different requests, queue or log requests, and support undoable operations." Dafür benötigst du lediglich ein Command für jede Art des Inputs und nicht für jede Kombination. Sollten in einer Execute mehrere Inputs abgearbeitet werden, dann werden sie das eben in einer Queue.

Naja aber das ist doch genau der Punkt. Du hast jeweils ein Command um dich nach rechts, links, oben und unten zu bewegen. Wenn dein "inputHandler" nur ein einzelnes Command zurück gibt dann musst du eben auch Commands für die diagonalen Bewegungsrichtungen schaffen. Abhilfe kann man sich natürlich schaffen indem so ein Input Handler mehrere Commands zurück geben kann. Dann könnten die Abfragen die jeweiligen Commands generieren und würden diese zurück geben. Danach könnten sie in die Queue gestopft werden um am Ende irgendwo verarbeitet zu werden. Darauf möchtest du vermutlich auch hinaus. In dem Beispiel wird das aber so erst mal nicht umgesetzt. An sich ist Command ein schönes Pattern, man sollte sich aber überlegen ob man es am Ende wirklich benötigt. Vergleich einfach mal den kurzen Code den TGGC da zeigt mit dem Code den ein Command Pattern hier benötigen würde. Flexibilität ist natürlich ein Argument, wobei ich mir die auch mit anderen weniger aufwendigeren Mitteln schaffen kann. Man sollte halt erst nachdenken bevor man solche Patterns benutzt. Die können einem halt viel Arbeit einbringen.

Zitat von »Schorsch«

Naja aber das ist doch genau der Punkt. Du hast jeweils ein Command um dich nach rechts, links, oben und unten zu bewegen. Wenn dein "inputHandler" nur ein einzelnes Command zurück gibt dann musst du eben auch Commands für die diagonalen Bewegungsrichtungen schaffen. Abhilfe kann man sich natürlich schaffen indem so ein Input Handler mehrere Commands zurück geben kann. Dann könnten die Abfragen die jeweiligen Commands generieren und würden diese zurück geben. Danach könnten sie in die Queue gestopft werden um am Ende irgendwo verarbeitet zu werden. Darauf möchtest du vermutlich auch hinaus. In dem Beispiel wird das aber so erst mal nicht umgesetzt. An sich ist Command ein schönes Pattern, man sollte sich aber überlegen ob man es am Ende wirklich benötigt. Vergleich einfach mal den kurzen Code den TGGC da zeigt mit dem Code den ein Command Pattern hier benötigen würde. Flexibilität ist natürlich ein Argument, wobei ich mir die auch mit anderen weniger aufwendigeren Mitteln schaffen kann. Man sollte halt erst nachdenken bevor man solche Patterns benutzt. Die können einem halt viel Arbeit einbringen.

Man könnte die Bewegungsrichtungen auch zusammenfassen zu einem MoveCommand und daraus einen Richtungsvektor berechnen (Wie sonst soll das klappen? 360 Commands erstellen für jeden Grad des Kreises?). Außerdem ist die Erweiterung, das mehrere zutreffende Commands zurück gegeben werden, jetzt nicht gerade schwer. Das hier zu schreiben dauert länger, als die Abänderung im Beispiel von Nystrom hinzuzufügen.
Das TGGCs Code kürzer ist bleibt unbestritten. Aber die Argumentation, dass das Command in einem echten Projekt um die Ohren fliegt ist absolut nicht haltbar. Ich kenne kaum ein großes Projekt welches den Input (jeglicher Art, ob Remote/Network/Proxy, KI etc. pp.) nicht in Commands kapselt. Es gehört zu einen der wichtigsten Patterns in der Spieleentwicklung und ist super flexibel.

Zitat von »Wirago«

Ich habe die Bewegung der Spielfigur extra ausgelagert um zu verhindern, dass sich Aktionen und Bewegung gegenseitig blockieren.
Dort wird im Prinzip nur auf die Bewegungstasten reagiert, die Bewegung berechnet und dann die Figur bewegt. Drückt man also Links und Rechts gleichzeitig, dann steht die Figur still.

Das kannst du auch sehr gerne weiterhin so lösen. Das sollte aber meiner Meinung nach nicht im Input geschehen, sondern in der Simulation deines Spiels. Inputs und deren Commands werden erstmal alle erstellt und entgegen genommen. Welche du dann filterst oder nicht bleibt dir im nächsten Schritt. Zum Beispiel könntest du dann sagen, sobald das Command Array von Bewegungen größer 0 ist, reagierst du nicht mehr auf Commands von Aktionen.