„Game Loop“ – Versionsunterschied

Eine Game Loop ist ein zentrales Element der meisten Game Engines sowie VR- und AR-Systeme. In ihr wird die Verarbeitung der Eingaben des Benutzers angestoßen, die Berechnung neuer Weltzustände gestartet und das Erzeugen neuer Ausgaben angewiesen. Im Gegensatz zum EVA-Prinzip läuft eine Game Loop auch ohne weitere Eingaben des Benutzers weiter.

Gameloop

Aufgabe und Verwendung

Computerspiele, VR- und AR-Systeme unterscheiden sich von klassische Anwendung, wie z. B. einer Textverarbeitung oder Tabellenkalkulation, dadurch, dass sie auch ohne eine Eingabe eines Benutzers fortlaufend neue Berechnungen anstellen und Ausgaben erzeugen. Tätigt zum Beispiel der Benutzers bei einer Textverarbeitung keine neuen Eingaben, verändert sich auch der Zustand dieser Anwendung nicht. Bei Computerspielen verändert sich die simulierte Szene hingegen auch ohne weitere Eingaben des Benutzers.

Klassische Anwendungen sind in der Regel nach dem EVA-Prinzip aufgebaut. Hierbei wird zunächst die Eingabe des Benutzers gelesen. Diese Eingabe wird verarbeitet und aufgrund der neu berechneten Daten wird eine Ausgabe getätigt. Die Anwendung wartet jedoch solange auf neue Eingaben bis der Benutzers diese tätigt.

Computerspiele, VR- und AR-Systeme warten jedoch nicht bis der Benutzer eine Eingabe tätigt. Die Anwendung läuft hingegen fortwährend in einer Schleife, wobei zu Beginn jedes Schleifendurchlaufs die Eingaben verarbeitet werden, die seit dem letzten Schleifendurchlauf getätigt wurden.

Phasen

Die drei Phasen der Eingabe, Simulation und Ausgabe werden fortlaufen in einer Schleife ausgeführt, bis der Benutzer die Anwendung beendet.

Eingabe

Zu Beginn jedes Schleifendurchlauf werden alle Eingaben verarbeitet, die ein Benutzer seit dem letzten Schleifendurchlauf getätigt hat. Um welche Eingabegeräte es sich hierbei handelt hängt vom Anwendungsbereich ab. So sind für Computerspiele die Eingabegeräte Tastatur und Maus verbreitet. Bei komplexen VR-Systemen kommen hier jedoch noch weitere Geräte wie ein Tracking-System, Mikrophone zur Sprachsteuerung und Gestenerkenner, wie z. B. die LeapMotion hinzu.

Eine wesentliche Aufgabe diese Phase ist es Eingaben die zu unterschiedlichen Zeitpunkten erfolgten zu einer konsistenten Information zusammenzufassen.

Simulation

In diese Phase wird auf Grundlage der eventuell erfolgten Eingaben des Benutzers sowie Informationen der simulierten Szene ein neuer Weltzustand der Anwendung berechnet. Typische Sub-Systeme dieser Phasen sind z. B. die Anwendungslogik, Animation und Physik-Simulation.

Ausgabe

In dieser letzten Phase erfolgt die Ausgabe an dem Benutzer. Die zwei gebräuchlichsten Ausgabeformen sind visuelles Rendering, sowie akustische Ausgabe. Welche Ausgabekanäle in welcher Form vorhanden sind, unterscheidet sich wie bereits bei der Angabe stark zwischen den jeweiligen Anwendungsbereichen.

Frequenzbegrenzung

Eine Game Loop wird aus zwei Gründen in ihrer maximalen Frequenz begrenzt. Zum einen haben Ausgabekanäle, wie z. B. ein Bildschirm, eine maximale Ausgabefrequenz. Eine Ausgabe in höherer Frequenz würde somit nicht durch das Gerät dargestellt werden. Zum anderen sorgt eine Begrenzung der Frequenz auch dafür, dass das Spiel in möglichst gleicher Geschwindigkeit abläuft. Letzteres war z. B. ein Problem von Spielen die in den späten 1980ern und frühen 1990ern geschrieben wurde und auf schnelleren Prozessoren nicht mehr spielbar waren.

Literatur

• Gregory, Jason and Lander, Jeff: Game Engine Architecture. Erste Auflage. Taylor & Francis Ltd., 2009, ISBN 978-1-56881-413-1. 
• Game Programming Patterns: Game Loop
• Valente, Luis and Conci, Aura and Feijo: Real time game loop models for single-player computer games. In: Proceedings of the IV Brazilian Symposium on Computer Games and Digital Entertainment. 2005, S. 89--99 (puc-rio.br [PDF; abgerufen am 2. März 2016]). 
• Joselli, Mark and Zamith, Marcelo and Clua, Esteban and Montenegro, Anselmo and Leal-Toledo, Regina and Conci, Aura and Pagliosa, Paulo and Valente, Luis and Feijo, Bruno: An adaptative game loop architecture with automatic distribution of tasks between CPU and GPU. In: Comput. Entertain. Band 7, Nr. 4. ACM, Januar 2010, ISSN 1544-3574, S. 50:1--50:15, doi:10.1145/1658866.1658869 (acm.org [abgerufen am 2. März 2016]).