Alright guys, I’m trying to post weekly updates, at least when I have anything to report. There’s not much to report for last week. No devstreams, work was too busy.

However, I have a new direction:

• Build a low-effort grindfest demo with a low-effort custom engine and some existing assets.
• Polish the core mechanics and combat. Make it fun.
• Port the core RPG features from Sanguinity v0.2.1.
• Add enough content for a demo - in the 1700’s “Synthnostate: Salem” setting for simplicity.
• Polish the art/graphics somewhat.
• Then with enough help, hopefully we can expand it into a full RPG in either setting, or both.

Same ultimate goals, less ambitious shit up front.

And yeah, Sanguinity v0.2.1 is the end of the line for my Godot-based demo series. I will certainly do more tests in Godot 4.3, and I may even upload one or two, but nothing serious. As far as I’m concerned, Godot has terminal incurable AIDS. I could use some other engine if Godot’s passing makes way for a better one, but my preference is a custom engine only using small libraries maintained by single individuals. Group politics and drama ruin everything. I’ve built a bunch of RPG prototypes and demos over the last 10+ years, I want to finish one or two of them now. No more bullshit!

Also, Crusaders is potentially back on the menu. I put it on hold and started Sanguinity to make something with better graphics and no party-based RPG mechanics to balance (an unexpected time sink). And because people were taking conspiracy theory shit way too seriously just because a few theories panned out in 2020. My V2 engine still had some shortcomings as well, especially GUI performance and single-threaded scripting, which V3 should resolve. So if I hit a wall with Salem/Sanguinity I can give Crusaders another shot - once again starting with a tactics demo before adding RPG features back in. Man, I really liked the firearms system in that game. Yeah, a little tactics demo with turnbased gunplay alone would be sweet.

Custom engine tests

Continuing where I left off in April, I did a Raylib model & animation loading test - in C not Odin to avoid extra complications for now.

I’m just getting a feel for Raylib’s limitations. Root motion animation is out, and that’s okay, I think it’s an unnecessary complication anyway. Godot-style name suffixes (-col -colonly -nav etc) won’t work because Raylib discards the names, but the underlying CGLTF library loads them, so I could simply add names in an internal Git fork of Raylib.

Next up, I need to get my PBR textures working in Raylib. I might have to structure them a little differently. Later I’ll have to figure out how to manage materials. I’ll try loading tiled materials in whichever MaterialMaker export format is most convenient. For baked textures I could write a Blender script to grab the parameters from shader nodes and export them in the same format. But I may not need to if Blender properly exports them in GLTF format.

Then I can move on to core mechanics, combat, collision/physics, etc.

And maybe a few turnbased tactics tests…

Devlog tools

I was playing around with Markdown and I noticed there’s a Tables extension that works on Odysee. That’s useful. It’s not too much work to make a spreadsheet in LibreOffice, Save a copy, Text CSV, Fixed Column Width… then add the grid lines (dashes and vertical bars) in column-editing mode in a fancy text editor like Geany, Kate, Notepad++ or Vim… and paste it into an Odysee text post. Then preview or post it, press F12, inspect the table, and copypaste the outerHTML into my devlog on Itch.

Uh, I could just export the spreadsheet as an HTML table, probably. Might be a godawful mess though.

Here’s a feature comparison of all the engines I’ve used in my Synthnostate projects. This is just a start - I’m going to list out all the features to remind myself what I do and don’t need/want in V3. And we’re gonna see a bunch of X’s in the V3 column for shit we ain’t gonna need…