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.

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

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.

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.)

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.

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.

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.

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%

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.

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.