What seems to work best for me, though maybe not for anyone else <g>, is to keep "game" and "Blitz" categories separate (this is kinda what Red Ock/Mike said, but maybe more extreme). That is, when thinking about a game, I should be thinking in terms of game items (for example, if it's a boardgame then something like map, counters, and rules) and not in actual Blitz commands.
Once I've worked out in general, non-Blitz terms how the game will work, I create the game's objects and actions using Blitz commands. Then I create the game itself using only those objects and actions that I've made. For example, when I place a counter on the map, I don't think in terms of "DrawImage" directly, I use something like "Counter.Place(2,3)."
If I ever feel tempted to directly use a Blitz command to manipulate a game object or action, I know that I've failed to fully implement my game objects or actions. So I stop working on the game itself to dip into Blitz to make a game item to do what I need. Then I go back to creating the game itself without using Blitz commands directly.
This involves a bit more work than a more-direct approach, but I personally find it helpful to work as high-level as possible and as close to game-world terms as possible. It also seems to keep things simpler for me, since each "clump" of Blitz code only has to handle one object or action (and even I can manage that... usually <g>).
Once I've worked out in general, non-Blitz terms how the game will work, I create the game's objects and actions using Blitz commands. Then I create the game itself using only those objects and actions that I've made. For example, when I place a counter on the map, I don't think in terms of "DrawImage" directly, I use something like "Counter.Place(2,3)."
If I ever feel tempted to directly use a Blitz command to manipulate a game object or action, I know that I've failed to fully implement my game objects or actions. So I stop working on the game itself to dip into Blitz to make a game item to do what I need. Then I go back to creating the game itself without using Blitz commands directly.
This involves a bit more work than a more-direct approach, but I personally find it helpful to work as high-level as possible and as close to game-world terms as possible. It also seems to keep things simpler for me, since each "clump" of Blitz code only has to handle one object or action (and even I can manage that... usually <g>).