Game Loop

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Als Game Loop (engl. für ‚Spiel-Schleife‘) wird die Ereignisschleife eines Computerspiels bezeichnet. 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

Beschreibung[Bearbeiten | Quelltext bearbeiten]

Computerspiele bestehen in aller Regel aus vielen, gleichzeitig und in Echtzeit arbeitenden Subsystemen, die beispielsweise für die Ein- und Ausgabe, die Bildsynthese, die Animationen, die Physik-Simulation oder auch für die Netzwerkkommunikation in Mehrspielerpartien zuständig sind. All diese Subsysteme werden von einem zentralen Programmteil angesteuert, der durch seine zentrale Rolle häufig Game Loop genannt wird. Dieser steuert alle Subsysteme solange und in der Frequenz an, wie die jeweiligen Systeme benötigt werden. Solange das Spiel läuft, läuft also auch die Game Loop. Vereinfacht ausgedrückt ist die Game Loop demnach eine „ewige“ Schleife, die nach Initialisierung der Spieldaten gestartet wird und erst durch einen internen oder externen Eingriff wieder beendet wird.[1]

Der wesentliche Unterschied zu herkömmlichen Computeranwendungen ist dabei, dass die Game Loop zwar mitunter auch Benutzereingaben verarbeitet, aber nicht auf diese „wartet“. Die Schleife läuft weiter, auch wenn der Benutzer keine Eingabe tätigt. Ansonsten würde eine simulierte 3D-Welt auf dem Bildschirm „einfrieren“, sobald der Spieler keine Eingabe mehr vornimmt.[2]

Durch die zentrale Bedeutung für das Programm und eine vielfache Ausführung in jeder Sekunde, hat die Effizienz der Game Loop entscheidende Auswirkung auf die Performanz des Spiels. Herkömmliche Spiel-Engines und auch Spielkonsolen stellen Entwicklern daher eine bereits optimierte Game Loop zur Verfügung.[2]

Ein Durchlauf der Game Loop lässt sich demnach in drei Phasen gliedern. Eine vereinfachte und auf die drei essenziellen Phasen reduzierte Game Loop könnte wie folgt aussehen.[2]

while (true)
{
   processInput();
   update();
   render();
}

Eingabe[Bearbeiten | Quelltext bearbeiten]

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. Klassischerweise also Tastatur und Maus, ein Gamepad oder der Touchscreen. Bei komplexeren Systemen wie VR-Headsets kommen hier jedoch auch weitere Geräte wie ein Tracking-System, Mikrofone zur Sprachsteuerung und Gestenerkennung hinzu. Wesentliche Aufgabe dieser Phase ist es, Eingaben, die zu unterschiedlichen Zeitpunkten erfolgten, zu einer konsistenten Information zusammenzufassen.

Simulation[Bearbeiten | Quelltext bearbeiten]

In dieser Phase wird auf Grundlage der eventuell erfolgten Eingaben des Benutzers sowie Informationen der simulierten Szene ein neuer Zustand des Spiels berechnet. Wichtig ist hier, dass diese Phase auch bei Ausbleiben von Benutzereingaben ausgeführt wird, diese also nicht erst durch die Benutzereingabe angestoßen wird. Typische Sub-Systeme, die in dieser Phase aufgerufen werden, sind die Anwendungslogik, Animation und Physik-Simulation.

Ausgabe[Bearbeiten | Quelltext bearbeiten]

In der dritten Phase erfolgt die Ausgabe der neu berechneten Simulation. Dazu gehört unter anderem die Aktualisierung der Anzeige oder die Ausgabe von Audio-Signalen. Welche Ausgabekanäle in welcher Form vorhanden sind, unterscheidet sich wieder stark zwischen den jeweiligen Anwendungsbereichen.

Frequenzbegrenzung[Bearbeiten | Quelltext bearbeiten]

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.[1][2] Letzteres war z. B. ein Problem von Spielen, die in den späten 1980ern und frühen 1990ern geschrieben wurden und auf schnelleren Prozessoren durch die höhere Taktrate nicht mehr spielbar waren.

Literatur[Bearbeiten | Quelltext bearbeiten]

  • Jason Gregory: Game Engine Architecture. 3. Auflage. CRC Press, 2019, ISBN 978-1-138-03545-4, 8 The Game Loop and Real-Time Simulation, S. 252–558 (englisch).
  • Robert Nystrom: Game Programming Patterns. Genever Benning, 2014, ISBN 978-0-9905829-0-8, 9. Game Loop (gameprogrammingpatterns.com [abgerufen am 23. August 2021]).
  • 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.

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. a b Jason Gregory: Game Engine Architecture. 3. Auflage. CRC Press, 2019, ISBN 978-1-138-03545-4, 8 The Game Loop and Real-Time Simulation, S. 252–558 (englisch).
  2. a b c d Robert Nystrom: Game Programming Patterns. Genever Benning, 2014, ISBN 978-0-9905829-0-8, 9. Game Loop (gameprogrammingpatterns.com [abgerufen am 23. August 2021]).