15 Mai

Real Time vs Turn Based Games

Jedem werden die wesentlichen Unterschiede zwischen einem Real Time und einem Turn Based Spiel bewußt sein. Jedoch gibt es auch diverse Unterschiede auf die man während der Programmierung achten muss. Welche Probleme können auftreten und was sollte man in der Planungsphase unbedingt bedenken?

[ad#contentadbig]

Real Time Game

Ein Echtzeitspiel lebt von der Bildfrequenz. Jeder kennt Real Time Games wie die Mario Reihe, Sonic, Egoshootern und so weiter. Kein Spiel würde Spaß machen, wenn z.b. Sprünge unterschiedliche lange dauern würden. Man muss den Bildschirm diverse Male neuzeichnen. Damit das Menschliche Gehirn eine fließende Bewegung wahrnimmt benötigt man circa 25 Bilder in der Sekunde und einen Egoshooter kann man eigentlich erst ab 60 FPS (Frames per Second) gespielt werden. Das bedeutet für den Spieleentwickler, dass, ausgegangen von den 25 FPS, jede Berechnungsgruppe maximal 40 Millisekunden dauern darf. Jede bewegliche Figur und jedes Bild müssen somit in dieser Zeit gezeichnet werden. Jegliche Zugriffe und Verarbeitungen von Variablen und Funktionen müssen den schnellsten Weg gehen.

Turn Based Game

Die Platte der Rundenbasierten Spiele ist ebenfalls sehr Umfangreich und wird meist für Brettspiele oder ähnliches angewendet. Bekannte Gesellschaftsspiele wie Dame, Mühle oder Kartenspiele funktionieren nach diesem Prinzip. Das Bild muss bei diesen Spielen erst nach einer Aktion neu gezeichnet werden. Dadurch können Berechnungen etwas mehr Zeit in Anspruch nehmen. Eine Berechnungszeit von 100 oder 200 ms nimmt der Nutzer in diesem Fall nicht wahr.

Real Time Game vs Turn Based Game

Bei Rundenbasierten Spielen kann „gewohnter“ Programmieren. Man kann sich eine schöne Klassenhierarchie ausdenken und schön Objektorientiert die Zustände verändern und die neuen Zustände nach einer Aktion darstellen. Die Turn Based Games sind in der Entwicklung mit normalen Apps vergleichbar, die nur etwas darstellen und dann auf eine Interaktion warten wie dem Ausfüllen eines Eingabefeldes oder den Klicken eines Buttons. Bei den Echtzeitspielen muss man etwas linearer programmieren. Man muss darauf achten, dass Zugriffe auf Variablen so schnell wie möglich erfolgen. Jeder zusätzliche Aufruf einer Funktion, jedes Erzeugen einer Variablen und jeder Zugriff darauf kosten Zeit – die sehr begrenzt ist.
Wir sehen also, dass Speicherzugriffe Zeit kosten. Hier ein paar Vorschläge was man bei der Echtzeitspielprogrammierung beachten sollte :

  • Erzeuge keine neuen Variablen
  • Nutze Schleifen anstelle von Rekursionen
  • Arbeite ohne Interfaces

Diese Liste kann man noch beliebig erweitern, sie soll jedoch exemplarisch für das Hauptproblem stehen. Denn alle Punkte beinhalten die Kernaussage : Reservier keinen neuen Speicher zur Laufzeit!
Das der erste Punkt neuen Speicher reserviert sollte jedem klar sein. Bei genaueren Überlegen ist der zweite Punkt identisch zum ersten, denn für eine Iteration wird immer eine neue Variable des Typs angelegt. Der dritte Punkt hat weniger mit dem Speichererzeugen als mit dem Speicherzugriff zu tun. Bei einem Interface wird die entsprechende Funktion aufgerufen, und diese muss dann die Implementation in der Klasse finden, logischerweise kostet dies Zeit. Zeit die man bei der Echtzeitprogrammierung nicht hat und mit dieser feingliedrigen objektorientieren Programmierung verschwendet.
Viele werden sich jetzt fragen, warum das Reservieren von Speicher soviel Zeit frisst. Das Problem ist nicht das Reservieren, sondern das Freigeben! Der garbage collector von Java sammelt alle Objekte die nicht mehr benötigt werden und gibt diese irgendwann wieder frei.

dalvikvn Free Memory Garbage Collector

dalvikvn Free Memory Garbage Collector


Wie der Screenshot zeigt kostet das Freigeben des Speichers in diesem simplen Fall circa 100 ms. Es kann jedoch bis zu 500 Millisekunden dauern. Das bedeutet den Tod eines jeden Echtzeitspiels.

Wie kann man Speicheroptimiert entwickeln?
Für viele wird das, was ich nun schreibe wohl ein sträuben der Nackenhaare hervorufen. Leider ist es anders kaum lösbar.
Man sollte darauf achten möglichst auf globale Variablen zuzugreifen. Zusätzlich sollten Funktionsaufrufe so selten wie möglich genutzt werden. Komplexe Berechnungen wie die Collusion Detection sollten nicht ausgelagert werden. Zudem sollte man darauf achten so wenig unnötige Berechnungen wie möglich durchgeführt werden.
Im großen und ganzen sollte man unter Beachtung dieser Punkte dazu in der Lage sein bei einfachen Echtzeitspielen 50 bis 90 FPS zu erreichen. Eine Menge kann man auch noch durch die Verwendung von Threads usw optimieren.

Fazit

Manchmal muss man in der Entwicklung einen Schritt zurückmachen. Leider ist es oft Notwendig einen Kompromiss zwischen theoretischer Ideallösung und der Praxis zu schließen. Gerade in der IT gibt es dafür tausende von Beispielen.
Falls sich jemand näher mit der Real Time Programmierung unter Android beschäftigen möchte, den kann ich nur das nachfolgende Video von Chris Pruett von der Google I/O 2009 empfehlen.


In dem Video werden Erfahrungen in der Echtzeitprogrammierung während des Erstellungsprozessen von Replica Island geteilt.
Ich werde meine Erfahrungen mit der Echtzeitprogrammierung und der Rundenbasierten Programmierung regelmäßig im Milestone-Blog.de teilen.
Falls sich schon jemand vorher mit dem Thema Android Entwicklung auseinander setzen möchte, dem empfehle ich die Bücher Android 2: Grundlagen und Programmierung und Android. Anwendungen für das Handy-Betriebssystem erfolgreich programmieren.
Informative Bücher über die Spieleentwicklung habe ich leider noch nirgends gefunden. Falls ihr also noch Fragen habt hinterlasst einen Kommentar.




2 Kommentare zu “Real Time vs Turn Based Games”

  1. 1
    Mogoh sagt:

    „Nutze Schleifen anstelle von Iterationen“
    Meinst du vielleicht: Nutze Iterationen an stelle von Rekursion ?

    Denn für mich sind Schleifen und Iterationen das gleiche.

  2. 2
    Jens sagt:

    Ich meine natürlich Iterationen statt Rekursionen und auch foreach Konstrukte. Danke für den Hinweis, dies korrigiere ich sofort

Hinterlasse ein Kommentar