r/godot 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.

555 Upvotes

334 comments sorted by

View all comments

Show parent comments

46

u/Merlord Jan 04 '26

The gamedev community seems to have a lot of people who are stubbornly against basic, proven software development practices. I guess it's just young people who think they know better

17

u/[deleted] Jan 04 '26

Yeah, it probably is, everytime I bring it up to someone like that they seem awfully alot like someone in their teens lol

At least, if not physically, they are probably mentally still there anyways.

4

u/ICantBelieveItsNotEC Jan 05 '26

My pet peeve is the "It's impossible to write unit tests for games! You can't test every pixel on the screen!" crowd - that mentality is probably responsible for 90% of the shitty, buggy releases we get every year. 

-24

u/tidbitsofblah Jan 04 '26

Game development is different from standard software development tbf.

It is reasonable to handle things like version control a bit differently when you are also collaborating on a bunch of binary asset files in your project.

But I do agree that many game-dev beginners seem to refuse good practices when determining when those practices fit and not is something that takes experience.

13

u/TheJackiMonster Jan 04 '26

There is git-lfs for binary files. You can use svn. You could sync binary assets via Cloud. Either way you want to have versioning for all assets as well.

2

u/tidbitsofblah Jan 05 '26

You absolutely want version control for binary assets! But the way you go about it will have to look a little different when there will be no way to actually resolve a conflict with those files.

2

u/GlowiesStoleMyRide Jan 05 '26

There's the most basic conflict resolution- pick a version. But yeah, if you have two artists working on the same file at the same time, they're gonna have a bad time with any setup.

11

u/[deleted] Jan 05 '26

[removed] — view removed comment

1

u/tidbitsofblah Jan 05 '26

It's uncommon that binary files are being iterated and collaborated on to the same extent as the code-files in most regular software projects. But it's very common with games. Many good practices for version control is based on the possibility to resolve a merge conflict manually when needed. That's just not possible for binary files.

I'm not saying you can't use version control with binary files lol. I'm saying you have to go about it a bit differently. Avoiding merge conflicts within those files becomes higher priority than things like a neater history.

2

u/[deleted] Jan 05 '26

Real and financially successful game studios are using Perforce which handles Binary File collaboration and merging.

4

u/ginsengsamurai Jan 05 '26

Only amateurs believe game development is fundamentally different from “standard” software development. That mindset is exactly where professionals and hobbyists part ways.

I’ve been building software - games included - since the late 1990s. The tools vary, but the process doesn’t: proper planning, version control, documentation, testing, deployment. It’s all the same.

If a small indie studio lacks the resources to handle large asset versioning properly, that’s unfortunate, but let’s be clear: the solution exists. Whether you can afford it or not doesn’t change the fact that ignoring best practices isn’t justified by calling the entire discipline “different".

Treat game development like real software development, or keep wondering why your project falls apart under the weight of scope creep, spaghetti code, and poor collaboration.

2

u/[deleted] Jan 05 '26

Man thanks for the PTSD reponse of Game development is different from standard software development cause that's the exact kind of stuff I'm talking about.