Tree generator - WebGPU * reworked skinning to be more physically accurate * added stubs and knots * added roots * minor improvements to branch and leaf placement - better adherence to tree biomechanics And yes, the tree is rigged and skinned and the animation is 100% procedural from the real-time fluid sim

You'll find that a lot of indie game developers, myself included, are not against piracy. If you can't afford one of my games - knock yourself out and pirate it, you have my blessing.

When you play a game, at some point you stop being aware of the controller in your hands, or the mouse and the keyboard. The screen's pixels and subtle reflections stop existing. You are the character, and your brain is controlling that character directly. There are many terms for this phenomenon: * Kinesthetic Projection * Action-Awareness Merging * Body Schema Extension To me AI is like that too. If I want to make a piece of software or a game, the tools are in the way, and when I'm at my most productive, they disappear from my conscience, they become a part of the "me", as weird as it is to say. It's never been about the tools, it was always about the goal. Sometimes the journey to the goal is meaningful too, but most of it is just you dealing with a your tool's limitations. Given a choice, would you use a worse PC to develop? A tiny display? A worse editor, with no language support? - I wouldn't, and I don't.

AI in video games are a confusing topic to me. @TimSweeneyEpic recently got a lot of flak for pushing AI in game development. There are opinion pieces left and right condemning AI use in game development. Here I am, having worked for ~6 months on a game I released on Steam last week. And my sin, apparently, was using AI and disclosing it. The comment section was pretty clear on that. It's confusing to me. AI is a tool. IDE is a tool. A programming language is a tool. A graphics API is a tool. We're just using tools. I've been writing software for about 3 decades now, I'd like to think that I know what I'm doing and am pretty good at it. I see AI as an incredible productivity booster. It does some things that I pride myself on being good at, such as teasing out a math formula or optimizing an algorithm better than me most of the time (with a lot of handholding, granted), but for the most part it makes things I find tedious - fast. As I software engineer, and a game maker, I take relatively little pride in knowing a programming language, or remembering 100 shortcuts in an IDE, or knowing a programming language spec by heart. I remember the first time I needed to make an animated 3d model, almost 15 years ago now, and it took me about a week of full-time effort to get anywhere. I didn't feel particularly proud, I felt frustrated, I had a clear idea, but the tool and its complexity were getting in the way. Well, the tools are better now. Blender is better, animation tools are better, and there are AI models that keep improving at an incredible pace. Ultimately, when I write a piece of software, or work on a game - I rarely think about the tools, they are a means to an end, not the point in itself.

did more work on the tree generator for WebGPU * more biomechanically accurate branching, fewer very long thin branches * branch growth takes gravity and material into account now * branches use full collision resolution, previously it was statistically improbable, now it's impossible * Added senescence parameter to leaves, so we can cover different phases of growth, especially useful for autumn and for young leaves (spring) * leaf cards are now generated with variants, so leaves don't all look the same * placement optimization, much fewer cards and branches required for the same overall coverage/volume, ~50% fewer triangles overall I don't think realism is something I will chase relentlessly on this, as this is intended for real-time applications, to generate foliage for games and interactive experience, not so much for botanical simulations. But having a principled generator costs nothing at runtime, so I'm going as far as it makes sense to. Right now a tree takes anywhere from 50ms to about 1s to generate, depending on the size and other configuration parameters, which is entirely reasonable for my goals.

Foliage in WebGPU * tree generation * wind simulation

Pretty disappointed in Google's Gemini 4 Argon. Antigravity as a harness also feels like Claude Code from about 7 months ago

Not really. People judge Vampire Survivors like it's a simple game or one that's easy to make - I don't believe so. As a software engineer and a game maker myself - I see Vampire Survivors as a very complex and elaborate piece of software with deliberately primitive graphics.

Just released my AI coded game on Steam: store.steampowered.com/app/5… What it took is: - a few hundred prompts - about 6 months of development - just over 1500 commits.

Variable Rate Shading in WebGPU primary reference: VRCS in DOOM: The Dark Ages by @MartinJIFuller

Activision's CALDERA scene in WebGPU in the Browser - 216,122,609 source triangles - 487,465 instances - 116,513 unique meshes

Added ballistic audio simulation to my cute game. There are 114 guns in the game, so I wanted them to sound a bit different. Being an engineer, the solution is, of course: engineering. There are 3 sounds that make up a shot: * muzzle blast (propellant) * ballistic crack (supersonic) * mechanical action (the gun parts) So, each gun gets a set of 3 sounds, each having a bunch of filters applied based on weapon's: * muzzle velocity (no different ammo types per gun in my game) * bore size * barrel length * muzzle device ("none" is an option too) * action type * propellant type * propellant mass Way to over-engineer things, but it costs nothing at runtime and guns have distinct "voices" as a result.

Moved my game from #threejs to meep engine. Before and after. Still a bunch of things to tweak and adjust, but worked surprisingly well

WebGPU water (WiP) live demo: meep.company-named.com/examp…

WebGPU water * authored with geometry, conforms to any space and scale * unlimited number of water "bodies" * rendering is entirely screen-space, so you only pay for pixels you can see