Tyra: Strategy Towards Unreal Engine 6

The build tooling indicated that project-level modules did not currently contribute Verse, so I moved the experiment into a plugin. Verse requires a namespace to import against. Epic Games uses the domain-as-authority model, e.g., Verse.org and EpicGames.com. Personally I'm not a fan of domain-as-authority. Anyone that's tried to get a sane web domain since 2005 without 5-7 figures in cash to burn likely knows why. I went with just Tyra as an act of defiance and it worked fine. Alternatively I looked into it and brokers told me I could bid $8,000 for Tyra.org.

I defined the native Verse interface in a special .native.verse file. Both a native Verse binding and a native Scene Graph component were declared for this experiment.

I exposed a native C++ function to Verse.

Next I defined a native Scene Graph component with its own methods and lifecycle hooks in C++.

I made a scratch script to test it all from inside the engine. It uses the native function I created and does a few extra random things.

OnBeginSimulation occupies a role somewhat analogous to BeginPlay, although the Scene Graph component lifecycle has important differences. OnSimulate provides a coroutine-like execution path that can suspend, loop, and wait asynchronously for other things. It is vaguely analogous to Tick: you can create a continuous update loop inside it, suspending between iterations rather than receiving a conventional per-frame callback. At the time of this experiment I did not find an obvious equivalent to yielding until the next frame, so my tests simply resumed on a timed interval.

While I mentioned that Scene Graph currently looks and feels similar to Unity or Godot, there is one important distinction I am still unclear on. Game engines have overlapping concepts of scenes, worlds, and levels, but I tend to think in Unreal's terminology: a World is the outer spatial context in which the rendered scene exists, while a Level is a collection of Actors that exists within that World. At its root, Unreal fuses the World and Level together in a way developers can't separate.

Unity and Godot do not really have a first-class concept of a “level” in this sense. An entire level can effectively be another scene or node hierarchy streamed into an existing world, and technically a project’s worth of levels could all exist inside one persistent scene. It is not yet clear to me whether Unreal Engine 6 is moving toward something similar, where what we think of as a level becomes an entity hierarchy that can be streamed in and out without tearing down the larger world, or whether UWorld and ULevel will remain fundamental architectural boundaries as they are today. The current source contains hints in both directions, including transitional wrappers around some of these concepts, but not enough to establish where this leads.

Personally, I vastly prefer the idea of a level as just another prefab or node that can be streamed in, but it's very Epician to make the level a first-class concept in order to support enhanced rendering or streaming features.

The larger gameplay framework is considerably less settled. The current implementation still has a world-bound simulation_entity. In the source I inspected, the clearest architectural boundary currently appears around UWorld: the new simulation roots I found are world-bound, while UGameInstance remains outside them. For Tyra, one workable bridge would be native component methods that query application state through UGameInstance, or facade components exposed at the root of the Scene Graph.

Further down the stack, however, the shape of a replacement gameplay framework is much easier to see. Player and possession abstractions already exist around entities, but some of the important possession operations are still internal. Networking is clearly being designed into the system, as is the separation of presentation between players, but the public surfaces for authority, prediction, ownership transfer, RPC-like gameplay communication, and presentation are not complete enough for me to design around with confidence. I also found no clear Scene Graph replacement for Enhanced Input, although native C++ provides an apparent path for bridging existing input infrastructure into Scene Graph components.

One note I had was that Scene Graph components are currently backed by UObject. A compositional architecture naturally encourages larger numbers of smaller, more granular components, while UObjects are contextually heavy in Unreal Engine 5, particularly because garbage collection cost can become noticeable based simply on the number of objects being tracked. If this representation remains substantially unchanged, I would be concerned that aggressively composing large worlds from many small components could reproduce or amplify the familiar periodic GC hitch without significant improvements to object management.

It is too early to draw conclusions from the current implementation. Scene Graph is visibly transitional, and Epic is already experimenting with alternative GC approaches. The eventual component representation may become lighter and more data-oriented, or UObject itself may become considerably more scalable. In Unreal Engine 4/5, the UObject backing of ActorComponents encourages them to be much more individually comprehensive than a heavily compositional architecture would naturally want.

One of my first concerns was how much control remained on the native side. Tyra is currently predominantly a C++ framework, with scripted game events running on Blueprints that leverage latent nodes backed by C++ coroutines. A future in which Verse became the primary gameplay language while native development was restricted to whatever functionality Epic chose to expose would represent a significant architectural limitation.

What I could establish is that native C++ and Verse are not fundamentally isolated systems. From the perspective of this experiment, the relationship felt surprisingly similar to Unreal's familiar C++/Blueprint boundary: native systems can expose functionality upward while gameplay behavior can be authored in Verse around them. Implementing that boundary was considerably more straightforward than I expected. Compared with embedding and binding an external scripting language like Lua into C++, the integration felt very easy with minimal boilerplate.

I went into Verse having heard much of the surrounding discourse: that it was ugly, bizarre, overly functional, Haskell-like, or simply alien compared with the languages game developers were accustomed to. My initial experience was almost the opposite. In practical use I found it immediately recognizable as another scripting language, somewhere between a simplified C# and Python, with object-oriented structures alongside prominent asynchronous and coroutine-like concepts. Whatever unusual ideas may exist deeper in the language, nothing I encountered while building ordinary gameplay components felt particularly unconventional or difficult to reason about.

I came away considerably more optimistic about the language itself. Verse may be a somewhat unusual amalgamation, but I can see the beginnings of something approaching an "ultimate" game scripting language, in the sense that it appears informed by Epic Games' unusually deep experience with the requirements of large networked modern games.

The metaverse ambitions historically associated with Verse are easy to dismiss because the term itself has accumulated so much baggage, but I take those ambitions less as a requirement to believe in any particular vision of the metaverse and more as evidence of the scope the language is attempting to address. Persistent worlds, concurrency, networking, simulation, composition, failure, and code that must remain manageable as projects become enormous are ambitious requirements regardless of whether they are ultimately used to build a metaverse, an online game, or a conventional single-player. It feels like an inspired foundation for sophisticated modern games.

A concern regards Verse's networking model. After looking into how Verse operates practically in UEFN, I can't fully make sense of its replication approach in the context of broader development inside Unreal Engine. My netcode background isn't strong enough to fully fathom it. My current understanding of Verse in UEFN is strongly server-authoritative, and I have not yet been able to map that model cleanly onto the more familiar Unreal concepts of replicated Actors, ownership, prediction, and client/server RPCs.

There isn't enough exposed code yet for me to reach a confident answer, but I'd flag this as a concern for my timing. In current Unreal Engine 5, it's straightforward to design single-player systems in a replication-friendly way, leaving room to later add multiplayer side-modes around what's fundamentally a single-player game. I don't yet know the form of Verse's replication model in an engine context. I simply cannot plan around it because of this.

Verse replacing or displacing Blueprint as the center of gameplay authoring is likely to be one of the more controversial aspects of Unreal Engine 6, and I can sympathize with that. An enormous amount of expertise, tooling, accessibility, and established workflow has accumulated around Blueprint, and the reasons people like visual scripting are entirely valid.

The colder engineering argument is that textual source provides a stronger long-term foundation for ambitious authoring, maintenance, version control, search, reuse, large-scale refactoring, source review, and increasingly AI-assisted development.

Anyone who has followed a substantial node graph tutorial like Blueprint, Substance Designer, Geometry Nodes, Houdini, etc. also knows the other side of visual programming: watching a video at 1/16 of its normal speed for hours while reproducing nodes, wires, parameters, and values. The slowed-down playback turns the background music and narrator into something faintly horrifying over the course of an hour. Visual systems can make logic approachable, but they can also make that logic unusually difficult to communicate. Sharing knowledge was already a major problem with visual scripting, and as AI increasingly becomes an interface through which we author code, I suspect visual scripting's decline is inevitable.

I expect this shift across many platforms and programs, and it is worth emphasizing that experience with visual scripting is still programming experience. The skill is learning to design software systems, and that work ultimately happens in your mind. The language or style used to encode a program is just notation, like the paper and pen an author uses to write down a story.