The control

When roguelike project gets past a certain limit in size it can become difficult to understand the project as whole. What I have noticed is that in some point I lose control of the project more or less. Relationships between different parts of the source code can become hard to follow and you can start to build structures that closely (or strictly) copy some of behaviours in other place. In pure game design point of view it's also difficult to track relationships between features, especially if they are not yet defined in a plan.

Modular design is a handy tool to reduce complex relationships, but it can only solve some of the issues and on top of that it also requires planning to work nicely. Sometimes modular design can become unwieldy and complex itself. But it's something you can do to reduce refactoring, because usually independent modules rarely require refactoring at all. They can also be reused in other projects.

I've always used open source or free editors to write source code, but they are missing better tools to control the source code. Something like graphical browsers for relationships between classes etc. Or simply a graphical representation of classes to see how bloated they are. The percentage of public and private exposure. Things like that.

Of course you could view a graphical output of classes by drawing them on paper, but it feels a bit outdated method and backwards when you already have programmed the class hierarchy.

Sometimes it could be something really simple like setting the color of the name of class or file in the project browser. That way you could for example use green color to mark files that are ready and red color to set files that still require work. In similar way there could be a list for unfinished functions to recall. Simple tools that totally are missing in VC Express and Code::Blocks, two of most commonly used IDEs.