Proposal: EditorView vs GameView

[miogds]

Background & Problem

While working to make Untold Engine compatible across all Apple platforms, I’ve run into a recurring issue: much of the editor functionality is tightly coupled with macOS-specific code. To prevent errors, I’ve been forced to rely heavily on #ifdef directives, essentially excluding editor-related code on platforms where it doesn’t make sense (tvOS, watchOS).

This creates unnecessary complexity and reduces portability. For example, deploying to Apple TV or Apple Watch should focus solely on running the game (rendering and game logic), not on editor functionality that will never be usable on those platforms.

---

Proposal: Separation of Concerns

I propose splitting the engine into distinct layers of functionality:

1. Render Layer

• Core rendering capabilities: 3D rendering, animation, scene graph (Scene Node Builder), colors, and lighting.
• Lightweight and portable.
• Usable on all Apple platforms, even constrained ones like watchOS or tvOS.

2. Game Layer

• Builds on top of the Render Engine.
• Adds support for multiple views, input handling, physics, networking and game logic.
• Intended for platforms where actual gameplay makes sense (macOS, iOS, iPadOS, tvOS, VisionOS).

3. Editor Layer

• Superset of the Game Engine.
• Adds editor tools, asset pipelines, debugging utilities, simulation inside the editor, and the ability to swap between EditorView and GameView (similar to Unreal Engine).
• Focused on macOS, iPadOS, and potentially VisionOS—platforms powerful enough to support editing workflows.

This separation allows each compiled target to include only the necessary code, reducing complexity and build size, while maximizing platform relevance.

---

Benefits

• Clean Platform Support: No more clutter of #ifdef macros for excluding editor-only code.
• Optimized Builds: Lightweight builds for Apple Watch or Apple TV (Render/Game Engine only).
• Future-Proof: Ability to expand editor support to emerging platforms like VisionOS (where being early could differentiate us).
• Developer Experience: Clearer architecture—developers know which layer to work on, extend, or optimize.

---

Implementation Approach

1. Audit the current codebase to identify functionality that belongs exclusively to the editor.
2. Establish a modular design where:
   • Render Layer is the lowest layer.
   • Game Layer depends on Render Engine.
   • Editor Layer depends on Game Engine.
3. Define EditorView vs GameView:
   • EditorView: Full editing tools, game simulation inside editor.
   • GameView: Pure game runtime, deployable to lightweight platforms.
4. Initial focus: Decouple editor functionality from game runtime (reduce platform conditionals).

---

Future Possibilities

• VisionOS Editor: Being among the first to provide a native game editor in VisionOS could be a significant innovation.
• Cross-Device Workflow: Developers could edit on macOS or iPadOS, then instantly test on tvOS, iOS, or VisionOS.
• Standalone Builds: Streamlined packaging for games that don’t carry unnecessary editor overhead.

---

Architecture Diagram

Platform Support Matrix

The following chart shows which layers of the Untold Engine are relevant to each Apple platform:

Platform	Render Layer	Game Layer	Editor Layer
watchOS	✔️	—	—
tvOS	✔️	✔️	—
iOS	✔️	✔️	—
VisionOS	✔️	✔️	✔️
iPadOS	✔️	✔️	✔️
macOS	✔️	✔️	✔️

---

Summary

By splitting Untold Engine into Render (library), Game (library), and Editor (standalone application), we gain portability, cleaner code, and flexibility across all Apple platforms.
This modular approach ensures that each platform only carries the functionality it needs—making the engine lighter, more efficient, and more scalable into the future.

[untoldengine]

Totally agree. This has been on my backlog since the editor first landed. The core runtime (rendering, physics, collision, input) is already independent of game logic, which is initialized via a GameScene and importing UntoldEngine. The gap is that editor code is still interleaved with macOS specifics, which forces #if os(macOS) fences across the codebase.

I plan to extract all editor/UI and macOS-only services into a separate UntoldEditorKit module (macOS-only) and keep the core (runtime) platform-agnostic. Targets like iOS/tvOS/watchOS will build only the runtime; macOS will build the runtime + editor. Goal is to eliminate #if os(macOS) from the core, simplify the build matrix, and make tvOS/watchOS deploys purely “playback” (rendering + game logic) with zero editor baggage.

[miogds]

Do you want me to start working on the split and you review later in the pull request or do you want to do by yourself?

[untoldengine]

That would be great—please go ahead and start the split, and I’ll review PRs.
Thank you!

[miogds]

Plan of Action

I’ve created a new branch in our fork: editor_separation.

While moving the code and working to make the editor compile again, I also reviewed the globals and functions (most of which are global functions).

At this point, the branch compiles, but I think some cleanup is needed. I plan to:

• Add more function pointers and calls to the core engine to make it more customizable (e.g., for the editor, which currently includes pipelines not needed in the game or render versions).
• Introduce configuration structs to centralize options and improve engine flexibility.

---

Immediate Focus

My first goal is to establish a clear solution for adding a SwiftUI view capable of rendering graphics. This render layer should be compatible across all Apple OSes.

I’ll expand the renderView (or whatever name we choose later) to support multiple render views with different steps or configurations. Since the engine currently relies heavily on global variables, I will begin isolating the most critical ones.

---

Next Steps

• GameEntity: I’ll implement a GameEntity that can hold one or multiple render views. This will allow flexible setups, such as a game selection screen and the game itself, each with different views and configurations.
• Editor: Afterward, I’ll focus on evolving the editor into a full application. It should be able to host both the editor entity and a game instance (GameEntity), while adding the necessary tools and features for game development.

---

Long-Term Vision

The idea is to enable independent work across several layers of the engine. To support this, I’m building a SwiftUI demo with the first layer, ensuring it runs seamlessly on every Apple OS.

[miogds]

Editor Package Separation from Engine - Initial Implementation Plan

Overview

I will implement the first phase of separating the Untold Engine editor from the core engine library. The goal is to create a clean separation between editor-specific functionality and the game runtime, allowing for smaller binary sizes and platform-specific optimizations.

Approach: Mirror and Extend

The current approach will use a "copy-and-extend" pattern where editor-specific code will be moved to a new UntoldEngineEditor package that mirrors the engine's folder structure:

Sources/
├── UntoldEngine/           (Core engine - will be platform-agnostic)
│   ├── ECS/
│   ├── Mesh/
│   ├── Renderer/
│   ├── Systems/
│   └── Utils/
└── UntoldEngineEditor/     (Editor-specific code)
    ├── Editor/             (UI Views)
    ├── Renderer/           (Editor rendering extensions)
    ├── Systems/            (Editor systems)
    └── Utils/              (Editor utilities)

Key Changes

1. Editor UI Migration

All SwiftUI views will be moved from the engine to the editor package:

• AssetBrowserView
• InspectorView
• SceneHierarchyView
• SceneView
• GamePlayControlsView
• And all other editor UI components

2. System Separation

Editor-specific systems will reside in the editor package:

• GizmoSystem
• HotReloadingSystem
• VisualDebugger
• Editor-specific extensions to Camera, RenderingSystem, and InputSystem

3. Platform-Aware Compilation

The engine will use conditional compilation to support multiple platforms:

• iOS: Game runtime only (gameMode = true by default)
• macOS: Full editor support (gameMode = false by default)
• Separate input system implementations for AppKit (macOS) and UIKit (iOS)

4. Rendering Pipeline Split

We will create separate render graphs:

• Game Mode: Standard rendering pipeline for games
• Edit Mode: Extended pipeline with editor-specific passes
  • Gizmo rendering
  • Entity highlighting
  • Debug visualizations
  • Light volume visualizations

Rationale for This Approach

1. Maintaining Structure Parity

By keeping the same folder structure between engine and editor, we will ensure:

• Easy navigation and understanding of where code belongs
• Clear mapping between engine systems and their editor extensions
• Simplified future refactoring when we identify shared abstractions

2. Fast Initial Split

This copy-first approach will allow us to:

• Quickly achieve a working separation
• Avoid premature abstractions
• Identify what's truly editor-specific through practical use

3. Platform Benefits

• iOS apps will be able to use the engine without any editor overhead
• macOS will retain full editor capabilities
• We will achieve reduced binary sizes for game-only deployments

Implementation Details

Build Configuration

• The editor will be a separate Swift package target
• Platform-specific dependencies will be properly isolated
• Shared code will remain in the core engine

Code Organization

// Engine side (platform-agnostic)
public var gameMode: Bool = {
    #if os(iOS)
    return true
    #else
    return false
    #endif
}()

// Editor side (macOS only)
#if os(macOS)
extension UntoldEngine {
    // Editor-specific functionality
}
#endif

Temporary Solutions

Several aspects will be temporary in this initial implementation:

• Some code duplication between engine and editor
• Commented gameMode checks to be refined later
• Simple extension patterns instead of proper abstractions

Expected Outcome

The editor will compile and run as a separate macOS executable, while the core engine will be usable independently for games on both platforms. The separation will be functional but intentionally kept simple for this first iteration.

Benefits

1. Reduced Binary Size: Games won't include editor code
2. Platform Optimization: Each platform gets only what it needs
3. Clear Boundaries: Explicit separation of concerns
4. Faster Iteration: Editor and engine can evolve independently

Next Steps

This will be explicitly a temporary solution designed for speed of implementation. Future improvements will include:

1. Identify Common Abstractions

   • Find patterns that can be shared
   • Create proper interfaces for extensions

2. Optimize Build System

   • Better modularity
   • Faster compilation times
   • Cleaner dependency management

3. Refine Boundaries

   • Clear APIs between engine and editor
   • Plugin architecture for editor extensions
   • Better separation of rendering pipelines

4. Documentation

   • Architecture diagrams
   • Migration guides for existing projects
   • Best practices for engine/editor development

What do you think?

[untoldengine]

Thanks for putting this together — the proposal is very clear and I like the pragmatic "copy-first, refine later" approach. It’s a good step toward keeping the core engine lightweight and giving us flexibility across platforms.

One comment though, you mentioned "Rendering Pipeline Split". Currently, the pipelines are split between edit and play mode. Are you planning to make further modifications?

Overall, I like this. Thanks

[miogds]

Good question! I thought about it, and my first idea is to have 2 Views (subclass from SceneView), one for the game pipeline and the other for the editor pipeline, which are initialized with different pipelines. As soon as you click “play," we switch the Views. We stop one and run the other or vice versa.

That means I will change a little bit how the init pipeline works to remove the if gameMode == true ... inside the renderer. The idea is that every view / SceneView can have a custom pipeline init, so it depends on the project whether to add or remove the pipelines you need. If you don't specify any pipeline, it will load the default ones. For example, the editor will load all default ones plus the specific editor ones so we will not need to use the gameMode var inside the renderer code.

[miogds]

Another question,

I already did the split of the editor on my branch, but even though it's compiling and running (well kind of running because I had to comment some things out, I found that the SceneView has no folder!

I moved all the related editor stuff to the new target, but SceneView is the only one I use for the Swift demo to hold the renderer... so where can I put the file? inside the Render folder, inside the ECS folder? in a new folder?

[untoldengine]

mmm. what if we place it in the Utils folder?

[miogds]

This PR is for splitting the editor so there's only the SceneView, but in the next PR I will need to create a new folder to put all SceneBuilder stuff and maybe it's better to put it there. For this one I guess I will create the new folder to be ready for the next PR

[miogds]

This PR is becoming complex. I tried to minimize the changes to have a working commit, but moving from several global variables to a more component approach and extensibility required a lot of changes. Also, I had to implement singleton patterns in the LoadingSystem and InputSystem to be able to be customizable for the project, game, or the editor and still have a point of access to all global functions, which still requires access to those systems.

I think this PR will be ready tomorrow as I already have the editor working like a standalone project. I still need to figure out some input bugs.

[miogds]

One question, after the split, I don't fully understand why you have 2 cameras, the scene camera and the game camera? What is the purpose of that? I'm learning how the code is structured as I'm doing the splitting but as far as I understand, in the editor, we need just the editor camera ( is the scene camera? ), and when we play, switch to any active game camera, but why are both created in the UntoldRenderer init?

[untoldengine]

Good question, thanks for bringing it up.
The idea behind having both a scene camera and a game camera comes from the editor vs play mode distinction:

• Scene Camera (Editor Camera):
  This is the camera you use when navigating the scene inside the editor. It lets you orbit, pan, and inspect the level without being tied to the cameras that exist in the game world.
• Game Camera(s):
  These are the cameras defined by the user inside the scene (e.g., a third-person camera, first-person camera, cinematic shot). When you hit Play, the engine switches to whichever game camera is marked as active.

Right now, both are created during UntoldRenderer.init just so the renderer has valid defaults and doesn’t run into a “no camera” state. It ensures the scene view is always renderable, even before a user adds their own game camera.

That said, you’re right that in practice, when editing, you really only interact with the scene camera, and when playing, you switch to a game camera. This is something we can make clearer in the code comments and initialization logic.

We could move the creation of the default game camera so it only happens when entering Play Mode, or at least make it explicit in the docs/comments that the extra camera is a placeholder. That way, it’s less confusing for contributors looking at the code.

[miogds]

OK. I will create the scene camera in the editor only. While in a normal game, I will create a game camera if no one is found.

[miogds]

The new Editor standalone package will need an app icon. :)

I will try to put one of the designers on top of that. Any preference about the style or design?

[untoldengine]

This is exciting!!!

Thanks for bringing it up!

I don’t have a strong preference, but I’d like it to feel consistent with the spirit of the engine: simple, modern, and creative. Something that communicates “3D / rendering/creation” without being too busy.

I’m completely open to ideas/suggestions, though.

[miogds]

I will try to put the graphics designer to work on that, and I will present you with the options.

[miogds]

Good news here! I already finalized a branch that I have fully working (as the develop brach is working) the editor. Still, I don't want to commit because I took at the beginning some considerations that I don't like how I did at the beginning, so I will rewrite it in more simple ways. I will push the PR tomorrow morning so you can review.

[untoldengine]

Awesome. thank you

[miogds]

Well, well — the first version of the editor package is done! 🎉 I’ve pushed the PR.

There’s still work to do on several redesigns (like the input systems and so on), but for now everything runs as it does on the develop branch. I made some design decisions that we might revisit in the future, but at least we now have a stable foundation to keep building features and improving the editor. This also makes it easier to expand runtime/game functionality.

One thing I still need to address is the plug-in system. It’s not working at the moment — I had to comment it out in the demo app because the editor is now a separate entity from the core. To support it, I’ll need to create an editor plugin extension, but I need more time to figure out the best approach.

[miogds]

@untoldengine Now that the editor has his own repo, I think we should put all related things, ideas, discussions, etc., in that repo, but I didn't see any discussion tab there, or do you want to keep all the discussions in the engine repo?

[untoldengine]

I enabled a discussion tab for the untold editor repo.
Thanks