Sometimes the problem is that other workers get jealous if the programmers get too much leeway. It's that way with telecommuting, too - "How come he gets to work at home and I have to drive to the office? It's unfair!" - and the jealous ones complain a lot. That can be a headache.
And @Tim, whether or not playing Doom is unprofessional is really beside the point. Maybe in your company you couldn't deal with it for various reasons, but it's a matter of process and attitude more than adhering to enforcing "professionalism". (That's often often a euphemism used by poor-to-mediocre managers to try and hammer square pegs into round holes when it would be better (albeit more work) to get the most out of the square pegs in the first place.)
You have to decide what, as a manager, you're comfortable with managing and how much work you're willing to do to work with your people. If the game-playing programmer is hitting his schedule and QA milestones, then it's your job to decide whether it's more valuable to your company's business goals to spend time and energy to make your eccentric employees conform or to work around their eccentricities. But if he is doing the basic job you hired him to do, and his bottom-line work is good, why does it matter how he spends his day?
If, OTOH you hired him and are paying him by the hour rather than by the product he produces then how he spends his time is an issue. But my experience has been that the best programmers (that I have managed) will spend great hunks of time thinking about and planning what they're doing and then doing it rather than feeling that they have to be hitting keys to satisfy keystroke counters.
Having said that, if you're a service organization sending a programmer to a client site and the client is paying by the hour then as manager you need to (a) make sure the programmer understands this and agrees before you send him/her on site, (b) hire a different programmer (who may not be nearly as good) or (c) send a proxy onsite and keep the real programmer in the office.
I'm also a developer who has a not-very-dissimilar style of working - I need to think about things (which looks unproductive when measured by someone who doesn't understand programming), and sometimes I get ideas in the shower at 7:30 in the morning and need to work them through right then to see if they're viable or not. But try to explain to a manager who needs you on four back to back conference calls with product managers that you have had a critical insight and need to work at home for the next four hours so you don't have to interrupt your flow and lose your inspiration and you'll test your working relationship in a big way.
There's cookie-cutter programming which is amenable to an assembly-line management approach and there's creative programming which is not and can be difficult to manage if you're low on flexibility or have process-oriented management you have to report to.