🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Client/Server Engine Design: howto ?

Started by
9 comments, last by cmdkeen 23 years, 4 months ago
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
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.
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...).
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.

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
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.
Widelands - laid back, free software strategy
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.



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.

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

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 ? )

This topic is closed to new replies.

Advertisement