Interesting. Earlier I've made a few small game prototypes, nothing that can compare to a real, full blown game, but it's where I'd like to go someday and I can

Interesting. Earlier I've made a few small game prototypes, nothing that can compare to a real, full blown game, but it's where I'd like to go someday and I can totally agree with most of the points. However "OOP rules" is a bit dual edged for me. When I started out with prototyping these games I tried really hard to do it "the correct way" with loads of abstractions and with proper encapsulation and what not. Sure parts got good but I a made a lot of bloat along the way and now I could have made it a lot simpler (and better). Maybe it's because I've been spending time with Haskell and lisp (functional lisp that is) and now I'd like to "go back" to a more functional approach. Maybe it's because it's just a personal growth as a programmer though? I might agree with the step by step approach, although I personally think it's funner (and thus more educational) to just dive in head first and make shit happen. I don't think I've ever learned as much as when I sat down and decided that yes I would finally make a working game and just jumped in head first. Break things - it's the way we (at least how I) learn. Which brings me to #5: "Don’t just jump at any problem and start writing code." Well that's a little how I do things. Maybe I don't even know exactly what the problem is before a few attempts? How would you for example solve a path finding problem in a modern RTS? A bit of forethought is vital of course, but can you really think of all the subtle problems that will come up? Or even all the big ones? I think iterate early and often is the key to game making, and it's a bit similar with problemsolving. But of course that's also what he's getting at later with "Write some basic functionality and then expand it." It's just that I think when I'm coding, not before. Now after I wrote this I realize I agree with almost everything he said but with minor differences.