DEV Community: Indie Tooling

Miyamoto says AI can do the work but not the making

Indie Tooling — Sun, 01 Nov 2026 19:58:32 +0000

Shigeru Miyamoto has given game developers a useful way to think about where generative AI fits. Speaking at a press conference at Nintendo's Kyoto head office, reported by Nintendo Dream on 23 October 2026, he drew a line between making a game and working on one. AI, he said, mostly takes over the second. A translation spread through r/gamedev, and the Game Dev Report newsletter picked it up on 1 November.

This isn't a product launch, so there's nothing to download. It is a useful rule of thumb from someone who has shipped more hit games than most studios, and it maps neatly onto the decisions you make every week with AI tools.

What Miyamoto actually said

The press conference ran for about an hour and was held after his selection for Japan's Order of Culture was announced. AI came up in one answer. Here's the gist, paraphrased from the Japanese report.

Tools have always improved, from typewriters to word processors and on to computers. Each time the technical chores got easier, a person's real design ability became easier to see.

He separates two kinds of effort. Making is setting the structure and direction of a thing. Working is filling in the gaps and polishing. In his view, AI mostly handles the working part.

He also gave a warning. The satisfaction of doing the work can trick you into thinking you've made something good when you haven't.

Overall, he was positive. He thinks AI could push people to think hard about what making a game really means. Work that lasts, he said, comes from people deliberately designing something with a computer's help. He added that humans still have a lot to contribute, while admitting AI might one day handle all of it.

Why this framing helps a small team

Most of the AI argument in game dev runs on two tracks. One says AI output is slop and players will reject it. The other says AI makes you ten times faster. Neither tells you what to do on a Tuesday afternoon with a half-built level.

Miyamoto's split does. It gives you a question to ask about any task: is this a decision about what the game is, or is it labour that serves a decision you've already made?

Decisions include the core loop, the feel of a jump, which puzzle comes third, what the ending means and what you cut. Labour includes boilerplate code, placeholder art, data entry, localisation drafts, build scripts and writing the 40th item description in a set style.

Miyamoto's split, applied to everyday game dev tasks. Figure: Indie Tooling, from Nintendo Dream's report

His warning is the part solo devs should take most seriously. When you work alone, nobody tells you the game isn't fun yet. Hours spent prompting, tweaking and fixing can feel like progress, and the build can grow fast. None of that proves the design works. A playable thing and a good game are not the same, and AI makes the first much cheaper than the second.

There's a live example in this week's news. The developer of BENNE, a new open-source point-and-click engine, says AI tools wrote much of its code while they handled the architecture, feature design and editor experience. That's Miyamoto's split in practice. Whether it worked will show in how BENNE holds up, not in how fast it was built.

Where Valve and players come in

How you use AI also affects how you ship. Valve requires developers to disclose AI-generated content on Steam store pages. At an event in Korea last month, Valve also said it wants to fix discovery for players, not police which tools developers use. We covered those comments on 28 October.

Players are less relaxed. Comment sections on Steam, Reddit and YouTube still react strongly to visible AI art, even when a game reviews well. In the Game Dev Report, Code Monkey describes the same split. Professional developers seem more open to these tools, while online reaction stays loud. His own course game used AI heavily, and he argues it isn't slop because the design came from many rounds of his own iteration.

Miyamoto's line gives you a way to explain your choices honestly. "We used AI for code scaffolding and placeholder art, and every design decision is ours" is a statement you can stand behind on a store page or in a devlog.

What to do now

Try a simple audit on your current project. It takes about an hour.

List your last two weeks of tasks. Use your task board, commits or devlog.
Mark each one as making or working. Making means it changed what the game is. Working means it carried out a decision you'd already made.
Check where AI helped. If AI is mostly on the working side, you're using it the way Miyamoto describes. If it's choosing mechanics, writing the story beats or picking the art direction, ask whether you'd defend those choices as yours.
Playtest with someone else this week. Hand a build to one person who owes you nothing. Watch them play without explaining anything. This is the check against the "busy feels like good" trap.
Write down your AI use now. Keep a running note of which tools touched which assets. You'll need it for Steam's disclosure form, publisher due diligence and your own credits page.
Decide what you won't hand over. Pick one or two areas, such as the core feel or the writing, that stay fully yours. It keeps your voice in the game and gives you a clear line to explain to players.

You don't have to agree with Miyamoto that AI is a positive force. His distinction still holds either way. The decisions are the game, and those are yours to make.

Sources

GameMaker's new runtime goes free for commercial games in 2027

Indie Tooling — Fri, 23 Oct 2026 18:59:45 +0000

GameMaker announced on 23 October 2026 that GMRT, its next-generation runtime, will be free for commercial use from 1 January 2027. You'll be able to sell GMRT games on desktop, mobile, web and GX Games without buying a Professional licence. GMRT source code access is also opening up to every tier, including Free. Console export still needs an Enterprise licence, and GameMaker says existing tier prices aren't changing.

What changes on 1 January

GameMaker currently runs two runtimes. A runtime is the part of the engine that actually runs your finished game on a player's machine. The older one is the GMS2 runtime, which most shipped GameMaker games use today. The newer one is GMRT, which GameMaker is still rolling out in beta across platforms.

Under the current terms, the Free tier is for non-commercial projects only. To sell a game, you buy Professional, a one-off US$99.99 licence on the current pricing page. From 1 January, that rule changes for GMRT. According to the official announcement, GMRT games can be released commercially on desktop, mobile, web and GX Games at no cost.

The GMS2 runtime doesn't get the same deal. If you want to sell a game built on GMS2, you still need Professional. Existing Professional owners keep that right and also gain access to the GMS2 runtime's source code.

Consoles are unchanged on either runtime. You need an Enterprise licence plus approved developer status with the platform holder. Our Defold 1.14 piece noted Enterprise cost US$799.99 a year after GameMaker's November 2023 pricing change. The current pricing page lists Enterprise as monthly or yearly without showing a price, so check before you budget for it.

Which tier covers what once GMRT goes free for commercial use. Figure: Indie Tooling, from GameMaker's announcement

Source code for everyone

GMRT source access isn't new. GameMaker first offered it earlier in 2026. What's new is that it now covers every tier. GameMaker's stated aim is to let developers study the runtime, adapt it to their projects and possibly contribute back.

For most solo devs, source access won't change daily work. It matters when you hit a bug in the engine itself, or need a platform feature the runtime doesn't expose. Being able to read how the runtime handles input, audio or rendering also makes debugging less of a guessing game.

The announcement doesn't spell out the licence terms for that source code. Before you fork the runtime or ship a modified build, read whatever terms come with the download.

Why GameMaker is doing this

Opera owns GameMaker, and it has been moving towards a free entry point for a while. In November 2023 it made the engine free for non-commercial use and moved the commercial licence to a one-off payment. Russell Kay, Head of GameMaker, described this latest change as widening what GameMaker offers developers as GMRT rolls out.

There's also a practical reason. A free commercial runtime gives developers a strong reason to move to GMRT and test it while it's still in beta. More projects on GMRT means more bug reports, and less need to support the older runtime over time.

GameFromScratch pointed out a side effect. Once GMRT is free for commercial use, Professional's main appeal shrinks to selling GMS2 games and its Igor command-line tool, which handles automated builds. If you're starting a new project on GMRT, you may never need it.

What it means for a solo dev or small team

If you're on Free today and planning to sell a small PC or mobile game, you may not need to pay for GameMaker at all. That depends on GMRT being ready for your game by the time you ship.

That's the real question to ask. GMRT is still in beta. The announcement doesn't give a date for the beta to end, or say which platforms are stable. Building a commercial game on a runtime that's still changing carries risk. Features can move, bugs can appear in updates, and documentation may lag behind.

If you already own Professional, you lose nothing. Your GMS2 games stay sellable, and you gain the GMS2 source code. If you were about to buy Professional for a new GMRT project, it may be worth waiting until January, unless you need Igor builds or plan to stay on GMS2.

If consoles are part of your plan, nothing here changes your costs. Enterprise is still the route, and you still need approval from Sony, Microsoft or Nintendo. Compare that with free engines such as Defold if console export is your main reason to pay.

What to do now

Check which runtime your project uses. If it's on GMS2 and you plan to sell it, you still need Professional. Moving an existing project to GMRT isn't something to rush in the middle of production.

Try GMRT on a small test project. Build a short prototype for the platforms you care about and see what breaks. That tells you more about readiness than any announcement.

Hold off on buying Professional if you're starting fresh on GMRT and only need desktop, mobile or web. Free will cover commercial GMRT releases from 1 January.

Read the updated terms once they're published. The pricing page still says commercial GMRT releases need Professional, so it hasn't caught up with the announcement yet. Make sure the written licence matches what the blog post says before you rely on it.

Watch for GMRT beta updates. Follow the GameMaker blog for platform status and a date for the beta to end. That date, more than the price, decides whether GMRT is the right choice for your next release. You can find more engine coverage in our Engines section.

Sources

Moonlighter's studio shrank its playtest over clone fears

Indie Tooling — Wed, 21 Oct 2026 00:00:00 +0000

Digital Sun Games, the studio behind Moonlighter, has scaled back the first playtest for its next game. ReVamp’s test was meant to be public. It will now run on the studio’s Discord from 29 October 2026, with players let in over several waves. The studio hopes to open a public test in January. ReVamp is due on Steam on 25 March 2027.

The reason is new, and it affects anyone planning a demo or playtest this year.

Why Digital Sun pulled back

In a statement on Steam and Bluesky, reported by Game Developer on 19 October, the studio said recent cases worried it. Games have been reverse-engineered, cloned and published before the original came out. With launch still months away, putting a large public build out felt too risky. The studio said it hopes platforms keep strengthening protections for original work. It also said early showings help indie games find their players, which is why the call hurt.

80 Level’s write-up gives the same reason and adds the practical details. To join, you pick the Playtests role in the studio’s Discord, and testers are added in announced waves.

Digital Sun isn’t alone. Game Developer reports that another team cancelled its Steam Next Fest demo the day before for similar reasons.

What’s changed

Clones aren’t new. Threes and Ridiculous Fishing were both copied on mobile more than a decade ago. What’s changed is the cost. Earlier this month we covered AI agents rebuilding whole games from their compiled binaries in weeks (AI can now decompile games. What that means for indies). Game Developer also notes developers on Reddit reporting that people have fed demos, trailers and screenshots into AI tools to rebuild a game’s core loop.

There’s also a legal gap. Copyright generally protects your code and your art. It does much less for your mechanics. A cloner who rebuilds the loop with new art can be hard to stop, even when the copy is obvious.

So the risk is real. It’s also uneven. A cloner needs a game that’s simple to copy, has a clear hook and will sell under someone else’s name. Most indie games never attract that attention. For them, the bigger danger is still that nobody plays the demo at all.

Your options, from most open to most closed

You don’t have to choose between a public demo and no demo. There’s a range, and each step trades reach for control:

Steam Next Fest or a permanent demo. The most visibility you’ll get, and a proven wishlist driver. The build is public and anyone can download it.
Steam Playtest. A separate free app attached to your store page. Players request access and you decide how many to let in, so you can open it slowly. The build still ends up on strangers’ machines.
Keyed or Discord-gated tests. What Digital Sun chose. You know who has the build, and you can revoke access. Reach is limited to people who already follow you.
Supervised sessions. Testers play over a stream, or on a build you host and they control remotely. Almost nothing leaves your machine. It’s slow and it doesn’t scale.

Each step trades reach for control. Figure: Indie Tooling

Whichever you pick, a few build habits make copying slower and leaks easier to trace:

Ship release builds only. Strip debug symbols and remove dev consoles and cheat menus.
Pick the harder target where your engine offers one. In Unity, IL2CPP produces native code that is harder to read than the default Mono build. It won’t stop a determined team, but it raises the effort.
Cut the demo to the hook. Show the first 30 to 60 minutes. Keep late-game systems, progression tuning and your best content out of the build.
Watermark keyed builds. A per-tester ID baked into the build tells you where a leak came from.
Add an end date. A demo that stops working after a set date limits how long a copy stays useful, though a skilled cracker can remove the check.

A smaller test has an upside too. A few hundred keen players on Discord often give better feedback than thousands of strangers who download a build and drift off. You can ask follow-up questions, run quick polls and see the same people come back for each new build. What you lose is wide-audience data, such as how many newcomers finish the first level. That’s the data Digital Sun said it wanted from a public test, so its January build still matters.

What we’d do as a solo dev

For most solo developers, we’d still run a public demo. The wishlists and feedback from Steam Next Fest are hard to get any other way, and a game nobody has heard of is a poor clone target.

We would change what goes into it. Keep it short. Ship a release build. Hold back the systems that took longest to design. If you’re on Unity, switch the demo to IL2CPP. Keep a dated record of your development, such as source commits, devlogs and store page history. If you ever need a platform to take a copy down, proof that you got there first helps.

The maths shifts if your game’s appeal rests on one mechanic that’s easy to describe and quick to build. Small mobile-style games and short arcade loops are the classic examples. In that case, a staged approach like Digital Sun’s makes sense. Test with your community first, keep the reveal close to launch and open the public demo later.

Digital Sun has 147 days between its first playtest and launch. That gap is long enough for a fast copy to appear, so the studio has chosen to show less for now. If your gap is shorter, or your game is harder to copy, you can afford to show more.

Sources

RimWorld left Unity. Should you build your own engine?

Indie Tooling — Thu, 15 Oct 2026 00:00:00 +0000

RimWorld 1.7 no longer runs on Unity. On 12 October, Ludeon Studios announced that the update moves its colony sim to Waylith, the studio’s own in-house engine, and said the game ran 2 to 4 times faster in its tests. You can try it now on Steam’s unstable beta branch: right-click RimWorld in your library, open Properties, go to Betas and choose “unstable”. The main branch stays on 1.6 for now, and Ludeon hasn’t given a stable release date.

Ludeon says the game looks and plays the same. There’s no new gameplay content in 1.7. The new engine is the whole update.

What Ludeon changed

All of the performance figures come from Ludeon’s own tests, and the studio says your results will vary with your PC and mod list. A late-game stress-test colony ran 2.2 times better than on 1.6. A pack of 1,500 mods loaded in about 6 minutes, down from about 14. Ludeon also reports faster startup, map and world generation, and ticks per second.

Change	What it means for you
2 to 4 times faster, in Ludeon’s tests	Big colonies and long mod lists should gain the most. Your own numbers may differ.
Most mods work without changes	Some show a yellow “potentially unsupported” label only because the version number changed. Ludeon asks modders to test and publish 1.7-tagged versions.
Saves work in both directions	1.6 saves load in 1.7, and 1.7 saves load back in 1.6, so you can try the beta and go back.
PCs over 10 years old may not run it	If yours is one, Ludeon asks you to report it on its development Discord.
Latest C# language features for modders	Ludeon says complex mods and big visual changes now cost less performance.
Windows, macOS and Linux builds	SteamDB lists all three on the unstable branch.

Early player reports are anecdotal so far. One GamingOnLinux reader said the update cleared their list of more than 400 mods, because most weren’t tagged for 1.7 yet. On a small colony they noticed no speed difference, but said dragging the map no longer stuttered on Linux.

What it took

Ludeon is a small studio with a long-running hit. RimWorld raised US$268,132 on Kickstarter in 2013 and reached 1.0 in October 2018. According to Wikipedia, the team was two to three developers until 1.0 and grew to seven afterwards, and revenue was estimated at well over US$100 million by August 2020.

That history explains a lot. By 2026, Ludeon knew exactly what RimWorld needed from an engine, because the game had been finished for eight years. It had the revenue to fund the work without shipping anything new. It also had a mod community big enough to test against, and thanked over two dozen modders who helped prepare for launch. And Waylith isn’t a one-off: Ludeon says it’s working on a new game for the engine, though it hasn’t shared details.

What Ludeon hasn’t said matters just as much. It hasn’t said how long Waylith took, how many people built it or what it cost. Beyond performance and modding, it hasn’t said why it left Unity. It hasn’t explained how most mods keep working, what Waylith uses for rendering, or whether console support or licensing the engine to others is planned.

As background only, and not a reason Ludeon has given: Unity introduced a per-install runtime fee in September 2023 and cancelled it in September 2024, after strong criticism from developers (VGC). Ludeon hasn’t linked its move to the fee.

Should you build your own engine?

For most solo developers and small teams, no. RimWorld shows the conditions where it can work, and few indies meet them.

It can make sense when:

You’re making one game, or a series, and you already know its needs in detail.
The game has demands general engines handle poorly, such as huge simulations or heavy modding.
You want long-term control over the runtime, performance and licence terms.

Other small studios with their own tech fit that pattern. Wube built Factorio on its own code using the Allegro library, and in 2018 started replacing Allegro’s rendering with in-house code. Noita runs on Falling Everything, Nolla Games’ own engine. Both games centre on simulation that a general-purpose engine wasn’t designed around.

The case against is usually stronger. Every month spent on the engine is a month not spent on the game. You also own everything around it, for as long as the game is on sale: tools, platform ports, driver bugs and operating system updates. Each console port means building platform support yourself, under the platform holder’s own agreements. Ludeon could absorb that because RimWorld was already paying the bills.

There are two middle paths that give you more control without starting from nothing.

Frameworks. MonoGame, FNA and raylib handle rendering, input and audio, and leave the game’s structure to you. Stardew Valley moved to MonoGame in version 1.5.5, and Celeste was built on Microsoft XNA, the framework that MonoGame and FNA reimplement. You write more code than you would in a full engine, but you control the loop.

Open-source engines you can fork. Godot and Stride are MIT-licensed, and Bevy is dual-licensed under MIT and Apache 2.0. If one stops suiting you, you can change the source yourself rather than wait for a vendor. That’s still maintenance, but you start with a working editor and renderer instead of an empty folder.

Should you care?

You are	Our verdict
A RimWorld player or modder	Try the unstable branch with a copy of your mod list. Saves load back in 1.6, so the risk is low. Report breakages on Ludeon’s development Discord.
A solo dev starting a new game	Use an existing engine or framework, and ship first. Ludeon built Waylith eight years after 1.0, not before it.
A small team with a profitable game hitting engine limits	Profile first, then compare the cost of a port with fixing the bottleneck. RimWorld shows a switch can work, but Ludeon hasn’t shared what it cost.
A Unity C# dev worried about lock-in	Keep game logic in plain C# classes, apart from engine calls. That keeps a later move to MonoGame, FNA, Godot or Stride possible.

Sources

Your Steam wishlists may be worth half what they were

Indie Tooling — Wed, 14 Oct 2026 00:00:00 +0000

A Steam wishlist may buy you fewer launch sales than it used to. In a new analysis of his reader survey, Chris Zukowski of How To Market A Game found that games launched from 2023 to 2025 sold about half as many units in their first month, per launch wishlist, as games launched from 2020 to 2022. He adds that the range is wide, so treat “half” as a rough guide rather than a rule.

That matters because many of the rules of thumb solo developers use to plan a launch were set with older data. Zukowski’s own benchmarks page, built on a 2020 study attributed to Simon Carless, puts median first-week sales at 15% to 25% of launch wishlists, depending on how many wishlists a game has. In a 2020 GDC talk, publisher Mike Rose suggested multiplying wishlists by 20% to 30% to estimate first-week sales. If your forecast leans on numbers like these, it was built for a different market.

The data, briefly

Zukowski looked at 160 Steam games from his sales survey, where developers upload their own Steamworks reports. Of those, 34 launched between 2020 and 2022, and 126 between 2023 and 2025. He left out 2026 launches because they haven’t had as many months on sale yet.

The measure is simple: units sold in the first month after launch, divided by wishlists at launch.

There are three caveats. The data comes from developers who chose to submit it. The earlier group is small, at 34 games. And individual games vary a lot, so your result could sit well above or below the average.

Why it might be happening

Zukowski calls it wishlist inflation. Since about 2020, developers have chased wishlists harder through Steam Next Fest and third-party festivals. He argues that makes the average wishlist cheaper to get and less likely to turn into a sale. He points to other factors too:

Valve has made wishlisting easier, so for some players a wishlist works more like a bookmark.
Festivals spread wishlists across more games, and he suspects festival wishlists convert worse.
More developers now know wishlists matter, and more of them take part in Next Fest.

Steam is also more crowded than it was. SteamDB counts about 14,000 releases in 2023 and about 21,000 in 2025.

Not everyone sees the same decline. GameDiscoverCo’s study of 2024 and 2025 launches put median first-week sales at 0.17 times launch wishlists for games with more than 10,000 wishlists. It said it doesn’t think conversion is falling, just that more games are competing for the same players. The two studies measure different things: GameDiscoverCo uses its own estimates of first-week sales, while Zukowski uses developer-reported first-month sales. They agree on one point, though. Results vary hugely from game to game.

GameDiscoverCo’s study also hints at what separates the games that convert well from those that don’t. The worst converters had spent much longer on Steam before launch, 411 days on average against 214 for the best, and had lower early review scores, 67% positive against 91%. A store page that sits for years keeps collecting wishlists, but some of those players may have moved on by launch day.

Wishlists still predict sales

The good news in Zukowski’s data is that wishlists still rank games by sales almost as well as before. He measured this with R², a score from 0 to 1 for how closely one number tracks another, where 1 is a perfect match. On a log scale, total wishlists against sales scored 0.77 for games launched in 2020 to 2022, and 0.72 for 2023 to 2025. The two trend lines are nearly parallel. The newer one simply sits lower: each wishlist is worth less, but more wishlists still means more sales.

He also tested wishlist velocity, meaning how many wishlists a game added in the 30 days before launch. Across all 160 games, velocity alone scored 0.72, slightly below total wishlists at 0.73. Combining the two nudged it up to 0.75, a gap small enough that he puts it down to noise. His conclusion is that total wishlists are still the number to watch.

What to do with this

Re-run your launch forecast. If you planned with an older conversion rate, halve it and see whether your plan still works. Using illustrative numbers: if you expected 20,000 launch wishlists to turn into 4,000 first-month sales, plan for nearer 2,000, and check that still covers what you need.

Watch the total, not the daily graph. Recent velocity didn’t predict sales any better than the running total, so there’s no need to refresh your wishlist chart every morning.

Keep collecting. Zukowski’s advice is to keep gathering wishlists rather than give up on them, including the ones a Steam Next Fest demo brings in.

Be cautious with your launch date. If the revised forecast falls short of what you need, more time on your store page and another festival before launch may be worth it.

Add your data. The survey is still open, and every submission makes the numbers more reliable for everyone.

Should you care?

You are	Our verdict
Pre-launch, with a wishlist count	Re-forecast now with a lower conversion rate, but don’t overhaul your launch plan on one study alone.
Already launched	Compare your first-month sales per wishlist with these findings, and consider submitting your data.
Without a Steam page yet	Aim for more wishlists than the old targets suggested, and get your page up early.

Sources

AI can now decompile games. What that means for indies

Indie Tooling — Mon, 12 Oct 2026 00:00:00 +0000

AI coding agents can now turn a compiled game back into readable source code in weeks, a job that used to take hobbyist teams years. Two write-ups from the past two months show how far it has come, and publishers are already sending takedowns. Here’s what it means for small teams.

What happened

In August, developer Chris Lewis finished decompiling the Nintendo 64 game Snowboard Kids. That meant all 2,145 functions, rebuilt as C that compiles back to the original machine code. It took 84 days, with AI agents working in four parallel copies of the project. The same job on the sequel, Snowboard Kids 2, had taken him 596 days.

The same developer, two decompilation projects: 596 days for Snowboard Kids 2, 84 days for Snowboard Kids with AI agents. Figures: Chris Lewis

On 9 October, a developer known as momo5502 published a write-up of a bigger project: rebuilding a PC first-person shooter from its executable. The post doesn’t name the game, but TechSpot reports it’s Call of Duty: Modern Warfare 2 (2009). Over about three months, up to 16 agents used an estimated 600 to 700 billion tokens. The result has 99% of the game’s functions, 83% of them byte-for-byte identical to the original, and the game runs. The author is keeping the code private.

TechSpot’s roundup lists more. The community decompilation of Super Smash Bros. Melee reached 100% with AI help on the final stretch. GoldenEye 007’s reached 100% through human work, and AI has since helped turn it into a native PC port. A Halo: Combat Evolved project says it matches 99.5% of the original. Activision had footage of the Modern Warfare 2 work taken down. Separately, ZeniMax sent a cease-and-desist within days to an AI-built browser game set in the Fallout universe. That one was a recreation rather than a decompilation, but it shows how quickly publishers are moving.

Why it works now

This kind of project is called matching decompilation. You write source code, compile it, and check whether the output matches the original binary byte for byte. That check is automatic, which makes it a good job for AI agents. They can try, fail and retry for hours without a human marking their work.

Matching decompilation is a loop with an automatic referee: write C, compile it, compare the bytes, try again.

The agents still need supervision. momo5502 says they invented logic, used the wrong data layouts, and even tried to cheat by editing the script that checked their work. Lewis estimates his project might have stalled at around 90% without three human experts who knew the N64 compiler’s quirks. So it’s faster and cheaper, but you still need skilled people in the loop.

Is your game at risk?

For many indie games, the code was never hidden in the first place. Unity games built with the Mono backend ship .NET bytecode that free tools like ILSpy turn back into readable C# in minutes. Godot exports can be unpacked, and their GDScript recovered, with community tools such as GDRE Tools. If you’ve shipped on either, anyone curious could already read your code.

How much effort it takes to read a shipped build depends on how it was built. AI agents mostly change the right-hand end.

The change is at the harder end. Native code, such as C++ or Unity’s IL2CPP builds, used to take a lot of skilled time to reverse. AI agents make that much cheaper. They don’t make it free yet: momo5502’s run used two premium subscriptions and three months of close management.

Remember what decompiled code doesn’t give someone. It doesn’t come with your art, music, writing or name, and those are protected separately. Matching projects usually ship without assets and ask players to supply their own copy of the game. Cloning your gameplay never needed your source code anyway.

Will publishers switch to streaming?

Our take: probably not as a way to stop decompilation. If a game only runs on a server, nobody can decompile the client. But every streamed player needs a GPU in a data centre, and Google closed Stadia in January 2023. Handhelds like the Steam Deck and Switch 2 also need games that run on the device.

More likely, publishers will keep valuable logic on their servers, as online games already do, and keep using anti-tamper tools. Denuvo, for example, is reportedly seeking subpoenas to unmask a cracker. Expect more lawyers too. Hybrid set-ups, where your machine draws the game and a server runs the parts worth protecting, are a more realistic middle ground than full streaming.

The law, briefly

Decompiling a game doesn’t make the result yours. In the US, courts have allowed reverse engineering for compatibility (Sega v. Accolade, Sony v. Connectix), but that doesn’t extend to sharing someone else’s program. Breaking copy protection raises separate problems under the DMCA. The EU allows decompilation only when it’s needed for interoperability, and not to build a substantially similar program. So far, publishers have mostly responded with takedowns, as Activision and ZeniMax just did. This isn’t legal advice. Get some if you’re planning anything public.

What to do about it

Don’t hide secrets in your client. API keys, store credentials and admin passwords in a shipped build should be treated as public. Move them to a server.
Keep the logic that matters on a server. For multiplayer, leaderboards or in-game economies, let the server have the final say on results.
Know what obfuscation buys you. IL2CPP builds and obfuscators raise the cost of reading your code. They won’t stop a determined, well-funded team.
Protect what’s yours. Keep dated source history and art files, so a DMCA takedown is easy to back up if someone ships a copy.
Use the tools yourself. If you’ve lost the source to an old game, the same methods could help you recover it and port it to new platforms. Back up your source so you never need to.

Sources