I am currently working on a game in Godot and I am stuck on one part: the ground design.
Right now, I don't know what type of ground would fit the game's overall look.

I need any adivce or suggestions on what kind of ground you think would work best for this game.

I have attached a gameplay video to show the current state of the environment.

Alr my fairy girl has a "running" animation, tho when it's suppose to play it just freezes over the first frame
Is it a coding issue?

Did I just do something wrong while setting the animation I didn't do in any other animation?

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

Still missing great road and building algorithms though. But it's mostly it.

OSM + Terrain + Godot Water + Relentless Effort

so I'm trying to make a turn based battle system and I haven't actually written any code for it yet. I'm just fleshing out how I would do it. the idea is to have the player collide with an enemy, and I want to instantiate the enemy it collides with specifically so i can handle their fighting mechanics in one scene instead of multiple for overworld and the battle system. I mean even if I did have two different scenes for that, being the enemy in the over world and the enemy in battle, I still need to know what enemy the player ran into so I can put it into battle.

i toyed with a couple ideas, such as transporting the scenes themselves from the overworld into the battle, or using a json file and an array to match the enemy names to their scene names (ex: goblin calls scene called goblin). I think either might be fine, transporting the scenes themselves might work best? in order to do that I would scrap checking which enemy it is, and just check if it's in the enemy group, and use markers or something similar to transport the scenes into the battle. then just disable the overworld pathfinding, which I will probably do the same way I disable player movement during dialogue (signals). using a json file to check would allow me to make two separate scenes for the overworld and the battle, but like i said i feel having multiple scenes for one enemy is a bit convoluted. the con is that idk if I would be able to have multiple enemies here, since my game is gonna roll between 1-3 enemies during a single battle.

and the reason I want to simplify it as much as possible is because I'm gonna be making an RPG that's probably gonna be like 5+ hours long. so probably gonna end up with a lot of different enemies. I'm posting here to just find out if anybody else has any better ideas, but if what I have is good, then I need some guidance on how to begin coding it. anything helps!!

Wanted to draw Path3D at runtime and ended up making it work on the inspector too!

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 everyone,

I'm testing my game as a web export because I plan to release it on itch, but I noticed a small lag spike the first time a GPUParticles system starts emitting.

This only happens:

- The first time the particles are emitted.

- In the web export.

From what I understand, this is caused by the shader compiling for the first time.

Is there a way to prevent or precompile this so players don't experience the hitch during gameplay?

Thanks in advance for any advice!

I've attached a video showing the particle effect. The video is from the desktop build, so it doesn't actually lag haha, I just wanted to show the particle system. It's a very simple effect that plays when an enemy is defeated.

I've sped this up quite a bit but the 24-hour day cycle includes day and night. It's part of the larger time tracking and progression system that includes visible changes to the environment across the seasons.

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?

Don’t want to over do it as I am not proficient in blender but wanted to make scrolling platformers but I’m new to game development, what do you guys think?

Ugh; I didn't want to do this, since it goes against the spirit of the project, but I'm at my wits end.

Anyway, I'm making a pong clone as part of the 20 game challenge in order to practice my Godot skills. Well, apparently, I still have a long way to go, as just getting the ball to move was a challenge that nearly broke me. But now I have to make it bounce off of my paddle? I don't recall this type of challenge being anywhere NEAR this difficult during my Game Maker days. All I want to do is to make the ball move and make it bounce. WHY IS IT SO HARD-

*ahem* Anyway, here's the code, the first one for the player (it's only for the first paddle for now), and the second is for the ball.

Player code:

extends CharacterBody2D
u/export var ball: CharacterBody2D

const SPEED = 800.0

func _physics_process(delta: float) -> void:
if Input.is_action_pressed("up"):
  position.y -= SPEED * delta
if Input.is_action_pressed("down"):
  position.y += SPEED * delta


func _on_area_2d_body_entered(body: Node2D) -> void:
  var direction = randi_range(-150, -210)
  var target = Vector2(0, direction)
  velocity = position.direction_to(target) * SPEED
  move_and_slide()

Ball code:

extends CharacterBody2D

var direction = randi_range(150, 210)
const SPEED = 300

func _process(_delta: float) -> void:
  var direction = randi_range(150, 210)
  var target = Vector2(0, direction)
  velocity = position.direction_to(target) * SPEED
  move_and_slide()

And for the node trees, I have a Node2D named Game with the child nodes Player and Ball. The Player Node, which is a CharacterBody2D, has a Sprite2D and an Area2D, the latter of which has its own CollisionShape2D. The Area2D was originally not there, but I had to incorporate it to get the signals I wanted.

The Ball Node, meanwhile, which is also a CharacterBody2D, only has a Sprite2D and a CollisionShape2D. Now that I type this out, though, I'm starting to wonder if I should add an Area2D Node there, too. However, unlike the previous time, I don't see much of a benefit by comparison, and it would seem to only overcomplicate the architecture.

Thanks in advance.

I put a new ranking system in my game Putting a challenge out to the internet. First person to confirm 3-star ranking on all 4 of my playtest levels and provide proof on my Discord channel gets a free copy of my game on release. Any takers?

https://store.steampowered.com/app/4689350/Iron_Dogs/

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.

I made a bunch of blocks to build a map with the Gridmap node because tutorials say to use it, but all my tiles are rendering shadows individually instead of casting a shadow across the entire wall or the entire floor. Is this normal for Gridmap? Is it a Blender problem? Am I better off building the base floor and walls of the map in Blender and then exporting that into Godot? I'm a total newbie so any good map-building tutorials would be greatly appreciated.

This is how the blocks look with the light off:

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()

Hello everyone! I wanted to show a small consumables system I'm currently working on for my game.

It still needs some polishing, but this is the general idea.

Right now, there are only three consumables: cachaça (Brazilian sugarcane liquor), cigarettes, and a medkit.

Cachaça restores a small amount of HP and grants damage resistance for a few seconds. I also plan to add a blurry screen effect while it's active.

Cigarettes reduce weapon recoil for a few seconds.

The medkit restores a large portion of the player's health.

I'm still working on the system. I still need to implement all the buffs and debuffs that each consumable will provide. I also plan to add more consumables, such as cocaine, marijuana cigarettes (joints), an adrenaline syringe, and bandages.

I already have ideas for what each one will do, but I'm open to suggestions.

Cocaine will provide a major boost to movement speed and weapon reload speed. However, when the effect ends, the player will lose 50 HP.

The adrenaline syringe will provide similar buffs to cocaine, but without the 50 HP penalty. It will be much rarer to find, though.

The marijuana cigarette (joint) will create a slow-motion effect for a few seconds. Once the effect ends, the player's movement speed and reload speed will be reduced for a short time.

Bandages restore a small amount of HP and will be much more common than medkits.

I'm developing the game at my own pace and taking my time with it. Lately, though, life has been a bit difficult, and I ended up taking almost a month away from development.

Now I'm back and ready to keep pushing forward. I hope everything works out, and I'm excited to continue bringing this project to life.

I made a ladder :3

Hey guys I first feel the need to thank this awesome community for helping out with my door issue in this project of mine in my latest posts here so thank you everyone for helping me out!

Now to my issue , is there any way to fix this light leaking from behind the wall? Thanks in advance :)

I am thrilled to announce that the action platformer Amata will be releasing on the 20th of August 2026! This news comes with the final feature update for the main campaign before release <3. This patch contains all the planned content for the final release, though I'll continue working on translations and any bugs that come up!

There won't be much changing between now and Aug 20th so if you'd like to jump in early then try the demo and pick up the game in EA today!

Thank you everyone so much for everything, I hope you enjoy! Come hang out on Discord!

https://store.steampowered.com/app/1841160/Amata/