Godot on Nibbleblog

Glass Bead

Mon, 01 Jan 0001 00:00:00 +0000

A daily word-association game. You get eight words in a circle and have to connect them in the right order. Wrong guesses and hints add time to your score.

The frontend is plain JavaScript. The backend handles games and leaderboards in ASP.NET Core, with Azure Table Storage. You can also sign in with Bluesky to compare scores.

Built with: .NET 8, JavaScript, Azure Table Storage.

Play Glass Bead

Does it Spread

Mon, 01 Jan 0001 00:00:00 +0000

A short point-and-click puzzle game made for Pirate Software Game Jam 14. I put it together in about eleven hours.

Made with Godot 4.2, Krita, Paint.NET, LMMS and Audacity.

Download on itch.io

Seasons

Mon, 01 Jan 0001 00:00:00 +0000

A short adventure about travelling between parallel timelines to solve puzzles. Made for the Summer Fediverse Jam in 2023.

It’s a Godot game, with a Windows download on itch.io.

Download on itch.io · Source on GitHub

Creddy

Mon, 01 Jan 0001 00:00:00 +0000

A browser app for keeping track of store credit, shared spending, cards and cashback rules.

The PWA is built in Blazor WebAssembly. Programs can be kept in browser storage or use a Google Sheets source. The cloud-connected side is still a work in progress.

Built with: C#, .NET 10, Blazor WebAssembly.

Open Creddy

ASDF Tools

Mon, 01 Jan 0001 00:00:00 +0000

A bunch of small web tools that don’t really need a home of their own.

There’s a countdown timer, QR-code generator, graph visualizer, connection-string converter and a few others. Most are standalone HTML, CSS and JavaScript pages.

Browse ASDF Tools

Dialogative

Mon, 01 Jan 0001 00:00:00 +0000

A .NET library for writing dialogue trees in YAML. It handles branching options, conditions and updates to game state. Expressions use Power Fx.

It’s on NuGet, and the repository has examples.

Built with: C#, .NET 10, YAML, Power Fx.

Source and examples · NuGet package

SpriteCombiner

Mon, 01 Jan 0001 00:00:00 +0000

A small command-line tool for combining individual images into a sprite sheet. The source images are named with their X and Y positions, and the tool assembles them into one image.

There’s a Windows download on itch.io, along with the source on GitHub.

Built with: C#, .NET.

Download on itch.io · Source on GitHub

Spirit Games

Mon, 01 Jan 0001 00:00:00 +0000

A website where I keep my game-development projects. It links to games and tools, the Nibblebit Challenge and Spawn Point, a beginner Godot webinar.

The site is plain HTML, CSS and JavaScript.

Visit Spirit Games

Socials

Tue, 27 Oct 2026 00:00:00 +0000

Find me online

I’m Yasen Dinkov, also known as nibblebit. These are the public accounts and projects I link to from my own sites.

Threads: profile URL to be added after verification.

For game-development projects and experiments, visit spirit.games . For more about me, see About me . Spirit Games also has a socials page .

The Clone Wars: Why Your Best Anti-Clone Tool Might Be Marketing

Thu, 04 Jun 2026 12:00:00 +0200

At GodotCon Amsterdam 2026, I gave a talk called The Clone Wars: Defending Godot Games From Reupload Scams. It was about something nobody wants to put on their game-dev roadmap: people stealing your game and pretending it’s theirs.

Godot is open, accessible, and makes it wonderfully easy to get games into people’s hands. Unfortunately, exporting a game also puts a lot of its guts into other people’s hands. Some of those people are curious modders or researchers. Others are interested in repackaging somebody else’s work, publishing it under a new name, or tricking players into buying the wrong game.

The talk was partly about thinking like a security engineer. But the point I really wanted developers to take away was less technical:

Protecting your game’s identity often matters more than protecting its binaries.

Since the talk, developments in AI-assisted reverse engineering have only made that distinction more important.

You can’t protect what you distribute

When we think about securing a game, our instinct is to reach for technical barriers: encrypted assets, obfuscated scripts, license checks, anti-tampering systems. If we can make the build sufficiently difficult to take apart, surely that’s a win?

Sometimes it is. Those techniques introduce friction, and friction can discourage opportunistic abuse. But the player controls the computer running the game. Somewhere, the game has to load its assets, execute its logic, and render its output. A sufficiently motivated person can observe and inspect those things.

Consider an encrypted asset pack. It’s useful for discouraging casual extraction, but your game still needs to decrypt the assets to use them. If the threat is somebody willing to investigate the running process, encryption isn’t an absolute barrier. It’s one more cost imposed on the attacker.

That is a perfectly respectable thing to do, provided we remember the difference between making copying harder and making copying impossible.

And there’s an uncomfortable twist: the cost of understanding an unfamiliar piece of software is changing.

AI has changed the economics of reverse engineering

When I prepared the original talk, using AI to reverse engineer an entire game was possible in principle, but often impractical or prohibitively expensive. That is no longer a safe assumption.

By October 2026, agentic tools can connect coding models to established reverse-engineering systems such as Ghidra or IDA, helping inspect binaries, follow function calls, and test hypotheses about program behaviour. InfoQ’s coverage of Reverse Engineer Anything is one example of this shift.

Let’s not oversell it. An AI model cannot reliably swallow any random executable and spit out a flawless, legally unencumbered recreation. Reconstructing a large game still takes effort, verification, and specialist knowledge.

But the direction is clear: tasks that once required hours of tedious manual investigation are becoming easier to automate or accelerate. That lowers the cost of making an imitation, even when the imitation is imperfect.

If your protection strategy depends on somebody finding your implementation too difficult or expensive to understand, it may have a shorter shelf life than you think.

The case for an authoritative server

One strong response is to stop shipping everything that makes your game valuable.

If important game logic, persistent state, or decisions live on a server you operate, an attacker can’t simply extract those implementations from the downloadable client. For a multiplayer game, a server-authoritative design also helps prevent clients from inventing their own version of the truth.

Godot provides high-level multiplayer building blocks that can support this kind of architecture. The security comes from the decisions your server actually controls and validates, not merely from having a network connection.

There are trade-offs. Servers cost money and require maintenance. Connectivity introduces latency, operational work, and a dependency on the developer keeping the service alive. For a single-player indie game, always-online DRM can end up being a worse experience for legitimate players than for the people you’re trying to stop.

And even an authoritative server doesn’t stop somebody from looking at your game, learning its visible rules, and building a similar experience independently.

So yes: keeping genuinely sensitive mechanics on an authoritative server is a powerful tool where that architecture fits the game. It isn’t a magic anti-clone button.

Make something recognisable, not merely difficult to copy

Here’s the more interesting question: what makes your game unmistakably yours?

A distinctive visual language. A particular rhythm to its mechanics. Characters, humor, writing, sound, and a world that people remember. None of these elements is individually immune to imitation. Game mechanics aren’t automatically protected just because they’re clever, and an artistic style alone doesn’t guarantee legal exclusivity.

But a coherent creative identity has an advantage that obfuscated code doesn’t: players can recognise it.

Imagine two games with superficially similar mechanics. One is a pile of features; the other has a recognisable world, art direction, voice, and relationship with its players. A copycat may be able to reproduce a feature, but reproducing the whole identity convincingly is a different challenge.

There’s a production advantage too. Ideally you develop a visual language and design vocabulary that’s hard for outsiders to imitate convincingly, yet easy for your own team to keep extending. Good tools, reusable assets, and clear creative direction let the original evolve faster and more consistently.

In other words: don’t just make something hard to steal. Make something you’re uniquely well placed to keep making.

The boring stuff is surprisingly effective

Developers love technical puzzles. Marketing, community building, store listings, publication records, and trademark research? A considerably tougher sell.

Unfortunately, that less glamorous work is often better aligned with the actual problem of a reupload scam.

Suppose somebody republishes your build under a different name. Encryption might not help once the build has escaped. But an established official site, recognisable branding, public release history, and direct channels to your players all make it easier to identify the original and report an impersonator.

There are practical things worth doing before you spend months designing exotic anti-tampering measures:

Keep a clear official website and link to your legitimate store pages.
Build relationships with players through communities, newsletters, or other channels you control.
Preserve release dates, source files, artwork, and records of who created what.
Check names and marks before launch, and understand which copyright or trademark protections may apply.
Learn how the platforms you distribute on handle copyright complaints and impersonation reports.

The World Intellectual Property Organization’s guide to IP in video games is a useful introduction to the distinctions between copyright, trademarks, and other rights. Actual protection and enforcement depend on the jurisdiction and facts; none of this replaces legal advice.

None of these activities makes the executable impossible to copy. What they do is make it harder for somebody else to pass their copy off as the original.

That’s a different problem, and it’s the one many reupload scams actually exploit.

Protect against the threat you actually face

Before adding a technical safeguard, ask which attack you’re defending against.

Someone redistributing your original build? Extracting assets? Impersonating your studio? Recreating visible mechanics? Cheating in an online game? Those aren’t interchangeable threats, and their mitigations shouldn’t be interchangeable either.

For a multiplayer economy, server authority and validation may be essential. For an asset-theft problem, keeping evidence and making platform reports may matter more. For a counterfeit store listing, a recognisable brand and clear official distribution channels are especially valuable.

The right answer is usually a mix of proportionate technical friction, sensible architecture, and good old-fashioned creative and commercial work.

There are lessons here from enterprise security, but I promise I didn’t come to a game-development conference to sell anyone an ISO audit.

Make the original matter

AI is making software easier to inspect, understand, and reproduce. I don’t think that means security engineering is pointless. It means we should stop expecting technical obstacles alone to carry the full weight of protecting our work.

Use them where they address a real threat. Put valuable decisions on a server when that fits the game. But also invest in the parts that give players a reason to seek out your version rather than an imitation.

Make your game distinctive. Make its creator identifiable. Make the legitimate version easy to find. And make it possible to keep building on what makes it yours.

The strongest defence against somebody copying your game might be giving people a reason to care about the original.

This article expands on my GodotCon Amsterdam talk with reflections added in October 2026, particularly on AI-assisted reverse engineering.

Watch The Clone Wars: Defending Godot Games From Reupload Scams — GodotCon Amsterdam 2026 . The recording was published on June 3, 2026.