spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Beim Inputhandling gibt es verschiedene Aspekte, die man auch getrennt voneinander behandeln soll. (Callbacks sind nich zwingend erforderlich, um die Tasten konfigurierbar zu halten.)

Der erste Punkt ist die Abstraktion bzw. das Mapping der tatsächlichen Eingaben zu "highlevel" Eingaben. Hier ist lediglich die Frage, ob man dies macht und ob man auch über die Tasten/Buttons an den rohen Input kommen kann. Ich persönlich würde dazu raten, diese Abstraktion einzubauen und den direkten Weg über die tatsächlichen Tasten nicht anzubieten. In seinem Spiel wird man ohnehin nur eine begrenzte Anzahl an Aktionen/"highlevel" Eingaben haben ("springen", "nach rechts laufen", "nach links laufen", "ducken", "schlagen", "oberes UI Element auswählen", "unteres UI Element auswählen", "UI Element aktivieren" etc.). Diesen kann man jeweils eine oder mehrere lowlevel Eingaben zuweisen ("Pfeiltaste hoch" -> "springen", "W" -> "springen", "W" -> "oberes UI Element auswählen", ...). Mit geringem Aufwand ist es bereits an dieser Stelle möglich, die Zuweisungen konfigurierbar zu halten, sodass die Steuerung angepasst werden kann, ohne den Code anfassen zu müssen, und damit alternative Steuerungen (Zweitbelegungen) möglich sind.
Das Mapping ist dabei nicht der einzige Teil dieser Abstraktion. Man kann die Abstraktion auch so handhaben, dass sich dahinter unterschiedliche Eingabemöglichkeiten/-arten (digitale Tasten, die gedrückt oder nicht gedrückt sind, analoge Eingaben, deren Wert von 0 bis 1 oder -1 bis 1 gehen kann, "Zeiger", wie die Maus oder Touchinput) befinden können, die dann einheitlich angesprochen/abgefragt werden können. Je mehr Eingabemöglichkeiten man bei dieser Abstraktion berücksichtigen möchte, um so schwieriger wird es aber auch, eine einheitliche und gleichzeitig sinnvolle Schnittstelle zu definieren, über die man immernoch gut auf die Eingaben eingehen kann (wenn eine enorme Abstraktion für das eigene Spiel nicht von relevanz ist, kann man auf besetimmte Teile verzichten). Gerade im Falle der Maus wird man sich am ehesten denken, dass ein einheitliches Ansprechen mit bspw. einem Analogstick nicht wirklich möglich ist, da die Maus bereits die Koordinaten auf dem Bildschirm liefert, während der Stick nur Werte von -1 bis 1 für beide Achsen liefert. Wenn man allerdings auch von der Maus lediglich die relative Bewegung berücksichtigt (und nicht die vom System gegebene Mausposition für bspw. den Cursor verwendet), dann hat man nicht nur den Vorteil, über einen Analogsstick und die Maus den Cursor bewegen zu können, sondern kann auch sehr einfach Einschränkungen für die Bewegung des Cursors implementieren (während der Auswahl von Einheiten macht es bspw. wenig Sinn, mit dem Cursor den sichtbaren Bereich zu verlassen).
Teil der Abstraktion ist auch die repräsentation der abstrahierten Eingaben nach außen hin und welche Arten dabei angeboten werden. Es könnte dort Eingaben geben, die betätigt oder nicht betätigt sein können, es könnte wie in Unity Achsen geben, denen man entweder tatsächliche Achsen oder 2 Buttons zuweisen kann, die ggf. auch automatisch interpoliert werden könnten, Es könnte aber auch 2 Achsige Eingaben (bspw. für die Spielerbewegung) geben, der dann 2 Achsen oder 4 Buttons/Tasten zugewiesen werden können. Abhhängig vom Spiel ist es ggf. auch Erforderlich, auf Texteingaben einzugehen (Name für Highscore, Chatnachrichten, ...), wofür die Schnittstelle des Inputmanagement ebenfalls etwas parat halten sollte. Dabei können die Eingaben nicht nur von der Tastatur kommen, aber dazu mehr im übernächsten Absatz.

Nachdem man nun ggf. das Mapping hat, müssen die entsprechenden Objekte der Spielszene und des UIs davon mitkriegen. Dabei kann man Events (dem Inputmanager werden Callbacks mitgegeben), Polling (vom Inputmanager kann der Ektuelle Zustand einer Eingabe abgefragt werden) oder beides verwenden. Was sinnvoller ist, dürfte wohl sehr vom Einsatzgebiet abhängen, allerdings würde ich Events nur für Dinge verwenden, die sich "gelegentlich" ändern können (bspw. das Drücken eines Buttons, um im Spiel eine Aktion auszulösen) und für Dinge, die sich im Grunde in jedem Frame ändern können (bspw. die Achsen eines Gamepads für Bewegung/Umschauen) eher ein Polling verwenden.
Wichtig dabei zu bedenken ist nur, dass die bisher genannten Nachteile des Pollings keine Nachteile des Pollings sind. Verwendet man ein Polling muss man entweder an der jeweiligen Stelle prüfen, ob die Eingaben berücksichtigt werden sollen oder man muss eine "höhere Stelle" haben, die von Inputmanager die Eingaben abfragt und dann schaut, wohin diese weitergegeben werden sollen. Verwendet man Events muss man entweder im Eventhandler ebenfalls die Prüfung durchführen, ebenfalls ein "höheres Objekt" verwenden oder man muss die Callbacks permanent anpassen. Das heißt also, dass man entweder genau das Gleiche wie vorher hat (Prüfung im Zielobjekt oder übergeordnetes Objekt) oder dass man fast das gleiche hat (Prüfung an anderer Stelle, damit Callbacks angepasst / Zielobjekte ausgetauscht werden können).
Anbei noch: in anderen Bereichen ist sehr häufig etwas Event-basiertes besser, allerdings hat man dort i. d. R. nur gelegentlich auftretende Änderungen und will grundsätzlich auch nur dann etwas machen, wenn es Eingaben gab. In Spielen macht man ohnehin schon in jedem Frame viele (teils Input-abhängige) Dinge, wodurch die üblichen Nachteile des Pollings nicht mehr relevant sind.

Worüber man sich anschließend noch Gedanken machen kann, ist das manuelle Auslösen von Eingaben bzw. virtuelle Eingaben. Einfachstes Beispiel sind dabei Abbildungen von Eingabegeräten, die dann mit den physisch vorhandenen bedient werden. Das können die vermutlich allseits bekannten Softkeys/Bildschirmtasten sein, die häufig von Spielen für Mobilgeräte verwendet werden, es können aber auch "Tastaturen" sein. Während man seinen Namen in einem Spiel eingibt will man nicht unbedingt auf eine Tastatur beschränkt sein, vor allem wenn man an einer Konsole spielt oder das Spiel aus einem anderen Grund Support für Gamepads bieten will.
Es wäre zwar möglich, den Großteil der Spielinternen Events ebenfalls über den Inputmanager zu handhaben, das macht allerdings nur dann Sinn, wenn es mehr als 1 Möglichkeit gibt, dieses Event auszulösen und/oder wenn ein solches über Eingabegeräte ausgelöst werden kann. Sinnvoller dürfte es in diesem Fall aber sein, das Versenden der Nachrichten in einen EventManager auszulagern und eine Kommunikation zwischen diesem und dem Inputmanager für aus Inputs resultierende Events aufzubauen.


Ich habe mir die beiden verlinkten Seiten noch nicht weiter angesehen, werde ich dann aber noch nachholen.

Du benötigst eine solche Speicherung der Tastenzustände dann, wenn du diese abfragen musst (Polling), aber selbst lieber Events haben würdest.
Allerdings ist es nicht nur möglich, die Roheingaben zu speichern, da du genausogut auch den Stand des Highlevelinputs speichern kannst. Durch das Mapping ist bekannt, welche Tasten von welchem Gerät abgefragt werden müssen, um den aktuellen Zustand und somit den Unterschied zum letzten Zustand zu ermitteln, damit dann Events ausgelöst werden können.

Oder anders: Dieses Speichern des letzten Zustands muss nicht unbedingt mit dem Rohinput gemacht werden, sondern kann auch mit dem "Highlevel"-Input gemacht werden.