Unkermouse: wikilink

2010-12-11T15:40:46Z

wikilink

← Older revision		Revision as of 15:40, 11 December 2010
Line 44:		Line 44:

	In order to really make a generic engine we need to use a 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		We will use the SCF system provided by [[CrystalSpace]] to obtain a plugin
	system. This goes in two main point		system. This goes in two main point
	1. Try to make current code in plugin style and split them from each other		1. Try to make current code in plugin style and split them from each other

Ethryn: add to category (Engine documents), corrected some spelling (please use a spellchecker... ('phyton'... wtf?))

2010-10-23T00:03:00Z

add to category (Engine documents), corrected some spelling (please use a spellchecker... ('phyton'... wtf?))

Show changes

Talad at 21:43, 12 October 2010

2010-10-12T21:43:37Z

← Older revision		Revision as of 21:43, 12 October 2010
Line 142:		Line 142:
	obliges each plugin to implement the api even if some functionalities		obliges each plugin to implement the api even if some functionalities
	are unused.		are unused.

	8
	~~License situation~~

	~~As it is most of the code is licensed under GPLv2 and the copyright is assigned~~
	~~to Atomic Blue, the entity rappresenting PlaneShift, and this code isn’t going~~
	~~to disappear and neither going to not be added anymore in a collaboration~~
	~~enviroment. Plus we have to consider some sort of licensing allowing the~~
	~~code to not be pulled out of the code base (even in future versions: gpl~~
	~~doesn’t protect aganist this) but, at the same time, we don’t want to block~~
	~~who contribuites to this engine to license his code also to others under other~~
	~~licenses and we need in any case also someone who could obtain the right of~~
	~~holding the code in court in case of gpl breaches. This needs some tought as~~
	~~I’m not a lawyer.~~

Talad: Created page with '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, b…'

2010-10-12T21:32:27Z

Created page with '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, b…'

New page

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.

8
License situation

As it is most of the code is licensed under GPLv2 and the copyright is assigned
to Atomic Blue, the entity rappresenting PlaneShift, and this code isn’t going
to disappear and neither going to not be added anymore in a collaboration
enviroment. Plus we have to consider some sort of licensing allowing the
code to not be pulled out of the code base (even in future versions: gpl
doesn’t protect aganist this) but, at the same time, we don’t want to block
who contribuites to this engine to license his code also to others under other
licenses and we need in any case also someone who could obtain the right of
holding the code in court in case of gpl breaches. This needs some tought as
I’m not a lawyer.

Generic Engine - Revision history

Unkermouse: wikilink

Ethryn: add to category (Engine documents), corrected some spelling (please use a spellchecker... ('phyton'... wtf?))

Talad at 21:43, 12 October 2010

Talad: Created page with '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, b…'