Die 3D-Ansicht hält sechzig Bilder pro Sekunde. Anschauen kann man sie trotzdem noch nicht.
Der zweite Renderer ist fertig. Darunter dasselbe Spiel, zwei Arten, es zu zeichnen: die ursprüngliche flache Ansicht und eine 3D-Ansicht in Echtzeit, die sich eine Simulation teilen, die keine von beiden anfassen darf. Beide spielen denselben aufgezeichneten Durchlauf zu demselben Ergebnis ab — der Beweis, dass die 3D-Ansicht eine Ansicht ist und kein zweites, leicht anderes Spiel.
Auf der Testinstanz zeichnet sie ein Bild in etwa 16,7 Millisekunden, und das langsamste in einem langen Lauf brauchte 16,8. Das sind feste sechzig Bilder pro Sekunde, mit vierzig laufenden Reisenden und rund siebenhunderttausend Dreiecken auf dem Bildschirm. Siebzehn von siebzehn Prüfungen bestehen.
Und ausliefern lässt es sich trotzdem noch nicht, weil elf der Objekte, die darin stehen, Platzhalter sind — die im Eintrag darunter beschriebenen, erzeugt aus schriftlichen Beschreibungen statt aus der Konzeptgrafik. Der Renderer ist fertig. Das, was der Renderer zeichnet, ist es nicht.
Was sich geändert hat — „der Renderer ist fertig“ und „das Spiel sieht richtig aus“ haben sich als unabhängig voneinander herausgestellt, und wir hatten das Erste stillschweigend als Beleg für das Zweite genommen. Eine Leistungszahl kann keine Art Direction sehen. Wir berichten sie jetzt als zwei getrennte Zustände, denn ein grüner Build, der mit sechzig Bildern pro Sekunde die falschen Objekte zeichnet, zeichnet immer noch die falschen Objekte.
Und — die Asset-Arbeit ist weg von einer Person, die sich durch ein Web-Werkzeug klickt, und hin zu etwas, das der Build direkt ausführen kann. Das beseitigt eine ganze Klasse von Fehlern, die wir gemacht hatten: Die Einstellungen in diesem Werkzeug setzten sich zwischen den Schritten stillschweigend zurück — Sichtbarkeit, Detailstufe, welche Animationen exportiert werden — und drei verschiedene Sitzungen haben daran Arbeit verloren. Der Ersatz ist nicht klüger, er kann nur kein Kästchen vergessen.