This might be a little much for one post. I apologize in advance if it is.
To keep using my invented word...
Keyboard_function is a ticker. Whatever keyboard_function normally does goes inside one. In reality, you usually end up breaking keyboard handling up too, but that's neither here nor there for the time being (but we'll get there if this conversation goes on much longer).
Your radar is a ticker.
your physics system is a ticker: add velocity to all objects with one, tell the objects they've collided by calling a.collides_with(b) and b.collides_with(a), etc.
Enemy AI is a ticker. When it ticks, it figures out what the enemy should be doing, typically (for the stuff being discussed here) setting the velocity on the enemy. Enemy AI is the first example of a ticker which may not always finish the tick, as pathfinding can be expensive. I normally put enemy AI in the enemy class and register it as a ticker--this allows different enemies to have different AI.
Here comes the key insight: none of these are "special". Each of these is a game object just like all others. What you do is register them in a list; we've covered that before. But if you make sure that all the objects in your game can access that list, you can suddenly have one-of-a-kind enemies and stuff. The main loop doesn't care what needs ticking, it just cares that it's got the tick method on the objects therein. So everything can inherit from the base class if you want, and everything can have its own little slice of time whether or not it's used. It's like being able to run bunches of really simple games instead of one big one: everything has its own main loop, it's just that they all start with a function declaration instead of a while statement. Since you're not using threads (which make learning this particular pattern look like cake), you can be assured that only one ticker is touching the world at a time--no need for typically complex concurrency stuff that gives basically all programmers headaches.
Instead of waiting, you use what is called a finite state machine. The idea is that you might be in one of various states right now, so you set a flag and use if statements. This is the equivalent to blocking without actually blocking. Your radar is the simplest example. It can be either on (in which case it is doing something) or off (in which case it is not). You've almost certainly built finite state machines already; whether or not you know the words, it's a super common game design pattern. To apply limiters and lag, you replace them with more counters, i.e. the gun cant' fire again for .3 seconds.
Global variables are bad. The particular pattern I like to use to deal with the fact that tickers need to know about each other and other stuff outside themselves is called dependency injection (I mention this so you can have a googlable term). If your radar needs to know about whatever object is responsible for holding the level map, it either gets a reference to it passed in via the constructor or looks it up on your game object--also passed in via the constructor. I personally prefer the latter. When I set something up like this, I usually put the main loop of the game inside of a game class and then hang things like the current level off of it. Tickers can then access important game state through that avenue.
To make two tickers representing important things know about each other, I suggest either the use of instance variables on your game object or the use of a dictionary (BGT might call this something else) mapping names of important things to tickers. The latter is probably a bit advanced for what you're doing, but you'll probably end up using something like it down the road (mapping things to unique ids like that is great for saving to disk and doing network stuff). But in truth, I find that tickers don't often talk to each other. They can, and there's nothing wrong with it-just, if you do this right, each ticker is completely responsible for exactly one concern, and there isn't that much mixing.
To make tickers know about important things like the level map being changed, I typically add more empty methods to the base class that act as events: level_changed, for example. And then you just call them all without caring if anything happens (which can be faster than most naive lookup schemes and avoids a lot of bugs--do not worry about performance).
You might try looking into XNA tutorials. I don't have specific ones as it's been like 6 years at this point. XNA is big on this particular pattern, aimed at new game programmers, and was pretty popular for a few years. It's also the earliest thing I can recall seeing this pattern in, and you can find some other useful stuff floating around that talks about saner ways to handle input (even if they don't seem so at first).
And finally, some motivation for you, as i know the proceeding is possibly like hitting your brain with a brick. If you want a game which is both complex in terms of game mechanics (though not necessarily in terms of coding, believe it or not) and also bug-free, you need this pattern. More complicated variations on this pattern power almost every online service you interact with on a daily basis. If you ever have or want to work with microcontrollers or robotics, you see things that are similar to what we're talking about here. I'd be willing to bet quite a lot that Swamp looks something like this internally. If you take this to the next level, you could be hired as a node.js or twisted programmer (both of which are frameworks that use a much more advanced version of this pattern and power huge chunks of the web). Every windows app eventually boils down to a message loop, which is this in essence, at least in most GUI framework internals. The list goes on, I'm sure.
You don't have to roll this out all at once. Start by doing it for your radar, and then see where it goes. Rearranging your entire idea of how games and other software is structured does not happen overnight.
My BlogTwitter: @ajhicks1992