Advertisement

Separating the client & server code?

Started by May 16, 2004 07:57 AM
3 comments, last by peter_b 20 years, 8 months ago
Hello! Im designing the layout of my next project atm. And im having some trouble deciding what how to do it well. Problem nr1: First i was thinking that the whole engine would be in one lib. But the problem here is that the server will be crossplatform, and directx wont compile on linux. Anyway even if it was just for windows, including unneccesery client functionality in the server build seems "wrong". So i decided to make two libs, with the client lib including the serverlib. (since the client will also be able to act as server, and need alot of the functionality for lag prediction). Is this a good way to solve the problem? Anyone who had this problem figured out a diffrent way? Problem nr2: Is there any good way to reuse the ai statemachines of the server on the client? I use the statemachine to controll actor animation, sound playing etc(is there a better way?). But apart from that, the code on the server and the client is identlical. But i have to paralle copies of the same code on the server ai and the client ai, except that the client also handle animation states and sound playing. Example: AI statemachine on server:

StateIdle
  OnAttacked:
    PathFind(oponent);
    // Do other logic

  OnDead:
    Remove(this);
EndState




And the same on the client:
StateIdle
  OnAttacked:
    PathFind(oponent);
    setAnimation(angry)
    playsound(roar);
     // Do other logic


  OnDead:
    setAnimation(dieing)
    playsound(deathsound);
    Remove(this);
EndState
It works but it seems like there might be a better way.. Anyhow these are the problem iv encouterd in my planning so far. Any advice is greatly appreciated. Thanks in advance [edited by - peter_b on May 16, 2004 8:59:38 AM] [edited by - peter_b on May 16, 2004 9:00:31 AM]
Shields up! Rrrrred alert!
Instead of breaking the game down into sever/client libs, consider breaking it down into core/platform lib. Let me elaborate.

The core library contains the code which is platform independent ( such as simluation engine, AI engine, event sub-systems, memory manager etc.. ). The core exposes an API which allows external modules to query it. This is the interface which the platform dependent code talks to the core.

The platform library contains code restricted to a certain platform, such as 3D graphics, sound and networking.

Look up concepts relating to the Model View Document or Model View Controller. It deals with structuring programs and designing programs. It''s a good way to break you program down into more flexible and manageable units.

Also look up the concept of data driven applications. This will solve your problem of sharing code between the server/client.

Good Luck!

-ddn
Advertisement
Thanks for the advice, that sounds like a better idea, il look into the Model View concepts.


On a side note: What do you mean with "simluation engine"? Iv noticed other references to it here and there. Is it the actual "game" running? I mean the frame tick, physics update, actor update etc?
Shields up! Rrrrred alert!
I do it kinda the same way. I have a portable lib with appropriate headers. In it is everything that is not platform specific. Then, for every platform, I make an executable that uses the lib.
As for the client/server issue. I simply put core functionality in CServer and CClient inside of the lib. Basically they are just two connection managers and datagram routers. For a dedicated server, I create a CServer object, and it will run simply managing connections and routing datagrams to a CProtocol class that is loaded from a plugin. If there is a local connection, create a CClient class with the loopback protocol. Sounds complicated but it is very simple if you understand what I am saying. Basically, in the lib is client/server portable, in the executable is platform specific code and the execution environment, in the plugins are server/client specific code and protocols/cvars/console commands/etc...

Intro Engine
Well games usually have arbitraty code which fits no encompassing descriptive name. Unlike the physics, event, or memeory manager subsystem for instance. It''s the game rules and logic. I call it the simulation layer but that''s because my games are usually simulations. So it''s a catch all.

Good Luck!

-ddn

This topic is closed to new replies.

Advertisement