Thirteen clicks to kill a target that did not move
What Slip & Die: Banana Killers is, who does what on the team (two humans and a group of AI agents), and why that team ended up on Rust and Bevy.
You are a 30-centimetre banana. The guns fire grapes, apple seeds, watermelon seeds and a coconut, and the enemies are other bananas.
Most of the code is written by AI agents, and this episode explains who does what and why the game runs on Rust and Bevy.
On 22 May, five review agents played the tech demo that other agents had built over the previous three days. Their report had 110 findings. The most useful sentence in it described the game as it stood: it took thirteen clicks to kill a target that did not move.
I will get to what was wrong with that build in the next episode. This one is about what the game is and who builds it.
A banana in a world built for humans
Slip & Die: Banana Killers is a third-person shooter. You play a 30-centimetre banana fighting other bananas, in a tropical plantation drawn at real size. A crate is one metre. A palm is around twelve.
The weapons come from the setting. The Acinaia fires grapes, the Sgranamela is a rapid-fire apple-seed gun, the Anguriere fires watermelon seeds and the Coccobomba launches a coconut. There is no red blood: damage produces yellow pulp, seeds, peel and exaggerated splashes.
The first commit is from Sunday, 17 May, and the concept was already on paper. We looked at humans, other fruit and aliens as the main enemy. Humans would need a much more expensive modelling and animation pipeline, every other fruit would need its own skeleton, and aliens had nothing to do with a plantation. Banana against banana gives one shared body plan, and colour, proportions and equipment can carry the six planned types: Cavendish, Plantain, Baby, Red, Green and Overripe.
Humans stay in the game as hazards. A 1.8-metre fruit picker is six times the height of the player, a tractor is closer to a moving building, and a monkey steals a weapon and runs away. I kept them at real size on purpose, because the point of view is the whole joke and it only works if the world stays big.
An ordinary minute of play should be short-range fighting in a dense arena: you move between cover, read a small group of enemies and deal with a human-sized hazard in the same space. The comedy should come from a hit or a collapse, and the controls have to stay precise.
Who does what
I am arf, the lead designer. I set the direction and priorities, build the levels, play every review build and reject work that does not hold up in the game.
GattixGGX designs how combat works: weapon balance, armour, encounter rules and the systems that decide what happens in a fight. GattixGGX will also make the final character models and animations.
The programmers, the researchers and the first-pass reviewers are AI agents. It is a personal project, and one of the things we wanted to find out was how far a virtual dev team could take a game when two people give it direction.
The player and the Overripe Brute you will see in these early episodes are temporary models. They exist to develop movement, combat and the asset pipeline.
Why Rust and Bevy
An agent writes code quickly, but it can also make a wrong assumption and repeat it through six files. Rust’s compiler catches many of those mistakes in the agent’s own terminal, before a build ever reaches my PC. Bevy splits the game into small plugins, so an agent can work on the camera without loading the weapon and gore code into its context. The price is that Bevy is still before version 1.0, so updates break things: we moved from 0.18 to 0.19 during the summer, which a later episode covers.
Under the hood: the choice of Rust and Bevy, and code written for a team of agents
Rust. The compiler enforces ownership: every value has one clear owner, so two parts of the code cannot silently change the same data. Types do not silently become null, and moving a contract between modules produces concrete compiler errors. ADR-0001 lists these, a reproducible Cargo.lock and clear compiler messages. It also lists what we gave up: Bevy has no visual scene editor, and its community is smaller than Unity’s, with fewer tutorials. The mitigation written there is that agents read code, docs and GitHub issues well. The same ADR sets aside one week of engine-upgrade budget per major Bevy release.
Bevy. Bevy is built around an Entity Component System (ECS): entities are plain things, components are the data stuck on them, and systems are functions that run over every entity with a given set of components. Plugins group systems by domain, and headless tests can run the gameplay world without opening a window. We started on 0.18 and moved to 0.19 following Bevy’s official migration guide. Several plugins had to be ported or temporarily vendored.
Alternatives. Godot’s editor is attractive, but GDScript would push more failures to runtime. Unity and Unreal put more of the work behind an editor, and Blueprint is not something an agent can sensibly change from a terminal. A custom engine would have postponed the first banana until we had built an ECS, a renderer and an asset loader.
Boundaries. ADR-0005 (17 May) set up the workspace as 14 library crates plus one binary: input, camera, player, weapons, gore, AI, level, hazards, audio, UI and balance, among others. The game binary mostly assembles plugins, and dependencies point one way so that a local change cannot quietly turn into a cycle. The ADR gives the reason in terms of how the agents behave: they read a file in small chunks, lose context when it grows past roughly 500 lines, and go wrong when one file has five overlapping jobs.
Context. Each crate has a short AGENTS.md that says what it owns, what it may depend on and which invariants must survive a change. The repository enforces a 300-line limit on Rust files with a CI script (since 18 September). Files already over the limit may shrink, but may not grow without being split.
Data. Speeds, damage, weather, materials and other tuning values live in RON files. In a development build they can be reloaded without recompiling.
Review. Work starts from an issue and ends with local checks plus a review by an agent that did not write the change. A merge needs the relevant tests, a readable diff and, for anything visible, a capture or playtest observation that matches the issue.
A plugin looks like this. Each crate exposes one plugin, and the app only adds it. The camera crate registers its own resources, types and messages:
#[derive(Debug, Default)]
pub struct CameraPlugin;
impl Plugin for CameraPlugin {
fn build(&self, app: &mut App) {
app.init_resource::<PreAimCameraMode>()
.init_resource::<CameraMotionTelemetry>()
.register_type::<CameraArm>()
.add_message::<CrouchToggled>()
// ...
}
}Sources
Next time: what 329 commits in one day actually produced, and a camera stuck 30 centimetres from the player.