End of weekend progress update: Reduced >500 limes of macro code to a dozen or two :D Realized it really wasn't necessary to stuff so much code into each class when I could use templated static functions instead.

CRUD (create, read, update, delete) mostly implemented. Next up I gotta support resource inheritance (I'm sorry 😔) in the SQL backend. And vector/quaternion properties. And more kinds of relations between tables. And clean up the mess :§

Gonna be worth it though!

Implemented* inheritance for the SQL data backend! Now a C++ class "Armor" can inherit from "Item" and a new SQL table with the additional fields is created, with the primary key also pointing to the table above it in the inheritance chain so you can retrieve base class fields.

*By "implemented" I of course mean it barely works and I shouldn't code after midnight

Thinking a bit about design choices for my engine. I can't and don't want to make it general and all-purpose like Godot so the scope is limited. What do I want people to be able to do with the editor?

Priority #1 is level and quest design. I want it to be a tool to easily make content / mods for my type of game. More complex tasks like shaders and gameplay code are fine to be done outside the editor or hardcoded.

Installed #gram (https://gram.liten.app/) by @krig, an AI and telemetry free fork of the code editor zed, and started feeling my way back into the engine project :)

Doing some janitorial work first, setting up a repo for the sample game now so that there's something for people to actually run. Faced with the eternal question, where do I put game assets? I don't mind just checking them into git but I don't want to overwhelm Codeberg's servers with large files.

The database backend for scene representation is finally falling into place :D Integrated it into the actual engine and updated the editor application. You can load a scene, move nodes around or hide them, save, and the changes are reflected on the next launch. Previously scenes were defined in handwritten YAML files that could be loaded from but not saved to.

There's a million issues still under the hood but debugging will be easier (and more fun) with 3D scenes to look at.

Can't wait to post screenshots / clips again soon. Been over half a year (?!) since I had any visual progress - the SQLite backend is essential but not really exciting to look at.

Still not doing any new rendering stuff in the near future probably, but editor workflow stuff mainly.

successfully did a math. years of education with vectors have not been in vain

turns out in the end I don't actually like what the algorithm does but at least it did the bad thing correctly

It's funny how some things in gamedev you never ever think about as a user are actually non-trivial problems. Like say you have a transform gizmo in a 3D editor. You click one of the arrows and drag the mouse somewhere to move it.

When the mouse remains on the axis of movement it's clear where it should end up. But what if the mouse is not exactly on the axis? You still want to move the gizmo in the general direction but confined to the axis. Where to exactly? There is no right answer

Update: Instead of redesigning the foundation I put more duct tape on it. Gonna try to build more on top to see where the system really breaks and learn what the requirements of a better alternative would actually be.

In other news, the SQLite based scene serialization/modding system is more or less fully integrated into the editor now. It works! You can spawn, rename, move, and delete nodes.

Next up: Show components in the inspector panel and make them editable.