# Eldiron: a Rust creator for classic 2D, isometric and first-person RPGs

> Eldiron is a cross-platform game creator aimed at 1980s and 1990s style role-playing games, with a built-in editor, multiplayer support and procedural content. It ships as a desktop app on Windows, macOS and Linux, but the architecture is mid-consolidation as the project works toward a v1 design.

**markusmoenig/Eldiron** — Create cross-platform classic RPGs in 2D and 3D with powerful built-in world editing tools.

- Repository: https://github.com/markusmoenig/Eldiron
- Website: https://www.eldiron.com
- Stars: 826 · Forks: 39
- Language: Rust
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/markusmoenig-eldiron

## A creator aimed at the Ultima era, not at the general engine market

Eldiron positions itself as a creator for classic retro role-playing games, with the stated goal of enabling RPGs reminiscent of the 1980s and 1990s while adding modern capabilities such as multiplayer support and procedural content generation. The reference points in the documentation are Ultima 4 and Ultima 5, and the repository topics carry the same vocabulary: classic, creator, pixel-art, procedural, retro, RPG, Ultima.

The world building is done inside the tool. The description calls out powerful built-in world editing, and the project ships an editor alongside the engine, which is the important difference from a general purpose engine where map authoring usually lives in a separate application.

Three viewing modes are supported natively: 2D in the Ultima style, isometric, and first-person. That choice is what separates Eldiron from a plain tile map editor, and it is also what makes the project interesting to study, because the same world has to be representable in projections that look nothing alike.

The audience is therefore narrower than a general engine audience. If you want to author a tabletop-style dungeon crawl, a 2D dungeon crawler, or an isometric settlement sim, the tool fits. If you want a platformer, a shooter, or a modern narrative game, nothing in the documentation suggests those are the target.

## Three embedded crates carry the window, the rasterizer and the renderer

Eldiron is built on three crates that the author developed over several years, and the documentation says each one focuses on a specific aspect of the engine and the editor.

TheFramework handles cross-platform window creation, the abstraction of user events, and the custom UI system used by Eldiron Creator. Rusterix began life as a software rasterizer for 2D and 3D geometry and later became the core game engine, although SceneVM now performs most rendering and the software rasterization part of Rusterix survives mainly for in-game UI elements. SceneVM is an abstracted, layer-based renderer for 2D and 3D built on top of wGPU, where each layer can define its own geometry and compute shaders, and it is described as the main rendering backbone of the project.

That split is the architectural story of Eldiron. A software rasterizer and a GPU layer renderer coexist, and the older one has not been deleted because it still draws parts of the interface.

The workspace layout in Cargo.toml shows how much lives in the same tree. Members include creator, run-wasm, xtask, and crates for ruleset, shared, rusterix, theframework, scenevm, organicgraph, buildergraph, procedural_recipes, scepter, icon_builder, and character_generator. Under clients there are client, client-wgpu, and client-terminal, so the runtime exists in more than one form, including a terminal client and a wasm run target.

The workspace package metadata pins the version across the tree.

```toml
[workspace.package]
edition = "2024"
version = "0.95.6"
license = "MIT"
authors = ["Markus Moenig"]
description = "A retro-style RPG game creator."
repository = "https://github.com/markusmoenig/Eldiron"
homepage = "https://eldiron.com"
```

## Installing the creator and the client separately from crates.io

Eldiron ships as two distinct programs, the Creator and the Client, and both are published to crates.io, so a Rust toolchain is enough to get going. Pre-built binaries are also published on the GitHub Releases page for each supported platform, and the README carries badges for Windows, macOS and Linux.

With Rust installed, the two installs are independent.

```bash
cargo install eldiron-creator
cargo install eldiron-client
```

Installing them separately is deliberate rather than accidental, since one person authors and another plays. It also means you can update the two halves at different times.

Building from the repository follows the same pattern. The clone step and the run step are both given directly.

```bash
git clone https://github.com/markusmoenig/Eldiron
cd Eldiron
cargo run --release --package creator
```

Running the creator as a release build is worth the extra compile time if you plan to iterate, since a debug build of a project with a large workspace and a custom renderer is slow to respond while you edit a map.

On Linux, three system libraries have to be present before the build will link. The documentation names them plainly: libasound2-dev for audio, libatk1.0-dev, and libgtk-3-dev for the desktop toolkit. On macOS and Windows the toolchain is expected to work without extra system packages.

## Two rendering paths, and the older one is still in use

The most interesting technical decision in Eldiron is the coexistence of two renderers, and it is worth understanding because it explains both the flexibility and the awkwardness of the project.

Rusterix started as a software rasterizer, meaning it draws geometry on the CPU without a GPU pipeline. It grew into the core game engine, so it carries engine responsibilities, but rendering duties have moved to SceneVM, the wGPU based layer renderer. The remaining software rasterization work in Rusterix shows up in in-game UI elements, which is the practical symptom of a half-finished migration.

For a user, this shows up as a rule of thumb: the world is drawn by the GPU path, but some interface elements are drawn by the old software path. If an element renders differently from the rest of the screen, that split is the first place to look.

The layer model in SceneVM is the part that makes 2D, isometric, and first-person possible in one project. Each layer defines its own geometry and compute shaders, so a layer can be a tile grid, a set of billboards, or a full 3D scene without the rest of the stack caring. The abstraction is the reason the same world can be viewed in several projections, and it is also the reason the renderer is a research-adjacent piece of engineering rather than a thin wrapper over a graphics API.

The workspace keeps a debug artifact for this area, a file named eldiron-render-debug.log at the top level, which suggests rendering diagnostics are part of the working workflow.

## The v1 consolidation is the real upgrade cost

The documentation is unusually candid about the state of the code. It says that over the past five years Eldiron has gone through several major iterations, and that as a result some parts of the code are in the process of being consolidated or phased out as the project moves toward a cleaner v1 architecture.

That single sentence is the main risk in the project. A creator tool is a long lived asset for its users, and the projects built inside it carry a much longer life than the tool itself. If the file format, the ruleset format, or the client and creator pair change shape between releases, content made in an older version may not open cleanly in a newer one, and the documentation says nothing about a compatibility guarantee, a migration tool, or a changelog policy for content.

There is a Changelog.md in the repository root, which is a good sign, but the README does not describe what kind of change goes into it, and it does not document a deprecation window.

The versioning itself is disciplined in a way that helps. The workspace package version is 0.95.6, and the three core crates, theframework, rusterix, and scenevm, are pinned to the same 0.95.6 in the workspace dependencies, so the engine parts move in lockstep. Recent tags follow the same numbering, with v0.95.6, v0.95.5, and v0.95.4 published in the days around 2026-10-15, and the repository is not archived with the last push on 2026-10-15. Work is landing, but the version number itself says the project has not called itself stable.

## Procedural recipes, scepter and the character generator

Several parts of the tree point at the procedural content claim, and it is worth naming them since the README mentions procedural generation only in passing.

There is a crates/procedural_recipes member in the workspace, a top level file called procedural_recipes_concept.md, and a separate concept document called scepter.md alongside a crates/scepter member. A crates/character_generator member and a crates/icon_builder member round out the list of specialised generators, and the starter and test_projects directories at the root suggest there is reference content to work from.

The distinction between a recipe concept and a shipped crate matters. A concept document is a design note, and a crate in the workspace is code that compiles into the product. The presence of both says the procedural system is at two different stages at once, which is consistent with the overall picture of a project reorganising itself before a v1.

The ruleset crate is the other piece worth noting, since it separates game rules from the engine, and shared holds the common types used across the tree. The organicgraph and buildergraph crates suggest the world model is built as a graph structure rather than as a flat tile map, which is the kind of representation that makes procedural generation and 2D, isometric, and 3D views of the same world feasible.

The documentation does not describe the ruleset format or the graph format in enough detail to write an importer, so anyone planning to generate content outside the editor will be limited to what the tool exposes.

## Where Eldiron is the wrong tool

There are clear cases where choosing Eldiron is a mistake, and they are worth naming before anyone spends a weekend on it.

If you need a production pipeline for a commercial game with a team, a documented plugin API, and a stable export target, the documentation gives you no basis for planning around that. The tool is presented as a creator, which means the content format and the editor are the product, and those are the parts still moving.

If you want a terminal game or a headless server, note the split between creator and client. There is a clients/client-terminal crate in the workspace, but the README does not explain what that client is, what it renders, or whether it is a supported way to play.

If your interest is web deployment, the run-wasm member exists and the repository includes a run-wasm directory, yet the documentation does not describe a wasm build of an actual game, only the workspace member. Treat wasm as unverified.

Finally, a creator of this kind asks for a real time investment before it produces anything, since worlds are edited by hand inside the tool rather than generated from a text format. A team that needs to move fast on an isometric city builder will find that the tool's assumption of hand authored retro content works against it.

## Conclusion

Eldiron suits a solo developer or a small team that wants to author a classic tile based RPG inside one tool instead of wiring a general purpose engine to a separate map editor, and who can accept a creator project that is still rearranging its own internals. It does not suit work that needs a documented asset pipeline, a stable plugin API, or a shipped game format that will not shift between releases. Verify first that cargo install eldiron-creator and cargo install eldiron-client give you a working pair on your platform, and that the 2D or isometric mode you intend to use is the one the current version renders, since the renderer and editor are the two parts still being consolidated.

## FAQ

### How do I install Eldiron?

Download a pre-built binary for your platform from the GitHub Releases page, or install the two published crates with Rust present: cargo install eldiron-creator and cargo install eldiron-client. On Linux, libasound2-dev, libatk1.0-dev, and libgtk-3-dev must be installed first.

### Does Eldiron support 3D and isometric games?

Yes. The creator natively supports 2D in the style of Ultima 4 and Ultima 5, isometric, and first-person RPGs, and the same project can be viewed in those projections because rendering runs through the layer-based SceneVM renderer.

### What renderer does Eldiron use?

SceneVM is the main rendering backbone, an abstracted layer-based renderer for 2D and 3D built on wGPU where each layer can define its own geometry and compute shaders. The older software rasterizer in Rusterix still handles some in-game UI elements.

### Can I build Eldiron from source?

Yes. Clone the repository, change into the Eldiron directory, and run cargo run --release --package creator. The workspace uses Rust edition 2024 and builds creator, run-wasm, xtask, the three core engine crates, and the client variants together.

### What licence is Eldiron released under?

MIT. The documentation states that the source and all commissioned assets are MIT licensed, and that contributions submitted for inclusion are MIT licensed as well unless explicitly stated otherwise.

## Sources

- [License: MIT](https://github.com/markusmoenig/Eldiron/blob/master/LICENSE)
- [markusmoenig/Eldiron on GitHub](https://github.com/markusmoenig/Eldiron)
- [Project website](https://www.eldiron.com)
- [README](https://github.com/markusmoenig/Eldiron/blob/master/README.md)
- [Releases](https://github.com/markusmoenig/Eldiron/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/markusmoenig-eldiron