Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
IBM First Person Shooters (Games) Quake Entertainment Games

IBM Testing New Grid Technology with Quake 2 188

Posted by CowboyNeal
from the advances-in-fragging-technology dept.
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.
This discussion has been archived. No new comments can be posted.

IBM Testing New Grid Technology with Quake 2

Comments Filter:
  • Can you? (Score:5, Funny)

    by Surak (18578) * <(moc.skcolbliam) (ta) (karus)> on Friday August 22, 2003 @07:05AM (#6763680) Homepage Journal
    Can you imagine .... oh wait, those Beowulf jokes are WAYYY outdated aren't they? Can you imagine if we had a GRID of those? :)
  • by Rosco P. Coltrane (209368) on Friday August 22, 2003 @07:06AM (#6763688)
    IBM Corp. has begun a real-world test of its grid-computing system by turning to a familiar geek pastime: games.

    I'd have hosted Slashdot instead. Or updates.microsoft.com.
  • If you design an AI bot, and let it loose in a system like a Q2 game running on a set of nodes, do you have the right to arbitrarily shut it down? At what point do you have a responsibility to the code that you spawned (a Q2 pun, work with me)?
    As Dr. Chandra said in 2010, we're all life forms, whether silicon or carbon based it makes no difference.
  • by Trigun (685027) <evil AT evilempire DOT ath DOT cx> on Friday August 22, 2003 @07:07AM (#6763694)
    Giant blue gorillas with six million hit points, deadly accuracy, and are backed by a legion of undead lawyers.
  • by lingqi (577227) on Friday August 22, 2003 @07:07AM (#6763695) Journal
    bots that runs on distributed clusters, designed to take out humans in a simulated environment... hmmmm

    if we arm them (the programs) with paintball guns we can do simulated battles from the terminator universe.

    or until they get a hold of some real firepower and this becomes a real version of the terminator universe...

    Either way I for one look forward to a beowulf cluster of these steel and wire overlords, yeah?
    • Either way I for one look forward to a beowulf cluster of these steel and wire overlords, yeah?


      As a trusted Slashdot-personality I can help them with rounding up others to toil in their CPU-fabs.
  • Yes but (Score:5, Funny)

    by Salsaman (141471) on Friday August 22, 2003 @07:10AM (#6763706) Homepage
    they forgot the most important question of all:

    How many fps were they getting ?

    • Re:Yes but (Score:2, Insightful)

      by kasperd (592156)
      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:Yes but (Score:3, Insightful)

        by CaseyB (1105)
        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.

  • by jackb_guppy (204733) on Friday August 22, 2003 @07:11AM (#6763711)
    I know of large company that install quake servers 6 years ago to help balance 3 T3 lines. The quake servers (w/ players) gave a continous load that was easy to define and route, which helped in supporting a very large website.
  • 80 Users stress the system? 80 isn't really alot of users, especially since they are talking about implementing the technology for MMORPGs.
    • Re:80 Users (Score:3, Funny)

      by Trigun (685027)
      80 normal users don't stress the system, but 80 l337 |-|4>0rZ armed with the latest aimbot technology, scraming "I h8 K4mP3rz! D347h 2 4ll, \/\/3 4r3 1337!" would stress even the most well constructed system.
      • It might also result in:

        1) The cluster committing suicide hoping that the next level of existence doesn't have 1337 |-|4>0rZ

        or

        2) Realize it is better for us, and well you know, go skynet on our weak flesh hides.
    • heh, I had 72 Q2 bots running on one machine to form a crowd... It runs in real-time, albeit slowly!

      The problem with Q2 for a stress test is that it has hard coded limits for players and entities. Changing these values means the entire protocol has to be redesigned... So, in effect, you can't get more than 80 bots without a lot of work!

      Maybe they should have chosen an Open Source MMOG engine like NeL?
  • by jdreed1024 (443938) on Friday August 22, 2003 @07:14AM (#6763725)
    Bah, they had game grids back in 1982 [imdb.com]. I bet IBM's version doesn't have lightcycles, either. Yeesh, get with the times, IBM...
  • Acid test (Score:5, Interesting)

    by Zog The Undeniable (632031) on Friday August 22, 2003 @07:14AM (#6763728)
    Line all the players up and have one of them fire a railgun through the remainder [1]. Allegedly someone tried this at a LAN with 64 players and the server crashed. The problem is that the server has to send 4,032 death messages instantaneously. With 250 players it would have to do 62,250.

    [1] for the uninitiated, a Quake 2 railgun slug keeps going through any number of targets until it hits a wall or other part of the scenery.

    • Re:Acid test (Score:2, Interesting)

      by llamalicious (448215)
      Easier, you want to lag the thing?

      Setup a server and don't limit the number of projectiles used by the hyperblaster.

      Give every player an HB and unlimited ammo. Tell them to run around shooting those all over... that'll lag the grid.

      Of course, some of that is bandwidth driven... but, a good test nonetheless.
    • Re:Acid test (Score:1, Interesting)

      by Anonymous Coward
      Yes I can report we did this at Auckmageddon 2 with more than 64 people. Custom map was made and one person tried to line up everyone else and blast them. We used a railgun, which crashed the server (a dual p266!) and then using the BFG we crashed the server a few more times.

      We also managed to run a deathmatch with 123 people in it... had to write a quick and dirty mod to reduce gibs and a few other details but the server still crashed eventually.

      Would be much easier with today's beefier hardware.
    • Re:Acid test (Score:3, Insightful)

      by Boing (111813)
      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

      • Two possibilities:

        Quake 2 uses UDP packets, not TCP, so there is no assured delivery - perhaps it's a state issue.

        What it probably does is overload the outbound buffer on the server though, most events don't come all at once.
  • Someone please give me a quad damage so I can unload on our AIX boxes the way I've always dreamed.
  • Sounded good, until I got to this bit:

    When doing so, IBM's GameGrid software typically operated with latencies of 50 microseconds or less, according to Hammer.

    I hope thats a typo..

    • It's not a typo. 1 microsec = 1/1000th milisec, and 50 microsec response time is way fast enough, if the number is anything but pure theory in an optimized scenario.
    • When doing so, IBM's GameGrid software typically operated with latencies of 50 microseconds or less, according to Hammer.

      I hope thats a typo..

      Why? A microsecond is a millionth of a second [essex1.com], fifty should't be that long :)
    • Yes, that's a typo. We said 50 milliseconds. 50 us is ludicrous if you understand what is happening. 50 ms is actually pretty decent though. Quake II only generates server frames every 100 ms, so if the transfer occurs between them, it's essentially perfect.

      John Bethencourt (one of the developers of GameGrid)
      • I take it the whole setup was these 8 servers with the gamers connecting to them through ethernet? Or did they remotely connect?

        Also, how are the bots handles? If they move to another sector, is the AI handed off to that server too? Or is that what's being re-written in the bot code?
  • So we run a grid of computers (or Playstation 3's?) with Quake 2, but on a monitor? nooo... it needs to go on a CAVE [deltasearchlabs.com]
  • UDP/TCP (Score:5, Informative)

    by Zog The Undeniable (632031) on Friday August 22, 2003 @07:23AM (#6763781)
    Quake and all its descendants use UDP. While this is faster than TCP, packets are inevitably lost but the game is designed to cope with this - it just picks up player positions again from the next packet that arrives, which occasionally gives jerky play (the impression to the player is of a very high ping).

    Data-critical processes - that's most real-world applications - have to use TCP to ensure completeness of transmission, so maybe this isn't the best test for the grid?

    • Interesting and shameless plug:

      SCTP is another transport protocol that is in the works. It allows for multiple streams of data between multihomed computers. The streams may be in order or out of order which allows for related data to be transported reliably without head of line blocking. If a strictly ordered stream is necessary, that may be bundled in with the out of order streams.

      Quite a nifty protocol. Quite beast to try and write [sourceforge.net] ;-). It might make the grid more easily usable in many situations

    • Keep in mind that the "grid" tech is for server/server communications, not communications with the game clients, which could still be TCP (although highly unlikely, since clustering ALSO requires low latency.)

      I would not be surprised if most clustering technologies use UDP with something above it to handle the possibilities of loss, since they rely so much on low-latency communications.
      • Most current games also use some retransmission while still using UDP, as well. The key is that you have much more control over the overhead if you build your own retransmission protocol in UDP packets than if you let TCP do it for you.
    • The article mentioned that IBM was looking into multi-media applicaitons. UDP is just fine for this. With VoIP or other streaming-type apps, you don't really want a completely loss-less protocol. UDP, without the error detection/correction overhead of TCP is fast, but lossy.

      Using TCP would create skips and delays while the packets were re-transmitted. In a real-time app, you want (subjective) game time to keep on going, even if you drop a few packets.

      The same priciple goes for videoconferencing and

  • by Anonymous Coward
    As the article said (yes, I actualy had read it) IBM is exploring new consumer markets for their GRID tecnology... Gaming is BIG MONEY, and IBM is just taking their shot at it, too bad GRID systems are too expensive to be sold as video-game consoles!

    Now, forget Quake2 and imagine this system running Battlefield 1942!! I already can see the Omaha Beach Battle with 500 players online, that's would be awesome!
  • Slasdot them (Score:4, Insightful)

    by Siener (139990) on Friday August 22, 2003 @07:29AM (#6763818) Homepage
    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.
  • From the team that brought you Deep Blue [ibm.com], now comes the ultimate challenge, Deep Bot.

    Come on. If they are even going to do it as a sort of pet project IBM seems to have an abudance of geeks doing oddbal stuff for this to become one lethal bot.

    In other related news IBM invested 2 billion dollars in cybernetic research.

    In yet other future news McBride is kinda puzzeled why his house seems to be surrounded by skiny blue robots.

  • 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.

  • by vgaphil (449000) on Friday August 22, 2003 @08:00AM (#6763992)
    IBM is also planning on developing Quake 2 bots to take advantage of the system

    Dont't they mean "agents".

    "The Internet is a fad" -WB
    • While this whole thing is cool, what pisses me off is that the interns are developing the bots. When I interned with IBM back in the summer of '97, they had me converting text manuals from DocBook to SGML for IBM Japan. The script they had to do it needed a lot of tweaking and guess who got to be the tweaker/tester? Blech. I wish I had heard on the first day "Well, Patrick, this isn't going to be a fun summer I'm afraid. We need you to write a bot for Quake II. Probably not as fun as scrolling through inval
      • Ah, that's because Extreme Blue [ibm.com] wasn't around back then. They try very hard to get interesting projects for teams of four interns (three technical and one mba student) to work on during the summer. The mentors of each project hand pick the students working for them and are good at providing feedback during the whole summer.

        Also, not all the projects are as exciting as Game Grid. For example, I was working a few cubicles down from the Game Grid guys on a project for automatically generating high level U
  • by Anonymous Coward
    Quake II was ported to .NET!

    http://www.vertigosoftware.com/Quake2.htm
    or
    h ttp://msdn.microsoft.com/visualc/quake/
  • 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.
  • All we need now is for some people to design better man-machine interfaces, like a direct connect into the spinal cord. And let's have those AI programmers show their metal by making some wickedly smart bots.

    Certainly it would become boring killing people ad-infinitum, so I imagine it's just a matter of time before someone plugs in non-death oriented action into the Doom engines (and their kin). I myself would like to see a Half-Live/StockExchange!
  • More Details (Score:5, Informative)

    by lkaos (187507) <anthonyNO@SPAMcodemonkey.ws> on Friday August 22, 2003 @09:08AM (#6764531) Homepage Journal
    This was actually an Extreme Blue [ibm.com] project this summer. In fact, it was out of the Almaden [ibm.com] lab.

    Extreme Blue is a program where IBM hires three CS college students and one MBA student to work on exciting new technologies. The official party line is that Extreme Blue is IBM's incubator for talent, technology, and business innovation.

    Lots of cool things come out of Extreme Blue. They ran an IBM-wide test of this Quake2 grid thing. It was pretty cool...
  • by Selanit (192811) on Friday August 22, 2003 @09:20AM (#6764660)
    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.
    • Exactly. That is part of the business plan that Fred, the MBA student, came up with. Since it is hard for game developers to know how popular an online game is, this allows them to start with a small number of server and incrementally add them as popularity for the game increases. As the game ages and the number of players drop, you can remove servers from the grid and optimal grid should redistribute the load over the remaining servers.

      At least that's the way that Matt and John (the two main developer
  • Play is Slow (Score:3, Informative)

    by Josuah (26407) on Friday August 22, 2003 @12:26PM (#6766633) Homepage
    A friend of mine play-tested the GameGrid but found that it didn't play very well. Instead of mapping sections of a larger map onto servers, it seemed to map sections of individual rooms onto servers. This meant you hopped servers fairly often, instead of just when moving from one large area to the next (probably the right thing to do overall, to avoid massive load during huge combat). But the problem was an extremely noticeable lag when crossing those boundaries, making the game all but unplayable.

    Anyway, this is the feedback he gave me after he tried it. I didn't have time to try it myself during the short play-testing phase they had.

We don't know who it was that discovered water, but we're pretty sure that it wasn't a fish. -- Marshall McLuhan

Working...