Skip to main content
GameDev.net gamedev.net
Prometheus
In Development

Prometheus

Building the tools to bring an endless world to life.

Screenshots (16)

About This Project

Description

Pixel-art worlds with depth, light and a life of their own. That's the ambition behind
Prometheus, the custom 2.5D game engine and browser-based editor I'm building from the
ground up, together with the tools to turn that ambition into a game.

The long-term goal is Forgotten Memories, Endless Abyss, a fantasy MMO about exploring an
immense dungeon, recovering lost memories and living with the consequences of a shared world.
Its visual direction is a world of stylized, multi-angle sprites derived from real 3D models.

Right now, the focus is the foundation: scene editing, simulation, lighting, effects, scripting
and asset workflows. Prometheus also includes Forge, a companion workspace for version
control, code review, issue tracking and project documentation. The engine and tools are in
active development; the MMO remains a future milestone.

What 2.5D means here

The world uses 3D space, lighting, shadows and physics, while the intended final artwork is
made entirely from stylized sprites. Every world asset starts as a real 3D model imported
into Frieze, the sprite generator and creator. Frieze captures the model from many angles
and turns those views into stylized sprite sheets. Showing the appropriate captured angle
gives each asset a three-dimensional feel as the viewpoint changes.

That approach extends to the whole world: characters, trees, flowers, rocks, scenery and
props. Even static objects will have multiple views. The goal is to replace every visible
3D source model with its sprite counterpart in the final game. The underlying spatial
simulation stays 3D. The current showcase still contains 3D models while that asset workflow
is developed. Frieze also supports palette swaps, allowing visual variations of a sprite.

The appeal is the combination: the deliberate shapes and color of pixel art, with the
changing viewpoints and physical relationships of a 3D world. A tree should feel like an
object you can walk around. A character should belong in the light of the room.

What is taking shape today

The current prototype already brings several parts of that workflow together:

- Build and inspect a scene: hierarchy and property tools, four-view editing, wireframe
views, an asset browser, and authored paths for cameras and objects.
- Make light part of the scene: colored lights, shadows, normal-mapped sprites and
particle effects that can illuminate nearby objects. Smoke can pick up firelight;
lightning can briefly light the surrounding scene.
- Give a place atmosphere: layered fire, smoke and embers, rain, snow, fog, drifting
wisps, water effects and magical bursts, with bloom and color grading to shape the mood.
- Author behavior and sound: custom editor scripts can access transforms, timers,
collision hooks and audio. Scene and object controls support music, ambience and spatial
sound authoring. Script execution currently lives in the browser editor.
- Create the sprite assets: Frieze provides the model-to-sprite workflow, directional
views, animation playback and palette variations that the final art direction builds on.

The exciting part is getting these systems to work together: a flame that lights the
sprite beside it, a physics event that triggers a sound, a camera path that reveals the
scene from another angle. Each connection makes the editor more useful for building worlds.

How it is built

The engine is TypeScript from end to end. The browser renders the scene with Three.js and
React; Rapier handles physics; a Node backend owns the authoritative simulation state and
persistence, with MySQL behind it. The simulation lives in one shared package that runs on the
server while editing and can run locally in a shipped game, so the same rules apply in both
places. The editor and the server exchange state over WebSockets, not video: the browser
renders everything itself.

Live editing, and the rules around it

Scene edits use an operation log to support undo and redo, coordination between editor
clients and background persistence. Much of the recent work went into the unglamorous
guarantees around that: a save must
never lose an edit, a restore must never quietly replace newer work, and a backup must be whole
before it is trusted. Each of those rules exists because something went wrong once.

The showcase scene

One scene, Re-Forged, is the standing showcase and test bed. Its guided camera tour brings
together lighting and effects, physics, pixel characters and world-space UI. The working
rule is to give new visible features a persistent example there and verify it after reload.
It's a place to see how the pieces behave together and find out where they still disagree.

Forge

Forge is the workshop around the engine. Anvil manages repositories, branches, Git
operations and code review, including GitHub pull requests; Ember draws the commit graph;
Bench holds the boards, burndown and roadmap; Kiln keeps the documentation library,
versions it, runs a review queue and mirrors the issue files onto the boards. The issue tracker
itself is a folder of Markdown files in the repository. The file is the truth; the card on the
board is its mirror.

Building the workshop alongside the engine means the process gets attention too: how an idea
becomes an issue, how a change gets reviewed, and how the lessons survive the next rewrite.

The game these tools are for

The vision for Forgotten Memories, Endless Abyss is an endless dungeon that grows as it is
explored and reshapes itself around what players collectively do. Discovery is private by
default. Reviving costs memories, and exploring recovers them. Its residents keep living
when nobody is watching. What you discover, what you lose and what you leave behind should
matter to the world. These are design goals; the engine has to be able to support them first.

How I work

One issue at a time, from a written card with acceptance criteria; a review before anything
merges; tests that act as gates rather than decoration; and a handoff document that says
exactly where things stand. The project started in August 2025 and work on it when I have time.
The stack is built with open-source technologies, and the design has no vendor royalties in it.

This page

This project page is my development journal: new features, scene walkthroughs, technical
decisions, experiments and postmortems. I'll show the satisfying moments when a system
clicks into place, the bugs that send me back to the drawing board, and what each iteration
teaches me.

Screenshots show actual development builds. Generated cover illustrations are labeled as
concept artwork. Once the engine tooling is ready, I want to attempt the landscape cover's
scene in-engine using the intended pixel-art sprite workflow, then share the actual result.

If you enjoy engine internals, unusual art pipelines or seeing a world take shape one
working piece at a time, follow along. There is an endless dungeon to build, and this is
where its tools are being forged.



Comments

Discussion

Loading comments...