Current design decisions for my game engine:

[tracefree@mastodon.gamedev.place]

Camera controls for the engine editor. I stole the exact keybindings from Godot >:)

[tracefree@mastodon.gamedev.place]

Finally had some time again to work on the project. The scene tree is now shown in a QTreeView and you can toggle the visibility of individual nodes. Also re-implemented the resource manager and scene deserialization from the previous version.

Next up: Let the editor actually edit the scene and save it to disk!

[tracefree@mastodon.gamedev.place]

Wait, this isn't progressing in the right direction - maybe I should take a break...

[tracefree@mastodon.gamedev.place]

Today has been a very relaxing goblin mode coding Sunday :D Some more non-visual updates:

- StringIDs. Like Godot's StringNames, interned¹ strings are hashed and stored in an internal database. "bla"_id gets converted to a handle that is faster to compare for equality than std::strings.

- Loading scenes from the editor via a file dialog, including a "Recents" menu. The UI was surprisingly easy to implement with Qt!

¹ https://en.wikipedia.org/wiki/String_interning

[tracefree@mastodon.gamedev.place]

Thinking about the next steps for the editor. I want to add a transform gizmo, which means I need some way of recognizing when I click/drag things in the 3D viewport, so I'll try to find out how other editors do that. Naively I'd think I need a physics engine for that, but in Godot I can accurately select meshes without collision shapes 🤔

[tracefree@mastodon.gamedev.place]

AABBs (partially) implemented

They don't support scaling and rotations yet, but for starters it's good enough for (1) visualizing selected nodes and (2) testing raycasts from the cursor position against.

[tracefree@mastodon.gamedev.place]

Got node selection working, without a physics engine or CPU-side triangle raycasting! Used this idea from a colleague:

- Put mouse position and node ID into push constants
- In the fragment shader, check if current pixel is under the mouse
- If so, write node ID and depth into a list in a storage buffer
- On CPU, read back the buffer and sort by depth

Upside: No need for AABB testing, proxy meshes, or duplicating skinning code on the CPU

Downside: Has to be included in most shaders

[tracefree@mastodon.gamedev.place]

Weekend progress update: we have a transform gizmo!

It can't actually transform anything yet but it jumps to the average position of the selected nodes and disappears when nothing is selected.

[tracefree@mastodon.gamedev.place]

Bonus screenshot: one of the fun things that can happen when you mess up and bind invalid descriptor handles. Had a lot of GPU hangs today :P

[tracefree@mastodon.gamedev.place]

The translate gizmo is now functional :D

[tracefree@mastodon.gamedev.place]

For a second there I thought my refactor of the materials system just worked on first try, but no, it only seemed to work by accident and now my GPU crashed. Time to go to bed :D

[tracefree@mastodon.gamedev.place]

The refactor being: First I had a global buffer of materials with albedo color, roughness, metallic, bindless texture indices etc that's always bound to every shader and I pass a material ID via push constants with each object. But not every material is PBR, there's going to be custom shaders using different data. So now the global buffer is an array of pointers to material buffers of different types, and I send an additional material type index via push constants as well.

[tracefree@mastodon.gamedev.place]

Update:
- Proper dynamic point lights based on nodes (previously the light was just hardcoded in the fragment shader)
- Billboard shader
- Badly drawn icons for point lights in the editor using billboard shader
- Icons have the color of the light

[tracefree@mastodon.gamedev.place]

Update: KTX2 texture support. Smaller VRAM usage due to GPU block encoding, much faster loading times since I also downscaled some textures, and much better looking textures from afar due to mimapping that comes for free (the toktx tool I use to convert to ktx can automatically generate them).

Conversion to KTX isn't automated yet, but I hope to do that as part of the import process in the future.

Again mostly copied from the old engine and slightly adjusted

[tracefree@mastodon.gamedev.place]

The temptation to rush ahead and implement the the fun stuff is real :§ But before that I really gotta make a proof of concept at least for a core architectural system.

In Godot you have individual .tres / .tscn files for custom resources and scenes. I want to instead use a single SQL database for everything (or at very least for resources like items etc., but ideally also for whole scene hierarchies). That idea needs testing.

[tracefree@mastodon.gamedev.place]

Mods would then just be collections of insert / update statements. Upside is you could very easily modify the whole game based on complex parameters, like dimming all light sources in dungeons or changing the stats city guards based on the economic status of the town they're posted in calculated by the wealth of local shopkeepers, in a single SQL statement. No need to touch hundreds of files.

[tracefree@mastodon.gamedev.place]

Downside is I'm lazy and only want to maintain a single source of truth regarding data structure, so I'm experimenting with automatically generating an SQL table for every data class in my game by analyzing source code (with annotations). Let's see how that goes!

[tracefree@mastodon.gamedev.place]

Testing it by making a tiny text-based RPG in a separate project first. Depending on how much fun that is it will either stay a tech demo or become something to practice writing as well. Could be like a demo to put on itch to give a preview of the world and its characters.

[tracefree@mastodon.gamedev.place]

Slowly hacking away at prototyping a data resource system that's backed by sqlite. Not really sure what I'm doing...

Currently I have C++ classes representing data which have an equivalent table in the database. The classes have a static getter taking the ID as input. This does a select statememt on the DB, creates an instance of the class, puts it into a pool, and returns a handle to get a reference to the instance.

[tracefree@mastodon.gamedev.place]

I'm wondering how to handle relations between classes / tables. E.g. Actors have an inventory of Items. I know how to represent this on the DB, but on the C++ side I need to replace the foreign keys and utility tables for many-to-many relations with arrays of handles / pointers etc. But how much do I want to load into memory? Loading an actor shouldn't always load all items in their inventory and everything those items have relations to, not until actually needed.