DEV Community: Abisoye O

Hidden Objects: an escape room where the narrator would rather you stayed

Abisoye O — Sun, 01 Nov 2026 05:50:25 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

"I locked you in. The key gets you out, but you don't have it yet."

That's the first thing the narrator says. It doesn't shout, and it doesn't rush you. It would just rather you stayed.

Play it at hiddenobjects.tech, with your sound on.

What I Built

If you've used Blender, Maya, or Unity, you know the outliner: the panel that lists every object in a scene. Hidden Objects turns it into a puzzle.

The room is drawn with pieces missing. The narrator gives you eight riddles, each describing an object that isn't in the picture. Click the matching name in the outliner, and the object appears and the next riddle begins. The last name is the key, and the key opens the door.

A wrong name costs 25 points. Three wrong names and the door stays shut.
There's no countdown. Riddles are better when you have time to think.
The eye icons can't cheat. An object you haven't found yet stays hidden.

For Ghost in the Machine, the ghost is the narrator: a voice living inside a scene file that has hidden your things. The objects are ordinary on purpose (a clock, a mirror, a vase, a lamp, a stool, a plant, a frame, and the key), and a pumpkin, a candle, and fairy lights dress the room for Halloween. Every line is written with younger players in mind. Miss a riddle, and you'll hear "Wrong. I'm not in a rush."

Where the open-weight Gemma model comes in

The narrator runs on Gemma, Google's family of open-weight models, so anyone can run it themselves:

On the live site: Gemma 4 31B (gemma-4-31B-it) on DigitalOcean serverless inference.
On your own machine: Gemma 3 4B (gemma3:4b) through Ollama.

Both get the same prompts and the same checks. Gemma has two jobs.

1. Choosing what you look for next. Before each riddle, the server tells Gemma which objects are still hidden, which you've found, and how many times you've missed. Gemma replies with the next object and a mood for the room's lighting. A real reply from the live site, in under a second:

{"id": "mirror", "mood": "still", "line": "I see myself."}

The game only accepts an object that is still hidden. A late or invalid reply falls back to my written order, so the game never waits on the model.

2. Making the narrator sound different every play. I wrote every riddle and line. Before one is spoken, Gemma rewrites it with the same meaning in new words, so a second play doesn't sound like a recording. From a local run, my line:

"Mirror's up. Look once, then look away. The way out isn't on the other side."

became:

"It's just the reflection, dear. Watch it carefully, then turn your eyes away – the answer hides somewhere else."

A rewrite only plays if it's finished (two sentences at most), spoils nothing (no object the original didn't name), and passes a filter for kids. Otherwise my original line plays.

Is it an agent? Yes, a small one. An agent is a model inside a loop: it sees the state, picks an action, and is called again to see the result. Gemma does that every turn. It has no tools, no memory of its own, and no final say, though, since the game can refuse any move. It's a ghost that's only allowed to move the furniture.

Demo

hiddenobjects.tech is the full game: room, voice, and Gemma on DigitalOcean. No login is needed. Choose Enter the room, listen, and click the name you think the riddle means. Drag or use WASD to look around. With the voice off, every line still appears on screen.

Code

GitHub repository: AbisoyeOnanuga/hidden-objects (MIT)

To play locally, one PowerShell script installs Ollama and Gemma 3 4B. Then run python server.py and open http://127.0.0.1:8765/.

How I Built It

Three files for the page, one Python file for the server, no framework, and no build step.

Page: plain HTML, CSS, and JavaScript, with the room drawn as SVG and a draggable camera that keeps every object in frame.
Server: Python's standard library only. /act handles Gemma's turns, and /speak handles the voice. API keys never reach the browser.
Voice: ElevenLabs Flash v2.5, with each word appearing on screen as it's spoken.
Host: a Render web service on hiddenobjects.tech.

flowchart LR
  click["You select an object in the outliner"] --> act["/act"]
  act --> gemma["Gemma: next object + reworded line"]
  gemma --> checks{"Game checks it"}
  checks -->|passes| voice["/speak: ElevenLabs"]
  checks -->|fails| script["My written line"] --> voice

The hardest part was turn-taking, not the model. A narrator that talks over itself sounds broken, so every line goes through one queue. A late reply can't interrupt a riddle. A correct early click skips straight to the next riddle. A wrong click only counts once you've heard the whole riddle, and the ending line always plays alone.

Why Does Open Innovation Matter

Because Gemma's weights are open, the narrator isn't locked to one company's servers.

Same game, any host: Gemma 4 on DigitalOcean online, Gemma 3 on my laptop offline. One environment variable switches between them.
Free iteration: I tuned the checks against the local model, offline and at no cost, and the hosted model got the same rules.
It can't be taken away: if the hosted model disappears, anyone can still play against a local Gemma, and with no model at all, my written script still runs the room.

Prize Categories

Gemma: chooses the next object, sets the mood, and rewords the narrator so each play sounds different, inside rules the game enforces.
DigitalOcean: serves Gemma 4 for the live site through serverless inference, at a fraction of a cent per game.
Render: hosts the game as a web service.
ElevenLabs: gives the narrator its voice.
.tech domain: the game lives at hiddenobjects.tech.

Help, I'm using Houdini

Abisoye O — Mon, 26 Oct 2026 05:50:47 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 3 — Slow and Steady

If you've ever used Houdini for VFX, Procedural modelling, animation or CG content creation then you're probably familiar with its help-browser. Houdini's help-browser is a very useful source of documentation for any user looking for more information about all parts of Houdini. However, It is not context-aware, and does not know how a user's node networks are wired, or what parameter settings have been applied to a given or selected node. I built a new shelf tool that stays on that displays more details about actively selected nodes and uses the currently installed local-help file that shipped with the user's version of Houdini.

What I Built

houdini-wizard is a super-charged help-browser shelf tool. With any node selected, it will display organised documentation that updates based on what node is actively selected in the node network viewer. You can continue work in the network panel, while the tool is open and it will keep updating its help information or minimise it to avoid taking up screen-space.

The coolest features this tool has that you won't find in a standard help-browser:

Update help documentation for newly selected nodes.
Shows node's Input and Output connection status.
Adopts Houdini's existing Parameter organisation.
Enriches Parameter documentation by including their tooltips, keeping all this info in one panel and not just in the UI.
Maintains existing UI helper-text that users can access on-hover of parameter settings.

GitHub repository: AbisoyeOnanuga/houdini-wizard

Demo

If you have not used Houdini before, a scene is built by wiring small boxes together in a network. Each box is a node, its settings are parameters, and each setting has a short hover tip. When a node cannot compute its result, Houdini raises a cook error.

The standard help browser opens the manual for that type of node, from the very top of the page. It does not know which node you clicked, what is wired into it, or which setting you are trying to understand.

houdini-wizard sits beside your work and reads the room. You can also open it with nothing selected to browse the full help library by category, and the moment you click a node in your network, the view switches to that node.

How it handles parameter tips:

When the tip is already clear, it leaves it alone: On an Ocean Spectrum node, the Wind Speed tip already explains that "Higher wind speeds create larger low-frequency waves." The tool keeps that exact sentence and simply places the slider's range in front of it, so you see the numbers and the explanation together.
When the tip is too thin, it makes it readable: On a Rotate parameter, the built-in tip is four words: "Rotate angles in degrees." That tells you the unit, not how the slider behaves. Here, the tool asks Gemma for one plain sentence using the slider's actual range (0 to 360): 0 means no rotation, and positive and negative values turn in opposite directions.
When a node fails to cook: If the error message already names a parameter, the tool jumps straight to that section of the manual without calling the model. If the error is vague, Gemma picks the closest heading from that node's help file, and the tool quotes the manual directly.

Code

Most parameters never touch the model. If a tooltip already explains what happens when you raise or lower a value, rewriting it only wastes time and risks changing a good explanation.

This check is the gate in front of Gemma. It looks for cause-and-effect words that are already in the help text, and only lets short, label-like tips pass through:

def _needs_model(meaning: str) -> bool:
    if _effect_clause(meaning):
        return False
    words = re.findall(r"[A-Za-z0-9']+", meaning)
    return len(words) <= 6

Wind Speed contains "higher", so _effect_clause catches it and the original tooltip stays intact. "Rotate angles in degrees" has no effect words and is only four words long, so it gets the one-line value guide.

How I Built It

Each tool in the stack has one job, so the window stays fast while you are working in a scene:

Houdini Python (hou) and PySide: Runs inside Houdini to read the active node, its live input and output wires, its parameter tabs, and the slider ranges on the node you have open.
Installed Houdini Help ($HFS/houdini/help): Every node page, shelf step, and diagram is read directly from the zip archives that shipped with the user's installed version of Houdini, so the documentation always matches the software on screen.
Gemma 3 4B (via Ollama): Runs locally to handle the two places where a static page falls short: matching an unclear cook error to a help heading, and turning bare four-word parameter labels into a readable sentence about the slider's range.
Focused Skill Files: Instead of running an open-ended chat loop that might invent settings or try to art-direct the scene, Gemma is paired with two strict skill prompts. One only allows it to return an existing heading name from the file; the other only allows a single sentence using the numbers actually present on that parameter's slider.
Temporal (Python SDK): Wraps the heading lookup in a durable workflow so a slow local model call can retry cleanly, and if Houdini closes mid-session, reopening the shelf on that node restores the same help card without re-running the model.
Entire: Tracks the coding sessions behind the repo so you can query why specific guardrails exist—such as why the shelf skips Gemma whenever a parameter heading is already named.

A multi-process agent harness is for a loop: the model picks the next tool, and several processes keep a conversation going. This shelf does not need that. The path is already decided. Opening a node saves that card, whether or not the node is showing an error, a warning, or a message. Python quotes a heading that is already named, and that save does not call Gemma. Gemma runs inside a Temporal activity only when that text names no heading, and it may only return one heading from that file, or none. If the call times out, the same run tries again, up to three times, so a second call cannot also succeed. The browser stays closed until you click Session log or Developer monitor on the panel. Session log shows the newest node first, plus a Model view for tokens in and out, time spent, and model memory, and links to the public Entire session for how the code was built.

flowchart TD
  activeNode["active network node"] --> wizard["houdini-wizard shelf"]
  wizard --> helpFile["installed help file"]
  helpFile --> gemma["Gemma picks one heading, or a short value line"]
  gemma --> quote["wizard quotes that help section"]
  gemma --> noMatch["no match lists headings you can open"]
  quote --> temporal["Temporal keeps this card"]
  noMatch --> temporal
  temporal --> updated["you update the node"]

Why Does Open Innovation Matter

3D and VFX scenes are often under NDA, and artists regularly work on machines that cannot send scene data or node graphs to a cloud API. Just as important, Houdini changes from version to version—a generic web search or a cloud model trained on older forum posts will confidently point you to parameters that do not exist in your build.

Building this with open-weight and open-source tools solves both problems at once:

Local and private by default: Running Gemma through Ollama on the artist's workstation means node names, cook errors, and studio paths never leave the machine.
Grounded in the truth on disk: By pairing an open-weight model with the documentation archives already installed with Houdini, the tool improves how help is organised and read without inventing parameter values. It follows the same philosophy Saketh Balijepalli described in NannaDesk: An AI Assistant for My Dad That's Not Allowed to Guess: use the small local model for language, and keep the facts deterministic.
Inspectable workflow and history: Using Temporal and Entire means both the runtime retries and the development decisions behind the tool are open, reproducible, and easy for another developer or TD to inspect.

The artist stays in control of the shot. houdini-wizard never changes a value, flips a flag, or wires a node for you—it makes the documentation you already have easier to read while you work.

Prize Categories

Gemma: To match vague cook errors to the right section of the manual and turn short parameter labels into clear slider explanations, while running locally through Ollama.
Temporal: To store the tool's lookup history, retry local model calls when they time out, and reopen that same help card if Houdini closes while you are working on a node.
Entire: To record the agent sessions behind the build and make it easy to search why specific design choices and model guardrails exist in the codebase.

Price Wire: Live-seller pricing & listing copy (HF26 Week 2)

Abisoye O — Fri, 16 Oct 2026 04:42:52 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 2 — Side Hustle

You know the piece. You are not sure what to ask, especially minutes before a live marketplace stream or a new listing, and you do not want an hour of tab switching.

Price Wire is a prep notebook for live selling and regular listings: eBay Live, TikTok Shop LIVE, Etsy, Facebook Marketplace, and similar. It does not plug into stream APIs. It helps in the minutes before you go on camera or hit publish.

What I built

A small web app: describe what you sell and the condition, tap Get price, and receive:

Similar sales (live listings when SerpApi is on; bundled examples only if live search is off or empty)
A price sheet (suggested, quick sale, hold firm)
Paste-ready title and description (templates in the same response, not a second LLM write pass)

Notebook-style UI, light/dark theme, labeled Copy buttons on the listing draft.

What actually powers this prototype

I am not claiming a full agent platform or every sponsor integration end-to-end. This build is useful today because of:

SerpApi — pulls active similar listings from shopping and marketplace-style search so your price sheet is grounded in what other sellers are listing today, not a chat guess.
AI title parsing — Gemma / Gemini on Render, or Ollama locally, when configured; otherwise title rules.
Pricing from similar sales — median band and confidence labels from a price table; optional with TabPFN with a developer key.
Template listing copy — platform packets (Etsy-first) generated alongside the price sheet.
Render — hosts the API and UI (price-wire.onrender.com).

Status chips show what is configured; offline chips still run on bundled example sales so the User-flow can be tested.

Live sale prep

On a live marketplace stream, viewers often check the same marketplaces on their phone while they watch. If your starting ask is far above other sellers' active listings for a similar item, you lose time negotiating on air or lose trust.

Price Wire gives you a similar sales table (live rows when SerpApi is on), a price sheet to choose your floor and starting price, and paste-ready copy for what you say on camera or list after the stream.

Walkthrough

Title: Hand thrown stoneware mug set of 2 matte glaze
Condition: Used, e.g. light studio wear
Get price → Etsy tab → Copy title + description

More paths: WALKTHROUGH.md

Try it

Demo: price-wire.onrender.com (rate limits: ~8 quotes/min per visitor, ~30/day shared UTC)

Local: github.com/AbisoyeOnanuga/price-wire — npm install, npm run dev. Works without keys using examples + rules.

Where it could go next

The repo includes hooks and samples for a richer product; they are not part of the live demo story yet:

Tiger Data — save and search your own sale history (schema + seed in repo; production DB was not live for this submission).
Mastra — tools are registered; the HTTP path is a fixed pipeline, not a multi-step agent.
Sentry — optional pricing.run span; room for fuller quote tracing later.
TabPFN — stronger when comp sets grow.

Details: FUTURE.md

Agent session (how it was built)

Price Wire HF26 Week 2 — prototype UX and listing draft

You

Price Wire: HF26 Side Hustle — electronics comp pricing + listing copy prototype.

Agent

Shipped flat-repo app, simplified seller conditions, platform copy packets, tier 0 demo. UX: field descriptions, notebook chrome, interactive demo card, DEV draft 4857325 for proofread before publish.

Why live listings beat guessing on stream

A generic chatbot does not show you other sellers' current listing titles and prices for your item. On a live sale, that is what you are competing with in the moment.

SerpApi feeds today's shopping and marketplace search results into the similar-sales table. You use those rows plus the price sheet to pick a credible starting ask and the template copy for your pitch. Bundled examples in the repo are only a fallback when live search is off.

Code

https://github.com/AbisoyeOnanuga/price-wire

**Fine print** *AI disclosure.* I wrote and edited this post. Drafting and structure were assisted by AI coding agents while I built Price Wire. *Prototype disclaimer.* Hacktoberfest demo, not financial or legal advice. Verify fees, shipping, and marketplace rules before you list. *Post-deadline update (19 Oct 2026).* After the submission window, this article and the [judging disclaimer](https://github.com/AbisoyeOnanuga/price-wire/blob/main/JUDGING-DISCLAIMER.md) were updated so copy matches what you can verify on the hosted demo. One **bug fix** restores the intended SerpApi path (live similar listings when keyed; repo examples only when live search is unavailable—not mixed into live quotes). Optional stack (Tiger, Mastra agent loop, deep Sentry) remains future work, not live-demo claims.

Trail Sketch: a field-study guide for drawing and painting outdoors

Abisoye O — Mon, 12 Oct 2026 06:57:11 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Trail Sketch is a phone map for choosing a plein-air drawing or painting spot, then leaving with a short plan.

Pick what you want to study. Nearby places line up as cards: a photo when Wikipedia has one, a feel word, and how far the walk is.

Use the map button tucks that list away. Hide leaves the pins.

Open a place and the photo stays beside the weather. Graphite and ink get a value plan. Watercolor and oil add three pigments. You decide what stays on the page. Accepting a place saves the date, medium, and weather on this phone, and marks the pin. A studied place can be deleted.

Demo

trail-sketch.onrender.com

visit the link to see the early prototype.

Code

https://github.com/AbisoyeOnanuga/trail-sketch

How I Built It

One MapLibre map provides the opensource map library. OpenStreetMap lists what is nearby. Ranking stays on the phone. Open-Meteo describes the weather and lighting conditions. Gemma 4 writes the plan when you ask for one. ElevenLabs reads it aloud when an API key is present. A stored library of studied locations stays on the device.

Lenis scrolls the place list and the study sheet. The map keeps its own pan. The busy rings are recolored loaders from Uiverse Galaxy.

Two other Touch Grass projects inspire the focus of trail sketch to minimise screen dependency or use and encourage real-world interaction. Spotted names one thing and asks you to look up. fieldmemo leaves the phone in a pocket and writes the journal later, on your own machine. Trail Sketch uses that same restraint: the map does the choosing, and Gemma writes one plan when you ask, so you are ready to start studying the location with your pencil or paint.

Why Does Open Innovation Matter?

Trail Sketch is for choosing a place to draw, then leaving the screen. That choice should not depend on a closed map account or a model key. OpenStreetMap lists what is nearby. MapLibre and OpenFreeMap draw it. Wikimedia supplies a photo when one exists. Open-Meteo describes the light. The map and the search work with no keys, so the guide is usable before any paid service is connected.

The plan is the part that uses a model. Gemma is open-weight, so the same request can go to Google's endpoint or to a local process by changing a base URL. The wording of a study is not locked to one hosted model. Places already studied stay on the phone, not inside a closed map's saved list. Open source is what makes the guide available, and what keeps the painter's places and the plan's model from belonging to a single service.

My Agent Session snippet

Guiding map interactions, what data is kept for artists about their chosen locations, and improving some UI-scaling issues:

Trail Sketch mobile field explorer

You

Trail Sketch should suggest study places from the artist's interests when the phone loads, with visual previews. A feel word or a short description should rank the nearest walkable place. Accepting a place catalogues the date, medium, and weather, and marks the pin as studied. Google sign-in can key that library later. The light, middle, and dark boxes are a suggested plan, not a finished palette.

Agent

Nearby places come from an OpenStreetMap Overpass bbox query, ranked on the phone by feel, interests, and walking distance. A named place farther than a short ride is replaced with the nearest listed study. Gemma writes the accepted study as JSON. ElevenLabs is ready to narrate when its key is on the server. Studies stay in local storage, keyed by a Google subject once sign-in is configured.

▸ field-card watercolor study for a nearby pond

Input

watercolor study for a nearby pond

Output

Gemma 4 returned a three-value plan and three pigment swatches. The key and the raw response stayed on the server.

You

On a phone the place list disappears, buttons are too large, and the top of the results card is cropped. Wide layout and vertical scroll are fine. Map pins should be more visual. The selected study should keep its preview beside the written plan and the narration. Update the Entire session and the unpublished DEV draft.

Agent

On a narrow screen the place sheet now starts below the search bar and the list scrolls inside it, one card per row. Wide screens keep a two-column list. Pins are small scene drawings for water, trees, viewpoints, buildings, and ridges. Medium, distance, near-me, and studied controls use the same kind of marks. The study sheet keeps the preview image next to the place name, the weather line, and the plan that can be read aloud.

Process snapshot. The checkpoint on the screenshot commit holds the session stored with that commit, so a viewer can read the project's process there.

Sponsor tools used

Gemma writes the study plan when you ask.

Render hosts the page and API access.

ElevenLabs reads the plan aloud and starts the process of stepping away from your screen.

Entire stores the checkpoint of the agent session used to build this.