Main Area and Open Discussion > Living Room

Best choice for server-side game programming

<< < (2/4) > >>

f0dder:
Traditional MUDs were done in C, which doesn't have OOP support; however, I wouldn't be surprised if their programming model was still OOPish, even without language support :)

mouser:
If you were going to build a large-scale multi-user project, i would certainly not rule out any language like .net even if it required a dedicated server.

The larger the scale of the project, the more speed might matter and the more important code organization matters.  You could develop it on your pc and only after it gets to a stable state then raise money to pay for a virtual or dedicated server where you can run whatever software you need to run.

kyrathaba:
That's true, Mouser.  Also, there are quite a few linux server packages out there in the $4 to $10 per month range that offer more than adequate server capabilities for the sort of application I'm envisioning (assuming that I develop in .NET and that Mono or whatever equivalent fully materializes).  And, it's more or less a pipedream at this stage:  my skill level is not yet quite adequate, I don't think (though I'm closing the gap, gradually).

BTW, what is the distinction between a virtual and a dedicated server?

mouser:
A dedicated server is a real computer.  DonationCoder.com website for example runs on a dedicated server.  Essentially it means your operating system is running on the pc, and ONLY your stuff is running on the computer.

A *virtual* private server means your have a complete operating system running on the computer, but in a virtual environment along with other people's virtual environments.  So, you have complete control over your operating system and all files, and it is very secure against other virtual users touching your files, BUTall the resources are shared between all virtual users - so it's significantly slower (and cheaper).

A VPS (virtual private server) could cost you $25-$100 a month.
A Dedicated server could cost you $100 to $500 or so.

tinjaw:
There are a couple of main issues bundled in there. Let me attempt to separate them out.

* Where the code is executed.
* Where the data is stored.
* What technology is used.
* Build from scratch or use an existing game engine.
Where the code is executed.
In order for Stuff & Things (TM) to happen, code needs to be executed. Code can run on the server, the client, or both.

* On the server: This is the traditional manner. This includes Server Side Includes (SSI) and Common Gateway Interface (CGI). This is commonly used when you want to use dynamically generated web pages instead of static web pages. The classic example is a phone directory. A web browser (client) contacts the web server (HTTP server) and requests a web page identified by a Uniform Resource Locator (URL). (Actually a URI, if you want to be technically correct.) With a static page, the names and telephone numbers are "hard coded" into the page and only change when the file is edited by the author. If SSI or CGI is used, the HTML file is processed by the HTTP server and the names and telephone numbers are dynamically added to the web page before it is sent to the browser. In this manner, the web (D/X/HTML) page does not need to be edited every time the list of names and telephone numbers is changed. In these cases all the web browser (client) does is use the HTML rendering engine to display the web (D/X/HTML) page. No code is executed on client computer. This also includes standard X/HTML forms. The client doesn't execute any code outside of the HTML engine. It just take the data entered into the form by the user and sends it back to the HTTP server.
* On the client: The classic example is a static web page that contains Javascript/Actionscript/ECMAscript. The HTML file on the server is static - it does not change, every time the page is requested by a client the same exact page is sent. (This make it a good candidate for a highly requested web page as it can be cached by the HTTP server in memory instead of it constantly accessing the slower hard drive and/or requiring processing.) With a static web page containing script, the HTML engine of the web browser hands of the scripting parts of the page to a separate engine.
Script should not be confused with (embedded) binary attachments like images, video, audio, or, more feature rich items like Flash. The former is (ascii/text, i.e. human-readable) computer code that is interpreted and executed in a manner similar to a standard computer application, while the later is the equivalent of a DVD, VHS or audio cassette tape being played by a player. This later form, the binary attachment, also include Java applets. Java applets are binary files containing "byte-code". You can think of byte code and something in between human-readable source code and the zeros and ones understood by the CPU. In this case the web page is just an envelope and the web browser is just a canvas. The applet is run in a virtual machine. It is oversimplifying to a large degree, but it might be helpful to think of virtual machines as tiny computers inside another computer.
* On both: By combining the two you can get something that often looks no different that a stand-alone computer software application. The most recent use of code executing on both the server and the client is Asynchronous JavaScript and XML (AJAX). AJAX uses a constantly open connection between the client and the server and code is executing on both sides. (For standard or "legacy" web pages, one or more connections are made to the server, the pages are downloaded, and all of the connections opened to the server are closed.)
One of the main advantages of this later use of technology allows the "software" to be updated constantly without any need for intervention by the user/client. This is because, although code is executed on the client computer, the code it executes is requested from, and delivered by, the web server. This means that the "software" can be updated on the server and the next time the client attempts to run the "software" it downloads the latest version from the server seamlessly. As computers get faster and as broadband Internet connections get fatter, it may soon become nearly impossible to the the difference between these web-based applications and traditional stand-alone software.
This is the end of part 1. Later today I will post more on : Where the data is stored. What technology is used. Build from scratch or use an existing game engine.

Navigation

[0] Message Index

[#] Next page

[*] Previous page