For my fun time I've been working on a game engine in Nim since January of last year. It's built on top of SDL3, using SDL3's new GPU API (this API is bangin you should try it).
Took me a year to learn how to draw a triangle, learn how to draw 'many' triangles, learn how to render 3D geometry like cubes and spheres, texture things, make a controllable camera, load .obj models and manipulate them in 3D space, basic lighting.
Good progress, but that's about all I got after a year.
The game engine I want to create is super demanding. Ultimately it's being built for an ambitious online multiplayer, open world, zombie survival game in VR. The first of its kind.
I need things like stereo instancing, clustered forward renderer, world streaming, GPU-driven rendering, cascaded shadow mapping, and plethora of other optimizations baked in from the very beginning to make the game I want.
With so much to do and so little time, over the last two weeks I decided to take the architecture of what I needed and build out small plans to work on with AI.
I knocked out one or two features a day before bed. Very carefully guiding, reviewing, profiling, testing. Step-by-step, file-by-file.
In just two weeks I implemented more than what I would have been able to do in a year or two. I'm not even kidding. And it's not slop either. You can't slop an engine or it's going to perform like shit.
I had an example with a couple hundred models, a few lights, and other things to sort of 'simulate' a demanding scene environment. My implementation before ran at about 90 FPS. After working with the AI the same scene is at 1200 FPS, capped by my operating system. We have GPU-driven rendering, shadow maps, PBR, so many features that would have taken me no less than the rest of this year to learn and implement it all in an efficient manner.
I'm in such awe right now.
I think I'm actually going to be able to have a very 'usable' engine in a month or so to really start playing around with game development.
I've always tried separated myself from the end goal in things and enjoy the journey. One reason being is that I don't want to get discouraged by fixating the end goal is soooooo far away. I'm sure you know what I'm talking about!
Anyways, man, what a time to be alive. We can actually take our ability to think creatively and logically, problem solve, plan, our engineering expertise, all of these things and combine it with today's frontier LLMs to achieve literal god levels of work in just a fraction of the time.
@ kobi
When I paraphrase you statement, the marketing process might be: corps give the AI-service for free untill the client is hooked and dependant, and after that crank up the price. User-dependancy is the known and frequently used approach to create (local or temporary) monopolies. Good for the company, but bad for the customer or dependant business-owner.
So that gives the risk of vendor-lock-in. The more important it is (and always was) to:
On the other hand, the spreading of the tech may render monopolization efforts fruitless.
Nim is the right tool.
Much faster to compile than Rust!
I think I'm actually going to be able to have a very 'usable' engine in a month or so to really start playing around with game development.
Will you make it open source?
I'm not going to argue about it being nice to have AI to help push game engines along. I've had mine in an incomplete state for a while now and LLMs have helped me rapidly improve on the core that I already had.
Now I have a plugin-based engine with an editor where all assets and plugins are hot-reloadable. The engine leverages an entity-component system for scene compositions, and scenes are fully serializable. I also have a terrain graph editor, spline editor, ragdoll editor, multi-threaded physics via a fiber-based job system, a clustered forward plus renderer, vfx system (no editor yet), IK skeletal animation with animation blending (partial and full - no dual quat skinning yet though), a material system, some rudimentary AI, etc...
Here's a video I shared today in the Telegram channel showing off the spline editor (where I've been posting my updates) -
I just don't think it's going to be affordable for hobby projects for much longer. Maybe I'll be wrong.
Thanks! I'm looking forward to seeing your work as well when you decide to share more!
I'm using sokol-gfx for the graphics API, although I have a core graphics API that I abstract sokol with to do command buffering / draw call sorting so I could potentially swap out sokol with something else if I wanted.
I use clay for my UI layout library - https://github.com/nicbarker/clay - and I've implemented the slug algorithm in Nim for text rendering. For vector graphics I ported https://github.com/jdryg/vg-renderer to Nim so I have a fully capable UI rendering system as well (forgot to mention that stuff above in reply). I use ozz-animation for skeletal animation / compression / blending / IK / etc...
For physics I'm just using Jolt. I'm not ambitious enough to write my own physics engine yet. Jolt also has been working just fine for me so far. I have ragdoll animations driving death animations, and actual ragdolls for when I do want to have a character ragdoll (explosions, etc...)
I also have a gib system where I can deatch limbs and spawn gibs / blood trails. I'm working on a real-time tactics game similar to the Myth series of games (but in a more modern setting), so lots of blood is required haha.
Codex fixed a bug that would have taken me hours to find, can you spot it?
The error was this:
[info] loaded config from ./config.json
[error] near "=": syntax errorI at first blamed the command line options used, "--doc=test" might be rejected. But it wasn't that. GLM got stuck in a loop trying to prove that parsejson is buggy or the config.json has syntax errors. Instead the bug is here:
FROM """ & TableName & """
WHERE source = ?
AND doc_id = ?Yes, I had similar experience. Bug detecting is superior, not just simple syntax, but complicated high level modelling issues. Suggestion for improvements. Including math problem. As for the language level bugs - it's pretty much solved issue, AI catches almost all lang bugs. I use julia and don't even need typed language anymore, AI does all the checks.
Problem - yes it's age of abundance and very high productivity. Problem - it won't make you money. Making money require scarcity, it has nothing to do with how good or vital or complicated solution is.
Air is vital for life, but good luck selling it. Fly is very complicated, miracle flight machine, yet you can't make money selling it ether.
AI turns IT into flies, amazing technology, productivity, complexity, yet zero money.
I use julia and don't even need typed language anymore, AI does all the checks.
Yeah, that's a terrible idea. ;-) Typing is not to "detect bugs", it is to prevent bugs and also for readability.
If you want the web + native + cross-platform go with WebGPU. It has all of that and sits on top of a single unified shading language (WGSL if I recall correctly).
The only reason I didn't go with WebGPU from the beginning is because there's no native support for VR (OpenXR integration) and ultimately that's the kind of game I want to be able to create with my engine. Otherwise this API is fantastic.
This documentation was a really great resource when I experimented with WebGPU: https://eliemichel.github.io/LearnWebGPU/
However, if you don't absolutely HAVE to be able to target web, I would recommend going with SDL_GPU. You can write everything in GLSL and cross-compile to literally any other shading language. The backends are native to the OSs by default- D312 on Windows, Metal on Mac, Vulkan on Linux. Basically what WebGPU does under the hood too... but the documentation is super easy to read and just plain better. The API surface is TINY in comparison to WebGPU as well. Nim already has several bindings for SDL3, you'll need to make your own for WebGPU. You get the added benefit of already having SDL3 which is great for windows, input handling, etc.
This resource is how I got started in SDL_GPU if interested: https://www.youtube.com/watch?v=tfc3vschDVw NOTE: the tutorial series is using Odin, but it's so simple you can follow along with Nim.