DEV Community: Steven Wallace

Cozy Jam Spring 2026 Retrospective

Steven Wallace — Mon, 20 Apr 2026 07:06:55 +0000

During the Cozy Jam Spring 2026, my team and I created Norwegian Spring, a cozy 3D bicycle game made in Unity. You ride through a peaceful and scenic Norwegian landscape with forests, piers, and Norwegian-style homes. Because this was a cozy game jam, we wanted to make something that feels calm and just engaging enough to keep the player interested.

We were a four-person team: programmer/level designer, 3D artist, UI designer, and orchestrator. This is our retrospective.

What We Built

The core loop is a bike on auto-pilot that follows a waypoint system through the level. The player can nudge left and right with the keyboard, press a speed boost button when it appears, ring the bell, and choose which path to take at branch points. Birds flock overhead, flags wave in the wind, and Norwegian-style houses line the roads in randomized color variants.

The game jam had a limitation of making the game a seamless loop. The game needed to loop back to the start with no break in the gameplay.

Technical highlights

Waypoint system with road-width detection so waypoints span the full road rather than a single point
Seamless gameplay where the player continues along interconnected paths with no pause in the action
Living Birds asset integration for ambient flocking
Cloth simulation on flags for wind effect

The Biggest Challenge: Cozy vs. Engaging

Making a cozy game is harder than it sounds. Cozy means slow, calm, low-pressure, but that can easily cross into boring. We tried to balance the calmness with the speed boost mechanic and branching paths, giving players moments of agency without breaking the relaxed tone.

In hindsight, the fast-moving player character was our biggest design mistake. When your player moves quickly through a 3D environment, they fly past everything before they can appreciate it. You need a lot more content to fill a level that the player travels through quickly.

It helped me understand why we still don't have GTA 6.

We could have just made the bike slower, but any slower and it would feel too slow paced. Without enough movement power, the bike would also not be able to make it up hills.

For a jam with limited time, a slower-paced experience would have let us build a smaller, more polished world.

What Went Well

Shipping a full working 3D game with four people in two weeks is not easy, but we did it. Every team member contributed which helped us be able to combine programming, art, music, and design.
Our 3D artist delivered building meshes with full PBR texture sets (BaseColor, Normal, ARM maps) across multiple color variants.
Going into this jam, 3D level design was a weak point for me. I felt slow at it, but by the end I noticed that I had developed some muscle memory for things like placing terrain, implementing materials, and positioning assets.
WebGL debugging. We hit a bug where the bike had no drive force at all despite the code looking correct. After systematic debugging by adding logs to trace verticalInput, checking for null references, and verifying script execution order, we found that a leftover BikeControlsExample script was overwriting the auto-controller's input every frame with keyboard input (which was zero). The script seemed to take priority when we switched the build to WebGL. It helped me learn best practices when debugging Unity.

Lessons Learned

For a jam, slow players down. A fast player needs a bigger world. A slow player can appreciate a smaller, more detailed one.
WebGL is not the same as a Windows/MacOS build. Physics, shaders, and asset sizes all behave differently. Budget time for platform-specific debugging if you're targeting WebGL.
PBR texture sets are worth it. Even with basic lighting, proper BaseColor/Normal/ARM maps make assets look substantially better with minimal extra work in Unity.
The level designer and artist should have strong communication. I wasn't sure exactly what assets the 3D artist was going to make so it was tough to start designing. That sort of thing should be decided toward the start of the jam.

Play It

Norwegian Spring is playable here on itch.io. Give it a try, relax in the forest in Norway that we made, and let us know what you think!

Building MIRROR: A Luxury AI Fashion Try-On App with Perfect Corp APIs

Steven Wallace — Sat, 07 Mar 2026 04:31:20 +0000

Building MIRROR: A Luxury AI Fashion Try-On App

I built MIRROR for DeveloperWeek 2026, which is a luxury fashion e-commerce prototype that lets users virtually try on clothing, shoes, bags, and earrings using AI. Here's how it works and what I learned building it.

View the repo here

What Is MIRROR?

MIRROR is a full-stack web app that combines a luxury-styled product browsing experience with AI-powered virtual try-on. A user can browse products, open a try-on modal, upload a photo of themselves, see an AI-generated preview of them wearing the item, and add it to their cart. All of this can be done in the same page flow.

The app covers four product categories: clothing, shoes, bags, and earrings.

Each category has its own AI endpoint and unique payload structure.

MIRROR Home page (Photo by Cottonbro Studio)

Tech Stack

Frontend: React, React Router, Context API, custom CSS (no UI framework)
Backend: Node.js + Express
AI: Perfect Corp S2S (Server-to-Server) APIs
Photo persistence: localStorage (up to 10 saved user photos)
Cart: localStorage with quantity aggregation

Architecture

The key architectural decision was keeping the frontend completely decoupled from Perfect Corp. The React app never calls Perfect Corp directly. All AI requests go through the Express backend.

Client (React) → POST /api/tryon → Express Server → Perfect Corp S2S API

This matters because Perfect Corp's APIs require publicly accessible URLs for both the user photo and the product reference image. The server handles saving the uploaded user photo to disk and constructing a public URL via ngrok.

Dynamic Endpoint Routing by Product Type

One of the more interesting backend problems was that Perfect Corp has different endpoints for each product category, and each one expects a different payload shape. I solved this with a clean switch-based config lookup:

function getPerfectConfig(productType) {
  switch (String(productType || "").toLowerCase()) {
    case "cloth":
      return { startUrl: "https://yce-api-01.makeupar.com/s2s/v2.0/task/cloth", ... };
    case "earrings":
      return { startUrl: "https://yce-api-01.makeupar.com/s2s/v2.0/task/2d-vto/earring", ... };
    case "shoes":
      return { startUrl: "https://yce-api-01.makeupar.com/s2s/v2.0/task/shoes", ... };
    case "bag":
      return { startUrl: "https://yce-api-01.makeupar.com/s2s/v2.0/task/bag", ... };
  }
}

Then buildPayload() constructs the right request body for each type. Clothing needs garment_category and change_shoes. Shoes and bags need a gender field. Earrings are the most complex. They require ref_file_urls (array), source_info, and object_infos.

MIRROR Item page (Photo by Cottonbro Studio)

Task Polling Pattern

The Perfect Corp API is asynchronous. You POST to start a task, get back a task_id, then poll until task_status === success. I built a reusable poller:

async function pollPerfect({ pollBaseUrl, token, taskId, intervalMs = 2000, maxAttempts = 120 }) {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    const { json } = await httpRequest("GET", `${pollBaseUrl}/${taskId}`, { headers });

    const taskStatus = json?.data?.task_status || null;
    if (taskStatus === "success") return json;
    if (taskStatus === "error") throw new Error("Task failed");

    await sleep(intervalMs);
  }
  throw new Error("Max attempts exceeded while polling");
}

This polls every 2 seconds, up to 120 attempts (4 minutes). In practice, results come back in a few seconds.

Photo Upload Flow

On the frontend, the TryOnModal component handles a few photo states:

New upload: file input → URL.createObjectURL() for instant preview
Save to My Photos: FileReader converts to base64 → saved to localStorage (max 10 photos)
Reuse saved photo: dropdown select from localStorage
When the user clicks Try It On, the selected photo's data URL gets sent to the backend as part of the POST body. The server decodes the base64, writes it to /uploads, and constructs a public URL for Perfect Corp to fetch.

function saveDataUrlToUploads(dataUrl, filenameBase, req) {
  const match = dataUrl.match(/^data:(image\/[a-zA-Z0-9.+-]+);base64,(.+)$/);
  // ... parse mime + extension
  fs.writeFileSync(filepath, Buffer.from(base64, "base64"));
  return makePublicUrl(`/uploads/${filename}`, req);
}

Data-Driven Products

Every product is defined in a single products.json file. One reusable ProductPage component handles all of them. Each product carries the metadata the try-on flow needs:

"id": 1,
    "title": "Bright Red Pumps",
    "price": 75,
    "tag": "New Season",
    "image": "/images/products/red-pumps.jpg",
    "type": "shoes",
    "gender": "female",
    "garment_category": "na",
    "change_shoes": "na",
    "sizes": [5, 6, 7, 8, 9, 10],
    "description": "Statement pumps in vivid red with crystal accents. A refined silhouette designed to elevate evening looks with effortless confidence.",
    "details": [
      "Red",
      "Crystal embellishments",
      "Buckle strap",
      "Leather sole"
    ]

Adding a new product means adding one JSON entry. No code changes needed.

MIRROR Virtual Try-On Modal (Photo by Donnie0102)

Cart System

The cart uses localStorage with a key of mirror_cart. Adding the same product + size combination increments quantity rather than duplicating the entry. The cart page shows a subtotal, per-item quantity, and instant removal.

What I'd Do Differently

Public URL handling: ngrok works great for demos but you need to remember to update PUBLIC_BASE_URL in .env every time you restart the tunnel. A deployed backend would eliminate this friction.
Photo storage: localStorage caps out at ~5MB, so 10 photos is a practical limit. A proper backend photo store would be the next step.
Polling on the client: Right now the server blocks while polling Perfect Corp. For production, I'd move to a job queue + WebSocket or SSE to push the result to the client when it's ready.

Running It Yourself

# Install
cd client && npm install
cd ../server && npm install

# Configure
echo "PERFECTCORP_BEARER_TOKEN=your_token_here" > server/.env
echo "PUBLIC_BASE_URL=https://your-ngrok-url.ngrok.app" >> server/.env

# Expose server (Perfect Corp needs a public URL)
ngrok http 5000

# Start backend + frontend
node server/index.js
cd client && npm start

Wrapping Up

MIRROR was a great way to explore AI-powered fashion tech in a hackathon format. The most interesting engineering challenge was juggling the different API contracts for each product category while keeping the frontend interface clean and consistent.

If you're looking to integrate Perfect Corp's virtual try-on APIs, the biggest thing to know upfront is the public URL requirement. Plan your image hosting strategy before you start as well, and you'll save yourself a lot of debugging.

The full source is on GitHub. Feel free to take a look or use it as a reference for your own try-on projects.

Building a Full-Stack Stats Utility App with Node, React, Rust, and Python

Steven Wallace — Sun, 02 Nov 2025 08:54:10 +0000

📊 A containerized statistics toolkit that runs Rust + Python microservices behind a Node backend and React frontend.

🧠 Built with TypeScript, Axum, FastAPI, and Docker Compose.

💾 Repo: https://github.com/swallace100/stats-utility-app

Intro

Data analysis usually involves juggling multiple tools, such as Pandas for stats, R for tests, and Matplotlib for plots.

I wanted something simpler, so I made a single, containerized app where I could upload a CSV with numeric data and get common summary stats with plots.

The Stats Utility App is a lightweight, polyglot toolkit that runs four services:

React (frontend)
Node.js (backend)
Rust (stats engine)
Python (plot server)

The app runs completely in Docker and the backend orchestrates all cross-service communication.

In this post, I’ll show how it’s structured, how it runs, and what I learned while piecing four languages together.

Tech Stack

• Frontend: React + Vite + Tailwind + shadcn/ui

• Backend: Node.js (Express + TypeScript)

• Rust Microservice: Axum + serde for high-performance numeric kernels

• Python Microservice: FastAPI + Matplotlib for rendering plots

• Orchestration: Docker + Docker Compose

• Validation: Zod + shared JSON schemas

Everything runs locally in containers and no database is required.

Jobs are stored in memory, keeping it simple and fast to rebuild or demo.

Architecture Overview

frontend/     # React + Tailwind + Vite UI
backend/      # Express API gateway
stats_rs/     # Rust microservice for stats
plots_py/     # Python microservice for plots
docker/       # Compose file + build config

Service flow:

React → Node (Express) → Rust (Axum) → Python (FastAPI)

Each service exposes its own /health endpoint. Docker Compose ensures startup order and readiness before serving the frontend.

Backend Flow

The backend acts as an orchestrator.

When you upload a CSV file, it:

Reads and validates metadata (Zod schema)
Sends JSON { values: [..] } to the Rust service
Waits for summary or distribution results
Forwards the data to the Python plotter
Serves JSON + images back to the frontend

Example route:

app.post("/analyze/summary", textCsv, async (req, res) => {
  const csv = req.body as string;
  const out = await fetchJSON(`${RUST_SVC_URL}/api/v1/stats/summary`, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ values: csv.split("\n").map(Number) }),
  });
  res.json(out);
});

Frontend

The UI (React + Vite) lets users drag-and-drop a CSV file and instantly view:

Common summary stats (mean, median, sd, IQR, etc.)
Distribution and ECDF plots
QQ diagnostic plots

It calls /analyze/* and /plot/* endpoints on the backend, showing a live “Analyzing…” state while the microservices process the request.

Example Output
✅ Summary statistics (mean, median, std, min/max)
📈 Histogram + ECDF + QQ plots
🧮 All computed in Rust and rendered with Matplotlib
💡 Runs entirely in Docker, so setup takes minutes

Environment Setup

# build and run all services
make up
# or manually:
docker compose -f docker/docker-compose.yml up --build

Open http://localhost:8085 to access the app.

Services:

Service	Port	Description
frontend	8085	React UI (served by Nginx)
backend	8080	Express API
stats_rs	9000	Rust microservice
plots_py	7000	Python microservice

Lessons Learned

Rust’s type safety and Axum’s ergonomics make it a good match for numeric microservices.
FastAPI is ideal for plotting and quick JSON endpoints.
Zod and Pydantic together make schema validation simple across languages.
Docker and Docker Compose gave me the most issues out of all aspects of this project, but solving them gave me a much better understanding on how to work with added Docker-related complexity.
Storing data in memory instead of a database is a quick option for calculations that don't need to be saved.

Repository + License

📂 Full source: https://github.com/swallace100/stats-utility-app
⚖️ License: MIT

Building a Season-Smart Ramen Chef Agent with Ruby + OpenAI

Steven Wallace — Thu, 23 Oct 2025 09:49:22 +0000

🍜 A tiny web app that generates a season-aware ramen recipe (style, broth, tare, noodles, toppings, garnish, steps, shopping list).
🧠 Built with Ruby (Sinatra + Puma), JSON-schema validation, and the OpenAI Agents API.
💾 Repo: https://github.com/swallace100/ramen-chef-agent

Intro

Many AI recipe demos just post unstructured text. I wanted something that was testable and that follows a set format. This "ramen chef” agent app knows that it’s October in Tokyo, suggests seasonal ingredients, and returns a clean JSON plan that the UI can render without guesswork.

This app serves a single page (vanilla JS) and one API endpoint. It builds a small season context, asks the model to respond as strict JSON, validates that JSON against a schema, and renders a tidy plan in Japanese or English

Tech Stack

Language: Ruby 3.4+
Framework: Sinatra + Puma
Libraries: ruby-openai, oj, json_schemer, dotenv, rack-cors
Tools: Rake tasks (setup, dev, run, lint, test)
Data: data/japanese_seasonal.yml (month → suggested ingredients)

Everything runs locally.

Architecture Overview

.
├─ app.rb                   # Sinatra app: HTML UI + API routes
├─ services/
│  └─ ramen_agent.rb        # Agent: schema, prompt, OpenAI call, 
├─ public/
│  └─ app.js                # Fetch + render (safe, resilient)
├─ data/
│  └─ japanese_seasonal.yml # Month → seasonal ingredients
├─ puma.rb                  # Puma config
├─ Rakefile                 # setup/dev/run tasks
├─ resources/
│  └─.env.sample            # copy to .env with OPENAI_API_KEY
└─ config.ru                # rack entry

Flow:

Browser → Sinatra (/api/recommend) → RamenAgent → OpenAI (JSON) → JSON Schema validation → Rendered plan

All requests are validated. If the model drifts, the app returns a graceful fallback instead of breaking the UI.

JSON-First Planning

The agent enforces a schema so the UI never has to guess field names.

# services/ramen_agent.rb (excerpt)
Schema = {
  "type" => "object",
  "properties" => {
    "season_context" => {
      "type" => "object",
      "properties" => {
        "date" => { "type" => "string" },
        "month" => { "type" => "string" },
        "location" => { "type" => "string" },
        "suggested_ingredients" => { "type" => "array", "items" => { "type" => "string" } }
      },
      "required" => %w[date month location suggested_ingredients],
      "additionalProperties" => false
    },
    "style" => { "type" => "string" },
    "broth" => { "type" => "string" },
    "tare"  => { "type" => "string" },
    "noodles" => { "type" => "string" },
    "toppings" => { "type" => "array", "items" => { "type" => "string" } },
    "garnish"  => { "type" => "array", "items" => { "type" => "string" } },
    "method_steps" => { "type" => "array", "items" => { "type" => "string" } },
    "shopping_list" => { "type" => "array", "items" => { "type" => "string" } },
    "serving_note" => { "type" => "string" }
  },
  "required" => %w[
    season_context style broth tare noodles toppings garnish method_steps shopping_list serving_note
  ],
  "additionalProperties" => false
}

Validation code:

schemer = JSONSchemer.schema(Schema)
plan = Oj.load(model_json, mode: :strict)
raise "invalid" unless schemer.valid?(plan)

Frontend

A minimal page with a Generate Plan button. The JS shows a loading state, escapes strings (XSS-safe), renders lists, and displays a “Raw JSON” toggle for debugging.

// public/app.js (excerpt)
const $ = (id) => document.getElementById(id);

document.addEventListener("DOMContentLoaded", () => {
  $("go")?.addEventListener("click", async () => {
    const box = $("result");
    box.style.display = "block";
    box.textContent = "Generating…";

    const payload = {
      location: $("location")?.value || "",
      language: $("language")?.value || "ja-JP",
      notes: $("notes")?.value || ""
    };

    const resp = await fetch("/api/recommend", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(payload)
    });

    const data = await resp.json();
    // renderPlan(box, data) → outputs Style/Broth/Tare/Noodles/etc.
  });
});

Environment Setup

Clone + env

git clone https://github.com/yourname/seasonal-ramen-chef
cd seasonal-ramen-chef
cp .env.sample .env     # add your OPENAI_API_KEY=...

Install (project-local gems)

bundle exec rake setup

Run (auto-reload)

bundle exec rake dev
# open http://localhost:4567

(Prefer plain run? bundle exec rake run)

Example Request

curl -s -X POST http://localhost:4567/api/recommend \
  -H "Content-Type: application/json" \
  -d '{"location":"Osaka","language":"en-US","notes":"no onions please"}'

Returns a JSON plan with style, broth, tare, noodles, toppings, garnish, method_steps, shopping_list, and serving_note, plus a season_context like { date, month, location, suggested_ingredients }.

Lessons Learned

Including a schema makes it so users get output with the same style every time and a missed field won't break the UI.
Month + locale gives the agent a good baseline for ingredient suggestions without the need for more prompting.
ja-JP vs en-US makes it useful in Japan and abroad.

Repository + License

📂 Full source: https://github.com/swallace100/ramen-chef-agent

⚖️ License: MIT

Possible future features

A mode to get a recipe based on ingredients the user has on hand.
Diet/allergen filters (vegetarian, pork-free, nut-free).
Weekly planner export (PDF/Markdown).
Budget/servings sliders and rough price hints per bowl.
More food types beyond ramen.

If you fork this and add a new feature, drop a link and share!

Building a Twitch bot that lets chat interact with ChatGPT

Steven Wallace — Tue, 14 Oct 2025 10:32:11 +0000

🎮 A Twitch bot that allows users to send ChatGPT commands through Twich chat.
🧠 Built with Python 3.13, Twitch EventSub WebSockets, and the OpenAI API.
💾 Repo: https://github.com/swallace100/ChatGPT-Powered-Twitch-Bot-With-Logging

Intro

Many channels on Twitch have offline chats where users join and message with each other when the streamer is offline. I decided to make a chatbot designed for offline chats that allows users to send commands to ChatGPT through the Twitch chat.

The app listens to messages through Twitch’s EventSub WebSocket API, uses the OpenAI API to generate creative responses, and logs everything per channel and day for review.

With minor adjustments, it could be used when the streamer is online. I know many streamers try to keep bot messages to a minimum, though, so it defaults to offline only.

In this post, I will walk you through how it works, how to set it up, and lessons learned.

Tech Stack

• Language: Python 3.13
• APIs: Twitch EventSub WebSocket, Helix REST, OpenAI API (GPT-4)
• Libraries: asyncio, requests, websockets, python-dotenv, openai
• Tools: Makefile, pre-commit, pytest, ruff
• Persistence: Local logs

Everything runs locally. No hosted backend is required.

Architecture Overview

bot/
  app.py               # main entrypoint
  eventsub_bot.py      # Twitch EventSub WebSocket handling
  commands/            # command registry and built-in handlers
  services/            # OpenAI + logging helpers
  handlers.py          # routes messages to command handlers
resources/appSettings.env

Message flow:

Twitch → EventSub WebSocket → Command Registry → OpenAI → Twitch Helix (chat message)

All chat messages are timestamped and logged to disk.

Command System

The bot’s CommandRegistry routes messages by prefix ($ by default).

Example: a Twitch user types $joke, triggering:

async def joke(self, ctx, arg):
    banlist = self._join_recent(self.recent_jokes)
    prompt = (
        "Tell one short, original, Twitch-friendly joke. "
        "Avoid repeating these recent ones:\n" + banlist
    )
    joke = self.ai.chat(prompt)
    if joke:
        self.recent_jokes.append(joke)
        return joke

Built-in commands include $about, $inputs, $story, $trivia, $touchgrass, and $image <description> for AI-generated pictures.

Twitch Integration

Instead of the deprecated IRC interface, this bot uses EventSub WebSockets to listen for channel.chat.message events:

r = requests.post(
    f"{HELIX}/eventsub/subscriptions",
    headers=self._headers,
    data=json.dumps(payload),
)

When Twitch sends a new message event, the bot processes it asynchronously, calls OpenAI for a response, and posts it back through Helix’s /chat/messages endpoint.

Logging

Every message is saved under:
logs/<channel>/<YYYY-MM-DD>/<YYYY-MM-DD>.txt

Example line:
2025-10-07 13:22:54 user123: $trivia space

Logs make it easy to analyze chat trends or replay conversations later.

Environment Setup

Copy and edit your config: cp resources/appSettings.env_example resources/appSettings.env
Fill in TWITCH_CLIENT_ID, then run: python get_tokens.py This launches Twitch’s Device Flow to populate access tokens.
Install and run: make install-dev make run

The bot connects automatically and starts logging messages.

Lessons Learned

• EventSub WebSocket is cleaner and future-proof compared to IRC.
• Proper async design prevents dropped messages under high chat volume.
• I had a problem where ChatGPT would repeat the same response over and over again. I implemented a response history so that ChatGPT would know which responses it already gave and to not repeat them.
• A simple 10-second cooldown timer prevents spam effectively.

Repository + License

📂 Full source: https://github.com/swallace100/ChatGPT-Powered-Twitch-Bot-With-Logging
⚖️ License: MIT

Eternal Hunt: Building an AI-Powered Text-Based Thriller Game with the OpenAI Agents SDK

Steven Wallace — Fri, 10 Oct 2025 12:32:41 +0000

🎮 Eternal Hunt is a text-adventure thriller narrated entirely by an AI agent.

🧠 Built with Python, FastAPI, Gradio, and the OpenAI Agents SDK.

💾 Repo: github.com/swallace100/thriller-game-ai-agent

The Idea

As a software engineer living in Tokyo, I wanted to qualify for game-dev roles here if the right opportunity came up.
But most studios want to see that you’ve actually shipped a game.

So I decided to make one myself by combining game design with my other goal of building AI-powered tools.

That project became Eternal Hunt, a thriller text adventure narrated completely by an AI agent.

The Premise

The player lives in New York and carries a rare genetic mutation that grants them an unusually long lifespan. They can live for hundreds, maybe thousands, of years.

When a dying billionaire learns this secret, he’s determined to obtain it by any means necessary.

The player interacts only with the Narrator Agent, an AI storyteller who guides the player and manages the experience.

Two Agents: Narrator & Researcher

Eternal Hunt runs on the OpenAI Agents SDK and features two cooperating agents:

Narrator Agent — Handles dialogue, story logic, memory, inventory, and user interaction.
Research Agent — Queries the web in real time and feeds results back to the narrator to keep scenes grounded and current.

The user never interacts with the researcher directly.

Instead, the Narrator Agent can call a custom tool and ask the Research Agent for information whenever it needs real-world data to build the next scene.

Interfaces & Player Systems

The game can run in either a Gradio or Streamlit interface. These are simple chat boxes that work in light or dark mode.

Behind that minimal UI is a full game system:

Inventory Tool — lets the Narrator add and remove items from the player’s inventory.
Persistent Saves — every action is written to a JSON file so the player can pick up where they left off.
Memory Logs — internal context for the Narrator, plus an external save for the game state.

This structure lets the AI maintain continuity while feeling dynamic and alive.

The Challenges

Selective Memory

Sometimes the Narrator decides an event or item isn’t important enough to save.

The player picks up a spoon, later tries to use it… and the AI says it doesn’t exist.

That inconsistency breaks immersion fast.

Breaking Immersion

Early builds would gleefully announce tool usage:

“I just called add_item_to_inventory()! Your item is now in your inventory!”

Adding a simple instruction never mention internal tools fixed it.

Pacing & Tension

The AI’s writing was technically solid but often lingered too long in scenes.

A thriller needs motion. I’m still tuning prompts and constraints to balance detail with momentum.

Architecture Overview

Layer	Tech
Frontend	Gradio + Streamlit
Backend	Python + FastAPI
Agents	OpenAI Agents SDK
Persistence	JSON state files + memory log
Custom Tools	Inventory management, world event tracking, environment logic

Everything is modular. New agents or UI layers can be dropped in easily.

What I Learned

Agents follow structured instructions well, but you have to test their edge cases.
Small behavioral tweaks, like telling them what not to say, make a huge difference.
Two cooperating agents can feel surprisingly coordinated. Adding an Enemy Agent or Orchestrator Agent could take this further.

AI-based text adventures can scale quickly in complexity.

I'd like to see a multi-agent storytelling systems where narrators, enemies, and assistants interact dynamically.

I’m not sure if major studios would count this as a released game, but maybe it’s enough to get me a spot developing Death Stranding 3. Stranger things have happened.

Project Link

Repo: github.com/swallace100/thriller-game-ai-agent

Screenshots, architecture diagrams, and dev logs are all there.

If you experiment with AI storytelling, feel free to fork it and try your own narrator style.