0
\$\begingroup\$

I am fortunate being able to use the same programming language on both the server and client (javascript). I would therefore like to share my code and classes between server and client, like Half-Life (and possibly others) did.

To make things simple, suppose I have an MMO with a Player and an Enemy class, with a position, velocity, and health.

var Player = function() {
    this.health = 100;
    this.x = 0;
    this.y = 0;
}

var Enemy = function() {
    this.health = 100;
    this.x = 0;
    this.y = 0;
}

I know ideally these should inherit from each other (or use a CES system). But my question is as follows:

Since these classes will be used on the client and server (since both client and server needs to know about these entities) with some but not all shared logic, would it not be crazy to define two separate classes on both the server and client?

What are the advantages and disadvantages of sharing classes between server and client?

Are there any helpful websites with tips/tricks for this approach?

\$\endgroup\$
  • \$\begingroup\$ I would have a base class shared by the client and server, containing all the data shared by both (posision, rotation etc) Then I would derive a player and an enemy class on both the client and server. The client might need some more info from the player class like the representation (2d sprite, 3d model etc), the server has nothing to do with these. I would then make an update method on the base class with a parameter of type 'base class'. server. This way you can update the player and enemy class from the data received from the server \$\endgroup\$ – Thomas Oct 4 '13 at 9:38
  • \$\begingroup\$ You could also use preprocessor directives to omit code from the client. So you would only have a single class shared between the client & server but when building your game, you would enable or disable the preprocessor directive based on whether you're targeting the client or server. \$\endgroup\$ – user94720 Apr 8 '17 at 13:07
2
\$\begingroup\$

The answer is that it varies. A lot of the foundational code, messages and protocol handling and so on, can absolutely be shared.

At the game-object layer, it's often more advantageous to have separate client and server implementations. In a class-based system, it may make sense to have a common shared base class for each entity or component.

The advantages are that there is less code and ensuring common functionality (like replicated attributes and method calls) are hooked up is easier. The disadvantages are that little of the code will be common for most classes and you're leaking server-side implementation details (which may be relevant either to security or to cheat prevention) to the clients.

I've found it handy to support both, at least when using component-based game objects. Some components have no need of client- or server-specific logic. Some need heavy customization. Some differ only in their data or which messages they emit or receive.

Of further note for a component-based design is that some components are client- or server-only. Almost all of the graphics components, for instance, have no need to be loaded on the server. Likewise, many of the gameplay components have zero reason to exist on the client (assuming you're going for a client-server architecture and not a peer-to-peer setup). Physics or certain gameplay bits are needed on both ends, particularly if you have any kind of client-side prediction for lag-compensation going on.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.