First, I'm glad to see that people are using .NET framework to build a MUD environment. I've started my own project, though I only work on it on my free time...which is very sparce.
I do have a couple questions.
Do you have an overall design document that outlines your goals, motives, features, etc?
Do you have technical goals? How many users? Distributed systems?
Do you intend on compiling game assests and loading the DLL's into the environment...or do you favor .cs source that is compiled dynamically...much like LPMud drivers?
All of my efforts thus far have been in the core server itself. Netcode, distributed computing, telnet server, etc.
Anywys, I look forward to seeing updates on the forums!
Eric
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I took a peek at your source and came across your Core.Dynamics.Scripting code...answers my questions regarding source vs pre-compiled assemblies.
I had built a prototype that was very very similar...however the potential number of assemblies compiled could be pretty daunting. Also, the fact that you cannot unload an assembly from an AppDomain once compiled made dynamic updates problematic. I then considered managing AppDomains but I didn't want to have to pay the overhead. Have you come across similar issues?
There was also a complexity of referencing one dynamic type to another.
Given: Building a type "GenericStoreFront" through source...then later building type "Bakery" which inherits "GenericStoreFront".
To be able to do this added a degree of complexity that made me question the entire framework.
Anyways, I've since abandoned runtime compilation to work on core server functionality.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I don't have any design documents. Thats my biggest shortcoming when it comes to programming - no overall plan. However, I manage to work through, at least on my own.
Technical goals? Well, not in so many words. I want it to be practical - the number of online users it can handle needs to be flexible. "Distributed systems?"
But I'm glad to see someone else has addressed making a MUD server in .NET! Excellent! (Be sure to check out WheelMUD - www.WheelMUD.org).
Yes, the code does answer a certain number of questions. As the code shows, I'm going after an interchangeable format where a person can use compiled or uncompiled code as a plugin.
Wow! I didn't know that much about the script compiling posed such problems! I haven't been able to test it in a practical environment, so I had not yet encountered not being able to remove the loaded assembly, and I have yet to have done any work with AppDomains. So, to answer your question, I have not come across these issues. However, I am grateful that you have caused me to address these sooner rather than later.
Frankly, I had intended to avoid referencing one dynamic type in another. I hadn't intended on my system using dynamics for things so trivial as shop types - mainly just commands and skills and subsystems. Basically things and tasks that are self contained.
However, you've expressed some ingenuity by having "Bakery" inherit from "GenericStoreFront". You can still do this, just make it static. Especially if your server is open source, this won't be a problem.
Well, nice hearing from you Eric. Stick around, and don't be afraid to stick your nose in some more. And if you have a public web presence for your project, post a link - I wouldn't mind taking a look.
-Bruce
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For distributed systems, it's my feeling that one server imposes far too many limitations. So, the topology that I have worked on is based on 3 server types, supporting as much hardware as I want to throw at it.
GateWay server. This handles TCP over the internet. Handles up front security, and is considered to be in the DMZ and completely wide open.
World server. This handles what you would normally consider in a typical mud. Game assets, isntances, etc. These servers are considered a grid and managed through a command/message channel over multicast. These are intended to be connected via lan.
Logic server. Here you have static daemons running exposed on remoting-like endpoints. Here you would have global weather services...global economics services...global chat channel services etc.
You scale out each machine type as neccessary and can theoretically have as much CPU to handle as many users as you want.
There are some major obstacles to overcome...but I have the majority of the issues figured out.
Anyways, I'll check back up on these forums often to see how things are going. If you have a technical issue that you want advise or at least want another perspective on, email me through sourceforge or just post here. I do have about 2.5 years of very grueling heads down systems work in c#...so I may have some experience that you could use.
-Eric
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I agree. .NET is great, but a full featured MUD server is too much for one machine.
However, in the scope of ClexusMUD - it might be possible to use the distributed systems methodology, via remoting, to host each of ClexusMUD's "subsystems" on seperate machines as neccesary. This is really exciting to think and talk about, but its quite a ways off of the beaten path of making a functional MUD server. But I now plan on delving into this later.
I, personally, have only been doing C# seriously for about 6 months.
-Bruce
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there!
First, I'm glad to see that people are using .NET framework to build a MUD environment. I've started my own project, though I only work on it on my free time...which is very sparce.
I do have a couple questions.
Do you have an overall design document that outlines your goals, motives, features, etc?
Do you have technical goals? How many users? Distributed systems?
Do you intend on compiling game assests and loading the DLL's into the environment...or do you favor .cs source that is compiled dynamically...much like LPMud drivers?
All of my efforts thus far have been in the core server itself. Netcode, distributed computing, telnet server, etc.
Anywys, I look forward to seeing updates on the forums!
Eric
I took a peek at your source and came across your Core.Dynamics.Scripting code...answers my questions regarding source vs pre-compiled assemblies.
I had built a prototype that was very very similar...however the potential number of assemblies compiled could be pretty daunting. Also, the fact that you cannot unload an assembly from an AppDomain once compiled made dynamic updates problematic. I then considered managing AppDomains but I didn't want to have to pay the overhead. Have you come across similar issues?
There was also a complexity of referencing one dynamic type to another.
Given: Building a type "GenericStoreFront" through source...then later building type "Bakery" which inherits "GenericStoreFront".
To be able to do this added a degree of complexity that made me question the entire framework.
Anyways, I've since abandoned runtime compilation to work on core server functionality.
Wow! Such technical insight!
Sorry, I don't have any design documents. Thats my biggest shortcoming when it comes to programming - no overall plan. However, I manage to work through, at least on my own.
Technical goals? Well, not in so many words. I want it to be practical - the number of online users it can handle needs to be flexible. "Distributed systems?"
But I'm glad to see someone else has addressed making a MUD server in .NET! Excellent! (Be sure to check out WheelMUD - www.WheelMUD.org).
Yes, the code does answer a certain number of questions. As the code shows, I'm going after an interchangeable format where a person can use compiled or uncompiled code as a plugin.
Wow! I didn't know that much about the script compiling posed such problems! I haven't been able to test it in a practical environment, so I had not yet encountered not being able to remove the loaded assembly, and I have yet to have done any work with AppDomains. So, to answer your question, I have not come across these issues. However, I am grateful that you have caused me to address these sooner rather than later.
Frankly, I had intended to avoid referencing one dynamic type in another. I hadn't intended on my system using dynamics for things so trivial as shop types - mainly just commands and skills and subsystems. Basically things and tasks that are self contained.
However, you've expressed some ingenuity by having "Bakery" inherit from "GenericStoreFront". You can still do this, just make it static. Especially if your server is open source, this won't be a problem.
Well, nice hearing from you Eric. Stick around, and don't be afraid to stick your nose in some more. And if you have a public web presence for your project, post a link - I wouldn't mind taking a look.
-Bruce
Thanks for the response!
For distributed systems, it's my feeling that one server imposes far too many limitations. So, the topology that I have worked on is based on 3 server types, supporting as much hardware as I want to throw at it.
GateWay server. This handles TCP over the internet. Handles up front security, and is considered to be in the DMZ and completely wide open.
World server. This handles what you would normally consider in a typical mud. Game assets, isntances, etc. These servers are considered a grid and managed through a command/message channel over multicast. These are intended to be connected via lan.
Logic server. Here you have static daemons running exposed on remoting-like endpoints. Here you would have global weather services...global economics services...global chat channel services etc.
You scale out each machine type as neccessary and can theoretically have as much CPU to handle as many users as you want.
There are some major obstacles to overcome...but I have the majority of the issues figured out.
Anyways, I'll check back up on these forums often to see how things are going. If you have a technical issue that you want advise or at least want another perspective on, email me through sourceforge or just post here. I do have about 2.5 years of very grueling heads down systems work in c#...so I may have some experience that you could use.
-Eric
Yes, I agree. .NET is great, but a full featured MUD server is too much for one machine.
However, in the scope of ClexusMUD - it might be possible to use the distributed systems methodology, via remoting, to host each of ClexusMUD's "subsystems" on seperate machines as neccesary. This is really exciting to think and talk about, but its quite a ways off of the beaten path of making a functional MUD server. But I now plan on delving into this later.
I, personally, have only been doing C# seriously for about 6 months.
-Bruce