I want to make a game with one master server that takes care of things like determining what player attacked what mob or player, and pretty much all other authoritive things except for player positioning. It would also handle database interaction. I want this to be done in PHP.

Along with this, I want to have player hosted world servers that pretty much just handle the physics.


My main question is, how capable is PHP? How many players could a PHP server handle?


Also, how could I prevent players from flying if I get positions from the player servers? And how could I control their speed when there'd be different speed situations... such as mounts and vehicles.

It depends on what your requirements are. Is this a fast paced action game, a slow turn based game or something in between? Do you expect lots of players to cluster together or will they be mostly separated? PHP isn't fantastically quick, but if your game is I/O bound this wouldn't matter.

Also, how could I prevent players from flying if I get positions from the player servers? And how could I control their speed when there'd be different speed situations... such as mounts and vehicles.
[/quote]
The only way is to do these checks on your server. You could do them retroactively, maybe when a player is trying to move between servers. The "client" server could upload a path history to the master server, which could run through the path looking for collision violations and places where the player moves faster than their current mode of transport allows.

I'm thinking I'd limit the individual servers to about 100 players, so that's the max that could be interacting at any one time. It's going to be an action type game.

I don't think I can have set pathing because the environments are going to be dynamic. I guess I could let players get away with flying and a few other minuscule hacks on their own servers, or maybe I'll check and ban them or something. The main thing I don't want happening is players being invincible or hitting for a million damage and stuff.


I might just write the server in c++ because I was thinking I could use some cheap shared hosting with a php server but after checking it out, I don't think anyone will let me open sockets besides dedicated hosting.


I guess I'll have to run the server from home or something until I can afford dedicated hosting.

[quote name='Butabee' timestamp='1306697317' post='4817212']
My main question is, how capable is PHP? How many players could a PHP server handle?

75 million.
[/quote]

That's not all on one machine though right? From what I understand that's load balanced between multiple machines.

My main question is, how capable is PHP? How many players could a PHP server handle?

How many requests per second do the players make, and how much is needed from your system per request? PHP is just a language. Your question is no different from the question "how many players could an assembly server handle" or "how many players could a C++ server handle" or "how many players could a JavaScript server handle."

If your game is actually interactive, with physics data being sent to different players, PHP is *not* the technology you want to use, though. Even if you can live with TCP for the state stream (and, if it's an interactive physics game, you probably can't), you cannot live with the overhead of forking one copy of the environment per request (PHP garbage collection pretty much depends on this), nor the overhead in trying to get the data you need to send to each player, into each player's return value. This is pretty much the reason why persistent servers with non-transaction protocols exist.

[quote name='Butabee' timestamp='1306697317' post='4817212']
My main question is, how capable is PHP? How many players could a PHP server handle?

How many requests per second do the players make, and how much is needed from your system per request? PHP is just a language. Your question is no different from the question "how many players could an assembly server handle" or "how many players could a C++ server handle" or "how many players could a JavaScript server handle."

If your game is actually interactive, with physics data being sent to different players, PHP is *not* the technology you want to use, though. Even if you can live with TCP for the state stream (and, if it's an interactive physics game, you probably can't), you cannot live with the overhead of forking one copy of the environment per request (PHP garbage collection pretty much depends on this), nor the overhead in trying to get the data you need to send to each player, into each player's return value. This is pretty much the reason why persistent servers with non-transaction protocols exist.
[/quote]

I wouldn't be doing any environment or physics on the master server, but maybe some line box collision tests for attacks. It would pretty much relay player/NPC positions, and do the attack tests and interact with a database.

But anyways, I think I'm just gonna use c++.

I don't feel like making a new protocol so I'll just use eNet

But anyways, I think I'm just gonna use c++.

I don't feel like making a new protocol so I'll just use eNet

Sounds like what most games end up doing :-)

If you want a productive language suited to writing online servers, you might also want to check out Node.js/JavaScript, or OTP/Erlang, or Twisted/Python.

Actually, how do you guys think unity would work for this project?

I think they support a master server, but I'm not sure exactly what can be done on it.


EDIT - nevermind, looks like their "master server" is nothing but a matchmaking server.