Build LOD for thousands of animated characters in Unity around vertex count, not triangle count: with vertex animation textures, animation is computed per vertex. Prepare the lower levels by hand, attach the vertices of the lowest level to the surface of the original, and pick the level for each character separately. In our PC tower defense game with 3,000 enemies, this raised FPS when zoomed into the crowd from 62 to 120.

This applies to games where thousands of characters move on screen at once: tower defense, strategy and survival games. Ours is built in Unity with ECS and listed in our portfolio. LOD stands for level of detail: a distant character is drawn from a simpler mesh. The images show the actual meshes of our skeleton enemy, not in-game shots.

#Why generated LOD does not help a crowd

Unity can generate LOD levels when it imports a model (the Mesh LOD feature). For thousands of characters that has two problems.

The first is appearance. Automatic simplification tore thin limbs and broke the UVs, the mapping of the texture onto the mesh.

The second is the cost of animation. Standard skeletal animation is too expensive for thousands of entities, so vertex animation textures (VAT) are used instead. A VAT is a texture where each column belongs to one vertex and each row to one animation frame. The shader reads the vertex position from the texture, so the cost of animation depends on how many vertices are read, including when shadows are drawn.

A test with one forced generated level on every character shows the ceiling (Unity also generates levels 3 and 4; build, 1080p, 3,000 enemies, shadows on):

There is plenty of room for speedup. The goal is to get it without visible holes or jumps between levels.

#Count vertices, not triangles

Halving the triangles does not help on its own. A LOD with half the triangles and 996 of the original 1,521 vertices saved 1.9 ms per frame, a LOD with 217 vertices saved 6.4 ms. Track both counts for every level.

Meshes often carry far too many vertices. A vertex is duplicated at every UV seam, because one position then needs two texture coordinates. Our models from an AI generator had UVs chopped into hundreds of islands: the skeleton had 1,521 vertices but only 608 distinct combinations of position and normal.

#Step 1: Reduce vertices in LOD 0

The first saving costs no detail. Merge vertices with the same position and a similar normal (within 25°), unwrap the UVs again with seams only on sharp edges (over 70°), and rebake the texture from the old one triangle by triangle. The skeleton dropped from 1,521 to 1,090 vertices; other enemy types lost 19 to 29% with the same shape.

Then write only the columns of vertices that some level actually uses into the VAT. That saved 40 to 60% of animation memory.

#Step 2: LOD 1 from simplification with a shared texture

LOD 1 is LOD 0 simplified to roughly 52% of the triangles. Simplify piece by piece (each combination of bone and connected part of the mesh) and lock the vertices on the piece boundaries. Give the head a larger budget, since its silhouette is what the eye picks out in a crowd.

Keep the LOD 0 texture. A level with its own texture or a different shape is visible at the transition even with a similar silhouette.

Below about 50% of the triangles, simplifying from existing vertices tears thin parts and separate pieces. Going lower needs a different approach.

#Step 3: LOD 2 as a new mesh attached to the original

The lowest level is a new closed mesh. Thicken the original with a shell layer, run a voxel remesh and simplify to a target count (for us 200 to 460 triangles depending on the enemy type). Shrink-wrap the result onto the surface of the original and generate UVs automatically. Bake the texture from the original at the same density as LOD 0 so the mipmaps match too.

The new mesh has no animation weights. Attach each of its vertices to the nearest triangle of the original and store the three columns of that triangle and the barycentric weights (the ratios that define a point's position inside a triangle).

The VAT column of an attached vertex is the weighted sum of the positions and normals of those three vertices in every frame. The shader does nothing special, an attached vertex is just another column.

for every frame f:
    VAT[attached, f] = w0 * VAT[a, f] + w1 * VAT[b, f] + w2 * VAT[c, f]

#Step 4: Check for holes automatically

Images from a modeling tool do not reliably reveal holes. A simple check is enough: render the original and the candidate from 11 directions at 120 px and compare the silhouettes.

Count as a hole the pixels of the original inside the candidate's outline that the candidate does not cover, plus candidate pixels more than 2 px outside the original's outline. Our limits are 1% holes and 4 to 6% loss. The check must respect back-face culling per material. We set the limits based on where the transitions were visible in the game.

#Step 5: Pick the level per character

Switching the whole map to a level at once is visible. Picking per entity spreads the transitions out and they disappear in the crowd.

Whole map at once

Per entity

A version warning: the Unity 6.2 documentation states that Entities Graphics always uses LOD 0. We use per-entity selection by the formula below in Unity 6.6, so verify the behavior of your version first:

LOD = log2(d * C / D) * slope + offset
C = threshold * 2 * tan(fov / 2) / screen_height

Here d is the distance from the camera and D is the diameter of the entity's world bounds. Choose slope and offset so that level 1 starts at 93.3 and level 2 at 167.9 meters (camera with 30° fov and 1,440 px). Set the global LOD threshold to screen height / 1440 so the distances do not depend on the resolution.

Two mistakes to avoid:

• Scale. Compute the diameter D from world bounds, including the prefab scale. Meshes for VAT tend to be in small units and the prefab enlarges them 2 to 4 times. Without this, the game draws LOD 0 all the time and reports nothing. Verify it by comparing triangle counts in normal mode against a forced LOD. Rotating an entity enlarges its axis-aligned bounds, so we multiply the diameter by a factor of 1.22.
• Baking. The selection curve is baked with the SubScene and baking does not pick up a change in the mesh. Force a SubScene rebake after editing it.

#Results and limits

macOS build, 2560 × 1440, 3,000 enemies, shadows on, game stopped after game over (VAT animations keep running, so the measurement holds for graphics):

On the Steam Deck (1280 × 800, 8 RDNA 2 compute units) it is 75 to 80 FPS on the whole map. The closest view into the crowd runs at 33 FPS with shadows on high and 64 with shadows off. Shadows are the largest remaining cost: LOD lowers them too, but turning them off still gives a large FPS gain.

What LOD does not solve: the hole check runs in T-pose, so it does not catch stretching in extreme poses. One enemy type still exceeds the hole limit in LOD 2. LOD does not change the cost of moving the horde either; that is covered by the article on horde navigation in Unity DOTS, and reactions to explosions by the article on fake ragdoll.

Need help with game performance in Unity or crowd simulation? Get in touch.

An old 2D Unity game on the built-in render pipeline looks flat on a current phone: there is no lighting, glow is either missing or lights up the whole frame including the UI, and the interface sprites are blurry. In Unity URP you fix this with three things: Bloom with a threshold of 1 plus HDR colour only on objects that should glow, 2D lights from the 2D renderer, and a UI with larger sprites that respects the screen's safe area.

We show the process on our game Dreamica (App Store, Google Play). It is a falling adventure where you draw lines with your finger to guide a bubble with a sleeping child through four worlds. It was originally built in Unity 5.3, with the UI in the NGUI plugin, glow from the MK Glow plugin and art made for the iPhone 7 and its 1334 × 750 display. The gameplay stayed the same; only the graphics changed.

You often reopen an old game because of the store, not the graphics. Since August 2019 Google Play requires 64-bit versions, and a game with only a 32-bit build drops off it. That is exactly what happened to Dreamica. Once you are moving the project to Unity 6 anyway, the graphics are a relatively cheap bonus.

#Why the old full-screen glow is not enough

Older glow plugins work as a full-screen effect. They light up everything bright, including the icon buttons in the menu. In Dreamica, MK Glow in Unity 6 made the icons nearly vanish. Unity's official Post Processing Stack v2 only replaces it for the built-in pipeline and no longer applies in URP. If you want glow you control per material, plus dynamic 2D lights, move to URP and use the Bloom built into it.

#Step 1: Switch the project to URP

After switching to URP, an old 2D game will almost certainly hit two traps. Both show up as a picture that looks wrong, or exactly the same as before, even though the shaders are fine.

#A grey screen: set up a camera stack

If the Game view in the Editor shows nothing but a grey area while the Scene view and a one-off camera render look fine, the problem is not in the shaders but in how the cameras are combined. Old games often have two cameras, one for the world and one for the UI, and the UI camera only clears depth. That is how cameras are layered in the built-in pipeline, and URP does not support it. It needs an explicit camera stack: one camera is the Base, the others are Overlays added to its stack. Set it up in every scene where cameras are layered.

#Sprites ignore lights: switch to the 2D renderer

Sprites with a lit shader ignore every light if the regular URP renderer is active. It does not compute 2D lights at all. Switch to the 2D renderer. Even that one draws no lighting until the scene has at least one 2D light. When something looks exactly the same after a change, first check which renderer is running.

#Particles and old plugins

Particles on old shaders render black, or not at all, under the 2D renderer. Give them a new, simple shader.

Watch the Asset Store too. During an asset refresh the Editor can apply an "update" to an old plugin on its own, adding metadata and renaming shaders. Materials find their shader by name, so they break silently. After every larger asset refresh in an old project, review all changed files in version control, including the ones you are not working on.

#Step 2: Selective glow with HDR colour and Bloom at threshold 1

The goal is for selected objects to glow (in Dreamica the drawn line, lasers, sparks, fireflies and runes) but not the backgrounds or the UI. Bloom in URP blurs and adds everything brighter than its threshold. Set the threshold to 1 and push the colour of the materials that should glow above 1.

line shader:
    colour = texture × vertex colour × tint × intensity    (intensity = 6)

Bloom:
    threshold = 1, intensity = 0.3
    only what ends up brighter than 1 glows

Backgrounds and buttons have colours between 0 and 1, so they do not pass the threshold and stay sharp. That also gets rid of the washed-out icons. The camera must have HDR enabled. Without it the colour is clamped to 1 and nothing glows. The 2D renderer does not show the HDR toggle in the camera inspector, so enable it from a script.

Low threshold, whole frame

Threshold 1, HDR material

Once glow is under control like this, it does not have to be optional. In Dreamica we removed the glow toggle from the settings; glow is part of the look.

#Emission map: only part of the sprite glows

If only part of a sprite should glow, give it an emission map: a second, black and white texture that marks which part of the sprite glows. Only that part gets a colour above 1, so on a rune the core shines, not the whole outline.

#Pulsing in exposure stops

If the glow should pulse, do not multiply the colour linearly. An HDR material can have a brightness around 2 to the power of 8, and a linear multiplier from 0 to 10 makes no visible difference on it. Compute the pulse in exposure stops (EV), the same way as the intensity slider in Unity's HDR colour picker:

colour = tint × 2 ^ ev,   ev oscillates between a minimum and a maximum

#Step 3: A dynamic 2D light around the player

Put a 2D point light on the player with a soft flare around it. In Dreamica a single sine wave drives the flare brightness, the light radius and the light intensity together, so they pulse as one. The environment can set the light colour: white in the forest, orange in the swamp, purple in winter, yellow in hell. Switch backgrounds and obstacles to lit shaders, otherwise they ignore the light.

Short lights bring events to life. When the squirrel's cannon fires, an amber light with intensity 3 flashes and fades out over 0.3 seconds, and the muzzle sparks glow. Not everything has to glow: the dust when the acorn disappears is brown on purpose and does not glow.

#The same shader on adjoining surfaces

If two backgrounds join up, the source images have the same brightness and there is still a visible seam, check the shaders. In Dreamica the opening background and the endless forest background each used a different shader. One ignored the material tint of 0.733, the other applied it and darkened the forest to 73%. The fix is the same shader on both surfaces.

Two shaders

One shader

#Surge: blend to a peak instead of adding

On the way into the next world the light and flare surge: 0.6 seconds up, a short hold, 1.4 seconds down, and the flare turns once. If you simply add the surge on top of the pulse, the peak depends on where the sine wave happens to be, and every surge has a different strength. Blend smoothly from the pulse to a fixed peak instead:

weight = surge curve (0 to 1)
value = pulse + (peak - pulse) × weight

Added on top

Blend to peak

#Step 4: A sharp UI for current screens

A UI drawn for the iPhone 7 has small sprites. Dreamica's menu button sprite was 128 × 64 pixels, and on a phone with three times the pixel density it was stretched several times over. Redraw the sprites at a higher resolution: the new button is 800 × 434, and the progress bars grew from 200 × 26 to 800 × 104.

128 × 64

800 × 434

If the UI is built on NGUI, consider a rewrite. NGUI anchors resolve piece by piece across several frames, long anchor chains sometimes settle in the wrong place, and the scale differs between the Editor, a phone and an iPad. In Dreamica fixes did not make it reliable, so we rewrote the UI in uGUI and TextMeshPro. Go screen by screen and keep the old version running next to it as a reference. Scale the UI by height against a reference resolution (434 × 941 points in our case) and respect the screen's safe area, meaning the notch and rounded corners. When the rewrite is done, remove NGUI from the project entirely so you do not end up with two UI systems.

#Limits: uncompressed textures

This process only changes the graphics. In Dreamica we did not compress textures, on purpose, because we wanted full sharpness. The price is size: even the original game had 313 MB of textures in memory in the Editor, and it is 299 MB on the App Store. By our estimate compression would shrink the textures to roughly 40 MB. If game size matters to you, that is the first place to save.

For another Unity game from the first line of code to release, see the post on Space Impact Watch; performance in Unity is covered in the post on horde navigation in Unity DOTS. If the game is still on Unity 4, don't open it directly in Unity 6; the safe route is described in how to upgrade a Unity 4 project to Unity 6. If you have an old Unity game that dropped off the stores and you want it back, get in touch.

When an explosion throws hundreds of enemies at once, a real ragdoll for each of them is too expensive. You build a fake ragdoll in Unity DOTS by simulating the whole enemy body as a single point with its own simple physics and only rotating the model around the body's center. Falling and getting up are ordinary animation clips. No bones are simulated at all.

We show the approach on a PC tower defense game we are building in Unity with ECS (more in our references). In that game, a bomb or a fireball knocks back dozens to hundreds of enemies at once. With 2,000 bodies in the air, the simulation costs 0.53 to 0.59 ms per tick (a tick is one fixed-length step of the game simulation).

#Why not a real ragdoll

A real ragdoll means ten or more physics bodies connected by joints per character. With thousands of characters on screen, that is not realistic.

The second reason is determinism: the same state has to produce the same result. Our game relies on it to replay a lost wave from a checkpoint, and we check it with a hash of the simulation state after 1,800 ticks.

#The body as a single point

Instead of a physics engine, use your own simple 2.5D physics: a position on the grid, height above the ground, ballistic flight, bouncing off walls and friction. In our game the bomb moves this way too, and an enemy hit by an explosion briefly becomes the same kind of body. The inspiration was the way soldiers fly in Diplomacy is Not an Option.

The simulation only knows position, height and rotation angle. Don't write the model's rotation into it. It belongs in the entity's additional transform matrix, which the Entities package (ECS in Unity) supports for non-uniform scale (documentation).

#Phases of a knocked-down enemy

A knocked-down enemy goes through three phases and then returns to the crowd:

on hit:
    compute launch velocity (force, distance from the explosion, randomness from the seed)
    find a landing on a walkable cell (see below)
    enable the "knocked" state, release the spot it held at the attack target
flight:     the body flies along a parabola, the model rotates around the body center
landing:    pose from the rotation (back or belly), short settle
lying:      waits a fixed number of ticks
getting up: get-up clip from the back or from the belly, then back to the crowd

Make the "knocked" state a component that can be switched on and off without moving the entity between chunks (the memory blocks in which ECS keeps entities with the same set of components). Navigation, crowd separation and attack decisions then simply skip knocked-down enemies. How navigation and separation work for a large crowd is covered in the article on horde navigation in Unity DOTS.

#Launch: higher, not farther

The simplest launch uses an angle of 45° ± 10°. With a bomb force of 18 m/s and gravity of 20 m/s², the apex comes out at around 4 m. The body flies low over the crowd and the effect gets lost in it.

More force doesn't help, because the range grows with it. Split the velocity into two components and scale each one separately: an angle of 60° ± 5°, horizontal component × 0.85, vertical × 1.3. The apex is then around 10 m, the range stays at around 15.5 m and the flight takes roughly 2 seconds.

The direction deviates from the explosion by ± 15°, the force by ± 20%, and at the edge of the explosion the force drops to half. Don't take randomness from a global generator. Derive it from a hash of the level seed, the enemy's identifier and the explosion's sequence number. Process knockdown requests in sorted order, because jobs running on several threads produce them in arbitrary order. Two runs of the same wave then give the same arcs.

Knockdown is yes or no. Every knockable enemy at least falls when hit (the speed has a lower bound of 2 m/s), and resistance only changes the range. Give immunity its own flag; in our game the largest enemy type has it. If immunity came from resistance (at 0.95 the speed falls below 2 m/s) and weak knockdowns were cancelled, the enemy would only be immune by accident.

#Landing on a walkable cell

An enemy must not land in a ravine, on a cliff or inside a tower's footprint. Walkability is defined per grid cell and separately for each enemy size class.

#Bouncing off walls in the air is not enough

The obvious idea is to treat non-walkable cells as walls the flying body bounces off. Next to a cliff that looks natural, next to a ravine it doesn't: above a ravine there is only air, but the cell is non-walkable, so the body bounces off an invisible column above its edge. On top of that, nothing guarantees that it ends up in a good spot after the bounce.

#Trajectory prediction at launch

It is more reliable to find the landing right at launch. Simulate the flight ahead with the same step as the real physics and check the landing cell for the enemy's size class. If it isn't walkable, try other variants in a fixed order:

for angle in [0, +25, -25, +50, -50, ... , +175, -175]:
    for horizontal speed multiplier in [1, 0.7, 0.4, 0.1]:
        simulate the flight
        if the landing cell is walkable for the enemy's class: use this direction and stop
if nothing worked: horizontal speed = 0 (hop in place)

The worst case is 60 flight simulations per enemy (15 directions × 4 multipliers). The vertical speed doesn't change, so the flight height stays the same and only the range gets shorter. If another explosion hits the enemy during the flight, run the prediction again.

To keep the body from sliding or bouncing after landing, give it a ground restitution of 0 and high friction. It stays where the prediction said it would.

#Rotation planned from the flight height

The simplest option is to spin the model at a random speed, for example 180 to 540 °/s, and settle it onto the nearest lying pose within 0.2 s after landing. The settle is visible, though, when the body lands almost upright. Adjusting the rotation speed every tick so that the angle comes out exactly horizontal at landing only helps partly: even a low throw spins like a somersault, and the rotation has nothing to do with how high the body flies.

It works better to plan the rotation at launch from the flight height:

height = vz² / (2 g), flight time from vz and height
target = nearest horizontal pose in a random direction (quarter turn from standing)
target += half turn for every 2.5 m of height, at most 3
rotation speed = (target - current angle) / flight time

The landing side follows from the angle: face to the ground means belly, otherwise back. It selects the get-up clip. An enemy that is lying or getting up keeps its current angle when hit again and doesn't snap back to upright.

#Putting the model on the ground

The model rotates around the body's center, but the ground is under its lowest point, and that point changes with the rotation. Estimating the offset from two constants and the sine of the angle doesn't work for models with arms spread wide in the fall clip: in our game the skeleton model (a common enemy) sank up to 1.15 m into the ground and the necromancer model up to 1.73 m.

Estimate

Measured

It is more reliable to measure the lowest point. When baking the animations, compute the body's lowest point for the fall clip at 72 rotations in 5° steps, and interpolate from the table at runtime. The deepest sinking then drops to 4 mm. A single minimum across all frames of the clip is not enough, though: the body would hover 0.15 to 0.28 m above the ground after landing until the get-up clip pulls it down. So the table has to be frames × rotations.

The slow planned rotation reveals one more effect. If you place the model with its lowest point at the flight height, the body's center drops by the difference between half the character's height and half its thickness as it goes from standing to horizontal. The body then rises only slowly at the start of the flight and speeds up afterwards. Lift the model by the difference between its half extent when standing and at the current angle, at most by the flight height. The body's center then follows the parabola.

#Dead enemies: body, decal and dust

An enemy killed by an explosion should fly too. Create a flying body for it: a copy of the entity without gameplay components (health, reward, target). The body flies, lands, lies for a while and disappears. A corpse decal (a texture projected onto the ground) as in Warcraft 3 and a puff of dust stay in its place. In our game the limits are 1,000 flying bodies and 1,500 decals.

The decal is a top-down view of a frame from the fall clip, rotated the same way as the lying body, so the swap from body to decal isn't visible. The first frame of the get-up clip doesn't work, because the character is already sitting up from its back. Merge dust puffs within a 1.5 m cell. A bomb into a crowd then creates a few larger clouds instead of hundreds of small ones.

#Traps in Unity Entities

• The matrix from the baker disappears. If you add the additional matrix at bake time, the transform system removes it at uniform scale and knocked enemies don't move. Request non-uniform scale when baking. The prefab's whole scale then moves into that same matrix, so don't overwrite it with the rotation alone. Otherwise a knocked enemy scaled 2× ends up half its size, even after getting up. Store the scale separately and build the matrix from scale and rotation.
• Root height when importing clips. With humanoid clips, the root's vertical motion is thrown away and characters fall through the floor when getting up. Bake the root height into the pose. Don't use the option to anchor the pose to the feet: it moves the whole body a meter down.
• Matrix in closed form. Translation, rotation and reverse translation as three matrix multiplications are measurably slower in a job than a hand-written formula for the resulting matrix.
• Burst running an old version. After you change the fields of a component read by a Burst job, the editor may crash or report nonsense. Restarting the editor fixes it.

#Performance

Measured in the Unity Editor on an M3 Pro, 10,000 skeletons in a benchmark scene, launch force 18. The times are the sum of the Burst jobs' CPU time across all threads, not frame time. The chart and the table are without trajectory prediction and landing tables.

• The simulation grows linearly, roughly 0.25 ms per thousand knocked. With trajectory prediction and landing tables it is 0.58 to 0.59 ms at 2,000 knocked, slightly above the 0.5 ms target. A sensible cap is therefore 3,000 enemies knocked at once, which is about 0.8 ms.
• An explosion into a group of 359 enemies next to a wall costs 1.3 to 1.9 ms in the knockdown request system in a single frame. Most of that is the trajectory prediction.
• Editor FPS can't be compared: two runs of the same configuration differed by up to 80 FPS.

#Limits of the solution

Visual preparation went up to 1.3 ms in another test scene, probably because of reading the landing table for every body. It is the first candidate for optimization. FPS in a build and the load of killing 1,000 enemies at once (target: at most 1.5 ms extra per frame) are not measured yet.

If you are working on a similar crowd or effects simulation in Unity and need help, get in touch.

A shmup (shoot 'em up, a shooter where your ship flies against waves of enemies) on Apple Watch runs into three problems: a tiny display, a finger that covers half the game, and watches that come in different sizes. Three decisions solve them: the whole game runs on a fixed 84 × 48 grid, collisions are checked by hand with rectangles, and levels are tables of timestamps rather than code. The ship is steered with the Digital Crown and fires on its own.

The examples come from Space Impact Watch, a remake of Space Impact, the shooter that shipped on the Nokia 3310 in 2000. It runs on the watch as well as on iPhone and iPad. The code is built on SpriteKit, Apple's 2D game framework, but the principles apply to any shmup for a small screen.

#A fixed 84 × 48 virtual resolution

First decide which units the game works in. If you use screen points, the world has a different size on every watch. It is better to pick a small virtual resolution and do everything in it. Our game uses 84 × 48, exactly the size of the Nokia 3310 display. Positions, speeds, sprite sizes and enemy paths are all in these units. When the scene starts, it calculates once how many screen points one virtual pixel spans (scene width divided by 84), and everything is simply multiplied by that.

What you get:

• The same look on every device. The game looks identical on every watch size and on the iPad; only the block size changes.
• Level design in small whole numbers. An enemy flies at height 13, a rocket turns at x = 20.
• Simple graphics. Sprites are single-colour and drawn at ten times their size, so one virtual pixel is a 10 × 10 block in the source image. They get their colour in the game: black on a green background in light levels, the other way round in dark ones.

#Crown controls and automatic fire

On a watch, a finger covers half the game, so the ship is not steered by touch. The Digital Crown handles movement: turning it moves the ship up or down. Add a sensitivity setting and an option to invert the direction.

Firing is automatic; in our game every 0.4 seconds, and every 0.3 from level four on. The display is used for a single gesture: a swipe to the right fires one of three special weapons.

On a watch, a vibration on hit matters as much as the animation; a small explosion on the display is easy to miss. Trigger haptics through a single interface (hit, enemy killed, boss defeated) that each platform implements separately: the watch answers with a vibration, the iPhone in its own way. The phone version has no crown; it has on-screen buttons instead, using the same sensitivity and direction settings.

#A game loop in a single scene

The whole game can be one scene with one loop:

every frame:
    move all objects
    check collisions
    spawn new enemies based on the time in the level

Add features in the order that lets you test as early as possible:

• Shooting and player movement. Nothing can be tested without them.
• Enemies and collisions. The first enemy only needs to fly straight left and die after one hit.
• Vibration and hit animations. On a small display, the player cannot tell a hit landed without them.
• Background and HUD. Lives, score, number of special weapons. If the HUD gets in the way on some level, move it to the bottom.

At the end you have a playable loop with lives, score, explosions, a background and player respawn. If you keep the game logic separate from rendering and input, the watch and phone versions can share it.

#Rectangle collisions instead of a physics engine

SpriteKit has a physics engine, and it is tempting to use it for collisions too. Every object gets a physics body built from the outline of its sprite, precise collision detection and a category (player, enemy, bullet, special weapon), and the engine reports the pairs that touched on its own. Apple's documentation on physics bodies says that bodies built from a texture's alpha channel are the most accurate and also the most expensive to compute. We tried this in our game and went back to checking collisions by hand.

The manual check is one function that goes through pairs of groups and compares rectangles:

for every pair of groups:
    (player and enemies, player and bullets, bullets and enemies, bullets and bullets)
    for every object A in the first group and object B in the second:
        if rectangle A overlaps rectangle B:
            resolve the hit

The benefits: you control the order of the checks, and the whole "what happens on a hit" rule lives in one place. The inaccuracy is small, because on an 84 × 48 grid the sprites are so tiny that the rectangle and the real outline differ by only a few virtual pixels.

#Pooling only where it pays off

Pooling means that when an object dies you do not delete it, you hide it and reuse it next time. It is tempting to pool everything, explosions and power-ups included. That has a cost: every collision and every update first has to check whether the object is alive at all. One forgotten check and a hidden enemy kills the player, or a hidden bullet shoots down a rocket. When we removed pooling from everything in our game, most of the deleted code was these checks.

A simple rule: pool what there is a lot of and what is always created the same way. The player creates 21 bullets at the start and then only recycles them. Enemies and their bullets are reused too; explosions and power-ups are created and destroyed normally.

#Levels as timed tables

A level does not have to be code; a list of records is enough. Each record says what appears, at which second, at what height and how it moves. Movement is a list of points the enemy flies through at constant speed. Optionally there are shot times, a boss charge attack or a spawner of smaller enemies.

every frame:
    time = now - level start - time spent paused
    for every record in the level table:
        if the record is unused and time > record.time:
            create an object from the record
            mark the record as used

A level written this way is easy to tune: moving a wave by half a second means changing one number. The timeline also shows the rhythm you are after: a short wave, a pause, a different enemy type, a power-up before a harder stretch.

The downside shows with bigger changes. The densest level in our game has 71 rows, and a table like that is hard to read without an editor. It works better to write levels as waves (a group of enemies sharing one movement pattern) rather than as individual ships.

#Endless mode from one pseudo-random number

A leaderboard (Game Center in our case) needs a mode that never ends. There, a generator replaces the hand-written table and builds it while you play. It produces a 20-digit pseudo-random number, and individual pairs of digits decide one wave:

number = next pseudo-random 20-digit number
type = power-up if digits 4 to 5 > 90, otherwise enemy
sprite = digits 1 to 2 modulo number of enemy kinds
pause before the wave = digit 3 / 2 seconds (at least 1)
height = digit 7, scaled to the playfield height
movement pattern = digits 10 to 11 modulo 10
ships in the wave = digit 17 / 2 + 1
speed = digit 13 × (1 + wave number / 10), clamped to 20 to 50
every thirtieth wave = boss, generation stops while the boss is alive

Keep the generator's seed (starting value) fixed in the game. Every player then gets the same sequence of waves, and leaderboard scores are comparable.

A simulation of the generator outside the game (300 waves, the same seed as in the game) shows how the mode develops. The first boss comes after 29 waves, that is after 74 enemies and 3 power-ups, at roughly 130 seconds. The first 30 waves fly at the minimum speed of 20, because a single digit is still below the lower limit. Average speed then rises to 28.5, 37.5 and 41; from wave 120 on, most enemies are at the maximum. Roughly every eleventh wave is a power-up.

The weakness is that the generator knows nothing about rhythm. A hand-written level alternates pressure and rest; the generator does not. The pause during bosses and the rising speed help a bit, but the hand-written levels play better.

#Limits of this approach

• No automated tests. Everything is checked by hand in the simulator and on the watch.
• Global state. Most of the game state is global variables of a single scene. That is convenient for a watch-only game and inconvenient once you add an iPhone version.
• No level editor. A timed table is easy to tune in small steps, but bigger changes would call for an editor.

If you are making a game for a watch or another small screen and want help with something, get in touch. How we generate puzzles in another of our apps is covered in the post about our sudoku generator.

You generate a sudoku with a unique solution in two steps. First fill an empty 9×9 grid completely, by backtracking with digits tried in random order. Then remove cells one at a time in random order, and after each removal use a solver to check that the puzzle still has exactly one solution. If it doesn't, put the digit back. On an ordinary CPU this takes less than a millisecond at the median.

The approach fits any game or app that needs an unlimited supply of fresh puzzles without preparing them by hand. One example from practice is the sudoku in our crosswords and puzzles app (App Store, Google Play).

#Why exactly one solution

Everyone knows the rules: every row, column and 3×3 box contains each digit from 1 to 9 exactly once. Less often mentioned is that a good puzzle has a single solution. Only then can it be solved by pure logic, without guessing.

It has a practical side too. A game usually stores one solution and uses it to check the result and give hints. If a puzzle has two solutions, the player can reach the other one, which is just as correct, and the game won't accept it.

#Step 1: Write a fast solver

A solver is a program that solves the sudoku. It works by backtracking: it fills a cell with one of the possible digits, moves on to the next cell, and when it hits a contradiction, it goes back and tries another digit. You need it twice: to fill the empty grid and to check uniqueness. The check runs after every removed cell, so 40 to 70 times per puzzle, which means it has to be fast. Two things matter:

• Bit masks. Keep a 9-bit number of used digits for every row, column and box. A cell's candidates, the digits that can still go into it, then take a single operation: all digits except those already in its row, column or box. The number of candidates is the number of set bits and can be precomputed into a table of 512 values.
• Cell with the fewest candidates first. Don't take the first empty cell from the left, take the one with the fewest options (known in the literature as the MRV heuristic, minimum remaining values). Fill a cell with a single candidate right away. A cell with no candidate means a dead branch and you backtrack.

On hard puzzles, the uniqueness check with this rule needs 311 steps at the median. If the solver takes cells left to right instead, it needs 28,579 at the median and more than 300,000 in the worst 5% of cases. That is roughly a 90-fold difference.

#Step 2: Fill the whole grid

You get a full grid from the same solver run on an empty grid. The only difference is that you try a cell's candidates in random order. The first solution found is a random, valid, completely filled grid.

#Why removing random cells is not enough

The simplest idea is to remove N random cells from the full grid, for example 40, 50 or 55 depending on difficulty. The puzzle looks fine, but it often has more than one solution.

The picture shows the typical case. Four cells in the corners of a rectangle spanning two boxes can be filled in two ways, and nothing in the rest of the grid decides between them. Sudoku solvers know this as a deadly pattern. On 1,000 puzzles per difficulty the result looks like this:

A hard puzzle from random removal has hundreds of solutions on average. A uniqueness check after every removal is therefore necessary.

#Step 3: Remove cells while checking uniqueness

Go through all 81 cells in random order. Try to empty each one and count the solutions with the solver, but stop counting at two. That is all you need to know: one solution means the cell can stay empty, two mean it has to go back.

puzzle = copy of the full grid
empty = 0
for each cell in random order:
    if empty == target: stop
    digit = puzzle[cell]
    puzzle[cell] = blank
    if count_solutions(puzzle, at most 2) == 1:
        empty = empty + 1
    else:
        puzzle[cell] = digit

Once you put a cell back, don't try it again. Further removals only loosen the puzzle, so a cell that couldn't be emptied now won't be removable later either.

#Step 4: Set difficulty by the number of empty cells

The simplest measure of difficulty is the number of removed cells. The three levels we use in our game:

The fewer digits are left, the more often another removal would break uniqueness and the cell has to go back. On the hard level a single pass sometimes stops before reaching 55 empty cells. In that case generate a new full grid and try again. Measured on 1,000 hard puzzles, the first pass was enough in 97.6% of cases, and it never took more than 3 attempts.

#Generator speed and reliability

We ran the generator on 1,000 puzzles per difficulty (Node.js 22 on a server CPU, a phone will be slower):

We also checked every generated puzzle independently with the solver. All 3,000 had a single solution.

#Where the number of empty cells falls short

The clue count is a rough measure of difficulty. Two puzzles with 26 digits can differ in difficulty depending on which logical techniques they require. A more precise rating would solve the puzzle the way a person does and record the hardest technique it had to use. For a mobile game where the player picks one of three levels, the clue count is enough.

If you are solving a similar problem, generating puzzles or need a mobile app, get in touch. How to generate a word search with a hidden message is covered in a separate tutorial. Arrowwords with a hidden message have their own tutorial too.

You can generate a Swedish-style crossword (arrowword) with a hidden message in two phases. First use a local search to find the mask, that is, the layout of clue cells and letter cells, and then fill it with dictionary words as a constraint satisfaction problem (CSP) solved with backtracking. Do not place the hidden message in advance. Only once the crossword is finished, look for a joke whose punchline can be read in it from left to right and top to bottom.

This is how the arrowwords in our crosswords and word search app (App Store, Google Play) are made. One grid takes from a few seconds to tens of seconds of CPU time, so we generate them in advance on a more powerful computer and bundle them with the app. Word searches are generated in a completely different and simpler way, described in How to generate a word search with a hidden message.

#What an arrowword has to satisfy

An arrowword has no black squares. Every cell is either a letter or a clue with an arrow pointing right or down. That gives a set of hard constraints:

• Every letter belongs to both an across and a down word. A letter crossed by only one word cannot be checked and looks like a mistake.
• Every word has at least two letters and a clue in front of it. That is why the first row and the first column are always all clues.
• The letters form one connected area, with no detached islands.
• Every word must be in the dictionary and have at least one clue. No word appears twice in a grid.

On top of that come soft quality criteria: few two-letter words, no clues that point at nothing, and as few very long words as possible, because they are hard to fill. The problem is computationally hard. Engel et al. (2012) showed that filling a mask with words is NP-complete on its own.

#Why filling the grid word by word is not enough

The first idea is to do what a person with a pencil would do: split the hidden message into words, lay them out in a row like in a newspaper, run a crossing word through each of its letters and fill the rest of the grid with a greedy algorithm. A greedy algorithm picks whatever looks best at each step and never revisits the decision. Where nothing fits, a hole remains. And because greedy filling cannot go back, once the first ten words are bad, the rest of the grid cannot fix them.

A better word selection heuristic helps only a little. You can try crossing word lengths from medium, around five letters, towards the extremes. Or you can go evolutionary: a population of partial crosswords, five children per parent with one more word each, a score based on filled cells, vowel count and how evenly the letters are spread, and only the best move on to the next generation. The results get somewhat denser, but the holes stay, because the heuristic only sees the next step.

The way out comes from Jakob Engel's bachelor thesis at TU Munich (2009); he is also the first author of the paper above. Split the task into two independent phases: first find a good mask without caring about words, then fill it. Engel used an evolutionary algorithm for the mask. We use a simpler local search with random shakes, described in the next step.

#Step 1: the mask with hill climbing

The mask is a grid in which every cell is either a clue or a letter. Hill climbing is enough to find one: a local search that makes small changes and keeps those that do not make the result worse.

Start at random, with clues on about 22% of the inner cells. Give every mask a penalty score. Hard violations (a word that is too short, a letter without a crossing word, a detached island) should mostly cost 1,000 points; soft flaws (two-letter words over budget, a clue that points at no word, clusters of clues) 50 to 500.

Then, in a loop, flip one cell from clue to letter or back, or move a clue one cell diagonally. Keep the change if the penalty did not go up, otherwise revert it. Aim half of the changes at the cells with the highest penalty, and the gross errors disappear quickly:

Hill climbing gets stuck in local minima easily. When 2,000 steps bring no improvement, "shake" the grid: flip five random cells of the best mask found so far and keep searching. Those are the spikes in the chart. If even three shakes bring no better mask and it has no hard violations, stop.

The final mask has a residual penalty of 200 for soft flaws, but no hard violation:

It pays to have the penalties for a clue without a word and for a detached island in the mask from the start. On a large set of finished crosswords without them, 13.2% of clues pointed at no word and 23.5% of grids had a detached island of letters. With them, the figures are 5.0% and 0%.

#Step 2: filling with words as a CSP

The mask yields a list of slots, places for words with a known length and known crossings. Filling them is a classic constraint satisfaction problem (CSP): every slot is a variable, its domain is the set of words that fit, and the constraints are matching letters at the crossings. It is solved with backtracking, a search that steps back and tries another option whenever it hits a dead branch:

for every slot: domain = all words of that length
while not all slots are filled:
    pick the slot with the smallest domain (on a tie, the one with most crossings)
    for every word in its domain, best first:
        place the word
        narrow the domains of crossing slots to words with the matching letter
        if any domain became empty: undo, try the next word
        otherwise continue with the next slot
    if no word fits: go back one slot
give up after 50,000 steps

In the literature these heuristics are called MRV (minimum remaining values, the slot with the fewest options first) and forward checking (narrow the neighbours' domains after every placement, so a dead branch shows up immediately, not ten words later). Pre-index the dictionary by length, position and letter. "Words with Q in third place" is then a single set intersection, not a scan of the whole dictionary.

Word order matters too. Put words with more distinct clues in the dictionary first. It is a simple signal of a common crossword word. Without it, the grid fills up with obscure abbreviations.

#Step 3: the hidden message in the finished grid

While filling, you do not know the hidden message yet. Read the letters of the finished grid from left to right and top to bottom and look for a joke whose punchline is a subsequence of that string. The letters come in the right order, but they do not have to be adjacent. If one is found, spread its letters as evenly as possible across the grid, so the punchline cannot be guessed from a single word.

This order (grid first, joke second) increases the number of finished crosswords dramatically. In our measurement a single 12×12 grid fits on average 86 jokes from the Slovak list (5,960 jokes). So there is always one that has not been used in that size yet.

#Why not place the message in advance like newspapers do

In newspapers the hidden message is usually in one place, in a row, split into words. There are two ways to get that, and both give very few results.

The first is to place the message in the grid in advance. Then it has to fit. Our punchlines have 10.3 letters and 2 words on average. This is the share of jokes from the Slovak list that can be placed in a given size at all:

With the message placed in advance, filling small grids succeeds about as often as without it. For 15×15 it was 5 out of 60 attempts versus 8 without it, for 18×18 none out of 60. Each such grid also serves a single joke, and in small sizes most jokes cannot even be placed.

The second way is to let the grid form freely and look for the punchline in it as a contiguous run. In a sample of 2,200 finished Slovak crosswords (200 of each size from 8×8 to 18×18), the whole punchline appeared as a contiguous run in one row or column in only 81 grids (3.7%). When each word of the punchline may sit somewhere else, it is 443 grids (20%), still without requiring the words to be next to each other. Reading in order found a joke in every one of them. At the price of a hidden message scattered across the grid you get orders of magnitude more crosswords.

#Generator performance and why it does not run on the phone

The generator ran 60 attempts per size with the Slovak dictionary, single-threaded (JavaScript on Node 22, an Intel Xeon 2.8 GHz server CPU in the cloud). An attempt is one mask and one fill. "Successful fill" means the CSP found a solution within 50,000 steps.

What the numbers show:

• A small grid is not an easy one. An 8×8 grid has many short slots with many crossings and little freedom; filling succeeds in only 5% of attempts. One filled grid costs on average about 10 seconds of CPU time at 8×8, 4 seconds at 12×12 and 18 seconds at 18×18.
• Most attempts fail. So run attempts in parallel on all cores and take the first result that is good enough.
• It makes no sense on the phone. Players do not want to wait tens of seconds when they open a puzzle, and the app would have to ship the whole dictionary with clues. A generator inside the app also has to keep yielding to the UI, otherwise the app freezes.

#Generating at scale

The generator therefore belongs on a computer with a multi-core CPU. In our setup each core gets its own thread with the dictionary loaded once at startup. A grid is done when one of the threads returns a result with few enough unused cells. In continuous mode it keeps generating one crossword of every size in every language. That is how we got over 14,000 crosswords in four languages (Slovak, Czech, English, German) and eleven sizes from 8×8 to 18×18. Each joke is used at most once per size and language.

At this volume two things matter:

• Format. A full record takes about 28 kB per crossword and 390 MB for the whole corpus. Most of it can be derived (coordinates, cell types, clue numbers). A compact format with the grid stored as a single string takes about 2 kB, 15 MB for the corpus and about 7 MB in the app's install package.
• Measuring quality. Measure the share of clues without a word and of grids with islands after every generation, and let the check fail if the numbers get worse.

#What the approach does not cover

• Clues without words. The average crossword still has 2.7 clues that point at nothing. The top left corner is always one of them.
• Dictionaries without frequencies. The German dictionary from Wiktionary has a single clue for most words, so ranking by clue count barely discriminates and rare words end up in the grid. A frequency list would help; we do not have one yet.
• The hidden message is not in one place. People used to newspapers may look for it in a row. It is a compromise, not the ideal.

If you are working on a similar content generation problem or need a mobile app, get in touch.

To generate a 3D phone model in the browser, extrude a rounded rectangle to the device depth and then use boolean operations (CSG) to cut out the front panel, buttons, speakers and port. The whole device is then described by a handful of numbers in millimeters, and a new model means changing those numbers, not modeling in a 3D package.

This is useful wherever you need many similar devices or want users to adjust them: configurators, mockups, product previews. A real-world example is Ecranify, a tool for 3D mockups for App Store and Google Play screenshots that does not contain a single pre-made 3D model. Below is the process step by step, including a measurement that shows where the computation can be cut the most.

#What you will need

• Three.js for the scene, cameras, lights and above all geometry. In Three.js, geometry is a mesh, a set of triangles.
• The three-bvh-csg library for boolean operations on meshes. It speeds them up with a spatial index (BVH, bounding volume hierarchy), so it does not test every triangle against every other one.
• A description of the device as data, for example JSON with body dimensions, corner radius, bevel size and a list of features on each side. Give all positions in millimeters from the device center.

#Step 1: Extrude a rectangle into 3D

Draw a 2D rounded rectangle at actual size, for example 163.4 × 78 mm, and extrude it to a depth of 8.75 mm. You get a slab with sharp edges. No phone looks like that, so turn on a bevel, a rounded edge, during the extrusion as well. Three.js does both in one step.

Extrusion only

+ corners and bevel

One thing to watch: the bevel is added on the outside. If you need exact outer dimensions, shrink the 2D shape and the depth by the bevel size.

b = min(bevel, depth / 2)
shape = rounded rectangle(width - 2b, height - 2b, corner radius - b)
body = extrude(shape, depth - 2b, bevel b)

How smooth the curves are (tessellation) depends on the number of segments each curve is split into. More segments means a smoother shape and more triangles. This number later decides how fast the whole computation is, so we come back to it in step 7.

#Step 2: Carve a recess for the display

CSG (constructive solid geometry) builds solids from simpler ones with three operations: union, subtraction and intersection. Subtraction works like a drill bit: one solid removes material from another.

A phone display is not flush with the frame. It sits in a shallow recess. To make it, create a second copy of the body that is 1.4 mm smaller, keep only its front part, 0.7 mm thick (an intersection with a large box), and subtract that part from the body. Then place a dark display surface into the recess.

Cutter

After subtraction

Two practical details:

• The intersection box has to be really large. It only needs to clip depth, but in width and height it must exceed the whole device. Do not derive it from the depth: 20 times the depth, for example, is less than the height of a thin, tall phone, and an uncut frame is left at the top and bottom.
• Scale the cutter up by a few tenths of a percent. When two solids share exactly the same face, CSG cannot tell which side is inside. A scale of 1.002 prevents that and is invisible to the eye.

#Step 3: Prepare side features as drill bits

Every feature on the side follows the same recipe with a different drill bit. A button, for example, is made from three solids: a rounded rectangle slightly deeper than the button is subtracted from the frame, the edge of the opening gets a small chamfer, and a slightly smaller solid that protrudes a little from the frame goes into the opening.

Drill bits

Cut and button

Speakers are a row of small cylinders, the port is a rounded rectangle. Put something dark into every opening: a thin disc into the grille, a plate into the port. An empty hole in a thin shell looks like a bug, a hole with a dark insert looks like hardware.

for each feature in the side feature list:
    bit = feature shape (cylinder, rounded rectangle, ...)
    place the bit on the edge at its position in mm
    add the bit to the list of cuts
    if the feature has an insert: add the insert to the scene

Adding a button is then a data entry. Features add up quickly: an iPad Pro 13″ has 58 speaker holes, 4 buttons, 2 antennas and a port, more than 60 subtractions from a single body.

#Step 4: Do not drill front details

The camera cutout, the island at the top of the display and the home indicator are flat. Cutting geometry for them is wasted work. Apply them as decals instead, images projected onto a surface. Project them onto a hidden plane covering the whole front and position them in the same millimeters as everything else. The exception is the round home button of older iPhones. It has real depth you can see from the side, so it goes through CSG.

#Step 5: Move the work into a Web Worker

JavaScript in the browser runs on a single thread. The same thread computes, paints the page and responds to clicks. While CSG runs, the page freezes, and a spinner will not help, because it needs that same thread too.

So run the whole device build in a Web Worker, a separate background thread. The worker receives the device description, returns finished vertex arrays, and the page stays smooth. When a parameter changes, terminate the old worker and start a new one, so it does not keep computing an outdated state.

The worker result takes a moment, so add an instant preview. Show the feature being edited as a blue translucent "ghost", a simple box or cylinder with a few dozen triangles that can be built on the main thread right away. When the worker finishes, the ghost disappears.

#Step 6: Subtract all holes at once

The most direct approach is to subtract features one after another: hole 1 from the body, then hole 2 from the result, and so on. But every subtraction rebuilds the spatial index of the whole body, which is the most expensive part of the computation. With dozens of features the time grows very fast.

It is better to collect all drill bits for a given solid first, merge them into one mesh and subtract once.

cuts = []
for each feature: add its bit to cuts
merged = merge all cuts into one mesh
body = body minus merged
if merging fails: subtract cuts one by one

Measured on a simplified copy of the pipeline (Three.js 0.170, three-bvh-csg 0.0.17, Node 22, a cloud server with 2 Intel Xeon 2.1 GHz cores, median of 5 runs):

One condition: merging and subtracting once gives the same result as subtracting one by one only if the drill bits do not overlap. Features sit in different places, so it usually holds. But if a user drags two features on top of each other, a small artifact can appear where they overlap.

#Step 7: Keep the segment count as a parameter

Tessellation that is fine for display is often needlessly dense for CSG. With 64 segments per corner and 32 for the bevel, the body has 68,108 triangles. Half of that (32 and 16) is invisible on a 2 mm edge, but the body has only 17,676 triangles, and the third row of the table shows what that does to the time.

64 and 32 segments

32 and 16 segments

Give small features with a radius of up to 2 mm (speaker holes, screws) half the segments, gallery thumbnails even fewer. So do not hard-code quality as a constant. Make it a build parameter.

#Rendering on a server without a GPU

If you need to render the same scene on a server too, for example as an export backup, it runs in headless Chrome, which draws in software because there is no graphics card. Every inefficiency is multiplied there. In Ecranify, the heaviest tablet hit the 15-minute limit without the changes above. With merged cuts, smaller textures, lower tessellation and a cache of finished geometry keyed by a hash of the device description, a render takes about half a minute and a repeat one about 5 seconds. The details, with interactive demos, are in the article on ecranify.com.

If you are solving a similar 3D problem in the browser or need a custom app, get in touch.

Don't open a Unity 4 project directly in Unity 6, and above all don't save anything in it. Unity 6 only partly loads the old binary scenes and saving makes the loss permanent; the safe route goes through Unity 2019.4, which can both read the old format and write it back as text, and only then on to Unity 6.

This applies to projects with scenes and prefabs stored in the binary format and scripts written in UnityScript, the JavaScript-like language Unity used to support alongside C#. The example throughout is Onager, a catapult physics game written in Unity 4.1.2 and UnityScript. The project had 126 scripts, 75 scenes and 78 prefabs. After the conversion it runs on Unity 6000.5 with URP (Universal Render Pipeline) and is free on the App Store and Google Play.

#What happens when you open the project in Unity 6

The simplest approach is to open the project in Unity 6 and switch serialization to Force Text, which stores assets as readable YAML. That is not a straight file conversion. Unity loads every asset through its importer and writes it back as YAML, so everything passes through the Unity 6 loader. On every scene it reports a Transform that is not assigned to a GameObject and deletes the "dangling" component. Saving makes that permanent.

You can measure the loss with binary2text, a tool that ships with the editor and reads a serialized file without the importer. In Onager we compared its output with the resulting YAML and counted only components that disappeared from GameObjects that survived:

Not one of the 75 scenes came through without loss. Whole HUD cameras vanished and the main camera was replaced with a new default one. The important part is that the damage happens on load, not on save. Until the project is converted, Unity 6 must not save it: not a single scene, not a single prefab.

#Step 1: Record the original state

Before you touch anything, take a screenshot of every scene and save a binary2text dump of every original scene file. You will check cameras against those dumps in step 3 and rebuild the HUD from them in step 5. Keep the original binary files in your git history; don't delete them.

#Step 2: Convert to text through Unity 2019.4

Unity 2019.4 is the last editor that can both read and write the Unity 4.1 format. Do the conversion with the editor closed, in a separate copy of the repository:

• Project version. Set the original version (4.1.2 for Onager) in the project version file so the editor takes its old-project path. Unity overwrites it on open; it only has to hold for the first import.
• Empty packages. Empty the package dependency list. A single compile error means no menu item from editor scripts works, which looks as if the menu never appeared at all.
• Import from scratch. Delete the Library folder and let the project import.
• Force Text and a forced rewrite. After switching to Force Text, Unity 2019.4 does not rewrite existing files by itself. You have to trigger it with the asset reserialization function, for the assets only, not their meta files. Rewriting every meta file makes Unity 6 reimport in a loop afterwards.

There is one trap in git. If your git attributes mark scenes as text with LF line endings, git strips bytes that look like line endings out of binary scenes when you add them to the repository. In Onager that damaged eight scenes. Don't put a line ending attribute on Unity assets; Unity writes LF anyway.

#Step 3: Verify the result in the editor, not by reading YAML

Reading the converted files leads to confident wrong conclusions. Shortened prefab instance records look like a loss, and so does a camera that has only moved into a prefab. What counts is what Unity builds in memory. Open every converted scene and compare its cameras with the dump of the original from step 1.

In Onager all 75 scenes ended up with the same cameras in the same order. The only losses were things no current editor knows: 569 GUITexture, 179 GUIText and the legacy particle systems Unity removed in 2018.

#Step 4: UnityScript to C# with the same GUID

Unity phased UnityScript out starting with 2017.2, so a manual port to C# is the only way. Scenes reference scripts through the GUID, a unique identifier Unity stores in every asset's meta file, and store field values by field name. Keep both during the port and every reference reconnects by itself:

for every UnityScript script X:
  create a C# script with a class named exactly X
  copy the GUID from the old script's meta file into the new one's
  public fields: same name, same type, typos included
  rename nothing until the project runs

In Onager, after porting all 126 scripts this way, 12,935 components in 73 scenes reconnected and every value set in the Inspector stayed.

A text search of the project will not tell you which scripts are used. A binary prefab stores the GUID as bytes, not as text. In Onager twenty-one scripts looked unused and every one of them was live. Watch out for leftovers from earlier port attempts too: one wooden block prefab pointed at two scripts from such an attempt, and that prefab alone accounted for 1,140 missing components. If you need to change a GUID in a binary file, swap it right in the bytes, sixteen for sixteen, so the file does not shift.

#Step 5: Rebuild the HUD from the original binary scenes

GUITexture and GUIText do not exist in Unity 6, and the whole HUD built on them goes with them. You don't have to draw it again. binary2text reads the original binary scenes from your git history whether or not the classes still exist. Pull every HUD image and text out of them with its texture, colour, position and alignment, and have a script put them back on the same objects in the scenes. In Onager that was 577 images and 180 texts.

This also saves strings that exist nowhere else. In Onager that was 111 strings: every tutorial caption and the whole credits board. Writing the HUD from scratch would have meant making them up. When you carry colours over, keep in mind something the documentation does not say: the old GUITexture doubled the colour when drawing. All 577 images had a colour of exactly 0.5, so grey meant white.

#After the conversion: replace old workarounds

Old projects often worked around the limits of the Unity of their day, and those workarounds are worth rebuilding once the project is converted:

• Floor reflection. Onager had a shiny floor without a real reflection. Below the floor stood a second, mirrored world: a copy of every object whose position a script copied from the original every third frame, 50 to 70 clones in one level. One extra camera drawing the reflection at half resolution replaces all of that. Particles and debris then reflect too, which the cloned world could not do.
• Aiming. If the trajectory preview tries to predict where a force added in the first physics step will send the shot, the shot lands somewhere other than the marker. It is more reliable to compute the velocity once, draw the preview from exactly that and assign it to the shot directly.
• Performance. Measure on a weak phone. On a Motorola G52, Onager dropped from 20 to 6 fps just because of the wall shader, more than resolution, shadows and the reflection combined. That is why the walls use a simpler material on low and medium detail.

If you deal with physics for thousands of objects in current Unity, see also the fake ragdoll for thousands of enemies in Unity DOTS. How to add glow and 2D lights to an old 2D game in URP after the upgrade is covered in a separate tutorial.

#What this process does not solve

Components that current Unity does not know will not reconnect. GUITexture and GUIText have to be rebuilt as in step 5; legacy particle systems are lost. Class and field names stay exactly as they were in the original project, typos and whatever language someone once wrote them in included. Scenes bind to them by name, so renaming only makes sense through the editor, which rewrites the references itself.

If you have an old Unity project that needs to reach a current version, get in touch.

Steer a horde of thousands of enemies in Unity DOTS with one flow field for the whole map and a few cheap local rules: pushing off neighbours and walls, path cost that grows with crowd density, and a "waiting" state in jams. In the Unity Editor on a MacBook with an M3 Pro, that handles around 9,600 enemies at once at 90 FPS.

The problem shows up in tower defense, strategy and survival games where thousands of units head for a goal at the same time. Classic per-unit pathfinding is too expensive, and without local rules the crowd overlaps, hugs walls and gets stuck in chokepoints. Unity DOTS (Data-Oriented Technology Stack: Entities, ECS and the Job System) gives you the performance for thousands of entities, but it doesn't solve navigation for you. We use the approach below in our PC tower defense game (it's in our portfolio). The images come from a simplified 2D simulation running the same rules. They are not game footage.

#Step 1: A flow field instead of a path per unit

A flow field is a grid over the whole map in which every cell knows which direction leads to the goal. An enemy doesn't search for a path, it just reads the direction at the spot where it stands. The cost is the same for 10 or 10,000 enemies.

Split the map into 1 m cells (our test level is 128 × 128) and, once per goal, compute the distance from every cell to the goal. A static field can be computed in the editor when the level is prepared and stored in an asset.

The simplest version is Dijkstra over 8 neighbours with one of 8 directions per cell. It works, but enemies walk diagonals and stick to walls in single file.

8 directions

Smooth field

A smooth field gives a better result. Compute the distance by solving the eikonal equation (a wavefront equation whose solution is the shortest distance in continuous space, not just along grid edges) with the fast sweeping method, which passes over the grid repeatedly from all four corners. The direction is then not the direction of a cell but the distance gradient at the enemy's exact position. Add a surcharge to each cell's cost for being close to a wall, so the field itself keeps the crowd a little away from obstacles.

#Step 2: A separate field for each enemy size

A large enemy doesn't fit everywhere a small one does. Introduce size classes: each has its own walkability (a cell must be far enough from walls) and its own field per goal. Keep the classes as level data, not in code. We use three.

#Step 3: Pushing off neighbours

A flow field gives a direction but knows nothing about neighbours. The basis is a simplified boids model (the classic flocking rules): each enemy is repelled by neighbours within 0.9 m. Find neighbours in a spatial hash, a grid where every cell holds a list of the units inside it. Rebuild the hash every tick and sort it so the order stays deterministic.

Repulsion alone isn't enough. At 3,000 enemies, 83.7% of them had their nearest neighbour closer than 0.8 m, and the smallest distance was 4 cm, meaning two enemies were almost inside each other.

A higher separation weight doesn't fix it. At 6 instead of 1.5 the share of tightly packed enemies dropped to 54.6%, at 12 to 44.3%, at 24 there was no further gain (48.2%). On top of that the crowd starts to jitter, because unbounded pushes from many neighbours add up at once.

Positional correction helps. After moving, push every overlapping pair apart, each by half the overlap, and cap the shift at 0.15 m per tick. Without the cap the correction jitters just like the high weight. With it, 60.8% stay tightly packed, but the smallest distance rises to 28 cm and the crowd stays calm.

Separation only

Overlap correction

#Step 4: Pushing off walls

Next to a wall, correction between enemies fails. Moving into walls is forbidden (the move is split per axis and the part going into the wall is dropped), so a pinned enemy has nowhere to go and the push from its neighbour is lost. Out of 938 overlapping enemies, only 35 had any push from a wall.

So add a push away from the nearest blocked cells, in 4 directions and diagonally. Two mistakes you can avoid:

• Inner corner. Pushes from both edges and from the corner add up and fling the enemy away. Only add the corner push at an outer corner.
• Real walls. Push off the real walls, not off the walkability of the size class. For a large enemy the "wall" starts a metre before the real one. At a corridor entrance, the corner push cancelled a large enemy's forward motion and the whole group behind it got stuck.

#Step 5: Density cost and slowdown

Even with a smooth field the whole crowd takes the shortest path tight around the corner, no matter how many enemies are already there. Continuum Crowds (Treuille et al., 2006) offers a solution: cell cost grows with crowd density. Every 10 ticks, count the enemies per cell, smooth the result and recompute the field of one goal. At a crowded corner the field then sends enemies around, through less crowded cells.

No density

Density cost

The other half is slowing down. An enemy in a dense cell moves slower, down to 15% of its speed. Measured on 2,250 enemies: in sparse cells they moved at 94% of their speed on average, in medium density at 71%, in a jam at 20%. Let the slowdown start early: with a free-density threshold of 0.6 enemies per cell instead of 1, the share of tightly packed enemies in the chokepoint fell to 36.7%.

A practical tip: allocate arrays created at runtime (such as the density map) before a job uses them for the first time. A job scheduled with an array that doesn't exist yet crashes the Unity Editor in native code, without an exception.

#Step 6: Jams at a chokepoint: wait, don't push

When there's no room to spread, the chokepoint remains. The simplest idea is to drop the velocity component towards a neighbour the enemy is touching. The ones at the back then stop instead of stepping aside and keep the jam alive.

Stepping aside, for example by 35° to the side with fewer neighbours, is better, but the crowd starts to flicker. Smoothing the heading and lowering the turn speed (180 instead of 360 °/s) only dampens the symptom. The cause is elsewhere: with balanced density the enemy picks a different side every tick. Hysteresis, a bias towards the previous decision, fixes it: the side from the previous tick gets a bonus of 3 neighbours in the comparison.

The final solution combines a contact constraint with three states: moving, sidestepping, waiting. The velocity component into a touching neighbour is dropped, the sideways one stays. Whoever has neither a free side nor room ahead waits and doesn't push.

for each enemy, every tick:
    velocity = flow field direction × speed × density slowdown
    velocity += push from neighbours
    if touching a neighbour ahead:
        if a side is free: sidestep (side with hysteresis)
        else: wait
    drop the velocity component into touching neighbours
    move, drop the component into walls
then for everyone:
    push overlapping pairs apart (half the overlap, at most 0.15 m)
    push off walls

Watch out for three things:

• Patience. When two enemies meet head-on, let the one with the higher ID wait. A chain of neighbours can keep it blocked for thousands of ticks, though, so after a waiting limit it tries an emergency sidestep.
• Zero velocity. An enemy whose desired velocity is zero never leaves the "waiting" state and stays standing in the open after a wave. An enemy that doesn't want to move should always be "moving".
• Narrow cone. Look for a neighbour ahead within a narrow cone and with a short probe. At 45°, the settings sent 55 to 60% of the crowd into waiting or sidestepping even in the open; at 30° with a shorter probe, 41%.

#Step 7: Overtaking large enemies

Enemy types of different sizes and speeds bring more cases. Our large, slow enemy has a crowd radius of 1.25 m and walks at 1.1 m/s. A fast enemy behind it couldn't overtake: the side probes diagonally ahead were always closer to the large one than the sum of radii, both sides came out blocked and the fast enemy waited. The fix: the probe only counts the neighbour being passed on that neighbour's own side. A neighbour straight ahead blocks neither side.

The large enemy in turn kicks small ones out of its way to the sides, within ±45° in front of it. Don't kick those moving in its direction faster than it wants to go, or it will also kick the ones currently overtaking it.

#Step 8: Slots around the attack target

If enemies attack in melee, they need room around the target. Our tower has 24 slots around its 5 × 5 m footprint, each enemy takes one and the rest wait in a queue.

• Circle around. If you only offer a slot when a straight line leads to it, the rear slots stay empty, because from the front the line to them crosses the tower. Let the enemy circle the tower in an arc to a free slot.
• No eviction. Don't evict an enemy on its way to a slot in favour of another requester. It starts chains of evictions.
• No pushing at the slot. An enemy arriving next to an occupied slot gets pushed by its neighbour and ends up 13 cm from its target or completely off it. Enemies in a slot, and those within 0.5 m of it, don't push each other.

#Simulation and rendering performance

A benchmark in the Unity Editor (M3 Pro, around 9,600 simple enemies, two chokepoints) gave 90 FPS at 1440p and 100 at 1080p. Resolution barely changes FPS, time acceleration does: at 10× it drops to 20 FPS, because each frame has to run ten simulation steps. At normal speed the simulation has headroom.

With a detailed enemy model instead of a capsule, the bottleneck moves to rendering:

In the simulation, three things pay off:

• Two neighbour passes. The cheap one (contacts, blocking) always runs, the expensive one (side probes, side density) only for blocked enemies, a minority in free flow. Compare distances squared, without a square root.
• Simple sorting. Sorting the spatial hash synchronously took 0.37, 1.49, 3.16 and 8.46 ms at 3,000, 10,000, 20,000 and 50,000 entries, the job version 0.18, 0.93, 3.12 and 15.53 ms. The job isn't consistently faster, so simple sorting is enough.
• State hash. At ticks 600 and 1800, hash positions and health. A refactor must give the same hash, a behaviour change alters it and you can explain why. This works thanks to the deterministic order in the spatial hash.

#Limits of the approach

• Two full crowds going in opposite directions through one chokepoint get stuck for good. That's a limit of a model without physics.
• The numbers come from the Unity Editor on an M3 Pro. We don't have measurements on a Steam Deck or in a real build yet, only an estimate from public CPU benchmarks.

If you want to try your own crowd, the Unity Entities documentation is a good start. A similar path from the simplest solution to a working one is described in our post on the sudoku generator. How to throw enemies in such a crowd around with an explosion without an expensive ragdoll for each one is covered in how to fake ragdolls in Unity DOTS. If you're working on a similar simulation in Unity and want help, get in touch.

To generate a word search with a hidden message, drop random dictionary words into an empty grid until exactly as many cells stay empty as the message has letters. Then fill those cells with the message, left to right, top to bottom. On a phone this takes a few milliseconds and needs no backtracking, that is, no stepping back to earlier decisions when the generator gets stuck.

A word search is a grid of letters in which the player finds and crosses out words from a list. The hidden message is the text spelled by the letters that remain after all words are crossed out. So the generator has to build a grid that is completely full and leaves exactly the message once the words are gone. The process below is how the word searches in our crosswords and word search app (App Store, Google Play) are generated.

#Grid rules

Before you start, decide what a finished grid must satisfy. In our app:

• Words run in eight directions: horizontally, vertically and along both diagonals, each of them also backwards.
• Two words may share at most one letter.
• No word may pass through a cell of the hidden message.
• The grid must be full. An empty cell is a bug.
• The message is read left to right, top to bottom from all letters that are not crossed out.

#Step 1: Prepare the dictionary

Split the dictionary into groups by word length once, at the start. Picking a random word of a given length is then a single random index. If you filter the whole dictionary for every word, generation slows down noticeably, since a single grid tries hundreds of words.

Our Slovak dictionary has 16,713 words from 3 to 21 letters long, most of them with seven or eight letters. A few practical tips:

• Keep proper nouns and abbreviations in the dictionary. Words like HOUSTON or MAINE will then show up in the grid. Without short and "odd" words the grid can't be packed densely enough.
• Filter profanity with a separate list that can be switched off when the player wants adult content.
• With several languages, load only the one being played. The English dictionary has more than 414,000 words. Loading all four languages at app startup freezes a weaker phone for as long as 11 seconds.

#Step 2: Pick the hidden message

The message should have at least as many letters as the grid side, and at most four more. A shorter one gets lost in the grid, a longer one needs too many holes.

In our app the hidden message is the punchline of a joke. The player crosses out words and reads the ending of the joke from the remaining letters. We build the message from the end of the joke, adding whole words from the back until its length falls into that range.

The images below use the joke "Two snakes walk into a bar. Turns out they were lizards." on a 10×10 grid. The hidden message is WERELIZARDS, 11 letters. The words in the images come from the English dictionary narrowed down to common words, so they are readable.

#Why not to start with the message

The first idea is to do what you would do with a pencil: scatter the message letters over random cells in reading order, then build words around them.

That looks fine until the end. The generator picks an empty cell, tries to fit a word through it in every direction and offset, and once the grid gets dense, isolated holes remain. A single hole between two message letters can't be filled by anything, because the shortest word has three letters and no word may cross the message.

On a sample of 200 grids of 10×10, this approach produced a full grid in only 28 % of cases, with 1 to 2 holes left on average. Patching them afterwards is hard. So don't put the message into the grid until the words are done.

#Step 3: Fill the grid until exactly N holes are left

Filling is a simple greedy algorithm: each word is placed as soon as it fits and is never removed. The generator tracks a single number: how many cells are still empty. It places a word only if that would not leave fewer empty cells than the message has letters (N).

empty = rows × cols
while empty > N and attempts < 2000:
    word = random word of the chosen length
    repeat at most 50 times:
        start = random cell, direction = random one of 8
        if the word fits the grid rules:
            new = number of empty cells the word would fill
            if empty - new >= N:
                place the word
                empty = empty - new
                continue with the next word
if empty != N: throw the grid away and start over

The first words land freely in the empty grid:

As the grid fills up, words start sharing letters. That is welcome, since every shared letter is one cell less to fill:

When the number of empty cells drops to N, filling stops. Where the holes are doesn't matter. They can be scattered anywhere, because the message doesn't have to form any path through them:

#Step 4: Draw word lengths sensibly

Long words make a word search interesting, short ones get it finished. So draw the length from two normal distributions (you can get normally distributed random numbers from the Box-Muller transform, for example):

The length is always at least 3 and at most the grid side. Add two rules, without which the generator gets stuck at the end:

• Force the exact length at the end. When 5 or fewer cells are missing, look for a word of exactly the missing length (at least 3). Otherwise the generator keeps trying six-letter words that no longer fit.
• Ration three-letter words. The first three attempts at a grid may not contain any, attempts 4 to 6 may contain one, the next three two, and so on. Three-letter dictionary entries are often abbreviations like DNA or CPU and look cheap in a word search. Allow them only when there is no other way.

#Step 5: Pour the message into the holes

Walk the grid left to right, top to bottom and write the next message letter into every empty cell. Since there are exactly N holes, the message fits with nothing left over.

This is all the player sees:

#When a grid fails

If the generator doesn't reach exactly N empty cells within 2,000 attempts, throw the whole grid away and start over, at most 100 times. No hole patching. It is crude, but for grids up to 12×12 it is more than enough. Bigger grids need more attempts, as the table below shows.

#Success rate and speed by grid size

The generator ran on 300 grids per size, with real jokes and the Slovak dictionary (Node.js 22 on a server CPU, a phone will be slower; the images use the English dictionary, the numbers the Slovak one, because it is smaller and so a stricter test). "First try" means the first round of filling ended with a full grid.

What this means for your own generator:

• The average word has 4.7 letters, although the target is around 6. Long words simply fail to fit into a dense grid more often.
• About 9 to 10 % of cells are shared by two words. You don't need to tune this, it comes out of the "at most one shared letter" rule.
• You will get fewer diagonals than you expect. The direction is drawn uniformly from eight, so diagonals should make up half of the words. In a small grid, though, a diagonal word falls off the edge much more often. On 8×8 diagonals are 24 % of words, on 15×15 already 33 %. If you want more diagonals, give them a higher weight when drawing the direction.

#Tip: the same grid on every run

For store screenshots you need the exact same grid every time. In that mode, replace the usual random number generator with a simple linear congruential generator and a fixed seed (derived from the language, for example). If you keep all arithmetic within the range JavaScript numbers represent exactly, the result is identical on every device. The images in this article were generated with the same trick.

If you are solving a similar problem, generating puzzles or need a mobile app, get in touch. We also post short clips from development on YouTube. The same step-by-step approach is used in how to generate a sudoku with a unique solution. For crosswords instead of word searches, see how to generate an arrowword with a hidden message.