Some questions about server side plugins

Started by
3 comments, last by hplus0603 14 years, 5 months ago
I am creating a MMO Engine and I am using different MMO Engines to base my design on. Having experience with Multiverse I like the fact that you create Server side plugins and do not have to touch the client code at all. So my question is how would you go about setting it up this way? I am guessing the server takes care of all of the game logic while the client just handles the graphics but I am still unsure of how it would work. Any insight any one could provide would be great! Also I want to have the plugin system done in such a way that depending on what dlls are available different features would be available. For example you have a guild plugin. the main guild plugin that the server would load has the basic functionality for creating, disbanding, joining a guild. You then create other plugins for the more advanced features such as guild owned cities or guild to guild wars. When the guild plugin is loaded on the server the guild plugin checks to see if the other plugins are available and if so loads those features. If the plugins aren't available then your stuck with just a very basic guild system. Are there any tutorials or libraries available for creating plugin systems such as the one I describe?
In Development:Rise of Heros: MORPG - http:www.riseofheroesmmo.com
Advertisement
I'm a fan of the way Ogre3D handles plugins. Check out their source (the DynLib class handles transparent lib loading on different platforms. Each dll is loaded, and a dllStartPlugin method called, which then can register itself. For example, the OpenGL renderer plugin can call Root::registerRenderSystem(this)).
Thanks for your response. I am using Ogre for the rendering engine for the client but never took the time to see how they handle plugins. Good place to start I would say!
In Development:Rise of Heros: MORPG - http:www.riseofheroesmmo.com
The physical plugin architecture is the easy part. The hard part is providing a useful interface to tie into your game logic. How the plugins will need to work will depend a bit on how you structure your game architecture more generally. For example, if your game system involves logic being handled via messages sent to an entity, your plugins might register handlers for specific message types. If your logic consists of scripts called on entities to handle events, then maybe each plugin provides script overrrides for events it cares about. Persistence matters too - if your game is backed by a relational database then your plugin system may need to provide extra tables in the DB. And so on.
Here's a "grand unified theory" of mutliplayer games:

What the user sees is, at the end of the day, property updates, and events that cause property updates. Your HP goes down. Your position changes. Your list of spells is modified. Thus, the top-level capability should be one that can keep bags of properties on the server, and mirror them to the clients.

As an optimization, you often want to use events, rather than full property updates. For example, the event "start moving forward at time T" can substitute for a large number of "your position changed" property updates. Thus, you'll want some way to express that certain events will cause the client to update certain properties on its own, and only need occasional baseline updates to make sure any de-sync doesn't last for too long.

Your world is then a collection of objects, each of which has a bag of properties. Server plug-ins will be able to listen to events (filtered by source and target), read and write properties. Client plug-ins will be able to visualize property changes, and by extension, receive events that affect properties. Generally, when a client plug-in is loaded, it can start requesting its kind of properties/events/objects from the network system. No need for the server to send data that there's no-one there on the client side to listen to. This approach allows heterogenous clients cell phone vs desktop computer, say)

The devil is in the details, though. You'll need a large number of property kinds, and event kinds, that may have different forms of co-dependency. Thus, you'll want some framework that allows you to develop new property and event kinds, in addition to just reading/writing/sending/reacting to existing ones. At a high level, you can see any game networking system as some form of optimized implementation of this idea, with more or less bits being hard-coded for efficiency or simplicity.

enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement