A few multiplayer games I have seen that are in devolpment plan on using html get/put request to call php scripts. Those php scripts then preform the calculations, update the database and then transmit the server response back to the players. The programers say that this will save them bandwidth since all they are requesting is one php script with commandline values. A typical packet looks like: \get php.server.com/moverplayer.php?id=2581301?x=1?y=2?z=3?speed=5 The games being 3d, would this type of sever really be better than what most games currently use today?

I don''t think it really matters... By hitting the PHP script you also pass some bytes of info to the server program (a "website" in this case) and it calculates results, and sends them back. This would be the same as when you let the server program do this... In fact I think the PHP code might even be slower... PHP is not as fast as C++



KING CLAUDIUS Now, Hamlet, where''s Polonius?

HAMLET At supper.

KING CLAUDIUS At supper! where?

HAMLET Not where he eats, but where he is eaten

It''s a novel idea, but in reality I don''t think it''s very good. There could be no server-initiated communications, i.e. if a player moved near you, the only way you''d find out is when you poll the server the next time. That would make the server far more complicated than needs be. Also, PHP is an interpreted language, so it''s somewhat slower than a native language server would be. However, web servers are pretty highly optimized so maybe it wouldn''t be so bad as all that.

codeka.com - Just click it.

I think this idea is quite cool ! Of course it depends on the game type (quake won''t work ;-) ) but the advantages are obvious:
- seamless integration with web content
- fast development/prototyping
- easy debugging

anyone remember the telnet-based MUD''s ?