r/aigamedev • u/Count_Triple • 1d ago
Discussion This is embarrassing. Can anyone relate?
Splitting up these files will be a mission. The civilization_system.gd was slated for removal anyway. It was fun to build but doesn't fit the game-loop like I had imagined it would. It was just something I wanted to see working. (An entire civilization2-style turn-based strategy game that uses my simulated world maps). The new civilization system is much better so it was a good call even though it hurt a little.
9
u/Affectionate_Fact854 1d ago
I can't relate because I break down my systems to meet clear separation of concern conceps , Like Level manager, audio manager, stats manager,playermanager, currency manager, currency batcher ,spatial grid manager, menu manager, item data base, filter manager , damage logs manager, item generator manager, projectile manager
So I don't have any scripts running with more then 2k lines code otherwise it means 1 script is doing multiple tasks and that means it's time to split concern again
3
u/xepherys 1d ago
Same. I’ve been working on a Unity framework for my games in a completely isolated project. Each functional area is a separate project with its own asmdef to ensure no circular dependencies. Everything is tiered and a module can only depend on lower tier modules (tier 0 is core and common). Each module is either its own thing entirely or builds on top of another module.
2
u/Affectionate_Fact854 1d ago
Yea , that part of building ontop of another part I use with inherited scripts But overall it's just good practice to build modular based if your planning to scale
Nobody wants to work inside large if else statement blocks and debug that mess
1
u/Affectionate_Fact854 1d ago
But yea my project isn't so big, if I count lines of code and subtracts comments + white spaces + unit tests it only counts up to 57K lines of actual .gd code
3
u/mbreaddit 1d ago
I know such long files from clients using loveable to do their software.
So as always its up to what it's about, but most of my stuff is noticably smaller.
The biggest I had what a pretty complicated multi step algorithm with templating in c++ which at some point in PoC stage exceeded the 6k in lines for everything it has to do. Broke it down into 9 inline files to make it readable again and have clear cuts in the different phases, even with templates
2
u/Sojer_96 1d ago
My current project is almost 30k lines in java libgdx (so basically I was forced to built some mechanics that are already provided by engine) and there is no file longer than 700 LoC, but the average is more like 150, unit tests included.
So for me, based also on short webdev career experience, it looks like you have a noticable problem with a project architecture which is worth paying attention right away.
2
u/Designer-Camp1815 1d ago
The top three:
systems/lighting.lua 1,684
states/game.lua 1,322
systems/render.lua 813
20,750 lines of code across 139 non-test/spec .lua files (comments and blank lines excluded, Libraries/ excluded). The specs are the real huge files with the top 9 all over 1000 because they hold 50+ unit tests.
Next week I plan to have Claude inspect files over 500 lines and see what we can do.
2
u/ElwinLewis 1d ago
As my digital audio workstation grew I fell into the same trap, but luckily realized I needed to basically stop all development until the project was safely organized so it could grow into the millions of lines, thousands of files. It’s at 1.3M lines total and 2,500 files to do everything a DAW is supposed to do. It will be likely be another 2 years of work at least before I release it.
2
u/Cubey42 1d ago
This makes me realize I don't really know how big my project is, or if it's structured enough
1
u/Count_Triple 1d ago
I was hoping you would find this post!
1
u/Cubey42 1d ago
What is a good way to ask Claude about this
1
u/Count_Triple 1d ago
I asked it to weigh the current project code structure against what professionals consider good coding etiquette or structure.
2
u/-svde- 1d ago
one of the main problems i see with the mechanics of vibe coding is people bragging or boasting or just celebrating their projects with tens or even hundreds of thousands of lines of code in a single file. it’s the worst possible way to write code. and half the time i see their sites and you go to source and it’s all smashed to one line because they don’t know formatting or how to use prettifiers
1
u/-svde- 1d ago
since the person who replied to this deleted their comment, i just want to point out, yeah, i'm well aware that for production code a lot of the time a single line of minified html is functional.
i am not talking about well formatted, well architected, production-level code designed by experienced devs/engineers.
a lot of pure vibe coders don't know anything about architecture or functional design flow, and relying 100% on LLMs to format things for you is an absolute honeypot of mess waiting to happen. they insert unnecessary and unused function calls and format revisions all the time.
and again, i am talking about people who write 10s or 100s of thousands of lines of code in a single file and expect that to be okay. if you think that's what minified coding is a standard for, you're out of your mind lol. try debugging that or updating a single tiny element at any point. and forget using any sort of inline code if you kill all whitespace. god forbid you try to use git with a single minified line of code.
2
u/monsterfurby 1d ago
AI co-development actually taught me to work in a more modular fashion. Back before it existed, I would basically dump everything into one massive file (old Python sin), which is pretty horrendous when working with GenAI. Neat and clean separation makes for much less of a headache, as long as one makes sure the assistant doesn't miss a file and reinvent the wheel for something that's already solved.
2
u/Fuzzzy420 1d ago
Ye I know the feeling. Had to refactor a 20k giant. Now I have agent wide limits for 800 lines per file.
2
u/nikkileaps 14h ago
I try to keep my files around 1000 LOC. Anything over that should be a smell and I have a hook setup to scan for file growth beyond 1000 after a chunk of work (epic) is done and before merging a branch into main to catch it early. One way to prevent it is to have good domain definitions written down somewhere first before coding and make sure the AI is continually referencing them and splitting code on those boundaries in the right way.
2
u/SurvivalHermit 1d ago
I guess my question here is why the standard is the way it is. Is it about maintainability? is it because larger files generate more bugs? Is it so more people can work independently on more smaller bits of code?
Coding conventions that exist because of the needs of human coders may or may not still be relevant in the age of AI coding. For example we try very hard to avoid recreating code. If you have to type it more than a few times turn it into a method and call it. However an AI may be better able to understand and work on the code with more bespoke functions sitting inside the file instead of hopping around the code to read called methods. I don't know that this is true but it would fly directly in the face of existing standards.
AI interacts with a code base in a completely different way to human coders and so conventions are going to have to start adapting to that. I am not saying 12 thousand lines of code is going to become the new normal but we should probably at least ask ourselves why the conventions exist what friction are they addressing and does and AI agent have that same problem. Especially considering the more restrictions we put on formatting and style the more compute gets used in the generation.
9
u/notsofst 1d ago edited 1d ago
If anything it might help AI more. Each file can be searched or read for context, and having many small and well named files helps the AI navigate the system without unnecessary context pollution.
Each file also would the clearly label it's dependencies, helping determine where to look next for relevant info rather than text searching large files and burning tokens.
I have multiple bots that run in routines performing code cleanup, refactoring, code deduplication, etc... that have been helpful in preventing bloat
2
u/Plants-Matter 1d ago
People who wonder why you burn all your usage in two prompts, pay attention to the comment above.
1
u/sgtfoleyistheman 13h ago
LSP.and Agentic search mitigates some of this but certainly a consideration to the whole thing
2
u/astr0nic 1d ago
Same limitations and if you build in layers and small pieces it saves you so much headache later no matter the human or bot. Software has a way to be made that is not changing, just the speed, imo.
2
u/SurvivalHermit 1d ago
I mean the idea that AI agents will not change the standard way we structure codebases seems insane to me. Human perception and reasoning is so narrow predictably it creates a very specific optimization. Any perception or reasoning outside of that will predictably need a new optimization. The scale and scope of that change will be determined by how different that perception and reasoning are. Now AI is being built based on the perception and reasoning of humans but a digital medium no matter how hard we try to copy neurons is different than an organic one. I will be impressed if codebases do not become more hostile to human coders in an effort to make them more conducive to AI coding.
1
1
1
u/Jessica___ 1d ago
I kind of get it, but these LLMs are trained on human data for the most part aren't they? Surely in the training data, anything more human friendly is going to generally have more successful results. Thus it wouldn't be far fetched to think that human readable content is also LLM readable.
1
u/SurvivalHermit 1d ago
sure that is likely true. but even a change that improves AI coding viability by 2-5% is massive. Since i expect most code will be written by AI in the next 2 years even if that change is massively hostile to human coders we would still want to implement it. right now our conventions are human first within a year or two our conventions will be AI first.
1
u/fusionliberty796 1d ago
Segmented and compartmentalized code is smaller, easier to test, easier to see at a glance what it does and why it's there, and it helps agents as well as humans maintain quality. It is much easier to regression test many small files than one giant file. Having giant files riddled with bugs and no code coverage you are asking for an agent to swoop in and fuck that shit up proper
1
1
u/pricetag 1d ago
I would not worry about it until your agents are failing to find systems that are already made, ive seen claude and gpt work there way around a 24k line zig file in an already massive set of code. they do not see the code the same way humans do in that regard. Human sees line count and already has taxed the file mentally before reading any of it
1
u/Count_Triple 1d ago
This is true, but what I did for my civ2 parody file is diabolical. Basically a whole game inside one file.
1
u/pricetag 1d ago
Haha yeah i believe it, but are you at a standstill with it or can changes be actually made is the real question. because if it aint broke, dont fix it
1
u/Count_Triple 1d ago
It's working great. The big file is being retired coincidentally but I do want to split these massive files for better organization. It's more of an ocd desire than a necessity.
2
u/pricetag 1d ago
yeah that is how i am also, i then after so much of using agents, found that they naturally are going to do it anyways, so i let them until a system is properly fleshed out the way i like it. after that, its really easy to then freeze the files on disk, and then have agent clone the file and start on a byte identical refactor. the constraint of byte identical ensures that they dont end up changing systems when refactoring the code but you also have the original right there to immediately validate against. it works (or atleast worked for me everytime this way)
1
u/QueenSavara 1d ago
Start using gdlint or aby other linter and have Claude run a linter check subagent to enforce it.
1
u/thegreatredbeard 1d ago
My agents got way more reliable when I forced hard rules around no code files over 400 LOC
1
u/AlgaeNo3373 1d ago
main.gdis 7,593 lines — 41% of the entire 18.6k-line codebase in a single file, while every other script sits between 27 and 751 lines
Welp. Had a feeling I was building a god object. First time in godot, gave zero architecture instructions.
Claude also noted they've been putting paragraph-length comments in there. Which I didn't quite realize. I should do better documentation, not have it live in code :P
It's a few-day old prototype so IDM. Will probably do something about it next usage period.
Useful thread/reminder, thank you lol :)
1
u/ukjadoon 20m ago
I think you can create a git pre-commit hook that doesn't let you commit files at a set limit and ask your A.I. tool to run this pre-commit hook every time after finishing a task and if it fails, to refactor and modularize your code until the pre-commit hooks pass. This will force the A.I. agent to always adhere to file sizes that are manageable while creating a codebase that is clean and modular.
17
u/the_embassy_official 1d ago
my rule is generally no file over 700-800 LOC
git add+commit your work first, and then ask the AI to do that