Current design decisions for my game engine:

[tracefree@mastodon.gamedev.place]

Current design decisions for my game engine:

- NOT a general purpose engine, it'll be tailored to the kind of games I want to make
- Open source
- C++23
- Vulkan 1.3
- SDL3 for windowing, input, filesystem interfacing, possibly audio
- Slang as shader programming language
- Jolt physics
- Split into core engine library, game application, and editor application
- Dear ImGui for the editor UI
- Maybe Luau for gameplay scripting?
- Powerful and accessible modding possibilities

[tracefree@mastodon.gamedev.place]

Goal for the weekend will be to draw the first pixels on the screen. Might take longer though since I want to focus on proper architecture and abstraction from the beginning.

Then I think I'll integrate Dear ImGui and play around with it. I want the UI to be as flexible as Blender's: every panel can be moved, resized, hidden, replaced, be a floating window, etc. And configurations can be saved and named, to support all sorts of workflows

[tracefree@mastodon.gamedev.place]

Types of panels I'm thinking of: 3D viewport, asset browser where you can search by tags, scene hiearchy tree, property/game object inspector, graph editor for dialogues and for complex animation blending, etc.

Animation programming is one the most important aspects to me and one I'm looking forward to tackling!

[tracefree@mastodon.gamedev.place]

Also I want a preview of shaders and support hot reloading them.

In-editor code editor is out of scope, won't reinvent the wheel there and just use an actual IDE for that.

[tracefree@mastodon.gamedev.place]

Rendering goals:

- Forward+, at least in the beginning
- Bindless
- I'm considering going all in on raytracing, and add fallback solutions for shadows etc only later
- GPU driven rendering, wanna minimize the amount of CPU to GPU communication to a minimum
- I guess I'll do PBR, at least until I have a more creative idea or find a stylization I like
- Photorealism is NOT a goal, but I do want shadows to not look awful
- Targeting medium vertex density for meshes
- 3D only (except UI)

[tracefree@mastodon.gamedev.place]

For input management I might take heavy inspiration from the OpenXR API. I like how it enables extreme flexibility for remapping actions by players.

Speaking of OpenXR... I know the scope is already huge but this is gonna be a lifelong project anyway. VR integration is a stretch goal (_if_ I can even get my VR headset to work properly on Linux and find a way to make it comfortable to wear)

[tracefree@mastodon.gamedev.place]

To be fair basic VR support should be pretty straight forward. The OpenXR runtime does most of the heavy lifting, you just need to render two images (for two eyes) and hook up the head position to the camera. The hard part is making good controls that don't nauseate people and gameplay that makes sense for VR.

[tracefree@mastodon.gamedev.place]

Regarding licensing: My thinking so far, and it may change in the future, is open source editor, open source game application (at least the parts written in C++), but the actual game data like assets, quests, levels, gameplay scripts etc. will be non-open (but allowed to be modifed and redistributed when it's for a free mod for the game)

License is currently set to MIT but there is a non-zero chance I'll go copyleft at some point. (Or even closed-source, not committing to anything yet)

[tracefree@mastodon.gamedev.place]

Ah, and I should mention the primary goal of the engine: maximum moddability. Much of what drives me here comes from playing Dark Souls and thinking "man, I really wish this were as moddable as Skyrim"

The editor I'll use to make levels and quests etc. is the same one that modders can use to extend the game. That's why it must be easy and fun to use and learn. Modding shouldn't be restricted to technical people.

[tracefree@mastodon.gamedev.place]

(this thread is brought to you by a sleepless night where I could not rest until I got up and wrote down all my hopes for the engine in a notebook. Anyway time to get back to waking reality and actually follow through)

[tracefree@mastodon.gamedev.place]

Ok I'm way too tired to code (or to be awake at all, really) so here's more non-goals instead. They're just as important to define as goals after all.

- No mobile support. Android GPUs work differently and supporting them has major implications for the engine architecture. Do not want to deal with all that. Best explained by this official manga by ARM: https://interactive.arm.com/story/the-arm-manga-guide-to-the-mali-gpu/page/2

- Similar story for web. Browsers are a pain to support and I don't care about them.

[tracefree@mastodon.gamedev.place]

- Multiplayer: I'm actually not ruling out the possibility of it later, but I have no immediate plans for networked multiplayer support. And since adding it later is very difficult if not planned for from the beginning I will likely never do it. But who knows what rabbit holes I get sucked into in the coming years :D

[tracefree@mastodon.gamedev.place]

- Espresso: There are no plans for the engine to support brewing coffee of any kind, even if you manage to install it on a smart coffee machine.

(I should really go to bed now)

[tracefree@mastodon.gamedev.place]

I had intended to roll my own logging, but I've heard enough people recommend spdlog that I'll probably use that (but with my own wrapper code around it)

[tracefree@mastodon.gamedev.place]

Also regarding embedded scripting language besides Luau I will also evaluate Angelscript, and look for more options. Requirements are:
- Fast JIT compilation
- Battle tested
- Secure sandboxing (to support modding)
- Easy integration with C++ codebase
- Static typing

[tracefree@mastodon.gamedev.place]

I thought about using VK_EXT_shader_object again but I did some more research and it seems the extension, which would make life easier by eliminating pipelines and making _all_ state dynamic, needs more time in the oven. It has some bugs in the drivers that support it natively, isn't guaranteed to be as performant as using pipelines, is missing some features like raytracing support, etc. So I'll stick to pipelines after all for now

[tracefree@mastodon.gamedev.place]

We have pixels! It's only earlier than anticipated because I hardcoded a graphics pipeline after all instead of doing abstraction first. And it was good, now I have a much better idea of how I want the abstraction to work.

Btw ImGui's docking functionality is great :D

[tracefree@mastodon.gamedev.place]

So typically, tutorials will tell you to create one Renderer class that holds everything - VkInstance, VkDevice, the graphics queue, frames-in-flight data like command buffers, semaphores, fences, swapchains etc. This is a good starting point.

Now I'm thinking about how to split all this up to support multiple windows with multiple viewports that can be rendered to. The game won't need multiple windows, but the editor does.

[tracefree@mastodon.gamedev.place]

So, I want to support having multiple windows. #ImGui has a "multiviewport" feature for that where the ImGui context can be shared, but it's not supported under Linux with Wayland. So my only option is initializing multiple ImGui contexts and rendering them separately.

That's all fine. I'm just wondering if doing so will prevent me from doing drag-and-drop operations with ImGui across windows 🤔

[tracefree@mastodon.gamedev.place]

Guess I'll just use multiple contexts for now and not worry too much about drag and drop. I don't need it super badly to move panels from one window to another, and for simpler stuff like dragging a resource over everything _should_ be able to be handled with lower level API.

The refactor is interesting - there's different swapchains but still only one thread so using fences correctly will be fun!