Hello! Welcome to the first ever progress report for Elegy, and a happy New Year! As I'm writing this, I hear fireworks non-stop. I've been writing very summarised versions of these on Knockout for quite some time, but here I can go all out.

I'll be talking about all the stuff that happened in 2024. So, let's go chronologically.

I have been messing around with Roslyn's C# API lately, and I've found it to be quite useful for my vision for Elegy's scripting system.

For years I've been observing a few C# scripting solutions like CS-Script and recently Westwind.Scripting, however those did not quite fit the bill.

Introduction​

In essence, from a gameplay programmer's POV, Elegy is structured like so:

• Framework & launcher - the core/platform stuff, you would never touch this unless you're adding console support.
• Engine - the engine modules, asset system, console system etc. You would also likely never touch this.
• Game SDK - this hosts all the game systems, the client-server model, and other game things.

Finally, it was about time I talked about this as well. Elegy's UI system.

In short, while ImGui is fine for debug menus and such, it's not really adequate for extensive in-game and tooling menus. Solutions like RmlUI are good for in-game GUI, however it's in C++. I would prefer a C#-only solution.

I figured, it wouldn't be a bad idea to tackle this problem myself. Essentially, build a lightweight UI library without too many fancy features. Something that will be good enough for basic game GUI needs as well as basic app/tool needs.

Besides, I've wanted to explore some alternative approaches to UI, and hopefully make it fairly data-driven too. It would be driven by C# scripts, as described in the scripting system blog.

The kinds of games I wanna make on Elegy will occasionally feature relatively large (1.5 km × 1.5 km), sandboxy maps. Landmarks, vegetation, interactive objects, all kinds of things. But there would also be plenty of indoor sections.

So, since 2021 (the inception of BurekTech X) I've thought about occlusion culling systems that could work either real-time or be baked, preferably utilising the GPU as much as possible, and scaling with level size and varying densities of detail.

This will be another pretty technical post, so prepare your imagination for this one! Yeah.

I've always envisioned multiplayer to be part of this story. Ever since I wrote the first design document for BurekTech X, and later for Elegy, I've viewed basic "multiplayer with friends" as something that should be an out-of-the-box feature.

By this, I don't mean an MMO-scale thing or even support for an official-ish system involving a master server and whatnot, no no, I just want to provide very basic "join this IP address" multiplayer which could later be extended to support Steam's P2P thingy. Ultimately, those are the kinds of games I wanna make on this, a singleplayer + multiplayer experience, whether the latter is co-op or deathmatch or whatever gamemode.

Elegy's entity system could've directly copied Half-Life's, having a class hierarchy and a base entity class that supports a lot of stuff out of the box. However, this path has a few issues:

• cannot mix'n'match traits (e.g. door + breakable)
• is cache-unfriendly
• potential of bloat by dozens of unused member variables

So, I've decided to research a bit and it seems with some clever design and an ECS library, we can reap the benefits of both approaches.

Entity system requirements​

Fundamentally, entities can undergo the following interactions:

• Spawned:

Docusaurus moment.

This is epic, I've just started using this library/framework I suppose.

Just need to figure out how to deploy this eventually.

Elegy's designed to be pretty modular in some regard. If you don't need game-specific world rendering, you can still use the render backend. You can still use the shader templating system and all of that. That, at least, is the idea.

So I've decided to write a bit about rendering architecture here again and what I wanna have by the end of the year. Simply put, here are the layers:

• RenderBackend - Vulkan stuff, shader templating business
• RenderSystem - defines renderable object types (meshes, materials, lights, views etc.), provides facilities to actually use shader templates and generate resource sets for them and such, TL;DR handles "mid-level" rendering stuff

I'm cataloguing my thoughts here about VR integration in the future.

Goals​

• OpenXR integration
  • I prefer this to OpenVR or anything else, as I have the impression it's the most widespread thing a.t.m. A bit similar to my choice for Vulkan: one size fits most!
• Stereo rendering
  • Basically rendering two views, one for each eye. There is a small technical challenge in this.
• Plug'n'play
  • This would be an optional plugin to the game SDK and shouldn't require too many modifications to the engine itself.
• Mobile VR
  • Ideally this should run on standalone headsets like the Quest and Pico.

and other pipeline shenanigans...

In this idea I'll talk about:

• Material templates (abbr: MT)
• "Polyshaders" (abbr: none)

Problem: modern rendering APIs (DirectX 12 and Vulkan) have something called pipeline state objects (abbr. PSO), which I'll call "pipelines" from now on.

The idea is that various things you could dynamically configure in OpenGL (face culling mode, fill mode, blending mode, depth testing, the shader program etc.) are known in advance. In the world of dynamic shader generation from material node setups, this doesn't exactly fit so well: