I cannot think about work anymore right now, so instead I'm thinking about game programming. And more specifically how I feel like I very rarely have difficulty with bugs, at least relative to the impression I get from other devs

Which is not because i'm Smart, im not bragging /

But I think it's because I've developed a bit of an intuition for things that are going to bite me later.

I even think it's more or less two relatively simple rules I stick to that make my life easier. And I can pinpoint the big struggles I've had when I didn't follow them

And these are:

1) Minimize the data you store across frames
2) By default visualize all the state you can

So for Rule 1, it means basically don't cache anything if you don't have to. If you can evaluate something per frame, don't store it across frames instead. It's "less efficient" but most of the time it doesn't actually matter at all.

It also covers things you wouldn't think of as caching. For example if I need to animate something - it's very rare that I'll modify a value each frame. What I do instead is store a timestamp (relative to a certain pausable clock sometimes) and then animate based on elapsed time.

It also sometimes means that instead of storing immediate mutable state for something, you store an immutable base state, and a list of modifications. This avoids a situation where you're going to need to reset it later (which you might forget, or a weird code path might skip).

Anyway, all of this means I very rarely have glitchy "impossible" states for things, because the state is mostly static and only modified at key points in the code flow.

It also means things are typically easy to debug. If something looks weird, it's almost certainly because of some calculation *this frame* instead of the last ten seconds of bizarre mutations.

Anyway, Rule 2, visualizing by default. The hardest bugs to fix are the ones where you can see the outcome is wrong, but you can't see anything leading up to it.

So for a forced example: say you press the jump button and the character doesn't move...

Is it because they're not on the ground? Is it because the button hasn't registered as being pressed? They're out of jumps? The game thinks a cutscene is playing? The character is in a stunned state? Something *other* than the character is receiving the jump command? etc?

In this case, it's probably not that hard to narrow down. But it'd be even easier if:

- the player's grounded state was part of their animation
- you show button presses in a debug UI
- the player changes color when they're out of jumps

- cutscenes letterbox the screen
- being stunned shows up as a little effect over your head
- the currently controlled entity is marked in a debug UI

So every possibility is already visible at a glance, before you had to even start debugging.

And sure, some of this stuff is debug-mode-only stuff. Like showing button presses, or labelling the character.

But a lot of it is also just... good UX? So there's a nice side benefit. If your game is readable enough for you to debug easily, it's probably also readable enough to be fun for players.

So those are 2 things, that i think are very good when programming

thank u