Project
- Project
- Vogglenauts
- Role
- Lead programmer
- Status
- In development
Lead programming
Vogglenauts
Vogglenauts is a cozy online co-op game about exploring a tropical world, cleaning up harmful gloop, and solving small mission-based problems together. My part is lead programming: setting up the gameplay architecture, multiplayer patterns, code workflow, and the systems other team members build content on top of.
Project
- Genre
- Online co-op cozy game
- Loop
- Explore, clean, solve missions
Role
- Role
- Lead programmer
- Team
- Student team project
Tech
- Engine
- Unreal Engine
- Gameplay code
- AngelScript
- Workflow
- Perforce + UGS
Project note
Vogglenauts is a good example of the programming work I like: not just making one feature work, but building the systems, conventions, and workflow that let a team keep adding game content without fighting the codebase.
Process timeline
Process
-
Game concept
Defining the co-op game loop
The game is built around low-stress co-op: players travel through a tropical world, clean up gloop, use different tools, and complete mission objectives together. The programming work has to support that style: readable systems, quick iteration, and multiplayer behavior that does not make simple interactions feel brittle.
The technical direction is shaped around fast iteration for a cooperative, mission-based game rather than one-off prototype code.
The hub is a shared space before and between missions. -
Programming workflow
Gameplay code in AngelScript
Most gameplay code lives in AngelScript. That gives the team quick iteration: scripts hot-reload on save, even while testing in PIE. I documented the code layout and conventions so gameplay programmers can find the right place for player code, tools, components, missions, enemies, props, and UI.
The project can keep most moment-to-moment gameplay work in script while still allowing C++ and engine changes when needed.
Underwater mission gameplay with objectives and tool slots. -
Gameplay architecture
Tools, components, and missions
The tool system is data-driven: tools inherit from a common base and use primary/secondary action configs. Actors expose capabilities through components such as cleanable, buoyant, pickup, glooped, or objective-related components. Missions then query a world subsystem by GameplayTags instead of scanning the whole level.
This keeps new content additive: add a component, objective, or tool type without hardcoding every interaction into one large system.
Mission gameplay built from tools, components, and objectives. -
Networking
Multiplayer and physics constraints
The game uses a listen-server setup with resimulation-based physics. Client-side actions can predict local feedback, but important gameplay state still goes through server validation and multicast updates. The documentation also calls out performance rules: avoid unnecessary Tick work, cache components, budget resimulation actors, and pool projectiles or VFX.
The multiplayer work is less about one flashy feature and more about making everyday interactions stable enough for co-op play.
Co-op mission spaces need responsive local feedback and server-authoritative state. -
Production setup
Engine fork and team builds
The project uses a custom Unreal setup with AngelScript and engine-side changes. I documented how to work with the engine fork, mark local engine modifications, and create UnrealGameSync builds so designers can use precompiled editor binaries instead of building the engine themselves.
This is the kind of unglamorous setup work that makes a student team project much easier to keep moving.
UnrealGameSync setup for team builds and project syncing.