Skip to main content
GameDev.net gamedev.net
🔒 Locked

Maximizing client/server code re-use

Started by venzon Jul 1, 2007 at 11:02 PM 1 replies 1.4k views
Original Post
venzon
venzon
I'm about to start implementing a multiplayer system (on top of SDL_net) for an FPS-type game. I want to build a dedicated server as well as a client. The server will compute and send deltas from the previously sent object states as they are relevant (for example, only in a certain radius around a client). The client plugs the data into its objects via de-serialization and does some sort of compensation logic to alleviate warping. This means that although the client and server objects are similar, they also have functionality specific to each (server needs to compute relevant sets and deltas per client, client needs warp compensation and extra graphical data). Anyway, I'm trying to figure out how to maximize code re-use between my client and server. Any ideas? How is this usually done? Should I make every class have a base class with shared functionality and then one derived class for the client and one for the server? Or just implement both client and server functions in one class? Has anyone tried these and decided what's easier? I'm trying to shortcut some lengthy prototyping by getting advice from people with more multiplayer coding experience.
oliii
oliii
if it's server/client, I would keep the separation as much as I can between server and clients. Even if it means more code. It's a lot clearer than to use a common class that can do both. Especially if you work in a team, and other coders have pretty loose concepts of network game coding. As for shared functionality (physics prediction code), it is better to have helper functions that are shared for both server and clients.

Server/client entities can however share a small common basis ('entity' based stuff mostly, update(), render(), init(), handleMessage(), entity creation and referencing...). It's better to work that part out through aggregation anyway.

I am working on peer-to-peer and the network game part has been slapped on top of a single player framework. It's a total nightmare. It's also peer-to-peer, and has server migration. However this is more difficult to achieve with a split client-server interface.
Everything is better with Metal.
venzon
venzon
Quote:
Original post by oliii
if it's server/client, I would keep the separation as much as I can between server and clients. Even if it means more code.
...
Server/client entities can however share a small common basis ('entity' based stuff mostly, update(), render(), init(), handleMessage(), entity creation and referencing...). It's better to work that part out through aggregation anyway.


Thanks for the advice. I'll try what you recommend -- using aggregation (or external helper functions) rather than inheritance for the shared code, and create separate client/server objects.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.