Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

cmdkeen

Client/Server Engine Design: howto ?

This topic is 6482 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 want to rewrite the design of my platformer engine using a Client/Server structure. This is what I understand ( or believe to understand ) Basically I know I there is a Server class simulating the game/level/world/... and a Client displaying the whole thing and catching input to. The Server part sends information about the game state to the client and the client sends input from the user back to the Server. Can anyone give me some more detailed information ? Also a sample implementation (links..) would be great. One special thing I''m wondering about is what amount of information has to be sent from Server to Client ? Only the movements of all the objects, only things that are near the Client''s player, etc. ?? thanx in advance

Share this post


Link to post
Share on other sites
Advertisement
Well, as to what messages need to be sent from the client to the server, it all depends on what works best for you. You can design a very thin client which just sends keypresses from the user to the server and renders exactly what the server tells it to, or you can design a very thick client that performs most of the server work, where the server is only responsible for distributing those changes to other clients.

The thin client model generally has somewhat higher network requirements, while the thick client requires some higher system specs. Figuring out the perfect balance for your system is the key to it all.

Share this post


Link to post
Share on other sites
For me the thick client seems better because for me there are two main goals the whole thing has:
1. keeping the Server/Clients synchronised whatever happens
2. keep the amount of data to be sent as small as possible

In most cases the server is a player himself ( i even won''t implement a standalone server ). That''s why the Client and Server should get the same amount of jobs to do.

The best thing would be a scalable structure. This means if the connection is bad the server sends less data and if it''s good he sends more data. Maybe some areas of the map should be done by the clients.


There are some measures I thought of to decrease network traffic dependent on the connection quality:
- reduce the accuracy of object positions ( -> they''ll be moved pixel wise )
- only send infos about the area around the client''s player(s)
- calculate a checksum from the object''s status and send it to detect async parts of the game world

What do you think of this ?

cmdkeen

btw: Only transmitting the user''s input could be a bit dangerous as it might desync if any keypresses/releases are lost ( I even got problems with this on a local machine when the player dies and the keys aren''t resetted - a hero running straigth into a pitfall isn''t too exciting...).

Share this post


Link to post
Share on other sites
Hi,

You should create a thick client, because the internet is slow, and you''d want to keep data sent as small as possible, so you can send more dataframes per second -> smoother gameplay.

Share this post


Link to post
Share on other sites
The main reason people don''t use "thick" clients is security...any thing the client has control over is able to be hacked by people. In your simple platformer you probably don''t care, but anyone who has faced a cheater in online games knows it basically sucks. If you let the server decide what is legal and what is not, etc, you keep people from ruining the game for others.

Anthracks

Share this post


Link to post
Share on other sites
Well, there are basically three sorts of cheats you have to handle seperately:

- "Rule" cheats: these actually violate the game rules, i.e. a player running too fast. You can have a thick client and just make sure the transmitted data is valid to prevent them. No problems there
- Knowledge cheats: These cheats reveal knowledge to the player that she shouldn''t have, e.g. cheats that reveal the whole map, or cheats that let you see through walls. Thick clients prone to these cheats because they have to know more stuff about the current state of game to do the game logic.
- Doping cheats: cheats that increase a player''s ability, e.g. aimbot proxies. It really doesn''t matter whether you have a thin or a thick clients; both are quite prone to doping, and unfortunately there''s no final cure against them.

cu,
Prefect

---
Sanity is the trademark of a weak mind.

Share this post


Link to post
Share on other sites
Isn''t it possible to add some sort of checksum to the packets? It could be a simple 2 byte value, like an integer in VB (or an Float/Dword in C?). This would probably prevent Aimbots, cause they don''t know the formula to calculate the checksum.



Share this post


Link to post
Share on other sites
Almar: yes, I believe by using checksums you could detect many manipulation. But the algorithm could be hacked. Maybe there should be 2 checksums. The second is only used every 10st game so a cheater can''t test his hacked algo too often. But when it detects a cheat the cheaters prog will manipulate all data files to make the cheater reinstall his game or even ban him.

Share this post


Link to post
Share on other sites
I think that if you make the "formula" for the checksum long/complex enough that hackers will have a very hard time...
Like: LengthOfPacket * FirstByte + ValuesOfOtherBytes / 2 + AnythingElseYouCanThinkOf

Share this post


Link to post
Share on other sites
Well some interesting thoughts here but back to my initial question:

How to design a Client/Server game framework ?
What special technics are used ?
And most important: how to transmit the game state to all clients in time ? ( only send positions, or better the speed to enable clients to continue the game even if theres no connection for a second ? )

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!