Jetzt mal ganz ehrlich: Ich wollte schon immer ein Spiel entwickeln. Nicht, weil man damit Geld verdient. Das tut man meistens nicht. Sondern weil es die eine Sache ist, die man als Softwareentwickler irgendwann gemacht haben will. Und ich wollte es nicht so machen, wie es viele machen. Ich wollte, dass es stimmt.
Was ich schon immer wollte
Ein Katapult. Eine alte Welt, ein bisschen wie bei Anno, Mauern, Häuser, Burgen, Türme, Holz und Stein. Man steht mit einer Onager da, stellt den Winkel ein, die Spannung, wählt ein Projektil, und schiesst. Und dann fliegt das Ding, trifft, und die Mauer bricht.
Bis hierhin klingt das nach hundert anderen Spielen. Der Unterschied war eine Entscheidung, die wir am ersten Tag getroffen haben und nie zurückgenommen haben: Wir rechnen die Physik. Wir arbeiten nicht mit Animationen, die fixiert sind.
Was YOW ist
YOW steht für Ye Olde World. Ein 3D-Spiel, von devpoint, Early Access auf Steam am 4. Juli 2022, Release am 25. Januar 2023. Windows und Mac. Es gibt eine Demo, 21 Achievements, und einen Preis, den man in einer Stunde Katapult wieder drin hat.
Man schiesst mit einem Onager auf Ziele. Mauern, Häuser, Burgen, Türme. Die Ziele sind jedes Mal anders, weil sie prozedural gebaut werden. Kein Level ist zweimal gleich, und deshalb reagiert auch kein Level zweimal gleich auf dasselbe Projektil. Es gibt einen Trainingsmodus, 24 Missionen, bei denen die Ziele zurückschiessen, einen Endgegner, und einen Modus, in dem man Wellen von Ballons abwehrt, mit Ballisten, die einem helfen.
Und es gibt die Kamera, auf die ich am stolzesten bin: Man fliegt mit dem Projektil mit. Man drückt ab, und dann sitzt man auf dem Stein, sieht die Mauer näherkommen, und sieht, was passiert, wenn er einschlägt. Genau das, was passiert. Nicht ein Video davon.
Rechnen statt abspielen
Hier muss ich kurz erklären, wie es die meisten machen, damit klar wird, was wir anders gemacht haben.
In vielen Spielen ist eine einstürzende Mauer eine Animation. Jemand hat einmal am Rechner gebaut, wie die Mauer schön kaputtgeht, mit Staub, mit fliegenden Steinen, und das wird abgespielt, wenn das Projektil die Mauer berührt. Egal wo es trifft. Egal wie schnell. Egal wie schwer. Es sieht jedes Mal gut aus, weil es jedes Mal dasselbe ist.
Wir haben gesagt: nein. Jedes Projektil hat ein Gewicht. Jeder Schuss hat einen Winkel, eine Spannung, eine Flugbahn. Wenn der Stein die Mauer trifft, dann trifft er sie an einem Punkt, mit einer Energie, aus einer Richtung. Und die Mauer besteht aus Teilen, die untereinander gehalten werden. Wo die Energie reicht, bricht die Verbindung. Wo sie nicht reicht, bleibt sie. Was darüber steht, verliert seine Auflage und fällt. Und was fällt, trifft wieder etwas.
Das heisst: Ein leichter Stein oben an den Turm ist ein anderes Ergebnis als ein schwerer Stein unten an den Turm. Ein flacher Schuss ist anders als ein hoher. Und ein zweiter Schuss auf eine halb kaputte Mauer ist wieder etwas ganz anderes, weil die Mauer jetzt anders zusammenhält. Auf Steam steht dazu: Nicht immer der direkte Weg ist das Ziel, fast jedes Ziel ist auf mindestens zwei Arten zu treffen, und manchmal sind tiefe Treffer besser als hohe. Das ist kein Marketingsatz. Das ist die Physik.
Auf Steam haben wir dazu geschrieben: physikalisch korrekt, meistens. Manchmal bleibt ein Effekt, den wir liebevoll den ACME-Effekt genannt haben. Wer alte Cartoons kennt, weiss, was gemeint ist. Ein Stein, der einen Moment zu lange in der Luft hängt. Ein Balken, der sich anders entscheidet als die Schwerkraft. Wir haben das nicht versteckt. Es gehört dazu, wenn man rechnet statt abspielt.
Nativer Code, sehr viel davon
Und jetzt der Teil, den man von aussen nicht sieht.
Wir haben extrem viel nativen Code geschrieben. Nicht, weil wir es wollten, sondern weil das, was wir wollten, in dem, was man fertig bekommt, nicht schnell genug war. Eine Physik, die bei jedem Schuss für jedes Teil einer Mauer rechnet, ob die Verbindung hält, und das sechzig Mal pro Sekunde, während dreissig Dinge gleichzeitig fallen: Das läuft nicht in der Skriptsprache einer Engine. Das läuft nah an der Maschine, oder es läuft nicht.
Also haben wir die heissen Teile selber geschrieben. Die Berechnung der Flugbahn. Die Prüfung, was bricht. Das Verwalten der Teile, die gerade in Bewegung sind. Wir haben das schon einmal gemacht, bei Scan Your World, als wir das Tracking selber geschrieben haben, und ich habe damals gedacht, das war die härteste Rechnerei bis dahin. YOW war härter. Weil bei einem Scan der Raum stillsteht. Bei YOW steht nichts still.
Wann die Hardware einknickt
Das war das eigentliche Problem, und es war kein technisches. Es war ein Kommunikationsproblem.
Fakt ist: Wenn man die Physik rechnet, kostet jedes Objekt, das sich bewegt, Rechenzeit. Ein Stein, der fliegt, kostet. Eine Mauer aus zweihundert Teilen, die einstürzt, kostet zweihundert Mal. Zwei Mauern, ein Turm, ein Haus, alles gleichzeitig, und der Rechner des Spielers, den wir nicht kennen, knickt ein. Die Bilder pro Sekunde fallen, das Spiel ruckelt, und der ganze Zauber vom mitfliegenden Stein ist weg.
Also mussten wir uns zu dritt ständig abstimmen. Wer ein Level baut, entscheidet, wie viele Teile eine Mauer hat. Wer ein Projektil baut, entscheidet, wie viel Energie es hat, und damit, wie viel gleichzeitig bricht. Wer die Physik schreibt, entscheidet, wie viele Teile gleichzeitig in Bewegung sein dürfen, bevor wir sie einfrieren. Und alle drei Entscheidungen hängen zusammen. Baut einer eine schönere Burg, muss der andere das Projektil schwächer machen oder der dritte die Physik schneller.
Ein Budget für bewegte Objekte. Nicht mehr als eine bestimmte Zahl von Teilen darf gleichzeitig fallen. Was darüber ist, wird zusammengefasst oder liegt schon. Die Zahl war das meistdiskutierte Ding im ganzen Jahr.
Jedes Projektil ist ein Vertrag. Gewicht, Grösse, Energie. Wer ein neues baut, sagt den anderen, was es kaputt macht. Sonst baut jemand ein Level, das mit dem neuen Projektil in einem Schuss weg ist. Das ist passiert.
Die Physik entscheidet, nicht das Design. Wenn es schön aussieht, aber ruckelt, ist es falsch. Wenn es richtig rechnet, aber langweilig aussieht, ist es auch falsch. Beides zusammen, auf einem Rechner, den wir nicht haben: Das war die Arbeit.
Extrem anspruchsvoll in Sachen Kommunikation und Abstimmung. Das ist der Satz, den ich heute jedem sage, der ein Spiel machen will. Die Physik kannst du lernen. Das Reden zu dritt über eine Zahl, jeden Tag, ein Jahr lang, das ist die eigentliche Arbeit.
Ein Jahr, drei Leute
Das Spiel hat ein Jahr gedauert, mit zwei weiteren Personen. Drei Leute, ein Katapult. Kein Publisher, kein Budget von aussen, kein Plan, dass daraus eine Firma wird. Es war ein Fun-Projekt. Von Anfang an. Und ich glaube, gerade deshalb ist es fertig geworden.
Wir waren in ein paar Magazinen. Das war ein Moment, an den ich mich erinnere: die eigene Burg, die eigene Physik, in einem Heft, das jemand am Kiosk kauft. Für ein Fun-Projekt von drei Leuten aus Zug ist das mehr, als man erwarten darf.
Was es heisst, ein Spiel dieser Klasse zu bauen
Wir haben so viel gelernt, dass ich heute sagen kann: Ich weiss, was es heisst, ein Spiel in dieser Klasse zu entwickeln. Nicht ein Prototyp. Nicht ein Jump'n'Run fürs Wochenende. Ein 3D-Spiel mit eigener Physik, prozeduralen Levels, Missionen, Endgegner, auf Steam, auf zwei Betriebssystemen, mit Achievements und Leaderboards, das Leute kaufen und spielen.
Ein Spiel ist zu neunzig Prozent nicht das Spiel. Die Physik war der Kern und vielleicht ein Drittel der Zeit. Der Rest: Menüs, Speichern, Steam-Anbindung, Achievements, Demo, Build für Mac, Build für Windows, Store-Seite, Trailer, Bugs auf Rechnern, die wir nicht haben. Das weiss man erst, wenn man es gemacht hat.
Performance ist eine Teamentscheidung. Nicht ein Entwickler optimiert am Ende. Alle drei entscheiden jeden Tag, was sich bewegen darf. Wer das nicht früh klärt, hat am Ende ein schönes Spiel, das ruckelt.
Rechnen ist teurer als abspielen, und es lohnt sich nur, wenn man es zeigt. Die mitfliegende Kamera war deshalb nicht Dekoration. Sie war der Beweis, dass wir rechnen. Ohne sie hätte niemand den Unterschied gesehen, und wir hätten die Physik umsonst gemacht.
Fertig werden ist eine Fähigkeit. Early Access im Juli, Release im Januar. Dazwischen liegt der Teil, in dem viele aufhören. Wir haben nicht aufgehört, weil wir uns das gegenseitig versprochen hatten. Zu dritt geht das. Allein wäre es schwerer gewesen.
Man kann es heute noch laden
Das Spiel ist noch da. Auf Steam, mit Demo, für Windows und Mac: YOW, Ye Olde World. Ich spiele es manchmal. Nicht, um zu prüfen, ob es noch läuft. Sondern weil es Spass macht, mit einem Stein auf einen Turm zu zielen und mitzufliegen. Ich liebe es heute noch.
Und wenn ich es heute nochmal bauen würde? Die Physik würde ich wieder rechnen. Die Kamera würde ich wieder bauen. Das Budget für bewegte Objekte würde ich am ersten Tag an die Wand schreiben, statt es ein Jahr lang zu diskutieren. Und ich würde wieder zu dritt anfangen. Nicht allein, nicht zu zehnt. Drei Leute, die sich jeden Tag über eine Zahl streiten und sich am Abend trotzdem mögen.
Ich wollte ein Spiel machen, bei dem die Physik stimmt. Wir haben ein Jahr gebraucht, zu dritt, mit viel nativem Code und noch mehr Abstimmung darüber, was sich bewegen darf. Jetzt weiss ich, was ein Spiel in dieser Klasse kostet. Und ich weiss, dass es eine der grössten Freuden in meinem Leben war. Beides stimmt. Man kann es heute noch laden.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert unser eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal bleibt ein Hüpfer drin. Das ist dann auch von mir.