Skip to content
Vilanel
Roadmap

Now, next, and directional

Deliberately undated. This is my plan for my own engine rather than a commitment to anyone, and a date on it would be a date I invented for a reader who is not owed one.

Now3
Landing in current commits
Deeper animation graphsAnimation

Characters can now switch between animations with a proper blend, carry movement from the animation itself into the world, and mix several clips together based on how fast they are going.

More file formatsAssets

glTF is still the format the engine is built around, but it will now open FBX and OBJ as well. Asking someone to install Blender and convert a file before the engine will look at it is a worse answer than reading the format.

A more consistent editorEditor

The editor had four different tree views that had each been drawn separately, so they disagreed on spacing, icon size and text size. They now share one implementation. Right-click menus and asset previews are filling in the parts that were still unfinished.

Next3
Named in the plan, not yet built
Better collision shapesPhysics

A complicated object can currently have a rough collision shape that is cheap, or an exact one that only works when it does not move. Splitting it into several simple pieces would give you both. What exists covers most cases, which is why this has waited.

Other languagesInterface

Text that runs right to left, writing systems where letters change shape depending on what is next to them, and more flexible ways to arrange things on screen. None of it matters until the interface has to work in a language other than English, and all of it matters immediately after.

Previews for models and fontsEditor

You can see images in the asset browser. Models and fonts still show a generic icon, because previewing those means rendering them first, and that is a separate piece of work.

Later4
Directional, no dates
Let the compiler write itCore

Saving a file, filling the properties panel and surviving a code reload all need the engine to know what a type contains. It works that out at build time today. A future version of C++ can do it on its own, so the current version is kept behind a boundary and can be swapped without touching anything that uses it.

Threading built into the languageCore

Splitting work across processor cores is something every engine currently writes for itself. A future version of C++ makes it part of the language. The engine's version is deliberately small so that switching later is a small change.

LinuxPlatform

The code stays portable and a Linux compiler is kept working, but Linux is not a supported target today and no work on it is scheduled.

A scripting languageGameplay

C++ is the only way to write gameplay today. A scripting layer is planned, and the engine is already shaped to take one: it would plug in the same way any other part of the engine does, rather than needing anything unpicked first.

Behind it

The milestone table, finished

The design document was written before the first line of code, and it laid out twenty-three milestones running from a blank window to a working editor. All of them are done. The order is the interesting part, because it is what everything after each one had to be built around.

Planned milestones23 of 23 complete
February 2025August 2026Engine version 0.1.0
  1. 00A window, a graphics device, and a cleared screen
  2. 01A triangle, then meshes, then a 3D camera, then loading a real model
  3. 02Editor windows you can dock, and a profiler wired in from the start
  4. 03Gameplay code in its own library, reloadable while the editor runs

    Done early on purpose. This boundary shapes how everything after it is written, so finding out late what it needs would have meant rewriting the things built in the meantime.

  5. 04A scene of objects, parents and children, saving and loading
  6. 05The core renderer: physically based materials and lighting from an environment
  7. 06Shadows, many lights at once, and film-style colour handling
  8. 07Skeletal animation
  9. 08The editor: a viewport, a scene tree, a properties panel and move handles
  10. 09Turning source files into engine-ready data, and reloading it without a restart
  11. 10The in-game interface system: widgets, layout, text, keyboard and mouse
  12. 11A visual designer for building those interfaces
  13. 12Physics, and a character that walks around a level
  14. 13Sound, and pathfinding for characters
  15. 14Letting the graphics card decide what to draw, and smoothing the image over time
  16. 15Building a game you can ship, with the editor stripped out
  17. 16Textures and materials, compressed for the graphics card
  18. 17Making a level a file rather than code, so it can be edited without rebuilding
  19. 18Finishing the renderer: skipping what is hidden behind something else, transparency, and shadows for animated characters
  20. 19A real editor: play mode, undo, a log, an asset browser, and a window it draws itself
  21. 20A project is a folder anywhere on disk, not a copy of the engine
  22. 21The Hub: your projects, project templates, and installed engine versions
  23. 22Generating the saving and properties-panel code straight from the source

What the columns actually mean

Now is work that has landed in the last few weeks. Next is what the design document names as not yet built, which is a narrower claim than intending to build it soon. Later is what it says it is keeping an eye on, mostly future C++ features that would replace something already written by hand. Nothing in either of those two columns is scheduled.

The reasoning behind most of these lands in the devlog before it lands here.