Current design decisions for my game engine:

Rie

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)

Rie

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.

Rie

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)

Rie

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.

Rie

(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)

Rie

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.

Rie

- 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

Rie

- 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)

Rie

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)

Rie

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

Rie

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

Rie

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

Rie

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.

Rie

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 🤔

Rie

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!

Rie

I guess there isn't actually a reason to give each window its own command buffer. And it's not like there's any multithreading involved or that windows would need to run at different framerates. So the window-specific data will be the surface, the swapchain, and the related release semaphore. Frames-in-flight will have one command pool/buffer each, and they'll record commands for all windows. Then each frame there's a single vkQueuePresent, handling all swapchains. Yeah.

Rie

Wait! But one of my monitors is 60Hz while the other is 144Hz! I _do_ want windows to run at different framerates or else windows on my main monitor will be bottlenecked by the other one! Ahhhhh

Rie

Ok after doing some research my preliminary conclusion is that the only way to reliably have multiple windows with independent refresh rates is to use multithreading, one render thread per window. Threads are a blind spot of mine that I've been meaning to overcome anyway, guess the time has come 🥴

Rie

Once I have my game engine where every panel in the editor is detachable I'll get a third monitor to make it worth the effort

Rie

Hmm I wonder if it's worth checking out Qt as well as an option for editor GUI... it seems like a heavy dependency but it might be more suited for what I want to do. ImGui is great for in-game debug UI but is not really meant to be used for a full application

Piero Bosio Social Web Site Personale

Current design decisions for my game engine:

Feed RSS

Gli ultimi otto messaggi ricevuti dalla Federazione

Post suggeriti

Bavaglio alla pagina Facebook di Articolo 21, interrogazione alla Presidente del Consiglio

Man Alarmed to Discover His Smart Vacuum Was Broadcasting a Secret Map of His House

"there are more than two types of people in the world" shouldn't be a controversial statement

This is unbelievable.