Next time maybe spend more time on the design.
That's not always enough. It's quite rare that you know exactly what you're going to build when you set out to build a game. You might start out trying to build one thing, but find that it just isn't fun, so the requirements change the game into something else. Or the design just isn't workable because you didn't think of something, or the way you designed a particular component puts unnecessary restrictions on how other features of the game can access that component. Or maybe you have to redesign something because you didn't foresee where the performance bottlenecks would actually be, and end up putting in a whole bunch of complicated hacks to keep the program in your memory or speed requirements.
In any case, the longer you work on a program, the more complicated and unwieldy it is likely to get. This holds true regardless of how disciplined you are and this is why refactoring is important. In my view, refactoring (and knowing when and how to do it) is an important part of being a disciplined programmer.
I might be stubborn, but any project would benefit from having some sort of design thought out before running of to code. At least that's my opinion, unless it's just experimenting around a bit.
Oh, many or most projects DO have some sort of design thought out before coding starts, even if only at a high level. But having a design thought out before you code is not in the general case going to prevent situations where refactoring is beneficial, which is what you seemed to be implying.
In my view, it's better to prototype a design to work out the kinks before you put it into production. Prototypes not only serve as working demonstrations of your concept, but they also serve as iterations in designing the implementation.
Of course it doesn't have to 100% in detail and can change/ adapt to new insights.
You mean through... refactoring?