At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga.
Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus.
Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat.
so my main.c will consist solely of #include's, #define's, and #pragma's and other weird directives (possible macros, etc)... and I will have an my_algorithms.c, a my_data.c (which will #include some .txt files itself), and my_game.c which will be the game engine.
Or is this the WRONG way to build a large program? :(
Not the answer you are looking for? Search for more explanations.
While it is allowed to include the .c files in a #include statement, it is considered bad practice. It can be useful for certain performance related code, it can become make maintenance of the code difficult in the long run.
Also this can cause builds to fail because many environements assume that each .c file will create one object file. This can lead to you having problems linking.
It's legal but has all kinds of problems. For example, static variables or functions in one of the source files (statics are supposed to be known only in the scope of the file that they're declard in) are sudddenly known throughout your entire program. There are other examples of why this is bad.
It'll also lead to enormous build times. Change one thing in one of the files, the preprocessor will include them all into one big file and you're essentially always doing a full rebuilt.
So long story short, yes - this is absolutely the wrong way. :P