Sign in to follow this  

Game server and database communication

This topic is 2323 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[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.
[/quote]

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.

Share this post


Link to post
Share on other sites
Hidden
[quote name='Butabee' timestamp='1312513032' post='4844837']
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?
[/quote]

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.

Share this post


Link to post
[quote name='Butabee' timestamp='1312513032' post='4844837']
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?
[/quote]

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)

Share this post


Link to post
Share on other sites
[quote name='ApochPiQ' timestamp='1312564559' post='4845094']
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.
[/quote]


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.

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1312566409' post='4845110']
[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.
[/quote]

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.

Share this post


Link to post
Share on other sites
[quote name='Butabee' timestamp='1312581408' post='4845241']

would go communicate through a game world server which would then access the php scripts
[/quote]

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.

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1312585813' post='4845268']
[quote name='Butabee' timestamp='1312581408' post='4845241']
would go communicate through a game world server which would then access the php scripts
[/quote]

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.
[/quote]

They say Unity is has ODBC support but I have no idea where the documentation is on how to use it with unity, or how to use it at all. If there's little documentation, I'd much rather use scripts even if it is some extra work.

Share this post


Link to post
Share on other sites
[quote name='Butabee' timestamp='1312588382' post='4845277']
They say Unity is has ODBC support but I have no idea where the documentation is on how to use it with unity, or how to use it at all. If there's little documentation, I'd much rather use scripts even if it is some extra work.
[/quote]

So your proposed architecture is this?

1) Unity client
2) Unity game server
3) PHP application server
4) Database

That can work fine, assuming that you can trust what 2) sends to 3).

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1312663512' post='4845533']
[quote name='Butabee' timestamp='1312588382' post='4845277']
They say Unity is has ODBC support but I have no idea where the documentation is on how to use it with unity, or how to use it at all. If there's little documentation, I'd much rather use scripts even if it is some extra work.
[/quote]

So your proposed architecture is this?

1) Unity client
2) Unity game server
3) PHP application server
4) Database

That can work fine, assuming that you can trust what 2) sends to 3).
[/quote]

Yup that's it! :)

I'm actually kinda debating on the game server though, I'd like to have server side physics but that's less players per server, but IMO there's no reason to support more players than can be handled as if the whole server of players was in one area and interacting.

I think unity as a game server could only handle 500-1000(depending on current CPUs) concurrent players with physics and collision detection. That's more than a client could render at reasonable speeds though so I guess I'm good :)

Share this post


Link to post
Share on other sites

This topic is 2323 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this