It's not going to be reusable anyway. It's application code, by the time it's actually polished, featureful and useful to the end-user it's so tightly integrated and full of special cases that you have to consider it a one-off.
Again, as Blow mentions several times, this is a domain-dependent thing. If you are shipping line-of-business code that sits around for 30 years, yes, that kind of polish becomes important. But games don't (typically) have that lifespan. If you want to do an update 10 years later you can remake it with all new assets as well as new tech, and the exceptions to this tend to be on a completely different scale from indie games(MMOs...) So when "in the moment" of bringing the game together you optimize for broad, fast changes, which favors having a bit of lengthiness and redundancy within the source.
Here's an example from a game I'm working on now:
I have some UI code that makes rounded-rectangle frames. I thought, when I first made it, that I might want to customize the look a bit(roundedness, thickness, coloring, etc.) so I parameterized it. As it turns out, I used the same parameters everywhere. So the abstraction wasn't useful. But at the same time, I don't really have a great need to refactor it, because the problem it causes(dirty looking code) is so localized to the instances where I create the frames. It's still there and the customization is possible. If I need something different from a rounded-rect frame I'd be writing completely different code, so it just doesn't make a huge difference.
On the other hand, one thing that I got wrong and want to fix is an architecture problem. I went in with an architecture tuned around a single, serializable scene capable of defining complex entities. But I made a game with a lot of UI/editing screens and one gameplay screen with very simple game elements. So ideally I would have had something with a DSL for defining those rounded-rects and tweens and positioning efficiently, better ways to manage all the scene transitions, a system to iterate on UI quickly(e.g. load a file = restart scene), and a simpler model for the gameplay. As it is, it gets a bit hacky in a few places, and the overall "shape" of the code is likely to be discarded, but I will be able to reuse lots of the pieces if I do a sequel or similar type of game; they'll just be assembled in a different way.
Yes, it's important to make the code clear. Shipping is so much more important than code reusability though. When the lifetime is small, rewriting it to be more modular isn't quite as justifiable as in a long-term project where you actually have the time to get it right.
Again, as Blow mentions several times, this is a domain-dependent thing. If you are shipping line-of-business code that sits around for 30 years, yes, that kind of polish becomes important. But games don't (typically) have that lifespan. If you want to do an update 10 years later you can remake it with all new assets as well as new tech, and the exceptions to this tend to be on a completely different scale from indie games(MMOs...) So when "in the moment" of bringing the game together you optimize for broad, fast changes, which favors having a bit of lengthiness and redundancy within the source.
Here's an example from a game I'm working on now:
I have some UI code that makes rounded-rectangle frames. I thought, when I first made it, that I might want to customize the look a bit(roundedness, thickness, coloring, etc.) so I parameterized it. As it turns out, I used the same parameters everywhere. So the abstraction wasn't useful. But at the same time, I don't really have a great need to refactor it, because the problem it causes(dirty looking code) is so localized to the instances where I create the frames. It's still there and the customization is possible. If I need something different from a rounded-rect frame I'd be writing completely different code, so it just doesn't make a huge difference.
On the other hand, one thing that I got wrong and want to fix is an architecture problem. I went in with an architecture tuned around a single, serializable scene capable of defining complex entities. But I made a game with a lot of UI/editing screens and one gameplay screen with very simple game elements. So ideally I would have had something with a DSL for defining those rounded-rects and tweens and positioning efficiently, better ways to manage all the scene transitions, a system to iterate on UI quickly(e.g. load a file = restart scene), and a simpler model for the gameplay. As it is, it gets a bit hacky in a few places, and the overall "shape" of the code is likely to be discarded, but I will be able to reuse lots of the pieces if I do a sequel or similar type of game; they'll just be assembled in a different way.