LarpClient

Problem

Standard Minecraft modding frameworks provide no clean abstraction for authentication, custom rendering pipelines, or reliable injection into both obfuscated and deobfuscated Minecraft bytecode simultaneously. Achieving feature parity with commercial clients required building infrastructure from scratch.

What it does

LarpClient is a production-grade Minecraft mod client that combines low-level JVM injection with a high-level Kotlin feature layer. It includes a custom HTTP authentication server, a code obfuscation pipeline for distribution, a GLSL shader-driven GUI system, and a custom loader that bridges obfuscated and deobfuscated method references via mixin remapping.

Architecture

LarpClient is structured around three distinct layers with well-defined boundaries between them. The loader layer handles class injection into the Minecraft JVM at startup, using a custom agent that intercepts class loading and applies mixin transformations before classes are used. The feature layer is written in Kotlin and implements all client-side functionality — from movement systems to GUI state management. The GUI layer is a fully custom GLSL shader pipeline that bypasses Minecraft's standard rendering stack entirely. Authentication is handled through a lightweight HTTP server that issues signed tokens, validated on the client side via a challenge-response protocol. This prevents trivial session sharing without requiring a heavyweight backend.

Technical implementation

• —Custom Java agent with class transformer for pre-load mixin application
• —Mixin remapping pipeline that handles both obfuscated and deobfuscated Minecraft targets simultaneously
• —GLSL-based GUI system with layer composition, transform hierarchy, and event routing
• —Kotlin feature layer with typed state management and lifecycle hooks
• —HTTP authentication server with challenge-response token validation
• —Obfuscation pipeline for distribution — ProGuard-based with custom rule generation
• —Gradle multi-module build with separate loader, core, and feature modules

Challenges & constraints

The primary challenge was the mixin mapping problem. Minecraft in development mode uses deobfuscated names; in production it uses obfuscated names. Most mixin targets are specified by development name. The loader needs to translate these mappings at runtime, which requires maintaining and querying a mapping table during class transformation — adding latency that must be minimised. The second major challenge was the GUI rendering pipeline. LWJGL's OpenGL bindings operate at a different abstraction level than Minecraft's rendering stack. Building a GUI that correctly handles Minecraft's rendering lifecycle — including its frame-buffer state, projection matrices, and rendering passes — required careful attention to state management and extensive debugging of GPU state.

Systems thinking note

LarpClient is an exercise in operating at multiple levels of abstraction simultaneously. At the lowest level, it manipulates bytecode. At the highest level, it presents a feature-rich user experience. The complexity arises precisely because the boundaries between levels are not clean — Minecraft's rendering system bleeds into LWJGL's state machine, and the JVM's class loading mechanics constrain what mixin transformations are possible. This kind of multi-level systems thinking is the same skill that makes geopolitical analysis tractable: the ability to hold simultaneously a view at the level of mechanism and a view at the level of outcome, and to reason about how disturbances at one level propagate to the other.