Austin GDC made it apparent that where I work is not a well-kept secret - still, I'm obligated to not say anything just yet. We still don't have office space, but I've been looking into some of the decisions we'll need to make early on for server technology.
My impression, at this point, is that MMO servers are about 50/50 split between Windows and Linux. I certainly know of games, both live and in development, that have used both. Would folks who read the blog like to weigh in with their opinions on this?
One strong advantage to using a Windows-based server is how easy it is to do all of your development on a single machine. Run the database server, game server, game client, and any ancillary processes all on the same machine. With just 1-2 players, all the running services together shouldn't significantly strain a modern desktop.
I have mixed feelings about another argument that Halldor Guðjónsson made in his talk at AGDC on the server technology of EVE Online: buying all your technology from one vendor prevents all your various vendors from pointing to the left when you have a problem. That makes a certain amount of sense, but first you have to pay for support contracts on everything from the vendor, and then you have to have problems that rely on those support contracts for resolution. I don't think I ever saw that come up while working at NCsoft... it was always our own database/network/system administrators fixing problems. Investing in your own team's expertise that way makes a lot more sense to me when fixing problems on the server side (whether systems, database, or network problems) are so critical to your business.
A better argument presented by Guðjónsson - and this one implicit in his demos, rather than stated outright - was that managing the servers consisted of mostly talking HTTP to the game server processes themselves, and interacting with their built-in management interface. That requires the same investment regardless of platform, and overall looked like an excellent way of doing things. On the other hand, starting with a Unix platform means (again, IMO) that more management tools are available immediately, for integration with your own server, rather than needing to be developed from scratch.
Right now I'm investigating whether VMWare would be an adequate development solution. Performance is a particular concern, but also how easily I could make the normal management steps used during development (start, stop, reload data, verify data, etc.) straight-forward for our non-Linux staff. I think that would really have a huge impact on the viability of a Linux (or FreeBSD, or Solaris) server platform: how well it could be integrated into the independent iteration cycles of all programmers, designers, and artists.
Saturday, September 20. 2008
server platforms
Sunday, September 14. 2008
Still no details
I was kind of hoping to have more to say this week, since I'll be attending Austin GDC and talking to a lot of people. I don't much like being the one who can't talk about what he's doing, but it happens.
On the other hand, I'm really looking forward to the conference, there are some really good talks scheduled.
On the other hand, I'm really looking forward to the conference, there are some really good talks scheduled.
Monday, September 8. 2008
Hot damn
I'm in the process of accepting a job offer. I'd rather not discuss the details just yet, but I'm pretty excited. Stay tuned for details...
Tuesday, September 2. 2008
back from PAX
I've been a very busy bee, but now I'm back from PAX and relaxing a little bit. Feeling pretty good. :-) I'll have more to say later...
Thursday, August 21. 2008
Great article on C++0x
Per Slashdot, an interview with Bjarne Stroustrup. He's always an interesting read, and there's quite a bit of meat in the article that has me interested.
Of course, C++0x ("...it's touch and go whether C++0x will be C++09..." he says) won't be out and available in compilers for some time, but once it does... my impression is that a lot of the new syntactic sugar constitutes compile-time checks that won't really affect run-time performance. With IncrediBuild and distcc to distribute compilation and reduce build times, it's naturally time to start adding more work for the compiler to do.
I'm not so sure about the concurrency/threading support being added. There's a lot of pre-existing code, APIs, and kernel-level interfaces that will need to be adapted, and most of it simply won't. At a guess, I won't get to work with the concurrency stuff for another five years (I guess that means I'm optimistic that there will be C++0x implementations out in less than five years).
Of course, C++0x ("...it's touch and go whether C++0x will be C++09..." he says) won't be out and available in compilers for some time, but once it does... my impression is that a lot of the new syntactic sugar constitutes compile-time checks that won't really affect run-time performance. With IncrediBuild and distcc to distribute compilation and reduce build times, it's naturally time to start adding more work for the compiler to do.
I'm not so sure about the concurrency/threading support being added. There's a lot of pre-existing code, APIs, and kernel-level interfaces that will need to be adapted, and most of it simply won't. At a guess, I won't get to work with the concurrency stuff for another five years (I guess that means I'm optimistic that there will be C++0x implementations out in less than five years).
previous page

