'I Am Prey' Source Now PUBLIC

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?

Check out the source code on my GitHub here!


Looking forward to finding time to check this out!


Was that 3 months full time? Impressive regardless! I just attempted a two week surge and it was quite the endeavour!


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! :grin:


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.


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;
        "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.


Omg I’m not crazy or alone! :grin: :joy:

I…did not know that was possible! That’s super cool!!


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!


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.


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…


I also never thought about the blank modify followed by +, but I’ve never needed it. Pretty slick…


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.