Why Prune’s editor tools live inside the viewport

Screenshot of the platformer scene type in Prune, basic platforms and editor controls

Prune is a 2D game engine I am building where the editor and engine exist within the same runtime.

One editor, not three

One of the first major problems I needed to solve with the early prototypes was ensuring all the scene types were first-class citizens in the editor. I have spent a considerable amount of time ensuring that Prune is not three game editors disgused as one. Each of the scene types builds upon the same WorldScene foundation, the share the core editor shell and then add their own behaviour, tools and object semantics.

Although slow, this part of the design was pretty easy to solve, I had a vision of what I wanted and I made it happen.

What I wasn’t prepared for was how hard it would be to design the editor, both in thinking time and development effort

Unexpected design issue

I have recently started working on the tooling. Prune has moved beyond the simple creation tools for each scene type, I need to start adding the interaction tools users expect from a 2D game engine editor. I am starting with Select and Move, with Scale planned for sometime next week.

I mistakingly thought this would be quite simple, I already had tools, I just need to add a few more buttons.

Over the last couple of weeks I have gone through three seperate versions of the tool palette design before settling on the currrent design.

Finding the solution

I started with the tool palette below the main toolbar, it worked but didn’t feel right, the tool themselves were disconnected from the rest of the editor.

I then tried moving them into the same panel as the scene tools, that was wrong straight away, it made the scene type panels too big. It introduced scrolling which meant the scene specific controls were not visible, this is an existing problem which the additions made way worse.

The answer in the end was a floating tool panel above the viewport, I settled on the top right, the tools are near the other panels but seperated form the inspector controls.

It looked great, I had solved the prolem but it raised a major usability issue. The tool palette was a seperate panel, clicking the viewport brought the viewport forward hiding the tools behind the viewport.

After some research the fix was to move away from the tool palette being its own ImGUI panel, I needed to render it as part of the viewport itself. The tool palette is an overlay over the viewport, it is rendered above the scene and excluded from viewport hit-testing.

Dual mode tool palette

The tool palette had two responsibilites. The palette houses the general purpose editor tools and any creation tools specific to the scene type. For example, adding a platform in the platformer scene type or a wall in the simple shooter scene type.

The top half of the palette is interaction. You enable a tool such as Select or Move, and it remains active until you choose another tool.

The bottom half is immediate, you click and Prune creates an entity, records it in undo history, and leaves the selected interaction tool unchanged.

I expect this design to work well moving forward, the majority of the features in game engine editors are controls and flags in the inspectors, not buttons in the tool palettes

The current palette is tiny but it gives Prune a place for additional interaction tools, scale and rotate are next on the list.

The tool palatte also had the benefit of tidying up the scene type panels, I was able to move buttons out of the panels reducing all their heights.

Prune 2D Game Engine

A screenshot of the platformer scene type prototype in Prune. Multiple platforms, hazards, a spawn point and a character

Prune is a C++ 2D Game Engine where the game and editor exist within the same runtime. It is not trying to be a traditional engine where the editing happens in one mode and gameplay happens in another. The core goal is a play-and-build system where the editor is part of the runtime.

Prune has a shared editor shell. Different scene types reuse the main shell and then define their own behaviour, tools, panels, inspectors, object semantics, defaults and how to save their own data.

I pushed the initial commit to GitHub on the 2nd April 2026 and have been working on it steadily since then outside of my work and other commitments.

This is not my first attempt (Prune 2D) at building a 2D Game Engine in C++, I’ve tried a couple of times before; once from scratch and one using a template from The Cherno, a C++ YouTuber. Both previous attempts failed for the same reason, I leaned too far into building a general-purpose 2D game engine and all the required pieces, not what I needed and I didn’t even consider the editor.

Prune is different, this time the project has a clear purpose, I am building it for four reasons:

  • I have limited time to work on Prune. It is a hobby project so I need to be efficient with my time.
  • I want to improve my C++ knowledge.
  • I want to be able to build games with my children.
  • I want to create a system where the editor and runtime coexist.

The approach

My development approach is simple, I’m only plan a few phases each time, I’m always validating that everything works across of the game slices and I’m only developing the tools and features which are immediately useful to one or more game slices, or solve real UX problems.

The repository has an active record of what is happening, along with documentation explaining why decisions were, and were not made.

NOTES details what I will be working on in the short term and the goals for each phase.

DECISIONS is an ADR (Architecture Decision Record). The ADR details important decisions made during development. The most important entries are often why something is not eing done, along with the rationale behind it, these help me ground the project and retain focus.

The Goal

Prune has a specific goal which I have detailed above. The README includes a “Ready for users when…” section. My immediate larger goal is releasing a 0.x version of Prune, that section details what I need working before I consider the project ready for users at large.

I will blog more on Prune in the future, when I reach specific milestones, make important decisions or feel like explaining a more about the project.

I have not blogged for a few years, Prune felt like the right way to get started writing again.