I was wondering if it would be possible to develop a web-based version of bzflag - Flash, maybe? I guess one issue that would have to be resolved would be where to host the web version.
My reasoning for that is in thinking of how to play BZFlag on-the-go, and perhaps in some free time at my office work place (where we are firewalled). I can access some web pages, but I can't play BZFlag due to my firewall.
Let me know what you ladies and gentleman think, if you will - even if you do not think it is a good idea at all.
No, this isn't a good idea. First of all, you just can't do this properly. Flash doesn't have the necessary networking functions, it can only talk to web servers and then in XML. Java is too inefficient for a game like this, especially as a Java applet usually cannot access hardware 3D acceleration. One could use ActiveX but it is proprietary and Windows only. And anyway, this wouldn't solve any firewall problems - all this solutions execute on your machine and have accordingly the same restrictions as the normal BZFlag game. And nobody would download 4 MB on a web page just to play BZFlag "in the browser".
I think making the BZFlag connect to the server through HTTP on the standard HTTP port could help here. This would require the server to keep port 80 open in addition to the normal BZFlag port, but other than this it doesn't require much - HTTP is just like a normal TCP connection, only some lines of headers before the actual data.
You bring up some very good points. I can't code, otherwise I suppose that I could have come up with that. I had gotten the idea when I recalled playing a game or two online with other players across the web via my browser - a tank game being one (gosh, I can't remember where it was). The graphics were very basic.
On that note, do you think that it might be possible (even if the graphics option is only low) to have a web version if web page was on the host server? I am guessing that admins even through this type of connection would still be able to see the IP of those connecting and could still administrate the servers. I suppose that a centralized server could have a refreshing web page with links to participating servers (say the server that BZFlag looks up when looking for servers?).
Besides my firewall issue, I was thinking that it might be cool for people to be able to play BZFlag on public computers where BZFlag is not installed. At any rate, I do like the HTTP idea; that sounds good. Is this a good place to make that kind of a recommendation?
A "web based" bzflag would still need to contact the server. It would have the same firewall issues your native client has.
I've hacked bzflag to "play" through an HTTP proxy, but performance is so horrible, that I never added the feature to the game. No UDP traffic would get through, just tcp, so it actually can make lag for other players worse.
In short... If you can't play bzflag trough your firewall, that's just the way it is. Try to change your firewall. =(
Linux hackers may want to checkout a package called transconnect to experiment with the horrible proxied game play.
Thank you, Tim, for the information. The challenges to a web-based BZFlag are much more clear.
Do you think that perhaps HTTP might work if the graphics quality (for HTTP play) were limited to low or to a level that would permit decent game play?
Lastly, your post here to this thread is a true pleasure, Tim. Regardless, I can still play BZFlag at home. BZFlag is a great game. Thank you so very much for bringing it to us.
it's not graphics quality. it's latency. The graphics are actualy local, and would be up to the 3d engine, and would have nothing to do with HTTP.
HTTP is a very wordy format, and it is just not designed for fast realtime comunication. Web based games are usualy systems that work in high latency situations ( i.e turn based ). Not to mention that browsers and java are just plain slow. Your web based bzflag would add huge amounts of lag to it's users. Having them play against real users would be unfair to both partys. Unless you find a way to create a dedicated optimised stream between client and server, it's just going to suck. Even right now the current UDP based protocoll is proving to be unoptimal in most situations. Slaping it on top of yet another protocoll will just make it worse.
Ether add proxy support to the game ( still adds latency ) or just run servers on port 80 for those people who can run UDP.
Thank you, Jeff. That makes sense. One reason that I had been thinking of reduced graphics was from when I had dial-up. If I played with medium or high graphics quality, the lag was too high for reasonable game play; however, game play was acceptable at low. It's sort of like the difference between a GUI browser and a text browser such as Lynx; I would get much faster connections (and file downloads) over dial-up with Lynx.
Well, no HTTP or web based BZFlag is a disappointment. Thank you, though, for taking the time to explain why. I really appreciate it.
The "lag" you saw was due to low framerate. If the Framerate drops the game dosn't have enough cycles to send out data fast enough. It's not tied to your internet connection at all, but produces the same effects. On modern hardware graphic res dosn't affect the speed in any noticable way.
Your comparison to graphical and text based browsers does not fit here. Text is faster due to the fact that less data is sent down the line. In a game no graphical data is sent down the line as the graphics are all local. The same amount of data is sent to the client regarless of how the scene is drawn. The tank could be a box, or a 1000 polygon model, and the network data is still the same ( x, y, z pos, and a rotation..etc.. )
Log in to post a comment.