English VersionVaporware und Streifen
Ah, endlich bin ich mit den Abiturprüfungen durch und habe Zeit, wieder etwas zu programmieren. Bevor einer fragt: Die Noten habe ich noch nicht, außer für die mündliche Prüfung, wo ich 15 Punkte (1+) habe.
Zweifel
In einem Forum behauptet gerade jemand, eine furchtbar tolle Engine zu schreiben. Ich glaube, er lügt. Weil es schnell peinlich werden könnte, wenn sich diese Vermutung nicht bestätigt, poste ich dies nicht in jenem Forum (was hier aus eben diesem Grund nicht genannt werden soll), sondernd irgendwo, wo niemand nachschaut, also genau hier.
Ich habe einige Indizien dafür, dass es sich bei diesem Spiel um Vaporware (Software, die es nicht wirklich gibt, aber trotdem stark vermarktet wird) handelt. Zuerst einmal haben zwei der drei Screenshots, die es dort gibt, keine Texturen - um nicht zu viel zu verraten, offiziell. Auch fehlen bei der Umgebung in einem der beiden wesentliche Teile, die durch einen himmelblauen Hintergrund ersetzt werden. Wieder die selbe Begründung. Nebenbei steht noch eine Figur da wie Jesus am Kreuz rumhängt, also sehr unrealistisch - obwohl die künstliche Intelligenz furchtbar toll sein soll. Der Beweis, dass diese Bilder nicht mit irgend einem 3D-Programm gerendert worden sind, sondernd echt ingame sind, steht noch aus.
Ein weiterer Punkt ist, dass alle meine technisch interessanten Fragen nur vage bis gar nicht beantwortet werden. Beispielsweise: Was passiert, wenn die Antriebsräder eines Fahrzeuges auf einem Holzbrett stehen und man dann Gas gibt? Korrekt wäre es, wenn das Holzbrett wegfliegt. Wenn jemand Ray-Cast-Physik verwendet, geschieht dies nicht (ich verwende keine Ray-Cast-Physik, aber bei mir würde das Holzbrett auch nicht wegfliegen). Als Antwort auf die Frage erhalte ich, dass die Physik cool ist und die Fahrzeuge richtig Staub aufwirbeln. Wenn dies meine Frage gewesen wäre, wäre die Antwort sicher hübsch gewesen.
Ein anderes Beispiel ist die Frage, wie er und sein Team es schaffen, große, detailreiche Szenen effizient zu verwalten. Antwort ist im Prinzip, das Prozessor und Grafikkarte schön abgewogen werden. Das klingt gut, sagt aber nichts. Die selbe Antwort gibt es auch auf die Frage, wie gut das Spiel auf schlechteren Rechnern läuft.
Es gibt davon noch mehr Beispiele. Viel interessanter ist aber, dass er seine Programmierkenntnisse offensichtlich daher hat, dass er 3D-Werbung für eine Marketingagentur macht (wofür man eher wenig programmieren muss). Die Pläne für den Umfang des Spiels wirken übertrieben, der angebliche Fortschritt ist für Leute, die noch nie ein Spiel gemacht haben, extrem schnell.
Ich weiß es nicht sicher, aber wenn jemand eine Umfrage starten sollte, würde ich auf Vaporware tippen.
Snow
Snow ist nun gerade nicht Vaporware, aber bei den wenigen Updates, die ich daran in letzter Zeit machen konnte, kriege ich fast selbst den Eindruck. Mein aktuelles Ziel ist, die Fahrzeuge auf JavaScript umzustellen, so dass ich ohne neu zu kompilieren zusätzliche Fahrzeugklassen einbauen kann. Diese Arbeit ist nun etwas nervig, da ich hier tief in meinem Spiel rumfuchtele und so viel ändern muss, dass ich vermutlich in den nächsten paar Tagen keine lauffähige aktuelle Version des Spiels erstellen kann, weil ich immer irgendwo etwas vergessen habe.
Allerdings habe ich noch ein paar alte Screenshots, die ich schon lange mal verwenden wollte, aber nie dazu gekommen bin. Darum poste ich die jetzt mal.
Zuerst einmal möchte ich auf das nette Program Inform hinweisen, was sehr schön ist, ich aber leider nicht wirklich brauche. Aber für Leute, die es brauchen, ist es echt toll. Das hier hat etwa 2 Minuten damit gedauert:
Mein nächster Punkt: Wegen besserer Performance wollte ich von Display Lists auf Vertex Buffer Objects wechseln. Das klingt beides schlimm, und ob das etwas verbessern würde kann ich nicht wirklich sagen. Aber ich wollte es halt mal probieren. Dabei wollte ich auch vom Zeichnen einzelner Dreiecke zu Dreieckstreifen wechseln, was schneller gehen sollte. Leider sah das Ergebnis nicht so aus, wie ich wollte:
Das Problem ist, dass die Streifen alle in die selbe Richtung schauen sollten, was sie nicht taten. Ich habe viel damit herumexperimentiert und kam zum Beispiel zu dem hier:
Hier schauen alle Dreiecke in die falsche Richtung. Leider gelang es mir nicht, dies umzukehren. Ich experimentierte viel und überlegte viel, auch theoretisch:
Der Trick ist, dass die Drehrichtung entscheidet, in welche Richtung das Dreieck schaut. Bäh. Na ja, jetzt läuft es auf jeden Fall.
Geschrieben am 7. Mai 2006 um 10:52
