A flight through the mist and clouds of my almost completely procedural world (all geometry and materials, and almost all sounds). Powered by Rust on the back-end, and three.js running in a browser.

This is the rapidly evolving landscape that forms the base of a game I've been working on for most of the year. It's been pretty much an obsession, with most nights and weekends spent adding more detail and interest, while trying to balance the performance with my (perhaps a bit over-ambitious?) choice of runtime.

There's a lot more that I haven't yet shown, especially with regards to gameplay and story, but most of my effort has gone towards making the world itself an enjoyable place to be.

Lots of inspiration has come from captivating, yet somewhat mundane, moments in games I've played in the past, where I've found myself wandering through the rain as the sun rises in Dark Age of Camelot, approaching a mist-shrouded village in Morrowind, or even wandering around the stunning (yet empty) locations in the leaked World of Warcraft beta back in 2004.

Game is made with threejs and fully open source github.com/aresrpg/aresrpg

Well, this took a leap and a half.

The engine I was working on is now a smart rendering engine. Long story short, the engine maps harmonic waves to target vectors and quite literally transforms into various shapes.

The genius part of it is that none of the shapes are hardcoded. Each shape is derived from an .obj file. Which means to say, I can place any object file in the same folder and when we run the engine...it automatically reads the list of .obj files and creates a 3D slideshow of it all, periodically moving through the various shapes.

To tell you how crazy this is... The original idea was to create a digital ditto who could transform from a ditto.obj into any pokemon.obj...which it can, but I don't have those files. lol

But I thought it might be able to become some sort of mind's eye for AI in the future. The same way we can hook a camera up to an AI and have it "see," we can point its mind to this abstract space and map words to object files that allow it to see what it's thinking about in real time.

I had a lot of fun with this one. Back to work.

P.S. Every single sphere/node you see is a bit, so that's why it's a smart rendering engine. It can actually compute anything while rendering shapes.

Hey guys. I'm reposting right now as my initial post was a bit dry, not good imo. Quite bad tbh. I decided to explain and write a bit more this time around.

So here it goes...

Lusto is an experimental, deterministic diffusion engine with an unusual property: the control parameters are dynamically derived from two co-evolving channels. There is division of responsibility in data processing between two mechanisms. I like to call these - a worker and an orchestrator. It's basically a single pass engine, not a layered, repeating static pipeline. My design philosophy was to build something different. Something that behaves more like a sysytem that "flows", for the lack of a better word. I belive it's due to my backgroud. I'm not a programmer by education, I'm a chemist. A bit of an obessive hermit by nature and thought to approach the problem of data diffusion from a different angle. I called the the primary mechanism - Evolving Representation Dynamics. It's basically a control unit that can derive different classes of control parameters. In case of Lustro V1 it's rotation values.

ERD has a specific method of linking the data channels. Evolution is emerging from within the system. The data basically controls itself. Sort of like a chemical reaction, that's how I like to think about it ;-)

I'd really appreciate you opinions on my take on the subject as I'm still in the process of learning. Thanks in advance!

Ps. I'm Polish and in my native language Lustro means "mirror". It is a project of deep personal meaning for me. If anyone is interested I'm including a link here, inside this post.

https://github.com/Ligatum/Lustro

Added really cool fissures to procgen world generator in my game (colossal citadels)

I posted a couple weeks ago about a procedural fish generator I was working on. It's now turned into a playable "game", with random fish in random lakes. There's some light fishing mechanics for casting and reeling and it keeps track of your collection of fish and lakes visited. It's playable in browser on mobile or desktop.

There are still a lot of things I'd like to add and polishing/tuning that's needed, but it's pretty functional at this point. From a procedural generation standpoint I'd like to add more variety to the lakes (biomes, plants, etc.), add more behaviors and attributes to the fish, and probably some equipment (rods, boats) with different stats.

I'd be honored if people would give it a try and send me any feedback, thoughts, suggestions from either procedural generation or gameplay perspectives.

The game is uploaded to Itch as "Procedural Fishing".

https://stellarsaguaro.itch.io/procedural-fishing

Hello everyone,

I have tipped my toe into climate simulations and am now building a planet simulation that has climate as it's main target.

For that I use an icosahedron subdivided. Each vertex holds every parameter that is needed for the simulation. The amount of parameters has not been decided yet and will grow over time with the implementation. The amount of subdivision are aimed between 3-10 that I would like to have and between 6-8 as defaults. For the vertical I want to have multiple of these layers to represent higher and lower levels of altitude around the surface. The amount of levels should be around 10-15 as default and maybe around 50 as max.

The simulation will likely be calculated on the GPU. So the structure I thought of is the following:

Every parameter is one long vector f32. Every vertex in a layer is written in sequence of and every layer is also in the same sequence. Meaning that the Len(vec) would be layer * N_verticies and the specific vetted would be layer[i] * N_verticies + vertex.

To address the neighbours for derivative computation, one neighbour vec gets created as a look up table with the form vec[vec[6]] where every neighbours index gets written down for every vertex of the icosahedron. The base 12 verticies are the first 12 verticies in the neighbours vec as in the parameter vecs and the sixth input gets double marked as f32_max.

So in the end, I would have a list of every parameter that each holds one long vec with every vertex of every layer in them, and a relationship vec of neighbours that can also be used to look up neighbors of different layers by in-/decrementing the layer index inside the long vec. (Vec[ layer[I+/-1] * N_verticies + neighbours index] to get the neighbours in the neighbouring layer.)

Is that any good structure or is another structure better and if yes, why?

Thanks a lot for thinking though this one with me.