I was planning on communicating between my game servers and database(user/persistent data) through password protected php scripts.

Would this be a preferred way to do it?

What's to stop someone from intercepting (or guessing) your password and then taking over the system?

Isn't that the case for every password protected system?

How would you suggest I communicate between the game server and database on different systems? The php scripts and database would be on the same system.

I'm confused. Are you asking for information about talking to a database from PHP on the same box, or are you talking about communicating between a game server and a database on separate boxes? Those are very different questions.

Isn't that the case for every password protected system?

How would you suggest I communicate between the game server and database on different systems? The php scripts and database would be on the same system.

Every distributed application on the internet ends up looking something like this:

- Application Client
- Application Server
- Data Store

The game client receives data from the game server, and displays to the user. It also receives commands from the user, and enters them into the game server.
The game server receives commands from game clients, verifies the commands against game rules, and then updates the data store and sends new information to all game clients.
The data store stores data for later retrieval :-)

There really isn't much different, at this level, between a web site that sells hats, and a game. I can only add a hat to my shopping cart if it's a valid product ID that is in stock. I can only check out if I provide a valid credit card number and the shopping cart is not empty. Etc.

What differs between online games and online hat stores are mostly the value of the data, the rate at which the data updates, the complexity of the business rules, and the complexity of the data being exchanged.

So, in your online game, the application server could be a web server running PHP, assuming the rate of requests is reasonable for your game and server set-up. (Hint: if it's a real-time game, it probably won't be). The PHP page can talk to a database just like any other PHP page, as long as the data rate update isn't too much for your database server (Hint: if it's an action game, it will be too much). The client just connects, authenticates using a user/password that's specific to that user account, and sends commands; the application server verifies that the commands are valid given the current game state, and applies the commands.

I was planning on communicating between my game servers and database(user/persistent data) through password protected php scripts.

Would this be a preferred way to do it?

It depends, if you host the game server yourself, then no, its not the prefered way (If you host the game server you can have it connect to the DB directly, integrate php parsing in the game server or run a webserver thats only accessible from the game server)

If you need servers hosted by third parties to have persistent data you should give each host its own login details.

I was planning on communicating between my game servers and database(user/persistent data) through password protected php scripts.

Would this be a preferred way to do it?

It depends, if you host the game server yourself, then no, its not the prefered way (If you host the game server you can have it connect to the DB directly, integrate php parsing in the game server or run a webserver thats only accessible from the game server)

If you need servers hosted by third parties to have persistent data you should give each host its own login details (not to the DB; but to the layer between the DB and the game servers (Which you can write in any language you want, including php)

I'm confused. Are you asking for information about talking to a database from PHP on the same box, or are you talking about communicating between a game server and a database on separate boxes? Those are very different questions.

I would commuicate from a seperate system running the server software(game world server) with the PHP scripts which would then communicate with the database on the same server as the PHP scripts.

[quote name='Butabee' timestamp='1312517222' post='4844856']
Isn't that the case for every password protected system?

How would you suggest I communicate between the game server and database on different systems? The php scripts and database would be on the same system.

Every distributed application on the internet ends up looking something like this:

- Application Client
- Application Server
- Data Store

The game client receives data from the game server, and displays to the user. It also receives commands from the user, and enters them into the game server.
The game server receives commands from game clients, verifies the commands against game rules, and then updates the data store and sends new information to all game clients.
The data store stores data for later retrieval :-)

There really isn't much different, at this level, between a web site that sells hats, and a game. I can only add a hat to my shopping cart if it's a valid product ID that is in stock. I can only check out if I provide a valid credit card number and the shopping cart is not empty. Etc.

What differs between online games and online hat stores are mostly the value of the data, the rate at which the data updates, the complexity of the business rules, and the complexity of the data being exchanged.

So, in your online game, the application server could be a web server running PHP, assuming the rate of requests is reasonable for your game and server set-up. (Hint: if it's a real-time game, it probably won't be). The PHP page can talk to a database just like any other PHP page, as long as the data rate update isn't too much for your database server (Hint: if it's an action game, it will be too much). The client just connects, authenticates using a user/password that's specific to that user account, and sends commands; the application server verifies that the commands are valid given the current game state, and applies the commands.
[/quote]


I don't think I'd be acessing the php scripts and database very often.... it would be primarily for players logging in where clients don't directly communicate with the PHP scripts but would go communicate through a game world server which would then access the php scripts. There would be a variety of php scripts for doing stuff, like downloading character data for new players logging in. I wouldn't access the database to get to generate new items. The world server on a seperate machine would have a copy of all items in the DB and would handle new item creation and deletion. The world servers would pretty much handle everything else too... spawning mobs etc. Also the php access would happen in separate threads. Then the database would be occasionally up dated with new info.

So besides players logging in the DB/php scripts wouldn't be accessed that much.

I'm using unity so using the php script database communication would make things much easier.

If there's a better way to handle database access let me know.

would go communicate through a game world server which would then access the php scripts

In a traditional world, the game server would connect directly to the database server, using whatever the database server's client library is (either linked in, or something like ODBC).

If you build PHP scripts just to front-end the database, then generally you'd want to do that because you want to enforce a REST-ful view of your data. That can sometimes be a good idea, but it means that your entire application needs to actually be designed for a REST back-end, or it's just pointless extra work.