Scaling in games and virtual worlds

Link: Scaling in games and virtual worlds

This is an article written by someone who works on Sun's Project Darkstar.

Hiding threading and distribution is, in the general case, probably not a good idea (see http://research.sun.com/techrep/1994/abstract-29.html for a full argument). Game and world servers tend to follow a very restricted programming model, however, in which we believe we can hide both concurrency and distribution.

The linked paper is quite old. I haven't read it all yet, only the first page, but I've printed it out and thrown it on that stack on the floor just over there where there's things I found interesting enough to want to read and print out, but never quite find the time. The gist so far is that when you can refer to anything as an objects and you have remote applications you talk to, you tend to want to make calls to the remote applications just like calls to local objects. This is actually one of the idioms of Stackless Python which I appreciate the most.

The blocking which Stackless provides can transparently block the entire call stack (whether it contains Python, C code, C++ code or whatever) allowing you to wrap the use of asynchronous IO to allow microthreads to block waiting for their IO to complete while the others continue to run in the meantime. Now you could write your own custom API around the asynchronous IO your application uses, perhaps making it clear you're not really using a normal blocking socket. But that just results in you writing more complex code which is tied to that unique API - you're not just writing code, you're writing code with extra boilerplate.

When you can just use the same API provided for standard synchronous IO, then you can get on with the business of writing code with less complication. This then, comes back to the reference the article makes to the paper, that hiding threading and distribution is probably not a good idea. In the case of Stackless, it certainly isn't a good idea - you need to know where the blocking happens. You're writing logic to run as microthreads, if you pretend within each microthread that the others don't exist, you're denying that you're running within a framework and if you think it's going to work, you're in for a surprise.

I'd say that pretending the blocking isn't happening is definitely a bad idea. But making it possible to write remote calls just like local ones is a huge benefit as long as the person writing code understands the framework they are using. I should definitely read the whole paper and see what it actually has to say.

Measuring the performance of the system is made especially challenging by the lack of any clear notion of what the requirements of the target servers are. Game developers are notoriously secretive, and the notion of a characteristic load for a game or virtual world is not something that is well documented. We have some examples that have been written by the team or by people we know in the game world, but we cannot be sure that these are accurate reflections of what is being written by the industry.

Quite often I think about various implementational details of computer games. I visit dozens of forums, scanning what is being posted, doing searches, and can find no-one discussing anything related to them. If I post about them, there's rarely any response, and none with any insight. It's unfortunate.