How to Protect a Game Demo From AI Decompilation and Cloning: What Actually Works (2026)

Short answer: you can't make a game demo impossible to decompile, and AI tools have made reading decompiled code much faster. What still works: ship less code, put the logic that matters on a server, gate who gets the build, and make every copy traceable. IL2CPP, obfuscators and pak/PCK encryption are worth turning on because they're cheap, but they only buy days, not months. Below are the exact settings for Unity, Godot and Unreal, a Steam Playtest setup, a watermark you can add in an afternoon, and a rating of each defense by effort against how much it actually slows an attacker.

The hook: a top-100-wishlisted game pulled its Next Fest demo over AI clones

On 16 October 2026, Tokyo publisher Alliance Arts announced that it was cancelling the public Steam demo of Drunken Goddess Reflux, which was due on Monday 19 October, the first day of Steam Next Fest. The studio's own post gives two reasons:

1. It had planned limits on posting and streaming gameplay, but concluded it "is not currently in a position to properly handle and manage those restrictions."
2. It is "concerned that, based on the content of the demo, works imitating or replicating this game's presentation and gameplay could be quickly produced using AI or other tools and released ahead of the game's launch."

What replaces the demo is a lottery-based closed playtest on Steam, 23 to 31 October (JST). You apply through the studio's Discord by 22 October, 11:59 PM JST, and winners get a product code by email (how to join). The participation agreement bans streaming, spoilers outside Discord, sharing codes, and, in Article 10, "disassembling, decompiling, reverse engineering... (including having any AI analyze them)" and using the build for AI training. The game launches 8 December 2026 at $4.99, per Alliance Arts' release-date post on X, which had promised the 19 October demo.

Coverage: GameSpot (it puts the game in Steam's top 100 most-wishlisted and points to the clone wave around Needle in a Haystack), Pogwire, and an IGN post on X that had about 48,700 views when we checked. On 19 October the story was being reposted in English, Spanish, German and Japanese circles on X. We couldn't confirm that it hit an official X trending list, so "widely shared" is the accurate claim.

What's not in the record: Alliance Arts doesn't say a clone of its game already exists, and it doesn't say which engine the game uses. Its worry is about what could happen in the seven weeks between the demo and launch.

That worry is reasonable for this game, and the reason matters for everything below. A short Russian-roulette drinking game with one character and a strong look gets cloned from video, not from its code. Most of what follows will slow down someone working from your binary. Only access control and timing slow down someone working from a 30-second clip.

What an AI-assisted attacker actually does with your demo

If you want the attacker's side in depth, our reverse-engineering toolkit roundup and the REA vs GhidraMCP vs IDA Pro MCP vs Binary Ninja comparison cover the tools. Here's the short version for games:

Engine / build	What falls out with free tools	What AI adds
Unity, Mono backend	Assembly-CSharp.dll opens in ILSpy or dnSpyEx as close-to-original C#: class names, method names, logic	Reads and summarizes the whole codebase in minutes and can port it to another engine
Unity, IL2CPP	GameAssembly.dll plus global-metadata.dat. Il2CppDumper or Cpp2IL restore type and method names, then Ghidra or IDA show native code	Names and explains the stripped native functions. That's the slow part for a human, and AI is good at it
Godot 4	GDRE Tools (gdsdecomp) recovers a project from an unencrypted .pck, tokenized GDScript included	Same: it rebuilds readable scripts and scene logic
Unreal	FModel or UModel open .pak/IoStore assets. If they're encrypted, people pull the AES key from the executable	Blueprint and C++ logic still has to be reverse-engineered from native code, and AI helps there
Any engine	AssetRipper-style asset extraction, plus screen capture	Generates lookalike art, music and UI from screenshots and gameplay video

The pattern: anything that runs on the player's PC can be read. AI doesn't break your protection. It makes the reading step after the protection much cheaper.

Ratings: effort vs. how much each defense slows an AI-assisted clone

Scores run 1 to 5 and are our editorial judgment, not benchmark results. The baseline is a plain Unity Mono build with no protection (0).

Defense	Effort (1-5)	Slows AI-assisted decompile/clone (1-5)	Verdict
Critical logic/content server-side	5	5	The only thing they truly can't decompile. Worth it for a small, valuable piece, not the whole game
Closed, keyed playtest (Steam Playtest keys)	2	4	Fewer binaries in the wild, each tied to an account. Alliance Arts' choice
Ship a thin demo slice (code removed with #if)	2	4	Code that isn't in the build can't leak. Most underrated item on this list
IL2CPP + metadata-protecting obfuscator	3	3	Breaks the one-click Il2CppDumper/Cpp2IL step. Good for Unity games that rely on systems
Commercial packer / anti-tamper	4	3	Real friction, but it costs money, can trigger antivirus false positives and can hurt performance. Rarely right for a demo
Unity IL2CPP + High managed stripping	1	2	Free, takes 10 minutes, turns "read the source" into "reverse native code." Just do it
Unreal pak encryption + signing	1	2	Checkboxes. Stops casual asset browsing, but the key ships in the exe
.NET obfuscator on a Mono build	2	2	Renaming helps. LLMs are good at re-guessing names from context
Godot PCK encryption + binary tokens	3	2	Needs custom export templates, and the key lives in the binary
Asset encryption (any engine)	2	1	Does nothing against screenshots and video, which is how art gets cloned
Per-tester build watermark	2	1	Doesn't slow anyone. It tells you who leaked
Legal/DMCA prep + EULA clauses	2	1	Doesn't slow anyone. It cuts takedown time from weeks to days

Step by step: the settings that matter

Unity: switch to IL2CPP and strip

1. Edit > Project Settings > Player > Other Settings > Configuration > Scripting Backend: IL2CPP. (On Windows you need the "Windows Build Support (IL2CPP)" module from Unity Hub and the C++ workload in Visual Studio.)
2. Same panel: Managed Stripping Level: High. Test the build afterwards. Stripping removes code reached by reflection, so keep anything you need in a link.xml or mark it with [Preserve].
3. Build as a Release build with Development Build unchecked. Don't ship a .pdb or a *_BackUpThisFolder_ButDontShipItWithYourGame folder. Unity names that folder that way for a reason, and people ship it anyway.
4. If your demo's value is in its systems, add an obfuscator that supports IL2CPP and protects or encrypts global-metadata.dat. Several Unity Asset Store obfuscators (Beebyte's Obfuscator is the long-standing one) rename symbols before IL2CPP runs, so even a successful dump shows a1b2c() instead of CalculateRouletteOdds(). Check that the tool you pick supports your Unity version before you buy.

Strip the demo down for real. Settings that just lock content don't remove it. Use a scripting define:

// Project Settings > Player > Scripting Define Symbols: DEMO_BUILD
public static class Content
{
#if !DEMO_BUILD
    public static void RegisterLateGameSystems()
    {
        BossPhaseTwo.Register();
        EndingRouter.Register();
    }
#endif
}

Also remove late-game scenes from File > Build Profiles / Build Settings, and keep their Addressables groups out of the demo build. A boolean isDemo check still ships the full code, ready to decompile.

Mono or plain .NET games: obfuscate, but expect less

If you stay on Mono (or ship a .NET game outside Unity), run the assemblies through an obfuscator as a post-build step. Options include ConfuserEx forks such as ConfuserEx2, Obfuscar (free), and commercial tools such as .NET Reactor, Eazfuscator.NET, Babel and Dotfuscator. Turn on renaming plus control-flow obfuscation and string encryption. Renaming alone barely slows an LLM, because it infers what a.b(c) does from the code around it. Control flow and string encryption break the code up and make the model's summaries less reliable.

Godot 4: PCK encryption needs your own templates

From the official Godot docs:

openssl rand -hex 32 > godot.gdkey          # keep this out of git
export SCRIPT_AES256_ENCRYPTION_KEY="$(cat godot.gdkey)"
scons platform=windows target=template_release production=yes

Then, in Project > Export > your preset: point Custom Template at the binary you just built. In the Encryption tab, enable PCK encryption, paste the key, enable Encrypt Index, and add include filters (*.gd, *.tscn, *.tres, *.json). With empty filters, nothing gets encrypted. For CI, set GODOT_SCRIPT_ENCRYPTION_KEY. Official precompiled templates can't decrypt the result. The docs say plainly that the key is stored in the binary, so treat this as a speed bump. Also set Script Export Mode to binary tokens. It isn't encryption, but it costs nothing.

Unreal: encrypt and sign the pak

1. Project Settings > Project > Packaging: Use Pak File / Use Io Store on, Include Debug Files off.
2. Project Settings > Project > Crypto: Generate New Encryption Key, then enable Encrypt Pak INI Files, Encrypt Pak Index and Encrypt UAsset Files. Under Signing, Generate New Signing Key and turn on Enable Pak Signing so modified paks are rejected.
3. Ship a Shipping configuration, not Development, so symbols and console commands stay out.

Two minutes of work. It blocks drag-and-drop asset browsing in FModel. Someone who has done AES key extraction before gets past it in an evening.

Move the logic that matters server-side

Don't put the whole game online. Pick the one thing a clone would need that video can't show:

• Procedural generation or level data: the client asks for the next level and gets JSON back. The generator never ships.
• Balancing tables, odds, AI opponent behavior: for a roulette-style game, the odds curve and the opponent's decision model.
• Narrative branches or dialogue for later chapters.

On Steam you can authenticate requests cheaply: the client calls GetAuthTicketForWebApi("your-service") and your backend checks the ticket with the ISteamUserAuth/AuthenticateUserTicket Web API, so only real playtest accounts get content. A small serverless function and a key-value store will handle a demo's traffic. Set an end date and shut the endpoint off when the demo ends. That's also a clean way to end the demo.

The cost: the demo needs a network connection, and you're now running a service. For a 30-minute demo that's usually acceptable. For the full release, think about it again.

Steam Playtest: the closed, keyed demo Valve already built

Steam Playtest is a free child app ID tied to your main game. Reviews, wishlists and refunds stay separate. Two ways to run it:

A. Signup on your store page (limited signup):

1. Steamworks > your app > Associated Packages & DLC > Create Playtest.
2. Add the required library capsule and community assets, and set the name. You can't change the name after release.
3. Complete the simplified release review (capsules and icons only).
4. Main game > Edit Store Page > Special Settings: enable Playtest signups.
5. Upload your build to the Playtest's depots like any other app.
6. Application > Playtest Settings: grant access in batches. Steam picks randomly from signups, and you can restrict by country.
7. When you're done, set Not Playable, after turning off signups.

B. Keys only (closest to what Alliance Arts is doing): request Standard Release keys for the Playtest app, set it Playable, set Store Visibility to Hidden, and hand keys to people who signed your terms on your own form or Discord. Valve's FAQ says this setup is how to run a playtest where players agree to an NDA. The same FAQ notes that ordinary Playtest signups carry no NDA. Two details to remember: a key that's already been redeemed is not revoked when you mark the Playtest Not Playable, and Reset (irreversible) is how you disable every key and start a new cohort.

Steam Playtest controls who has the binary. It doesn't stop a tester from dumping it. That's why you pair it with the next section.

Watermark every build so a leak points to someone

All testers get the same depot, so watermark at runtime, keyed to the Steam account. Here's a minimal Unity version using Steamworks.NET (SteamManager comes from its sample code):

using Steamworks;
using UnityEngine;
using System.Security.Cryptography;
using System.Text;

public class TesterWatermark : MonoBehaviour
{
    const string Salt = "rotate-per-playtest";   // change per cohort
    string tag = "";

    void Start()
    {
        if (!SteamManager.Initialized) return;
        ulong id = SteamUser.GetSteamID().m_SteamID;
        using var sha = SHA256.Create();
        var h = sha.ComputeHash(Encoding.UTF8.GetBytes(id + Salt));
        tag = System.BitConverter.ToString(h, 0, 4).Replace("-", "") + " " + Application.version;
        // Log id -> tag on your backend at first launch so you can look it up later.
    }

    void OnGUI()
    {
        GUI.color = new Color(1f, 1f, 1f, 0.07f);   // barely visible, survives screen capture
        GUI.Label(new Rect(Screen.width - 240, Screen.height - 26, 230, 22), tag);
    }
}

Leaked footage or a leaked build now carries a short code that maps back to one account. For extra coverage, also:

• Use password-protected beta branches per cohort (press, creators, community) and give each branch a different build ID. That tells you which group leaked, even if someone strips the overlay.
• Hide a cohort ID in data that a clone would copy, such as a balance constant or a tile value that doesn't affect gameplay. If a clone ships with your exact odd value, that's strong evidence it was copied.
• Tell testers the watermark exists. Deterring the leak is most of the value.

Legal and DMCA prep: do it before the demo, not after the clone

• Know what's protected. Copyright covers your code, art, music, text and the specific expression of your game. It doesn't cover the general mechanic ("Russian roulette with drinks"). Close visual copies of expression are fair game for takedowns. Same idea with different art usually isn't.
• Build a dated evidence folder now: git history, dated builds with hashes, your store page's launch date, original art source files (PSD/Blend with layers), trailer upload dates. This is what makes a takedown quick.
• US copyright registration is required before you can sue over a US work (17 U.S.C. §411). It's inexpensive, and registering before infringement unlocks statutory damages. Non-US works like Alliance Arts' don't need it to sue, but registering still helps if you plan to enforce in the US.
• File the trademark for your title. Clones often copy the name too, and trademark complaints are often the fastest takedown route on storefronts.
• Have takedown notices drafted for Steam (Valve's copyright/IP infringement process), itch.io, Google Play and YouTube. On launch day, all you should need to fill in is the infringing URL.
• Put the anti-AI clauses in your playtest terms, like Alliance Arts' Article 10: no decompiling, no AI analysis, no training. It won't stop a determined bad actor, but it turns a leak into a breach of contract with a named, watermarked party, and that's a much stronger position.

What actually works vs. what doesn't

Works:

• Shipping less: a short, #if-stripped slice of the first 20 minutes, not the full game behind a flag.
• Gating access with Steam Playtest keys plus signed terms, then watermarking each account.
• Keeping the hard-to-guess part (generator, odds, AI behavior) on a server.
• Speed: a short gap between demo and launch, and launch-day takedown notices ready to send. Alliance Arts' seven-week gap was the risky part.

Helps a bit (do it anyway because it's cheap): IL2CPP plus stripping, Unreal pak encryption, Godot PCK encryption, an obfuscator.

Doesn't work:

• Asset encryption to stop art theft. Screen capture gets around it.
• Obfuscation as protection for a game whose whole design shows up in one trailer.
• EULA anti-AI clauses on a public demo that nobody signed.
• Hiding the game entirely until launch. Next Fest demos drive wishlists, and a demo you didn't ship gets you none. Alliance Arts had wishlist momentum to spare, and most indies don't.

Our take: for most indie games, a public demo is still the right call. Make it a thin slice with IL2CPP or engine encryption on, keep one critical piece server-side if you can, watermark it, have the paperwork ready, and launch soon after. Go closed and keyed, like Alliance Arts, when your game is mostly visible spectacle that can be cloned from video, and you already have the audience to fill a lottery.

Sources checked 19 October 2026 (KST): Alliance Arts' announcement, playtest guide and participation agreement; GameSpot; Pogwire; IGN on X; Steamworks Playtest docs; Godot PCK encryption docs.

---

← Back to all posts