Teaching Our Games to Think: Neural Networks at RedKnack

Hello and welcome back to Inside RedKnack! Today we want to talk about something we've been quietly cooking up in the background. The more we work on it, the more excited we get, so grab your beverage of choice because this one's kind of a big deal. At least for us.

The Idea

First things first! Games are only as interesting as the decisions being made inside them. Whether that's an NPC choosing whether to run away or stand its ground, or a system silently judging how well a player built something, etc. Those moments of "the game reacted to me" are what stick with players. We wanted more of that. We wanted something organic!

The problem is that traditional game logic scales reeaalllyy badly with complexity. You start with a simple

if health < 30% then flee

and it feels fine. Then you want the enemy to also consider whether they're outnumbered, whether the player has a ranged weapon, whether there's a wall nearby. And suddenly you've got a nested conditional nightmare that breaks in ways you never anticipated, and fixing one behavior accidentally breaks three others. In the end it can look like this:

if health < 0.3:

    if enemies_nearby > 1:

        flee()

    else:

        if player_has_ranged_weapon:

            if wall_nearby:

                take_cover()

            else:

                flee()

        else:

            fight()

In short: Code you should not write like that.

We've been down that road, like most developers have. And at some point you start wondering if there's a better way to describe what good looks like rather than every step to get there.

That's exactly the gap neural networks fill. Instead of writing the rules, you show the system examples of good outcomes and let it figure out the pattern. It sounds almost too simple when you put it like that, but the results are genuinely different in ways that are hard to describe until you see them running in an actual game.

But wait! Aren't Those Huge?

Yeah, this is probably the first thing most people think, and honestly it's a fair assumption so far. When you hear "neural network" you probably picture something that needs a server farm and six months of training data to do anything useful. And for the big general-purpose models, that's true.

But here's the thing: those models are trying to understand everything, literally. Language, images, code, recipes, legal documents, the works. Our networks don't need to do any of that. They need to answer one very specific question, reliably, thousands of times per second. Btw: Tests actually showed us that it takes circa 0.049ms for an average DNN-Model to make a decision.

"Should this NPC attack or retreat right now?"

"How well does this terrarium layout work for its inhabitants?"

"Is this challenge level appropriate for this player at this moment?"

For questions like these, you don't need a model the size of a city block. You need something lean , and focused, and fast. And it turns out you can get surprisingly good answers from a network that fits in a fraction of a kilobyte. We have models running right now that make color-recognition decisions in under a millisecond and weigh less than 7kb on disk. That's, funnily enough, smaller than most button icons in a UI.

The key insight is (suprise, suprise) scope. A network that knows everything about one small domain is, for that domain, just as useful as one that knows a little about everything. And it's a thousand times cheaper to build, train and ship.

The DNNM

So we built our own format around exactly that idea: the DNNM, short for Dynamic Neural Network Model.

The "Dynamic" part is maybe the most important bit to explain, because it doesn't mean what you might expect. It's not dynamic in the sense of learning while the game runs or changing in real time. It's dynamic in the sense that these models are lightweight enough to actually move around. You can train a new version, drop it into a game update, and ship it to players without them ever knowing something changed under the hood. You can have different models for different game modes. You can iterate fast without rebuilding your entire codebase around it. That kind of flexibility is what the name is really about.

The pipeline itself is pretty clean and straight forward. You write a JSON file that describes everything: the structure of the network, what inputs it expects, what outputs it produces, and the training data. Then you run that through our compiler, and out comes a

.dnnm

file, a compact binary format that Godot can load directly and run without any external dependencies... Besides our code that runs that models.

The JSON side is actually quite readable. You define your input features by name and value range, define your output classes, then hand it training samples with expected results. The compiler handles the rest: normalization, training, weight optimization, and packaging everything into the binary. If something doesn't train well, you adjust your samples or tweak the network size, and recompile. The whole loop from idea to working model can take minutes for simple tasks.

A color recognition model, for example, takes a handful of RGB values as input and outputs a color category. Trained, compiled, ready to use in Godot: 7kb. It's a bit of a party trick at this point but it illustrates the idea nicely. The format is designed to stay out of your way.

The deeper technical details we'll save for another post. :3

So What Are We Actually Using Them For?

This is where it gets fun. A few things are already taking shape, and a few more are in the "we're seriously thinking about this" pile.

RPG Characters That Actually Act Like Themselves-thingy

The most obvious application is NPC behavior, and it's the one we've been prototyping the longest. The goal isn't to replace all game logic with networks. It's to replace the parts that traditionally turn into unmaintainable messes: personality-driven decisions, context-sensitive reactions, the stuff that's really hard to express cleanly as if-statements.

Imagine a merchant NPC whose willingness to negotiate depends on a combination of factors: how much gold the player is carrying, how rare the item is, what time of day it is, whether the player has helped them before, whether there's been recent trouble in town. You could write that as a decision tree. It would be enormous. And it would never quite feel right, because every branch is a hard edge where the real answer is a gradient.

With a small trained model, you define what "willing to negotiate" looks like across a spread of example situations, and the network learns the in-between. The merchant starts behaving in ways that feel consistent without being robotic. That's the goal. And: It needs to be FAST AF!

The results we've been getting are already weird and interesting in the best way. Behaviors emerge that we didn't explicitly program. Sometimes that's a bug. Mostly it's a feature. But actually they make sense in a way you cannot really describe technically, but more... emotionally.

Rating Systems With Actual Taste

This one is something we're actively exploring for Snail Keeper. Right now, evaluating a terrarium is mostly a matter of counting: do you have enough plants, enough hides, enough moisture sources? That works as a baseline but it doesn't capture the difference between a terrarium that's technically correct and one that's actually good.

A neural network trained on good and bad terrarium examples could evaluate the combination of what's in there. A mossy corner with appropriate ground cover and a hide nearby reads differently than the same objects scattered randomly. The layout matters. The coherence matters. Whether things make sense together matters.

We're not promising this will make it into Snail Keeper, we're still figuring out whether the training data side is feasible and how to make it feel fair to players. But it's a direction we find really compelling, and the technical side is already proven out. The question is design, not capability. Ah, and time, of course! We want that game to be done!

And More

The honest answer is that once you have a format like this working cleanly inside your engine, you start seeing potential applications everywhere. Dynamic difficulty that models what's actually challenging for a specific player's playstyle, not just their win rate (okay, that one too). Procedural content filters that have been trained on what "feels right" rather than relying entirely on hand-tuned parameters. Small evaluator models that can tell a level generator whether a room layout is interesting before a player ever sees it.

Some of these are distant. Some are closer than you'd think. All of them are on the table. Right now, btw.

So, Why Now?

The tooling finally caught up to the dream. For a long time this felt like something only big studios with dedicated ML teams could pull off. But with the right approach, purpose-built scope-limited networks trained on curated game data, it's absolutely within reach for an indie studio. We've done a lot of R&D behind the scenes, built our own compilation pipeline, and we think we've cracked a way to make this practical.

It's not magic. It's math. Very compact, very fast, very cool math.

What's Next?

We're not ready to show everything just yet. There's still integration work to do, and we want to make sure it actually feels right in-game before we start making big claims. But we wanted to share the direction we're heading because we think it fundamentally changes what kinds of games we can make. By far.

Keep an eye on this space. There will be more to show, and probably more to play, before too long.

Until next time! 🐌

← Back to overview