How can I separate component functionality from networking logic?

Question

Is it possible to make network independent components that allow networking details to be specified externally?

For example, if I have a "Follow" script that follows a game object, it would need to do certain actions on the server and certain actions on the client. However, these things can change based on the network architecture. Single player games would not even need to consider what runs where. That makes perfect sense, except why should a component as general as "Follow" need to be different across different types of game?

I've tried creating a base component class that figures out how to call each method based on options set in the editor, but that failed due to RPC names needing to be different across all components attached to one game object. Not to mention it was messy. I've tried abstracting method calls to figure out how they should be called, but that doesn't solve the problem of WHICH methods should be network invoked.

I really don't want to build this into the components themselves, even though it might be the easiest / most obvious solution. That would destroy their portability across projects.

Answer 1

It sounds like your intuition is correct and the components should be separate. However, I would look for better abstractions. For example, you say:

"a base component class that figures out how to call each method"

Putting Unity aside, this is something of a design anti-pattern (in OOP). You'll wind up with messy classes that don't have a clear purpose and do too broad a variety of things (violate Single Responsibility). You will also have a base class that has knowledge of the more specific derived classes (the inverse of what you want). Instead, try to break the functionality into logical parts and use those as class boundaries. Here's an arbitrary example of classes you might create:

• FollowBehavior - keeps one object at a given proximity to another object
• FollowNavigator - determines which coordinates an object should move to when following (consumed by FollowBehavior)
• NavigationClient - Sends requests to a server to move an object from one set of coordinates to another (optional)
• NavigationPredictor - used to smooth the rendering on the client by anticipating acknowledgements from the server. Helps avoid server lag.

You can see that each class is responsible for a very specific task. They are also modular. e.g. You might keep the general follow behavior, but "plug in" a new FollowNavigator for a new experience. Hope that helps.