i’m not a coder - not by trade. i know where my limitations are. i used claude code and, at times, codex to help me bring my designs to life.
i started this project assuming that, since bots already exist in some form in the free infantry server repo - that this would be a quick weekend vibe project. a few variations of a commonly used, maybe overused, idea is to fail fast, fail often, or to fail cheap. i am proud to say i did all 3 - the first iteration was a catastrophic failure.
the initial idea was to build the brains for the bot - the micro and macro decision making. the design itself was sound, and most of it survived. what killed the first iteration was how it got integrated: rather than building behind a clean seam, it gradually rewired the live path in place.
that left a hybrid runtime, half migrated, with several movement owners, several movement truths, and several packet-emission paths. the shape of it let objective routing, route execution, local navigation policy, runtime state, packet-facing fields, and fallback paths all participate in behavior or movement truth. the most visible symptom was replay - the bot would walk a stretch of ground, broadcast a position saying it hadn’t, decide it was stuck, and walk the exact same stretch again. think groundhog day.
a navigation subsystem is allowed to be wrong, but it is not allowed to become authoritative.
the failed attempt tried to add a better navigation brain into a body with multiple movement truths and packet paths. the second attempt - the sealed kernel design first builds one body: one controller decision, one input frame, one simulated state, one guard verdict, one packet path.