DEV Community: SteamPixel

Text adventure: Alan Turing’s Ghost Was Not Ready for a Probabilistic Afterlife

SteamPixel — Fri, 19 Jun 2026 19:29:33 +0000

This is a submission for the June Solstice Game Jam

What I Built

I built a short browser based text adventure with wanderer-flow.de, the flow builder I created for interactive chat experiences.

In the game, the solstice has stopped working and ancient writings declare that a chosen one must restore it. The player steps into that role, chooses a weapon, and enters a small absurd adventure full of strange dialogue and logic puzzles.

A central part of the game is an encounter with Alan Turing’s ghost, who appears as an NPC guarding the logical gates. He is deeply irritated that the afterlife has turned out to be probabilistic instead of deterministic. To progress, the player has to interact with him in chat, figure out how to get the right response, and gain access to the gates.

The final challenge is a sequence of simple but thematic logic puzzles where the player must correctly activate OR, AND, and XOR gates to bring the machine back online and save the solstice. If they succeed, they receive a printable certificate.

The game fits the challenge theme in several ways. It is directly about the solstice, it plays with light, restoration, and turning points, and it also connects to Pride and Alan Turing through the narrative and the player’s interactions. I wanted the whole thing to feel playful, slightly absurd, and unmistakably computer science flavored.

One important note is that the current build only runs in Chrome on suitable hardware because it relies on a local on device LLM (Will be installed automatically when available).

Video Demo

I recorded a short demo showing the full flow of the game, including weapon selection, the conversation with Alan Turing’s ghost, and the logic gate puzzles.

https://wanderer-flow.de/videos/alan_turing.webm

Code

The project was built with wanderer-flow.de.

Playable in browser: https://wanderer-flow.de/flows/Dev-to-Challence-Alan-Turing-s-Ghost-Was-Not-Ready-for-a-Probabilistic-Afterlife-ry0kzcbn8vn0vy9nijhgs0be5fpzik5w
Open in flow editor: https://wanderer-flow.de/builder?flowUrl=https://hub.wanderer-flow.de/flows/ry0kzcbn8vn0vy9nijhgs0be5fpzik5w
Source code or flow export: https://hub.wanderer-flow.de/flows/ry0kzcbn8vn0vy9nijhgs0be5fpzik5w

How I Built It

I built the game as a graph based conversational flow in wanderer-flow.de.

Wanderer is based on Reactive Graph Sequencing, a system I designed for state driven interactive flows. Instead of executing a fixed sequence once, the graph continuously re sequences itself when state changes. That makes it a good fit for chat based experiences where dialogue, branching, backtracking, and user decisions need to remain flexible and reactive.

I liked using a local LLM as an NPC rather than as a hidden implementation detail. In this game, the model becomes part of the world. Alan Turing’s ghost is not just flavor text pasted into a static dialogue tree. He is presented as a character that the player must engage with in order to advance.

From a design perspective, I deliberately kept the scope tight. I wanted something that was easy to understand, quick to play, and memorable because of tone rather than size. The result is a compact interactive piece that combines narrative, puzzle logic, and local AI in a way that feels playful without becoming over engineered.

For more technical background on the system behind Wanderer, I wrote about it here:

https://wanderer-flow.de/blog

Prize Category

I am submitting this project for Best Ode to Alan Turing and Best Google AI Usage.

Best Ode to Alan Turing is a natural fit because Alan Turing is not just referenced in the title or theme. He appears in the game as a central NPC and guardian of the logical gates. The game also draws directly on ideas closely associated with his legacy, including computation, logic, truth, and artificial intelligence.

Best Google AI Usage also applies because the game uses a local Google LLM in Chrome at runtime. The model is not just a development aid behind the scenes. It appears directly inside the game as an NPC that the player must interact with in order to progress. That makes the AI part of both the fiction and the mechanics of the experience.

A chatbot that helps you fill out a form

SteamPixel — Thu, 18 Jun 2026 18:34:05 +0000

Chatbots usually block when they offer buttons, forms, or input fields. That's always annoyed me. I fixed that and built a working demo. This bot can show you a form and simultaneously guide you on how to fill in certain fields or where to find the information. Furthermore, it works locally first in the browser.

You can find the demo and a short blog post here: https://wanderer-flow.de/flows/a-chatbot-that-helps-you-fill-out-a-form-4klu6pqihjd5403a98ugvrluqmkunuvw

I'm done. Flow editors are broken. And you all know it.

SteamPixel — Mon, 18 May 2026 12:42:58 +0000

I spent the last years trying to make flow editors work. For chatbots. For forms. For LLM orchestration. Every single time I end up in the same place: buried in nested menus, drowning in node configurations, writing inline code in a tool that promised me "no-code."

I'm done making excuses for these tools. They are broken. Not the UI. Not the docs. The foundation.

So you open Botpress. Or Voiceflow. Or n8n. And within five minutes you're staring at a canvas full of nodes, nested menus, inline code editors, and condition builders that feel like they need their own documentation. You wanted to build a chatbot. Now you're studying a tool.

And it's not just chatbots. Complex form flows, onboarding wizards, LLM orchestration. Every single flow builder out there follows the same pattern: drag a node, click on it, get buried in configuration. Add a condition? Another menu. Need an API call? Another node, another config panel. Want to change something? Good luck finding where that logic actually lives.

This is not normal. And we should stop pretending it is.

The code editor test

Let me ask you something. Have you ever clicked on a variable name in your code editor and suddenly 10 nested submenus popped open? With configuration options, conditions, and inline logic attached to that single variable?

No? Of course not. That would be insane. No developer would accept that. You'd close the editor and never look back.

So why do we accept exactly this in flow builders? Every node is a little universe of hidden complexity. Click on it, and you're three menus deep before you even understand what it does. That's not a powerful tool. That's a broken abstraction.

If a flow editor requires a course before you can use it, it's not a tool. It's a problem.

The real issue is deeper than UI

The frustrating thing is: most people blame the UI. "It just needs a better interface." "A cleaner design." "Fewer options."

No. The UI is a symptom. The actual problem is the underlying architecture.

Think about it. An edge between two nodes is already a condition. It says: if this, then that. That's temporal logic. That's a rule. It's right there, visible on the canvas.

So why does every flow builder then bury another layer of conditions inside the nodes? You connect two nodes with an edge, and then you click on the node and configure more conditions in a nested menu. Conditions hidden inside a box. Invisible from the outside. Black boxes everywhere.

And it gets worse. Most flow builders love super-nodes. Take a typical "Choice Node" or "Question Node." It contains the question, the answer options, the branching logic, sometimes even validation. All packed into one node. That's a conceptual breach. The answer options are not part of the graph. They are buried inside a single node, invisible to the structure, unreachable by edge logic.

What if each answer option was its own node? Connected by edges that already carry the logic? Then your entire decision tree would be visible on the canvas. No hidden menus. No black boxes. The graph is the logic. This applies to every complex node type out there. The moment a node contains structure that should live in the graph, you've lost the point of having a graph in the first place.

And there is another problem: Most flow builders are event-driven at their core. Something happens, a trigger fires, a sequence runs top to bottom, done. That model has no real concept of state. It doesn't know where you are. It doesn't adapt when things change. So every edge case, every branch, every "what if the user goes back" scenario has to be manually wired and configured inside the nodes. The architecture can't handle the logic on a structural level, so it dumps it on you, hidden behind click after click after click.

What if the graph could think for itself?

Imagine a different foundation. Instead of "event happens, sequence runs," the graph itself holds the state. Every node knows if it's alive or dead. Every connection between nodes has a clear semantic meaning: this path must be taken, this path may be taken, this path must not be taken.

Three edge types. Must. May. Not. That's it. And that's enough. These three types can express every logical gate visually on the canvas. AND, OR, NOT, XOR. No configuration panels. No inline code. Just edges you can see.

When state changes, the graph re-sequences itself. You don't manually wire fallback paths. You don't write inline conditions. The structure is the logic. Change a decision and entire branches die while others come alive. No custom code. No nested menus. The graph adapts because it was designed to.

And before someone asks: no, re-sequencing doesn't mean the entire graph is traversed every time. At the start, only the entry node is active. As the user progresses, the active portion grows, but it stabilizes at a fraction of the total graph. When a user backtracks, the old branch dies and a new one activates. The traversal shifts, it doesn't accumulate. The more complex your graph, the more branches are dead at any given moment. Complexity makes it more efficient, not less.

This concept is called Reactive Graph Sequencing. And I built a flow editor based on it.

Wanderer

Wanderer is an open source flow editor built on RGS. No nested menus. No inline code. No configuration hell. The graph structure itself defines the logic.

If you want to understand the technical foundation in detail, I wrote about it here: Reactive Graph Sequencing: The Technology Behind Wanderer

Want to see demos? Check this out

I'm not saying this is the only way. But I am saying that the current generation of flow builders is built on a broken foundation. And we should stop blaming ourselves for struggling with tools that were never designed to be intuitive.

What do you think? Is the architecture the real problem, or am I just bad at reading nested menus?

Title image: https://pixabay.com/de/illustrations/ai-generiert-scrapyard-wagen-8241457/

Your Chatbot Ignores 2 Out of 3 Requests. Here's a Structural Fix.

SteamPixel — Wed, 13 May 2026 07:55:24 +0000

You know the drill. You type something like:

"I want to buy moisturizer, check the status of my last order, and I need your address."

The chatbot picks one of those (usually the first) and the rest just vanish. You're stuck repeating yourself, clicking through menus again, or giving up entirely.

This isn't a prompting problem. It's an architectural one.

Why most chatbot builders fail at this

Most builders (Dialogflow, Voiceflow, Botpress, you name it) route conversations through tree-like or linear flow structures. One input → one intent → one path. That model breaks the moment a user has more than one thing to say.

Some builders try to work around this by looping back after each task, but that leads to fragile state management and spaghetti flows. The fundamental structure doesn't support it.

I've written more about why conversations don't fit into trees here and why they also don't belong in relational databases here, if you want the deeper reasoning.

The fix: serialize intents before routing

The approach I built into Wanderer works like this:

User sends a message with multiple requests
A GPT call extracts and splits the intents into a structured list
Each intent gets queued as a separate task
The graph executes them one by one, each in its own context
Each task knows the full picture — it can say "Let me handle the first of your 3 requests" and "All done — that was the last one"

This is possible because Wanderer uses a reactive graph architecture instead of rigid trees. I call it Reactive Graph Sequencing — nodes react to state changes in the graph rather than following a fixed path. That means dynamically queuing 1, 3, or 7 tasks at runtime isn't a hack, it's how the system naturally works.

Before & after

Without multi-intent serialization:

User: "I want to buy moisturizer, check the status of my last order, and I need your address."
Bot: "Sure, I can help with the moisturizer! Here is a selection.
"
(The other two requests? Gone.)

With serialization:

User: "I want to buy moisturizer, check the status of my last order, and I need your address."
Bot: "Got it — 3 things! Let's start with the address..."
(Then moves on to order status, then moisturizer — automatically.)

Try it yourself

I built a working example you can test right now — no signup, no account needed:

👉 Open the Multi-Intent Demo

There's a chat embedded on the page. Try throwing multiple requests at it and see what happens.

Why this matters

This isn't just a nice-to-have. If your chatbot handles support or e-commerce, users constantly send multi-intent messages. Dropping those silently means more repeated messages, more frustration, more drop-offs, and ultimately more tickets landing on a human agent's desk.

I'm building Wanderer as a new kind of chatbot builder based on reactive graphs. If the architecture angle interests you, I've written a whole series on the underlying concepts on the Wanderer blog.

Visual Logic Without Code - Can This Change the Way We Build Flow-Based Systems?

SteamPixel — Mon, 07 Jul 2025 12:08:44 +0000

What if logic wasn’t hidden behind blocks – but was the blocks?

With Wanderer, I’ve built a free visual flow builder where the logic is the structure.

No function bodies. No hidden scripts. Just nodes and edges - and a graph that executes itself in real time, right in your browser.

You can build things like AND, OR, XOR, and NOT gates - all 100% no-code.

🧠 The twist?
Edges are the logic. They define behavior, and the whole system reacts live.

🎯 Try the interactive logic gate demos

It’s for builders, educators, and anyone curious about what visual programming can become when it’s truly visual.

Let me know what you think – and what you'd build with it.

— Chris

I built a reactive no-code flow engine that runs entirely in your browser, no login, no backend

SteamPixel — Sat, 05 Jul 2025 11:20:25 +0000

Hey Dev.to 👋

I’ve been working on a side project that started from a simple frustration:

I just wanted to build a chatbot

but every tool forced me to write complex code, bury logic inside nodes, or sign up for yet another cloud service.

So I built my own.

Introducing Wanderer Flow – a reactive, visual, and open flow engine that runs 100% in the browser.
No backend. No login. Just open a tab and start building.

What makes it different?

Flow-based: You build logic by connecting nodes and edges, not writing scripts.
Reactive: The flow is constantly traversed, like a living system.
No server: It’s fully client-side. Nothing gets uploaded. You own your data and logic.
Fork & share: Every flow can be exported as JSON or shared via URL.
GPT support: You can add GPT nodes, define your own prompts, and react to responses in the graph.
Instant preview: The flow runs while you’re building. You see your changes live.

Example use cases

Chatbots that adapt to changing context (like weather or inputs)
Interactive decision trees
Lightweight, offline-ready AI agents
Guided flows for websites or tools — without backend dependencies

Tech stack

Nuxt3 / Vue / Tailwind/ Vanilla JS / TypeScript
Open source (soon on Codeberg)
Designed to run on the edge, Raspberry Pi, or inside any CMS

Try it now

Go to: wanderer-flow.de

No signup required. Try the builder or fork one of the included examples.

I’d love your feedback

What’s clear or confusing?
What would make it more useful for you?
Would you use this for anything?

Thanks for reading!

Chris