I’ve done some more thinking about it, and I figured out why using the HTML5 streaming video components to send 3D graphics to web browsers won’t work: the pre-roll and network lag.  Let me ‘splain:

When you start viewing a video on the web – even a “live” stream – your video player will pre-load quite a bit of video before it starts playing.  The exact amount is very variable, but I would say generally speaking at least 10-15 seconds, and perhaps as much as 60 seconds. This is done so that if the Internet slows down for a bit, your video viewing experience is not interrupted.  This means that the video you’re watching was actually sent to you at least 10-15 seconds ago, and perhaps as much as a minute ago.  A one-minute lag does not make for a good user experience when you’re talking about a first-person-shooter style video game.

Additionally, when lag does occur and all the pre-roll is used up, yor player will pause automatically and wait for more data to become available.  Let’s say the lag is really bad and takes 2 minutes to sync back up again.  Now you’re watching video that was sent somewhere between two minutes and three minutes ago (when you add in the pre-roll period again), making the problem even worse.

A third problem is more mine than yours: rendering video is an expensive operation, even in the best of circumstances.  It takes a pretty beefy video card and quite a lot of CPU to do 30FPS for a moderately complicated scene.  Having that much hardware on my end to render video for players will be quite expensive, and I just don’t have the resources to pay for it all.

So, it seems that for now I’ll have to stick with 2D top-down graphics for the game, at least for the web client.  Perhaps I’ll make a 3D version at some point that works through Java, a browser plug-in or a native OS application.