Game devs usually forgo a lot of the software engineering principles for the sake of quicker prototyping and time to market. However, it is also those same principles that make it possible to manage huge code base.

For example, following the Open-Closed principle, would help you avoiding taking more time to add functionality to a certain aspect of your game by not having unneeded coupling to other parts of the code. Similarly, different principles, patterns, and paradigms avoid different code smells/problems early on before they become too tangled.

Suggested readings:

1. Clean Code.

2. The Game Programming Gems series

3. The Gang of Four or some good design patterns book.

There's always UML if you want to diagram things super formally. Sounds like you are knee deep in complexity from pursuing a modular approach. I would say code that won't be reused outside of the project doesn't need to be overly designed. As a general rule, I don't even design very hard I just jump in and code, then refactor into a design I like that helps me not repeat code everywhere. For example, I have a project that includes a game server, login server, and client. I have code that I refactored into a module that I can use across all three projects. I did this for udp communication, encryption and decryption, and a few other things. Other code I have no desire to use across projects and so I worry much less about its design. It is partitioned into functions/objects that minimize repeating of code. And that's all I do, my project spirals outwards, I refactor, add feature, etc. Old features are in old files I don't have to touch very often. The biggest way to not touch old code is to truly 100% finish a feature before moving on to other features, taking into account everything you can. This is how I am tackling the complexity of my MMO project. I will not add new features until I am 100% done with features that come before it. It has helped me flesh out the design of my data very well. I need a 100% decided on data structure to represent players and accounts, etc. As I said finishing features rigorously helps to prevent from touching old code, unless something about your design is the culprit. My simple designs do not have rippling effects from changes, and all I did was not repeat code. Just divided it up with an eye to not repeat code and to provide a good interface. I already have 3 or 4 classes shared across projects I haven't changed a bit. If you can manage to write code abstract enough to work across projects, it seems you don't have to work on it often.... there's that lol. The code in those files does what it's supposed to do and there's no changing requirements on my end... maybe it's just a miracle lol.

On 5/14/2018 at 8:47 PM, zuhane said:

the code becomes more and more intertwined and interdependent

You have to use a decomposition to ommit it. Just devide a whole tasks to tiny separate subtasks, each of wich solve a problem of its competence by universal way. It allow to ommit remaking of similar mechanics and eliminate unnesessary dependences and  then construct complexive mechanics from its simple bricks. Open-Close is one of principles that help to make decomposition proper. Gang of Fours also have lot of very usefull concepts, but of course described not all possible tricks into its area. But general concept of any of its techniques - is to analize fields for dependences and similarities and determine zones of responsebilities for components and interfaces of interoperation and data interchange before develop a code. It allow to minimize or ever complete avoid refactoring, becouse minimize components dependeces,and also significantly reduce code size .