بداية رحلة تطوير محرك ألعاب

مقدمة

قررت لسبب ما إني أخيرا ابدأ رحلة تطوير محرك ألعاب خاص بي.

أنا جديد إلى حد ما في مجال برمجة المحركات، بغض النظر عن بعض المساهمات لمحرك جودوه زي

Vertex Shading:

PR: https://github.com/godotengine/godot/pull/83360

Blog Post: /ar/blog/update-on-my-vertex-shading-pr/

Blender import geometry nodes:

https://github.com/godotengine/godot/pull/87735

فأنا غير كده خبرتي ضعيفة في برمجة المحرك نفسه، بمعنى الأساس بتاعه والنواة والتصميم.

ودلوقتي لأهم سؤال:

ليه ؟

أولاً وقبل كل شيء، هذا الأمر يخصني شخصيًا، فأنا أحب التعرف على ما يحدث في الأدوات التي أستخدمها، وأحب أن أتمكن من تعديلها، فأنا ببساطة أحب الاستكشاف والتعلم!

ثانيًا، ربما يصبح هذا محركًا آخر مفتوح المصدر (لأنني أخطط لجعله مفتوح المصدر في النهاية)

الأهداف

1- Cross platform (meaning windows, linux, macos, android, ios and even web)

2- can be exposed to any language (use C)

3- cross compilation (so I used zig as the build system)

4- easily package your game to all supported platforms

5- focus more on performance & new features than compatibility (Godot already fills the compatibility part)

6- self contained engine (no external libraries unless totally necessary like X11/Wayland) which also means I will do everything from scratch (UI system, platform backends, etc)

أفكار زيادة:

7- Blender’s geometry nodes like system (Procedural Geometry System)

8- Visual Shader system (converts to the written shaders)

9- Import blender files & convert GeoNodes/Shaders to engine’s equavilants

10- Path Tracing Renderer + Raster Renderer (path tracer will be for producing animations & sims, as I plan to use this engine for such applications, and the raster is for the game engine part of course)

الأدوات والتصميم\هندسته

languages: C & Zig

C for most of the engine code, this allows the engine to be compiled and expose an API to any language

Zig for the Editor & Game Scripting

future: YScript for game scripting (YScript is a scripting language that I am planning to implement one day in this engine, and the editor of the engine will be able to read/write the script using Node Based Approach -Unreal’s Blueprints like- or just as a script -Godot’s GDscript like- this script will then have two modes:

1- interpreted mode, this mode will always work when working in the editor, for fast prototyping

2- compiled mode, this mode will trigger when you export your game, basically all of the YScripts will convert into zig source files and compile normally with other zig scripts.

Now for the backend: curruntly I plan to support Vulkan & WebGPU.

Vulkan is for best native performance when available on the target platform.

WebGPU to cover all of the other platforms that Vulkan doesn’t.

also I am thinking of removing Vulkan in the future if WebGPU proves enough capability for what I need in this engine.

that’s it, this is the basic principles of this engine.

مصادر ساعدتني

Kohi Series: Kohi Youtube playlist

basically I am able to work on this idea due to this series, it helped me understand a lot of parts, and currently my engine is almost just a copy of kohi except that mine has WebGPU backend & Zig Build System

I don’t plan to stay forever on kohi’s way, every time I find something that doesn’t suit me I will just deviate, but currently the series is basically a documentation for my engine, lol, it is actually the opposite.

WebGPU guide for C/C++: https://eliemichel.github.io/LearnWebGPU/

This helped me implement the WebGPU backend.