Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>When the game is based on completely a server-client architechture, the job is almost done I think, but there is also wall hacks or something else.</p> </blockquote> <p>If you cannot move most of the logics to run on the server-side, at least try to share as little state as realistically possible during each game play phase, in other words: keep each player's active game mode into account and only share information that's actually relevant at that time. </p> <p>This will not only reduce the possibility to cheat, but also reduce the traffic caused by your protocol, i.e. it will improve the efficiency.</p> <p>This is a technique that in itself has long been known and applied in the gaming/simulation industry to improve efficiency when rendering large 3D scenes. </p> <p>There, "frustum culling" is used to determine which parts of a scene are actually visible, so that only the relevant parts are rendered.</p> <p>Similarly, the same technique can be used to restrict multiplayer clients to only receive certain updates/information if they are actually relevant, e.g. if other clients are actually within a "<em>range of relevance</em>", so that other clients may retrieve corresponding updates.</p> <p>Still, differentiate between relevance and "visibility": two players separated by a door may not actually "see" eachother, but depending on the surroundings, may very well hear eachother. So, differentiate between different types of "visibility": propagating audible state doesn't necessarily have to imply propagating the player's actual position in game coordinates. The same applies vice versa: only because you 'see' a player, you are not necessarily entitled to also hearing the client (e.g. imagine a scope on a rifle).</p> <p>In other words, try to loosely couple the update packets that you support, so that they don't have mutual dependencies on one another, and can also be propagated/subscribed to independently.</p> <p>Cheating can be largely controlled just by applying proper encapsulation and data hiding mechanisms, so that multiplayer clients do not generally share global state, but shared state is instead directly dependent on the player's active context (position, heading, orientation, speed etc).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload