🔒 Locked

Multiplayer server-side scripting with C#

Started by Integra Jun 15, 2004 at 12:54 PM 17 replies 3.5k views

Original Post

Jun 15, 2004 at 12:54 PM

I fixed up the majority of bugs I had in my server software last night, so I figured I would post the idea incase others were interested. Basically what I have done is build my game server in unmanaged C++ for the time being and aimed at the Windows Server platform. I thought long and hard about scripting, and after much debate I really felt like using the .NET framework and the C# language for scripting. What turned out as a small test now encompasses my whole server, and I find this technique quite powerful, if not the most powerful I have used yet. When I did was interface the performance critical unmanaged C++/Winsock code server with managed C++ and C#. The scripting language used on the game server is obviously C#, and this has added much benefit. First of all the syntax of the language and the design behind it, I find it probably the best and most intuitive that I have used for scripting on a server. Secondly, the ability to reflect and recompile on the fly REALLY has it's benefits. Right now you are able to make changes in the scripts on the servers and have them recompile on the fly while the server is still running. This was very important to me because I wanted the ability to update while keeping the servers live. The server compiles the scripts to the dedicated files on the fly and without any performance hit (when benchmarked there has been zero difference). Another team has used this approach, the RunUO server emulator for Ultima Online, although they wrote the complete server in C# and I do not believe they support compilation while the server is running, I believe they only allow this at startup. Anyways I just thought it was really cool and that I'd share my latest project. PROS: On the fly compilation of scripts. Ability to change scripts, etc while the server is live. Easy to use OO syntax and structuring. CONS: Microsoft platform licensing fees. (although I have to look into this, I have not yet tried to port my server to FreeBSD/Linux yet. I need to read some more specs on the GNU .NET project to make sure it is fully functional at the moment) Having to interface unmanaged C++, with managed C++, with C#. This isn't very hard and there you don't see a performance hit as it is not at a critical stage in the server.. but it still had to be learned.

Voxelsoft

Jun 16, 2004 at 2:16 AM

If you want to avoid Microsoft, have a look at the free implementation of C# on http://www.go-mono.com/

Integra

Jun 16, 2004 at 8:00 AM

It's not that I want to avoid Microsoft, I actually love the Microsoft platform along with it's performance, stability, and ease of use.

The only problem is licensing fees to run Windows servers, as I do not steal software and the fees would actually amount to more than the hardware.

I know about Dot GNU and Mono, but I haven't yet checked up to see if they run on FreeBSD.

Thanks.

hplus0603

Jun 16, 2004 at 1:33 PM

We have tried deploying production server clusters on Windows 2000 (as well as XP) and I have to say that Linux has been more stable for us. The one problem we found, we could fix, because we had the source.

That being said, I love Windows for the desktop. While I do have the source to Linux, the volume of things needing fixing for a productive corporate desktop environment encompasses many engineer-lifetimes of work. (In my opinion, which is well-researched for my specific circumstance.)

Integra

Jun 16, 2004 at 1:39 PM

I've had no problem with deployment of Microsoft servers, it's quite the opposite when I used to run Linux DNS servers that weren't very stable and were switched back to Windows boxes. That was about 3-4 years ago though I must say, so I am guessing that Linux has progressed since that time.

My concern is basically the licensing fees for Windows server and SQL server, which are astronomical for a small vendor such as myself.

This is the reason I am most likely going to write a port to run on a cluster of FreeBSD boxes using PostgreSQL. I still have not had enough time to really delve into dotGNU or mono so see if reflection and codedom framework namespaces are working fine, and if those platforms support FreeBSD.

The reason I am trying to learn more and get into FreeBSD is due to the fact that it not only outperforms most operating systems, is open source, but the security issue. FreeBSD is widely known to have the longest uptime servers with the least amount of security issues.

Thank you kindly for your input. I appreciate any input on the subject.

Arild Fines

Jun 16, 2004 at 2:23 PM

Quote:
Original post by Integra
I still have not had enough time to really delve into dotGNU or mono so see if reflection and codedom framework namespaces are working fine, and if those platforms support FreeBSD.

See this page. It lists the status of the various classes in the Mono class library.

Integra

Jun 16, 2004 at 2:31 PM

Wow hey thanks a million Arild, I appreciate the link I hadn't seen that before.

I am curious about one thing, I do not see the System.Codedom namespace listed in that tree. Am I just looking in the wrong place for it or is it not implemented into their .NET version for some reason?

Thanks again.

hplus0603

Jun 18, 2004 at 1:32 PM

According to what I can see when I click the "System" assembly on that page, and scroll down, 100% of System.CodeDom is implemented:

System.CodeDom: 100%

Arild Fines

Jun 18, 2004 at 2:41 PM

Quote:
Original post by Integra
I am curious about one thing, I do not see the System.Codedom namespace listed in that tree. Am I just looking in the wrong place for it or is it not implemented into their .NET version for some reason?

The link I gave you was for the corlib assembly. System.Codedom is in System.dll. At the top of the page there is a list of the various assemblies you can click on in order to see the status of the classes in them.

Integra

Jun 18, 2004 at 5:34 PM

Quote:
Original post by Arild Fines

Quote:
Original post by Integra
I am curious about one thing, I do not see the System.Codedom namespace listed in that tree. Am I just looking in the wrong place for it or is it not implemented into their .NET version for some reason?

The link I gave you was for the corlib assembly. System.Codedom is in System.dll. At the top of the page there is a list of the various assemblies you can click on in order to see the status of the classes in them.

oops didn't see that.. this is great thanks a million Arild.

Now the only thing I'm going to have to find out is if the FreeBSD port is up to date and if it will run mono. If so that I will be writing a port for that OS as to have BSD and Windows compatibility. If not I guess I'll stick with Windows for the time being and worry about live licensing later on.

When I get some more time next week I will be installing my FreeBSD machine and I'll update on whether or not mono can successfully be run.

Arild Fines

Jun 18, 2004 at 6:39 PM

I recommend that you sign up for this mailing list. If you run into any trouble with it on FreeBSD, these people will help you out pretty fast.

wolfman8k

Jun 21, 2004 at 11:30 AM

Also, you mentioned in another thread that you want to use generics. guess what? mono already has support for generics! It's alpha, but i've been using it with no problems. You can even install mono on your windows development box and use it, if you must stay on windows :P

Integra

Jun 21, 2004 at 12:44 PM

Quote:
Original post by wolfman8k
Also, you mentioned in another thread that you want to use generics. guess what? mono already has support for generics! It's alpha, but i've been using it with no problems. You can even install mono on your windows development box and use it, if you must stay on windows :P

Oh I know that mono is already supporting much of the generics with C#.. and I have heard some great things about it.

For this project I did not need generics, as I used C# mostly as a scripting language for the server, I did not run into problems.

What I wanted the use of generics for was in C# and Managed DirectX projects, where I really need the generics support. I may actually try out mono on Windows tonight and see how my test rendering code works with generics.

Integra

Jul 19, 2004 at 12:31 PM

Quote:
Original post by Anonymous Poster
You say you recompile the code using Code dom How du you unload the ould code?.

using .net as an Scripting host issent that good today as if you compile a newe version of the assambly the old version stays in merory. You can onely unload code if it is in a nother code dom. but comunicate beween code doms is like cominication beween prozesses.

Can you pleas explain how you managet to avoid this problems ?

Wow sorry I didn't see this last post at all, my apologies for taking so long to reply.

Well this was actually one of the largest problems I had when building my framework, because obviously .NET does not allow for unloading assemblies from the AppDomain because of issues with managed code (ie it truly isn't a managed system if you could just pull assemblies out).

What I did was use multiple AppDomains, as is recommended by Microsoft if you really do need to unload assemblies. As stated by numerous Microsoft developers, the ability to unload assemblies either will not be put into the system, or if it is than it requires some major work being done and would be in a major .NET release.

I found a post by Stephen Styrchak elsewhere and he posted what he used for basic script-engine code with dynamic AppDomain, and I went from there designing and building the system with multiple AppDomains.

Here is the code he posted:

public class MyApplication{
public static void Main(){
AppDomain appDomain = null;
AppDomainSetup setup = new AppDomainSetup();
//TODO: customize settings for the remote AppDomain.
try {
// Create a remote AppDomain to do compilations in
appDomain = AppDomain.CreateDomain("VsaDomain", null, setup);

// Instantiate my VSA host object in the remote AppDomain. This
// reduces the number of cross-appdomain calls and also I do not
// want to call IVsaEngine.Assembly from here because that defeats
// the purpose of the remote AppDomain.
AssemblyName assemblyName =
Assembly.GetAssembly(typeof(MyVsaHost)).FullName;
MyVsaHost host = (MyVsaHost)(appDomain.CreateInstance(assemblyName,
"MyVsaHost").Unwrap());
host.Run(args);
}catch (Exception e) {
//TODO: handle errors
}finally{
// Unload the remote AppDomain now that we're done with it.
if (appDomain != null)
AppDomain.Unload(appDomain);
}
}
}

public class MyVsaHost{
public void Run(){
//TODO: create a VSA engine and operate on it
}
}

netflow

Jul 19, 2004 at 1:05 PM

I won't claim to know much about what you guys are talking about but what I do know about is DB's and DB management, and I will tell you this, if it comes between MSsql or Mysql Postgres will take them both hands down any day of the week and twice on sundays.
If you are planning on ever having more than 100-200 concurrent connections to your DB then postgres is the only option as it handles concurrent connections so much more efficiently than any other DB it isn't even funny.

Integra

Jul 19, 2004 at 1:45 PM

Quote:
Original post by netflow
I won't claim to know much about what you guys are talking about but what I do know about is DB's and DB management, and I will tell you this, if it comes between MSsql or Mysql Postgres will take them both hands down any day of the week and twice on sundays.
If you are planning on ever having more than 100-200 concurrent connections to your DB then postgres is the only option as it handles concurrent connections so much more efficiently than any other DB it isn't even funny.

I would never use mySQL for obvious reasons, but I object to saying Postgres is a more competant DB than MS SQL. Both MS SQL and Postgres are amazing DB systems, but I would still rank MS SQL higher on an enterprise level, especially once you pass the 100GB mark.

There are pros and cons to both of those RDBMS packages.

hplus0603

Jul 19, 2004 at 1:58 PM

Why would you ever have 200 connections to your database? You're using an application server in front of the database, right? If not, well, there's no saving you :-)

We looked at a number of databases, and ended up with MySQL for performance and operational reasons. PGSQL was out of the running, because it doesn't currently spool roll-forward logs. This means that you can only ever restore the database to the point of your last consistent back-up; if you lose your table space, you can't restore the table space from backup and then roll forward to the point of crash using the logs.

That's a pretty major limitation for an online, high-availability transactional system!

Integra

Jul 19, 2004 at 6:42 PM

Quote:
Original post by hplus0603
Why would you ever have 200 connections to your database? You're using an application server in front of the database, right? If not, well, there's no saving you :-)

LOL I was actually going to say this myself but just figured there may be some wierd out of the way kind of application that would require this for some reason.

I really can't think of any sane reason to have 200 connections to a single RDBMS server though.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.