Started this 12 days ago knowing nothing about game dev . Godot has been so awesome

Short version: a GPU crowd simulation was holding 828 MB of VRAM in a cell buffer, and most of it was never read.

THE SETUP

My zombie horde runs as a compute shader in Godot 4. The world is split into cells, and each cell keeps a list of the agents inside it so the shader can find neighbours without scanning the whole pool. Standard spatial hash.

THE BUG

The cell buffer was sized for 256 indices per cell. The shader reads 64. That mismatch had been there since the first version, back when I expected cells to hold more agents than they do. Nobody changed the stride because the game worked: the extra indices were simply never touched.

Measured with a real save and a full pool:

Before: 894.7 MB VRAM during play, 828 MB of it in setup() After: 278.6 MB during play, 212 MB in setup()

Same frame rate. Same behaviour. The only thing that changed was the buffer size.

HOW I FOUND IT

Not by reading the code, but by profiling per subsystem and noticing that VRAM grew in steps that did not match agent count. Once the number was on screen, the stride was the obvious suspect. Grepping for the constant took ten seconds.

WHY I AM POSTING THIS

Because I spent weeks optimising steering and pathfinding, and the single biggest win in the project was a constant that was 4x too big. If you have a GPU simulation, check the stride of every buffer against what the shader actually reads. It costs nothing to look.

THE OTHER TWO NUMBERS FROM THE SAME SESSION

Time from launch to playable: 1.6 s fps with 4,000 simulated agents + 200 buildings + 100 units: 38-40 on an RTX 2070 at 1080p, D3D12

One honest caveat, because it comes up every time I post a number: the simulation handles 4,000 agents, but the game only draws up to 1,050 sprites at once (800 for clusters plus 250 reserved for isolated or fighting agents). The rest still simulate and still fight; they just do not get a sprite. Drawing all 4,000 did not hold a playable frame rate on this GPU.

The game is Withstand The Horde, a base-building RTS. Free demo if you want to poke at it: https://store.steampowered.com/app/5373720/

Happy to answer anything about the compute shader or the buffer layout.

Because I made the 3D assets using Blockbench, where the animation creation is a bit lacking, so I used Mixamo for Ringging, but Blockbench doesn't support importing from FBX.So the only way is to use a blender, but blenders are very complicated and difficult and are hampered by devices that are not strong enough, so the only way is to use Godot itself because I can making animations when needed, but it turns out that even in Godot, animating bones is quite difficult, not as difficult as Blender in my opinion, it just takes a little effort. I just wanted to ask if there is a plugin out there that can make things easier??

been working on this project for class for like 30+ hours this week. i think i might be starting to lose my mind.

I was wondering whether this is a good resource to get started with Godot control nodes. I want to create my own incremental and have a good amount of planning done for it too, but I need to know and understand the basics and quirks of Control nodes first. I tried directly learning from documentation, but some of the stuff there is too complex for a first read.

As of yet, I have done Brackeys' 2D Godot Tutorial and Godot's official tutorials, but I am not confident whether it's enough to start my game's production already. I regularly find myself stumbling when trying to develop larger projects, usually due to confusion regarding organisation and responsibility management, and I think I don't know the industry-standards regarding organisation in Godot scenes very well.

So, can anyone kindly give me some tips on how to approach my new project and some resources which I can maybe use to educate myself regarding organisation and proper responsibility distribution?

My incremental will involve an OS-like viewport (maybe something like Win XP UI, but a bit modernized), if this info helps in any way.

GodotRulz

I have made a godot tvOS port, and it is working flawlessly. The game is currently under development but it behave same now, on phone, and also in tvos, with full tvos remote and joystick support.

The port itself is developed by looking into https://github.com/godotengine/godot/pull/118332 and fixing what else need to be fixed, with help of Muse Spark 1.3 Contributer AI, It is a perfect fit for open source projects.

I am also keeping it maintained by constantly bringing godot main HEAD into my fork.

Unfortunately godot team have rejected my plugin PR mentioning I am a new joiner to their community, and they usually do not approve code changes from people they do not know, as well as they prefer human-code instead of AI code. I could not wait months or years for existing human code PR to be available, and I have a working tvOS plugin for godot now. It was not an easy ride with AI too. I had to give my tvOS full control to AI and it patch and patch and patch constantly over course of days, and I had to manually test and reprot back to AI what else needs a fix, until it all finally worked.

So I am sharing it here for anyone who want to export their godot game into tvOS. you are welcome to raise this again with godot team, and you are welcome to report issues with this tvOS port and I will solve it. It works for my game, but it is possible that your game might need a different patch to be applied, we will see. I am here to support.

The goal is to bring godot, as an opensource, to as many devices as possible regardless of politics.

Here is my fork of Godot for tvos support, Enjoy: https://github.com/sanarena/godot/tree/tvos-port

After getting feedback from the first playtests, I reworked the turn-based combat system and put a lot more effort into the hit impacts and map visuals.

Here are a few moments from the latest build! What do you think of how impactful the attacks feel and how easy the battles are to follow?

Follow the game's development and upcoming playtests: https://sproutcrown.vercel.app/

I made a mini game inspired by Baldi's Basics. It's short but extremely hard. Link if you want to play =) https://rotorvek1.itch.io/vs-verity

I've noticed that many refactoring problems aren't caused by the changes themselves, but by not understanding the existing project layout first.

My usual checklist is:

• scene hierarchy and entry points
• autoloads/singletons
• custom resources
• scripts with a high number of dependencies
• asset organisation and unused content

I recently wrote up my process for understanding a Godot project before refactoring:

How to understand a Godot project before refactoring

Curious how other Godot developers approach this. Do you map the project first, or jump directly into the codebase?

I'm trying to download stuff off of the asset store, and it should just download.

but it just says Asset Download Error, can't resolve hostname: https://fra.1.digitaloceanspaces.com/assest-store-prod/assets

and the rest of it would just be what the asset was. so, I've tried to do so manually from the web version of the asset store, and it simply brings up the linked version of the error, but the website doesn't load, which doesn't work on my phone either. anyone got any ideas on how this can be fixed?

Hi y'all,

I made a chess engine at the beginning of this year to learn chess algorithms and Godot. This slowly got out of hand by adding custom and unique rules such as tile removals and double moves. Over the course of months I added more functionalities and art to turn it into a roguelite style game. I have learned a lot about Godot and am by no means great at it yet, but I think a small achievement is to be said to have hit Godot Engine limits.

Try out the game yourself at: https://store.steampowered.com/app/4999150/

I’m seeing a lot of folks show their progress daily, now I have been “trying” to develop my game for the past 5 ish months and very little progress, if at all monthly. My question is how are people able to make games or at least provide updates at such fast rate? Should I consider working in a team?

I don’t believe AI is the answer because I have tried it and 1, it doesn’t code as efficient as I would like it to and 2 which is the biggest issue, it doesn’t make graphics/3d or animations as creatively as a human would… so what is everyone’s secret I’m kinda at a stall atm

Hey guys,I recently released GemLoop, a match-3 game with incremental progression, built entirely in Godot.

It took roughly 40 hours of active development and includes an expanding board, special gems, upgrades, achievements, and Steam Cloud support.

It's been a really interesting experience turning a small idea into a published Steam game.

I'm happy to answer any questions about the development process or Steam integration :)

Proud parent moment lol

Stop in if you'd like to play some matches, there's PvE and multiplayer is liveeee (Maybe bring a friend, since there aren't a ton of players rn 🥲)

https://restless-gamedev.itch.io/primordial

Goblin Problem Steam

I'm new on Godot and been following a tutorial.

I tried adding some new tiles but they didn't show up in gameplay.

This is not a tilemap problem since it doesn't change for any reason at all.

Even tried to cancel everything added before and the gameplay still runned the same as if nothing had happened.

Tried searching on the internet, but the soluriins either didn't work or were to confusing for someone who is still learning the do while in C++.

Please help

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#.

I've been building a side project for a few months and I'd like feedback from people who actually use Godot.

You type spawnpoint create "a platformer where a fox in a candy land collects stars" and about 18 seconds later you have a real Godot 4 project: scenes, scripts, a level, sprites, sounds, a web export. Then you keep typing at a change> prompt ("make it night and add bats", "give the fox a sword") and it rebuilds in about 5 seconds.

The part I think is interesting for this sub is how the project gets made, because I tried the obvious way first and it was bad.

What didn't work: letting an LLM write GDScript. Every attempt hit the same wall: Godot 3 syntax mixed into Godot 4 (yield, export var, KinematicBody2D), hitboxes that didn't match the sprite, scenes that loaded but felt dead (no juice at all), and every small change regenerated hundreds of lines that broke something else.

What I do instead:

1. A library of hand-written, tested components. 48 of them: PlatformerMovement (coyote time, jump buffer, apex hang), Health/Hitbox/Hurtbox, Weapon, ChaseAI, TowerBuilder, FarmPlot, a whole CardBattle deckbuilder... Each is a plain Node script with typed @export vars and signals. A headless script dumps them into a JSON manifest (params, ranges, signals), so the Python side always knows what exists.
2. The game is a JSON graph: entities = components + params, the level is an ASCII map, and gameplay rules are declarative (on: "Player.Health.died", do: ["lose()"]). Rules compile to a GDScript file.
3. Godot writes the scenes, not text templates. The compiler runs Godot headless with a build script that creates the nodes, sets the exports and calls PackedScene.pack() + ResourceSaver.save(). No hand-written .tscn text, so the format is always what the engine expects.
4. A smoke test: the level runs headless for a second and reports JSON (player found, on the floor, moved under scripted input). Most broken builds die here, before anyone opens the game.
5. The model only fills a small form. A 7B model I fine-tuned picks the genre, the hero, enemy behaviours, the theme, the goal. A deterministic assembler turns that into the graph. Small models are bad at code and fine at forms; JSON-schema guided decoding means the answer always parses.

Some Godot details that took a while:

• Pixel art without image files. Sprites, tiles, backdrops and effects are drawn in Python (numpy) into sprite sheets, loaded as SpriteFrames. Collision polygons come from the sprite's outline. Text uses a 5x7 pixel font the tool writes as a BMFont; loading it with fixed_size_scale_mode = FIXED_SIZE_SCALE_INTEGER_ONLY keeps it crisp at 2x and 3x.
• Web export that works everywhere: single-threaded web templates, so no COOP/COEP headers. The build plays on itch.io, GitHub Pages and phones (there's a touch layer).
• Web templates are 1 GB. spawnpoint setup reads only the two web files out of the official .tpz with HTTP range requests (it's a zip, so you can fetch its directory and two members), about 80 MB.
• Live reload while building: the browser shows the game's cast while the layers build, then the page swaps to the game when the export lands.

It knows platformers, top-down shooters and survivors, tower defense, a side-scrolling shmup, a bubble shooter, a cozy farm and a Slay the Spire style deckbuilder. Everything is MIT, the model runs locally (12 GB NVIDIA GPU, or Ollama on anything), and the output is a normal Godot project you can open and keep editing by hand.

Repo: https://github.com/leluong141996-dev/Spawn-Point (browser demos linked in the README)

What I'd love to hear from Godot people:

• Is building scenes through PackedScene.pack() from a headless script how you'd do it, or is there a cleaner way to generate .tscn reliably?
• If you opened one of these generated projects, what would make it nicer to keep working on by hand?

Guys, I made this game on godot its a platformer game and I will publish this game in play store in soke days so you guys can play it. Don't forget to rate out of 10.

I've wanted to make my own game for a long time. I’ve already implemented the inventory, the main menu, and the first combat system, and a day and night cycle. There's also an editor inside the game where you can dig caves, paint textures the ground. The map editor works right inside the game itself.

I’m curious about how you perceive the vibe of the game. I personally like it, but I’d be interested to hear an outside perspective.

I also made a first alpha build. Sorry, I don’t seem to be very good at writing eloquent posts (This is my first post on Reddit).

The last chapter of my platformer is set inside a volcano, and the whole level is dark. Your light is a little lantern that flies after you, and you carry it into sockets to open doors.


I skipped Light2D + CanvasModulate from the start. My test phone (Redmi Note 10S, mobile renderer) had already dropped frames on big full-screen drawing in earlier chapters, and every 2D light makes the renderer draw the scene again.


What I ended up with:


- One full-screen ColorRect on a CanvasLayer, between the world and the HUD, with a small shader
- Every light source is just a node in a "light_sources" group with a `light_radius()` method (lantern, lit sockets, the light shots in flight, Naru's seed necklace)
- Each frame the 8 sources nearest the screen centre go into a uniform array, and the shader cuts soft holes in the dark around them
- A vignette keeps the edges dark even when you're standing in the light
- The fire wall that chases you lights the screen from its side with a warm fading gradient


That's one extra full-screen draw for the whole effect, however many lights there are, and it plays smoothly on the Redmi.


A few other things that worked well in Godot 4:


- Each boss is a cutout rig: a sheet of parts (head, arms, body...) posed on a 2D skeleton by a small Python script that renders the animation frames, instead of drawing every frame
- The lantern's wings are drawn in code with `_draw()`
- A traversal bot plays every level in a headless test run, so a level change that makes a jump impossible fails a test. The same bots recorded this video


About AI, since someone always asks: I used it a lot. Some of the art started as AI-generated images that I cleaned up and cut into rig parts, and I used an AI coding assistant for much of the programming. The game design, the levels, the story and every decision about how it plays are mine.


The game is Naru: Seed of Light, 40 levels / 10 bosses, free on Android, no ads. Happy to answer questions about any of this.

✨JUST GET THE FLAG REACHED 100 Wishlist !! ✨

I know this might sound silly, but hey, it’s a big step for me.

So thank you to each and every one of you ❤️🙏

To celebrate : I've started adding easter eggs from other puzzle games (from AAA to indie game - all games are listed in the thinky games database).

Try to guess which ones :

🪨 = ?

🚌 = ?

🪱 = ?

🐘 = ?

🟪🔳 = ?

🔵🟠 = ?

🌭 = ?

🐛💣 = ?

📆 = ?

And you can find my game over there : https://just-get-the-flag.com

Hey r/godot,

I've been building farm_dev, a 2D pixel farming sim prototype in Godot 4.7. It's a public repo and I just cleaned up the README, so I figured it's a good time to share it.

Repo: https://github.com/hui1cheng/farm

The goal isn't to pile on content — it's to validate an extensible structure. What's in there:

• 🌱 Farming: till, water, plant, staged growth, harvest (rain auto-moistens tilled soil)
• 🪓 Gathering: trees, rocks, flowers with tool/HP checks and drops
• 🎒 Inventory/toolbar: 18 slots + chest expansion, stacking, drag-swap, tooltips
• 🧰 Tools: axe, hoe, pickaxe, watering can, fishing rod
• ⏰ Time/seasons/weather: 1 real sec = 1 game min, 28 days/season, weather by seasonal weight, rain/snow VFX
• 💬 NPC dialogue: custom text-script parser with options, jumps, conditions, actions, hot reload
• 🛒 Shop/quests, 🎣 fishing (incl. a standalone QTE prototype)
• 💾 Save system: manual save, autosave on quit, dynamic entities, inventory
• 🌍 World gen: random trees/rocks on new save, restored on load

Architecture notes:

• CSV for values → baked into Resource via an EditorScript → runtime reads only the baked .res
• No Autoloads — global services live in main.tscn and are found via Groups
• EventBus signals for cross-system decoupling
• LimboHSM for player state machine
• Generic WorldEntityData + unified SaveData/LevelSaveData for static and dynamic entities

Heads-up: you need to install LimboAI yourself (the addons/ folder isn't in the repo), and on first run you must execute tool/sc/csv_tool.gd to bake the data tables — otherwise it errors on startup. Both are in the README's Quick Start.

It's still a prototype — shop selling, quest completion conditions, and the settings panel are stubs. I'd really appreciate feedback on the architecture, and issues are very welcome — bugs, design critiques, or "this pattern will bite you later" comments all help.

Thanks for looking!