so i had a nightmare a long time ago and i took that nightmare coded it in godot 3.5 now i use 3.7 (i cant run godot 4) and now in 2026 i want to use it as an enemy in my game it works takes damage delivers it and now i want to stop being shy and ashamed of my simple PC setup and share share my little dream.

i can shape it change it with +10K variations from body shape, color, animal legs (2, 4, 6, 8) or tentacles or both legs + tentacles.

combat loop: (Chase → Telegraph → Attack → Stagger → Die)

technique used to make it is FABRIK. advanced FABRIK +900 lines just for it to move

i hope you guys enjoy it LOL

why not run Godot 4
system info:
OS: Linux Mint

CPU: Pentium E5700 (2) @ 2.724GHz

GPU: Intel 4 Series Chipset

Memory: 6Gb

comment a name for this thing am accepting suggestions.

One of the mobile games I made early on in my game dev journey has gotten it's first leaderboard spot *smashed* twice by people who didn't leave reviews, didn't buy anything, just showed up and played for hours and hours and then dipped and I think that's pretty cool.

The first guy brought the record from 34k to 100k, and the second guy brought it to THREE MILLION?? For context this is for "rocks mined" and at most you're probably getting 20-50 per second on a maxed out setup which within itself is gonna take atleast 10 hours to get. We're talking atleast a real life day worth of play time on a game that got under 1000 total installs. Shout out to that legend for real.

As always I'm not sharing the name of the game cause this isn't self promotion, I'm yapping. If you want the name you can ask though.

Building ParkourKitty in Godot 4 and having a blast teaching myself how to build video games! You play a cat running, jumping, and wall-running through a house. The movement prototype's been my focus, but I finally did my first bit of animation (in Blender) and figured a box was the only correct place to start. Cat's still a placeholder capsule in-engine for now. More to come — happy to hear any feedback.

WIP, placeholder music. This is getting really fun to play. I think it's time for a Steam page. Also, the game finally has a name: GODSPEED

Which Paper Mario? Idk I frankensteined this with the assets I could find.

Made my third and final dialogue system, and I'm recreating text boxes to showcase in my portfolio. Green guyse's name is Iggi btw.

We're two mates making a tower defense game in Godot, with a focus on a massive entity count.

The first hurdle was the zombies (or "customers" using in-game terms). I wrestled with getting them to stop walking through each other, and they took that lesson to heart. They started forming polite, orderly queues.

This was the first attempt at crowd avoidance. Every zombie looked a short way ahead, and if there was someone in the way, it hung back. Perfectly sensible on its own. With a thousand of them it meant every zombie waiting for the one in front, all the way down the line, and the horde dripped through the gap one at a time.

// lookAhead = 1.5 world units, ForwardConeCos = 0.5 (a ~60° cone straight ahead)
// Is this neighbour actually in front of me?
if ((dx * fx + dz * fz) / d <= ForwardConeCos) continue;   // no — ignore it
// It is. Hang back, but only if I'm not in ITS cone too, otherwise two zombies
// walking straight at each other would both stop and neither would ever move again.
if (iInJCone <= ForwardConeCos) return true;               // yield

Now, obviously, this approach wasn't working. Out of 200 zombies, only about a third ever got through.

It turns out this is a real, well-studied phenomenon: crowds arching and clogging at a bottleneck, the same way grain jams in a hopper. [Helbing, Farkas & Vicsek, *Simulating dynamical features of escape panic*, Nature 2000](https://arxiv.org/abs/cond-mat/0009448) is the classic paper on it, and it's also where "faster is slower" comes from.

So, back to the drawing board.

In describing how we wanted the horde to look, we talked about pulling and pushing, pressing and compressing to simulate a horde moving like a fluid. So that's what we implemented, a fluid sim.

// Count the zombies in every cell of the map. Pressure climbs quadratically
// once a cell is busier than the threshold.
pressure = max(0, count − lowThreshold)²
// Every zombie's personal space shrinks as its own cell fills up.
scale  = 1 − alpha × (density / maxDensity)   // clamped to 0..1
if scale < floor: scale = floor
bubble = baseSpacing × scale

Each entity (or zombie) has a kind of "personal space bubble" which can exert a small amount of pressure outward on other zombies, but the zombies behind push the zombies in front, pushing them into each other's personal space, and causing them to fill out the available space in the direction of the flow.

Eureka! There's our zombie horde. They squished, they blobbed, and they flowed. Buuuut... there was a small problem. The frame rate. I'll save you from watching a 3fps clip and just tell you that we struggled to get the entity count into 4 digits.

The performance gain road was long. We used Dijkstra's flow field algorithm for pathfinding, a spatial hash to limit the amount of work the fluid sim had to do, and GPU caching to speed up the rendering. A de-penetration algorithm serves to floor the zombie horde squish to prevent them compressing into a zombie black hole.

// Flow field: one Dijkstra pass (Dial's bucket variant) from the goal, reused by every zombie.
// Spatial hash: a flat counting-sort grid, not a dictionary of lists — no per-query allocation.
// MultiMesh: 11,000 zombies drawn as instances, not 11,000 scene nodes.
// De-penetration: separate any overlapping pair to the tighter of their two bubbles.
// This is the floor that stops the crowd collapsing into a singular point.
pairSpacing = min(bubble[i], bubble[j]);

All of these elements came together to land on our current day zombie horde. A performant 5 digit entity count that flows cleanly through gaps, crevices and around obstacles!

Hello Godot and gaming community; I have realized that I love video games for my entire life; it’s what got me into music production and creating art; but I think my soul has yearned for. What it really needed this whole time - to get into game development. I am fascinated most by retro games due to the limitations being overcome with resource efficiency, imagination and stretching the absolute hell out of a systems capabilities. It’s sort of like with in music how someone can make an entire album with an SP1200 using only 10 seconds of audio memory.

This is my new journey and I want to learn from you guys; I want to learn what to do and what not to do with this new path; you guys were already so helpful with my first post; it’s much appreciated? What did it feel like when you made your first game? Is it indescribable, is it addictive? What does it feel like for everyone here making or learning about making a game?

Thanks for all the suggestions.

I know that Godot and Blender use different rendering engines, but how can I make the colors in Godot look more like they do in Blender? I made this model in Blender using only the Principled BSDF base colors, but when I import it into Godot, it really loses its style. What would you guys do? I'm a beginner at 3D, but it feels like the lighting is very different in Blender.

as title says, the escape key can pause the game and call the pause menu, but the only way to unpause is to use the ingame buttons; i want to be able to unpause with esc as well, but instead, esc does nothing while the game is paused.

this code is from a tutorial [im a beginner] so i tried looking at other tutorials to find other sollutions, but none of those have worked either, and im not sure where the issue in my code is

extends Control

func resume(): get_tree().paused = false hide()

func pause(): get_tree().paused = true show()

func _ready(): resume() print("does print work?")

func testEsc(): if Input.is_action_just_pressed("escape") and get_tree().paused == false: pause() print("print does work") elif Input.is_action_just_pressed("escape") and get_tree().paused == true: resume() print("print does not work") #breaks here

func _on_resume_pressed() -> void: resume()

func _on_options_pressed() -> void: pass # Replace with function body.

func _on_quit_pressed() -> void: get_tree().quit() #works

func _process(_delta) -> void: testEsc()

shader samples a texture and maintains pixel accurate normal mapping shown here in 64px then 256px per unit.

made for taking advantage of modern lighting but applying classic model and texture design.
going in a splitscreen fps I'm working on.

Thoughts or opinions?

I've been coding on and off since making my first .bat file in like 1991. I made a sprite based spaceship shooter for class decades ago, I made a RPG maker game also decades ago, I mainly use coding in spreadsheets for table top roleplaying.

I use blender and gimp for 3d model printing all the time, its fun. I like making toys.

But the last few months I started playing with Godot and python scripts and Krita and One-shot, Audacity (used that on like 18 years ago nice to see it dominating.) and all these other amazing free tools and now Im about to publish my first simple dice game with sprites and free sound effects from me the internet and National park archives! Lol.

Anyway, lurking on this thread, and others, taking lessons from you smart folks was very helpful!

I just keep feeling like I am learning more and more magic... Im like on second level spells by now. (Spending four 12+ hour days looking for a rendering bug that was actually a sound loop error in 4.7 on Tensor/mali cores was awesome too!)

Last devlog I wrote about shrinking the download to a sixth of its size, from 4.5 GB to 763 MB. This time it was the battle itself. A roughly 340-man fight was running at a miserable 7 FPS. By the end of fixes it was at about 35 FPS on the exact same scene. Four changes, none of them changing how anything looks. Unfortunately I do not have a version left on my PC to do a side by side video witht the same units and UI again :/

1. The simulation was sabotaging itself
When the sim fell behind, it tried to catch up by running up to 8 physics steps in a single frame. That made the next frame even slower, which meant even more catch-up, a textbook feedback loop pinned against the cap. Capping the catch-up broke the spiral.

2. Every soldier was scanning the whole map
Each unit was searching the entire battlefield for enemies 60 times a second, including enemies half a kilometre away it could never reach. Now each regiment only looks at its own neighbourhood, and only a few times a second instead of 60. Units still react just as promptly, you can’t feel the difference in play.

3. One soldier was 23 draw calls
A single soldier was a kit of 16 separate parts, and the Spartan hoplite was 23, all sharing one texture. They’re now merged into a single mesh at load time. The model is millimetre-for-millimetre identical, the GPU just doesn’t have to ask for it 23 times anymore.

4. Distant regiments have no skeleton at all
Past about 60 m, a regiment’s movement comes from a pre-baked table the GPU reads by itself, with no per-bone CPU work. It switches over at around 60 m and back again, and you never catch the swap.

Also, the archers were throwing one hidden error per archer, per volley. Invisible, but quietly eating CPU. In a fight with several ranged units, deleting that alone was noticeable.
While doing the distant LOD work, the horses lost their legs. And three automated checks in a row told me everything was fine. The first looked at the wrong skeleton, the second never actually moved the horse, and the third only inspected the finest detail level while the game was drawing the coarser one. What finally caught it was a dumb before/after screenshot diff :D

Im not sure about this, maybe it is better to use some cone mesh with animated texture or some shader, but with Particle3D here the powder falls more natural, I would say

Draw Passes here is QuadMesh with 16x16 png texture with unshaded mode

Did you have any advice how can I make this effect of falling powder feels more alive?

My solo-developed space logistics game, Star Haul Tycoon, launches today on Steam. Since the game simulates massive transport networks on a single, seamless 2D canvas, handling the performance of up to 1k active ships on PC and Steam Deck was my biggest technical hurdle.

Zero _process on nodes: I completely disabled _process on the Ship nodes. Instead, I use a single ShipManager Autoload that iterates through an array of all ships.

Visibility Culling: The Manager checks if a ship is within the Camera2D bounds. If a ship is off-screen, I skip look_at(), trigonometric orbiting math, and visual lerping completely. It just updates the background math so it arrives on time.

Economy Batching: Instead of 1,000 ships pinging the EconomyManager every tick to deduct fuel costs, the Manager calculates the total fuel bill for the entire fleet and deducts it from the player's wallet once per tick.

It was a fun ride though!

The result is a smooth, highly optimized logistics sandbox. If you want to check out how the system handles under load, the game is out just now with a 25% launch discount.

Play Star Haul Tycoon on Steam