Finally those academics are working with a real game. That ORTS thing was not at all representative of real RTSs.

The project treats game design as a math/science discovery problem where hypotheses must be created and tested via concrete games.

A related but more general question: When people talk of bits of infrastructure being connected or disconnected from the Internet, are they talking about the presence of direct, layer 3 connectivity (can I ping the airport's tracking systems?), any layer (if I hack the contracting company's intranet can I view aircraft positions through a series of proxies and application layers?) or actual electronic disconnection from the Internet (can you get only get in via getting your man on the inside the tweet the secrets from his cell)? Distributed infrastructural systems communicate Somehow...

Funny you mention that, I've already blurred all the maps. Enjoy: http://www.adamsmith.as/blurry_maps/

"Just come to the site and begin using the application."

That was the idea behind a techdemo/test game that a friend of mine and I made. AjaxWar, inspired by Wil Wright's SimWar, uses only javascipt on the client side to produce an N-players in N-games, bandwidth concious, non-polling, visually interesting (although most effects were disabled for the demo), robust, realtime strategy game. In the demo, the two browser windows are shown side by side but could have been behind NAT, firewall, proxies, etc on completely different networks than the server and each other. Oh, sorry, I know the demo requires flash (the real game required some modifications to php on the server side that we didn't want to make on a public web server).

Now, enough showing off. The thing we realized by the time we stopped working on the game is that doing things like making pretty multiplayer games with complex IO patterns is something thats really a lot easier, and more predictable using something like Flash or Java. It kinda felt like we were programming in a hostile atmosphere where you can't breathe without a helmet -- I mean can't get data pushed from the server unless you had a multipart encoded stream hanging in the ready. The latency was not bad at all, and neither was throughput of large chunks of data, however we reached a bottleneck when experimenting with several small updates in a short amount of time -- we couldn't reset our transfer mechanism fast enough to make something like an FPS viable at all. A majority of our time was spent expermenting with methods of moving data from the client to the server, politely, asynchronously, quickly, the actual gameplay was mostly an afterthought. While there aren't many web applications that demand the kind of IO we wanted, the pipe to the server is going to be a limiting factor for Ajax-ONLY type applications. Sure, you can use sockets in javascript if you require a certain browser and make the user click ok to a dialog, but if you have them doing that, you might as well have them install Flash. This issue of plumbing needs to be resolved before smart-client apps become ubiquitous.