Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

DPIT

1
Posts
1
Topics
A member registered 36 days ago · View creator page →

Recent community posts

Hi, I'm DPIT. I'm building game-playing agents, and this devlog starts with a failure that says quite a lot about the gap between sending a command and doing something useful.

My earlier project, Pikagente, played the Spanish version of Pokémon Yellow through Gen1Recomp, a native Lua/LÖVE2D recreation of the Gen 1 engine. I didn't build that engine, and it isn't an emulator. The agent reads structured game state, uses deterministic routines for movement and menus, and asks a model to score possible choices when judgment is needed. Pikagente is now archived; my current project is Zomboid IA for Project Zomboid.

In Zomboid, Lua exposes game state and carries out actions, while Python selects actions and records the results. Reflex rules, utility scoring and models have different jobs. Some specialist roles are still being tested by comparing their choices without controlling the character. The design has working components and experiments at different stages.

Project Zomboid development capture with the public chat

A real development capture of Project Zomboid alongside the chat panel. The game is paused in this captured frame.

An action can be accepted and still fail

In life 151, the system accepted 13 shove commands, but recorded zero impacts. An earlier escape path was still controlling the character's facing direction and conflicting with combat actions. The command reached the execution layer, but the intended effect did not happen in the game. Looking only at the acceptance log could have hidden that distinction.

The useful lesson here is to keep request acceptance, action execution and game effect separate. For a shove, receiving the command and actually hitting a zombie answer different questions. A reasonable action choice can become ineffective when another controller interferes with its execution.

Project Zomboid development capture with the decision panel

A real capture of the paused game alongside the decision panel, showing the available choices and execution log.

Keeping the evidence useful

The correction was checked in isolated native game scenarios. Those checks give evidence about the specific execution problem; they don't establish better survival over long runs. Future comparisons need to preserve that boundary.

That also matters for learning data. The project has separate death records and preference pairs, but collecting them doesn't establish that they trained the active decision maker. Treating an accepted command as a successful action could put misleading labels into later training data.

I'm also experimenting with a bounded recursive self-improvement (RSI) loop that changes training recipes with a budget and separate evaluation. I haven't shown that each death automatically makes the agent stronger. Future entries will focus on specific problems and the evidence behind each change.

If you've built game agents or mods, how do you distinguish command acceptance from a verified effect, especially when movement and combat controllers can compete for the same character?