Back to IndexBeserkBot
Python plugin work for a CarbonX Rocket League environment, focused on AI control hooks, trajectory prediction, state timing, and runtime behavior.
A real-time plugin/runtime study framed around timing, prediction, and state freshness instead of vague AI claims.
The page separates Python plugin work from the CarbonX environment and avoids overclaiming authorship.
The core signal is state sampling, trajectory reasoning, update cadence, and action timing.
The engineering shape maps to simulation, robotics-style control loops, and low-latency runtime tooling.
Runtime clips and Vercel demo
Scope: Python plugin layer for CarbonX Rocket League environment
Proof: four downloaded runtime clips embedded below
Demo: public Vercel app remains the primary interactive artifact
Framing: runtime systems and prediction work, not CarbonX authorship
BeserkBot: Rocket League Plugin Runtime
BeserkBot is listed publicly as a Rocket League plugin/runtime project for a CarbonX environment. I did not build CarbonX itself. My work is the Python plugin layer that allows the AI player to expose the behavior demonstrated on the BeserkBot site: state access, timing coordination, trajectory reasoning, and runtime control.
The portfolio version focuses on the engineering signal: prediction math, update timing, plugin boundaries, configuration, and how real-time decisions behave when state changes quickly.
Problem
In a fast game-like runtime, the useful question is not just "where is the object now?" It is "where will the object be when my next action matters?"
That turns the project into a systems problem: sample state, model motion, handle latency, make a decision, and avoid acting on stale data.
What I Built
- Plugin bridge: Python-side control logic that connects the AI behavior path to the runtime environment.
- State sampling: Read changing game state and prepare it for prediction.
- Trajectory reasoning: Estimate movement, ball path, and timing windows.
- Runtime coordination: Keep reads, prediction, and output aligned under frame and latency constraints.
- Visual explanation: A public site that explains the behavior through runtime and prediction views.
Constraints
- State can go stale between sampling and action.
- Prediction quality depends on velocity, acceleration, latency, and update cadence.
- A plugin has to respect the boundary between the environment, the AI decision layer, and the output path.
- The project needs careful framing: it is presented as runtime/plugin engineering and prediction work, not as a claim about stealth, bypassing, or competitive advantage.
Tradeoffs
The site keeps the focus on engineering behavior: state, timing, prediction, and plugin boundaries. That is the part that transfers to simulation, robotics-style control loops, low-latency tooling, and game-adjacent systems.
Proof
- Public demo site with runtime and behavior explanation.
- Plugin framing that separates my work from the CarbonX environment itself.
- Four embedded runtime clips on this page.
- Portfolio framing that points visitors to the Vercel app instead of pretending a fake graph is the demo.