Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^2: What's a good alternative to browser-webapp-webserver for remote apps?

by rudder (Scribe)
on Mar 29, 2008 at 23:41 UTC ( #677267=note: print w/replies, xml ) Need Help??


in reply to Re: What's a good alternative to browser-webapp-webserver for remote apps?
in thread What's a good alternative to browser-webapp-webserver for remote apps?

I've been investigating how multiplayer online games work. What I've found is that many simple games are flash based. So, to play them, you've got a flash app running in your browser, communicating with a web server presumably via http sending something like xml back and forth. This seems inefficient.

What I'm curious about is more sophisticated games -- desktop games, with multiple players, communicating with a central game server.

Perhaps the standard way to do that is to use http with mod_perl (or FastCGI)... I don't know. How is this sort of thing usually handled these days?

  • Comment on Re^2: What's a good alternative to browser-webapp-webserver for remote apps?

Replies are listed 'Best First'.
Re^3: What's a good alternative to browser-webapp-webserver for remote apps?
by dragonchild (Archbishop) on Mar 30, 2008 at 00:21 UTC
    In general, they follow the old client-server model because of the need to have a custom protocol for updating the graphical elements. This generally entails some sort of half-model-plus-protocol that replicates most of the model information on the client. This allows the server to send very little information to the client for a large effect on the client. Having written one of these in AJAX, this takes either
    • A large amount of duplication of effort across two languages
    • Two completely different applications that both speak the same protocol
    Neither of these is simple to maintain. This is why those MMORPGs suck, have few features, or have a monthly cost.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      This is why those MMORPGs suck, have few features, or have a monthly cost.

      Or all of the above :)


      I'm a peripheral visionary... I can see into the future, but just way off to the side.

      This generally entails some sort of half-model-plus-protocol that replicates most of the model information on the client.

      Ok. So, I'm guessing that means maybe something like:

      player:position_x=120;position_y=83;orientation=52.2 ...

      and so on for other objects or events in the game (though probably in some more condensed format).

      Having written one of these in AJAX, ...

      Just curious: what format did you choose for sending your data back and forth? XML? Plain text? Something else?

        Definitely in some more condensed format, though that condensing can often be provided by mod_deflate / mod_gzip.

        We used JSON which is a proper subset of YAML. Very nice format to work with when chatting with Javascript. It also compresses very well. :-)


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re^3: What's a good alternative to browser-webapp-webserver for remote apps?
by perrin (Chancellor) on Mar 30, 2008 at 02:41 UTC
    Network protocols for actions games are going to be heavily affected by the demands of the game environment in a way that makes them poor choices for other applications. For example, action games are very concerned about latency and about minimizing network traffic in general. That will lead to very compact binary protocols that are difficult to write and torture to debug.

    For other network applications -- a shared spreadsheet, a turn-based strategy game, etc. -- those issues are less of a concern, so an easy and widely-used approach like XML over HTTP makes a lot of sense.

    Although I've never written one, I'd guess that modern MMORPGs are commonly written as multi-threaded daemons in a low-level language like C++ with some kind of higher level "scripting" language built in for implementing most of the game functionality. This is very similar to a mod_perl or FastCGI setup where you have a daemon (the web server) handling all of the tricky network stuff and you build the high-level functionality in perl.

    If you specifically want to know about certain games, I bet you can find details about their implementation and protocols with a little Googling. The developers usually give interviews with at least general information.

      For example, action games are very concerned about latency and about minimizing network traffic in general. That will lead to very compact binary protocols that are difficult to write and torture to debug.

      Ah. Ok. You're ringing a bell for me. I bet these sorts of games would use UDP (rather than TCP) also. So for these, you're looking at using Socket or IO::Socket.

      Also, your observation about modern MMORPG's with scripting being similar to apache/mod_perl/perl sounds right on. Thanks.

Re^3: What's a good alternative to browser-webapp-webserver for remote apps?
by ruzam (Curate) on Mar 30, 2008 at 02:55 UTC
    The reason they're flash based and run in a browser is because that way you don't have to develop a client side application. Anyone, from anywhere, with any kind of flash compatible browser can play. It may be inefficient, but it's universal.

    For the more sophisticated games, you need to create a client application. Users have to trust you enough to download and run your client software. Given what's on the net these days, that can be a hard sell (who's to say your client isn't another spyware app?). Then you have to support the client, running on who knows what hardware, with who knows what version of operating system, etc, etc. Some users will be excluded from your game by way of what computer they use (Mac, Windows, Linux, other). All in all alot of extra work that takes you away from your real goal of making the best darn game server you can.

    Communicating over the net doesn't have to be http. You can use any port and what ever communication scheme you want over a bog standard TCP connection. The client doesn't have to be a browser, the server doesn't have to be a web server, and neither of them have to follow a valid HTTP protocal. If you're not running the client from a browser, then there's no reason to use HTTP, but it does have one particular advantage in that it usually won't be blocked by firewalls (the port that is).

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://677267]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (10)
As of 2017-12-13 17:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (371 votes). Check out past polls.

    Notices?