IBM Testing New Grid Technology with Quake 2

boschmorden writes "In conjunction with IBM, a group of college students from the University of Wisconsin developed GameGrid, a derivative of IBM's OptimalGrid effort. The students adapted the open-source version of id Software's Quake 2 first-person shooter, and attempted to scale it across the grid to stress the system." IBM is also planning on developing Quake 2 bots to take advantage of the system.

A Test? Riiiight.

[jpnews]

C'mon. I'm sure there are better ways to test the system. How about some complicated mathmatics? Why not just load up the chess software and let it analyze every possible move?

This is just the design team's wet dream. Not that I blame them, but c'mon- is it really news? Nerds like to play games??? Alert the press!

Re:IBM wants stress testing ?

[Gherald]

So you don't think hosting Slashdot itself takes more resources than hosting a site Slashdot links to?

I'll have some of whatever you are having.

Slasdot them

[Siener]

Seems like there main problem was that they did not get enough people connected simultaniosly to really put the system under any kind of stress. They should announce the next test on /. - I'm sure they'll get more than 80 users then.

Having trouble generating a load?

[Cooper_007]

At no time were there more than 80 players connected?

If that really was a problem they should've just hooked it up to the internet and put an invitation up on some game sites. Surely IBM can foot the bandwidth bill that would result from it.

Re:Acid test

[iainl]

Its because 63 'playerx died' messages each need to be sent to all 64 players. 63x64=4032

Personally, I'd be more concerned with the 63 loads of gibbed players the remaining one has to draw on screen at once, but there you go.

Re:Yes but

[kasperd]

How many fps were they getting ?

FPS are overrated. I once saw a person claiming he could tell the difference between 500 and 1000 FPS on a 100Hz monitor, yeah right. More FPS than your monitor can display is simply waste. When you can render enough FPS, the only improvement left to make is better timing. That requires help from the gfx hardware, nothing difficult though, the Amiga could do it 15-20 years ago or something like that.

Re:A Test? Riiiight.

[orb_fan]

This wouldn't test the system - the whole point, and unfortunately this was buried near the bottom of the article, is that the grid could repartition the map to ensure that no one node got swamped. The grid also has to move date between the nodes so that the game state was consistent between nodes - something that a chess analysis problem wouldn't need to do.

It might well be the case that this is a solution waiting for a problem.

Re:50 microseconds.. yeah!

[dago]

or just use google math [google.ch]

Well,

[way2trivial]

than hosting a site Slashdot links to?
in terms of actual pages served up? obviously slashdot serves more pages than it's membership goes off site to read

in terms of bytes? slashdot is rather low bandwidth-

99 %text NO photograph complex jpgs.. no avi's or mpegs..

it's quite possible that /. server does not have requirements nearly as intense as some sites that /. manages to swamp

Re:Acid test

[Boing]

So what? Lets say that the death message is "[DC]_-Oob3rL33tS7ud-_ got a hole in the head". That's 44 bytes, assuming ASCII. Let's also assume that each death message is the same length, for simplicity's sake.

Server: 4032 x 44 = 177408 = 173.25k that has to be sent out in a timely manner ("instantaneously" is a bit misleading). That's a lot to have to transmit quickly, but any server running on a decent pipeline should be able to manage it in 5 seconds or so.

Clients: 63 x 44 = 2772 = 2.7k. Even 56k modems can get this in no time.

I know there's a lot of other crap being sent over the line, but the worst that scenario should mean would be a few seconds of lag in the game while the server got back up to speed. What would really kill everything would be trying to model all of the gibs' physics all of a sudden, while simultaneously adding newly spawned players with new weapons.

Re:Yes but

[CaseyB]

When you can render enough FPS, the only improvement left to make...

Right, because we will never want better image quality than Quake 2.

... is better timing. That requires help from the gfx hardware, nothing difficult though, the Amiga could do it 15-20 years ago or something like that.

Timing? Yeah, it's called vertical synchronization and double or triple buffering, and every graphics card in existence has it.

Shared-world development?

[Selanit]

The article says:

GameGrid dynamically partitions areas of the game map, including players and objects, onto different servers. If a player or object, such as a rocket, moves from one server to another, the first server sends the player's state--the player's name, vector, velocity, and statistics--from one server to the next. [. . .] Even if a player isn't physically "on" a server, he must still be able to "see" objects stored on another. The Quake code determines the state of the world every tenth of a second, Bethencourt said.

Could this (or something like it) be used in a user-constructed world? I'm thinking of Active Worlds [activeworlds.com] and similar sorts of software, where people log in, and can then alter the landscape or build things using pre-defined shapes and textures. Kind of like Legos, only you can't step on 'em in the dark.

Anyway, would it be feasible to run such a thing using a grid? Currently, the size of such a shared world is limited by the power of the server on which it is hosted. Alphaworld, [activeworlds.com] the largest world in the Active Worlds universe, is only about the size of California. But if you were using a grid, you could then theoretically expand the world by adding more nodes to handle more real estate. (Or virtual estate, rather.)

If you could find a situation with low enough latency, individuals could even provide their own nodes, adding new territory to the fringes of an existing world. Neaaaat.

Re:IBM wants stress testing ?

[GT_Alias]

I'm not sure web serving would ideally test this (I know it's a joke...I'm just wondering about this...). The article mentioned how the software would load balance the servers in the case of something happening like all of the players gathering in one corner of the map. Whereas in a typical system this might overload the server that was responsible for that portion of the map, the software would now spread out the load so that several of the servers would divide up the load for the one part of the map.

Seems to me that web serving would stay pretty balanced...no ONE server would suddenly have a spike over all the others, assuming the front-end load balancing was just cycling through the servers with each incoming request.