Brainstorming: Things to make RunUO Better
In order to facilitate some general discussion and thought, i'm creating this thread. If there's something you would like to see changed and/or added, post it here as well with your thoughts. generally, in order to be usefull remember that its best to post the "who, what, when, where, why, and how" behind your ideas as much as possible.
Keep in mind that the thoughts and proposals in this thread are intended as forward planning. Nothing mentioned should be regarded as "this should be done now!" kind of thing. Also, keep in mind that this discussion is about changing the current RunUO core. It is not about discussing or supporting "my ultra leet custom core", as Zippy would say.
so, to kick this off, here are some of my thoughts.
Main as a Windows Service
Keep in mind that I'm talking about a rewrite of Main.cs (and everything that supports it), which implements both ServiceBase and ServiceInstaller.
Two other items would also be required. the first is a custom EventLog to store RunUO events separately from other application eventlogs. The second, of course, is a separate "front end" application to read and view the server's EventLog(s) and provide other interface functions (ServiceController type application).
here's some of the advantages that I see to doing this:
Disadvantages include:
As you can see, there are some significant hurdles to doing this. however, I personally beleave that the ultimate payoff would be worth the time and effort.
Moving separate subsystems into there own space
using .net framework tools such as Application domains and the afore mentioned service structure, improvements and optimizations could be made which could include:
leveraging the Windows Service application model and AppDomains could possibly lead to some large performance gains and much improved security, in my opinion.
of couse, the same or similar disadvantages exist as above.
while significant time and effort in both development and user training exists in implementing all the above, some forward planning and good code practices could lead to a much better system as a whole. Basically, the thinking behind all of this is development of an "enterprise services" model program. If you adjust the view of RunUO as being a program that provides a emulation server to one that is simply a generic information server, as you read documentation regarding how to provide data services and communication you can start to visualize RunUO not as something programatically unique, but something very similar to what is widely available now in the windows world. Additionally, this view can lead to significant offloading of work onto the .net framework, which is running anyway. Leveraging the technology already provided by Microsoft, some savings could be realised in terms of lines of code and eventually even time updating or maintaining the code base.
A couple of less thought out ideas to leave you with:
Anyway, these are some admittedly "pie in the sky" proposals, but I figure it can't hurt to discuss them.
besides, as Zippy said, its disapointing how little discussion occurs in these forums.
In order to facilitate some general discussion and thought, i'm creating this thread. If there's something you would like to see changed and/or added, post it here as well with your thoughts. generally, in order to be usefull remember that its best to post the "who, what, when, where, why, and how" behind your ideas as much as possible.
Keep in mind that the thoughts and proposals in this thread are intended as forward planning. Nothing mentioned should be regarded as "this should be done now!" kind of thing. Also, keep in mind that this discussion is about changing the current RunUO core. It is not about discussing or supporting "my ultra leet custom core", as Zippy would say.
so, to kick this off, here are some of my thoughts.
Main as a Windows Service
Keep in mind that I'm talking about a rewrite of Main.cs (and everything that supports it), which implements both ServiceBase and ServiceInstaller.
Two other items would also be required. the first is a custom EventLog to store RunUO events separately from other application eventlogs. The second, of course, is a separate "front end" application to read and view the server's EventLog(s) and provide other interface functions (ServiceController type application).
here's some of the advantages that I see to doing this:
- Windows services are designed to be run continuously.
- Runs in a separate Windows Station. (lends stability. noone needs to login to the server to controll the service)
- Runs within its own security context. (plus, noone needs to login)
- no inherant interface = less resources. (should be anyway, even though the console really doesn't require much)
- Control. developing RunUO as a Windows Service allows separation of the functions performed by the program. subsystems could be implemented as separate services that run concurrently for one thing. further optimizations can be made with other .net framework tools (see below).
Disadvantages include:
- rewriting a large protion of some of the most basic code.
- a requirement to develop at least a basic interface as a separate program.
- larger "learning curve" for folks to install and use RunUO.
As you can see, there are some significant hurdles to doing this. however, I personally beleave that the ultimate payoff would be worth the time and effort.
Moving separate subsystems into there own space
using .net framework tools such as Application domains and the afore mentioned service structure, improvements and optimizations could be made which could include:
- improved stability. a single portion could be controlled individually. world saves, for instance, could be separated into its own process which could be started, stopped, paused, and adjusted on the fly without taking down the whole server. Of course, nothing can make a server 'crash proof', and failures in one subservice could of course still take an entire server offline. However, logical separations of functions could reduce these occurances to the bare minimum.
- performance. the inherant threading involved with running subsystems within their own processes sould improve performance in and of itself. however, having things somewhat separated could also lend itself to threading optimizations even further. having less syncronious operations to worry about should expose opertumities for threading.
- security. exposing only the portions of the server required to facilitate communication will improve security in and of itself. the ports and application domains required for logins, administration, web services, etc... could all be separated.
leveraging the Windows Service application model and AppDomains could possibly lead to some large performance gains and much improved security, in my opinion.
of couse, the same or similar disadvantages exist as above.
while significant time and effort in both development and user training exists in implementing all the above, some forward planning and good code practices could lead to a much better system as a whole. Basically, the thinking behind all of this is development of an "enterprise services" model program. If you adjust the view of RunUO as being a program that provides a emulation server to one that is simply a generic information server, as you read documentation regarding how to provide data services and communication you can start to visualize RunUO not as something programatically unique, but something very similar to what is widely available now in the windows world. Additionally, this view can lead to significant offloading of work onto the .net framework, which is running anyway. Leveraging the technology already provided by Microsoft, some savings could be realised in terms of lines of code and eventually even time updating or maintaining the code base.
A couple of less thought out ideas to leave you with:
- getting rid of world saves. moving the serialization engine to its own application space and a concurrent Service, world saves could possibly become continuous.
- World state: spawners and things such as quest systems behavior could be similarly offloaded. possibly, this could improve stability and performance, but more importantly control could be improved.
- interface. while having a separate program for interfacing with the server would be a pain to develop and maintain, it logically follows that much of the administrative duties could be offloaded from the UO client. separating the administrative functions from the client could also improve seurity.
- imagine the possibility of vastly improved web services, and perhaps if someone has the time and imagination, such additions as voice communications or IRC servers, UOAM type subsystems, etc...
- scalability. actually separating functions into real subsystems should lend itself well to scal issues. the "size" of a server should really be limited only by the availability of resources (which, it is for the most part. i'm refering to optimizing, not critisizing whats been done already).
- CodeDom. I redily admit that I know next to nothing about it, but it appears to me to be possible to move the server compiler to a CodeDom model, meaning MSIL code as well as support for Java and C++ in addition to the currently supported C# and VB? perhaps this could lead to a better definition of what a "script" is as compared to base application programming.
Anyway, these are some admittedly "pie in the sky" proposals, but I figure it can't hurt to discuss them.
besides, as Zippy said, its disapointing how little discussion occurs in these forums.