lenitrous / sekai Goto Github PK

Sekai.Framework was made on a time where our engine architecture resembled a traditional game engine, however, ever since our re-architecting of the system, it doesn't make sense to name it as such as this was a legacy name back when we still have the Sekai.Engine namespace and we needed a distinction between low level and high-level systems, which we merged into one already.

An entity-component system is a design pattern used in many game engines. This allows great flexibility and reusability in code.

As our rendering engine is primarily for 3D, we'd need a basic rendering system that shows 3D models with lighting and shadows.

Currently execution happens on the main thread which we do not want!

Now we have a perfect picture of what we want + due to GH-49, we will be working towards using System.Numerics to reduce technical debt and to allow us to take advantage of .NET 7.0's improved mathematics library.

Despite having the same mathematics, Dot product can be unreliable when comparing against System.Numerics, which needs investigation later on.

Having DI would greatly allow us to componentize our systems allowing reusability between tests and in a normal game context.

Avalonia will be our backing UI system.

Once #2 has been formalized, it should be easy to add a PhysicsController to plug a physics engine. By default Sekai will have BepuPhysics but we should allow games to define their own by implementing the following first as a skeleton:

• IPhysicsController
• IPhysicsCollider
• IMeshCollider
• IPhysicsSystem.

This will lay the groundwork for our BEPUPhysics implementation, which should be released seperately.

Currently we're encountering various perf bottlenecks in debug mode, which shouldn't be the case, because it might also appear in production mode. We'll need to determine all bottlenecks currently to see which ones are the most breaking.

Currently our aim with the graphics API subsystem is to support as many devices as possible, but this comes with an additional cost that we must write new system-level APIs and abstract it over a high-level API. To reduce burden on Sekai's end post-Encore, we're exploring some avenues to simplify the graphics subsystem to achieve the following goals for Vignette:

• To create a single interface both engine-level and consumer-level (A game consuming Sekai through NuGet or a Vignette extension).
• Increase developer velocity by having one surface that =<2 developers could even maintain in a short notice.
• Share shader code with no need to write our own transpile (if possible).

Option A: Re-visit Veldrid

Currently @LeNitrous has expressed that we will re-visit Veldrid in some time in the future post-Encore, despite the friction Veldrid has given to us during the early days with Sekai's development. We're willing to give it a shot again since a lot has changed over the course of ~7 months.

Option B: Evaluate Dawn

Dawn powers the WebGPU implementation of Chromium and implements a native API that wraps around Vulkan, DirectX, and even OpenGL. Dawn implements the WebGPU standard, which means we will be able to take advantage of the commonality of Web Standards. In fact, WebGPU-based APIs tend to be used by Rust-based projects using the wgpu crate as it is a common and standardized API over native graphics APIs, reducing maintenance overhead for anyone working with native graphics.

The Evergine team maintains a WebGPU.NET library which is a 1-to-1 bindings with raw low level code, which is acceptable given that we will abstract this to be safer down the line as we usually do with our current implementation.

Currently we would have to implement animations by ourselves in any game we would have to do, causing non-standard behavior to happen such having different skeleton standards to work with per-game/application. As part of our post-Encore efforts, we should be able to implement an animation system for bipeds and for common transforms.

Despite being rendering-first, we'd also want to incorporate audio output and input with our framework.

(Unfortunately?) This may be delayed to Alpha 2, but it depends if our velocity will not be impacted.

Essentially we will be implementing a W3C-compliant user interface engine based on AngleSharp and ImageSharp, rendered and backed by our rendering backend. This allows @vignetteapp/web to help with the UI.

Our primary goal is to allow a Blazor-like API, which in turn, would allow us to write the ClearScript objects for it in scripting. Unfortunately we will not support JS inside the files, so it'll be full static JS-less UI.

Primarily, we'd want to use Vulkan. Thanks to Veldrid and Silk.NET, we are able to support other graphics backends. This should be a simple feat to accomplish.

We'd want to be able to interact with our game. While we can already read input, we'd want to implement a virtual keymapping system that maps certain joystick, touch, mouse, or keyboard inputs to a certain action and then be passed down via an event or a boolean flag that tells its state whether its down or not.

The test may pass 50% of the time. This is due to the fact that we are only blocking the thread using Thread.Sleep. It is preferrable that we block using semaphores for a more deterministic and expected result.

On some frameworks like MonoGame, a GameService acts as an additional "backend" or service that the game will use. This would be something like Websocket Server as a service, Game broadcasting, a spectator hub client, or anything. With that note, GameSystem should fulfill what people use Services for.