What I've learned from the years I write code now is that it dosen't always depend on comments because comments don't make a good code base. Thinking about what should be achieved with the code base before writing the first line is much more important because I ended up refactoring a projects logical structure in the past more times I refactored code from changing content. This is why I splitted large projects into a more modular structure where I have a core code base that is modular extended by functionality of logical different topics.

In C++, this is quite simple by splitting the project into standalone projects and linking them together as static library while you havent this kind of convinience in C#, you can split everything up into several libraries to include into your final application.

My development tools for the game engine written in C# stay all in the same directory but have there own subdirectory. Anything is build into the root directory (Tools). I then have a core library that contains certain subset of C# code that any other of my tools shares partially. This way I have the same code base for all my tools.

Using my dev tools leaded to having a shell application that is dynamically loading my tools into one single program during runtime. It is capable to do all the build setup, remote attach to my game engine and even manages the code base by managing the modular parts in packages. I took this from NPM here but a little more simplified enabling my development process to dynamically drag in/out code packages/ modules of my current project depending on the requirements I currently have in this project.

If you are working in Unity, you are something bound to the engine (I took Unity in here because you tagged just C#) so its project structure and building pipeline. But managing your modular code in several subdirectories should work here too and you are also able to declare code as your core or main module.

Second, using namespaces. I know that this is a topic to discuss about because half the people tend to not use them while the other half overcomplicates namespaces. Namespaces are a great feature to logically split up your code into functional sections. This means that IO classes should live in there own namespace, encryption classes should live in there own namespace and so on.

Third and least, keep it simple and be as lazy as possible.Simple class names, simple but meaningfull function and variable names make life easier. Using consts for constant values makes it easier to change them in certain code base and most of the time you just need static functions (from my experience) so making a class for everything is pointless. With being lazy I mean that a lazy coder wont copy/paste the same code, do repetitive stuff by hand (just like filling out a table of key codes) using some kind of quick n dirty tool to do the work and writes as less comments as possible except for those that are meaningfull too

These are some of my experiences I made, someone will have other experiences made and at the end you have to choose what fits best to you

Hey Zuhane.

I recognize your effort, 10 games is a certainly an accomplishment, no matter the size of the games in question.

I'm sure that throughout that endeavor, your experience in programming has grown. However, our experience grows in many ways, and programming, overall, is a big beast to tackle. So, like always, there may be areas in which we need to improve that we haven't been paying much attention to.

I see 2 possible problems here:

1) A classic problem of tightly coupled code. What this means is that your method clearly forces apply several changes in your codebase whenever you need to apply a small change somewhere. This is a problem that gets more and more noticeable, the larger the size of your code base, and is usually solved through programming patterns, software architecture, and similar software engineering solutions.

However, you mention you've done a lot of research into programming patterns, which either means you're lacking in your program architecture, or...

2) Perhaps you're attempting to make projects that are simply too big for one single person, and need to consider bringing additional programming brawn. You don't mention whether you're alone or not, so I don't know if this even applies.

I hope any of these alternatives can help you in your problem :)

This is a massive topic, and books have been written on the subject, and something that all of us manage better in some projects than others.

One thing that is common I think, is the tendency that the bigger and more complex a program, the more difficult it is to reason about and maintain. Techniques that work fine for small games often don't scale. The priorities in a large scale project can be different, and things like modularity and simplicity become more and more important.

The general solution to manage this complexity is usually to try and break down parts of the system into smaller, simpler modules. If you can force your modules to only communicate over a simple interface to each other, you can turn a task of making one massive program into a task of making, say, 10 smaller programs, each of which is easier to follow and debug.

This idea was part of the inspiration for object orientated programming, but the idea can scale above the level of individual classes. In fact, I would say that worrying about the details of comments or functions is too low level, there is a big danger that you won't see the forest for the trees. Try to think very high level and enforce that abstraction.

An example of this in practice working well is a plugin architecture used in many successful apps. It isolates a system into a host app providing some services, and a selection of smaller programs which use those and communicate only over a simple interface.

The other technique which becomes more and more useful is to split your work into code that is specific to a project, and library code which you will be able to reuse many times. Often you will implement something several times in different projects, get a feel for it, then decide it is time to make a generic version you can reuse, perhaps with templates (if you use c++). With a large library it makes the task of writing specific project code much less daunting, more concise, and you (hopefully) get to fix the bugs once in the library code instead of debugging the same thing over and over.

The truth is, large projects with several people are easier to manage as a hierarchy than small to medium sized projects with a single person. For perspective, Imagine 7 people completing single individual tasks, now imagine one person failing at all 7 tasks. You need to go easy on yourself and realize that you're wearing all of the hats. You're the one having to design, code, document, refactor, test, etc. So, don't feel as if it's a 'you' problem, and that you can't maintain structure, it's inherent for everyone except highly experienced solo developers.

Clearly define the scope of the project, this step is probably the most important. Use programs like DIA, or VISIO or even mindmeister.com to design the structure of all of your namespaces, classes, methods, and variables while keeping in mind future proofing code interdependence, especially if you're using middleware. This should be a working diagram that the game reflects, not a diagram that reflects the game. The difference being that the diagram is the first stop for any design decisions, someone should be able to open this diagram and build every piece of the game without ever speaking to you. Essentially this will be your design document, the holy bible for your creation.

I believe that if you stay disciplined enough to hold the design document at a higher priority than the actual game, you will alleviate the majority of your issues.

The only other advice I can give you is to create a vertical slice while you implement the design document before you start building the full project, use it as a evolutionary prototype to iron out potential conflicts. This is a good place to start building any necessary tools to help automate building the full scale game.