Bloodhunt: Don't You Mess With RobotLegs news

Making a game as fast as you can often leads to some dirty programming tricks. Getting dirty in game development is not necessarily a problem, as long as your code base is small (with a few classes you can still see the bigger picture above the dirt). The problem comes when your dirty trickery becomes an obstacle to development, making each change or improvement a bit more difficult to perform. This snow ball effect forces you to maintain an increasing technological debt that you'll have to pay in the future (probably in the form of bugs, patches and a hellish maintenance). In other words, each dirty patch that saves you time now becomes a time bomb silently awaiting to detonate somewhere in the future.
This week I've realized that my dirty trickeries and helping tools, i.e. Flixel, have become an obstacle to development. This striking moment of realization hit me when I was implementing a ridiculously complicated operation to perform a super simple effect like a blinking selection glow.
So the time to pay my debt is now. I'm migrating Bloodhunt dirty code to a clean model-view-controller-service framework: RobotLegs. Instead of obscure mixtures of alchemy and programming, RobotLegs forces you to organize your code in the following crystal clear concepts: all game data is stored in models, all screens, graphics and visual representations become views of the game, the controller is formed by commands that execute actions upon your game models, executing services to provide functionality. Therefore, I have to spend a little time cleaning up the code mess. This cleaning process will not add new functionality or features to the game but will make each future change a lot easier. For instance, my static class containing the game texts will become a XML file which will allow a simple method for localization (adding new languages is as easy as translating the texts of the XML file).