Toly Gillman

UdonCombatSystem

UdonCombatSystem is a reusable combat framework for VRChat, providing consistent, extensible weapon handling, damage logic, and physically interactive reloading in Udon. Originally a lightweight hitscan/projectile system, it has since been rewritten from the ground up to support H3VR/Boneworks-style manual manipulation, including physical magazine loading, charging handles, and body-anchored holsters, while remaining fully playable for desktop users.

It has also become something of a reference point in the space: searches for combat, weapon, and related VRChat/Udon systems frequently surface this framework, and other creators routinely encounter it while looking for systems to build their own projects on.

🔗 View on GitHub

Core Features

• Hitscan and projectile weapon support, with semi-auto, burst, and full-auto fire modes
• Physical reloading with manual magazine insertion and slide/charging handle cycling to chamber rounds
• Mag belt that auto-populates with the correct magazine for the currently held weapon, backed by a managed mag pool
• Optional ammo inventory for Boneworks-style scarcity and carry limits
• Pockets system with body-anchored holsters at hip and chest for stow/retrieve by physical placement
• Two-handed weapon handling with independent grip points and preserved held rotation across grip changes
• Split between complex and arcade weapons for high-depth interaction or easier setup
• Full desktop parity, with keyboard/mouse equivalents for each VR interaction

Technical Considerations

• VRChat's Udon is treated as a hostile runtime, so the rewrite targets robustness and scalability over ideal-engine assumptions
• Networked via events with parameters, replacing legacy ownership-transfer damage propagation
• Hitboxes are PlayerObjects rather than a shared pool, improving scalability and reducing world upload size
• No Update timing reliance, with logic driven by events and state rather than per-frame polling
• Slide/charging handle behavior via world PhysBones, avoiding clunky pickup-based pull interactions

Sockets, Rebuilt From Scratch

VRChat has no native socket concept, so both the magwell and pockets system are effectively custom socket implementations.

• Pickup parents carry a size enum and stowed flag, and pockets only accept matching sizes
• When items are stowed, visuals are hidden for remote players to mask poor sync for non-woken objects
• Two anchor points are used: hips and chest

Two-Handed Handling

Two-handed interaction was the hardest part of the rewrite because VRChat has no native two-grip pickup model.

• Implements two-handed behavior using two separate pickups and a reparenting strategy
• Held rotation is preserved when releasing the front grip to avoid orientation snapping
• Architecture serves as groundwork for bolt-action reloading that requires front-hand support

Desktop Parity

• Pockets bind to number keys for presenting pocket contents or stowing currently held items
• For complex desktop weapons, reload is programmatically stepped through the same sequence as VR manual interaction

Video Demonstrations

The system is intentionally minimal and composable, designed to be dropped into worlds without dragging in unrelated gameplay logic.

View Repository →

VRCRP (VRChat Roleplay Framework)

VRCRP is a large-scale roleplay framework inspired by DarkRP-style systems, adapted for VRChat's instance-based multiplayer and Udon's technical constraints. This is my most complex and ambitious project, developed over multiple iterations and used in real communities.

Core Features

• Persistent player progression across sessions
• Job and role systems (civilians, police, dealers, service roles)
• Inventory systems with item variants, stacking, and metadata
• Currency, shops, and economy balancing
• Abuse-resistant persistence within strict data limits

Technical Challenges Solved

• Compact persistence formats under VRChat’s ~100KB per-player save limit
• Inventory synchronization across players in a client-authoritative environment
• Variant item storage using delta data to reduce storage costs
• Ownership and race condition handling for late-join consistency

Implementation Highlights

• Inventories stored as compact tokenized data structures rather than naïve objects
• Variant items store only delta data (attachments, custom properties, etc.)
• Heavy use of PlayerObjects for persistence and identity
• Backend logic cleanly separated from UI systems
• Designed as a technical feasibility study as much as a gameplay system

Use Cases

VRCRP has been adapted for a VRChat milsim community (jobs, equipment, controlled access) and forms the conceptual backbone of multiple RP-style experiments. It actively informs academic work on VR multiplayer systems.

Video Demonstrations

Note: VRCRP is not fully public due to its size, ongoing iteration, and community-specific adaptations, but represents my strongest example of large-scale systems design under hostile constraints.

AfterDark Plaza (Systems Implementation)

🔗 Visit AfterDark Plaza in VRChat

AfterDark Plaza is a VRChat world developed in collaboration with a game/level designer. My role focused on implementing gameplay systems based on concrete design requests rather than self-directed framework work.

Key Capabilities Demonstrated

• Translating designer requirements into technical systems
• Integrating multiple gameplay systems into an existing world
• Building modular features that interact cleanly with each other

Implemented Systems

Session-Based Economy & Inventory

• Non-persistent economy designed for session-based gameplay
• Currency earned through gameplay interactions
• Clean separation between economy, inventory, UI, and combat systems

Arcade Machine Integration

• Event-driven currency rewards on completion
• Clean hooks between unrelated systems
• Avoided tight coupling in system design

Shop System

• In-world shop for spending earned currency
• Purchase items and weapons
• Extendable and designer-friendly interface

Shooting Range

• Fully functional gun range powered by UdonCombatSystem
• Weapon spawning and target interaction
• Scoring logic and feedback systems

Portable Inventory UI

• Handheld/menu-based inventory interface
• Item management without world-anchored UI
• Designed specifically for VR usability

Technical Highlights

• Clean separation between all major systems
• Session-safe design with no persistence assumptions
• Reuse of UdonCombatSystem as underlying combat layer
• Emphasis on stability in multiplayer VR environment

Collaboration Process

• Worked directly with game/level designer
• Iterated based on feedback and gameplay needs
• Balanced designer intent with VRChat technical limitations

AfterDark Plaza serves as a contrast to my larger framework projects, showing my ability to integrate into a collaborative pipeline and deliver feature-complete gameplay systems within an existing creative vision.

Visit World →

Quackworks Engine

Quackworks is a C++ cross-platform game engine built as an assessed university group project, targeting Windows and PS5. The engine powers a Duck Game-inspired 2D platformer demo. The systems below are my individual contributions within the team.

EventBus

A type-safe publish/subscribe system for decoupled inter-system communication.

• RTTI-free type identification using addresses of function-local statics — unique per type, zero runtime cost after the first call, no compiler type-info table required
• Type erasure stores all handlers as std::function<void(const void*)> with a typed wrapper at the subscribe site, keeping storage uniform across all event types
• Immediate and deferred dispatch — Publish fires synchronously; Enqueue/Flush defers events to a controlled point in the game loop so input lands before gameplay logic runs
• Re-entrant safe — iterates a snapshot of handlers, so subscribe or unsubscribe during a callback is safe without affecting the current pass
• Token-based unsubscription for RAII-style lifetime management

Input System

A three-layer input architecture designed so gameplay code never sees raw key codes or platform SDK types.

• IInputBackend — pure interface whose sole job is filling a platform-agnostic InputState struct each frame; all normalisation and SDK-specific knowledge stops here
• InputSystem — double-buffered state snapshots; IsKeyPressed/IsKeyReleased derived from current/previous diff rather than hardware edge detection, making edge detection consistent across all backends and testable without real hardware
• InputActionSystem — semantic action bindings identified by plain integers so each application defines its own enum; multiple bindings per action, per-binding trigger types (Down/Pressed/Released), analog axis bindings with deadzone, scale, and invert

Windows backend (PCInputSystem) — unifies three controller SDKs into the common InputState:

• XInput loaded at runtime via LoadLibraryW across three DLL candidates — no hard link-time dependency, engine still launches on machines without XInput
• DualSense via scepad — the same Sony library used on PS5 hardware; Y-axis inversion corrected during normalisation; exposes LED lightbar control through a SDK-agnostic SetGamepadLedColor API
• Steam Input — resolves named action handles against a "Gameplay" action set, covering Switch Pro Controllers, Steam Deck, and generic pads; conditionally compiled under QUACK_ENABLE_STEAM_INPUT
• Stable slot assignment — controllers tracked by a uint64_t device ID encoding both the source SDK and native handle in a single value, so reconnected controllers return to their original slot
• SDK priority — when Steam Input reports active controllers, XInput and DualSense candidates are discarded to prevent the same physical device appearing twice under different IDs

PS5 backend — same IInputBackend interface without the PC complexity:

• Fixed hardware platform with static SceUserServiceUserId constants maps directly to gamepad slots — no dynamic discovery needed
• Splash screen input interception resolved by force-closing the system splash at initialisation — undocumented PS5 SDK behaviour discovered by process of elimination
• ControllerConnectedEvent/ControllerDisconnectedEvent publishes explicitly added after they were found missing on PS5 hardware during lobby testing

SpriteSheetAnimatorComponent

Drives a SpriteSheetRendererComponent by selecting which cell of a sprite sheet to display each frame.

• Two-layer animation — a base layer plays sequences of absolute cell coordinates; an offset layer adds coordinate offsets on top each frame, allowing facial/mouth animations (stored as row offsets in the source art) to composite over any movement animation independently without duplicating sprite data
• Delta-time accumulator using a while loop so large frame deltas advance multiple frames rather than causing the animation to fall permanently behind
• Design inspired by Duck Game's rebuilt source (_sprite.AddAnimation("run", 1f, true, 1, 2, 3, 4, 5, 6)), with the coordinate system and offset compositing developed independently

PlayerManager & PlayerControllerComponent

Application-layer systems for the Duck Game demo's local multiplayer lobby and character control.

• Opt-in lobby registration — controllers present but idle do not auto-join; players explicitly press Start to join and Back to leave, mirroring local multiplayer convention
• Event-driven controller discovery — subscribes to ControllerConnectedEvent/ControllerDisconnectedEvent rather than polling; controller disconnect mid-game immediately unregisters the player and publishes PlayerLeftEvent
• Stable device ID tracking — maps controllers by uint64_t device ID rather than slot index, so reconnects return to the same player slot
• Isolated action ID allocation per controller component, starting at 1000 to leave the lower range for game-level enums
• Lazy component resolution — rigidbody, collider, and animator resolved on first Update rather than at construction to avoid ordering constraints
• Grounded detection via contact set — tracks all bodies currently in contact below the player rather than a single boolean flag, correctly handling simultaneous surface contacts
• Crouch slide with suppressed steering input, reduced linear damping for momentum preservation, and velocity threshold gating
• Quack pitch modulation via right trigger analog binding — deeper trigger pull produces a higher-pitched quack (1.0–1.5×), keyboard always plays at 1.0