site banner

Tinker Tuesday for June 16th, 2026

This thread is for anyone working on personal projects to share their progress, and hold themselves somewhat accountable to a group of peers.

Post your project, your progress from last week, and what you hope to accomplish this week.

If you want to be pinged with a reminder asking about your project, let me know, and I'll harass you each week until you cancel the service.

1
Jump in the discussion.

No email address required.

Didn't get much done in terms of code, but I figured I'll get to the bottom of performance issues. So like I said I noticed that I get better graphics performance on Windows, but I remembered that actually things weren't working half-bad back when I was on Mint, so it had to be something with configuration rather than the drivers or something inherent to Linux. Turned out I had some hybrid setup, where it was mostly using the integrated gpu, and only "offloading" specific programs to the external gpu. It's supposed be better for the battery, but goddamn does it screw with performance. Fixing it was a huge QOL improvement so I'm pretty happy just for this.

Ok, so this helped, but the frame rate was still dropping after a few seconds. The simulation I was testing was pretty massive, with 6 figure numbers of monsters, and I thought maybe it's because they get concentrated in a pretty small area. I have a spatial index grid to sort the monsters and exclude huge chunks of them when I do collision calculations, and I remember that it helped to make the grid cells smaller... curiously doing so only seed to make it worse. Then I rendered I refactored the simulation set up, and it's size is now fixed. Using smaller cells just means there'll be more of them, and that can indeed screw with performance, if it's not balanced. I tweaked the numbers a bit, and created a smaller area simulation, with small cells.

This, also helped significantly, but the frame rate was still dropping as time went by. I thought I'll try to wait it out, the player character is on auto fire, so I figured the more monsters die, the less load on the simulation, but again if anything it kept getting worse. So I thought, maybe that's the issue? Maybe they're not properly ignored once they're dead? I kept all the collision detection stuff, and took out just the part that changes their state to dead. It worked! The fans run at full steam, but I can sustain +100K monsters at 60 FPS indefinitely. I still haven't found how moving them to the "dead" state actually increases the load, but I'm positive the issue is somewhere there.

How have you been doing @Southkraut?

Stripped out large swathes of LLM-generated code that I was not minded to maintain compatibility with as I reworked my core systems. Which also means that my minimum viable prototype is no a nonviable prototype, as this has cost me my terrain generation and everything having to do with NPCs, but I'm fairly confident that I'm now in a better position to write those systems myself.

I ended up re-implementing the same component pattern for my PhysicalEntities that I had already used in my Unity days, in which each PhysicalEntity has a number of mandatory components:

  • One for Shape and Substance.
  • One for how it is to be physically simulated - on low-fi rails, in Unity/Unreal physics, or not at all.

And several optional ones:

  • One that handles any functions like Speech, Perception, Locomotion etc.
  • One that handles ongoing behavior, like walking up to NPCs and starting conversations with them, or like seeking and consuming food, or like evading other NPCs.
  • Several others that I forgot. My Unity project had around a dozen such components per Entity.

Obviously there's a lot of degrees of freedom in here. I could combine Functions and Behavior, for one, by simply making Behavior a Function. But I need to take care not to make it too granular - that was a trap I fell into back when, where I spent months building intricate networks of such Functions to generate fairly simple behavior. Like building a gun out of separate functions for each mechanical interaction possible with the gun, instead of just having one overarching "Shoot!" Function. Which was fun, in its way, but not very productive. If I go into that level of detail again, let it be after everything is up and running.

And then there's the matter of whether it even makes sense to create all this architecture, when Unreal already offers a Component Pattern through its Actors and their, well, Components. I'm very likely overengineering everything when I should just use the tools that come with the engine. But I have a slight feeling of disgust when I'm forced to use the Unreal API instead of one I wrote myself. For no good reason, as far as I can tell. Unreal's is probably the way it is for very good reasons. But as always I'm stubbornly determined to make as much myself as I can.