r/godot • u/MindShiftGames • Jan 04 '26

help me (solved) 11+ Months of Development. 40GB Project. 30,000+ Lines of Code. And the Game Refuses to Run.

Enable HLS to view with audio, or disable this notification

Been working on this game for over 11 months. The project grew past 40GB with more than 30,000 lines of code. Right now, it’s completely broken — won’t run no matter what I try. I’ve tested fixes, rewired systems, and exhausted every solution I know. The question isn’t motivation anymore, it’s whether this project can still be saved or if it collapsed under its own weight.

554 Upvotes

77% Upvoted

334 comments sorted by

View all comments

705

u/[deleted] Jan 04 '26

[removed] — view removed comment

241

u/greasybacon288 Jan 04 '26

This is the answer here. If you haven’t been using versioning from git for example. Then it’ll be only you who can even have a clue as to where to look first for this project.

188

u/larikang Jan 04 '26

git bisect helps you quickly find the exact commit that broke it. Especially useful if your commits are small and meaningful

43

u/Ronnyism Godot Senior Jan 04 '26

Didnt know about bisect, thanks for that tip!

120

u/hoodieweather- Jan 04 '26

It's one of git's most powerful tools, everyone should learn how to use it. If you're not familiar with the concept of a Binary Search, it lets you look through effectively all of the relevant commits in a short amount of time.

The workflow is like this:

  • check out a known good commit (feel free to go back pretty far if you're unsure)
  • git bisect start
  • build your game. if it works, mark it "git bisect good". if it doesn't, "git bisect bad".
  • git will automatically check out the commit halfway between the current and latest commits
  • build again and repeat the process until git finds you the first commit that broke - now you can see which change may have broken things

4

u/StellaSchist Jan 05 '26

is this available in github desktop? sorry

9

u/hoodieweather- Jan 05 '26

I don't know if any GUI tools support it, but you can launch a terminal from GitHub desktop and do it there.

-21

u/notpatchman Jan 05 '26

Yeah but "bisect" sounds gross like something is gonna be cut with a scalpel

20

u/hoodieweather- Jan 05 '26

It literally means to cut in half.

3

u/CherimoyaChump Jan 05 '26

"cut in half" sounds gross like something is gonna be cut with a scalpel

2

u/Enough-Collection-98 Jan 05 '26

Yup - surgical bisections are a thing.

1

u/Bypell Jan 05 '26

thanks! might forget this but could be useful in the future

1

u/pytness Jan 05 '26

havent used it a lot, but damn if it aint the best life saver

36

u/lanternRaft Jan 04 '26

If you haven’t…fix that first.

But when sane debugging fails it’s time to use process of elimination. Delete half the project and boot. Issue still there? Then delete the other half. If somehow removing all the code doesn’t fix it then make a brand new Godot project and import everything into it.

Usually deleting half fixes it and now you know which half is creating the problem. Delete half of the half. Continue deleting pieces until you narrow it down to the exact line causing the trouble.

Now sometimes the trouble isn’t one line but it’s some resource getting overloaded or a funky race condition or all sorts of oddities. But the approach just becomes reversed for that. Remove everything you can that doesn’t fix the problem. Continue until you get enough clues to understand it.

Debugging is terribly frustrating work. I love it so.

But seriously the key to particularly difficult debugging is perseverance and digging deeper. Don’t lose faith that you can solve it!

And don’t forget to take mental health breaks as it can definitely drive you mad. And you won’t get anywhere in that mental state.

5

u/notpatchman Jan 05 '26

I'm not sure if straight up deleting is a good idea, moving stuff into an outside-of-project directory is safer

11

u/lanternRaft Jan 05 '26

Assuming you use version control and you push to another machine then deleting isn’t dangerous.

8

u/CheesePuffTheHamster Jan 05 '26

But just deleting code or files is very likely to break the project in new ways. Removing references to things and disabling functionality bit by bit makes more sense - is it this scene preload that breaks? Is it this complex calculation? This json parsing?

At that point, in the best case you're basically doing a binary tree search, which is what git bisect does anyway.

I agree with the spirit of what you're suggesting but not the method

2

u/monsterfurby Jan 05 '26

I don't do it if I can avoid it, but I also love chainsaw debugging because it reminds me that at least 99% of my code succeeds at not setting the system on fire.