Sign in to follow this  

Basic Client/Server models

This topic is 4834 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

I recently read this in another thread and it caught my interest.
Quote:
Original post by hplus0603 As far as I've been able to determine, there are two kinds of MMOG servers: those that just act like big routers and forward data between places (with a modicum of validation), and those that actually run the same physical simulation on the server as the clients. If your requirements for interactivity, latency hiding or integrity of the game world aren't that high, then the first is good enough, and you can use a different language on the server from the client. If you co-simulate on server and client (as in the Forterra platform), then you have to use the same language on both ends, or write ALL of your simulation code TWICE and have both implementations always come to the same result -- not my idea of fun :-) As far as I can tell, Persistent Worlds (Second Life, There, etc) lean more towards distributed simulation, whereas RPGs lean more towards packet forwarding with validation (EQ, CoH, WoW, etc).
This is a different approach from what I had envisioned. I'm doing a server for a RPG (not MMO; less than 100 players) and I had planned on doing it differently. I had planned on making the server run the authoritative simulation and have the clients just run the basic sprite movements on its own. I had planned on having the server sent a packet of the current state of the immediate vicinity around the player and have the client do a bare minimum. Is that a bad idea? (Note: I'm not experienced at all with network programming.)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by nagromo
I recently read this in another thread and it caught my interest.

Quote:
Original post by hplus0603
As far as I've been able to determine, there are two kinds of MMOG servers: those that just act like big routers and forward data between places (with a modicum of validation), and those that actually run the same physical simulation on the server as the clients.

If your requirements for interactivity, latency hiding or integrity of the game world aren't that high, then the first is good enough, and you can use a different language on the server from the client. If you co-simulate on server and client (as in the Forterra platform), then you have to use the same language on both ends, or write ALL of your simulation code TWICE and have both implementations always come to the same result -- not my idea of fun :-)

As far as I can tell, Persistent Worlds (Second Life, There, etc) lean more towards distributed simulation, whereas RPGs lean more towards packet forwarding with validation (EQ, CoH, WoW, etc).


This is a different approach from what I had envisioned. I'm doing a server for a RPG (not MMO; less than 100 players) and I had planned on doing it differently. I had planned on making the server run the authoritative simulation and have the clients just run the basic sprite movements on its own. I had planned on having the server sent a packet of the current state of the immediate vicinity around the player and have the client do a bare minimum. Is that a bad idea?

(Note: I'm not experienced at all with network programming.)



Clients can get loaded down doing the graphics.
Also, you dont want to have every client sending packets to every other client (you might look into broadcast mode sending if the machines are all on the same subnet)

You will be using UDP (speed is needed). Ive heard that there are free packet libraries available that can do most of the functionality for what you need (lobbies, sending reliable and unreliable messages etc...).


You might look into dead reckoning -- where movement vectors
are sent so that if packets are dropped/not synchronizing well
the object will continue along last known movement direction and be near where they are supposed to be (extrapolation of next position until the actual position arrives).





Share this post


Link to post
Share on other sites
The key is to make the server run all simulation authoritatively.

Then you can do different things on the client. For example, if your "guy" didn't move on your screen until you got the packet back from the server that he moved, then there would be lag between you pressing the button, and the guy moving.

Ways of hiding, masking, or designing around this latency are many and varied, and some are even patented.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Ways of hiding, masking, or designing around this latency are many and varied, and some are even patented.


Wow,

I dint think you could patent ideas, but source can be patented.So would it be right in thinking libraries which cost huge amounts will be/are available which have such capabilities?

The Internet is getting more and more commercialised .....

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by FireNet
Quote:
Original post by hplus0603
Ways of hiding, masking, or designing around this latency are many and varied, and some are even patented.


Wow,

I dint think you could patent ideas, but source can be patented.So would it be right in thinking libraries which cost huge amounts will be/are available which have such capabilities?

The Internet is getting more and more commercialised .....


There is no point patenting source because source is automatically copyrighted (protection that lasts longer than the life of the author, depending on published status). You can patent inventions, not ideas. Some algorithms can be patented and you may have to wait 20 years or agree on license terms. But then it is in the public domain, totally free. Also, the author must reveal the work in order to patent it (there are evil means to delay this in some places, but it is generally inevitable).

Share this post


Link to post
Share on other sites

This topic is 4834 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