Emulator

01/16/2011 09:16 Syst3m_W1z4rd#1

Is it ever done that a source was made to an emulator, so everything was script based and you had an emulator where you could edit everything, just like those bad 2d mmo emulators?
What I meant was, there was base code behind it, then it was obfuscated etc. So users only had the emulator to work of and no access to the actual sourcecode. C# Wouldn't be the best option in that case, but is possible with the right protectors & obfuscators.

Would it be nice to do one?
Do you think there ever will be done one public/non-public?
Is there one?
How should be working, if there should be one or if there come one?
What language should it be coded in?
What language should the scripting be in?
Should it be able to change versions from the emulator and enable/disable things?

What's your opinion?

/discuss

01/16/2011 09:29 ChingChong23#2

your getting mixed up, emulator does not mean 'core of a server'

01/16/2011 11:27 pro4never#3

So basically you're asking for a proper server core where all functionality is controlled through external plugins or scripts...

Emulator means recreating... or EMULATING a certain platform, game, experience. etc. If you want to get right down to it... all private server sources are a form of emulator. They seek to emulate the server functionality of conquer online.

As for doing a base server core... I like the idea as far as just doing a base core (say through a dll which handles all the connections and stuff) and then leave everything else up to the user to do as plugins. Actually immune was working an a C++ library for conquer iirc... there were a few other projects doing something like this before.

Basically you'll get no real advantage in MOST cases from doing this other than making an easily distributable/upgradable source. Any source that is organized at all though would have virtually the same set of 'advantages'. Namely customization (again... normal servers can use external scripts all they want) and the ability to easily upgrade/change things (if everything is organized and or using some external plugins/scripts... it's far from difficult)

01/16/2011 16:18 Nullable#4

WARNING: Quite a big post, code example below.

Such a server core just can't be done by simply opening up the IDE and making up code that works as you go on, you're missing a great deal of real software engineering, and since you're going for something serious, you have to check your possibilities.

You need to specify an efficient design pattern to use/customize to your needs, or you might even create up your own design pattern.

IMHO for extensibility i'd go with a Strategy Pattern (aka Policy based design) design for keeping the core intact and available for later editing by simply changing functional classes in there, which could also be other hosts for other functional classes.

You will not only allow for really fast edits in less time, but by allowing such extensibility in your code also allows for having multiple running modes for the server, ex. 5135 mode for allowing 5135-patched clients or 4267 mode for allowing 4267-patched clients, notice the amazing patch difference yet the same core for both.

As for the language in choice, i'd take C++, C++'s templates allow (IMHO) further more control and extensibility to your classes, plus the types of the classes are determined at compile time so there will be absolutely no impact on the performance vs a core that's not extensible.

C# also allows such functionality, with no significant performance impact.
[[Only registered and activated users can see links. Click Here To Register...]]

LATER EDIT:
Kinda free so I decided to write up a small example of policy-based designs in C#

Code:

	public interface IOperation
	{
		int Operate(int arg1, int arg2);
	}
	
	public interface IDisplay
	{
		void Display(object Arg);
	}
	
	public class TestHost<T, C>
	    where T : IOperation, new()
	    where C : IDisplay, new()
	{
		T Oper = new T();
		C Disp = new C();
		
		public void Display(object Arg)
		{
			Disp.Display(Arg);
		}
		
		public int Operate(int arg1, int arg2)
		{
			return Oper.Operate(arg1, arg2);
		}
	}
	
	public class MultipleOperation : IOperation
	{
		public int Operate(int arg1, int arg2)
		{
			return (arg1 * arg2);
		}
	}
	
	public class ConsoleDisplay : IDisplay
	{
		public void Display(object Arg)
		{
			Console.WriteLine(Arg.ToString());
		}
	}
		
	public static void Main (string[] args)
	{
		TestHost<MultipleOperation, ConsoleDisplay> THost = new TestHost<MultipleOperation, ConsoleDisplay>();
		int result = THost.Operate(2, 6);
		THost.Display(result);
#if DEBUG
		Console.ReadLine();
#endif
	}

Code:

Result: 12

01/16/2011 18:17 Syst3m_W1z4rd#5

Thank you all for your answers.

@Nullable
That's some sick info you got right there. Alot I didn't know.
Well I'm not going to do one, was just something that went on my mind :D

01/16/2011 19:11 Nullable#6

I realize that, my post was merely to introduce the idea of generic design patterns for the core that allows scripting idea that p4n was talking about, also that design approach allows having multiple classes that could be plugged in as generic types anytime for multiple scripting languages support while keeping the core code that relies on those scripts intact as long as they follow a common interface/signature.

Adding up to what I posted before, I'd say any language, which can be adapted to the design pattern that you decide to use, can be used.

For a public one, I had the thought of introducing an open source core with such extensible properties before, but ImmuneOne already started with one. so..