Spiel aufnehmen und abspielen

[gombolo]

Hi Leute,

ich entwickle ein TopDown-Shooter...Das Spiel ist auch sehr weite und bin schon fast fertig mit der "Mechanik".

Was noch auf meiner ToDo-Liste steht ist ein -> Replay-Modus.

Das bedeutet...das gespielte Spiel soll, wenn der Player "stirbt", wiedergegeben werden. Dann kann er sich sein Spiel noch einmal ansehen (wenn er mag).

Ich habe so was schon mal programmiert. Damals habe ich nur die Bewegung des Spielers aufgezeichnet. Bei der Wiedergaben habe ich die Steuerung durch den Spieler einfach durch die Eingabe aus der aufgezeichneten Datei ersetzt. Das führte jedoch zu (Versatz)Problemen. Diese Probleme konnte ich damals nicht lösen (wenig Wissen, keine Erfahrung, keine Lust usw...)

Das Spiel lief nicht 1:1 ab. Es gab einen Versatz in der "Zeit" und der Spieler war mal zu weit Rechts oder Links oder wo auch immer.

Meine Frage wie macht man so was?

• Soll ich die Bewegung jedes Objekts speichern? Also Gegner, Geschosse, Animation, Explosionen usw...macht man das so?

• Welche anderen Möglichkeiten gibt es

• Was ist die Voraussetzung dafür? U.U. müsse ich den Kern des Spiels umprogrammieren (z.B. Fixes Framerate, aber das würde ich dann nicht machen)

• Hat einer von Euch so was mal programmiert und möchte seine Erfahrung mit mir teilen?

[mtorc1]

Ich habe sowas selbst noch nicht implementiert, ich denke aber es hängt im Wesentlichen davon ab, was dein Spiel unter der Haube für eine Architektur einsetzt.
Man liest aber z.B. im Kontext von ECS, dass eine Replay-Funktion relativ einfach implementierbar ist. Ich kann mir vorstellen, dass wenn man die Kommunikation einzelner Systeme eines ECS konsequent über Events realisiert hat, das auch gut machbar sein sollte. Man müsste "nur" alle Events aufzeichnen und für den Replay-Modus ein eigenes System aktivieren, welches dann "nur" alle aufgezeichneten Events im richtigen Frame auslöst. Unter Umständen müssen nicht alle Events aufgezeichnet werden (z.B. ein "performAttack"-Event verursacht durch ein Kampfsystem eine gewisse Menge Schaden; das ist aber irrelevant, weil das Kampfsystem nach Berechnung der Schadenshöhe dann ein "doDamage"-Event auslöst).
Als Nebeneffekt löst man vergleichsweise einfach das Problem, dass zufällige Einflussfaktoren automatisch berücksichtigt werden (Beispiel: der Angriff verursacht zufällig 5-10 Schadenspunkte. Das Event "doDamage" beinhaltet neben Verursacher und Ziel eben auch die Schadenshöhe - der zufallsbedingte Wert wird automatisch mitgespeichert).
So müsstest du z.B. auch das Auftreten von Explosionen nicht separat aufzeichnen. Wenn deine Explosion als Folge des "doDamage"-Events getriggert wird, kommt die Darstellung einer Explosion mit so einer Implementierung ohne Mehraufwand "gratis" und von alleine.
Ich denke, eine Fixed Framerate macht die Implementierung massiv einfacher.

[gombolo]

ja...Sachen wie eine Explosion oder auch das Erscheinen eines PowerUps passieren "automatisch". Das würde so funktionieren. Wobei im Spiel selber nichts zufällig passiert. Die Bewegung der Spieler und ihr Erscheinungszeitpunkt ist immer das selbe.

Ich denke mir die ganze Zeit ->

ich müsste von jedem Objekt in jedem Frame die Position, Rotation speichern und diese dann wiedergeben. Auch die Position der Geschosse usw...die Kollisionsabfrage müsste dann so programmiert sein...das auch das im Replay-Modus funktioniert.

Ich tue mir echt schwer mir was einfallen zu lassen. Mein Gehirn sträubt sich dagegen für jedes Objekt in jedem Frame Position und Rotation zu speichern...vielleicht muss das so sein.

[mtorc1]

Wenn dein Spiel vollständig deterministisch ist, müsste es reichen, einzig und allein die Spielereingaben aufzuzeichnen. Das wird aber nur mit einem Fixed Timestep funktionieren, weil sich die Fließkommaungenauigkeiten sonst zu stark summieren.

[mtorc1]

Sorry, du hattest in deinem ersten Post ja schon geschrieben, dass du das schon einmal probiert aber mit Versatz zu kämpfen hattest. Kann sein, dass das an Floating Point (Im)Precision lag, ist aber schwer so generell zu beantworten. Klingt nach einer ziemlich schmerzhaften Debugging-Session :)

[gombolo]

Sorry, du hattest in deinem ersten Post ja schon geschrieben, dass du das schon einmal probiert aber mit Versatz zu kämpfen hattest. Kann sein, dass das an Floating Point (Im)Precision lag, ist aber schwer so generell zu beantworten. Klingt nach einer ziemlich schmerzhaften Debugging-Session :)

Das Spiel selber läuft immer gleich ab. Es gibt praktisch nicht was zufällig passiert. nur in einer Schussfolge gibt es einen Rand, aber der wird vor jedem Levelstart wieder auf "0" gestellt. Ist also auch kein echter Zufall.

Ich fange mal an nur den Spieler aufzuzeichnen und mal sehe wie weit ich komme. Ich habe keine Lust zu viel Zeit damit zu verbraten. Wenn es nicht hinhaut lass ich diesen Teil einfach weg (keine Lust auf eine schmerzhafte Debugging-Session). Obwohl mich das schmerzen würde...man will ja alles perfekt machen ;)

EDIT: Mit Aufzeichnen meine ich nicht die Position des Spielers sondern die Eingabe des Spielers. Mal sehen ob das klappt...

[x1m4]

Im Optimalfall läuft dein Spiel deterministisch, heißt das Spiel wird simuliert und das einzige an externen Variablen sind z.B. Spieler Eingaben.
Häufig ist es so, dass die Spiel Logik getrennt vom Rendern ist, z.B. wird die Spiellogik mit 30 TPS berechnet, während mit 60 FPS gezeichnet wird.

Da die Logik in dem Fall nur halb so schnell läuft wie das Rendern, wird zwischen den Frames extrapoliert. Als Beispiel, wenn du ein Geschoss hast, dann hat es eine Richtung und Geschwindigkeit. Ohne Extrapolation würde sich das Geschoss "ruckelig" bewegen, deshalb extrapolierst du die zeitliche Differenz zwischen Logik und Rendern, so dass sich das Geschoss visuell flüssig bewegt.

Für eine Art Replay musst du dann lediglich die Start-Variablen des Spiels (den 0 Zustand) speichern, und die Zeitstempel der Kommandos von Spielern. Falls möglich, kannst du optional auch noch einbauen, dass man anstatt in der Zeit nur vorwärts spulen kann, auch die Möglichkeit hat, rückwärts zu spulen. Das eignet aber nicht für alle Simulationen und kann allgemein in der Umsetzung sehr kompliziert sein.

Viele Multiplayer Spiele laufen heutzutage deterministisch, da hierbei die Spieler selbst die Simulation berechnen, und der Server lediglich die Eingaben der Spieler verteilt und dafür sorgt, dass das Spiel synchron läuft (der Server gibt quasi den Simulations-Takt vor).

Eine vollständig deterministische Simulation erfordert ebenfalls, dass du selbst das Spiel, welches bei dir Lokal läuft nicht verändern kannst. Heißt wenn du eine Eingabe machst, wird das erst an den Server gesendet. Der Server schickt dann im nächsten Tick dir, und allen anderen Spieler deine Eingabe zu, welche dann in den lokalen Simulationen ausgeführt werden. Hierdurch entstehen allerdings schnell Lags, da deine Eingabe nicht direkt ausgeführt wird, sondern erstmal einen Roundtrip zum Server machen muss.

Gegen dieses Problem hilft dann sogenannte Client-Side Prediction. Du verpasst deiner Simulation zusätzliche Parameter, welche es ermöglichen zwischen der Zeit von der Logik, sowie der Verzögerung zwischen dir und dem Server zu extrapolieren. Die Prediction der Simulation darf allerdings keinen direkten Effekt auf die Simulation selbst haben, sondern ist lediglich ein weiteres visuelles Hilfsmittel, um es schöner aussehen zu lassen.

[gombolo]

Im Optimalfall läuft dein Spiel deterministisch...

ja das ist so...ist ein Top-Down-Shooter und "Eigentlich" ist es bei solchen Spielen so, dass der Spieler die Bewegung der Gegner sich einprägt und dann im Level so weiter kommt. Wäre blöd wenn nach jedem Start eine andere Gegnerformation angreift... :D

Also macht das schon mal vieles einfacher. :)

[Schrompf]

Determinismus kannst Du mit Fließkomma-Zahlen allgemein nicht wirklich erreichen. Du müsstest alle Mathematik im Spiel auf Festkomma, also Integer, umstellen. Und selbst dann - ich spreche da aus Erfahrung - übersieht man vereinzelt ein Zufallselement oder eine Zeitabhängigkeit, und das Replay läuft doch aus der Synchronizität raus. Ich halte die "echte" Aufnahme für die einzige Methode. Also jeden Simulationsschritt die Parameter aller beweglichen Dinge auf dem Bildschirm speichern und nachher wieder abspielen. Zusammen mit den Ereignissen, die die Spielsituation verändern - also neu erscheinende Gegner, treffende Schüsse, eingesammelte Items - ist das leider eine fiese Fleißarbeit.

[gombolo]

...und das Replay läuft doch aus der Synchronizität raus. Ich halte die "echte" Aufnahme für die einzige Methode...

Das habe ich befürchtet...die Erfahrung hatte ich auch bei meiner ersten Implementierung eines Replay-Systems. Das liegt mehrere Jahre zurück und ich Schlussfolgerte, das die nicht passende Synchronisation an meiner Programmierkunst lag...vielleicht war einfach der Ansatz falsch, aber ein "echtes" Aufnahme-System möchte ich nicht erstellen. Vor allem nicht für ein Hobby-Projekt.

Es ist ja nicht nur die Bewegung der einzelnen Objekte...ich habe ein paar animierte Objekte im Spiel...die müsste ich auch betrachten...Bohaaaaa das wird mir dann doch zu viel.

EDIT habe jetzt ein Replay-System fertig. Ich mache das über die Steuerung der Spielers. Ich speichere welche Taste wann gedrückt wurde. Im Replay-Modus übernimmt die Aufzeichnung die Steuerung des Spielers. Bis jetzt sieht es gut aus...aber ob es passt sieht man wenn man mehrere Durchläufe simuliert hat. Mal sehen...die Implementierung selber ist wirklich easy...ist nur Werte in einem Array speichern und wieder rauslesen...mir macht nur die Größe der Datei sorgen. Muss mal paar Messungen machen...und einfach ist es weil ich nur den Spieler betrachte und auch nur die Tasten abfrage.

EDIT / EDIT es ist doch nicht so gut. Das mit dem speichern der Tasten geht doch nicht so einfach. Es sah sehr vielversprechend aus, aber bei einer näheren Betrachtung merkt man...es ist doch nicht 1:1 das was man gespielt hat. Vor allem wenn man schnell hintereinander mehrere Tasten drückt. Man muss wohl doch alles speichern. Von mir aus zwischen den Bewegungen interpolieren um den Speicherbedarf gering zu halten, aber das erfordert sehr viel Arbeit und ist, meiner Meinung nach, ein eigenes Projekt und nicht einfach nice to have...vor allem nicht für ein Hobbyprojekt. :)

[Tiles]

Mh, du arbeitest doch mit Unity wenn ich mich recht erinnere. Man muss ja nicht jedesmal das Rad neu erfinden :)

https://assetstore.unity.com/packages/t ... tem-158370

Das ist nur mal ein schnelles Beispiel. Da gibts sicher mehr. Vielleicht sogar kostenlos.

[gombolo]

hmmm...ok....ich denke das ist nicht das was ich benötige. Ich will das ganze Spiel aufnehmen und wiedergeben. Meine Objekte werden aus einem Pool geholt und bewegen sich nicht über die Physik. Ich vermute der Author macht seine Aufnahmen über die Physik, aber ich habe ihn mal angeschrieben was seine Meinung dazu ist.

Trotzdem macht es Spaß selber zu entwickeln :) ich nutzte gar kein fremden Code. Sicher schaue ich mir hier und da was ab, aber das Komplette Pool-System...das Gamemanagement...Enemy movement...Levelsystem...Highscore-Eingabe auch die Grafiken und die 3D Modelle erstelle ich selber. Wobei ich bei der Grafik auch mal gerne bei Dir im Forum Fragen stelle ;) Nur mit der Musik...das kann ich nicht :D

[Tiles]

Wie gesagt, das war nur ein Schnellschuss. Da gibts im Asset Store bestimmt noch viel mehr. Und wenn du unbedingt alles selber machen willst, du kannst dir ja die Ideen von den Scripts borgen ;)

Um das Off Topic Thema Musik ein wenig breit zu treten, Musik kannst du bestimmt auch. Das ist viel Mathe und Patterns. Zur Not ziehst du einfach deinen Lieblingssong in eine Timeline, markierst dir die Songstruktur und baust das schlicht mit neuen Melodien nach. Der primitivste Song ist Intro, Vers 1, Refrain, Vers 2, Refrain, Outro. Und dazwischen kannst du dich kreativ mit Bridges und Solos austoben.

Du brauchst halt das geeignete Equipment. Ich bin mit FL Studio unterwegs. Aber von Bandlab gibts immer noch die DAW (so heissen die Dinger zum Musik machen, das steht für Digital Audio Workstation) Cakewalk für Lau. Ist allerdings ein wenig Tricky bis das Ding endlich installiert ist. https://www.bandlab.com/products/cakewalk

Die zweitbeliebteste DAW hinter FL Studio und im Low Budget Bereich angesiedelt ist Reaper. Da gibts eine endlose Demo von. Oder gab es zumindest mal. https://www.reaper.fm/

Und ansonsten musst du dir halt die passenden Instrumente suchen. Kostenlos gehts hier los. Damit lässt sich schon was anstellen https://plugins4free.com/

Aber die guten Sachen kosten richtig Geld. Ich habe erst wieder dieses Frühjahr nen Tausender in Equipment investiert. Verdammtes GAS ^^

[gombolo]

Um das Off Topic Thema Musik ein wenig breit zu treten, Musik kannst du bestimmt auch. Das ist viel Mathe und Patterns. Zur Not ziehst du einfach deinen Lieblingssong in eine Timeline, markierst dir die Songstruktur und baust das schlicht mit neuen Melodien nach. Der primitivste Song ist Intro, Vers 1, Refrain, Vers 2, Refrain, Outro. Und dazwischen kannst du dich kreativ mit Bridges und Solos austoben.

Du brauchst halt das geeignete Equipment. Ich bin mit FL Studio unterwegs. Aber von Bandlab gibts immer noch die DAW (so heissen die Dinger zum Musik machen, das steht für Digital Audio Workstation) Cakewalk für Lau. Ist allerdings ein wenig Tricky bis das Ding endlich installiert ist. https://www.bandlab.com/products/cakewalk

Die zweitbeliebteste DAW hinter FL Studio und im Low Budget Bereich angesiedelt ist Reaper. Da gibts eine endlose Demo von. Oder gab es zumindest mal. https://www.reaper.fm/

Und ansonsten musst du dir halt die passenden Instrumente suchen. Kostenlos gehts hier los. Damit lässt sich schon was anstellen https://plugins4free.com/

ja das ist ja cool...die Links schaue ich mir an...Danke!

[marcgfx]

Deterministisch ist ganz schön schwer imho. Ich habe damals für mein Rennspiel Aufnahmen gemacht. Dabei habe ich pro Frame die Zeit und pro Objekt Koordinaten, Winkel und Animationsframe gespeichert. Ist relativ simpel und verlässlich.

[gombolo]

Deterministisch ist ganz schön schwer imho. Ich habe damals für mein Rennspiel Aufnahmen gemacht. Dabei habe ich pro Frame die Zeit und pro Objekt Koordinaten, Winkel und Animationsframe gespeichert. Ist relativ simpel und verlässlich.

Hast Du nur den Spieler aufgenommen? Oder alle Objekt die im Spiel vorhanden waren?

[marcgfx]

Hast Du nur den Spieler aufgenommen? Oder alle Objekt die im Spiel vorhanden waren?

Statische Elemente wurden einfach am Anfang einmal gespeichert. Alles was dynamisch war, musste pro Frame gespeichert werden. Danach habe ich die Daten gezippt.

Falls die Datenmenge ein Problem sein sollte:
Einzelne "Spuren" sequentiell speichern um das zip kleiner zu halten. Also alle x Werte des selben Objekts am Stück.
Du kannst auch nur die Veränderung der Werte speichern, was aber den Nachteil hat, dass du nicht an jegliche Stelle in der Aufnahme springen kannst. Da kann man sich mit Key-Frames die absolute Werte alle 100 Frames speichern wieder abhelfen.

[gombolo]

Statische Elemente wurden einfach am Anfang einmal gespeichert. Alles was dynamisch war, musste pro Frame gespeichert werden.

Ich entnehme meine Objekte aus einem Pool. Also kann es sein das ein Objekt in einem Level mehrmals verwendet wurde. Somit kann ich die Replay-Daten nicht im Objekt ablegen.

Das erstellen der Objekte im Spiel passiert Zeitgesteuert. Die Objekte selber bewegen sich auf einer festgelegten Route. Dieses System kann ich für das Replay nicht mehr verwenden?!

Ich müsste dann praktisch für das Replay ein eigenes System programmieren in dem ich die Daten aus der Aufzeichnung dazu verwende um die richtigen Objekte aus dem Pool zu nehmen und zu bewegen.

[marcgfx]

Wenn du Objekte hast die immer genau das gleiche machen und du zu jedem Zeitpunkt berechnen kannst was sie machen, dann sind das eigentlich statische Objekte :) (evtl. braucht es einfach eini Init-Zeit die du speichern musst)

[gombolo]

Wenn du Objekte hast die immer genau das gleiche machen und du zu jedem Zeitpunkt berechnen kannst was sie machen, dann sind das eigentlich statische Objekte :) (evtl. braucht es einfach eini Init-Zeit die du speichern musst)

ok...dann sind die Gegner statisch...diese bewegen sich, jedoch immer gleich. Probleme macht mir der Spieler. Das Spielläuft immer gleich ab, aber wenn ich den Spieler wiedergebe, dann passt es nicht. Mal verpasst er den PowerUp und mal wird er getroffen, obwohl im eigentlichen Spiel das feindliche Geschoss nur knapp vorbei flog.

Ich habe jetzt die Eingabe gespeichert. Dann versuche ich mal die Position vom Spieler zu speichern und das dann Zeitabhängig zu bewegen.

Hier mal ein kurzes Video vom Spiel. Die Qualität ist schlecht, aber die Bewegung der Gegner ist jedes mal das selbe.

[starcow]

Determinismus kannst Du mit Fließkomma-Zahlen allgemein nicht wirklich erreichen.

Wie meinst du das genau Schrompf?
Es leuchtet mir schon ein, dass es aus rein parktischen Gründen keinen Sinn macht, sich auf diesen Determinismus zu verlassen... Aber müsste es streng genommen nicht auch mit Fliesskomma-Zahlen 100% deterministisch ablaufen? Oder verstehe ich deine Aussage falsch? Der Recher ist ja, von extrem seltenen "Bitflips" mal abgesehen (die dann in den allermeisten Fällen von der Fehlerkorrektur erkannt werden), eine 100% deterministische Maschine - auch mit Fliesskommazahlen. Am Ende des Tages sind ja auch Fliesskommazahlen nur Nullen und Einsen im RAM - einfach anders interpretiert.
Wieso soll das denn ein Unterschied machen, ob Fliesskomma, Festkomma oder Integer?

[Schrompf]

Da bin ich ein bisschen unsicher, aber ich glaube, ich habe es in freier Wildbahn schon gesehen:
a) verschiedene Prozessoren scheinen den Fließkomma-Standard leeeiiiicht unterschiedlich auszulegen in irgendwelchen Grenzfällen. Juckt Dich erst, wenn Du das Replay auf Platte schreibst und ein anderer Rechner es ausführt, aber für mein Szenario war's eine Gefahr.
b) Die x86-Prozessoren haben aus uralten Zeiten mehrere Fließkomma-Betriebsmodi, zwischen denen global umgeschaltet werden kann. Es kann Dir passieren, dass der aufdringliche Druckertreiber in Deiner Taskleiste den umschaltet, während Du zockst. Macht wieder nur in Grenzfällen einen Unterschied, aber zerstört Dir den Determinismus selbst auf der lokalen Maschine.

[marcgfx]

ok...dann sind die Gegner statisch...diese bewegen sich, jedoch immer gleich. Probleme macht mir der Spieler. Das Spielläuft immer gleich ab, aber wenn ich den Spieler wiedergebe, dann passt es nicht. Mal verpasst er den PowerUp und mal wird er getroffen, obwohl im eigentlichen Spiel das feindliche Geschoss nur knapp vorbei flog.

Ich habe jetzt die Eingabe gespeichert. Dann versuche ich mal die Position vom Spieler zu speichern und das dann Zeitabhängig zu bewegen.

Wenn du nur die Eingabe speicherst müssen alle Bedingungen gleich sein damit du das gleich Ergebnis bekommst. Wenn du irgendwo delta-Time Werte hast wird es schwierig. Speicher lieber die Positionen und den Zeitschritt. Bei der Wiedergabe kannst du auch mit einem anderen Zeitschritt abspielen, dann musst du einfach zwischen den gespeicherten Zeitschritten interpolieren.

Für mich hört es sich so an als ob du das Spiel einfach normal spielen willst mit den gespeicherten Eingaben. Das wird nur gehen wenn alles determistisch ist, was sehr schwer zu bewerkstelligen sein dürfte. Du sagst die Gegner bewegen sich immer gleich, aber stimmt das wirklich? Kannst du zu jedem Zeitpunkt sagen wo sich ein Gegner befinden wird, oder ist die Position abhängig von der letzten Position? Das gleiche gilt dann für die Schüsse. Ganz kleine Änderungen im Zeitschritt kann ziemlich viel verändern. Framerate unabhängiger Code ist ganz schön kompliziert. Ich hab es für Devader so gut wie ich konnte gemacht, aber ich würde niemals glauben es wäre absolut deterministisch.

[starcow]

Da bin ich ein bisschen unsicher, aber ich glaube, ich habe es in freier Wildbahn schon gesehen:
a) verschiedene Prozessoren scheinen den Fließkomma-Standard leeeiiiicht unterschiedlich auszulegen in irgendwelchen Grenzfällen. Juckt Dich erst, wenn Du das Replay auf Platte schreibst und ein anderer Rechner es ausführt, aber für mein Szenario war's eine Gefahr.
b) Die x86-Prozessoren haben aus uralten Zeiten mehrere Fließkomma-Betriebsmodi, zwischen denen global umgeschaltet werden kann. Es kann Dir passieren, dass der aufdringliche Druckertreiber in Deiner Taskleiste den umschaltet, während Du zockst. Macht wieder nur in Grenzfällen einen Unterschied, aber zerstört Dir den Determinismus selbst auf der lokalen Maschine.

Ok, danke. Das leuchtet ein.

[Alexander Kornrumpf]

the more you know ...

[Krishty]

Nur kurz weil unterwegs aber "float ist nicht deterministisch" halte ich weitgehend für Unsinn. Jede Menge Spiele setzen auf float-Determinismus und funktionieren damit.

Wenn ich bei sowas nachhake, ist normalerweise immer irgend ein anderes Problem schuld. Am weitesten zu tatsächlichen Problemen bin ich hier vorgedrungen: https://encode.su/threads/3409-Compress ... #post65703

Darum: 1. benutzt keine FPU (tun GCC/MSVC sowieso seit Jahren nicht mehr, auch nicht im 32-Bit-Modus)
2. Setzt fp:strict oder Konsorten
3. Setzt die C-#defines für FP_CONTRACT & Co. korrekt

Schrompfs Druckertreiber passiert nur, wenn die DLL in den Prozess injiziert wird. Das kann z.B. beim File Open-Dialog passieren, aber sonst eher nicht. C# gibt sogar volle Garantie, dass das *nicht* passieren wird, indem sie nach zahlreichen Win32-Aufrufen den FP-Mode erneut setzen.

[Schrompf]

Oh, gut zu wissen, danke. Ich hab's nicht in dem Detail verfolgt, es war mir nur aufgefallen. Aber ich bin auch steter Verfechter von fp:fast, weil's bei mir - wenn ich mich recht erinnere - massive Performance-Verbesserungen gebracht hatte.

[Jonathan]

Ich habe neulich nochmal Tomb Raider 2 gespielt (das von 1997) und bin durch Zufall über ein Feature gestoßen, dass ich gänzlich vergessen hatte: Wartet man im Hauptmenü lange genug startet das Spiel einen Demo Modus, in dem ein zufälliges Level geladen und angespielt wird. Das ganze scheint inspiriert von alten Arcade-Automaten auf denen ja auch Demos liefen bis man seine Münzen eingeworfen hat (zu Werbezwecken halt).

Ich habe mich ein wenig gefragt, warum die Entwickler Zeit in ein Feature investiert haben das im Grunde genommen ein Easter-Egg ist. Aber die Antwort ist wohl, dass so ein Aufnahme / Demomodus trivial ist, wenn das Spiel von Anfang an auf eine bestimmte Art programmiert ist (feste Framerate, deterministische Spiellogik, alles andere was hier besprochen wurde), aber direkt furchtbar aufwändig wird, wenn diese Dinge nicht zutreffen.

Das ist ein bisschen wie Multiplayerunterstützung, über die auch jeder sagt, dass sie von Anfang an in die Engine eingebaut sein muss, wenn man will, dass es jemals funktioniert. Wobei ich gerade denke, dass man, wenn man schon einen Multiplayermodus hat, einen Demomodus auch immer sehr leicht einbauen kann, man muss nur die Befehle vom Server abspielen.

[Schrompf]

Quake hat das ja auch immer gemacht, Unreal genauso. Bei Netzwerk-Spielen hast Du halt wieder den Vorteil, dass die Netzwerk-Pakete das Spielgeschehen sowieso authentisch orginalgetreu auf einem fremden Rechner rekonstruieren müssen. Die dann einfach mitzuschneiden und halbwegs zeitgetreu lokal einzuspielen ist ein Nobrainer.

[gombolo]

dass so ein Aufnahme / Demomodus trivial ist, wenn das Spiel von Anfang an auf eine bestimmte Art programmiert ist (feste Framerate, deterministische Spiellogik, alles andere was hier besprochen wurde), aber direkt furchtbar aufwändig wird, wenn diese Dinge nicht zutreffen.

Auf den Punkt gebracht...wenn alles passt, dann ist es wirklich einfach. In 30Minuten hast du den Code für die Wiedergabe programmiert, aber der Teufel steckt wie immer und in wie in jedem Projekt im Detail :D Ich habe jetzt eine Kopie vom Projekt erstellt und versuche den Code für die Wiedergabe zu modifizieren.