spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

1) Wieso sollte man etwas berechnen, was nicht gebraucht wird?
2) Welches Buch?

1) Du kannst ja aber nicht mit Gewissheit vorher schon sagen, ob eine Eingabe eine Auswirkung hat oder nicht. Das entscheidet ja die KI. Wenn sie der Meinung ist, dass sie mehr Eingaben benötigt, dann brauch sie natürlich auch nichts zu berechnen und kehrt sofort wieder zurück. Aber genau das Gegenteil kann ja eventuell ebenfalls der Fall sein, dass eine Eingabe eben doch eine sofortige Änderung bewirkt.
Stell dir z.B. ein Shooter-Game vor, wo jemand auf der Lauer liegt. Der Zustand des Gegners soll sich an der Farbe des Namens über dem Kopf des Gegners ablesen lassen. Ein einziger Klick auf den Feuer-Knopf könnte reichen um den Status von "idle" auf "aggressive" umzuschalten, was sich dann aber sehr wohl auf die Darstellung auf dem Bildschirm auswirken könnte. Wie gesagt, die Entscheidung darüber, ob sich etwas tut oder nicht, die wird erst während der Berechnung getroffen.

Das hängt sicherlich von deinem konkreten Problem ab. Pauschalisieren (Meh, das Firefox-Wörterbuch schreibt das Wort immer noch falsch... oder kennt jemand "Pauschaleisiren"?) kann man das nicht.

Der große Nachteil, den ich in einer solchen Trennung sehe ist der, dass der Teil des Codes, der über eine solche Trennung entscheidet
(1) ja damit selbst eine Art Berechnung oder "Move-Funktion" darstellt, wenn man so will
und
(2) dann Dinge über die Funktionsweise der Move-Funktion wissen muss, die ihn eigentlich nichts angehen, sondern die nur in die Move-Funktion hinein gehören. Ohne dieses Wissen wäre eine solche Trennung ja gar nicht möglich.

Eine Abarbeitung nach Prioritäten oder auch parallel zum Rendering ist sicherlich möglich und wird auch praktiziert. Allerdings bleibt die Entscheidung darüber, was eigentlich wichtiger ist dann doch der Move-Funktion selbst überlassen. Denn nur diese kann das wissen, außer man will das Problem der Wissens-Redundanz aus (2) wieder einführen.

Normalerweise werden die meisten Spiele mit diesem Prinzip umgesetzt. So ein Game-Loop hat halt einfach den Vorteil, dass Logik und Zeichnen getrennt sind. Das ist nicht nur was, was in Hobbyprojekten so umgesetzt wird. Auch große Spieleschmieden benutzen diese Technik. Nur weil es einfach ist heisst es nicht das es schlecht ist Auch wenn viele Leute denken je komplexer und wichtiger sich was anhört umso besser ist es, was aber ein typisches Problem von uns deutschen ist Aber gut darum gehts ja nicht. Es gibt natürlich auch andere Techniken wie du dein Spiel aufbauen kannst.
Stell dir vor du programmierst ein Kartenspiel und benutzt dafür normale Gui-Komponenten. Zum Beispiel möchtest du ein Skat-Spiel mit Qt programmieren. Da würdest du dann keinen Game-Loop haben, sondern eher auf andere Designs setzen. Dort würde sich zum Beispiel Model-View-Controller anbieten. Zu MVC findest du genug Sachen bei google. Dieses Design wird bei vielen Anwendungen eingesetzt, kann aber mit ein bischen Anpassung auch bei manchen Spielen eingesetzt werden. Du könntest dir dein Design auch ganz anders einteilen. Als Beispiel jede Klasse zeichnet sich selber und hat die eigene Logik in sich. Jetzt läufst du jedes Objekt einfach durch und sagst "Führe das Objekt aus". Dadurch wird automatisch alles für das Objekt berechnet und es wird direkt gezeichnet. Das wäre natürlich ein super bescheidener Ansatz, aber er könnte je nach Art des Spiels funktionieren(Aber bitte niemals einsetzen ). Die Sache ist wie du dein Spiel nun aufbaust liegt an dir, du solltest aber mit ein paar Techniken vertraut sein. In den meisten Fällen wirst du auf die Game-Loop Variante mit Update und Render zurückgreifen. Versuchs doch einfach mal so. Denke dir nen anderes Design aus und versuch damit einfach mal ein kleines Spiel zu schreiben. Pong oder vielleicht Tetris oder irgendwas. Dann siehst du schnell wie geeignet sowas ist Aber besser erstmal nur an kleinen Projekten ausprobieren.