A few ideas:
1. Try not putting any wmode parameter on there...
I personally consider wmode to be quite buggy and I'm trying to force myself to
figure out how not to use it whenever I can. It would appear from your page
design that the wmode for the game isn't that important, so this is just
possible thing you could try. I doubt this is the cause, but I've seen
much stranger issues resolved by removing wmode, so, worth a shot.
2 Try swfobject's static publishing instead of
dynamic publishing.
3 (DISCLAIMER: this suggestion is not
SWFObject related, but just general HTML/Javascript authoring, which
is off topic for this list so we probably can't help too much with nitty
gritty details, and your mileage may vary). In your page's
HTML/Javascript, if you set up event handlers for keypress/keydown/keyup for the
window/document, and you trap for the arrow keys, and you cancel the event
handler bubbling and event response cycle, you should be able to shut down the
window scrolling with arrow keys. This would leave the flash as the
only asset who would respond positively to such key events.
Downside is that it shuts it off for the whole
page, not just when the user is playing and needs game control. So, you
could have some kind of Javascript flag (true/false variable) that either
applied these key filtering rules only when the flash object has the focus (you
can set an onfocus/onblur event handlers directly on the swf's object itself via
javascript -- see swfobject.getObjectById), or even more robust, have the game
swf itself make a call out to the container javascript (fscommand,
ExternalInterface, etc) and control the value of this variable dynamically as
the game progresses, only shutting off the key event filtering while an actual
level is being played and restoring it when not, etc.
Obviously #3 is more complicated and less
desirable.
I'd try to avoid this solution if
possible, but it is likely doable if nothing else works.
--Kyle