Nothing groundbreaking here but I've recently used AI to put my old C++ hydraulic erosion code onto CUDA, which sped it up from 10 minutes per planet to 10 seconds. And doing that I can finally tweak in almost realtime to find nice settings. Anyway here's one planet that although unrealistic looks IMO very cool

Game Title: Land of Ascii

Playable Link: https://oddslice.itch.io/land-of-ascii

Platform: WEB/HTML

Description: There's a fort on a hill and a lake to walk to. The villagers go about their own days; say hello and some of them will ask you a small favour. Stop wherever the view is good and sketch it. Night falls, rain sets in and clears again, and the music and every sound are made in code as you walk.

Half an hour is enough to see the main sights. After that the land is still there whenever you want a calm walk, and each seed builds a different world.

- The whole game is one HTML file of about 1 MB (1,017 KB). No images, no engine, no downloads.

- The world is 2 x 2 km. Walking straight across takes about 8 minutes.

- Every frame is around 40,000 letters, drawn from 28 characters in 617 colours.

- 32 kinds of sound and 3 music tracks, all made in code as you play. There isn't a single recording.

- The default world has nearly 12,000 trees, 58 villagers, 255 animals and 59 buildings.

- The villagers have 329 lines of dialogue between them.

- 27,000 lines of code, with no libraries.

Free to Play Status:

• [ ] Free to play

Involvement: solo dev

In my last post here, I talked about how I was working on adding large-scale structure to my procedural terrain based on Voronoi-esque cells. Now I've added lakes!

The lakes are the first large "structures" enabled by this cell-based approach. They can be at whatever altitude each cell has.

It's still a work in progress. I ensured there's no trees and grass under the water, but there's still towers and paths for now. So far I only used existing splat-maps and textures here (grass, cliff, forest, gravel) but it's fairly serviceable (e.g. the gravel for paths can double as beach sand).

The irregular shapes of the lakes come primarily from the large scale erosion filter I use, while I only add a tiny bit of conventional noise.

If you haven't already seen it, you could also consider watching my latest dev video about 'supercharging my procedural mountain forest' - although it does not feature the cell based terrain or lakes. :)

For more info on what kind of game this is all for, I have a page about 'The Big Forest' here.

Hello Again, came back with another quick video showing the settlement growing and adapting to the games terrain

A tech test for Florasynth: various trees grown by simulation, with a frame captured each year to build a timelapse. The first tree is pruned partway through and grows back.

Managed to get through a full map playthrough on the Steam Machine now most bugs and glitches have been resolved (C++/OpenGL/GLSL). Final polishing before release (+ a few more candidate maps to clean up and include). It won't sell but I'll continue working on it anyway.

Here’s a showcase of everything procedural in Out of Pixkrieg, my RTS extraction prototype!

Virtually everything in the game relies on procedural generation. Terrain, units, animals, structures, and items. This system merges two previous projects of mine: a 2.5D terrain generator and a pixel creature generator.

Want to see how these graphics look in a live game?

Try out the running prototype at https://pixkrieg.com/.

I'd love to hear your thoughts!

Spent about 4 years chipping away at this track generator. First in Unity then ported to Godot 3.6. It also supports intersections and simple highway interchanges. I enjoy sitting back and seeing what it comes up with.

I'm making ground impact effects in Godot, and I draw the crack in polar coordinates in the fragment shader. I take each pixel's angle and radius and measure the distance to the nearest of ten arms. That's the usual polar trick, nothing new. But since it's a distance field, more arms cost basically nothing.

My first arms only bent with one smooth octave of value noise. They looked like tentacles!

Real cracks are mostly straight with kinks. So now each arm gets the slow bend plus a weaker, faster one on top, and I scale the bend up with the radius so the arms leave the center almost straight.

If every arm reaches the rim it's a sea star. I let each one stop somewhere between 62% and 100% of the radius, and one branch peels off part way out.

I also stand the rock shards on that function with the same seed. That way I never get a shard sitting next to a crack.

I ported the function to numpy for the picture. Does anyone have a trick to make the branches look less glued on?

I'm the creator of Cbirds, a 2D/3D bird flock simulator that runs in the terminal, written in C99 and inspired by Craig Reynolds' Boids algorithm. The video is the 3D mode running in Ghostty on macOS.

I started working on the 2D version in September 2025, mostly out of curiosity. I wanted to see whether it was possible to build a real time simulation inside a terminal using the Kitty graphics protocol.

The idea came from two places: antirez's amazing C64 terminal emulator (https://github.com/antirez/c64-kitty), and a lecture from the Foundations of AI course at Politecnico di Milano, where Professor Pier Luca Lanzi was discussing multi agent systems.

I really dislike relying on third party libraries, so I decided to implement everything from scratch in C99. I did get quite a bit of help from coding agents along the way. One interesting thing I ended up building was a custom GIF encoder, which allowed the agents to visually inspect the simulation and check whether their changes were working as intended.

The original 2D simulation is conceptually quite simple, based on the three classic rules from Craig Reynolds' work: alignment, cohesion, and separation.

In 3D each bird only listens to its nearest neighbours, seven by default as real starlings do, instead of everyone within a radius. A pull toward a roost keeps the flock in view, and a slow drift in the air over the roost does the rest: the bands, the splits and the folds in the video all come out of those rules.

From there, the project gradually grew to include:

- A full 3D simulation and renderer, running entirely in the terminal
- Real time tuning of simulation parameters
- The ability to pipe text into Cbirds and watch it fly around (e.g. `cat file.txt | cbirds`)
- Multiple flocks with different colors, with runtime controls to make them merge or avoid each other
- Hawks that chase the birds
- Different rendering techniques, ranging from PNG images displayed through the Kitty graphics protocol to Braille characters
- IPC support that lets birds fly between different terminal windows

What started as a small experiment has turned into a much bigger project than I originally expected.

Some of you may have seen the browser port posted here last week (https://nicobrenner.github.io/flock/). This is the terminal program it started from.

Source: https://github.com/clainstone/cbirds
Command in the video: `cbirds --render kitty --3d --color prism`
Install: `brew install clainstone/tap/cbirds` (also MacPorts, apt and Nix, see the README)

Disclaimer: WIP, things are still wrong (leafes growing into each other, etc.)

For a game I'm building we needed to have plants at scale that can grow based on the surounding environment and input genomes. To test the simulation, I targeted a mangrove tree, due to its "weird" shape and growth habit.

Now how does it work? Biology!

We drop a seed with a genome into the mud. That seed has energy based on sugar, and then starts to shoot when conditions are right. We simulate water, nutrients, sunlight, weather, wind, temperature - even the light spectrum to support weirdly alien looking plants where conditions align.

Also stress like insects, water deficit and nutrient deficits, which you can see as visible yellow spots on the leafes itself.

The goal with this is to have alien worlds for our game plastered with realistic plants that would grow (based on our understanding of bioligy) on those planets - which I think is a really cool thing.

The frame is rendered with a spectral path tracer under real captured daylight. On simulated tidal mud.

Things like ferns, grass, moss, bushes are also supported - however the Rhizophora is the most advanced render up to today.

We might open source this at some point :-)

I've been working on Planet 0 Drive, a relaxing, low-poly 3D driving game built with Svelte, Three.js, and peer-to-peer multiplayer.

It's an endless driving experience where you can cruise around at your own pace, explore the world, discover interesting spots, chase new records, or compete and coordinate with friends.

On the technical side, the game features:

• Three.js for 3D rendering, procedural world, and weather
• Peer-to-peer multiplayer with optimized network updates and movement interpolation
• Spatial audio and performance optimizations for smooth gameplay
• Version-compatible rooms to keep multiplayer sessions in sync

Planet Zero Drive started with the idea of a relaxing drive through a landscape that keeps unfolding. It also gave me a place to experiment: how much world could I generate, how far could I render it, and what would it take to keep driving (fairly) smooth on a phone?

Play: https://planet0drive.vercel.app/

Blog https://zackwebster.com/blog/building-planet-zero-drive

Been working on this maze sim for a while. the maze is generated in chunks from a seed as the characters explore, and every character keeps a private map built only from line of sight.

In this clip Juno sees someone's tape X from the side, reads it as a plus, and walks into a dead end that was already checked.

Being upfront about AI: the character sprites were made with an AI pixel art tool (pixellab) and cleaned up by hand, and i build the code with claude, an AI coding assistant, to my own design. nothing in the clip is AI generated while it runs, it's a deterministic sim. Juno's line comes from a fixed set of lines (for now) in the code.

Each battle is generated from a seed: a bocage hamlet, open ridge farmland, a highway junction or a market town, each with its own weather. One in ten seeds has a tank. Battles are seed specific, so you can share a link to an exact fight.

Under the hood: separate RNG streams per system, an event log with a hash, and replay checking, so any run can be reproduced exactly.

Try a seed here!

Sharing Texture Lab, a procedural texture tool by our studio. One seed reproduces the same result, and a shared link restores the settings.

It has three modes: seamless pixel tiles with atlas + JSON export, noise-based height / normal / roughness / AO maps, and 360-degree skies with PNG, HDR and cubemap export.

Completely free, no registration, no installation. Everything runs in your browser: https://openbench.fun/textures/

The clip shows the generated surfaces and export options. What would be most useful for your workflow: more surfaces, autotiling or a 3D height preview?

#TextureLab #ProceduralGeneration #Textures

Hi there, here is a side project in C#/Raylib to create some planets with my own renderer.

I use spherical (equirectangular) flat map of the surface made by one of my curated terrain distributions (3d Perlin noise). And finally a well-chosen palette of 10-16 handpicked colors with a mix of stochastic and dither rendering.
For each frame, the sprite pixels sample the corresponding part of the map, with a rotation on each frame to make it spin.
I really like the result of these retro chunky pixels !

I've been building a Rust + Vulkan game engine (Vulkano + winit). This is the Lorenz attractor with 1,000,000 particles that all start inside a cube 0.000001 wide.

How it works:
- Every particle follows the real Lorenz equations (sigma = 10, rho = 28, beta = 8/3).
- Plain f32 positions don't work here. Particles start about 1e-8 apart, but near the attractor one f32 step is about 2e-6, so a million particles collapse into a handful of points. Instead the CPU integrates one reference path in f64, and a GPU shader integrates each particle's tiny offset from it with RK4 (h = 0.005), using the exact difference f(r + d) - f(r).
- Color comes from each particle's starting position, so you can watch neighbors get pulled onto opposite wings. The two circled at the end started side by side.
- There are no interactions between particles, so the cost grows linearly with the count.

It's not real time: live it runs at 9 FPS with 1M particles on an RTX 3060. Most of the frame goes to per-entity CPU work in the engine, which is what I'm optimizing next. The video was rendered offscreen at 4K, and the camera zoom is scripted to follow the spread.

Source: lorenz_butterfly.rs (src/examples/lorenz_butterfly.rs)

Run it: cargo run --release --features window --example lorenz_butterfly -- --side 100

Hei
This is EDEN, a little project I’m developing in Python.
The idea is simple create an ecosystem, give creatures different genes, and let evolution do its thing.

Creatures reproduce, mutate, fight for survival and sometimes go extinct
I’m experimenting with different environments to see how evolution changes over time.
What do you think?

https://www.twitch.tv/edenevolutionwars