Nexus-Devlog: Der Prototyp der Engine

▶

Watch on YouTube

Vor anderthalb Monaten habe ich auf der Website die Pläne des Studios veröffentlicht - über die Nexus-Engine: was sie ist und welche Projekte wir auf ihr bauen werden, bis hin zu Strategien und Fortsetzungen unserer ägyptischen Reihe. Dort gab es auch eine Roadmap. Die Engine ist komplex, und um das Risiko zu senken, wollte ich sie nach und nach zusammensetzen. Doch die Spieler haben es in den Kommentaren klar gesagt: So etwas zu bauen ist unmöglich. Deshalb habe ich beschlossen, mit einem Prototyp anzufangen - um zu zeigen, dass sich eine solche Engine doch bauen lässt. Den zeige ich jetzt.

So sieht die Engine im Moment aus. Auf den ersten Blick ist es eine ziemlich einfache Konsolenanwendung. Aber sie zeigt das Wichtigste gut - dass unterschiedliche Mechaniken auf einer einzigen universellen Engine laufen.

Im Moment laufen vier Simulationen auf ihr. Die erste ist Stone Age, das allererste Spiel des Studios, von 2013. Die anderen drei beruhen auf fremden Projekten. Kopieren oder veröffentlichen will ich sie nicht, sie sind nur hier, um zu zeigen, dass völlig unterschiedliche Spielmechaniken auf einer einzigen Engine laufen können.

Stone Age

Stone Age ist auf der Engine vollständig nachgebaut. Dieselben Eigenschaften, Jahre und Züge, die Bevölkerung, die Länder. Man schickt Arbeiter in den Wald, sie sammeln Essen, die Bevölkerung wächst, Technologien tauchen auf - die erforscht man, schaltet Bauten und den Evolutionsbaum frei, vom Australopithecus zum Homo habilis und weiter. Ereignisse, das Ende - alles aus dem Original ist da.

Slay the Spire

Als Nächstes Slay the Spire, ein hervorragendes Karten-Roguelike, manche von euch haben es sicher gespielt. Auf der Engine läuft nur der Kampf: der Spieler hat Karten, Energie und Gesundheit, der Gegner hat seine Absicht. Strike (Schlag) schlägt zu, Defend (Verteidigen) gibt Block. Man gibt Energie aus, beendet den Zug, und so geht es abwechselnd weiter, bis einer gewinnt.

GURPS

Die dritte Simulation ist GURPS, ein Pen-and-Paper-System, ziemlich komplex. Daraus habe ich nur ein Modul genommen, den Sternsystem-Generator. Interessant ist, dass dieses Modul selbst gar kein Spiel ist, sondern ein komplexer Generator. Er hat ein System mit einem Stern und einem Haufen Eigenschaften zusammengebaut: zehn Bahnen, auf ihnen unterschiedliche Welten. Die erste, klein und felsig, ähnelt dem Merkur - mit eigener Masse, eigenem Atmosphärendruck und allem Übrigen. Insgesamt hat diese Simulation mehr als sechstausend Fakten. Das ist ein guter Stresstest: man sieht, wie viele Daten die Engine verkraftet.

Oregon Trail

Die vierte ist Oregon Trail, ein Klassiker von 1971 und eines der frühesten Computerspiele. Es ist der Weg von Siedlern quer durch Amerika mit Planwagen: vor der Reise kauft man Vorräte - Ochsen, Essen, Munition, Kleidung -, und danach jagt man, teilt die Rationen ein und kümmert sich um Ereignisse. Gerade wurden wir überfallen. Und so geht es bis zum Ende der Strecke.

Alle vier Spiele laufen auf einer einzigen Engine, und für keines davon musste Code geschrieben werden.

Ändern im Lauf

Aber die Engine lässt diese Spiele nicht nur laufen - man kann sie direkt im Lauf ändern, ohne den Code anzufassen. Nehmen wir Slay the Spire.

Ich ändere den Schaden der Karte Strike (Schlag) und setze ihn auf 100:

/set Strike.CalcDamage Value 100

Die Eigenschaft hat sich sofort bei beiden solchen Karten geändert, weil sie dieselbe Klasse haben.

Man kann aber auch eine ganz neue Karte hinzufügen, Fireball (Feuerball):

/add Fireball Is DirectDamage
/set Fireball.CostEnergy Value 2
/add Fireball Has CalcDamage
/set Fireball.CalcDamage Value 20
/add Fireball Has ApplyDamage
/add Fireball.ExecutionEffects Has CostEnergy
/add Fireball.ExecutionEffects Has CalcDamage
/add Fireball.ExecutionEffects Has ApplyDamage

Es gab sie nicht, und jetzt ist sie im Spiel - sie liegt auf der Hand, wird ausgespielt, macht 20 Schaden und wandert auf den Ablagestapel, wie jede andere auch:

Man kann auch die Regeln selbst ändern, mit einem einzigen Befehl. Ich entferne die Regel, nach der gespielte Karten auf den Ablagestapel wandern.

/remove PlayCard Has MovePlayedCard

Jetzt bleiben sie auf der Hand. Ich habe Defend (Verteidigen) gespielt: der Block ging hoch, die Energie wurde verbraucht, aber die Karte blieb.

In einem gewöhnlichen Spiel, in einer Programmiersprache geschrieben, müsste man dafür in den Code gehen und das Projekt neu bauen. Hier ist das nicht nötig.

Genauso lässt sich auch das ins Spiel bringen, was es vorher gar nicht gab. Zum Beispiel Gold - ich richte es ein und beschreibe, wie es ausgegeben wird:

/set Player.Gold Value 100
/add CostGold Output Owner.Gold
/add CostGold Math.Subtract.Apply true

Es taucht eine Eigenschaft auf, die es eben noch nicht gab - Gold, und gleich eine ganze Hundert.

Auf diesem Gold lässt sich auch eine neue Aktion bauen - Bribe (Bestechung). Sie verbraucht nicht Energie, sondern Gold:

/add Bribe Is DirectDamage
/set Bribe.CostEnergy Value 0
/set Bribe.CostGold Value 30
/add Bribe Has CalcDamage
/set Bribe.CalcDamage Value 15
/add Bribe Has ApplyDamage
/add Bribe Has CostGold
/add Bribe.ExecutionEffects Has CostGold
/add Bribe.ExecutionEffects Has CalcDamage
/add Bribe.ExecutionEffects Has ApplyDamage
/create Bribe Player.Hand

Bribe (Bestechung) kostet dreißig Gold und macht fünfzehn Schaden - und funktioniert sofort.

Es mag wie Cheaten aussehen und so, als wäre das Eintippen solcher Befehle umständlich. Aber das sind keine Cheats. Das ist das Bearbeiten der logischen Fakten und Daten, auf denen das ganze Spiel ruht - seine Objekte, Eigenschaften und Mechaniken. Im Grunde ist es die Sprache, in der das Spiel geschrieben ist.

Diese Sprache zu lernen ist nicht nötig. Man kann die KI bitten, einen gewöhnlichen Satz in Befehle zu übersetzen, die Nexus versteht. Zum Beispiel:

give 999 gold

Übersetzt heißt das einfach „Gib mir 999 Gold“.

Die KI überlegt, findet den passenden Befehl und führt ihn aus, und wir haben 999 Gold.

Man kann es auch anders sagen, „Gold 100“ - das funktioniert ebenfalls. „Mach mich zum Gott“ - die KI gibt einem Unverwundbarkeit. Den Zug beenden, zuschlagen, sich heilen - all das lässt sich mit Worten machen, die Engine versteht es. Und nichts davon ist geskriptet, alles funktioniert wirklich.

Pläne

Die Befehle möchte ich vereinfachen. Im Moment braucht man, um denselben Fireball (Feuerball) zu erstellen, etwa acht Befehle, und ich denke daran, das auf drei bis vier zu reduzieren. Und im nächsten Video versuche ich, etwas Anschaulicheres zu zeigen - einen 2D-Render.

Mehr über die Engine und die Pläne gibt es im Bereich Nexus.

Hinweis: Stone Age ist ein Spiel des Studios. Slay the Spire, GURPS und Oregon Trail gehören ihren jeweiligen Rechteinhabern und werden nur als Demonstration der Engine gezeigt - diese Builds werden nirgendwo verbreitet.