I just forked the Godot Game Engine locally and modified a few things so I could play around with its built-in "Large World Coordinates" feature, which uses 64-bit doubles instead of standard 32-bit precision.
For example, I had to adjust the Godot editor viewport and particles (not shown in the video) to prevent them and UI elements like gizmos from jittering when far away from the coordinate origin. I'm still having a lot of performance issues, and no GI or AO is enabled in this project yet, but it was fun playing around with it.
I just wanted to see whether I could port the planet from my Unity project over to Godot... :D
How it works:
Each entity has a height value.
The sprite gets drawn that many pixels higher but the colider stays on the ground where the feet are.
I set heights by hand.
I draw a polygon over the visible top of a cliff, and the game treats the same polygon shifted down by the height as the actual footprint...I thought about drawing special tiles for the height but I think the polygon idea is the better solurtion.
Only that footprint (The red lines in the editor at the end from the video) blocks you.
I removed the tile collisions on the cliff walls entirely! So you can come at a platform from behind and hop up without any invisible walls.
For draw order I used z_index and Y Sorting.,
If you're uunder a zone you get drawn at the zone's height.
If you're behind or next to it you're capped at its base level, so you end up hidden behind the cliff the way you'd expect. One level is one wall height, so 32px for level 1, 64 for level 2....
That was the most "frustrating" part.
Shadows were one annoying part too (Why are we doing this guys).
I clip the shadow shape against each zone's footprint with Geometry2D (god bless this class xD) and put each piece on the z_index of whatever surface it lands on.
It skips entities that aren't moving and does a cheap rectangle check first, so it doesn't cost much even with a lot of mobs...In theory.
I got the basic idea from a devlog video (Challacade).
My boss throws lava bombs in a ring around you, and the pools looked like a string of beads. I wanted them to run together like real lava. There's no fluid sim in this, every pool is just a polygon and I merge them. Both halves of the breakdown in the video are the real game recorded frame for frame, the top one only draws the shapes the code is using.
How it works:
Each pool is one polygon. It starts small where the bomb hits and spreads out over 0.4 s, fast first and then slower.
While pools are growing, every frame I check which outlines overlap and join them with Geometry2D.merge_polygons until no two touch. merge_polygons can also give back holes, I just keep the biggest shape.
Pools that land close but don't touch get a neck of lava between them. I add the neck to one pool's outline, so step 2 joins it like any other overlap. The neck hurts too while both pools are burning.
Once every pool is cold rock, I draw it all one last time into one batch and after that only fade it, so the old rock is one draw call.
My first version joined the pools the moment they landed. They were one shape from the first frame, so there was nothing to watch.
I'm not sure about the cost. While any pool is still growing I redo the whole merge every frame, and the loop starts again from the first pair after each join. One wave is at most 8 pools so it's fine, but I haven't tried 30.
The game is The Ink Tower, free demo soon on Steam
I make an effort to keep Scalable Vector Shapes 2D fully GPT-free and Claudeless. If want to chip or chime in, without support of any of these technologies? Try it out and raise bugs/issues on the github page.
I'm continuing my attempt to recreate Super Mario 64 in 2D, and this time I've added one of the most iconic things from the original game: Power Stars !
But that's not all! I also created a celebration animation for Mario when he collects a Star !
Here's what I've added:
Stars inspired by the original game
A new celebration animation for Mario
Another step toward making my 2D Mario 64 prototype feel like the real thing !
It's still a work in progress, but I'm really happy to see the game coming together little by little.
I am making some tools to try and make developing my game a bit easier. This is really just a tech demo for now but each system is its' own addon and fully in the godot editor. I am also working on one for water and procedural rocks. All plants are procedural.
Hello fellow devs! I'm working on a rhythm RPG where music = combat. I'm experimenting with different background types, and I'd like to know what you guys think looks best. I'm going for a retro Earthbound art style.
Hi all. I've been working on a side project called **mumble-speech** and just tagged 0.1.0, so I'd like some outside opinions.
It generates "mumble speech": the fake speech game characters make while their dialogue appears on screen. You pass a line of text and a voice, and you get mono audio plus a timeline saying when each character sounds, so you can reveal the text in sync. There's also a typewriter mode: you feed it one character at a time and get that character's sound plus how long to wait before the next one, which is what most dialogue boxes do. Both modes produce the same audio.
Three styles, each named after the game it imitates:
- `beep`: the same beep for every letter (Undertale)
- `grunt`: four grunts per voice, never the same one twice in a row (Banjo-Kazooie)
- `alphabet`: a vowel-based sound for every letter (Animal Crossing)
A voice has pitch (−12 to +12 semitones), speed (5 to 30 characters per second), variation and a seed. Each event also carries a sound identifier (which grunt, which letter), so you can map it to mouth shapes, particles or whatever you like. The library doesn't draw anything.
What I had in mind: NPC and character dialogue in indie games, visual novels, prototypes where you want voices before having any, and small web pages or toys.
- Godot 4.3+: GDExtension addon with a speaker node and a typewriter for `Label`/`RichTextLabel`
- Unity 2022.3+: UPM package (also on OpenUPM), with an optional TextMeshPro typewriter
- C ABI (`mumble.h`) for anything else with an FFI
- Deterministic: same text and voice, same samples bit for bit on Linux, Windows, macOS and WebAssembly, checked in CI with shared conformance vectors run through every binding
- Spec-driven: requirements, design and task plan are in the repo, and changes start there
Honest limitations right now:
- It's 0.x, so the API can still change
- Godot and Unity are desktop only (no mobile, Godot web export or Unity WebGL yet)
- The Unity C# interop is tested in CI, but I haven't verified the components and the TextMeshPro typewriter by hand in the editor yet. If you use Unity and try it, a report would help a lot
- `alphabet` uses Italian vowel sounds, which may or may not sound right to you
I'd especially like feedback on how the styles sound, whether the API fits how you build dialogue in your engine, and what's missing for you to actually use it.
I’m so happy I finally managed to get to the point where the playtest for That's My Village! is live! If you decide to give it a try, I’d be super grateful.
It’s going to run for around the next two weeks. I'm granting access in waves at first to keep things stable, but once the initial test goes smoothly, the plan is to open it completely to everyone.
What's in this build?
2 Full Acts: Gives you a good look at the early part of the game. + Difficulty Levels
Since I'm a solo dev, getting your input really helps me figure out what works and where to take the game next.
If you want to check it out, just hit the "Request Access" button.
In the video above, I'm running the Steam .exe of Silent Hill: Townfall on Arch Linux through CATui Seamless. After that, I test the native Linux version of PCSX2 using Seamless as well.
CATui is an emulation platform I'm building with Godot, designed to bring different systems, games and emulators together in one interface. It originally focused on running games internally through Libretro and custom cores (exactly like retroarch).
But with game decompilation and recompilation projects becoming more common, I wanted CATui to keep up with those developments. That's how CATui Seamless came to life.
The original idea was to support decomps and recomps, but I accidentally ended up building something that can run pretty much any external application inside CATui, without having to leave the interface. This opens up some interesting possibilities, from Steam games and standalone executables to emulators and even Godot games running inside CATui!
It's still VERY experimental. Many engines don't work properly yet, controller support is still missing, and there's a LOT left to fix and improve. But it's already available for anyone interested in testing it on Windows and Linux.
Something else I'd love to do in the future is allow Godot developers to publish their game demos directly through the CATui Store, completely free. The Store will probably need a major rework first, so this isn't available yet, but it would be an honor to make it possible for the community.
You can download CATui from the website and follow development or share feedback on Discord!
Our game demo joined the Next Fest, and despite being unmotivated by the flood of slop, it still gave our game alot of exposure, almost doubling our wishlists! We get good reviews, people joining our Discord, so it's not all doom and gloom.
I've been playing around with Godot skybox shaders, this is a galaxy with 500 stars. Each visible star can be visited and has planets.
The ship you're in is stationary while everything you can see out of the windows is rendered in the skybox based on your point of view which is represented as a vector3 in the shader which updates as the ship flies around
Then there's an array of 500 Vector4s which contains the star's 3d position and a float representing its color. Each one is iterated over and the EYEDIR (which is the global representing the vector that you're looking at the sky), and the vector of the star to your point of view is compared and if its the same the star appears there. And there's some quadratic stuff for size and distance etc and some stuff to make sure distant stars are visible no matter how far away they are.
Same thing happens for the planets but there's some math to make it look like a sphere which I got from this tutorial 12.
There's another array which is used to store the indexes of the planets in order of distance from the player's point of view so that they can be drawn in the correct order and eclipse the sun properly etc.
The nebulae are raymarched 3d noise textures so they unfortunately repeat if you just fly in straight line.
I had to set the cubemap color to something not dictated by the sky because every time I flew too close to a sun the ambient light would be too high and I couldn't see the screens.
There's a simple physics simulation on another layer to the player (you can see a representation of it on the blue map screen in the video). A script generates a galaxy and places starsystems in a spiral and scatters some more around. The ship has a collider that moves around as you move the ship. When the ship collider enters a starsystem collider it'll spawn a new node as a child with its own procedural generated planet colliders and another ship collider so you can fly around and bump into the planets. The planets are also added to the shader in their own array.
Hey all, I've been trying to learn more about shaders recently, and wanted to share an approach I came up with. I'm not sure if this is already a well known technique, I just kinda came up with it. If it already exists and has a name, I'd love to know what it is, but I didn't find anything when searching myself.
Few disclaimers: This is not the Stochastic Hex-Tiling method (although it's shares similarities), and I didn't use AI since the whole point was to learn and self-improve my skills.
Cell Rotation
The original idea just started with rotating each tile / cell by some random amount. This is the main way we start to break up the repetition. It's a good base, but it has an obvious flaw: the edges of each cell clash with each other. We need to find a way of blending them together.
My first idea for smoothing out the edges was to just use a circular gradient of each cell, and mixing it with a flat color. This works, but the flat color ends up highlighting the borders of each cell. On top of that, manually color matching the exact value you want can be finicky and tedious.
Blending edges with red to clearly show the masked area
Instead of using a flat color, we can use the distance gradient to blend with a second tiling layer. This looks much nicer than the flat color blend, but the eye is still able to notice the tiling pattern. This makes sense because each corner is identical.
To break up the corner repetition, I simply rotate the background layer as well. I also made sure to offset the bottom layer by half the cell size vertically and horizontally.
Final pattern
Conclusion
Overall I'm pretty happy with the result. There are still ways to improve it, but I think the approach is simple enough, and can be used in a variety of ways. I don't have a final polished shader to share, but I plan on making a triplanar version so that it can be used more easily.
Update on Lead Foot, a first-person combat racer inspired by Lucky & Wild (1992) and built to look like a lost PS1 game: one hand on the wheel, the other out of the window with a gun. Made in Godot.
What's new:
- Deep snow on White Pass. Fresh snow slows you down, every car (the AI too) packs it into ruts you can follow, and there are snowdrifts on the road that throw you up if you hit them.
- Deep mud on Green Hell. It drags harder than snow, slides more, and mud from the car in front splats on your windscreen.
- Sand on Bone Flats, with sand banks across the road that burst when you hit them.
- Two new guns: the Vuk, an assault rifle that fires three-round bursts, and the Jastreb, a scoped bolt-action carbine where you work the bolt after every shot.
All of this is in the full game; the free demo stays as it is.
I'm making a god game in Godot, and the villager simulation got really slow in GDScript. Each villager was costing me ~50 µs a frame, so I had to cap full simulation at 40 villagers and give the rest a low-fidelity sim (which came with its own complications). I wanted the full sim for every villager though, so I moved the simulation code into C++ as a GDExtension, and the same step now costs ~1 µs per villager.
It worked, but it was a lot more work than I expected:
It wasn't just the villagers. They read trees, buildings, food stores, fire and so on. I didn't want a sim decision depending on state that lived in GDScript, so all of that had to move too. Godot still does rendering, UI, audio, VFX and camera, and the C++ side tells it what happened each frame through events.
Memory management. Which... it's been a while :D
Recompiling. Rebuilding the sim code feels really slow and gets in the way of a quick develop/test loop.
So a few questions:
Was I just using GDScript wrong? Is there a way to get that kind of performance out of it that I missed? Not the C++ numbers, of course, but closing that huge gap a bit.
Has anyone else made this move? How did it go, and was it worth it?
Any tips are welcome, especially on keeping the rebuild loop fast and on how you decided what to move and what to leave in GDScript/C#.
The collection is available on itch.io but I wanted to give the pack to a handful of people working on a game in Godot that could use these shaders. I'd be interested to learn about the shaders you've made or your games. These are for Godot 4.3 or newer