but how t f do you do it beforehand
When I do systems design, if I go straight-ahead, I tend to throw in a lot of dirty code without comments that becomes extremely hard to manage. It's therefore best if I know what I want to achieve and design the rules for the system first (with proper documentation!) so that future system updates are easier to manage.
I start by thinking about everything in the game as part of a class hierarchy (not worrying about implementation, just about who is a parent and who is a child via their similarities/differences); I'll also make notes about things that can be instanced rather than requiring a whole new class.
Once I'm happy with the layout, I'll then write down implementation notes for each class that include stuff like data they need to track (variables), things they need to do (methods), things they need to react to (events) and so on. My goal is to try and get a clean network that's modular.
I'll then take the notes and build a full documentation for the system. It will definitely change after implementation, but it helps me stay focused when writing code; it's almost like a programming homework exercise you get in university, since I've written down what I need to achieve, some rules about how it works, and what the end result should be. It's also great since I have more energy at the beginning of projects, and writing documentation can be a slow and painful process at times.
Once I'm happy with the plan, I'll start laying out the roads. Things will absolutely get switched around, break or require solutions I didn't have access to before, but it's always handy to have something to stick back to.
