Generic Engine

1 General idea

The goal of this project is starting with PlaneShift actual source code and pol- ishing it, in order to get an engine which could, not only work for PlaneShift, but also with any other project who wishes to make an MMORPG(if the en- gine was also able to mesh to other mmo games types it could be considered a plus, could be a nice goal but not fundamental).

1.1 Data mantainability

It’s important to understand that the goal of this project isn’t to mantain the data, as is, of any project which will be using the engine but mantaining the possibility to obtain the same result. This means that with the same code, provided the correct data is updated accordly, if old, or made, if it’s a new feature, should allow various projects to obtain different games from the same engine: so whathever the data is updated accordly you should be able to obtain any frontend exactly as it is or even better. If anything of such would be impossible to obtain due to a change, even by redoing all the data (which is art, data files for the client and server database) it means the code being threated has failed the generic engine goal

2 Collaboration

We are trying to put up a collaboration enviroment with PlaneShift engine team and other developers using the same engine. there will be gains for both and when the generic engine will be mature enough maybe the separate code base could be entirely dropped and only one could be started from that point on. In the mean time the code will have to be merged between the code bases.

3 Handling of new features and big changes

Anything bigger than little changes like a rewrite of the gui or new big func- tionalities. which could lead to merge issues, should be done on a separate branch and kept merged with trunk. This way we will avoid long merge headcaches.

4 Plugin based design

In order to really make a generic engine we need to use a plugin based design. We will use the SCF system provided by CrystalSpace to obtain a plugin system. This goes in two main point 1. Try to make current code in plugin style and split them from each other interdependancy. This is, probably, the most complex thing to obtain and in some cases it could not be worth it. 2. If the code is not worth being converted to a plugin, due to better possibilities of code available now, differently from when it was first implemented, or it’s new (wasn’t in the codebase before) it should be designed in order to be prepared as a plugin since the beginning So at any time the goal should restructure code or structure it for the first time, depending on the case, to be plugin friendly, even if you don’t have enough time to actually complete the work needed to make it a plugin you should always have in mind it!

4.1 Benefits

As logical with any plugin based system there are various gains from this even if they come at an higher cost of time of implementation and complexity of design (which is also the biggest problem of this): • Allows to implement any subsystem even by breaking the point ex- plained in the section Scripting (This shouldn’t be done for the main plugins!). This would allow someone to make a more optimized game, if they have an use of it, or implement systems which are too radical to be compatible with any current code or plugin(like this would allow to make a different game type by changing some plugins and writing them again) • Allows easier unit testing: if the various parts of code doesn’t call each other but uses something else to interact this allows to test each piece of the project alone and discover bugs more easily. • Regardless, it forces the programmer to avoid bad programming prac- tices, and it’s a really good challenge even for who starts programming as it helps getting more clean code.

5 Scripting

An important thing, which is unfortunately lacking for most of the codebase we are starting from, is the scriptability of it. This is doable by splitting ideas as much as possible in sub-entities/sub-methods/sub-functions and, as we don’t have yet a good central scripting system, implement new things as c based ”scripts” inside a function which should be perfectly replaceable by an external scripting language.

5.1 Implementation

The scripting could be itself one or even two plugins with a 3 level structure. Starting from the script point of view: 1. The Script interpreter(LUA, Phyton, progressionscript (what is cur- rently implemented: an xml based custom scripting system), scheme, c like) This can even be in reality actually c/c++ built and compiled script which can be hooked up to the system as a plugin. This should implement, obviously, all the opcode of the lower levels, but is already usable with just a part of them implemented (just the plugin parsing the script won’t be able to use the full power of the engine and as a result also that particular scripting language won’t be able to). 2. A script handler which compiles the opcodes from the higher level plu- gin according to his directives and stores them for example in arrays rappresenting the program flow. These scripts should then be able to interact with the various parts of the program, which have been up- dated to be able to use it. Someone should be able to replace also this with his own implementation provided he can provide the right commands to the other parts of the engine. 3. The actual engine which uses the script in order to implement it’s functionalities.

6 Hardcoding

Just to be sure i’m adding also this: No hardcoding of any type will be tollerated!

6.1 Special cases

There are situations where hardcoding is not possible to workaround: an example could be an updater crisis case recovery code, where you need to rely on a builtin url in order to obtain the data, because, for example, config files could be not existant, or another example application names and con- figuration folders. In these cases all the needed things should be put in a global header which can be changed easily to build another project without any other changes to the source.

7 Implementation ideas for plugins

As cross plugin comunication in something complex as a server or game client could be needed there are various ways to obtain this without creating a direct cross dependancy (cross accesses). Just some examples: • Messaging system: make the plugin broadcast to all messages on need or requesting something and then waiting for other plugin to catch the message and work on it and maybe answer back (similar to bus system with memory mapped adressing). The code we have has already something similar builtin and could be improved upon. • Clear plugin api: Make the api standard and valid for all plugins. This obliges each plugin to implement the api even if some functionalities are unused.