I’m pretty much the opposite to you in the updating-things department, which is mostly just down to my DNA. So I don’t think I can impart any lessons from my DNA
I’m trying to think of strategies from your position. You are prolific, forward-moving, and some of your code may be a bit higgledy-piggledy (cue Amanda saying ‘It’s ALL higgledy-piggledy!’). The higgledyness is a genuine factor, as the chances of fixes breaking things elsewhere increase when the code isn’t consistent.
To me, it sounds like understanding the code is the important context for you. If revisiting and re-understanding old code is going to be rare with you, the time to strike is when you do understand it – which is while making the game, having it tested, and in the honeymoon period of some comp afterwards.
I’m assuming most of the bug identification and feedback is happening during all this time, especially the comp period.
So if you can wield the discipline, I’d advise you to attend to those bugs and fixes in that comp to post-comp period. The game will be fresh in your mind, hopefully still exciting (due to people’s responses) and you’ll still understand the code.
If you let yourself slide out of this period, and especially into the starting of the next thing, without doing some fixing, sounds like your chances of doing so in the future are low to zero.
I’d take advantage of this window. If you can tick off a list of improvements on the game here, you’ll be able to say ‘I’ve made this a hell of a lot better.’ If you never revisit it after that and there are still some bugs, no biggie. That will be your now-improved version of moving on. You making this topic shows that you don’t want your version of moving on each time to be… the game was never improved and never will be.
But you may need to file your previous games in the moved on box for now. I would try improving either your most recent one now, if you still have it in mind, or wait 'til after the next one.
Having written this post, I realise a couple of things.
- That ‘right after I made it’ period is indeed where I fix most of the bugs and make most of the improvements, so I actually haven’t suggested anything too radical there
- Even though I’m a great improver, I’m aware that when a list of improvements required is building, I drag my feet a bit (like, I write something new instead of attend to it, for a day or three). But my experience in most cases is that the fixing goes super quick. I’m always amazed afterwards how quickly or easily the whole fix list went, and it does give me a little upper. You’d think my brain would have grokked this by now, but it hasn’t, quite.