Runtime first
Kernel runtime, ECS scheduler, job safety, and stable boot/teardown rules are treated as production foundations.
Flagship product
Verth Engine is the first product in the Verthsoft platform.
It is being designed as a serious engine stack, not a renderer demo. Runtime, editor shell, build graph, plugin system, licensing, and launcher activation are all moving toward one stable production base.
Editor without hidden lag debt
The UI target is hard: fixed response, retained-mode rendering, virtualization, no drag stutter, and no blocking on heavy background tasks.
Shipping path included
Compile, bake, sign, package, and launch are part of the same system. The launcher is not a disconnected afterthought.
Architecture themes
What defines Verth Engine right now.
The UI architecture targets retained-mode rendering, virtualization, and fixed response within one frame even under heavy background work.
The build pipeline is designed as a DAG-driven orchestrator that compiles once, bakes runtime blobs, signs outputs, and packages per platform target.
The graphics stack emphasizes validation, offline shader compilation, pipeline caching, multi-queue thinking, and stable device-lifetime control.
world lifecycle
entity handles
allocator core
ecs archetypes
command buffers
render graph
offline shader compile
build orchestrator
plugin permissions
launcher contract
What it is meant to compete with
A modern engine stack with the ambition of Unity-scale workflow and Unreal-scale depth, but with a cleaner product spine.
That means less separation between editor, launcher, licensing, and build operations. The product story should stay coherent from the first sign-in to the final package.
A
For creators
One account, one launcher, one entitlement model, one production path. No fractured ownership of identity, billing, and engine activation.
B
For teams
Explicit contracts, deterministic build behavior, signed plugin surfaces, and clear operational boundaries for the future product suite.