Console or Windows App?
Author
Hey, I'm working on a C# Server for my ORPG.
Preferably, for working with the server, I would like a windows application.
Would a console application save enough space/memory that I should use it over a windows app?
console vs gui barely makes a difference on modern computers. It's what's going on behind the scenes that causes slow-down.
It's a sensible idea to not burn any bridges as far as portability is concerned. If you need to migrate to linux later, ensuring your gui / platform-specific app is wrapped neatly (and separate from the bulk of your application code) will save you masses of time and stress later.
This all depends on how you intend to administer the game - if you need it to sit on a remote server doing it's thing, you may want to look at implementing a remote administration system (with the gui on that, or a platform specific admin client) rather than embedding the gui in the server itself. If it's a home-hosted server, then the gui can be shipped with the server, but I'd still recommend making it effectively a separate beast that talks either to the server process (a local client of it) or operates in a separate thread and communicates with the server in an 'indirect' way (like through a subscriber pattern).
This all depends on how you intend to administer the game - if you need it to sit on a remote server doing it's thing, you may want to look at implementing a remote administration system (with the gui on that, or a platform specific admin client) rather than embedding the gui in the server itself. If it's a home-hosted server, then the gui can be shipped with the server, but I'd still recommend making it effectively a separate beast that talks either to the server process (a local client of it) or operates in a separate thread and communicates with the server in an 'indirect' way (like through a subscriber pattern).
C# GUI is portable, though – it's included in Mono. But I still second the point that a GUI should just be a way of accessing the 'real' code, and not be all mixed up with it. (I.e., event handlers and other GUI code shouldn't do any computation beyond that required to transform data to/from a displayable form, and so on.) In C# this is easy as you make your engine one class (or set of classes) and use that from the GUI.
And in response to the original question: no. The entire Framework is probably loaded into memory anyway, and consoles aren't really any cheaper than a GUI.
And in response to the original question: no. The entire Framework is probably loaded into memory anyway, and consoles aren't really any cheaper than a GUI.
It doesn't make much sense to make a server app with a GUI to me. Probably the biggest reason is that it's just a lot simpler to use a text-based console as one of your logging targets then it is to build a text output library to support that sort of thing in a GUI app.
Another reason is that you probably will want to be able to control your server remotely and you will need some sort of GUI app to do that which talks to the server via some dedicated admin channel. Since this app is seperate from your server already there's no point in building a second GUI directly into the server itself.
A third reason is that on Windows in a production environment your server will probably run as a service and services are very restricted when it comes to putting up GUI.
Another reason is that you probably will want to be able to control your server remotely and you will need some sort of GUI app to do that which talks to the server via some dedicated admin channel. Since this app is seperate from your server already there's no point in building a second GUI directly into the server itself.
A third reason is that on Windows in a production environment your server will probably run as a service and services are very restricted when it comes to putting up GUI.
Author
Thanks, I totally overlooked the fact that I might need remote admin later.
So do I just make a framework around the packets recieved from the real server?
For instance, a button on my remote GUI will send a packet that will be run by the console of the real server?
So do I just make a framework around the packets recieved from the real server?
For instance, a button on my remote GUI will send a packet that will be run by the console of the real server?
what exactly are you trying to do? a remote admin type thing for your server?
if so, i would just use all settings and variables stored in an sql table(s). then you can throw togeather an ASP.NET app (or whatever) which allows you to adjust those settings. this method has many advantages primarily being easily adjustable settings and a user friendly interface so you can have admins of your game use it as well.
if so, i would just use all settings and variables stored in an sql table(s). then you can throw togeather an ASP.NET app (or whatever) which allows you to adjust those settings. this method has many advantages primarily being easily adjustable settings and a user friendly interface so you can have admins of your game use it as well.
I would completely seperate the server from the management system, other then perhaps base configuration via a prefered storage medium such as XML. In almost EVERY case you want remote administration of some sort, so you want a special client to handle this. If the client is also being done in C#, you can have a base class which handles all of the potential messages to send to the server, and then have a class derived from it which contains static functions invoking delegates and an event system which diagnoses responses and divides them into particular events which you can connect gracefully into any gui immaginable.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
