Emberbound Game

Emberbound is a free-to-play, 4-player online co-op brawler that combines the instant action of classic arcade beat’em-ups with the progression, loot, and dark atmosphere of a modern dungeon crawler.

Comment 9

Emberbound: Siege of Ashen Vale

About the project

Emberbound is an original browser-based fantasy beat-’em-up for one to four online players. Players form a private warband, choose distinct heroes, and fight through a persistent campaign filled with monsters, cooperative challenges, cinematic storytelling, character progression, and multi-phase bosses.

The goal was to create a game that friends could immediately play together from separate computers, phones, or controllers—without downloading a traditional game client. Campaign checkpoints support shorter 20–30 minute sessions while allowing the same group to return and continue its quest later.

The current source build includes:

  • A twelve-stage campaign with twelve boss encounters
  • Nine cooperative bonus trials
  • Six playable heroes with unique combat styles
  • Twenty-three starter and unlockable weapons
  • Pair-specific Team Up attacks and cooperative revives
  • Persistent campaigns, hero progression, and equipment upgrades
  • Forty-four synchronized cinematics with 368 voice assets
  • Friends, private messages, party chat, and optional WebRTC voice
  • Mouse, keyboard, gamepad, touchscreen, fullscreen, and mobile support

Inspiration

I wanted to recapture the immediate cooperative fun of classic arcade brawlers such as Golden Axe and Teenage Mutant Ninja Turtles, then combine it with a darker, atmospheric fantasy world reminiscent of games like Diablo.

The central idea became:

What if a classic arcade beat-’em-up grew into a persistent online adventure that friends could play together over many sessions?

I did not want cooperation to mean simply placing four players on the same screen. Emberbound’s players rescue downed allies, coordinate bonus objectives, pass important objects, activate structures together, and perform character-specific Team Up attacks. Who initiates a Team Up can even change the resulting move.

Although Emberbound draws inspiration from the feeling of classic fantasy brawlers, its world, characters, story, graphics, audio, code, enemies, and abilities are original.

How I built it

Emberbound was human-directed by Jeff J Hunter as a Generated Adventures original. The development workflow was completed through the Codex App using GPT-5.6 Sol through a ChatGPT Pro subscription.

The game does not use Unity, Unreal, Phaser, or another off-the-shelf game engine. We created a purpose-built browser game runtime using:

  • Node.js for the authoritative game server
  • WebSockets for real-time multiplayer
  • Canvas 2D for rendering
  • Web Audio for music, voices, and combat effects
  • WebRTC for direct and party voice communication
  • PostgreSQL-ready persistence for accounts and campaigns
  • HTML and CSS for the responsive interface
  • JavaScript and private TypeScript engine packages

The browser sends player intentions—such as movement or attacks—but it does not decide whether an enemy was hit, how much damage occurred, or what reward was earned. Those outcomes are controlled by the server.

Conceptually, the simulation follows:

[ S_{t+1}=F(S_t,I_t,\Delta t) ]

The next world state is determined from the current state, an ordered set of validated player inputs, and a fixed simulation step. This makes multiplayer behavior more consistent, testable, reconnectable, and resistant to basic client-side cheating.

As the project grew, I incrementally extracted reusable engine packages for deterministic simulation, multiplayer rooms, network protocols, reconnect handling, content manifests, and automated replay testing. A separate headless test game now proves that these systems can operate without depending on Emberbound’s characters or content.

Challenges I faced

One of the hardest challenges was making the world feel physically grounded. In a perspective beat-’em-up, character feet, shadows, collisions, mouse targeting, camera movement, foreground artwork, and the walkable combat lane must all agree. When one calculation was wrong, characters, bosses, or even a loot wagon appeared to float above the floor.

Responsive presentation was another major challenge. The same game needed to remain readable on phones, desktop displays, fullscreen browsers, high-DPI screens, and a 49-inch ultrawide monitor. This required a bounded 16:9 battlefield, separate high-resolution HUD rendering, mobile performance limits, landscape touch controls, safe-area handling, and a rule that critical game controls never hide inside scrolling panels.

Online continuity also required more than reconnecting a WebSocket. The game needed to preserve player identity, reject stale commands, reserve a disconnected player’s position, rotate reconnect credentials safely, and prevent duplicated characters. Persistent progress was therefore designed around safe stage and bonus-round checkpoints instead of saving arbitrary mid-attack states.

Audio and animation required extensive iteration. Human playtests exposed problems that ordinary code tests could not fully judge: repetitive attacks, voices ending before subtitles, incorrect pronunciations, projectiles coming from the wrong hand, awkward death sounds, floating defeat animations, and boss weapons appearing twice. Those observations became new animation contracts, voice timing rules, pronunciation checks, audio-density limits, grounding tests, and weapon-presentation tests.

What I learned

The biggest lesson was that a browser can support a surprisingly ambitious real-time cooperative game, but only when performance and server authority are designed into it from the beginning.

I also learned that automated testing and human playtesting solve different problems. A complete automated four-player raid can verify every stage, trial, boss, revive, reconnect, checkpoint, and reward. Only real players can tell you that an attack feels weak, a sound is irritating, a marker is difficult to see, or a supposedly dramatic death looks ridiculous.

Another important lesson was to extract a reusable engine gradually from a working game. Preserving compatibility, rollback points, and playable checkpoints was safer than stopping development for a complete rewrite.

Most importantly, cooperative design needs real interaction. Shared rewards, revives, complementary abilities, contribution scoring, and coordinated objectives create a warband. Merely increasing enemy health does not.

What’s next

The next phase is final physical-device testing, production voice and TURN validation, additional audio and animation polish, hardened VPS deployment, and continued balancing with real groups of players.

The long-term goal is to evolve the extracted Generated Adventures engine foundation into a reusable platform for creating additional online cooperative games—while continuing to expand Emberbound’s world, characters, weapons, challenges, and quests.

Built With

Share this project:

Updates