Bauen Sie LOD für Tausende animierte Figuren in Unity nach der Zahl der Vertices, nicht der Dreiecke: Bei Vertex Animation Textures wird die Animation pro Vertex berechnet. Bereiten Sie die unteren Stufen von Hand vor, binden Sie die Vertices der niedrigsten Stufe an die Oberfläche des Originals und wählen Sie die Stufe für jede Figur einzeln. In unserem Tower-Defense-Spiel für den PC stieg die Bildrate bei 3 000 Gegnern in der Nahansicht der Horde so von 62 auf 120 FPS.

Das Verfahren betrifft Spiele, in denen sich Tausende Figuren gleichzeitig bewegen, also Tower Defense, Strategie und Survival. Unser Spiel entsteht in Unity mit ECS und ist in den Referenzen zu finden. LOD steht für Level of Detail: Eine entfernte Figur wird aus einem einfacheren Mesh gezeichnet. Die Bilder zeigen die echten Meshes unseres Skelett-Gegners, keine Spielszenen.

#Warum generierter LOD bei einer Horde nicht hilft

Unity kann LOD-Stufen beim Import eines Modells erzeugen (Funktion Mesh LOD). Für Tausende Figuren hat das zwei Probleme.

Das erste ist das Aussehen. Die automatische Vereinfachung riss dünne Gliedmaßen auf und zerstörte die UVs, also die Zuordnung der Textur zum Mesh.

Das zweite sind die Kosten der Animation. Klassische Skelettanimation ist für Tausende Entities zu teuer, deshalb kommen Vertex Animation Textures (VAT) zum Einsatz. Eine VAT ist eine Textur, in der jede Spalte zu einem Vertex und jede Zeile zu einem Animationsframe gehört. Der Shader liest die Vertex-Position aus der Textur, die Kosten hängen also von der Zahl der gelesenen Vertices ab, auch beim Zeichnen der Schatten.

Die Obergrenze zeigt ein Test mit erzwungener generierter Stufe auf allen Figuren (Unity erzeugt auch die Stufen 3 und 4, Build, 1080p, 3 000 Gegner, Schatten an):

Der Spielraum ist groß. Er muss ohne sichtbare Löcher und ohne Sprünge zwischen den Stufen genutzt werden.

#Vertices zählen, nicht Dreiecke

Halb so viele Dreiecke helfen für sich genommen wenig. Ein LOD mit halb so vielen Dreiecken und 996 von ursprünglich 1 521 Vertices sparte 1,9 ms pro Frame, ein LOD mit 217 Vertices 6,4 ms. Beobachten Sie bei jeder Stufe beide Werte.

Oft gibt es unnötig viele Vertices. An jeder UV-Naht wird ein Vertex verdoppelt, weil eine Position dann zwei Texturkoordinaten braucht. Unsere Modelle aus einem KI-Generator hatten UVs in Hunderten Inseln: Das Skelett hatte 1 521 Vertices, aber nur 608 verschiedene Kombinationen aus Position und Normale.

#Schritt 1: Vertices in LOD 0 reduzieren

Die erste Einsparung kostet kein Detail. Verschmelzen Sie Vertices mit gleicher Position und ähnlicher Normale (Abweichung bis 25°), entfalten Sie die UVs neu mit Nähten nur an scharfen Kanten (über 70°) und übertragen Sie die Textur Dreieck für Dreieck aus der alten. Beim Skelett sank die Zahl von 1 521 auf 1 090 Vertices, bei den übrigen Gegnertypen um 19 bis 29 %, bei gleicher Form.

Schreiben Sie danach nur die Spalten in die VAT, die eine Stufe tatsächlich nutzt. Das sparte 40 bis 60 % des Animationsspeichers.

#Schritt 2: LOD 1 durch Vereinfachung mit gemeinsamer Textur

LOD 1 ist das auf etwa 52 % der Dreiecke vereinfachte LOD 0. Vereinfachen Sie stückweise (jede Kombination aus Bone und zusammenhängendem Teil des Meshes) und sperren Sie die Vertices an den Rändern der Stücke. Geben Sie dem Kopf ein größeres Budget, denn seine Silhouette erkennt das Auge in der Menge.

Behalten Sie die Textur von LOD 0. Eine Stufe mit eigener Textur oder anderer Form ist beim Übergang auch bei ähnlicher Silhouette sichtbar.

Unter etwa 50 % der Dreiecke reißt das Vereinfachen aus vorhandenen Vertices dünne Teile und einzelne Stücke auf. Noch weiter nach unten braucht es einen anderen Weg.

#Schritt 3: LOD 2 als neues Mesh, das am Original hängt

Die niedrigste Stufe ist ein neues geschlossenes Mesh. Verdicken Sie das Original mit einer Schicht, lassen Sie ein Voxel-Remesh darüberlaufen und vereinfachen Sie auf die Zielzahl (bei uns 200 bis 460 Dreiecke je nach Gegnertyp). Ziehen Sie das Ergebnis auf die Oberfläche des Originals und erzeugen Sie die UVs automatisch. Backen Sie die Textur aus dem Original in derselben Dichte wie LOD 0, damit auch die Mipmaps passen.

Das neue Mesh hat keine Animationsgewichte. Binden Sie deshalb jeden seiner Vertices an das nächstgelegene Dreieck des Originals und speichern Sie die drei Spalten dieses Dreiecks und die baryzentrischen Gewichte (die Anteile, die die Position eines Punkts im Dreieck festlegen).

Die VAT-Spalte eines angehängten Vertex ist in jedem Frame die gewichtete Summe der Positionen und Normalen dieser drei Vertices. Der Shader muss nichts Besonderes tun, ein angehängter Vertex ist einfach eine weitere Spalte.

für jeden Frame f:
    VAT[angehängt, f] = w0 * VAT[a, f] + w1 * VAT[b, f] + w2 * VAT[c, f]

#Schritt 4: Löcher automatisch prüfen

Bilder aus dem Modellierungswerkzeug zeigen Löcher nicht zuverlässig. Eine einfache Prüfung genügt: Rendern Sie Original und Kandidat aus 11 Richtungen mit 120 px und vergleichen Sie die Silhouetten.

Als Loch gelten Pixel des Originals innerhalb der Kontur des Kandidaten, die der Kandidat nicht abdeckt, sowie Pixel des Kandidaten mehr als 2 px außerhalb der Originalkontur. Bei uns gelten als Grenzen 1 % Löcher und 4 bis 6 % Verlust. Die Prüfung muss das materialabhängige Backface-Culling beachten. Die Grenzen haben wir danach festgelegt, wann Übergänge im Spiel sichtbar waren.

#Schritt 5: Stufe für jede Figur einzeln wählen

Wenn die ganze Karte gleichzeitig die Stufe wechselt, sieht man das. Bei einer Auswahl pro Entity verteilen sich die Übergänge und gehen in der Menge unter.

Ganze Karte auf einmal

Pro Entity

Hinweis zur Version: In der Dokumentation von Unity 6.2 steht, dass Entities Graphics immer LOD 0 verwendet. Die Auswahl pro Entity mit der folgenden Formel nutzen wir in Unity 6.6, prüfen Sie daher vorab das Verhalten Ihrer Version:

LOD = log2(d * C / D) * steigung + versatz
C = schwelle * 2 * tan(fov / 2) / bildhoehe

Dabei ist d der Abstand zur Kamera und D der Durchmesser der World Bounds der Entity. Wählen Sie Steigung und Versatz so, dass Stufe 1 bei 93,3 und Stufe 2 bei 167,9 Metern beginnt (Kamera mit 30° FOV und 1440 px). Setzen Sie die globale LOD-Schwelle auf Bildhöhe / 1440, dann hängen die Abstände nicht von der Auflösung ab.

Zwei Fehler, die Sie vermeiden sollten:

• Skalierung. Berechnen Sie den Durchmesser D aus den World Bounds, also mit der Skalierung des Prefabs. Meshes für VAT liegen oft in kleinen Einheiten vor, das Prefab vergrößert sie 2- bis 4-fach. Ohne das zeichnet das Spiel die ganze Zeit LOD 0 und meldet nichts. Prüfen Sie das anhand der Dreieckszahl im Normalbetrieb gegenüber einem erzwungenen LOD. Die Drehung einer Entity vergrößert die achsenparallelen Bounds, deshalb multiplizieren wir den Durchmesser bei uns mit 1,22.
• Baking. Die Auswahlkurve wird beim Baken der SubScene gespeichert, und das Baking erkennt eine Änderung am Mesh nicht. Erzwingen Sie nach der Anpassung einen Neuaufbau der SubScene.

#Ergebnisse und Grenzen

macOS-Build, 2560 × 1440, 3 000 Gegner, Schatten an, Spiel nach dem Game Over angehalten (VAT-Animationen laufen weiter, die Messung gilt also für die Grafik):

Auf dem Steam Deck (1280 × 800, 8 Recheneinheiten RDNA 2) sind es 75 bis 80 FPS auf der ganzen Karte. Die engste Nahansicht der Horde läuft mit hoher Schattenqualität bei 33 FPS, ohne Schatten bei 64. Schatten sind damit der größte verbleibende Posten: LOD senkt auch ihre Kosten, aber das Abschalten bringt immer noch einen großen Sprung.

Was LOD nicht löst: Die Lochprüfung läuft in der T-Pose und erkennt daher kein Dehnen in extremen Posen. Ein Gegnertyp überschreitet die Lochgrenze in LOD 2 noch. Die Berechnung der Hordenbewegung ändert LOD nicht, dazu gibt es den Artikel zur Hordennavigation in Unity DOTS, zu den Reaktionen auf Explosionen den Artikel zum Fake Ragdoll.

Brauchen Sie Hilfe bei der Performance Ihres Unity-Spiels oder bei einer Crowd-Simulation? Schreiben Sie uns.

Ein altes 2D-Spiel in Unity auf der Built-in Render Pipeline wirkt auf einem heutigen Smartphone flach: Es gibt kein Licht, der Glow fehlt oder lässt das ganze Bild samt UI leuchten, und die Sprites der Oberfläche sind unscharf. In Unity URP lösen Sie das mit drei Dingen: Bloom mit Schwelle 1 und HDR-Farbe nur auf Objekten, die leuchten sollen, 2D-Lichtern aus dem 2D Renderer und einer UI mit größeren Sprites, die den sicheren Bereich des Displays beachtet.

Wir zeigen das Vorgehen an unserem Spiel Dreamica (App Store, Google Play). Es ist ein Fall-Abenteuer, in dem Sie mit dem Finger Linien zeichnen und damit eine Blase mit einem schlafenden Kind durch vier Welten lenken. Ursprünglich entstand es in Unity 5.3, die UI lief im Plugin NGUI, den Glow lieferte das Plugin MK Glow und die Grafik war für das iPhone 7 mit seinem Display von 1334 × 750 Pixeln gemacht. Das Gameplay blieb gleich, geändert hat sich nur die Grafik.

Ein altes Spiel öffnet man oft wegen des Stores, nicht wegen der Grafik. Google Play verlangt seit August 2019 64-Bit-Versionen, und ein Spiel mit nur einem 32-Bit-Build fliegt aus dem Store. Genau so erging es Dreamica. Wenn Sie das Projekt ohnehin nach Unity 6 bringen, ist die Grafik ein relativ günstiger Bonus.

#Warum der alte Vollbild-Glow nicht reicht

Ältere Glow-Plugins arbeiten als Vollbild-Effekt. Sie lassen alles Helle leuchten, auch die Icon-Buttons im Menü. In Dreamica verschwanden die Icons unter MK Glow in Unity 6 fast. Das offizielle Post Processing Stack v2 ist nur ein Ersatz für die Built-in Pipeline und greift in URP nicht mehr. Wenn Sie einen Glow wollen, den Sie pro Material steuern, und dazu dynamische 2D-Lichter, wechseln Sie zu URP und nutzen Sie das dort eingebaute Bloom.

#Schritt 1: Projekt auf URP umstellen

Nach dem Wechsel zu URP stößt ein altes 2D-Spiel fast sicher auf zwei Fallen. Beide zeigen sich so, dass das Bild falsch oder genau wie vorher aussieht, obwohl die Shader in Ordnung sind.

#Graues Bild: Camera Stack einrichten

Zeigt die Game-Ansicht im Editor nur eine graue Fläche, während die Scene-Ansicht und ein einmaliger Kamera-Render richtig aussehen, liegt der Fehler nicht in den Shadern, sondern im Zusammensetzen der Kameras. Alte Spiele haben oft zwei Kameras, eine für die Welt und eine für die UI, und die UI-Kamera löscht nur die Tiefe. So werden Kameras in der Built-in Pipeline geschichtet, und URP unterstützt das nicht. Es braucht einen expliziten Camera Stack: Eine Kamera ist die Basis (Base), die anderen sind Überlagerungen (Overlay) in ihrem Stack. Richten Sie ihn in jeder Szene ein, in der Kameras übereinanderliegen.

#Sprites ignorieren Licht: auf den 2D Renderer wechseln

Sprites mit beleuchtetem Shader reagieren auf kein Licht, wenn der normale URP-Renderer aktiv ist. Er berechnet 2D-Lichter überhaupt nicht. Wechseln Sie auf den 2D Renderer. Auch dieser zeichnet keine Beleuchtung, solange die Szene kein einziges 2D-Licht enthält. Wenn etwas nach einer Änderung genau wie vorher aussieht, prüfen Sie zuerst, welcher Renderer läuft.

#Partikel und alte Plugins

Partikel mit alten Shadern werden im 2D Renderer schwarz oder gar nicht gezeichnet. Geben Sie ihnen einen neuen, einfachen Shader.

Vorsicht auch beim Asset Store. Beim Aktualisieren der Assets kann der Editor von sich aus ein „Update“ eines alten Plugins anwenden, das Metadaten hinzufügt und Shader umbenennt. Materialien finden ihren Shader über den Namen und gehen dadurch unbemerkt kaputt. Sehen Sie sich nach jeder größeren Asset-Aktualisierung in einem alten Projekt alle geänderten Dateien in der Versionsverwaltung an, auch die, an denen Sie gerade nicht arbeiten.

#Schritt 2: Selektiver Glow mit HDR-Farbe und Bloom-Schwelle 1

Ziel ist, dass ausgewählte Objekte leuchten, in Dreamica die gezeichnete Linie, Laser, Funken, Glühwürmchen und Runen, aber nicht Hintergründe und UI. Bloom in URP verwischt und addiert alles, was heller ist als seine Schwelle. Setzen Sie die Schwelle auf 1 und heben Sie die Farbe der Materialien, die leuchten sollen, über 1.

Linien-Shader:
    Farbe = Textur × Vertexfarbe × Tönung × Intensität    (Intensität = 6)

Bloom:
    Schwelle = 1, Stärke = 0,3
    es leuchtet nur, was nach der Berechnung heller als 1 ist

Hintergründe und Buttons haben Farben zwischen 0 und 1, kommen nicht über die Schwelle und bleiben scharf. Damit verschwinden auch die ausgebleichten Icons. Voraussetzung ist eine Kamera mit HDR. Ohne HDR wird die Farbe auf 1 begrenzt und nichts leuchtet. Der 2D Renderer zeigt den HDR-Schalter im Kamera-Inspector nicht an, schalten Sie HDR deshalb per Skript ein.

Niedrige Schwelle, ganzes Bild

Schwelle 1, HDR-Material

Wenn der Glow so unter Kontrolle ist, muss er nicht optional sein. In Dreamica haben wir den Glow-Schalter aus den Einstellungen entfernt, der Glow gehört zum Look.

#Emission Map: nur ein Teil des Sprites leuchtet

Soll nur ein Teil eines Sprites leuchten, geben Sie ihm eine Emission Map: eine zweite, schwarz-weiße Textur, die festlegt, welcher Teil des Sprites leuchtet. Nur dieser Teil bekommt eine Farbe über 1, sodass bei einer Rune der Kern strahlt und nicht der ganze Umriss.

#Pulsieren in Belichtungsstufen

Soll der Glow pulsieren, multiplizieren Sie die Farbe nicht linear. Ein HDR-Material kann eine Helligkeit um 2 hoch 8 haben, und ein linearer Faktor von 0 bis 10 ist darauf überhaupt nicht zu sehen. Rechnen Sie den Puls in Belichtungsstufen (EV), genau wie der Intensitätsregler in Unitys HDR-Farbwähler:

Farbe = Tönung × 2 ^ ev,   ev schwingt zwischen einem Minimum und einem Maximum

#Schritt 3: Dynamisches 2D-Licht um den Spieler

Setzen Sie ein 2D-Punktlicht auf den Spieler und um ihn einen weichen Schein. In Dreamica steuert eine einzige Sinuskurve gleichzeitig die Helligkeit des Scheins, den Radius des Lichts und seine Intensität, sodass alles gemeinsam pulsiert. Die Lichtfarbe kann die Umgebung bestimmen: im Wald weiß, im Sumpf orange, im Winter violett, in der Hölle gelb. Stellen Sie Hintergründe und Hindernisse auf beleuchtete Shader um, sonst reagieren sie nicht auf das Licht.

Kurze Lichter beleben Ereignisse. Wenn das Eichhörnchen mit der Kanone schießt, blitzt ein bernsteinfarbenes Licht mit Intensität 3 auf und erlischt in 0,3 Sekunden, und die Funken aus dem Rohr leuchten. Nicht alles muss leuchten: Der Staub beim Verschwinden der Eichel ist absichtlich braun und leuchtet nicht.

#Derselbe Shader auf angrenzenden Flächen

Wenn zwei Hintergründe aneinandergrenzen, die Quellbilder gleich hell sind und trotzdem eine sichtbare Naht bleibt, prüfen Sie die Shader. In Dreamica hatten der Starthintergrund und der endlose Waldhintergrund jeweils einen anderen Shader. Einer ignorierte die Materialtönung von 0,733, der andere wandte sie an und dunkelte den Wald auf 73 % ab. Die Lösung ist derselbe Shader auf beiden Flächen.

Zwei Shader

Ein Shader

#Lichtblitz: zum Höhepunkt überblenden statt addieren

Beim Übergang in die nächste Welt flammen Licht und Schein auf: 0,6 Sekunden Anstieg, kurzes Halten, 1,4 Sekunden Abklingen, und der Schein dreht sich dabei einmal. Wenn Sie den Blitz einfach zum Puls addieren, hängt der Höhepunkt davon ab, wo die Sinuskurve gerade steht, und jeder Blitz ist unterschiedlich stark. Blenden Sie stattdessen fließend vom Puls zu einem festen Höhepunkt über:

Gewicht = Blitzkurve (0 bis 1)
Wert = Puls + (Höhepunkt - Puls) × Gewicht

Addiert

Überblendet

#Schritt 4: Scharfe UI für heutige Displays

Eine UI, die für das iPhone 7 gezeichnet wurde, hat kleine Sprites. Der Menü-Button in Dreamica hatte ein Sprite mit 128 × 64 Pixeln und wurde auf einem Smartphone mit dreifacher Pixeldichte um ein Vielfaches gestreckt. Zeichnen Sie die Sprites in höherer Auflösung neu: Der neue Button hat 800 × 434, die Fortschrittsbalken wuchsen von 200 × 26 auf 800 × 104.

128 × 64

800 × 434

Wenn die UI auf NGUI basiert, ziehen Sie eine Neuentwicklung in Betracht. Die Anker in NGUI werden stückweise über mehrere Frames berechnet, lange Ankerketten pendeln sich manchmal falsch ein, und der Maßstab unterscheidet sich zwischen Editor, Smartphone und iPad. In Dreamica haben Korrekturen das nicht zuverlässig gelöst, deshalb haben wir die UI in uGUI und TextMeshPro neu geschrieben. Gehen Sie Bildschirm für Bildschirm vor und lassen Sie die alte Version daneben als Vorlage laufen. Skalieren Sie die UI nach der Höhe gegenüber einer Referenzauflösung (bei uns 434 × 941 Punkte) und beachten Sie den sicheren Bereich des Displays, also Notch und abgerundete Ecken. Entfernen Sie NGUI danach vollständig aus dem Projekt, damit nicht zwei UI-Systeme übrig bleiben.

#Grenzen: unkomprimierte Texturen

Dieses Vorgehen ändert nur die Grafik. In Dreamica haben wir die Texturen bewusst nicht komprimiert, weil wir volle Schärfe wollten. Der Preis ist die Größe: Schon das ursprüngliche Spiel hatte im Editor 313 MB Texturen im Speicher, im App Store hat es 299 MB. Komprimierung würde die Texturen nach unserer Schätzung auf etwa 40 MB verkleinern. Wenn Ihnen die Spielgröße wichtig ist, sparen Sie hier zuerst.

Ein anderes Unity-Spiel von der ersten Codezeile bis zur Veröffentlichung beschreibt der Artikel über Space Impact Watch, um Performance in Unity geht es im Artikel über Horden-Navigation in Unity DOTS. Liegt das Spiel noch in Unity 4 vor, öffnen Sie es nicht direkt in Unity 6; den sicheren Weg beschreibt die Anleitung, wie Sie ein Unity-4-Projekt auf Unity 6 umstellen. Wenn Sie ein altes Unity-Spiel haben, das aus den Stores verschwunden ist, und es zurückbringen möchten, melden Sie sich bei uns.

Wenn eine Explosion im Spiel Hunderte Gegner gleichzeitig wegschleudert, ist ein echter Ragdoll für jeden einzelnen zu teuer. Einen Fake-Ragdoll in Unity DOTS bauen Sie, indem Sie den ganzen Körper des Gegners als einen einzigen Punkt mit eigener, einfacher Physik simulieren und das Modell nur um die Körpermitte drehen. Fallen und Aufstehen sind gewöhnliche Animationsclips, Knochen werden überhaupt nicht simuliert.

Wir zeigen das Vorgehen an einem Tower-Defense-Spiel für PC, das wir in Unity mit ECS entwickeln (mehr in unseren Referenzen). Eine Bombe oder ein Fireball schleudert dort Dutzende bis Hunderte Gegner auf einmal weg. Bei 2.000 Körpern in der Luft kostet die Simulation 0,53 bis 0,59 ms pro Tick (ein Tick ist ein Schritt der Spielsimulation mit fester Länge).

#Warum kein echter Ragdoll

Ein echter Ragdoll besteht pro Figur aus zehn oder mehr Physikkörpern, die über Gelenke verbunden sind. Bei Tausenden Figuren auf dem Bildschirm ist das nicht realistisch.

Der zweite Grund ist Determinismus: Derselbe Zustand muss dasselbe Ergebnis liefern. Unser Spiel braucht das, um eine verlorene Welle ab einem Checkpoint zu wiederholen, und wir prüfen es mit einem Hash des Simulationszustands nach 1.800 Ticks.

#Der Körper als ein Punkt

Verwenden Sie statt einer Physik-Engine eine eigene, einfache 2,5D-Physik: Position im Raster, Höhe über dem Boden, ballistischer Flug, Abprallen an Wänden und Reibung. In unserem Spiel bewegt sich auch die Bombe so, und ein von der Explosion getroffener Gegner wird für einen Moment zum gleichen Körper. Die Inspiration war, wie Soldaten in Diplomacy is Not an Option durch die Luft fliegen.

Die Simulation kennt nur Position, Höhe und Drehwinkel. Schreiben Sie die Drehung des Modells nicht in die Simulation. Sie gehört in die zusätzliche Transformationsmatrix der Entity, die das Paket Entities (ECS in Unity) für nicht-uniforme Skalierung unterstützt (Dokumentation).

#Phasen eines umgeworfenen Gegners

Ein umgeworfener Gegner durchläuft drei Phasen und kehrt dann in die Menge zurück:

beim Treffer:
    berechne die Wurfgeschwindigkeit (Kraft, Abstand zur Explosion, Zufall aus dem Seed)
    finde eine Landung auf einer begehbaren Zelle (siehe unten)
    schalte den Zustand "umgeworfen" ein, gib den Platz am Angriffsziel frei
Flug:      der Körper fliegt auf einer Parabel, das Modell dreht sich um die Körpermitte
Landung:   Lage aus der Drehung (Rücken oder Bauch), kurzes Nachkippen
Liegen:    wartet eine feste Anzahl von Ticks
Aufstehen: Aufsteh-Clip vom Rücken oder vom Bauch, dann zurück in die Menge

Bauen Sie den Zustand „umgeworfen“ als Komponente, die sich ein- und ausschalten lässt, ohne die Entity zwischen Chunks zu verschieben (Speicherblöcken, in denen ECS Entities mit derselben Komponentenkombination ablegt). Navigation, Separation in der Menge und Angriffsentscheidungen überspringen umgeworfene Gegner dann einfach. Wie Navigation und Separation in einer großen Menge funktionieren, beschreibt der Artikel über Horden-Navigation in Unity DOTS.

#Wurf: höher, nicht weiter

Der einfachste Wurf geht in einem Winkel von 45° ± 10°. Bei einer Bombenkraft von 18 m/s und einer Gravitation von 20 m/s² liegt der Scheitelpunkt bei etwa 4 m. Der Körper fliegt tief über die Menge, und der Effekt geht darin unter.

Mehr Kraft hilft nicht, weil damit auch die Weite wächst. Teilen Sie die Geschwindigkeit in zwei Komponenten und skalieren Sie jede separat: Winkel 60° ± 5°, horizontale Komponente × 0,85, vertikale × 1,3. Der Scheitelpunkt liegt dann bei etwa 10 m, die Weite bleibt bei etwa 15,5 m, und der Flug dauert ungefähr 2 Sekunden.

Die Richtung weicht um ± 15° von der Explosion ab, die Kraft um ± 20 %, und am Rand der Explosion sinkt sie auf die Hälfte. Nehmen Sie den Zufall nicht aus einem globalen Generator, sondern aus einem Hash von Level-Seed, Kennung des Gegners und laufender Nummer der Explosion. Verarbeiten Sie die Umwerf-Anfragen sortiert, denn Jobs auf mehreren Threads erzeugen sie in beliebiger Reihenfolge. Zwei Durchläufe derselben Welle ergeben so dieselben Bögen.

Umwerfen ist ja oder nein. Jeder umwerfbare Gegner fällt bei einem Treffer mindestens um (die Geschwindigkeit ist nach unten auf 2 m/s begrenzt), die Resistenz ändert nur die Weite. Geben Sie Immunität ein eigenes Flag, in unserem Spiel hat es der größte Gegnertyp. Ergäbe sich die Immunität aus der Resistenz (bei 0,95 liegt die Geschwindigkeit unter 2 m/s) und würden schwache Würfe verworfen, wäre der Gegner nur zufällig immun.

#Landung auf einer begehbaren Zelle

Ein Gegner darf nicht in einer Schlucht, auf einer Klippe oder in der Grundfläche eines Turms landen. Begehbarkeit wird pro Rasterzelle und für jede Größenklasse von Gegnern separat bestimmt.

#Abprallen an Wänden in der Luft reicht nicht

Naheliegend ist, nicht begehbare Zellen als Wände zu behandeln, von denen der fliegende Körper abprallt. An einer Klippe sieht das natürlich aus, an einer Schlucht nicht: Über einer Schlucht ist Luft, aber die Zelle ist nicht begehbar, also prallt der Körper an einer unsichtbaren Säule über ihrem Rand ab. Außerdem garantiert nichts, dass er nach dem Abprall an einer guten Stelle landet.

#Vorhersage der Flugbahn beim Wurf

Zuverlässiger ist es, die Landung gleich beim Wurf zu bestimmen. Simulieren Sie den Flug im Voraus mit demselben Schritt wie die echte Physik und prüfen Sie die Landezelle für die Größenklasse des Gegners. Ist sie nicht begehbar, probieren Sie weitere Varianten in fester Reihenfolge:

für Winkel in [0, +25, -25, +50, -50, ... , +175, -175]:
    für Faktor der horizontalen Geschwindigkeit in [1, 0.7, 0.4, 0.1]:
        simuliere den Flug
        wenn die Landezelle für die Klasse des Gegners begehbar ist: nimm diese Richtung und Ende
wenn nichts passt: horizontale Geschwindigkeit = 0 (Hüpfer auf der Stelle)

Im schlimmsten Fall sind das 60 Flugsimulationen pro Gegner (15 Richtungen × 4 Faktoren). Die vertikale Geschwindigkeit ändert sich nicht, die Flughöhe bleibt also gleich, nur die Weite wird kürzer. Trifft den Gegner während des Flugs eine weitere Explosion, starten Sie die Vorhersage erneut.

Damit der Körper nach der Landung weder rutscht noch abprallt, geben Sie ihm einen Restitutionskoeffizienten am Boden von 0 und hohe Reibung. Er bleibt dort liegen, wo die Vorhersage es gesagt hat.

#Rotation nach der Flughöhe geplant

Am einfachsten ist es, das Modell mit zufälliger Geschwindigkeit zu drehen, etwa 180 bis 540 °/s, und es nach der Landung innerhalb von 0,2 s in die nächste Liegeposition kippen zu lassen. Das Nachkippen ist aber sichtbar, wenn der Körper fast aufrecht landet. Die Drehgeschwindigkeit in jedem Tick so nachzuregeln, dass der Winkel bei der Landung genau waagerecht ist, hilft nur teilweise: Auch ein niedriger Wurf dreht sich wie ein Salto, und die Drehung hat nichts damit zu tun, wie hoch der Körper fliegt.

Besser ist es, die Rotation beim Wurf aus der Flughöhe zu planen:

Höhe = vz² / (2 g), Flugzeit aus vz und Höhe
Ziel = nächste waagerechte Lage in zufälliger Richtung (Vierteldrehung aus dem Stand)
Ziel += halbe Drehung je 2,5 m Höhe, höchstens 3
Drehgeschwindigkeit = (Ziel - aktueller Winkel) / Flugzeit

Die Landeseite folgt aus dem Winkel: Gesicht zum Boden heißt Bauch, sonst Rücken. Danach wird der Aufsteh-Clip gewählt. Ein liegender oder aufstehender Gegner behält bei einem weiteren Treffer seinen aktuellen Winkel und springt nicht in die aufrechte Lage zurück.

#Das Modell auf den Boden setzen

Das Modell dreht sich um die Körpermitte, der Boden liegt aber unter seinem tiefsten Punkt, und der ändert sich mit der Drehung. Eine Schätzung des Versatzes aus zwei Konstanten und dem Sinus des Winkels passt nicht zu Modellen mit weit ausgebreiteten Armen im Fall-Clip: In unserem Spiel sank das Skelett-Modell (ein häufiger Gegner) bis zu 1,15 m in den Boden ein, das Modell des Nekromanten bis zu 1,73 m.

Schätzung

Gemessen

Zuverlässiger ist es, den tiefsten Punkt zu messen. Berechnen Sie beim Baken der Animationen für den Fall-Clip den tiefsten Punkt des Körpers bei 72 Drehungen in 5°-Schritten und interpolieren Sie zur Laufzeit aus der Tabelle. Das tiefste Einsinken fällt so auf 4 mm. Ein einziges Minimum über alle Frames des Clips reicht allerdings nicht: Der Körper würde nach der Landung 0,15 bis 0,28 m über dem Boden schweben, bis der Aufsteh-Clip ihn herunterzieht. Die Tabelle muss deshalb die Dimension Frames × Drehungen haben.

Die langsame geplante Drehung zeigt noch einen Effekt. Setzen Sie das Modell mit seinem tiefsten Punkt auf die Flughöhe, sinkt die Körpermitte beim Übergang vom Stehen in die Waagerechte um die Differenz zwischen halber Höhe und halber Dicke der Figur. Der Körper steigt dann am Anfang des Flugs nur langsam und beschleunigt erst danach. Heben Sie das Modell deshalb um die Differenz zwischen seiner halben Ausdehnung im Stand und beim aktuellen Winkel an, höchstens um die Flughöhe. Die Körpermitte folgt dann der Parabel.

#Tote Gegner: Körper, Decal und Staub

Ein von einer Explosion getöteter Gegner soll ebenfalls fliegen. Erzeugen Sie dafür einen fliegenden Körper: eine Kopie der Entity ohne Gameplay-Komponenten (Lebenspunkte, Belohnung, Ziel). Der Körper fliegt, landet, liegt eine Weile und verschwindet. An seiner Stelle bleiben ein Leichen-Decal (eine auf den Boden projizierte Textur) wie in Warcraft 3 und eine kleine Staubwolke. In unserem Spiel liegt die Obergrenze bei 1.000 fliegenden Körpern und 1.500 Decals.

Das Decal ist eine Draufsicht auf einen Frame des Fall-Clips, gedreht wie der liegende Körper, sodass der Tausch von Körper zu Decal nicht zu sehen ist. Der erste Frame des Aufsteh-Clips eignet sich nicht, weil die Figur darin vom Rücken schon aufgerichtet ist. Fassen Sie Staubwolken in einer Zelle von 1,5 m zusammen. Eine Bombe in die Menge erzeugt so ein paar größere Wolken statt Hunderter kleiner.

#Fallen in Unity Entities

• Die Matrix aus dem Baker verschwindet. Wenn Sie die zusätzliche Matrix beim Baken hinzufügen, entfernt das Transform-System sie bei uniformer Skalierung, und umgeworfene Gegner bewegen sich nicht. Fordern Sie beim Baken deshalb nicht-uniforme Skalierung an. Dann wandert allerdings die gesamte Skalierung des Prefabs in dieselbe Matrix, überschreiben Sie sie also nicht mit der reinen Rotation. Sonst hat ein umgeworfener Gegner mit Skalierung 2× nur die halbe Größe, auch nach dem Aufstehen. Speichern Sie die Skalierung separat und setzen Sie die Matrix aus Skalierung und Rotation zusammen.
• Wurzelhöhe beim Import der Clips. Bei Humanoid-Clips wird die vertikale Bewegung der Wurzel (Root) verworfen, und Figuren fallen beim Aufstehen durch den Boden. Baken Sie die Wurzelhöhe in die Pose. Die Option, die Pose an den Füßen zu verankern, sollten Sie nicht verwenden: Sie verschiebt den ganzen Körper um einen Meter nach unten.
• Matrix in geschlossener Form. Verschiebung, Rotation und Rückverschiebung als drei Matrixmultiplikationen sind im Job messbar langsamer als eine von Hand geschriebene Formel für die resultierende Matrix.
• Burst mit alter Version. Nachdem Sie die Felder einer Komponente geändert haben, die ein Burst-Job liest, kann der Editor abstürzen oder Unsinn melden. Ein Neustart des Editors hilft.

#Leistung

Gemessen im Unity Editor auf einem M3 Pro, 10.000 Skelette in einer Benchmark-Szene, Wurfkraft 18. Die Zeiten sind die Summe der CPU-Zeit der Burst-Jobs über alle Threads, nicht die Frame-Zeit. Diagramm und Tabelle sind ohne Flugbahnvorhersage und Landetabellen.

• Die Simulation wächst linear, etwa um 0,25 ms pro tausend umgeworfene Gegner. Mit Flugbahnvorhersage und Landetabellen sind es bei 2.000 umgeworfenen 0,58 bis 0,59 ms, also knapp über dem Ziel von 0,5 ms. Eine sinnvolle Obergrenze sind daher 3.000 gleichzeitig umgeworfene Gegner, das sind etwa 0,8 ms.
• Eine Explosion in eine Gruppe von 359 Gegnern an einer Wand kostet im System der Umwerf-Anfragen 1,3 bis 1,9 ms in einem einzigen Frame. Den größten Teil davon macht die Flugbahnvorhersage aus.
• FPS aus dem Editor lassen sich nicht vergleichen: Zwei Durchläufe derselben Konfiguration unterschieden sich um bis zu 80 FPS.

#Grenzen der Lösung

Die Vorbereitung der Darstellung stieg in einer anderen Testszene auf bis zu 1,3 ms, vermutlich wegen des Lesens der Landetabelle für jeden Körper. Das ist der erste Kandidat für eine Optimierung. FPS in einem Build und die Last beim gleichzeitigen Töten von 1.000 Gegnern (Ziel: höchstens 1,5 ms zusätzlich pro Frame) sind noch nicht gemessen.

Wenn Sie an einer ähnlichen Simulation von Menschenmengen oder Effekten in Unity arbeiten und Hilfe brauchen, schreiben Sie uns.

Ein Shmup (Shoot 'em up, ein Shooter, in dem das eigene Schiff gegen Wellen von Gegnern fliegt) auf der Apple Watch hat drei Probleme: ein kleines Display, einen Finger, der das halbe Spiel verdeckt, und Uhren in verschiedenen Größen. Drei Entscheidungen lösen sie: Das ganze Spiel läuft auf einem festen Raster von 84 × 48 Punkten, Kollisionen werden von Hand mit Rechtecken geprüft, und Level sind Tabellen mit Zeitpunkten statt Code. Gesteuert wird mit der Digital Crown, geschossen wird automatisch.

Die Beispiele stammen aus Space Impact Watch, einem Remake des Shooters Space Impact, der im Jahr 2000 auf dem Nokia 3310 erschien. Das Spiel läuft auf der Uhr sowie auf iPhone und iPad. Technisch basiert es auf SpriteKit, dem 2D-Spieleframework von Apple, die Prinzipien gelten aber für jeden Shmup auf einem kleinen Bildschirm.

#Feste virtuelle Auflösung 84 × 48

Legen Sie zuerst fest, in welchen Einheiten das Spiel rechnet. Mit Bildschirmpunkten ist die Welt auf jeder Uhrengröße anders groß. Besser ist eine kleine virtuelle Auflösung, in der alles berechnet wird. In unserem Spiel sind das 84 × 48, genau wie beim Display des Nokia 3310. Positionen, Geschwindigkeiten, Spritegrößen und Flugbahnen der Gegner sind in diesen Einheiten angegeben. Beim Start der Szene wird einmal berechnet, wie viele Bildschirmpunkte ein virtuelles Pixel hat (Szenenbreite geteilt durch 84), und alles wird nur damit multipliziert.

Was Sie damit gewinnen:

• Gleiches Aussehen auf jedem Gerät. Das Spiel sieht auf jeder Uhrengröße und auf dem iPad gleich aus, nur die Blockgröße ändert sich.
• Leveldesign mit kleinen ganzen Zahlen. Ein Gegner fliegt auf Höhe 13, eine Rakete biegt bei x = 20 ab.
• Einfache Grafik. Die Sprites sind einfarbig und in zehnfacher Größe gezeichnet, ein virtuelles Pixel ist im Quellbild also ein Block von 10 × 10. Ihre Farbe bekommen sie erst im Spiel: in hellen Leveln schwarz auf grünem Hintergrund, in dunklen umgekehrt.

#Steuerung mit der Krone und automatisches Feuer

Auf der Uhr verdeckt ein Finger das halbe Spiel, deshalb wird das Schiff nicht per Touch gesteuert. Die Bewegung übernimmt die Digital Crown: Eine Drehung bewegt das Schiff nach oben oder unten. Bieten Sie eine Einstellung für die Empfindlichkeit und eine Option zum Umkehren der Richtung an.

Geschossen wird automatisch, in unserem Spiel alle 0,4 Sekunden, ab Level vier alle 0,3. Das Display dient nur für eine Geste: Ein Wischen nach rechts löst eine von drei Spezialwaffen aus.

Auf der Uhr ist die Vibration bei einem Treffer genauso wichtig wie die Animation, eine kleine Explosion auf dem Display übersieht man leicht. Lösen Sie Haptik über eine einzige Schnittstelle aus (Treffer, Gegner zerstört, Boss besiegt), die jede Plattform selbst umsetzt: die Uhr mit einer Vibration, das iPhone auf seine eigene Art. Die Telefonversion hat keine Krone, sondern Tasten auf dem Display, die dieselben Einstellungen für Empfindlichkeit und Richtung verwenden.

#Der Game Loop in einer Szene

Das ganze Spiel kann eine Szene mit einer Schleife sein:

in jedem Frame:
    alle Objekte bewegen
    Kollisionen prüfen
    je nach Zeit im Level neue Gegner erzeugen

Bauen Sie die Teile in der Reihenfolge ein, in der sie sich am frühesten testen lassen:

• Schießen und Bewegung des Spielers. Ohne sie lässt sich nichts testen.
• Gegner und Kollisionen. Dem ersten Gegner reicht es, geradeaus nach links zu fliegen und nach einem Treffer zu sterben.
• Vibration und Trefferanimationen. Ohne sie merkt der Spieler auf dem kleinen Display nicht, dass er getroffen hat.
• Hintergrund und HUD. Leben, Punktestand, Anzahl der Spezialwaffen. Wenn das HUD in einem Level stört, verschieben Sie es nach unten.

Am Ende steht eine spielbare Schleife mit Leben, Punktestand, Explosionen, Hintergrund und Respawn des Spielers. Wenn Sie die Spiellogik von Darstellung und Eingabe trennen, können Uhren- und Telefonversion sie gemeinsam nutzen.

#Kollisionen mit Rechtecken statt Physik-Engine

SpriteKit hat eine Physik-Engine, und es liegt nahe, sie auch für Kollisionen zu nutzen. Jedes Objekt bekommt einen Physikkörper aus dem Umriss seines Sprites, präzise Kollisionserkennung und eine Kategorie (Spieler, Gegner, Geschoss, Spezialwaffe), und die Engine meldet selbst die Paare, die sich berührt haben. Apple schreibt in der Dokumentation zu Physikkörpern, dass Körper aus dem Alphakanal einer Textur am genauesten und zugleich am rechenintensivsten sind. Wir haben das in unserem Spiel ausprobiert und sind zur Prüfung von Hand zurückgekehrt.

Die Prüfung von Hand ist eine Funktion, die nacheinander Paare von Gruppen durchgeht und Rechtecke vergleicht:

für jedes Paar von Gruppen:
    (Spieler und Gegner, Spieler und Geschosse, Geschosse und Gegner, Geschosse und Geschosse)
    für jedes Objekt A der ersten Gruppe und jedes Objekt B der zweiten:
        wenn Rechteck A sich mit Rechteck B überlappt:
            Treffer auflösen

Die Vorteile: Die Reihenfolge der Prüfungen liegt in Ihrer Hand, und die ganze Regel „was bei einem Treffer passiert“ steht an einer Stelle. Die Ungenauigkeit ist gering, denn auf dem Raster 84 × 48 sind die Sprites so klein, dass Rechteck und echter Umriss nur um wenige virtuelle Pixel abweichen.

#Pooling nur dort, wo es sich lohnt

Pooling bedeutet, dass Sie ein Objekt nach seinem Ende nicht löschen, sondern ausblenden und beim nächsten Mal wiederverwenden. Es ist verlockend, alles zu poolen, auch Explosionen und Power-ups. Das hat aber seinen Preis: Jede Kollision und jedes Update muss zuerst prüfen, ob das Objekt überhaupt lebt. Eine vergessene Prüfung reicht, und ein ausgeblendeter Gegner tötet den Spieler oder ein ausgeblendetes Geschoss schießt eine Rakete ab. Als wir in unserem Spiel das Pooling überall entfernt haben, waren es vor allem diese Prüfungen, die wegfielen.

Eine einfache Regel: Poolen Sie, wovon es viel gibt und was immer gleich entsteht. Der Spieler erzeugt beim Start 21 Geschosse und recycelt sie danach nur noch. Gegner und ihre Geschosse werden ebenfalls wiederverwendet, Explosionen und Power-ups entstehen und verschwinden normal.

#Level als Zeittabellen

Ein Level muss kein Code sein, eine Liste von Einträgen genügt. Jeder Eintrag sagt, was erscheint, in welcher Sekunde, auf welcher Höhe und wie es sich bewegt. Die Bewegung ist eine Liste von Punkten, die der Gegner mit gleichbleibender Geschwindigkeit abfliegt. Optional kommen Schusszeiten, ein Sturmangriff des Bosses oder ein Erzeuger kleinerer Gegner dazu.

in jedem Frame:
    Zeit = jetzt - Levelstart - Zeit in der Pause
    für jeden Eintrag in der Leveltabelle:
        wenn der Eintrag unbenutzt ist und Zeit > Eintrag.Zeit:
            Objekt laut Eintrag erzeugen
            Eintrag als benutzt markieren

Ein so geschriebenes Level lässt sich leicht abstimmen: Eine Welle um eine halbe Sekunde zu verschieben heißt, eine Zahl zu ändern. Auf der Zeitachse sieht man auch den Rhythmus, um den es geht: kurze Welle, Pause, anderer Gegnertyp, Power-up vor einem schwereren Abschnitt.

Der Nachteil zeigt sich bei größeren Änderungen. Das dichteste Level unseres Spiels hat 71 Zeilen, und so eine Tabelle liest sich ohne Editor schlecht. Günstiger ist es, Level als Wellen zu schreiben (eine Gruppe von Gegnern mit einem gemeinsamen Bewegungsmuster), nicht als einzelne Schiffe.

#Endlosmodus aus einer Pseudozufallszahl

Für eine Rangliste (bei uns Game Center) brauchen Sie einen Modus ohne Ende. Dort ersetzt ein Generator die handgeschriebene Tabelle und erzeugt sie während des Spiels. Er erzeugt eine 20-stellige Pseudozufallszahl, und einzelne Ziffernpaare entscheiden über eine Welle:

Zahl = nächste 20-stellige Pseudozufallszahl
Typ = Power-up, wenn Ziffern 4 bis 5 > 90, sonst Gegner
Sprite = Ziffern 1 bis 2 modulo Anzahl der Gegnerarten
Pause vor der Welle = Ziffer 3 / 2 Sekunden (mindestens 1)
Höhe = Ziffer 7, umgerechnet auf die Höhe des Spielfelds
Bewegungsmuster = Ziffern 10 bis 11 modulo 10
Schiffe in der Welle = Ziffer 17 / 2 + 1
Geschwindigkeit = Ziffer 13 × (1 + Nummer der Welle / 10), begrenzt auf 20 bis 50
jede dreißigste Welle = Boss, die Erzeugung ruht, solange der Boss lebt

Lassen Sie den Seed (Startwert) des Generators im Spiel fest. Dann bekommt jeder Spieler dieselbe Wellenfolge, und die Punktzahlen in der Rangliste sind vergleichbar.

Wie sich der Modus entwickelt, zeigt eine Simulation des Generators außerhalb des Spiels (300 Wellen, derselbe Seed wie im Spiel). Der erste Boss kommt nach 29 Wellen, also nach 74 Gegnern und 3 Power-ups, nach etwa 130 Sekunden. Die ersten 30 Wellen fliegen mit der Mindestgeschwindigkeit 20, weil eine einzelne Ziffer noch unter der Untergrenze liegt. Danach steigt die Durchschnittsgeschwindigkeit auf 28,5, 37,5 und 41, ab Welle 120 sind die meisten Gegner am Maximum. Etwa jede elfte Welle ist ein Power-up.

Die Schwäche: Der Generator kennt keinen Rhythmus. Ein handgeschriebenes Level wechselt zwischen Druck und Erholung, der Generator nicht. Die Pause während des Bosses und die steigende Geschwindigkeit helfen etwas, aber die handgeschriebenen Level spielen sich besser.

#Grenzen dieses Ansatzes

• Keine automatischen Tests. Alles wird von Hand im Simulator und auf der Uhr geprüft.
• Globaler Zustand. Der Großteil des Spielzustands sind globale Variablen einer einzigen Szene. Für ein reines Uhrenspiel ist das bequem, beim Hinzufügen einer iPhone-Version nicht mehr.
• Kein Leveleditor. Eine Zeittabelle lässt sich in kleinen Schritten gut abstimmen, für größere Änderungen bräuchte sie einen Editor.

Wenn Sie ein Spiel für eine Uhr oder einen anderen kleinen Bildschirm entwickeln und Hilfe brauchen, schreiben Sie uns. Wie wir in einer anderen unserer Apps Rätsel erzeugen, steht im Beitrag über unseren Sudoku-Generator.

Ein Sudoku mit eindeutiger Lösung generieren Sie in zwei Schritten. Füllen Sie zuerst ein leeres 9×9-Gitter vollständig, per Backtracking mit Ziffern in zufälliger Reihenfolge. Leeren Sie dann einzelne Felder in zufälliger Reihenfolge und prüfen Sie nach jedem Leeren mit einem Solver, ob das Rätsel noch genau eine Lösung hat. Wenn nicht, setzen Sie die Ziffer zurück. Auf einer gewöhnlichen CPU dauert das im Median weniger als eine Millisekunde.

Das Verfahren passt zu jedem Spiel und jeder App, die beliebig viele neue Rätsel ohne Handarbeit braucht. Ein Beispiel aus der Praxis sind die Sudokus in unserer App mit Kreuzworträtseln und Denkspielen (App Store, Google Play).

#Warum genau eine Lösung

Die Regeln kennt jeder: In jeder Zeile, jeder Spalte und jedem 3×3-Block steht jede Ziffer von 1 bis 9 genau einmal. Seltener wird erwähnt, dass ein gutes Rätsel nur eine Lösung hat. Nur dann lässt es sich mit reiner Logik lösen, ohne Raten.

Das hat auch eine praktische Seite. Ein Spiel speichert meist eine Lösung, prüft damit das Ergebnis und gibt Hinweise. Hat ein Rätsel zwei Lösungen, kann der Spieler bei der anderen landen, die genauso richtig ist, und das Spiel erkennt sie nicht an.

#Schritt 1: Einen schnellen Solver schreiben

Ein Solver ist ein Programm, das das Sudoku löst. Er arbeitet mit Backtracking: Er setzt eine der möglichen Ziffern in ein Feld, geht zum nächsten Feld weiter und kehrt bei einem Widerspruch zurück, um eine andere Ziffer zu probieren. Sie brauchen ihn zweimal: zum Füllen des leeren Gitters und zur Eindeutigkeitsprüfung. Die Prüfung läuft nach jedem geleerten Feld, also 40- bis 70-mal pro Rätsel, und muss deshalb schnell sein. Entscheidend sind zwei Dinge:

• Bitmasken. Speichern Sie für jede Zeile, jede Spalte und jeden Block eine 9-Bit-Zahl mit den bereits verwendeten Ziffern. Die Kandidaten eines Feldes, also die Ziffern, die dort noch stehen dürfen, sind dann eine einzige Operation: alle Ziffern außer denen, die schon in seiner Zeile, Spalte oder seinem Block stehen. Die Anzahl der Kandidaten ist die Zahl der gesetzten Bits und lässt sich vorab in eine Tabelle mit 512 Werten rechnen.
• Zuerst das Feld mit den wenigsten Kandidaten. Nehmen Sie nicht das erste leere Feld von links, sondern das mit den wenigsten Möglichkeiten (in der Literatur die MRV-Heuristik, minimum remaining values). Ein Feld mit nur einem Kandidaten füllen Sie sofort, ein Feld ohne Kandidaten bedeutet einen toten Zweig, und Sie gehen zurück.

Bei schweren Rätseln braucht die Eindeutigkeitsprüfung mit dieser Regel im Median 311 Schritte. Nimmt der Solver die Felder der Reihe nach von links nach rechts, sind es im Median 28.579 Schritte und in den schlechtesten 5 % der Fälle über 300.000. Der Unterschied ist etwa 90-fach.

#Schritt 2: Das ganze Gitter füllen

Ein volles Gitter erhalten Sie mit demselben Solver auf einem leeren Gitter. Der einzige Unterschied: Die Kandidaten eines Feldes probieren Sie in zufälliger Reihenfolge. Die erste gefundene Lösung ist ein zufälliges, gültiges, vollständig gefülltes Gitter.

#Warum zufälliges Leeren nicht reicht

Die einfachste Idee ist, N zufällige Felder des vollen Gitters zu leeren, etwa 40, 50 oder 55 je nach Schwierigkeit. Das Rätsel sieht gut aus, hat aber oft keine eindeutige Lösung.

Das Bild zeigt den typischen Fall. Vier Felder an den Ecken eines Rechtecks, das zwei Blöcke berührt, lassen sich auf zwei Arten füllen, und der Rest des Gitters entscheidet nicht darüber. Sudoku-Löser kennen dieses Muster als Deadly Pattern. Bei 1.000 Rätseln pro Schwierigkeit sieht das Ergebnis so aus:

Ein schweres Rätsel aus zufälligem Leeren hat im Schnitt Hunderte Lösungen. Eine Eindeutigkeitsprüfung nach jedem Leeren ist deshalb nötig.

#Schritt 3: Felder mit Eindeutigkeitsprüfung leeren

Gehen Sie alle 81 Felder in zufälliger Reihenfolge durch. Versuchen Sie, jedes zu leeren, und zählen Sie mit dem Solver die Lösungen, brechen Sie aber bei zwei ab. Mehr müssen Sie nicht wissen: Eine Lösung heißt, das Feld darf leer bleiben, zwei heißen, es muss zurück.

rätsel = Kopie des vollen Gitters
geleert = 0
für jedes Feld in zufälliger Reihenfolge:
    wenn geleert == ziel: Ende
    ziffer = rätsel[feld]
    rätsel[feld] = leer
    wenn anzahl_lösungen(rätsel, höchstens 2) == 1:
        geleert = geleert + 1
    sonst:
        rätsel[feld] = ziffer

Ein Feld, das Sie einmal zurückgesetzt haben, probieren Sie nicht noch einmal. Weiteres Leeren lockert das Rätsel nur, ein Feld, das sich jetzt nicht leeren lässt, lässt sich also auch später nicht leeren.

#Schritt 4: Schwierigkeit über die Zahl leerer Felder einstellen

Das einfachste Maß für die Schwierigkeit ist die Zahl der geleerten Felder. Die drei Stufen, die wir in unserem Spiel verwenden:

Je weniger Ziffern übrig sind, desto öfter würde ein weiteres Leeren die Eindeutigkeit zerstören, und das Feld muss zurück. Auf der schweren Stufe bleibt ein einzelner Durchlauf manchmal stehen, bevor er 55 leere Felder erreicht. Generieren Sie dann ein neues volles Gitter und versuchen Sie es erneut. Bei einer Messung an 1.000 schweren Rätseln reichte der erste Durchlauf in 97,6 % der Fälle, und es waren nie mehr als 3 Versuche nötig.

#Geschwindigkeit und Zuverlässigkeit des Generators

Wir haben den Generator an 1.000 Rätseln pro Schwierigkeit laufen lassen (Node.js 22 auf einer Server-CPU, ein Telefon ist langsamer):

Zusätzlich haben wir jedes generierte Rätsel unabhängig mit dem Solver geprüft. Alle 3.000 hatten eine einzige Lösung.

#Wo die Zahl leerer Felder nicht ausreicht

Die Zahl der vorgegebenen Ziffern ist ein grobes Maß für die Schwierigkeit. Zwei Rätsel mit 26 Ziffern können unterschiedlich schwer sein, je nachdem, welche Lösungstechniken sie verlangen. Eine genauere Bewertung würde das Rätsel wie ein Mensch lösen und die schwierigste Technik festhalten, die nötig war. Für ein Handyspiel, in dem der Spieler aus drei Stufen wählt, genügt die Zahl der vorgegebenen Ziffern.

Wenn Sie ein ähnliches Problem lösen, Rätsel generieren oder eine mobile App brauchen, schreiben Sie uns. Wie man ein Wortsuchrätsel mit Lösungswort generiert, beschreibt eine eigene Anleitung. Dem Schwedenrätsel mit Lösungswort widmet sich eine weitere Anleitung.

Ein Schwedenrätsel mit Lösungswort generieren Sie in zwei Phasen: Suchen Sie zuerst mit einer lokalen Suche die Maske, also die Verteilung von Fragefeldern und Buchstabenfeldern, und füllen Sie sie dann mit Wörtern aus dem Wörterbuch als Constraint-Satisfaction-Problem (CSP) mit Backtracking. Setzen Sie das Lösungswort nicht vorab ins Gitter. Erst wenn das Rätsel fertig ist, suchen Sie einen Witz, dessen Pointe sich darin von links nach rechts und von oben nach unten lesen lässt.

So entstehen die Schwedenrätsel in unserer App mit Kreuzworträtseln und Wortsuchrätseln (App Store, Google Play). Ein Gitter kostet wenige Sekunden bis einige Dutzend Sekunden Rechenzeit, deshalb generieren wir die Rätsel vorab auf einem leistungsfähigeren Rechner und liefern sie mit der App aus. Wortsuchrätsel entstehen ganz anders und einfacher, das beschreibt der Artikel Wie man ein Wortsuchrätsel mit Lösungswort generiert.

#Was ein Schwedenrätsel erfüllen muss

Ein Schwedenrätsel hat keine schwarzen Felder. Jedes Feld ist ein Buchstabe oder ein Fragefeld mit Pfeil nach rechts oder nach unten. Daraus ergeben sich harte Bedingungen:

• Jeder Buchstabe gehört zu einem waagerechten und einem senkrechten Wort. Ein Buchstabe, den nur ein Wort kreuzt, lässt sich nicht überprüfen und wirkt wie ein Fehler.
• Jedes Wort hat mindestens zwei Buchstaben und davor ein Fragefeld. Deshalb bestehen die erste Zeile und die erste Spalte immer nur aus Fragefeldern.
• Die Buchstaben bilden eine zusammenhängende Fläche ohne abgetrennte Inseln.
• Jedes Wort muss im Wörterbuch stehen und mindestens eine Umschreibung haben. Kein Wort kommt im Gitter zweimal vor.

Dazu kommen weiche Qualitätskriterien: wenige Wörter mit zwei Buchstaben, keine Fragefelder, die ins Leere zeigen, und möglichst wenige sehr lange Wörter, die schwer zu füllen sind. Das Problem ist rechnerisch schwer. Engel et al. (2012) haben gezeigt, dass schon das Füllen einer Maske mit Wörtern NP-vollständig ist.

#Warum Wort für Wort füllen nicht reicht

Der erste Gedanke ist, wie ein Mensch mit Bleistift vorzugehen: das Lösungswort in Wörter teilen, sie wie in der Zeitung in eine Zeile legen, durch jeden Buchstaben ein kreuzendes Wort führen und den Rest des Gitters mit einem Greedy Algorithm auffüllen. Ein Greedy Algorithm wählt in jedem Schritt, was gerade am besten aussieht, und revidiert die Entscheidung nie. Wo nichts passt, bleibt ein Loch. Und weil Greedy-Füllen nicht zurückgehen kann, rettet der Rest des Gitters nichts mehr, wenn die ersten zehn Wörter schlecht sind.

Eine bessere Heuristik für die Wortwahl hilft nur wenig. Sie können die Längen der kreuzenden Wörter von mittleren, um die fünf Buchstaben, hin zu den Extremen probieren. Oder evolutionär vorgehen: eine Population halbfertiger Rätsel, aus jedem fünf Nachkommen mit je einem Wort mehr, bewertet nach gefüllten Feldern, Anzahl der Vokale und Gleichmäßigkeit der Buchstaben, und nur die besten kommen in die nächste Generation. Die Ergebnisse werden etwas dichter, aber die Löcher bleiben, weil die Heuristik nur den nächsten Schritt sieht.

Den Ausweg zeigt die Bachelorarbeit von Jakob Engel an der TU München (2009); er ist auch Erstautor des oben genannten Artikels. Teilen Sie die Aufgabe in zwei unabhängige Phasen: Finden Sie erst eine gute Maske, ohne auf Wörter zu achten, und füllen Sie sie dann. Engel verwendete für die Maske einen evolutionären Algorithmus. Wir verwenden eine einfachere lokale Suche mit zufälligen Erschütterungen, beschrieben im nächsten Schritt.

#Schritt 1: die Maske per Hill Climbing

Die Maske ist ein Gitter, in dem jedes Feld entweder Fragefeld oder Buchstabe ist. Um sie zu finden, reicht Hill Climbing: eine lokale Suche, die kleine Änderungen macht und diejenigen behält, die das Ergebnis nicht verschlechtern.

Beginnen Sie zufällig, mit Fragefeldern auf etwa 22 % der inneren Felder. Geben Sie jeder Maske eine Strafpunktzahl. Harte Verstöße (zu kurzes Wort, Buchstabe ohne kreuzendes Wort, abgetrennte Insel) sollten meist 1.000 Punkte kosten, weiche Mängel (Zweibuchstabenwörter über dem Budget, ein Fragefeld, das auf kein Wort zeigt, gehäufte Fragefelder) 50 bis 500.

Ändern Sie dann in einer Schleife ein Feld von Fragefeld zu Buchstabe oder umgekehrt, oder verschieben Sie ein Fragefeld um ein Feld diagonal. Behalten Sie die Änderung, wenn die Strafe nicht gestiegen ist, sonst machen Sie sie rückgängig. Richten Sie die Hälfte der Änderungen auf die Felder mit der höchsten Strafe, dann verschwinden grobe Fehler schnell:

Hill Climbing bleibt leicht in einem lokalen Minimum hängen. Wenn sich 2.000 Schritte lang nichts verbessert, „schütteln“ Sie das Gitter: Schalten Sie in der besten bisher gefundenen Maske fünf zufällige Felder um und suchen Sie weiter. Das sind die Spitzen im Diagramm. Bringen auch drei Erschütterungen keine bessere Maske und hat sie keine harten Verstöße, hören Sie auf.

Die fertige Maske hat eine Reststrafe von 200 für weiche Mängel, aber keinen harten Verstoß:

Die Strafen für ein Fragefeld ohne Wort und für eine abgetrennte Insel sollten von Anfang an in der Maske stecken. In einem großen Bestand fertiger Rätsel ohne sie zeigten 13,2 % der Fragefelder auf kein Wort, und 23,5 % der Gitter hatten eine abgetrennte Buchstabeninsel. Mit ihnen sind es 5,0 % und 0 %.

#Schritt 2: Füllen mit Wörtern als CSP

Aus der Maske entsteht eine Liste von Slots, also Plätzen für Wörter mit bekannter Länge und bekannten Kreuzungen. Das Füllen ist ein klassisches Constraint-Satisfaction-Problem (CSP): Jeder Slot ist eine Variable, seine Domäne sind die Wörter, die hineinpassen, und die Bedingungen sind gleiche Buchstaben an den Kreuzungen. Gelöst wird es mit Backtracking, einer Suche, die in einem toten Zweig einen Schritt zurückgeht und eine andere Möglichkeit probiert:

für jeden Slot: Domäne = alle Wörter dieser Länge
solange nicht alle Slots gefüllt sind:
    wähle den Slot mit der kleinsten Domäne (bei Gleichstand den mit den meisten Kreuzungen)
    für jedes Wort der Domäne, das beste zuerst:
        setze das Wort
        schränke die Domänen der kreuzenden Slots auf Wörter mit passendem Buchstaben ein
        wenn eine Domäne leer wurde: rückgängig machen, nächstes Wort versuchen
        sonst mit dem nächsten Slot weitermachen
    wenn kein Wort passt: einen Slot zurückgehen
nach 50.000 Schritten aufgeben

In der Literatur heißen diese Heuristiken MRV (Minimum Remaining Values, zuerst der Slot mit den wenigsten Möglichkeiten) und Forward Checking (nach jedem Setzen die Domänen der Nachbarn einschränken, damit ein toter Zweig sofort auffällt und nicht erst zehn Wörter später). Indizieren Sie das Wörterbuch vorab nach Länge, Position und Buchstabe. „Wörter mit Q an dritter Stelle“ sind dann eine einzige Schnittmenge, kein Durchlauf durch das ganze Wörterbuch.

Auch die Reihenfolge der Wörter zählt. Geben Sie Wörtern mit mehr verschiedenen Umschreibungen im Wörterbuch den Vorrang. Das ist ein einfaches Signal für ein gängiges Rätselwort. Ohne das füllt sich das Gitter mit unbekannten Abkürzungen.

#Schritt 3: das Lösungswort im fertigen Gitter

Beim Füllen wissen Sie noch nicht, wie das Lösungswort lautet. Lesen Sie die Buchstaben des fertigen Gitters von links nach rechts und von oben nach unten und suchen Sie einen Witz, dessen Pointe in dieser Zeichenkette als Teilfolge vorkommt. Die Buchstaben stehen also in der richtigen Reihenfolge, müssen aber nicht nebeneinander liegen. Wird einer gefunden, verteilen Sie die Buchstaben möglichst gleichmäßig über das Gitter, damit sich die Pointe nicht aus einem einzigen Wort erraten lässt.

Diese Reihenfolge (erst das Gitter, dann der Witz) erhöht die Zahl fertiger Rätsel drastisch. In unserer Messung passt ein einziges 12×12-Gitter im Schnitt zu 86 Witzen aus der slowakischen Liste (5.960 Witze). Es findet sich also immer einer, der in dieser Größe noch nicht verwendet wurde.

#Warum das Lösungswort nicht vorab wie in der Zeitung

In der Zeitung steht das Lösungswort meist an einer Stelle, in einer Zeile und in Wörter geteilt. Dahin führen zwei Wege, und beide liefern sehr wenige Ergebnisse.

Der erste Weg ist, das Lösungswort vorab ins Gitter zu setzen. Dann muss es hineinpassen. Unsere Pointen haben im Schnitt 10,3 Buchstaben und 2 Wörter. So groß ist der Anteil der Witze aus der slowakischen Liste, die sich in einer bestimmten Größe überhaupt platzieren lassen:

Mit vorab gesetztem Lösungswort gelingt das Füllen kleiner Gitter etwa so oft wie ohne. Bei 15×15 waren es 5 von 60 Versuchen gegenüber 8 ohne, bei 18×18 keiner von 60. Jedes solche Gitter dient außerdem nur einem Witz, und in kleinen Größen lässt sich die Mehrheit der Witze gar nicht platzieren.

Der zweite Weg ist, das Gitter frei entstehen zu lassen und die Pointe darin als zusammenhängenden Abschnitt zu suchen. In einer Stichprobe von 2.200 fertigen slowakischen Rätseln (200 jeder Größe von 8×8 bis 18×18) fand sich die ganze Pointe als zusammenhängender Abschnitt in einer Zeile oder Spalte nur in 81 Gittern (3,7 %). Darf jedes Wort der Pointe an einer anderen Stelle liegen, sind es 443 Gitter (20 %), und das noch ohne die Bedingung, dass die Wörter nebeneinander stehen. In Lesereihenfolge fand sich in jedem von ihnen ein Witz. Für den Preis eines über das Gitter verstreuten Lösungsworts bekommen Sie um Größenordnungen mehr Rätsel.

#Leistung des Generators und warum er nicht auf dem Handy läuft

Der Generator lief mit dem slowakischen Wörterbuch 60 Versuche pro Größe, in einem Thread (JavaScript auf Node 22, Server-CPU Intel Xeon 2,8 GHz in der Cloud). Ein Versuch ist eine Maske und ein Füllvorgang. „Erfolgreich gefüllt“ heißt, dass der CSP innerhalb von 50.000 Schritten eine Lösung gefunden hat.

Was die Messung zeigt:

• Ein kleines Gitter ist kein leichtes. Ein 8×8-Gitter hat viele kurze Slots mit vielen Kreuzungen und wenig Spielraum, das Füllen gelingt nur in 5 % der Versuche. Ein gefülltes Gitter kostet im Schnitt etwa 10 Sekunden Rechenzeit bei 8×8, 4 Sekunden bei 12×12 und 18 Sekunden bei 18×18.
• Die meisten Versuche scheitern. Starten Sie Versuche deshalb parallel auf allen Kernen und nehmen Sie das erste ausreichend gute Ergebnis.
• Auf dem Handy ergibt das keinen Sinn. Niemand will beim Öffnen eines Rätsels Dutzende Sekunden warten, und die App müsste das ganze Wörterbuch mit Umschreibungen mitliefern. Ein Generator in der App muss außerdem ständig die Kontrolle an die Oberfläche abgeben, sonst friert die App ein.

#Generieren in großen Mengen

Der Generator gehört deshalb auf einen Rechner mit Mehrkernprozessor. Bei uns hat jeder Kern einen eigenen Thread mit dem Wörterbuch, das einmal beim Start geladen wird. Ein Gitter ist fertig, sobald einer der Threads ein Ergebnis mit ausreichend wenigen ungenutzten Feldern liefert. Im Dauerbetrieb erzeugt er reihum ein Rätsel jeder Größe in jeder Sprache. So sind über 14.000 Rätsel in vier Sprachen (Slowakisch, Tschechisch, Englisch, Deutsch) und elf Größen von 8×8 bis 18×18 entstanden. Jeder Witz kommt pro Größe und Sprache höchstens einmal vor.

Bei dieser Menge zählen zwei Dinge:

• Format. Ein vollständiger Datensatz braucht etwa 28 kB pro Rätsel und 390 MB für den ganzen Bestand. Das meiste lässt sich berechnen (Koordinaten, Feldtypen, Nummern der Fragefelder). Ein kompaktes Format mit dem Gitter als einer einzigen Zeichenkette braucht etwa 2 kB, 15 MB für den Bestand und etwa 7 MB im Installationspaket der App.
• Qualität messen. Messen Sie nach jeder Generierung den Anteil der Fragefelder ohne Wort und der Gitter mit Inseln, und lassen Sie die Prüfung fehlschlagen, wenn die Zahlen schlechter werden.

#Was der Ansatz nicht abdeckt

• Fragefelder ohne Wort. Das durchschnittliche Rätsel hat immer noch 2,7 Fragefelder, die ins Leere zeigen. Die linke obere Ecke ist immer eines davon.
• Wörterbücher ohne Häufigkeiten. Das deutsche Wörterbuch aus Wiktionary hat für die meisten Wörter nur eine Umschreibung, die Sortierung nach Anzahl der Umschreibungen unterscheidet daher kaum, und seltene Wörter landen im Gitter. Eine Häufigkeitsliste würde helfen, wir haben noch keine.
• Das Lösungswort steht nicht an einer Stelle. Wer es aus der Zeitung kennt, sucht es vielleicht in einer Zeile. Das ist ein Kompromiss, kein Ideal.

Wenn Sie ein ähnliches Problem mit generierten Inhalten lösen oder eine mobile App brauchen, schreiben Sie uns.

Ein 3D-Modell eines Smartphones generieren Sie im Browser, indem Sie ein Rechteck mit abgerundeten Ecken in die Tiefe extrudieren und daraus mit booleschen Operationen (CSG) Vorderseite, Tasten, Lautsprecher und Anschluss ausschneiden. Das ganze Gerät wird dann durch ein paar Zahlen in Millimetern beschrieben, und ein neues Modell bedeutet, diese Zahlen zu ändern, nicht in einem 3D-Programm zu modellieren.

Das lohnt sich überall dort, wo Sie viele ähnliche Geräte brauchen oder Nutzer sie anpassen sollen: Konfiguratoren, Mockups, Produktvorschauen. Ein Beispiel aus der Praxis ist Ecranify, ein Tool für 3D-Mockups für Screenshots im App Store und bei Google Play, das kein einziges fertiges 3D-Modell enthält. Unten finden Sie den Ablauf Schritt für Schritt, samt einer Messung, die zeigt, wo sich bei der Berechnung am meisten sparen lässt.

#Was Sie brauchen

• Three.js für Szene, Kameras, Lichter und vor allem Geometrie. Geometrie ist in Three.js ein Mesh, also eine Menge von Dreiecken.
• Die Bibliothek three-bvh-csg für boolesche Operationen auf Meshes. Sie beschleunigt sie mit einem räumlichen Index (BVH, Bounding Volume Hierarchy) und testet so nicht jedes Dreieck gegen jedes andere.
• Eine Beschreibung des Geräts als Daten, zum Beispiel JSON mit Gehäusemaßen, Eckenradius, Bevel-Größe und einer Liste der Elemente an den Seiten. Geben Sie alle Positionen in Millimetern ab der Gerätemitte an.

#Schritt 1: Ein Rechteck in 3D extrudieren

Zeichnen Sie ein 2D-Rechteck mit abgerundeten Ecken in Originalgröße, zum Beispiel 163,4 × 78 mm, und extrudieren Sie es auf eine Tiefe von 8,75 mm. Sie erhalten eine Platte mit scharfen Kanten. So sieht kein Handy aus, deshalb schalten Sie beim Extrudieren auch einen Bevel ein, also eine abgerundete Kante. Three.js erledigt beides in einem Schritt.

Nur Extrusion

+ Ecken und Bevel

Achten Sie auf eines: Der Bevel wird nach außen hinzugefügt. Wenn Sie exakte Außenmaße brauchen, verkleinern Sie die 2D-Form und die Tiefe um die Bevel-Größe.

b = min(Bevel, Tiefe / 2)
Form = abgerundetes Rechteck(Breite - 2b, Höhe - 2b, Eckenradius - b)
Körper = extrudiere(Form, Tiefe - 2b, Bevel b)

Wie glatt die Rundungen sind (Tessellation), hängt von der Zahl der Segmente ab, in die ein Bogen zerlegt wird. Mehr Segmente bedeuten eine glattere Form und mehr Dreiecke. Diese Zahl entscheidet später über die Geschwindigkeit der ganzen Berechnung, deshalb kommen wir in Schritt 7 darauf zurück.

#Schritt 2: Eine Mulde für das Display ausschneiden

CSG (Constructive Solid Geometry) setzt Körper aus einfacheren Körpern mit drei Operationen zusammen: Vereinigung, Differenz und Schnitt. Die Differenz funktioniert wie ein Bohrer: Ein Körper nimmt Material aus einem anderen weg.

Das Display eines Handys liegt nicht bündig mit dem Rahmen, sondern in einer flachen Mulde. Dafür erstellen Sie eine zweite, um 1,4 mm kleinere Kopie des Körpers, behalten davon nur den vorderen, 0,7 mm dicken Teil (Schnitt mit einem großen Quader) und ziehen diesen Teil vom Körper ab. In die entstandene Mulde legen Sie dann eine dunkle Displayfläche.

Schneidkörper

Nach der Differenz

Zwei praktische Details:

• Der Quader für den Schnitt muss wirklich groß sein. Er muss nur die Tiefe beschneiden, in Breite und Höhe aber das ganze Gerät überragen. Leiten Sie ihn nicht von der Tiefe ab: Das 20-Fache der Tiefe ist bei einem dünnen, hohen Handy zum Beispiel weniger als seine Höhe, und oben und unten bleibt ein unbeschnittener Rahmen stehen.
• Vergrößern Sie den Schneidkörper um ein paar Promille. Wenn zwei Körper exakt dieselbe Fläche haben, kann CSG nicht entscheiden, welche Seite innen liegt. Ein Maßstab von 1,002 verhindert das und ist mit bloßem Auge nicht zu sehen.

#Schritt 3: Seitliche Elemente als Bohrer vorbereiten

Jedes Element an der Seite folgt demselben Rezept mit einem anderen Bohrer. Eine Taste entsteht zum Beispiel aus drei Körpern: Ein abgerundetes Rechteck, etwas tiefer als die Taste, wird vom Rahmen abgezogen, der Rand der Öffnung erhält eine kleine Fase, und in die Öffnung kommt ein etwas kleinerer Körper, der leicht aus dem Rahmen ragt.

Bohrer

Ausschnitt und Taste

Lautsprecher sind eine Reihe kleiner Zylinder, der Anschluss ist ein abgerundetes Rechteck. Setzen Sie in jede Öffnung etwas Dunkles: eine dünne Scheibe ins Lautsprechergitter, eine Platte in den Anschluss. Ein leeres Loch in einer dünnen Schale wirkt wie ein Fehler, ein Loch mit dunkler Füllung wirkt wie Hardware.

für jedes Element in der Liste der Seitenelemente:
    Bohrer = Form des Elements (Zylinder, abgerundetes Rechteck, ...)
    setze den Bohrer an seiner Position in mm auf die Kante
    füge den Bohrer zur Liste der Schnitte hinzu
    wenn das Element eine Füllung hat: füge die Füllung zur Szene hinzu

Eine Taste hinzuzufügen ist dann ein Dateneintrag. Die Elemente summieren sich schnell: Ein iPad Pro 13″ hat 58 Lautsprecherlöcher, 4 Tasten, 2 Antennen und einen Anschluss, also über 60 Differenzen an einem einzigen Körper.

#Schritt 4: Details auf der Vorderseite nicht bohren

Die Kameraaussparung, die Insel oben im Display und der Home-Indikator sind flach. Dafür Geometrie zu schneiden ist verschwendete Arbeit. Bringen Sie sie stattdessen als Decal an, also als Bild, das auf eine Oberfläche projiziert wird. Projizieren Sie es auf eine unsichtbare Ebene über die ganze Vorderseite und geben Sie die Position in denselben Millimetern an wie alles andere. Die Ausnahme ist der runde Home-Button älterer iPhones. Er hat echte Tiefe, die man von der Seite sieht, und geht deshalb durch CSG.

#Schritt 5: Die Berechnung in einen Web Worker verlagern

JavaScript läuft im Browser in einem einzigen Thread. Derselbe Thread rechnet, zeichnet die Seite und reagiert auf Klicks. Solange CSG läuft, steht die Seite still, und auch ein Spinner hilft nicht, weil er denselben Thread braucht.

Starten Sie deshalb den gesamten Aufbau des Geräts in einem Web Worker, also in einem eigenen Hintergrund-Thread. Der Worker erhält die Gerätebeschreibung, gibt fertige Vertex-Arrays zurück, und die Seite bleibt flüssig. Wenn sich ein Parameter ändert, beenden Sie den alten Worker und starten einen neuen, damit er keinen veralteten Zustand zu Ende rechnet.

Das Ergebnis aus dem Worker dauert einen Moment, deshalb ergänzen Sie eine sofortige Vorschau. Zeigen Sie das bearbeitete Element als blauen, durchscheinenden „Geist“, einen einfachen Quader oder Zylinder mit ein paar Dutzend Dreiecken, der sich im Haupt-Thread sofort aufbauen lässt. Wenn der Worker fertig ist, verschwindet der Geist.

#Schritt 6: Alle Löcher auf einmal abziehen

Am direktesten ist es, die Elemente nacheinander abzuziehen: Loch 1 vom Körper, dann Loch 2 vom Ergebnis und so weiter. Jede Differenz baut aber den räumlichen Index des ganzen Körpers neu auf, und das ist der teuerste Teil der Berechnung. Bei Dutzenden Elementen wächst die Zeit sehr schnell.

Besser ist es, zuerst alle Bohrer für einen Körper zu sammeln, sie zu einem Mesh zu verbinden und einmal abzuziehen.

Schnitte = []
für jedes Element: füge seinen Bohrer zu Schnitte hinzu
verbunden = verbinde alle Schnitte zu einem Mesh
Körper = Körper minus verbunden
wenn das Verbinden scheitert: ziehe die Schnitte einzeln ab

Gemessen an einer vereinfachten Kopie des Ablaufs (Three.js 0.170, three-bvh-csg 0.0.17, Node 22, Cloud-Server mit 2 Kernen Intel Xeon 2,1 GHz, Median aus 5 Läufen):

Eine Bedingung: Verbinden und einmal Abziehen liefert nur dann dasselbe Ergebnis wie das schrittweise Abziehen, wenn sich die Bohrer nicht überlappen. Die Elemente sitzen an verschiedenen Stellen, also gilt das in der Regel. Schiebt ein Nutzer aber zwei Elemente übereinander, kann an der Überlappung ein kleiner Fehler entstehen.

#Schritt 7: Die Segmentzahl als Parameter führen

Eine Tessellation, die für die Anzeige passt, ist für CSG oft unnötig dicht. Mit 64 Segmenten pro Ecke und 32 für den Bevel hat der Körper 68.108 Dreiecke. Die Hälfte (32 und 16) sieht man an einer 2-mm-Kante nicht, der Körper hat dann aber nur 17.676 Dreiecke, und die dritte Zeile der Tabelle zeigt, was das für die Zeit bedeutet.

64 und 32 Segmente

32 und 16 Segmente

Geben Sie kleinen Elementen mit einem Radius bis 2 mm (Lautsprecherlöcher, Schrauben) die Hälfte der Segmente, Vorschaubildern in der Galerie noch weniger. Legen Sie die Qualität deshalb nicht als Konstante im Code fest, sondern als Parameter des Aufbaus.

#Rendern auf einem Server ohne Grafikkarte

Wenn Sie dieselbe Szene auch auf einem Server rendern müssen, etwa als Backup für Exporte, läuft sie in Chrome ohne Bildschirm (headless), das ohne Grafikkarte in Software zeichnet. Dort vervielfacht sich jede Ineffizienz. In Ecranify lief das schwerste Tablet ohne die genannten Anpassungen in das Limit von 15 Minuten. Mit verbundenen Schnitten, kleineren Texturen, geringerer Tessellation und einem Cache fertiger Geometrie, dessen Schlüssel ein Hash der Gerätebeschreibung ist, dauert ein Render etwa eine halbe Minute und ein wiederholter etwa 5 Sekunden. Die Details mit interaktiven Beispielen stehen im englischen Artikel auf ecranify.com.

Wenn Sie ein ähnliches 3D-Problem im Browser lösen oder eine App nach Maß brauchen, schreiben Sie uns.

Öffnen Sie ein Unity-4-Projekt nicht direkt in Unity 6 und speichern Sie darin vor allem nichts. Unity 6 lädt die alten binären Szenen nur teilweise, und das Speichern macht den Verlust endgültig; der sichere Weg führt über Unity 2019.4, das das alte Format lesen und als Text zurückschreiben kann, und erst danach zu Unity 6.

Das betrifft Projekte, deren Szenen und Prefabs im Binärformat gespeichert sind und deren Skripte in UnityScript geschrieben wurden, einer JavaScript-ähnlichen Sprache, die Unity früher neben C# unterstützte. Als Beispiel dient Onager, ein Physikspiel mit Katapult, geschrieben in Unity 4.1.2 und UnityScript. Das Projekt hatte 126 Skripte, 75 Szenen und 78 Prefabs. Nach der Umstellung läuft es auf Unity 6000.5 mit URP (Universal Render Pipeline) und ist kostenlos im App Store und bei Google Play.

#Was passiert, wenn Sie das Projekt in Unity 6 öffnen

Der einfachste Ansatz ist, das Projekt in Unity 6 zu öffnen und die Serialisierung auf Force Text umzustellen, also Assets als lesbares YAML zu speichern. Das ist aber keine Übersetzung der Dateien. Unity lädt jedes Asset über seinen Importer und schreibt es als YAML zurück, alles läuft also durch den Loader von Unity 6. Der meldet in jeder Szene einen Transform ohne GameObject und löscht die „hängende“ Komponente. Beim Speichern wird das endgültig.

Den Verlust können Sie mit binary2text messen, einem Werkzeug, das dem Editor beiliegt und eine serialisierte Datei ohne Importer liest. Bei Onager haben wir die Ausgabe mit dem entstandenen YAML verglichen und nur Komponenten gezählt, die von überlebenden GameObjects verschwunden sind:

Keine der 75 Szenen kam ohne Verlust durch. Ganze HUD-Kameras verschwanden, und an die Stelle der Hauptkamera trat eine neue Standardkamera. Wichtig ist: Der Schaden entsteht schon beim Laden, nicht beim Speichern. Solange das Projekt nicht konvertiert ist, darf Unity 6 es nicht speichern, keine einzige Szene und kein einziges Prefab.

#Schritt 1: Den Ausgangszustand festhalten

Bevor Sie irgendetwas anfassen, machen Sie von jeder Szene einen Screenshot und speichern Sie für jede ursprüngliche Szenendatei einen Dump mit binary2text. Mit diesen Dumps prüfen Sie in Schritt 3 die Kameras und stellen in Schritt 5 das HUD wieder her. Lassen Sie die ursprünglichen Binärdateien in der git-Historie und löschen Sie sie nicht.

#Schritt 2: Über Unity 2019.4 in Text konvertieren

Unity 2019.4 ist der letzte Editor, der das Format von Unity 4.1 lesen und schreiben kann. Konvertieren Sie bei geschlossenem Editor in einer separaten Kopie des Repositorys:

• Projektversion. Tragen Sie in der Datei mit der Projektversion die ursprüngliche Version ein (bei Onager 4.1.2), damit der Editor den Weg für alte Projekte nimmt. Unity überschreibt sie beim Öffnen, sie muss nur für den ersten Import gelten.
• Leere Pakete. Leeren Sie die Liste der Paketabhängigkeiten. Ein einziger Kompilierfehler bedeutet, dass kein Menüeintrag aus Editor-Skripten funktioniert, und das sieht aus, als wäre das Menü nie erschienen.
• Import von Grund auf. Löschen Sie den Ordner Library und lassen Sie das Projekt importieren.
• Force Text und erzwungenes Neuschreiben. Unity 2019.4 schreibt vorhandene Dateien nach dem Umstellen auf Force Text nicht von selbst neu. Sie müssen das mit der Funktion zur Reserialisierung von Assets auslösen, und zwar nur für die Assets, nicht für ihre Meta-Dateien. Das Neuschreiben aller Meta-Dateien führt dazu, dass Unity 6 danach endlos neu importiert.

Eine Falle steckt in git. Wenn Ihre git-Attribute Szenen als Text mit LF-Zeilenenden markieren, entfernt git beim Hinzufügen zum Repository aus binären Szenen Bytes, die wie Zeilenenden aussehen. Bei Onager hat das acht Szenen beschädigt. Setzen Sie für Unity-Assets kein Zeilenende-Attribut, Unity schreibt ohnehin LF.

#Schritt 3: Das Ergebnis im Editor prüfen, nicht im YAML

Das Lesen der konvertierten Dateien führt zu selbstsicheren falschen Schlüssen. Verkürzte Einträge von Prefab-Instanzen sehen wie ein Verlust aus, ebenso eine Kamera, die nur in ein Prefab gewandert ist. Entscheidend ist, was Unity im Speicher aufbaut. Öffnen Sie jede konvertierte Szene und vergleichen Sie ihre Kameras mit dem Dump des Originals aus Schritt 1.

Bei Onager hatten danach alle 75 Szenen dieselben Kameras in derselben Reihenfolge. Verloren ging nur, was kein heutiger Editor mehr kennt: 569 GUITexture, 179 GUIText und die alten Partikelsysteme, die Unity 2018 entfernt hat.

#Schritt 4: UnityScript nach C# mit derselben GUID

Unity hat UnityScript ab Version 2017.2 schrittweise abgeschafft, ein manueller Port nach C# ist also der einzige Weg. Szenen verweisen auf Skripte über die GUID, eine eindeutige Kennung, die Unity in der Meta-Datei jedes Assets speichert, und speichern Feldwerte nach dem Feldnamen. Wenn Sie beides beim Port beibehalten, verbinden sich alle Verweise von selbst:

für jedes UnityScript-Skript X:
  lege ein C#-Skript mit einer Klasse namens genau X an
  kopiere die GUID aus der Meta-Datei des alten Skripts in die des neuen
  öffentliche Felder: gleicher Name, gleicher Typ, auch mit Tippfehlern
  nichts umbenennen, bis das Projekt läuft

Bei Onager verbanden sich so nach dem Port aller 126 Skripte 12.935 Komponenten in 73 Szenen, und alle im Inspector gesetzten Werte blieben erhalten.

Per Textsuche im Projekt lässt sich nicht ermitteln, welche Skripte verwendet werden. Ein binäres Prefab speichert die GUID als Bytes, nicht als Text. Bei Onager wirkten so einundzwanzig Skripte ungenutzt, und alle waren aktiv. Achten Sie auch auf Reste früherer Port-Versuche: Ein Holzblock-Prefab zeigte auf zwei Skripte aus einem solchen Versuch, und allein dadurch fehlten 1.140 Komponenten. Wenn Sie in einer Binärdatei eine GUID ändern müssen, tauschen Sie sie direkt in den Bytes, sechzehn gegen sechzehn, damit sich die Datei nicht verschiebt.

#Schritt 5: Das HUD aus den ursprünglichen Binärszenen wiederherstellen

GUITexture und GUIText gibt es in Unity 6 nicht, und mit ihnen verschwindet das ganze darauf aufgebaute HUD. Neu zeichnen müssen Sie es nicht. binary2text liest die ursprünglichen Binärszenen aus der git-Historie unabhängig davon, ob die Klassen noch existieren. Ziehen Sie daraus jedes HUD-Bild und jeden HUD-Text mit Textur, Farbe, Position und Ausrichtung und setzen Sie sie per Skript auf dieselben Objekte in den Szenen zurück. Bei Onager waren es 577 Bilder und 180 Texte.

So retten Sie auch Texte, die es nirgendwo sonst gibt. Bei Onager waren es 111 Texte: alle Tutorial-Untertitel und die ganze Credits-Tafel. Ein HUD von Grund auf zu schreiben hätte bedeutet, sie zu erfinden. Beim Übertragen der Farben gilt etwas, das die Dokumentation nicht sagt: Das alte GUITexture verdoppelte die Farbe beim Zeichnen. Alle 577 Bilder hatten eine Farbe von genau 0,5, Grau bedeutete also Weiß.

#Nach der Konvertierung: alte Behelfslösungen ersetzen

Alte Projekte umgingen oft die Grenzen des damaligen Unity, und diese Behelfslösungen lohnt es sich nach der Konvertierung neu zu bauen:

• Spiegelung im Boden. Onager hatte einen glänzenden Boden ohne echte Spiegelung. Unter dem Boden stand eine zweite, gespiegelte Welt: eine Kopie jedes Objekts, deren Position ein Skript in jedem dritten Frame vom Original übernahm, in einem Level 50 bis 70 Klone. Ersetzen lässt sich das durch eine zusätzliche Kamera, die die Spiegelung in halber Auflösung zeichnet. Dann spiegeln sich auch Partikel und Trümmer, was die geklonte Welt nicht konnte.
• Zielen. Wenn die Flugbahnvorschau vorhersagen soll, wohin eine im ersten Physikschritt hinzugefügte Kraft den Schuss schickt, landet er woanders als die Markierung. Zuverlässiger ist es, die Geschwindigkeit einmal zu berechnen, die Vorschau genau daraus zu zeichnen und sie dem Schuss direkt zuzuweisen.
• Leistung. Messen Sie auf einem schwachen Handy. Auf einem Motorola G52 fiel Onager allein wegen des Wand-Shaders von 20 auf 6 fps, mehr als Auflösung, Schatten und Spiegelung zusammen. Bei niedriger und mittlerer Detailstufe haben die Wände deshalb ein einfacheres Material.

Wenn Sie im aktuellen Unity Physik für Tausende Objekte lösen, lesen Sie auch über den Fake-Ragdoll für Tausende Gegner in Unity DOTS. Wie Sie einem alten 2D-Spiel nach der Umstellung in URP Glow und 2D-Lichter geben, beschreibt eine eigene Anleitung.

#Was dieses Vorgehen nicht löst

Komponenten, die das heutige Unity nicht kennt, verbinden sich nicht. GUITexture und GUIText müssen Sie wie in Schritt 5 wiederherstellen, die alten Partikelsysteme gehen verloren. Klassen- und Feldnamen bleiben genau wie im ursprünglichen Projekt, mit Tippfehlern und in der Sprache, in der sie jemand einmal geschrieben hat. Szenen binden über den Namen an sie, daher ist Umbenennen nur über den Editor sinnvoll, der die Verweise selbst umschreibt.

Wenn Sie ein altes Unity-Projekt auf eine aktuelle Version bringen müssen, schreiben Sie uns.

Steuern Sie eine Horde aus Tausenden Gegnern in Unity DOTS mit einem einzigen Flow Field für die ganze Karte und ein paar günstigen lokalen Regeln: Abstoßen von Nachbarn und Wänden, Wegkosten nach Dichte der Menge und ein Zustand „warten“ im Stau. Im Unity Editor auf einem MacBook mit M3 Pro schafft das rund 9.600 Gegner gleichzeitig bei 90 FPS.

Das Problem tritt in Tower-Defense-, Strategie- und Survival-Spielen auf, in denen Tausende Einheiten gleichzeitig auf ein Ziel zulaufen. Klassisches Pathfinding für jede Einheit einzeln ist zu teuer, und ohne lokale Regeln überlappt sich die Menge, klebt an Wänden und bleibt in Engstellen hängen. Unity DOTS (Data-Oriented Technology Stack, also Entities, ECS und das Job System) liefert die Leistung für Tausende Entities, die Navigation selbst löst es aber nicht. Wir nutzen das folgende Vorgehen in unserem Tower-Defense-Spiel für PC (es steht in unseren Referenzen). Die Bilder stammen aus einer vereinfachten 2D-Simulation mit denselben Regeln, nicht aus dem Spiel.

#Schritt 1: Flow Field statt eines Pfads pro Einheit

Ein Flow Field ist ein Raster über die ganze Karte, in dem jede Zelle weiß, in welche Richtung es von ihr zum Ziel geht. Ein Gegner sucht keinen Pfad, er liest nur die Richtung an der Stelle ab, an der er steht. Die Kosten sind für 10 und für 10.000 Gegner gleich.

Teilen Sie die Karte in Zellen von 1 m auf (unser Testlevel hat 128 × 128) und berechnen Sie für jedes Ziel einmal die Entfernung jeder Zelle zum Ziel. Ein statisches Feld lässt sich im Editor bei der Vorbereitung des Levels berechnen und in einem Asset speichern.

Die einfachste Variante ist Dijkstra über 8 Nachbarn und in jeder Zelle eine von 8 Richtungen. Das funktioniert, aber die Gegner laufen diagonal und kleben im Gänsemarsch an Wänden.

8 Richtungen

Glattes Feld

Ein glattes Feld liefert ein besseres Ergebnis. Berechnen Sie die Entfernung durch Lösen der Eikonal-Gleichung (eine Wellenfront-Gleichung, deren Lösung die kürzeste Entfernung im kontinuierlichen Raum ist, nicht nur entlang der Rasterkanten) mit der Fast-Sweeping-Methode, die das Raster wiederholt von allen vier Ecken aus durchläuft. Die Richtung ist dann nicht die Richtung der Zelle, sondern der Gradient der Entfernung an der genauen Position des Gegners. Schlagen Sie auf die Kosten einer Zelle einen Aufschlag für Wandnähe auf, dann hält das Feld die Menge von selbst etwas von Hindernissen fern.

#Schritt 2: Ein eigenes Feld für jede Gegnergröße

Ein großer Gegner passt nicht überall hin, wo ein kleiner hinpasst. Führen Sie Größenklassen ein: Jede hat eine eigene Begehbarkeit (eine Zelle muss weit genug von der Wand entfernt sein) und ein eigenes Feld pro Ziel. Halten Sie die Klassen als Leveldaten, nicht im Code. Bei uns sind es drei.

#Schritt 3: Abstoßen von Nachbarn

Ein Flow Field gibt die Richtung vor, weiß aber nichts über Nachbarn. Die Grundlage ist ein vereinfachtes Boids-Modell (die klassischen Schwarmregeln): Jeder Gegner stößt sich von Nachbarn im Umkreis von 0,9 m ab. Suchen Sie Nachbarn in einem Spatial Hash, einem Raster, in dem jede Zelle eine Liste der Einheiten darin hält. Bauen Sie den Hash jeden Tick neu auf und sortieren Sie ihn, damit die Reihenfolge deterministisch bleibt.

Abstoßung allein reicht nicht. Bei 3.000 Gegnern hatten 83,7 % ihren nächsten Nachbarn näher als 0,8 m, und der kleinste Abstand lag bei 4 cm, also zwei Gegner fast ineinander.

Ein höheres Gewicht der Abstoßung löst das nicht. Bei Gewicht 6 statt 1,5 sank der Anteil der zu dicht stehenden auf 54,6 %, bei 12 auf 44,3 %, bei 24 brachte es nichts mehr (48,2 %). Dazu beginnt die Menge zu zappeln, weil sich unbegrenzte Stöße vieler Nachbarn gleichzeitig addieren.

Eine Positionskorrektur hilft. Schieben Sie nach der Bewegung jedes überlappende Paar auseinander, jeden um die Hälfte der Überlappung, und begrenzen Sie die Verschiebung auf 0,15 m pro Tick. Ohne diese Grenze springt die Korrektur genauso wie das hohe Gewicht. Mit ihr bleiben 60,8 % zu dicht, aber der kleinste Abstand steigt auf 28 cm und die Menge bleibt ruhig.

Nur Abstoßung

Überlappungskorrektur

#Schritt 4: Abstoßen von Wänden

An der Wand versagt die Korrektur zwischen Gegnern. Bewegung in die Wand ist verboten (die Verschiebung wird nach Achsen zerlegt und der Anteil in die Wand verworfen), also kann ein angedrückter Gegner nirgends ausweichen und die Korrektur vom Nachbarn geht verloren. Von 938 überlappenden Gegnern hatten nur 35 überhaupt einen Druck von der Wand.

Fügen Sie deshalb ein Abstoßen von den nächsten nicht begehbaren Zellen hinzu, in 4 Richtungen und diagonal. Zwei Fehler lassen sich vermeiden:

• Innenecke. Der Druck von beiden Kanten und von der Ecke addiert sich und schleudert den Gegner weg. Fügen Sie den Eckdruck nur an einer Außenecke hinzu.
• Echte Wände. Stoßen Sie von den echten Wänden ab, nicht von der Begehbarkeit der Größenklasse. Für einen großen Gegner beginnt die „Wand“ schon einen Meter vor der echten. Am Eingang eines Gangs hob der Eckdruck so die Vorwärtsbewegung eines großen Gegners auf, und die ganze Gruppe hinter ihm blieb stehen.

#Schritt 5: Kosten nach Dichte und Abbremsen

Auch mit einem glatten Feld nimmt die ganze Menge den kürzesten Weg eng um die Ecke, egal wie viele Gegner schon dort sind. Eine Lösung bietet Continuum Crowds (Treuille et al., 2006): Die Kosten einer Zelle steigen mit der Dichte der Menge. Zählen Sie alle 10 Ticks die Gegner pro Zelle, glätten Sie das Ergebnis und berechnen Sie das Feld eines Ziels neu. An einer überfüllten Ecke schickt das Feld die Gegner dann außen herum, durch freiere Zellen.

Ohne Dichte

Kosten nach Dichte

Die zweite Hälfte ist das Abbremsen. Ein Gegner in einer dichten Zelle läuft langsamer, minimal mit 15 % seiner Geschwindigkeit. Bei 2.250 Gegnern liefen sie in dünn besetzten Zellen im Schnitt mit 94 % ihrer Geschwindigkeit, bei mittlerer Dichte mit 71 % und im Stau mit 20 %. Lassen Sie das Abbremsen früh beginnen: Mit einer Schwelle für freie Dichte von 0,6 Gegnern pro Zelle statt 1 sank der Anteil der zu dicht stehenden in der Engstelle auf 36,7 %.

Ein Tipp aus der Praxis: Allokieren Sie Arrays, die erst zur Laufzeit entstehen (etwa die Dichtekarte), bevor ein Job sie zum ersten Mal nutzt. Ein Job mit einem noch nicht angelegten Array lässt den Unity Editor nativ abstürzen, ohne Exception.

#Schritt 6: Stau in der Engstelle: warten statt drücken

Wenn sich die Menge nirgends verteilen kann, bleibt nur die Engstelle. Die einfachste Idee ist, den Geschwindigkeitsanteil in Richtung eines berührten Nachbarn zu verwerfen. Die Hinteren bleiben dann stehen, statt auszuweichen, und halten den Stau am Leben.

Seitlich auszuweichen, etwa um 35° zur Seite mit weniger Nachbarn, ist besser, aber die Menge beginnt zu flackern. Eine geglättete Ausrichtung und eine niedrigere Drehgeschwindigkeit (180 statt 360 °/s) dämpfen nur das Symptom. Die Ursache liegt woanders: Bei ausgeglichener Dichte wählt der Gegner jeden Tick eine andere Seite. Hysterese hilft, also eine Bevorzugung der vorherigen Entscheidung: Die Seite aus dem letzten Tick bekommt beim Vergleich einen Bonus von 3 Nachbarn.

Die endgültige Lösung verbindet eine Kontaktbedingung mit drei Zuständen: gehen, ausweichen, warten. Der Geschwindigkeitsanteil in einen berührten Nachbarn wird verworfen, der seitliche bleibt. Wer weder eine freie Seite noch Platz vor sich hat, wartet und drückt nicht.

für jeden Gegner, jeden Tick:
    Geschwindigkeit = Richtung aus dem Flow Field × Tempo × Abbremsen nach Dichte
    Geschwindigkeit += Abstoßung von Nachbarn
    wenn vorne ein Nachbar berührt wird:
        wenn eine Seite frei ist: ausweichen (Seite mit Hysterese)
        sonst: warten
    Geschwindigkeitsanteil in berührte Nachbarn verwerfen
    bewegen, Anteil in die Wand verwerfen
danach für alle:
    überlappende Paare auseinanderschieben (halbe Überlappung, höchstens 0,15 m)
    von Wänden abstoßen

Achten Sie auf drei Dinge:

• Geduld. Wenn sich zwei Gegner frontal begegnen, soll der mit der höheren ID warten. Eine Kette von Nachbarn kann ihn aber Tausende Ticks blockieren, deshalb versucht er nach einem Wartelimit ein Notausweichen.
• Nullgeschwindigkeit. Ein Gegner mit gewünschter Geschwindigkeit null verlässt den Zustand „warten“ nie und bleibt nach einer Welle auf freier Fläche stehen. Wer sich nicht bewegen will, sollte immer im Zustand „gehen“ sein.
• Schmaler Kegel. Suchen Sie den Nachbarn vorne in einem schmalen Kegel mit kurzer Sonde. Bei 45° schickte die Einstellung 55 bis 60 % der Menge auch auf freier Fläche ins Warten oder Ausweichen, bei 30° und kürzerer Sonde 41 %.

#Schritt 7: Große Gegner überholen

Unterschiedlich große und schnelle Gegnertypen bringen weitere Fälle. Unser großer, langsamer Gegner hat in der Menge einen Radius von 1,25 m und läuft 1,1 m/s. Ein schneller Gegner dahinter konnte ihn nicht überholen: Die seitlichen Sonden schräg nach vorne waren immer näher am großen als die Summe der Radien, beide Seiten galten als belegt und der schnelle wartete. Die Lösung: Den Nachbarn, der gerade umgangen wird, berücksichtigt die Sonde nur auf seiner eigenen Seite. Ein Nachbar genau voraus blockiert keine Seite.

Der große Gegner wiederum stößt kleine aus seinem Weg zur Seite, in einem Sektor von ±45° vor sich. Stoßen Sie keine weg, die schneller in seine Richtung laufen, als er selbst will, sonst trifft es auch die, die ihn gerade überholen.

#Schritt 8: Slots am Angriffsziel

Wenn Gegner im Nahkampf angreifen, brauchen sie Platz um das Ziel. Unser Turm hat 24 Slots am Rand seiner Grundfläche von 5 × 5 m, jeder Gegner belegt einen und die anderen warten in einer Schlange.

• Im Kreis umrunden. Wenn Sie einen Slot nur anbieten, wenn eine gerade Linie zu ihm führt, bleiben die hinteren Slots leer, weil die Linie von vorne den Turm schneidet. Lassen Sie den Gegner den Turm im Bogen zu einem freien Slot umrunden.
• Kein Verdrängen. Verdrängen Sie keinen Gegner auf dem Weg zum Slot zugunsten eines anderen Anwärters. Das löst Ketten von Verdrängungen aus.
• Kein Abstoßen am Slot. Ein Gegner, der neben einem belegten Slot ankommt, wird vom Nachbarn weggestoßen und landet 13 cm neben seinem Ziel oder ganz daneben. Gegner im Slot und bis 0,5 m davon stoßen sich nicht gegenseitig ab.

#Performance von Simulation und Rendering

Ein Benchmark im Unity Editor (M3 Pro, rund 9.600 einfache Gegner, zwei Engstellen) ergab 90 FPS bei 1440p und 100 bei 1080p. Die Auflösung ändert die FPS kaum, die Zeitbeschleunigung schon: Bei 10× fällt sie auf 20 FPS, weil pro Frame zehn Simulationsschritte laufen. Bei normaler Geschwindigkeit hat die Simulation Reserven.

Mit einem detaillierten Gegnermodell statt einer Kapsel verlagert sich der Engpass ins Rendering:

In der Simulation lohnen sich drei Dinge:

• Zwei Durchläufe über Nachbarn. Der günstige (Kontakte, Blockieren) läuft immer, der teure (seitliche Sonden, Dichte der Seiten) nur für blockierte Gegner, im freien Strom eine Minderheit. Vergleichen Sie Abstände im Quadrat, ohne Wurzel.
• Einfaches Sortieren. Synchrones Sortieren des Spatial Hash dauerte bei 3.000, 10.000, 20.000 und 50.000 Einträgen 0,37, 1,49, 3,16 und 8,46 ms, die Job-Variante 0,18, 0,93, 3,12 und 15,53 ms. Der Job ist nicht durchgehend schneller, einfaches Sortieren reicht.
• Zustands-Hash. Berechnen Sie bei Tick 600 und 1800 einen Hash über Positionen und Lebenspunkte. Ein Refactoring muss denselben Hash ergeben, eine Verhaltensänderung ändert ihn, und Sie können erklären, warum. Das funktioniert dank der deterministischen Reihenfolge im Spatial Hash.

#Grenzen des Ansatzes

• Zwei volle Mengen in Gegenrichtung in einer Engstelle verkeilen sich dauerhaft. Das ist eine Grenze eines Modells ohne Physik.
• Die Zahlen stammen aus dem Unity Editor auf einem M3 Pro. Messungen auf dem Steam Deck und in einem echten Build haben wir noch nicht, nur eine Schätzung aus öffentlichen CPU-Benchmarks.

Wenn Sie eine eigene Menge ausprobieren wollen, ist die Dokumentation von Unity Entities ein guter Start. Einen ähnlichen Weg von der einfachsten zur funktionierenden Lösung beschreibt auch unser Artikel über den Sudoku-Generator. Wie Sie Gegner in so einer Horde per Explosion wegschleudern, ohne für jeden einen teuren Ragdoll zu simulieren, zeigt die Anleitung zu Fake-Ragdolls in Unity DOTS. Wenn Sie an einer ähnlichen Simulation in Unity arbeiten und Hilfe möchten, schreiben Sie uns.

Ein Wortsuchrätsel mit Lösungswort generieren Sie so: Legen Sie zufällige Wörter aus dem Wörterbuch in ein leeres Gitter, bis genau so viele Felder frei bleiben, wie das Lösungswort Buchstaben hat. Diese Felder füllen Sie dann mit dem Lösungswort, von links nach rechts und von oben nach unten. Auf dem Handy dauert das ein paar Millisekunden und braucht kein Backtracking, also kein Zurückgehen zu früheren Entscheidungen, wenn der Generator feststeckt.

Ein Wortsuchrätsel ist ein Buchstabengitter, in dem man Wörter aus einer Liste sucht und streicht. Das Lösungswort ergibt sich aus den Buchstaben, die danach übrig bleiben. Der Generator muss also ein vollständig gefülltes Gitter bauen, in dem nach dem Streichen genau das Lösungswort stehen bleibt. Mit dem folgenden Ablauf entstehen die Wortsuchrätsel in unserer App mit Kreuzworträtseln und Wortsuche (App Store, Google Play).

#Regeln für das Gitter

Legen Sie vorher fest, was ein fertiges Gitter erfüllen muss. In unserer App gilt:

• Wörter laufen in acht Richtungen: waagerecht, senkrecht und entlang beider Diagonalen, jeweils auch rückwärts.
• Zwei Wörter dürfen sich höchstens einen Buchstaben teilen.
• Kein Wort darf durch ein Feld des Lösungsworts laufen.
• Das Gitter muss voll sein. Ein leeres Feld ist ein Fehler.
• Das Lösungswort wird von links nach rechts und von oben nach unten aus allen nicht gestrichenen Buchstaben gelesen.

#Schritt 1: Wörterbuch vorbereiten

Teilen Sie das Wörterbuch einmal am Anfang in Gruppen nach Wortlänge auf. Ein zufälliges Wort einer bestimmten Länge ist dann ein einziger Zufallsindex. Wenn Sie für jedes Wort das ganze Wörterbuch filtern, wird die Generierung spürbar langsamer, denn für ein Gitter werden Hunderte Wörter probiert.

Unser slowakisches Wörterbuch hat 16.713 Wörter mit 3 bis 21 Buchstaben, die meisten mit sieben oder acht, das deutsche 134.937. Ein paar praktische Tipps:

• Lassen Sie Eigennamen und Abkürzungen im Wörterbuch. Dann tauchen im Gitter Wörter wie HOUSTON oder MAINE auf. Ohne kurze und „seltsame“ Wörter lässt sich das Gitter nicht dicht genug füllen.
• Filtern Sie Vulgäres mit einer eigenen Liste, die sich abschalten lässt, wenn jemand Inhalte für Erwachsene will.
• Bei mehreren Sprachen laden Sie nur die gerade gespielte. Das englische Wörterbuch hat über 414.000 Wörter. Werden beim App-Start alle vier Sprachen auf einmal geladen, steht ein schwächeres Handy bis zu 11 Sekunden still.

#Schritt 2: Lösungswort wählen

Das Lösungswort sollte mindestens so viele Buchstaben haben wie die Gitterseite und höchstens vier mehr. Ein kürzeres geht im Gitter unter, ein längeres braucht zu viele Löcher.

In unserer App ist das Lösungswort die Pointe eines Witzes. Man streicht die Wörter und liest aus den übrigen Buchstaben, wie der Witz endet. Wir bauen das Lösungswort vom Ende des Witzes: Von hinten kommen ganze Wörter dazu, bis die Länge in diesem Bereich liegt.

Die Bilder unten verwenden den englischen Witz „Two snakes walk into a bar. Turns out they were lizards.“ (Zwei Schlangen gehen in eine Bar. Es stellt sich heraus, dass es Eidechsen waren.) auf einem 10×10-Gitter. Das Lösungswort ist WERELIZARDS, 11 Buchstaben. Die Wörter in den Bildern stammen aus dem englischen Wörterbuch, beschränkt auf geläufige Wörter, damit sie lesbar sind.

#Warum nicht mit dem Lösungswort beginnen

Die erste Idee ist, es wie mit dem Bleistift zu machen: die Buchstaben des Lösungsworts in Lesereihenfolge auf zufällige Felder verteilen und dann Wörter darum herum bauen.

Das sieht vernünftig aus, bis das Ende kommt. Der Generator wählt ein leeres Feld, versucht ein Wort in allen Richtungen und Verschiebungen hindurchzulegen, und wenn das Gitter dicht wird, bleiben isolierte Löcher. Ein einzelnes Loch zwischen zwei Buchstaben des Lösungsworts lässt sich mit nichts füllen, denn das kürzeste Wort hat drei Buchstaben und kein Wort darf durch das Lösungswort laufen.

Bei einer Stichprobe von 200 Gittern 10×10 ergab dieser Ansatz nur in 28 % der Fälle ein volles Gitter, im Schnitt blieben 1 bis 2 Löcher. Sie nachträglich zu flicken ist aufwendig. Setzen Sie das Lösungswort also erst ein, wenn die Wörter fertig sind.

#Schritt 3: Gitter füllen, bis genau N Löcher übrig sind

Das Füllen ist ein einfacher Greedy Algorithm: Jedes Wort wird gelegt, sobald es passt, und nie wieder entfernt. Der Generator merkt sich nur eine Zahl: wie viele Felder noch leer sind. Ein Wort legt er nur, wenn danach nicht weniger leere Felder übrig bleiben, als das Lösungswort Buchstaben hat (N).

leer = Zeilen × Spalten
solange leer > N und Versuche < 2000:
    wort = zufälliges Wort der gewählten Länge
    höchstens 50-mal wiederholen:
        start = zufälliges Feld, richtung = zufällig aus 8
        wenn das Wort nach den Gitterregeln passt:
            neu = Anzahl leerer Felder, die das Wort füllt
            wenn leer - neu >= N:
                Wort legen
                leer = leer - neu
                weiter mit dem nächsten Wort
wenn leer != N: Gitter wegwerfen und neu anfangen

Die ersten Wörter landen frei im leeren Gitter:

Mit der Zeit beginnen Wörter, Buchstaben zu teilen. Das ist erwünscht, denn jeder geteilte Buchstabe ist ein Feld weniger, das gefüllt werden muss:

Sobald die Zahl der leeren Felder auf N fällt, ist Schluss. Wo die Löcher liegen, ist egal. Sie dürfen überall verstreut sein, weil das Lösungswort keinen zusammenhängenden Weg bilden muss:

#Schritt 4: Wortlängen mit Verstand ziehen

Lange Wörter machen ein Wortsuchrätsel interessant, kurze machen es fertig. Ziehen Sie die Länge deshalb aus zwei Normalverteilungen (normalverteilte Zufallszahlen liefert zum Beispiel die Box-Muller-Methode):

Die Länge ist immer mindestens 3 und höchstens die Gitterseite. Dazu zwei Regeln, ohne die der Generator am Ende hängen bleibt:

• Erzwingen Sie am Ende die genaue Länge. Fehlen 5 oder weniger Felder, suchen Sie ein Wort mit genau der fehlenden Länge (mindestens 3). Sonst versucht der Generator endlos Sechs-Buchstaben-Wörter, die nicht mehr passen.
• Rationieren Sie Wörter mit drei Buchstaben. Die ersten drei Versuche an einem Gitter dürfen keins enthalten, Versuche 4 bis 6 eins, die nächsten drei zwei und so weiter. Drei Buchstaben sind im Wörterbuch oft Abkürzungen wie DNA oder CPU und wirken im Rätsel billig. Erlauben Sie sie erst, wenn es anders nicht geht.

#Schritt 5: Lösungswort in die Löcher gießen

Gehen Sie das Gitter von links nach rechts und von oben nach unten durch und schreiben Sie in jedes leere Feld den nächsten Buchstaben des Lösungsworts. Da es genau N Löcher gibt, passt das Lösungswort ohne Rest.

Zu sehen ist am Ende nur das:

#Wenn ein Gitter misslingt

Erreicht der Generator innerhalb von 2.000 Versuchen nicht genau N leere Felder, werfen Sie das ganze Gitter weg und fangen neu an, höchstens 100-mal. Kein Flicken von Löchern. Das ist grob, aber für Gitter bis 12×12 reicht es mit Abstand. Größere Gitter brauchen mehr Versuche, wie die Tabelle unten zeigt.

#Erfolgsquote und Tempo je Gittergröße

Der Generator lief auf 300 Gittern pro Größe, mit echten Witzen und dem slowakischen Wörterbuch (Node.js 22 auf einer Server-CPU, ein Handy ist langsamer; die Bilder nutzen das englische Wörterbuch, die Zahlen das slowakische, weil es kleiner und damit der strengere Test ist). „Erster Versuch“ heißt, dass die erste Füllrunde mit einem vollen Gitter endete.

Was das für einen eigenen Generator bedeutet:

• Das durchschnittliche Wort hat 4,7 Buchstaben, obwohl das Ziel bei etwa 6 liegt. Lange Wörter passen in ein dichtes Gitter einfach öfter nicht.
• Etwa 9 bis 10 % der Felder teilen sich zwei Wörter. Das müssen Sie nicht einstellen, es folgt aus der Regel „höchstens ein gemeinsamer Buchstabe“.
• Es gibt weniger Diagonalen, als Sie erwarten. Die Richtung wird gleichverteilt aus acht gezogen, Diagonalen müssten also die Hälfte der Wörter sein. In einem kleinen Gitter fällt ein diagonales Wort aber viel öfter über den Rand. Bei 8×8 sind 24 % der Wörter diagonal, bei 15×15 schon 33 %. Wenn Sie mehr Diagonalen wollen, geben Sie ihnen beim Ziehen der Richtung mehr Gewicht.

#Tipp: dasselbe Gitter bei jedem Lauf

Für Store-Screenshots brauchen Sie jedes Mal genau dasselbe Gitter. Ersetzen Sie in diesem Modus den üblichen Zufallsgenerator durch einen einfachen linearen Kongruenzgenerator mit festem Seed (zum Beispiel aus der Sprache abgeleitet). Bleibt die gesamte Arithmetik in dem Bereich, den Zahlen in JavaScript exakt darstellen, ist das Ergebnis auf jedem Gerät gleich. Mit demselben Trick sind auch die Bilder in diesem Artikel entstanden.

Wenn Sie ein ähnliches Problem lösen, Rätsel generieren oder eine mobile App brauchen, schreiben Sie uns. Kurze Clips aus der Entwicklung gibt es auch auf YouTube. Ebenso Schritt für Schritt ist beschrieben, wie man ein Sudoku mit eindeutiger Lösung generiert. Für Kreuzworträtsel statt Wortsuche lesen Sie, wie man ein Schwedenrätsel mit Lösungswort generiert.