COPONGO — Action Roguelike Prototype Showcase

Important Note

This is not a plug-and-play game framework or reusable package.
This repository is a playable prototype and architecture showcase built to demonstrate gameplay programming, systems design, co-op synchronization, and performance-oriented engineering decisions.

The goal was not just to make "a vampire survivors-like game work," but to build a cleaner technical foundation that can scale into a larger action roguelike project.

---

Overview

COPONGO is an action roguelike prototype built with React, TypeScript, PixiJS, and Electron.

It combines a playable top-down survival gameplay loop with a more engineering-focused internal structure:

• system-based gameplay architecture
• fixed-tick simulation
• deterministic co-op multiplayer sync
• expandable skill and evolution systems
• performance-oriented data flow with pooling and spatial partitioning

This repository is meant to showcase how I approach:

• gameplay systems design
• scalable architecture boundaries
• performance-aware gameplay programming
• multiplayer synchronization strategy
• building production-oriented prototypes rather than one-off demos

---

What This Prototype Covers

This showcase includes:

• solo gameplay
• co-op multiplayer flow
• character selection and distinct starting loadouts
• active weapons, passives, and evolution mechanics
• level-up choices and reroll / ban style progression decisions
• merchant flow and mid-run upgrades
• breakables and interactive arena elements
• meta progression and persistent settings
• custom HUD, overlays, and game state transitions

---

Architecture

At a high level, the game flow looks like this:

[ React UI Layer ]
        ↓
[ App / Screens / HUD ]
        ↓
[ GameEngine ]
        ↓
[ Gameplay Systems ]
Input / Movement / Weapons / Skills / Collision / Enemies / Pickups / Arena / Merchant / Flow
        ↓
[ Render + Utility Layer ]
Pixi Renderers / Object Pools / Spatial Grid / Audio / Save / Networking
        ↓
[ Game State ]

The structure is intentionally split so each part has a focused responsibility:

• App.tsx controls front-end flow such as menus, loading, character select, and multiplayer entry
• Game.tsx bridges UI, engine lifecycle, overlays, and render orchestration
• GameEngine.ts owns the main simulation loop and system coordination
• gameplay systems handle narrow domains such as movement, weapons, enemies, pickups, merchant logic, and arena rules
• managers and utilities support synchronization, persistence, profiling, audio, rendering, and performance-sensitive helpers

---

Key Features

System-Based Gameplay Architecture

The core game loop is organized around dedicated systems instead of collapsing gameplay into a single monolithic scene controller.

Examples include:

• InputSystem
• MovementSystem
• WeaponSystem
• SkillSystem
• CollisionSystem
• EnemySystem
• PickupSystem
• DirectorSystem
• WaveSystem
• MerchantSystem
• ArenaSystem
• PlayerSystem

This keeps ownership boundaries clearer and makes it easier to grow or replace slices of gameplay without constantly rewriting unrelated systems.

Fixed-Tick Simulation

The gameplay simulation runs through a fixed-tick update path instead of relying purely on variable per-frame timing.

That matters because it improves:

• gameplay consistency
• multiplayer determinism
• timing predictability for weapons and spawns
• overall debugging clarity

For a game built around dense combat events, cooldowns, pickups, enemy pressure, and co-op sync, that stability matters more than a loose frame-driven loop.

Deterministic Co-Op Multiplayer Direction

The multiplayer approach is designed around a deterministic sync mindset rather than full snapshot streaming.

The intent is:

• both peers run the same simulation
• inputs and spawn-relevant events are synchronized
• checksum / correction logic exists for desync handling
• host / client flow stays tied to the gameplay simulation rather than a purely visual mirror model

This is especially useful as a technical showcase because it demonstrates multiplayer thinking beyond simple state replication.

Performance-Oriented Systems

The prototype includes several decisions specifically aimed at keeping combat-heavy gameplay responsive:

• spatial grid partitioning for faster enemy and pickup queries
• object pooling for transient combat data
• SoA-style enemy storage for cache-friendlier processing
• incremental grid updates instead of constant full rebuilds
• render separation through Pixi-based layers

The goal was to treat performance as part of the architecture, not as a cleanup step after features were finished.

Expandable Roguelike Loop

The gameplay layer is structured to support expansion rather than a single locked content set.

Current systems already support:

• character-specific starting setups
• active skills and passive upgrades
• weapon-like abilities
• evolutions that combine build pieces
• merchant-based progression moments
• persistent progression hooks and settings

That makes the project useful not just as a prototype, but as a foundation for iterating on content and balancing.

---

Multiplayer Focus

One of the most important technical goals in this project was exploring co-op architecture in a genre that can become chaotic very quickly.

The prototype includes:

• host / client game flow
• multiplayer-ready loading and ready states
• synchronized character selection flow
• local and remote input buffering
• deterministic start seed flow
• sync verification and correction infrastructure
• partner gameplay support inside the same combat space

Rather than treating multiplayer as an afterthought layered on top of single-player logic, the project was built with synchronization concerns in mind at the engine and system level.

---

Design Philosophy

Playable prototypes should still have real engineering discipline.

This project prioritizes:

• clear system ownership
• separation between UI flow and gameplay simulation
• multiplayer-aware architecture
• performance-aware gameplay code
• expandability for future content
• readable code boundaries over short-term convenience

Or more simply:

• the UI handles presentation and flow
• the engine coordinates simulation
• systems own gameplay rules
• managers support cross-cutting concerns
• data defines content

---

Relevant Files

Core Flow

• App.tsx
  • screen flow, character selection, multiplayer lobby state, loading transitions
• components/Game.tsx
  • engine bootstrapping, world container, UI overlays, game lifecycle
• game/GameEngine.ts
  • fixed-tick game loop, system orchestration, event wiring, multiplayer-aware simulation

Gameplay Systems

• game/systems/MovementSystem.ts
  • movement and player motion updates
• game/systems/WeaponSystem.ts
  • weapon logic, cooldown-driven attacks, player and partner combat output
• game/systems/SkillSystem.ts
  • skill acquisition and stat effect application
• game/systems/CollisionSystem.ts
  • collision handling between combat entities
• game/systems/EnemySystem.ts
  • enemy updates and combat-side behavior
• game/systems/PickupSystem.ts
  • gem and pickup collection flow
• game/systems/DirectorSystem.ts
  • pressure and pacing support
• game/systems/WaveSystem.ts
  • wave and progression timing
• game/systems/MerchantSystem.ts
  • merchant state and run-time shop behavior
• game/systems/ArenaSystem.ts
  • arena-specific rules and runtime events

Multiplayer / Sync

• game/managers/NetworkManager.ts
  • network integration layer for game simulation
• game/managers/network/DeterministicSyncController.ts
  • deterministic sync controller, input broadcasting, spawn / correction routing
• game/managers/network/InputReconciler.ts
  • input reconciliation support
• game/managers/network/ChecksumVerifier.ts
  • checksum generation and correction flow
• game/utils/MultiplayerManager.ts
  • higher-level session and room flow
• game/utils/InputBuffer.ts
  • local and remote input buffering

Rendering / Performance / Support

• game/render/PixiManager.ts
  • render bootstrap and Pixi integration
• game/ObjectPools.ts
  • pooled gameplay objects for transient combat data
• game/utils/SpatialGrid.ts
  • partitioning helper for efficient spatial queries
• game/data/EnemyStorage.ts
  • enemy storage tuned for performance-sensitive processing
• game/utils/GameProfiler.ts
  • per-system profiling support

Content / Data

• data/characters.ts
  • character definitions, unique starting weapons, passives
• data/skills.ts
  • active and passive skill definitions
• data/evolutions.ts
  • evolution requirements and upgrade logic
• data/weapons.ts
  • weapon definitions and tuning values
• data/enemies.ts
  • enemy definitions and gameplay parameters

---

How It Works

1. The player enters through the menu and game flow controlled by the React layer.
2. Game.tsx creates and owns the gameplay session lifecycle.
3. GameEngine.ts initializes systems, managers, and shared game state.
4. The fixed-tick loop updates gameplay systems in a deterministic order.
5. Combat, enemies, pickups, progression, and arena rules run through their dedicated systems.
6. Pixi-based rendering layers visualize the current world state.
7. In multiplayer, network managers synchronize inputs, spawns, and correction paths on top of the simulation.

---

Current Scope

This repository focuses on the gameplay architecture and prototype loop.

It currently demonstrates:

• action roguelike combat flow
• co-op architecture direction
• progression and evolution systems
• performance-minded gameplay engineering
• UI-to-engine integration in a desktop-friendly app structure

It does not aim to fully solve every production concern yet.

For example, this showcase is not presented as:

• a finished commercial game
• a generic engine framework
• a fully abstracted reusable package
• a complete live-service networking solution

---

Why This Repo Exists

This project is meant to be a concrete portfolio piece for:

• gameplay programming
• game systems design
• multiplayer-minded technical design
• performance-aware engineering

It is the kind of project I use to demonstrate not only what I can build, but how I think while building it.

---

License

Provided as a portfolio and reference implementation for action roguelike gameplay architecture, deterministic co-op experimentation, and performance-oriented gameplay engineering.

Feel free to study it, adapt ideas from it, and use it as inspiration for your own projects.