Behavior and logic are executed on the server. The clients are mostly for rendering, audio, and gathering input.

It looks as though most of the a components architecture benefits are only realized on the server.

Is it still beneficial to design the client with an component based architecture? Or is there a different approach that better fits a client.


1 Answer 1


If you plan on running similar architectures, ie. c++ for both client and server instead of mixed mode, then there's a pretty good case for building objects on both sides from a common code base of components.

1) you can choose what component load is needed for client or server independently. eg server doesn't need to render, client doesn't need to AI. 2) proxies of shared components for your networking protocol become trivial. 3) actions can be done local on the client to avoid ping delays, but verified on the server with the exact same code. eg movement 4) you've already written the code, may as well use it twice.

Reasons against might be: 1) you're using an existing engine for the client. 2) different language on the server. 3) if you're heavily scripting then your choice of language might work better monolithic.

  • \$\begingroup\$ Interesting. What about exposing part of the server logic (the shared component)? It can expose your game to be copied, doesn't it? \$\endgroup\$
    – barak1412
    Commented Sep 17, 2020 at 15:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .