Rumination on design and global variables

I had an interesting observation the other night. Switching back and forth between Robo-Ninja and Atari Anguna makes me much more aware of the differences in how I write code.

For example, when writing code for enemies in both games, I often need to know about various pieces of state that live outside the enemy -- such as the position of the player. (But not limited to the state of the player, which is what makes this tricky). In a game designed with a modern language and architecture, you have to make a lot of decisions about how you both provide and limit access to the state that the enemy would need. How do you expose certain state to the enemy, without giving it access to all sorts of things it shouldn't have access to?  There are lots of solutions to that problem, but it's a big part of thinking through the design of a system. (Tangent: I find this to be tricky in hobby-style video games, because I'm always dreaming up new enemies and mechanics that require access to things I hadn't planned on. I then sometimes get in a hurry and provide access in the easiest way possible, instead of taking the time to rethink what might be the best design for the future)

For Atari Anguna, on the other hand, everything is fair game. 6502 assembly by default makes all your variables global. In theory you could probably use some discipline to localize variable use, but you really don't have processor time to waste using any sort of accessor mechanisms anyway. Practically, everything has access to everything else.  With these constraints, many of the rules of good design get tossed out the window by necessity.  Which is strangely fun and freeing. An enemy needs to know the player's state? Just read it directly.  Who cares about loose coupling, orthogonality, and all that other stuff?  It feels dirty (and would be a disaster in a larger, more complex program), but for something small and compact like this, just adds to the fun.