The entire application layer would have to be converted - not just the sockets communication system. That is a big task, but not one that would be impossible.

The question should be asked, though, is why?

When I was at Slipgate working an MMO, our server was a Windows app. Engineers would create & launch the server on their own machine, then launch a client that connected to their local server. I can't speak to the technical reasons of why this was or was not a good architecture (I was on the client team), but it made our workflow MUCH better. For launch, I'm not sure what we would have done. We got canceled before getting that far.

What kind of game are you making? One reason to have a Windows server for things like FPS games is so that anyone who can run the game can also host or run a dedicated server. This is common in many peer-to-peer games.

-Rez

I'm going to chime in in favor of keeping the Linux server because I think Linux is cool. What you can do for local testing is just run a Linux VM inside of VirtualBox or similar and then run the server in that. However that does mean you'll have to debug server issues inside of Linux, so it might be easier to make a Windows server first, and then port it to Linux later after all the kinks are worked out.

Just my thoughts,
James

Originally posted by rickvanprim
I'm going to chime in in favor of keeping the Linux server because I think Linux is cool.

I feel like this isn't a valid reason for making a multi-million dollar decision, like which server tech to use for a game. Of course, if you're doing this just for the learning experience then by all means, go nuts. I've written a number of things I'd never actually use in a production environment just to help me learn.

What you can do for local testing is just run a Linux VM inside of VirtualBox or similar and then run the server in that.

No, running a server on a Linux VM is a terrible idea. On The Sims Medieval we had two different interpreters running the gameplay code. One was used for development and the other was used for the shipping product. The two builds behaved identically in about 90% of the cases, but those 10% were nightmares to deal with. You absolutely want to mimic your actual shipping product as closely as you can. Virtual boxes and emulators are not close enough to the real thing. There are two solutions to this problem: either every dev gets two machines (one for server and one for client), or everyone connects to the same server. Both have advantages and disadvantages and I've seen games do both.

Still, it really depends on the type of game you're making. If you're making a peer-to-peer game, there's no motivation to do this at all. If you're making an MMO or other server/client based game, this is something to consider.

However that does mean you'll have to debug server issues inside of Linux, so it might be easier to make a Windows server first, and then port it to Linux later after all the kinks are worked out.

Yes, if you're going with a Unix-based server, this is the way to do it. You create two build targets that only differ in their OS-specific calls (hopefully wrapped in an abstraction layer). You will likely have some Unix-specific issues to work out, but once the OS core layer is working, you probably won't have much trouble since the majority of the code is exactly the same.

-Rez

I think for starters a new build target, that does not touch any of the DirectX stuff and just includes boring WinAPI calls could be run with wine on your Linux server

For debugging on Linux, you can also attach GDB remotely and debug your server from a native Windows process, but yeah you're still using GDB and not your Visual Studio debugger. But maybe there's some integration of GDB into Visual Studio. It's at least wort to check it out

If you write your server to adhere to the POSIX standard, you could even get it to run natively on Windows. The newer Windows versions are fully POSIX-capable!

Choosing the platform for your server architecture is a big subject, and there are as many good reasons to choose Linux as there are to choose Windows. Enterprise operations outside of Microsoft probably lean more towards Linux. This has been historically true, because Linux machines were easier to set up and secure, and most hosting companies didn't want the extra expense of licensing Windows Servers or hiring Windows Certified IT Professionals alongside their Linux professionals.

That said, Windows is gaining ground is server architecture, but it is unlikely to become the top server architecture any time soon.

But, you aren't talking about an enterprise operation (at least not at first!). So, your choice has more to do with getting something up and running so you can prototype your game, rather than choosing one platform over the other.

I'd say clarify and focus on your goals, taking your skills into account, and let that direct your decision. If you want to try to create a game server architecture on Linux, then go for the port or choose an engine that already works on Linux! If you just want to play with MMO game architecture, it probably makes more sense to keep everything on one platform. So, if your client is going to be a Windows client, your server should be a Windows server to make your development experience a little less complicated. If you are already a complete badass in Windows and Linux, this won't be as important.

Later, once your game is running, you can always choose to swap platforms for the server if the business needs of your game require it.

Originally posted by rezination

What you can do for local testing is just run a Linux VM inside of VirtualBox or similar and then run the server in that.

No, running a server on a Linux VM is a terrible idea. On The Sims Medieval we had two different interpreters running the gameplay code. One was used for development and the other was used for the shipping product. The two builds behaved identically in about 90% of the cases, but those 10% were nightmares to deal with. You absolutely want to mimic your actual shipping product as closely as you can. Virtual boxes and emulators are not close enough to the real thing.
-Rez

I'm going to defend my VM statement by saying that I thought we were discussing a small scale project, not an enterprise set up. While I agree that there will certainly be some differences, I'm skeptical that those would cause much of a problem on a one-man team messing around with trying to make an MMO My comment was mainly just that if you want to write a Linux server app and iterate quickly on it, instead of having to deploy every new build to a remote server (even if remote just means other side of the room), then it might be easier just to run it locally on a VM. VirtualBox allows VMs to use shared folders, so it could be working off of the same source directory, and you could get VS to trigger a build.

That being said, and I'm sure Rez will pick this apart too, if you want to run it on your server (for all the reasons Rez cited) and still iterate quickly, then I propose the following: Set up a network file share on your Linux server, and then check your server code out there and on your developer machine. Then set up a Linux build target in Visual Studio, where you set the pre-build event to run xcopy to copy all modified source files over to the server's checked out code. There might be a better way than xcopy, I'm sure Rez will know. Next as your actual build step, have Visual Studio SSH in to your Linux server and run "make". Likewise you can set up Visual Studio to either restart your server app on successful builds, or just hook it up to the run command.

Hopefully that helps,
James

The funniest thing about this thread is we're sort of avoiding the original question - which was "how hard will this be" - I guess that was my fault.

Originally posted by Gaddam
LOL well from reading over each post the answer was: If your really good at programming it shouldn't be difficult, otherwise you may consider going with a windows based machine.

I'm going to go with a windows based solution to cut down on development time, lessen the burden, and just to keep the client/server setup the same.

Again, thank you each for replying!

Btw. you don't need to buy Windows Server to run a server application. You can use any Windows machine with a network connection and if you're running the server on your development machine you don't even need that. Although it can be useful to always test over a network connection, to get a feel for the latency.