Why Unity Is Dead.

Your game already works. Keep it moving.

A game has a simulation, a renderer and a reason people want to play it. Then someone asks for a mobile version, and suddenly the conversation becomes a migration plan.

New engine. New project. Rebuilt systems. A long road back to behaviour that already worked.

Every system you rebuild is time you could spend putting the game in someone’s hands.

AI-assisted engineering gives small teams a way to challenge that cost. Read the existing code. Keep the useful systems. Build the missing pieces. Get to a playable version and let the device tell you what needs work.

The shortcut changed.

A general-purpose engine bundles a huge amount of work. Adopting that bundle can feel safer than writing the platform integration, tools and interface yourself.

But custom development has a different cost when AI can help navigate an unfamiliar codebase, implement an adapter, write a regression scenario and revise the result against a screenshot. Work that once made a focused stack feel impractical becomes work you can actually attempt.

That changes the starting question. How quickly can we get this game playable on the target device?

An engine has to contribute to that answer. Familiarity alone is an expensive reason to rebuild a working game.

We put a factory in a phone.

For our shapez Android prototype, we kept the original JavaScript simulation and Canvas renderer. We built an offline Android shell, a touch editor and layouts for phones and foldables around them.

The result is a real construction loop: place a miner, draw a belt, feed a cutter, deliver to the hub. Delete a mistake. Rebuild. Save the factory and come back.

Keeping the simulation meant we could spend our adaptation effort on the parts the player would feel: placing buildings with a finger, moving the camera, switching tools and recovering from an incorrect placement.

A working factory is a much better design brief than another migration document.

Compress the loop.

Our development loop ran through real feedback. Deletion only handled one tile. The toolbar took too much room. Desktop mouse hints appeared on a phone. Two expanded upgrade cards collided. Fullscreen left a strip above the game.

Each observation became a concrete engineering task. AI helped trace the relevant code, implement a change and construct checks around it. We rebuilt, tested and returned to the device.

This is where development speed compounds. The person deciding how the game should feel can work across input handling, CSS, localization and native Android integration without treating every boundary as a separate handoff.

Review and verification are part of that loop. A save failure needs a test. A gesture needs cancellation rules. An attractive dialog needs to survive two open sections. Catching those failures early keeps the next iteration moving.

Less to rebuild. Less to carry.

A focused architecture starts with a simple question: what can we leave out?

For this project, we could leave out a second game engine and a recreation of the production simulation. Android hosts the existing game through WebView; our code supplies the mobile interaction and platform integration.

The browser runtime still has a footprint. Download size, memory use and frame time need their own measurements. Our case documents a playable prototype; a controlled performance comparison with the official mobile edition is still ahead.

The development decision is already visible in the source: we retained the working core and built around it. That is the kind of scope reduction AI can help a small team execute.

Make the engine earn the build.

Keep an engine when its renderer, animation tools, content pipeline or platform support solve the expensive problems in your game. Those are concrete reasons. “That’s how mobile games are made” is a habit.

AI expands the set of architectures a small team can realistically build and maintain. The advantage goes to teams that use that freedom to cut unnecessary work and test the important assumptions sooner.

The winning stack is the one that gets your game into players’ hands and survives what happens next.

Put your next port to the test.

Pick one production loop. Pick one target device. Keep the systems that already work. Build the smallest playable adaptation that exposes the real constraints.

That is how we approach mobile adaptation at Zerno. Start with something you can play, inspect and improve. Let the prototype earn the bigger project.

Explore our implementation, read the engineering decisions and use the source to judge the result.

Independent adaptation of the open-source shapez game by tobspr Games. Original authorship is retained; this is not the official mobile edition.