Bob Nystrom wrote a series of articles at http://gameprogrammingpatterns.com/ about some ways to structure code specifically in games. I found the site useful myself, so thought I should share it here. He recently released it as a book, but you can still read everything for free on the site if you scroll down a bit. :)

I remember reading these articles last year. Around that time I got inspired to make a game. It made so much sense then to use these design patterns in the game, thinking it would hugely simplify things down the line. But what I actually ended up doing was trying to create a big framework, locking everything down before I even really knew what problems I was trying to solve. Then there ended up being so much useless friction when I was trying to add actual features to the game that I just gave up.

I don't know if design patterns are to blame here or not. Maybe if I had persisted I would have actually ended up with a nice clean codebase. Or maybe design patterns like these are only useful for much larger projects, and should only be added when they're really needed. I don't really have enough experience to know that yet. But at the start of a project, the problems you're trying to solve are usually very clear and easy to wrap your head around, so there's no use for abstracting anything in such a way.

That kind of ties into what Casey has been saying in the videos this week. Too much design up front can just get in the way. Start off solving individual problems, then pull them out into reusable bits once they're working.

That also gives you some built in testing since it is working before you 'refactor' you have a clear target for what it should be doing after.

That's one of the things I'm liking so much about Handmade Hero so far, it's teaching me to solve problems step by step without adding any unnecessary complexity.