Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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