Doug Bora ....... Content, Editing, Proofing Tod Bouris ............ Content, Playtesting Bernd Kreimeier ...... Recent Technical Data Chris McAllen ......... Content, Playtesting American McGee ........ Early Technical Data Randy Pitchford ........ Quake 2 Information Dean Stretton ..................... Proofing
Additionally, the computer games referenced in the text are of an adult and graphic nature. In no way is this text intended to promote violence of any kind. Any references to violence in this text are meant in relation to the playing of the computer game, not real violence. The author is adamantly non-violent.
Additionally, this text is being presented in the form of a computer file. Any illegal or damaging activity related to the use or transfer of this or any other computer file is not the responsibility of the authors.
He was extremely helpful, and pointed out a couple places in the Doom public code release that answered my questions. Specifically, we've now got the exact time delay, damage, and range limitation information. Thanks, Bernd!
And to add icing to the cake, Randy Pitchford and I have nailed down the last few details about the Quake 2 BFG10K, so I've fleshed out that section as well. Thanks, Randy!
This BFG FAQ has been a very unique project for me. Its development cycle has spanned over two years, and it's been through many revisions. Thanks to all the folks who e-mailed me about it, and the folks who contributed.
I think my favorite part of this whole thing was seeing all the other "Doom specific weapon" FAQ files appear on the net after the BFG FAQ came out. All the way down to the "Pistol FAQ". The first one, I recall, was originally intended as a joke... it was a "Rocket Launcher FAQ" that started out as a satire of the BFG FAQ. It was hilarious, and even had satires of the ASCII diagrams. Now these files are actual legitimate FAQs in their own right.
When I first undertook this project, it was simply because I couldn't get a straight answer to the question, "How does the BFG work" on usenet. Now it's taken on a life of its own. With the Christmas release of the Doom source code (Thanks, id!), I guess the whole thing has come full circle.
It's been a fun ride!
This FAQ file describes, in as much detail as possible, the behavior of the BFG9000 weapon in the MS-DOS version of the games Doom, Doom II, and The Ultimate Doom. It is not intended to answer general questions about the game itself. Please refer to the other FAQ files for help in other areas of the game. You can also frequent the rec.games.computer.doom.* newsgroups for more information.
We began writing this FAQ out of necessity. We were frustrated at the apparent inconsistencies in the way the weapon seemed to behave during game play, especially during deathmatches. There were times when we would get killed by the weapon when we thought we were completely safe. Conversely, there were times when we thought we had used the weapon correctly against an opponent, but they walked away unscathed.
Our intent is to provide players with enough information to attack effectively with the BFG, and to correctly defend against it in a deathmatch. Our hope is that this information will give players a new attitude toward the weapon. We want to transform it from "The weapon we love to hate" into "The thinking man's weapon".
With the 1997 release of both the Doom source code and the sources for the Quake 2 game DLL, this FAQ will hopefully provide accurate information for all versions of this unique weapon.
Testing was performed on Pentium computers running the MS-DOS versions of Doom II and The Ultimate Doom. Tests were done both in single player mode and in 4-player deathmatch mode. Testing was performed on the regular levels as well as custom made levels. In some cases, a special .WAD file was created to test situations that would be difficult to reproduce with the regular levels.
At one point early in the development of the FAQ, we exchanged some emails with American McGee at id Software. He filled in some very important details for us-- for example, until American told us about it, we didn't know that the game used a set of damage traces to calculate blast area damage. His help was invaluable in putting this FAQ together and getting it off the ground.
Recently, I was able to ask Bernd Kreimeier some specific questions about the code. His answers, I hope, have cleared up any ambiguities in the details.
Then there's the issue of the Doom public code release. That code was "cleaned up" by Bernd Kreimeier, who was given the sources by id Software to prepare it for a public release. Bernd tells me that he did not change the BFG code in the cleanup process, but the sources are from a later date than the original commercial releases of Doom and Doom 2. In his words:
It is the January 10th, 1997 version - a few TNT/Plutonia
mod's have been done in this code base, but I am in no
position to confirm whether this affected the BFG code.
I never looked at that part of the code, nor changed it.
Until I hear otherwise, I'm going to assume that the public code release
contains the same BFG behavior as the commercial releases. Everything
you see in this FAQ will be based on the old playtesting we did in 1995,
cross-referenced against the sources found in the 1997 public code
release.Finally, now that the folks are modifying, compiling, and releasing their own versions of Doom, who knows what they might change? The BFG was an infamous feature in Doom, and will likely be the first target for modifications. So read those README.TXT files before you play a modified Doom.
Despite all of that, some items in this file may still be conjecture. Please see section 5 if you suspect this FAQ contains erroneous information.
The URL of the directory that contains the Doom FAQ files (usually in TXT format, compressed in a ZIP file) is:
ftp://ftp.cdrom.com/pub/idgames/docs/faqs/
The latest official version of the BFG FAQ is also posted monthly to the rec.games.computer.doom.announce and .playing newsgroups. This is part of the RGCD Periodic Information Postings (PIPs). If your news server does not keep the articles long enough for you to find one of the PIPs, they are archived at:
ftp://ftp.cdrom.com/pub/idgames/docs/rgcd-pips/
The official location for the hypertext version of the BFG FAQ is DoomGate on the World Wide Web. Check it out here, along with some other good documents:
http://doomgate.gamers.org/docs/
When you have it in your arsenal, the BFG is selected by pressing the 7 key on your keyboard.
When you pull the trigger, there is an excruciatingly long pause as the weapon warms up. Then a large green ball of plasma is emitted from its barrel. The plasma ball flies in the direction you fired it until it hits a target or a wall. Like all weapons in Doom, it will fly straight through decorative objects like torches or trees.
When the green ball hits a solid object, it detonates and does two types of damage: Direct Hit and Blast Area. Each damage type is outlined in its own section, later in the FAQ.
So is "Fragging" a deliberate softening of another famous F-word? Maybe. But the term "frag" is an actual word, and it's used in Doom to represent a confirmed kill in a deathmatch game. This comes from the idea that in a deathmatch, you are killing your fellow space marines. The definition of frag is:
frag Slang. Verb, transitive
fragged, fragging, frags
To wound or kill (a fellow soldier) by throwing
a grenade or similar explosive at the victim.
That's not to say that the the word Frag isn't often interchangeable
with the other word. And, of course, the Quake 2 manual calls the
new BFG10K the "Big, uh, freakin' gun."Other good name suggestions that have found their way to the authors are "Big Funny Gun" (Chris Somers) and the much more logical "Blast Field Gun" (William D. Whitaker). I'm sure there are thousands of names you could invent for it...
Note: This cheat code is disabled in multi-player games and single-player nightmare-skill games.
It worked by shooting multiple streams of different types of plasma and fireballs. Because this required an unusually large number of moving objects, it tended to slow down the game. Therefore, the BFG was redesigned with the invisible blast area that is used today.
Recently, these early Doom versions have been distributed on the internet. You can find screen shots and downloads at:
http://www.classicgaming.com/doom
(Update 8-15-99: This is now a dead link. You're on your own.)
If you want to download the one with the special BFG, get the October 4th, 1993 press-release version.
The base damage value for the green ball is 100 points, which gets run through the missile damage randomization routine:
damage = ((P_Random()%8)+1)*tmthing->info->damage;
Note that the above code results in damage values in 100-point
increments, i.e., 600 or 700, but not 666.A note about skill levels: Testing seems to show that weapons always do the same amount of damage to monsters, but that the player objects can absorb the weapons better at lower skill levels. Therefore, it takes more shots to kill a player at lower skill levels, and fewer shots at higher skill levels. This is why some players prefer to deathmatch at the higher skill levels: The frags are quicker that way.
The Doom public code release bears this out. They perform a right bitshift (a fast way to divide an integer by two) on the damage value as follows::
player = target->player;
if (player && gameskill == sk_baby)
damage >>= 1; // take half damage in trainer mode
And of course, armor is a factor as well. Depending on the type
and the amount of armor worn by a player, some armor will be
subtracted in lieu of health.If your target is lucky enough to survive a direct hit, he is still susceptible to damage from the blast area. This happens sometimes in a deathmatch. Since there is a brief pause between the direct hit and the blast area calculation, your victim may go through several stages of fear and elation in the space of one second:
The hard part is that the BFG's plasma ball travels at a fixed speed, and can be avoided by an alert deathmatch player. The reference number for the BFG ball's speed, as stored in the .EXE file, is 25. For comparison, rockets travel at 20 and plasma gun shots travel at 25.
If it seems like this is too fast, and would not be easy to avoid, remember that the plasma gun fires in a continuous stream. The BFG can only be fired once every few seconds. The BFG's green ball is also very bright and large on the screen. All of those factors make it generally easier to avoid in a deathmatch game.
A direct hit in a deathmatch (against good players) is usually the result of luck, or the result of a player that did not know the BFG ball was coming towards him. See section 4 for details of a trick that can help you achieve the latter scenario.
The direct hit can only damage one target. If there are two targets very close together, the green ball can only hit one of them directly-whichever one it touches first.
Simply put, the blast area is like an imaginary 'cone' or 'fan' of damage traces that briefly extends outward from the attacking player. The cone always points in the direction that the weapon was fired. For instance, if you originally fired the weapon in the northwest direction, the cone will always face northwest, regardless of which direction you're facing at the moment of detonation.
Note that this does not mean that the attacker must continue to face in that direction. The attacker is free to turn away from his targets, as long as he moves to a position that keeps this imaginary cone pointed at them. Common misconceptions are that you must be facing either the targets, the detonation point, or the same direction as the weapon was fired. None of those things are necessary in order to inflict damage.
Also note that this imaginary cone has no relation whatsoever to the detonation point. The location of the detonation point is only important for the direct hit (see section 2). Only the moment of detonation is important, not the location. It is possible to have the green ball detonate twenty miles away in a completely different room at a totally different altitude, but the blast can still cause damage right next to you.
The paragraphs above cover the basic concepts of the blast area. More detailed information can be found in section 3D, below.
There are 40 traces, and each one does 1-8 random points of damage in a 16-iteration loop. Meaning each trace will do between 16 and 128 points of damage.
Because these traces radiate outward from the attacker in a fan shape, a target will more likely be hit by a given trace if he is close to the attacker. Therefore, targets closer to the attacker will generally take more damage because they are hit by more traces.
If a target is very close to the attacker (for instance, standing right next to him), the target might be within the hit range of all the traces. The amount of blast area damage in this situation would be between 640 and 5120 points. However, all traces would not necessarily be absorbed by that target, and might move on to other targets. See section 3F, below, for more information on this phenomenon.
A note about random numbers:
A phenomenon known as the 'bell curve' happens when you combine the outcome of multiple random numbers. Players of book-and-paper role-playing games may recognize it. In those games, you would often use three dice to generate a random statistic. In theory, adding the three dice would generate a random number between 3 and 18. But in reality, the actual results would be weighted towards the middle of the range, around eleven. The odds of getting a three or an eighteen are rare because you'd have to roll 1+1+1 or 6+6+6. There's only one possible combination for each outcome. On the other hand, rolling an eleven is relatively easy: 6+4+1, 5+5+1, 3+3+5, etc. If you were to graph the outcome of a thousand rolls, the graph would be shaped like an arc or a bell, with more rolls coming up in the middle of the range of possible values. Hence the name 'bell curve'. The role-playing games use this to make certain random statistics more fair.
This applies to the damage traces, as well, because they are essentially a group of multiple random numbers. For instance, although the possible damage for a single trace is 16-128, the odds are that the total damage from a trace will more likely be around 50-60 points, due to the bell curve. The odds of doing full or minimum damage in that situation would be extremely rare.
Actually, if you look at the Doom code, you'll find that even the random numbers aren't random. They're "pseudo-random", and for a very good reason: So that all four computers in a multiplayer game can be synchronized. They pull the random numbers from a table whose index changes each time it's accessed. Looking at the table, it's obvious that there are no "runs" of all low or high numbers, so it's not only unlikely that full or minimum damage would be done, it's actually impossible in the current code.
What this means is that the "A_BFGSpray" function is triggered 16 game tics after the first death frame of the direct hit was started. Assuming a game tic is 35 frames per second, then the blast effect is calculated 0.4571428571429 seconds after the detonation. Which, Captain, if I had any emotions, I'd be excited about.
But what about the other thing?
Oh, you mean, when someone is running out from from behind a corner, and it looks like the blast area should have missed them, but it got them anyway? How can that be? They ran out from behind the corner after the blast area was calculated!
Well, it's been a while (two years) since I LAN-playtested this phenomenon. We were never able to nail it down under controlled tests. The "A_BFGSpray" function calculates completely within a single game tic, and if there's a slow computer in the game, all of the computers will freeze until the slow computer is done with its blast area calculations.
The only thing I can figure is, the guy's radius (which is larger than his visible sprite) was within sight of the damage traces. He took damage while he still seemed to be behind the corner, even though he wasn't. More on this phenomenon below.
Here's the code for the function in the public code release. I've waited two years to see this:
void A_BFGSpray (mobj_t* mo)
{
int i;
int j;
int damage;
angle_t an;
// offset angles from its attack angle
for (i=0 ; i<40 ; i++)
{
an = mo->angle - ANG90/2 + ANG90/40*i;
// mo->target is the originator (player)
// of the missile
P_AimLineAttack (mo->target, an, 16*64*FRACUNIT);
if (!linetarget)
continue;
P_SpawnMobj (linetarget->x,
linetarget->y,
linetarget->z + (linetarget->height>>2),
MT_EXTRABFG);
damage = 0;
for (j=0;j<15;j++)
damage += (P_Random()&7) + 1;
P_DamageMobj (linetarget, mo->target,mo->target, damage);
}
}
The traces radiate outward in an imaginary cone that is 90 degrees wide. This
is, coincidentally, about the same width as the player's field of view.Because the code uses "mo->angle" as the source for its angle, the cone always points the same direction that the green ball flew. For instance, if you fire the green ball in the southeast direction, your cone of traces will always radiate towards the southeast.
However, because it uses "mo->target" as the source for its attacks, the traces radiate from where the player is standing, not from the green ball.
So...
Regardless of how much you run and turn between the time you fire and the time the green ball detonates, the traces will always radiate from your location. Think of it like a tank with a gyroscopically stabilized turret: only the cone's origin point moves around with you, not its direction. The cone's direction remains fixed on the same compass heading.
From a technical point of view, the game engine does not actually keep track of the cone while you're running around. That's just the effect it seems to have. It simply uses the green ball's vector as the source angle for the traces, and the player's current position as the source location.
Note that the vector of the green ball's flight is based on what direction you were facing when the ball leaves the barrel of the gun, not when you pulled the trigger.
Here's a diagram of how it works:
When the green ball detonates, the traces are calculated one at a time, using the same criteria for calculation that the engine might use for a bullet: If there is a solid object (a wall, etc.) between the target and the attacker, the trace is harmlessly absorbed by the object. With one exception: In order to hit a target with a bullet, you had to be facing the target. You don't have to be facing your target in order to do damage with one of the traces.
Quick review:
P_AimLineAttack (mo->target, an, 16*64*FRACUNIT);
actually limits the traces to within 1024 (16*64) game units.
It's been a while since I playtested this, so I don't remember if
I was ever able to register a hit when outside of this range.Whether it actually limits the range or not, outside that range it would become increasingly hard to get a single trace to land on a given target anyway. So just deathmatch under the assumption that you can't hit anyone outside 1000 units.
If you are unfamiliar with the Doom engine's units, remember that a standard teleporter pad is 64 units across. Line up 16 of those and you've got a basic idea of what 1024 units is.
The blast damage is also limited to targets that have an unblocked line of sight to the attacking player. This does not mean the attacker must face the target. It means that the attacker must be in a position where his traces can see the target, i.e., he could see the target if he were facing in that direction.
Of course, in regular game play, rarely are that many targets standing in such a perfectly aligned pattern. Usually, some individual targets will soak up more than one trace, while other traces miss targets completely.
The traces are calculated on a 'first come, first fragged' basis. For each trace, the damage is calculated and subtracted from the target, and the target dies if there's enough damage. Then the engine moves on to the next trace.
Here is how it works:
(Please note: In the discussion below, we refer to 'line of sight' loosely. Remember that the attacker does not need to be facing his targets to inflict damage.)
In the following scenario, imagine that the attacker is standing in a direct line with several targets (imps, perhaps) lined up in front of him, and the green ball detonates on a wall somewhere:
In order for the above scenario to work, the targets must be perfectly aligned. For instance, in the following scenario, all of the targets take full damage, because there's no one in front of them to soak up traces.
The moral to this story is: In deathmatch, do not depend upon other players or monsters to absorb the BFG blast unless they are exactly between you and your attacker. And you'd better hope they're very healthy. In all other cases you take full damage.
Again, in the discussions that follow, we refer to 'line of sight' loosely. You do not have to face your targets to hit them.
If a difference in altitude brings your target out of the sight of your traces, then yes, it makes him safe from the blast damage. But if your traces can see any part of him, he takes full damage regardless of how much higher or lower you are than he is.
As far as altitude is concerned, the traces seem to use the same criteria as your view does to determine if the target is visible. In other words, if both you and the damage cone are facing the target, but the target is above the top of the screen, you can't hit him.
But there is a catch. The upper and lower angle limit of the traces seems to be the same as your view would be if your screen was fully zoomed in. For instance, if you are displaying the status bar at the bottom of the screen, your view window is slightly cut off at the top and bottom. Press the plus (+) key repeatedly to zoom all the way in, and you can see what this means. The BFG's traces seem to use the same angle as this full view does to determine if they can hit the target. So if you've got the status bar showing, you can actually hit someone who is off the top of your screen. If you are fully zoomed in, your view seems to be an accurate representation of the damage cone's angle.
Note: The angle limit of the traces is not affected by changing your zoom level. The traces use the same angle regardless of what your zoom is. It's just that zooming all the way in changes your screen's aspect ratio. So you can see more stuff at the top and bottom of the screen, stuff that normally would have been hidden behind the status bar.
If you are standing on a ledge above your target, and you are so close that you can 'touch' him (i.e., you can't step off the ledge because you're bumping into him), your shots will go right over his head and the blast damage will not affect him. This is because, technically, the traces can't see him. Well, if you could look down you would see him, but you can't look down in Doom. Must be those darned restrictive space helmets.
If you are hiding behind a decorative sprite (such as a tree or a technical column) you are fully exposed. All weapons in Doom always pass completely through decorative sprites.
If you are peeking over a podium, or partially obscured by a raising lift, or a closing door, and only half or one-tenth of you is showing, you still take the full amount of damage. The traces are calculated based on the game's two-dimensional block map. As far as the game engine is concerned, all of the traces can still hit you.
If you are hiding behind a vertical wall with your rear end peeking out, I'm pretty sure you still take full damage because the traces auto-aim at you. Tests seem to show that your distance from the attacker is more important than how much of you is exposed.
Also remember that what counts as 'showing' may not be what you think. The Doom engine uses the radius of the player to determine visibility. Your player's aspect ratio does not change when you rotate. It also seems as though your radius is slightly larger (in some cases) than the sprite (picture) that represents your player. In tests, it is possible to inflict damage upon a player that seems to be out of sight (no visible pixels) but whose radius is large enough to count as 'visible' to the BFG traces.
Here's why:
Even after being fragged, you can still see the action from your fixed point of view on the ground (your 'dead' state). The traces remain active and can still frag an opposing player (hopefully the one that fragged you). The traces will radiate from your dead body's 'eyes'. The traces still follow the same rules, i.e., they radiate in the direction the green ball was fired, regardless of which direction your 'dead view' is facing.
In a previous version of this FAQ, we reported that you will lose the chance to frag your opponent if you respawn before detonation. Several people pointed out to the authors that the statement was in error. The traces remain active even after respawning. Testing shows that the traces do, in fact, continue to radiate from the dead body even after you have respawned in a completely different area of the map. This testing was performed at the prompting of Kirby Nixon, who insisted that it was true. Whaddya know? He was right.
This means that, technically, you don't need to hang around and watch your opponent in order for the traces to work. But Kirby pointed out a good reason to wait for the detonation before respawning: Your dead body's traces can frag you, too! Just because they were once your traces doesn't mean you're immune. If you are unlucky enough to respawn within your dead body's damage cone, you can kiss your butt goodbye.
Of course, the same thing applies to projectile weapons like the rockets and plasma. If you play enough deathmatch, you've probably been fragged by your own rocket a few times. Don't be embarrassed, it happens to the best of us...
Please note: Any projectile kills made by a respawned player (whether by rockets, plasma, BFG traces, etc.) do not contribute to that player's frag count. Killing yourself in this manner does not change your frag count, either. This appears to be because the game engine creates a new instance of the player-object at respawn-time, and therefore 'forgets' to award that frag. In any case, if you wait before respawning, you will get credit for the frag as long as you're still dead. This is another reason to wait for detonation before respawning. Special thanks to John Castelli for pointing this one out.
The origin point of the damage cone is based on the current location of the marine who fired it (even if that marine is just a dead body- see section 3I for more info).
The purpose of this FAQ is to educate players about how the BFG behaves. If you know how it works, you will know how to defend yourself against it. You will also know how to effectively attack with it. If both (or all four) players have the same knowledge about how the weapon functions, then the BFG by definition is not unfair. If you play against an opponent who does not know how the BFG works, then you should make sure to educate them on its behavior before turning them into paste.
Having said that, the following things are debatable regarding fairness. I'm not saying they are patently unfair, I'm just saying that their fairness is debatable:
(OK, so it ain't Rocket Science.)
This requires, of course, that you know where the cone of damage actually is. That, in turn, requires that you know where your attacker is and in what direction he fired the weapon. That, in turn, requires that you know the weapon was even fired at all. Which, in turn, may be difficult against a player who has mastered the Silent BFG trick (See section 4D).
It still helps if you are playing the game with a stereo sound card and headphones. This allows you to hear how far away and in which direction your opponents are. If you think in three dimensions, the sounds you hear in the game will give you a great tactical advantage.
You must understand completely how the weapon works before any avoidance technique would be meaningful. So if you skipped ahead to this section, go back and read the gory details.
With all that said, here are a few ideas. These are just things to try, not necessarily good things in all cases.
(You were expecting some deep revelation, or what?)
This requires, of course, that you know where the cone of damage actually is. So if you looked here first, go back and check out the rest of this FAQ for details.
Anyway, here's some ideas. Not necessarily comprehensive:
If you are fortunate enough to play deathmatch with a stereo sound card and headphones, you know that sound cues are vital to playing well in deathmatch. In many cases, the only way a potential victim knows the green ball is in the air is by the distinctive sound the weapon makes when fired. The headphones can give him directional cues as to its origin, and therefore point the way towards a proper escape.
So if you wish to get the drop on someone, wouldn't it be great if you could put a silencer on that weapon? Well you can. A limitation in Doom's sound code allows you to silence the firing sound of the BFG. Regardless of the 'Number of Sound FX to Mix' that you chose in Doom's setup program, your character can actually only utter one sound at a time. This includes all weapons firing. If you cause your character to grunt, i.e., you jump off of a ledge or press the space bar on a blank wall, you have a brief period while the grunting sound is being played in which you can pull the trigger and no sound will be emitted from the weapon. Your grunt makes a little noise, but it's relatively quiet and is sometimes ignored by your opponents.
I've seen other information that tells me I've got it backwards: That you're supposed to fire first, then grunt. I don't know which is correct. Try both and use whichever one works for you.
While it works well in theory, in practice the trick is hard to perform. It also may be a little unfair. As with all secrets, it definitely makes the game unfair if you don't share this information with your opponents.
As of this writing, there seems to be a small handful of players on the doom newsgroups who use this trick. The first person to submit this trick to the author of this document was John Fedor.
Interesting anecdote: When reviewing a draft copy of this FAQ, American McGee at id Software informed us that they have been using the Silent BFG trick in their deathmatch games since day one.
Doug Bora first pointed this demo out to our particular group. Credit for the original version of this demo goes to John Ripley of the UK. The full deathmatch demo file PETALK2.ZIP is the first example of this specific action. Since that time, this has been repeated by many folks on the Doom newsgroups.
PETALK2.ZIP should be available at:
ftp://{INS site}/lmps/doom2/1.9/petalk2.zip
where {INS site} = any DOOM ftp site, eg. ftp.cdrom.com/pub/idgames
Click here to attempt to download the file from cdrom.com now.
(If the link above does not work, please consult the other FAQ files for information on FTP sites that carry doom-related files. The author won't be updating this particular link if it changes.)
How to do this:
This is an easy mistake to make because you tend to be more accurate in positioning your cone of damage if you keep your eyes on your targets. Especially if you are strafing instead of rotating.
See section 4E for proof of this.
Again, see section 4E for proof of this.
Again, see section 4E for proof of this.
Again, an easy mistake to make because you tend to be more accurate if you keep your eyes on your targets. Again, especially if you are strafing.
Again, see section 4E for proof of this.
Having said that, if the victim is standing right next to the attacker, at 90 degrees perpendicular to the cone of damage, they will fall within the cone if they are in front of the attacker's centerline. But if they are truly behind the attacker's cone of damage (behind the centerline of the attacker), they will walk away unscathed.
This seems to be due to the fact that the player's 'hittable' radius is larger than the player's 'walk into' radius. When you walk up to a player and bump into him, his 'hittable' area is overlapping into your area.
This is an easy mistake to make when looking at a deathmatch game, where everyone is moving around each other so quickly that it's hard to keep track of the location of the cone of damage. If you really think you fragged someone behind you, it's probably because of one of two reasons:
Since Quake's code is totally different than Doom's code, these BFG remakes can't be precisely like the original BFG. Most of them get pretty close in terms of "feel", though. The biggest difference is that they all have a "Z" direction for their damage cone, i.e., they can be aimed upwards.
Note that this list is not comprehensive and isn't necessarily up to date.
Randy Pitchford of Gearbox Software has written up an excellent Quake 2 Weapons FAQ. This document can be found at:
Randy and I have corresponded, and between his team's research and a few peeks at the Quake 2 public code release, we've got the BFG10K's behavior pretty much figured out. I'm only going to review it briefly here, and you can go look at Randy's FAQ for all the details. So, in other words, the torch has been passed.
Briefly, the main differences between the Quake 2 BFG and the Doom BFG are:
points = self->radius_dmg * (1.0 - sqrt(dist/self->dmg_radius));
So the farther away the target is from the detonation point, the
less damage the target will take.
The best way to defend against the BFG10K is to hide and/or run from the ball. It keeps you out of the way of the lasers, as well as keeping you out of the way of the BFG effect.
That's about all I need to say about the BFG10K (hey, that rhymes). Check out Randy's FAQ for the rest. See you on the Quake 2 servers! I'll be the one gathering cells for my BFG...