Need Help with a Game Server

[Eugen Jung]

.

 

[misson]

Caveat: I'm not a game programmer, though I have a little experience with simulations and client/server architecture (but it's been awhile).

This is my proposed method (not sure if it's already in use or will even work):

1. ...
2. The client processes the physics for itself ONLY, and transmits it's new location & orientation to the server.
3. ...

Any control that the server cedes to the client opens the door to cheating. You can reduce this by encrypting communications using public-key cryptography, embedding credentials in your clients and only distributing them as binaries, but if you'd ever consider releasing this (and not keeping it as a research project), someone will crack the credentials if it gets popular enough and write their own client.

One way of approaching this at the architecture level is to use distributed computing, which (if implemented properly) will scale very well. The processing nodes could then be run on a server cluster or clients or both. If the network is fast enough, you could have client nodes process the physics for unrelated (i.e. distant) client nodes to reduce the benefits of cheating. You could also see if you could add load balancing, so the server process the physics as long as it has the resources to handle it, but farms it out if it doesn't. If you're clever, you can do away with servers entirely and distribute all calculations across the clients.

Firstly, what kind of hosting would I need for this? Would I need a dedicated VPS?

On any host, you'll likely need a VPS since you want to run a custom server.

Secondly, how would the uploading/downloading of player info work? Remote SQL? What is most efficient? An actual program running on the server which stores the info in the memory, or something more like a simple database (SQL?) that the client programs can access?

Note there are two different concerns here: data storage, and data access/interchange.

While you could use SQL as a data access language, using an RDB wouldn't be prudent. DBs are more for persistence than IPC. Using SQL only makes sense if you're using a relational model for your data, but I expect that an object model would be more useful. Also, Codd himself has called SQL a flawed implementation (he even devoted a chapter of The Relational Model for Database Management: Version 2 to the subject).

A datastore probably won't be directly involved in communications with clients. The server simply accesses the structures it has in memory when servicing clients.

If you're only going to support your own clients & server and don't need to interoperate with any other system, you can design a custom protocol and binary format designed to best meets your needs. If interoperability is important, you could describe the format using ASN.1 and use a library (perhaps libtasn1) to handle data interchange. You might find a better alternative on PaulT's list of XML alternatives

As for what information to include in messages, consider that user input is mapped to events in the game world by the client. The client then sends these events (or their affects) to the server. The server also sends relevant events to each client, along with general world status updates.

One concept that might apply to designing your communication protocol is a common one in compression: a compressor and decompressor have a model of the information source. The compressor only sends information to fix deviations of the actual signal from the model output (in English: if you know what's coming, you don't need someone else to tell you).

And thirdly, how would the above be implemented? Are there third-party libraries for this kind of thing? How does my program connect to the server? Do I need to worry about ports? Is there a cross-platform way to do this?

The clients connect to the server the way any client does: TCP/IP sockets. The exact details vary from platform to platform. Some platforms (such as Java) offer abstractions, so you can treat network connections as an I/O stream, just like files and consoles. If you have to work at the socket level, there are books and webpages that can show you how. It doesn't have to be a terribly large topic, though if you want to really get into it get Stevens et al.'s Unix Network Programming, Volume 1. For Windows, see the Windows Sockets 2 section on MSDN. Back in college we used the slim Pocket Guide to TCP/IP Socket Programming in C (the authors have also published a slideshow on the book's site that ties in to the first to chapters).

You'll need to worry about ports insofar as the clients might be behind firewalls. If the server ever needs to initiate a connection, then you'll also need to worry about NATs. On the other hand, gamers should be used to dealing with their firewalls and NATs, so you can leave that up to them.

Java would be cross-platform. A Python client would also be fairly cross-platform.

Any help at all - even if it's just a link to something I might find useful - is greatly appreciated.

If you want to go spelunking, you can pick some open source games from Wikipedia's list of open-source video games and see how they handle things.

 

[Eugen Jung]

.

 

[misson]

For crypto, take a look at openssl. Make sure you read the license to see if it's appropriate for your project.

 

[vv.bbcc19]

There is already a game server such.
You can write your game for the same or find your game in the list of games available.
Its is a open source project named gameq.

http://sourceforge.net/projects/gameq/

Revert back if this is not what you wanted.
Hope this helps.

I'm working on a program for a research project (let's just call it a game, for the sake of simplicity).

The "game" is a standard stand-alone program, not an online browser-based game. It is a simple 3D world (think Second Life). So far so good.

Now the problem is that it also needs to be able to allow people to interact with each other within the game (think World of Warcraft). I don't know much about these kinds of game, as all my previous work has been single-player. Unfortunately, I am the only game developer on the research team, so it falls to me to create this "game".

I believe that a common method is:

1. The client connects to the server and adds itself to the list of players.
2. The server creates the required elements.
3. The server processes the physics for each player, and transmits the current location & orientation of every player to the various logged-in clients.
4. The client renders the scene.
5. Repeat from #3.

The disadvantage of this is that the server can't handle many players.

This is my proposed method (not sure if it's already in use or will even work):

1. The client connects to the server and adds itself to the list of players.
2. The server creates the required elements.
3. The client requests a list of players along with their current location/orientation.
4. The client renders the scene.
5. The client processes the physics for itself ONLY, and transmits it's new location & orientation to the server.
6. Repeat from #3.

This means that the server will be able to handle many more players because all it needs to do is supply the client with the location/orientation of each player, and the client program will do the rest.

However - as I've said - I have no experience with this sort of thing. (I should mention that I'm developing on Fedora Linux, using C++ and the Bullet physics engine.)

Firstly, what kind of hosting would I need for this? Would I need a dedicated VPS?

Secondly, how would the uploading/downloading of player info work? Remote SQL? What is most efficient? An actual program running on the server which stores the info in the memory, or something more like a simple database (SQL?) that the client programs can access?

And thirdly, how would the above be implemented? Are there third-party libraries for this kind of thing? How does my program connect to the server? Do I need to worry about ports? Is there a cross-platform way to do this?

Any help at all - even if it's just a link to something I might find useful - is greatly appreciated.

Thank-you for your time.