During the latest developments I had some problems to resolve that arose also, among other things, thanks to the growing complexity of the project. In particular some of them were:
- Offset of lights when linked to objects,
- Offset of animations when different frames are of different size,
- Growing bloat of the offset management code,
- Input management among the various widgets.
Management of complexity is one of the big difficulty with large projects. Over time, the Technical Debt accrues and becomes a prominent cause of delays and problems. There usually arrives a point where it is more convenient to rewrite than to maintain code. Fortunately there are techniques to address this problem and one of them is Refactoring.
Often Refactoring is seen with suspect, if nothing else because some consider it an anti-pattern of “if it ain’t broke don’t fix it”, but usually simply because it seems a waste of time. Since this is an Indie project, however, we have the huge advantage that we can take any step necessary to improve our product without having too much to compromise (and we technical guys have a lot to compromise in our day jobs to “get things done”… funnily enough this usually mean saving a bit of work today and waste orders of magnitude more tomorrow, or the day after if you are lucky).
While I was at it I also could not resist to rewrite the drawing logic of the WorldView, implementing a true Scene Graph system. Finally I decided to change the Input management from a polling system to an event driven one, exploiting the events handling features of C# and SFML.NET.
This was a bit risky: it is too easy to fall to the line of thinking that by rewriting this or that you could have a better product. Then, rewrite after rewrite you end up with lot of prototypes but no finished works. I believe however that this time it was necessary and it actually would make my job easier later on, when the code base will be even larger than it is today.
Have you had any similar experiences?
Thanks for reading.