Want to see how horrendous my code got after 3 straight months of crunching for this game?
Want to see the silly comments I left for my future self?
Want to know how this recreation of my recurring nightmare was made?
20 Likes
Looking forward to finding time to check this out!
5 Likes
Was that 3 months full time? Impressive regardless! I just attempted a two week surge and it was quite the endeavour!
6 Likes
Yeah, I was putting in around 48 hours per week, and then increasing it to 84 hours per week in the last half of March. It was absolutely wild! 
7 Likes
Okay, so when I first started this project, I had thought I was noticing a pattern of āone source file per moduleā, and that I would be sticking to that.
However, this had made my project an absolutely bloated catastrophe over time, so I have now split my really huge object definitions across chains of modify statements, each contained within a dedicated source file, with the collection being imported with a .h file.
So, for anyone who felt really intimidated by 1,000+ lines per source file: Iāve remedied this, because it was driving me absolutely crazy.
The modify statement is a part of the TADS 3 language, and Iām going to use it for the unintended purpose of making my code easier to maintain and organize.
Absolutely ridiculous.
11 Likes
Yeah, I do more or less the same thing. In general I start out with ābigā objects going in their own source file, but then really big objects get split into multiple source files by function. I think the ugliest example of this is that NPCs get split across several files where one contains the ābaseā definition and then all the other ones are a modify [npc object name]; followed by a bunch of +[declaration] statements, like:
#charset "us-ascii"
//
// alice_dialog.t
//
#include <adv3.h>
#include <en_us.h>
modify alice;
+HelloTopic
"Hi. ";
;
+ConvNode 'lunch';
++YesTopic, SuggestedYesTopic
[...]
++NoTopic, SuggestedNoTopic
[...]
++TacoTopic: Topic 'tacos'
++AskTopic @TacoTopic
[...]
;
ā¦and so on.
The āblankā modify statement feels a little silly, but I find it really helpful for organizing things.
4 Likes
Omg Iām not crazy or alone! 
Iā¦did not know that was possible! Thatās super cool!!
3 Likes
I am quite sure the topic of filesize v filecount is every bit as religious as perl v python or paren-indentation. So let me wade right in!
Does this strike folks as excessive? I tend to think of 1500 lines as a āsweet spotā of file size. It strikes me as big enough to encapsulate reasonable complexity and/or significant geography, but not overwhelming.
I may be biased because my in flight has chunks that range from 1200-1800 lines, so that may just be the granularity my brain is comfortable with. Fully understand no right or wrong answer here. For my part, I think I would struggle more with object/NPC complexity split across multiple files than one big one!
3 Likes
Itās mostly a thing of me keeping similar areas of functionality closer together for easier bugfixing and reference, which is a lot harder for me to do when itās all one giant class/object definition. If I split it up into multiple files, then itās much easier to quickly scroll around without passing up the functional region I was looking for. It also makes it harder for me to slowly leak code into the wrong functional region on accident, which forces me to reorganize later.
I know some Java devs solve this by making giant ASCII art banners with comment lines, but thatās not what I want to spend effort on.
The only downside I can see is the same-file search function gets a little awkward, but I regularly use project-wide searches most of the time anyways.
Also I remember a few Java devs in the industry saying that if a source file exceeds 1,000 lines, then thereās room to break it down into more specialized classes, and now I canāt break the habit lol
My average source file is usually 400-750 lines.
3 Likes
Since I learned programming through TADS/my current game, I had no gauge and created files on a whim. I would skeletalize a geo region (or a couple) in a file, and months or years later come back and flesh everything out. By time they had fully bloated I had two files over 4k, three files over 3k, 8 more between 2 and 3k, and five more over jjās sweet spot. (6 others less than 1500). For the most part I didnāt feel like reorganizing things and left them as they were. I canāt say that itās been much of a drawback since Iām usually jumping around by symbolā¦
2 Likes
I also never thought about the blank modify followed by +, but Iāve never needed it. Pretty slickā¦
2 Likes
Yeah, thatās one of the major factors for me.
Usually what I do is if I have some general utility functions/classes/methods that are more than a couple hundred lines, Iāll split them off into a standalone library. Especially if a bunch of different things touch/use the code, because then I want to be able to code up test cases for the various bits for regression testing.
But even if Iām not actually splitting things into standalone libraries, I sorta mentally divide everything in a project into ālibraryā-ish stuff and āinstanceā-ish stuff. āLibraryā stuff is the general utility stuff and āinstanceā stuff is all the individual objects, global singletons, and so on. And I pretty much always put the ālibraryā part in a separate source file from anything thatās calling it.
Thatās to make single file search easier, because even if Iām using an editor thatāll search the entire project for me, I donāt want to have to cycle through a half dozen callers before I land on the method I want.
It also fits how I debug, which usually involves having multiple editor windows openā¦one for the method thatās throwing an error, one for its caller, and one for whatever itās calling, for example.
I also tend to throw large static data structures into their own files, although if theyāre part of a fairly static block of code I might put it all in one file. So for example I have a poker hand evaluator thatās a little standalone object that contains a couple thousand lines of static tables but the logic is basically just doing table lookups and data type conversions, so it all lives in a single source file which basically hasnāt been touched since it was first written.
3 Likes