Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
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.
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.
