How Do Bullets Work in Video Games?
gamasutra.com
gamasutra.com
I find this really interesting because it’s a complete inversion of reality, where bullet impacts are vastly more energetic and chaotic than sword clashes. It tells you something about the scale we play games at, maybe.
I don’t see people talking about it, but this has to be a huge part of why sword combat in video games is so much less explored and well-realized than gunfighting. Figuring out why it’s such a hard problem, and exploring the various workarounds and their limitations, is a fun weekend project if you know a little computational geometry. (And it’s probably the work of a few minutes if you know enough formal geometry, I guess.)
You work that stuff out with numerical accuracy if you can be careful about when you need to, but since the animations and audio cues need to be carefully tuned anyway, it tends to add unnecessary complexity.
If you are running across some open space and a bullet hits you, the game can report you being hit 500ms later and it's perfectly fine. With sword, the player can actually see the sword hitting and it has to report the damage at the same moment.
A game can compensate by having slower strike animations and preventing players to redirect sword mid hit. Dark Souls 3 does a pretty decent job there - once you press the attack button, you commit to a the attack animation and cannot change or cancel it. So, the receiving end can speed up the attack animation somewhat to compensate and show the sword hit approximately at the same time it hits "on the server". As long as you have good ping, the game feels close to real time - except that opponent attack animations feel somewhat faster than your own (so, harder to dodge and parry).
If everything in your world behaves like a bullet, physics is simple. If everything in your world behaves like a sword, physics is a nightmare. A lot of games with swords literally pretend that swords are made of bullets to get around this. No kidding.
To spoil my deep explanation: in the sense games are concerned with, a bullet is a non-rotating length-0 inertially-controlled sword. That doesn’t generalize cheaply.
Model a sword as a point of rotation e, (elbow, shoulder, whatever, have the animator figure it out) location of the tip point p, and the linear velocity vector v of its tip. Look at the letter 'F': The elbow is the point at the bottom, the travel of the tip is the top bar, the travel of the hilt (not modeled) is the shorter bottom bar. The travel of the tip is the parametric equation `tv + p`, which defines the line `(tv+p)d + e` You have one line for each sword. Solve for the intersection of the two lines. If t is outside the bounds of your framestep, they do not intersect. Do basic comparisons on the length of the arm/forearm + sword length to figure out if they connect. Bonus: gives you one character slashing the others' wrists for free.
Piercing attacks are just hitscan.
If you really need to model elbows that are moving (probably only for characters on horseback while galloping) you'll need to parameterize the elbow point. Use the character's velocity vector I guess; I wouldn't do anything more complicated than that. I suppose that also works for combination slashing/thrusting attacks?
I'm too lazy to plug that into the line intersection formula, but it seems like a fairly basic linear algebra problem. Unless you're trying to make it super hyper realistic, (don't do that) I don't understand why the computational complexity is a problem.
https://sites.google.com/site/glennmurray/Home/rotation-matr...
I've used these to simulate polymer growth branching in 3D. Determining if and where two lines in 3D space intersect requires determining the scalar parametric equations of the two lines, then solving 3 simultaneous equations using a method like gaussian elimination. Seems like the last step could be computationally taxing for a cpu if performed each time-tic during sword swings - not sure if modern GPUs are optimized for just this sort of problem.
There's a closed form 3x3 matrix inversion procedure which is very fast on CPUs. [1] We don't use it with pen and paper because it's too hard to remember and there's a lot of places to fuck up substitutions, but computers don't have problems with remembering obtuse formulas. (it's like the 2x2 inverse where you shuffle stuff around and divide by the determinant) So you're looking at about 60 instructions (one division operation) with no branching to solve Ax = b in R3. [2] The reciprocal throughput is 16.5 cycles, so 5.5ns on a 3GHz Skylake assuming everything's in cache. In gamedev you'll use an approximate reciprocal instead of the division, so the latency will be lower but AFAIK the throughput will be the same.
The slow part of rotations is actually computing the sin/cos of the angles. You'll notice my model avoids anything to do with angles: there are no transcendental functions. This is non-physical for a few reasons, notably it's not possible to swing a sword more than 90 degrees in one frame. It's fine for a video game where you assume a full sword swing will take 15-30 frames and good enough is good enough, but it's not fine for scientific computing. Video games are all about faking it when nobody's looking.
Also, my model starts with defining motion in terms of the scalar parametric equations of the lines. I did think about this before posting. :)
[1] https://en.wikipedia.org/wiki/Invertible_matrix#Inversion_of...
Consider that many forms of sword fighting remove the complexity by creating zones. I’ve been told that a skilled swordsman can identify 16-32 zones considering where an attack can come from or where to strike.
Isn’t this a much easier model if you factor in the weight/mass/velocity of each particular character? This would be a little like auto-aim but you could still compute each path and create effects against one when they happen or not.
If you have 4-8 static blocks vs 16-32 attacks that would be fine, but if you need to calculate what happens when 16-32 attacks run into the same 16-32 attacks you have a combinatorial explosion problem which you then need to simplify.
One of the reasons I like going straight to the linear algebra approach is that you do a batch of basic arithmetic which the CPU does quite fast without branching, and then you do one branch to determine hit vs not-hit. Pairing zones with zones sounds like nested if/else statements, but I hadn't dived into considering that approach.
The problem is called tunelling, and though there are some features to deal with it, there aren't any ones that are simple, reliable and cheap.
I've never tried to implement anything like that, so I am curious where that might Fail.
Have you played Dark souls and or Sekiro? I've always been a little curious how FROM accomplishes such a great experience with melee weapons.
Also a shout out to Mordhau for similar reasons but with LOTs more people to worry about in a server.
But one of the reasons Dark Souls and Demon's Souls feel 'tough but fair' is that the animations are very explicit and mostly uninterruptible by the player. It meant if you made a mistake, it was probably your fault and not the animation or game logic.
Demon's Souls actually looked kind of cheap and had janky transitions at the time because of it but the games since then have been getting better at animating transitions between moves.
The animation-above-all-else style also leads to some silly interactions with the Havoc physics engine. For example, when you kick through a dead body the rag doll physics accelerate at the speed of the animated player leg causing it to look weightless and kind of ridiculous.
This is a good point, the only collisions are what you said and animations for parry windows.
And yes the rag doll physics in DS games is pretty silly.
Have you checked out Mordhau at all? Because that is probably more of the collisions/interactions you were initially referring to.
Does this really make a difference? There's nothing fundamentally different about sword to sword vs sword to body is there?
The anim set makes hits look good even though the impact is not physically calculated for collision angles and impact velocity and such. Perhaps you mean model in this way? Even still, the game has to at least do a hit detection on a deforming hitbox.
Do you happen to know how From accomplishes their hitbox animation and collision detection?
Real swords slide, slow down to a stop, jump back, get stuck, and variously swivel and yaw in your hands as they meet obstacles.
This is rather expensive to physically model, even harder to nicely animate, and nigh impossible to map to the keyboard and mouse controller combo.
There was a cool talk called "Phase-Functioned Neural Network for Character Control" that used a neural network to join animations together based on user input: https://www.youtube.com/watch?v=Ul0Gilv5wvY
Something like this where the gameplay outcomes smoothly animate realistic swordplay might be pretty fun.
Edit: For anyone wondering what truly accurate physics might do to gameplay, the Totally Accurate Battle Simulator is free on the Epic Game Store for Dec 26: https://www.epicgames.com/store/en-US/product/totally-accura...
The math seems like it would be preposterously difficult. I wouldn't even know where to begin. Seems like a very serious algebra problem. But once you solve the equations I can't imagine it's more than a few matrix operations each frame.
But it's entirely possible I'm missing something that makes it unsolvable without discrete math that pushes it into the computationally costly realm.
So you'd start with the skeleton, layer muscles on top of it, then fat layers, then skin. On top of that would come a couple of layers of cloth, then leather, mail, and plate armour.
My desire to see this has kind of sprung from mods for games like Skyrim, Fallout: New Vegas, and Fallout 4. Seeing the creativity of modders who make these amazing outfits, armours, and weapons, and wondering how they'd look if they were a single layer on top of other clothing.
This, combined with the amazing hitbox work that goes into some games, could be very cool to see. Imagine a character getting hit by an arrow: it would have a vastly different effect whether it hits on a shield, against shoulder armour, or against a helmet. Now imagine if the character had their arms raised for an overhead strike with a sword, and the arrow hit their side or under their arm?
This is exactly how dwarf fortress works. It's not a flawless system though and it tends to make combat realistically brutal. You can even modify the raws to a pretty large extent and create your own creatures and beings made out of and up of pretty much anything.
https://dwarffortresswiki.org/index.php/DF2014:Modding#Moddi...
Having an infinite supply of them would effect your decisions.
Swords can hit other swords but they also have to convincingly portray the arms, head, torso and legs during any swing or interrupt.
Having said all that, I think Jedi Knight 2 is still the best swordplay system. But only because the animations just ignore everything in their way, as a lightsaber would. Each time lightsabers hit there'e either a brief flash of light or a power struggle.
Agreed, but only if you put the following in your autoexec.cfg:
seta helpUsObi "1"
seta ui_iscensored "0"
seta g_saberRealisticCombat "1"
seta g_dismemberProbabilities "1"Nothing pushed my GeForce 2 harder than that pile of stormtrooper parts.
Imagine yourself surrounded by a transparent sphere, on which you can paint a point and a line. Where on the sword is that point? How does the point/sword travel along a line?
This is not easy to solve. What happens if you shift your perspective after a sword attack is drawn? Can you amplify it by looking away? Can you arrest the motion, by looking towards the executed sword motion.
When was the last time you saw a bullet do this in a video game? https://www.youtube.com/watch?v=0ABGIJwiGBc
If you do some light reading on "terminal ballistics", "experts" can't even agree on the lethality of bullet designs, especially in handguns.
People love to assume their models are accurate when they are usually educated guesses with gaping holes. Ballistics is no exception.
There's also the ace3 mod for Arma 3 which makes bullets behave more real
Set the FOV to some narrow angle to give yourself a sniper sight, go to a long corridor, take a nail gun, shoot horizontally along the length of it. You will see how nails end up below the aiming cross.
If it were a rounding error, the nails would end up randomly distributed the aiming cross.
Alas, shotgun did not sport the same effect IIRC, though the hit of every individual pellet was accounted for separately.
[1]: https://en.wikipedia.org/wiki/Delta_Force_(video_game)
[2]: https://en.wikipedia.org/wiki/Joint_Operations:_Typhoon_Risi...
That's not a sense in which you can determine the computational complexity of the problem. Perhaps accurate sword combat just isn't very fun. Maybe it makes convincing animation much harder. Maybe it makes controlling the character much harder. Maybe you just don't know that many games. There are plenty reasons that it might be true that no games that you know of shipped with a robust real-time solver for sword-sword collisions other than computational complexity.
> I find this really interesting because it’s a complete inversion of reality, where bullet impacts are vastly more energetic and chaotic than sword clashes. It tells you something about the scale we play games at, maybe.
Of course the modelling of bullets is also usually extremely simplified in video games. If there is anything we can learn from this I think it's that players prefer games to be predictable and controllable over them being perfectly realistic.
You're both right! I'd point out four big categories of difficulty:
1) Physics. You need a swept collision test capable of handling very high linear and angular velocity of very thin shapes (a sword is not thick, and the tip can move pretty dang fast), and collision response capable of dealing with the results. This is doable- conservative advancement operating on distance functions will work- but working out all the details in a way that makes the final result fast is not easy. A speedy implementation alongside a speculative contact solver can work, though: https://www.youtube.com/watch?v=sfgC_eNx9M8#t=1m20s
2) User interface. A mouse and keyboard struggle to express all the degrees of freedom available to a physical handheld weapon. Swinging using the mouse works okay, but you need to do so in a way that doesn't interfere with camera control, and you need to be able to interrupt and redirect movements at any point, then add jabs, different guards, ... Expressing all of that in a single intuitive interface that doesn't require awkward mode switching is not easy. My prototype had an okay-ish approach, and I think it could still be improved further, but there's no way a mouse-keyboard user would be able to compete with someone of equal skill using VR hand controllers. There's a good reason why melee combat games are so much more common in VR.
3) Graphics. Single planar projections simply aren't enough for first person (especially outside of VR)- it feels like wearing blinders. Even third person doesn't help enough, and seeing your character gets in the way of seeing your weapon and opponent sometimes. Using a nonplanar projection like stereographic fisheye, it starts feeling okay around 160 degrees, though 200+ is nice once you adapt to the mild distortion it introduces. This requires a pretty different approach to rendering (like multiple subviews, direct projection raytracing, vertex warped rasterization, etc.). A couple of examples: https://www.youtube.com/watch?v=jQOJ3yCK8pI https://www.youtube.com/watch?v=mIax_ProQ8c#t=1m4s
4) Animation. While achieving a level of animation quality common in early 2000's titles is pretty easy- just have a set of poses for various weapon states to interpolate between, blend in some leg motion, shrug, done- achieving a very high animation quality bar is extremely difficult. Most modern AAA games use massive libraries of mocap data, and in some cases the animations directly drive motion to make everything grounded and solid. For Honor is a good example: https://www.youtube.com/watch?v=4pdcA3mhe0E. But in a game allowing total physical control with expectation of proper physical response to every interaction, the mocap coverage requirements explode. You can still do pretty well if you have enough data and put in a huge amount of effort, but at a certain point you start wishing the magical machine learning genie would swoop in and save you.
I think all of these things are solvable enough to permit the existence of a game, but they're hard enough that it's not surprising that they are still so rare.
In VR you will run into edge cases where the difference between a miss and a parry at the tip of the blade requires sub-frame rotational resolution at the controller. If it were a gun, you’d never know the difference— with a sword you can feel that it moves wrong during the frame. I don’t think there’s going to be any software solution for that, we just need better tracking hardware before we can properly model a 1-meter object held out at arm’s length.
Which makes you think about constraints, is all I’m saying.
On that front, one of the things I had to end up doing to ensure physical consistency was bite the bullet on a level of indirection. This can be flat out necessary on a gameplay level- allowing full 1:1 control often leads to pretty nasty pathologies and difficulty with correct physical responses. A truly physical character's motion can never truly match the input motion, since your controller is dramatically more nimble than even a light 2.5 pound longsword and the physical sword may be interfered with. This introduces some challenges on the side of user responsiveness and intuition, to be sure, but the physical motion also smooths out input and seems to make small scale controller imprecision a distant concern to the player. If the player can adapt to the physical indirection, they tend to allow a lot more leeway. This becomes even more valuable when trying to hide latency. If you have physically reasonable accelerations, networking overhead becomes a whole lot less objectionable.
There are definitely tradeoffs- the feeling of being a puppeteer takes some time to get used to.
https://www.researchgate.net/publication/12618263_Perceptual...
This is the kind of comment that makes me just want to skip HN altogether. Why on earth are you arguing this at all — the counter to a point I never made — and why are you arguing from a position of ignorance like it makes you smarter than me?
You don’t have to pull an opinion out of your ass here. Just try it, the way my sibling poster has. This is a mathematically hard problem, and it will constrain your game design, and I think that’s really interesting.
You really don’t have to be a dick about it.
https://news.ycombinator.com/newsguidelines.html
p.s. On another note, can you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines too. HN is a community. Users needn't use their real name, but do need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
> Why on earth are you arguing this at all — the counter to a point I never made — and why are you arguing from a position of ignorance like it makes you smarter than me?
You are reading way too much into my post. I am arguing from a position of ignorance, but under no pretense that it somehow makes me smarter than you. On the contrary, it seems like you are familiar with the problem, and I think that you may have made much more relevant observations than the one you posted, but because my post has already prompted a more detailed description of the problem and its potential solutions I don't have to wait through petty insults to hear about it.
This is basically true with almost all character controller behaviors(perfect ability to jump high, sidestep, slide etc. without stumbling) and also with combat results(add enough animations and you have a melee combat system; turn granular physical reactions like bullet impacts into a state change making the target "hurt" or "stunned"). And it's even true of the earliest ball-and-bat games: reduce hitting a ball to a lookup table of trajectories and you get Pong without having any trigonometry in your algorithm. You can define a massive swathe of gameplay code as combinations of "lookup table, finite state, timers, resource counters".
This is also true of the physics solvers: define the solver in terms of eliminating all the visibly wrong results(which in the base case means filtering the set of results that contain penetration), and you have one sufficiently good for gameplay. For 2D games this has classically meant solving AABB-AABB movements along 1 axis at a time(i.e. if your raycast is diagonal it's reduced to two one dimensional on-axis movements, which is trivial to compute). Once you want realistic physics as a "special effect" you typically will switch towards using a physics library to provide both solver and colliders, and so as a gameplay programmer you may never have to learn the physics problem in much depth.
The video games that really work with physics instead of against them are kind of exceptional, and tend to be categorized as "simulators" - flight sim, racing sim, pool sim, pinball sim. Or they are joke games like QWOP, or at their most fantastic, space games. When we actually simulate anything, the scenario-and-story space tends to reduce dramatically as everything starts converging around the sim's chaos. As we eliminate the sim, more can exist in the designer-fiat space. That's how we can have games about wrestling and swordfighting and yet not really be able to convey the physics or controls of those activities.
The physics itself is not computationally complex as far as I know, but it depends on the amount of detail you want to simulate.
I personally think realistic systems like this are fun to make but they can often be frustrating when put in a game.
There's an old game called Die by the Sword released in 1998 which lets you control the movement of melee weapons with your
https://www.youtube.com/watch?v=DPm3R3eWtA4
The gameplay feels kinda silly, but it works in this game because it doesn't take itself too seriously.
Arma for instance you hear sound of the the bullet whizzing by or crashing into an object. After, you hear the sound of the bullet actually being fired (as bullets move faster then sound). This really threw me off at first, but really adds an immersive effect. The farther you are away, the longer the distance between the two sounds.
Without the muzzle report the enemy has a much more difficult task in assessing distance and direction to the source of fire.
If you’ve implemented hitscan, the easiest implementation would be to find other players within some distance along the ray, and play some sound effect where the intensity of the whizzing sound is a function of the other players distance from the ray. The whizzing sound should provide some sense of direction of the bullet relative to the direction another player is facing. Possibly playing a pre recorded sound from a map of available sounds? Eg a bullet rushing from your 2 o’clock just past your shoulder? Or you could try to mix the sound and create that effect in real time I suppose.
Our professor asked us how would we implement hit detection - there were a few answers, but none touched the underlying idea that when there's no agent(user, AI) input, objects move in a predictable way, so the distance between them is some function of time.
For example the distance function of two objects moving in a linear fashion is (IIRC) a squared parabola, so you only need to sample three points in time to get the whole function.
And, of course, you only need to recalculate this function for objects that changed direction.
This is only true for points. It’s demonstrably untrue for arbitrary shapes.
Then you can approximate any shape with spheres and use that as an optimisation before actually calculating the more costly distance functions.
Edit: I should add that part of the reason for this is that some of the external forces on a bullet are non-continuous, like wind coming around a building. That sort of pesky real world effects makes elegant solutions a lot more difficult.
But your point still stands and applies for most shooters.
Why not, if you use the flyweight pattern?
part 1: https://medium.com/@qingweilim/how-do-multiplayer-games-sync...
part 2: https://medium.com/@qingweilim/how-do-multiplayer-game-sync-...
I guess this made the collision detection a bit faster and also made the game more dramatic - the close calls were bullets passing through the ship.
Consider this: https://www.youtube.com/watch?v=AY7QEEnSGVU
EDIT: Or this, https://www.youtube.com/watch?v=JJgy5skcMJI
At the end, you can really see the boss's frustration with the player as the beautifully ordered patterns devolve into an angry display of brute force as she throws every kind of bullet in the game at you at once.
There's something called "Coyote Time" which is named after Wile E. Coyote and him staying in the air for a few seconds before gravity takes effect. Often in platformers, there's an invisible collision box added after cliffs so that if the user was slightly late pressing jump at the edge of the cliff, they would still make it as the invisible collision box would provide an extra step. It's an example of improving gameplay and game feel without being realistic.
It is, it's called "grazing."
It's possibly also worth mentioning for people unfamiliar with danmaku games that most are one hit kills against the player.
This caused problems for one of our tanks about two expansions ago where his class' combat stance combined with being the largest race had his character model stand entirely outside the hitbox.
Moreover, this kind of collision system is often used in games on systems where the hardware is capable of reporting pixel perfect sprite overlaps anyway, so I think you're on track when you say it's for dramatic effect. IME it's also frustrating in games where this isn't the case because you feel cheated when you die because a shot barely grazed some antenna.
1) If you look at how Nintendo solved ping-pong with Wiimote Plus (gyroscope addon) after the obvious letdown of the Wiimote standalone (only accelerometer): they gamified it, there is no 1:1 and the game is still fun. VR prooves this case too, as non-superhuman input is hard to sell after you give a man the mouse!
2) Ballistics are expensive on MMO's because you don't want a proper physics engine on the server. Two solutions I imagined: A) you chunk the projectiles temporal movement as vectors and add those to a 2D array that loops over time and has a limited amount of concurrent bullets per frame. B) You make a distributed voting system where other players detect and report hits to offload the server.
For sword fights I think left/right/jump/spin attack should be enough to get the player into the minigame of parrying and attacking interleaved (against many enemies). You just need to work on the abstraction so it's as fast in latency as possible and then make sure it's fun. The most important thing is to not try to simulate reality, reality is boring.
Look at how PoP Sands-of-time did it?
It’s important to keep performance considerations in mind, and be cognizant of when the performance characteristics change. For instance, if you’re working on a networked game, you have a huge set of constraints on what’s “easy” and what’s “performant” that do not exist in offline games. The projectile code is some of the most complicated in our engine just so that syncing state is consistent.
But right now I’m working on a boss fight, so I can optimize some damage code by only checking the projectile’s distance from the player against the projectile radius, instead of doing raycasts through our damage system. I also have more control of which things in the environment can be damaged by projectiles; another example of games being complex with lots of moving parts.
Destiny 2 not that long ago had an issue with the Cold Heart laser where players on the PC port could output gamebreaking damage by jacking up their FPS as the laser would tick per frame (presumably) so the advice resonated
Even in Counter-Strike, back in the days, you'd be slightly more floaty when you cranked your FPS above 150, some went up to 1000 or more.
It’s no more complicated to sync that than to sync a straight line. ARMA does it.
EDIT: If it sounds like I’m saying “syncing bullets is effortless and there are no complications,” you’re reading too much into this. My objection is that bullets are fundamentally easier to sync than players, because they’re perfectly predictable, and you have to sync players already.
UE does bruteforce calculation as I know.
Bullets are no more special in that regard than any network entity.
> Instead of expecting everyone's messages to be dealt with at once, I now deal with each packet as it comes in. That player alone is moved forward in time, and a custom response is sent out in very short order. The rest of the objects in the world are spread out between the incoming packets. There are a lot of issues that that brings up. Time is no longer advancing uniformly for all objects in the world, which can cause a lot of problems.
> It works, though! The average time from a packet ariving at the system to the time a response is sent back is down to under 4ms, as opposed to over 50 with the old dedicated servers.
> Another side benefit is that the server never blindly sends packets out into the void, they must be specifically asked for (note that this is NOT a strict request/reply, because the client is streaming request without waiting for the replies).
> I am going to be adding bandwidth estimation to help out modem links. If quake knows that a link is clogged up, it can choose not to send anything else, which is far, far better than letting the network buffer everything up or randomly drop packets. A dialup line can just say "never send more than 2000 bytes a second in datagrams", and while the update rate may drop in an overcommited situation, the latency will never pile up like it can with the current version of quake.
> The biggest difference is the addition of client side movement simulation.
> I am now allowing the client to guess at the results of the users movement until the authoritative response from the server comes through. This is a biiiig architectural change. The client now needs to know about solidity of objects, friction, gravity, etc. I am sad to see the elegent client-as-terminal setup go away, but I am practical above idealistic.
https://raw.githubusercontent.com/ESWAT/john-carmack-plan-ar...
This lead to a lot of "fun" instances of you seeing me, running behind cover, but due to lag those messages didn't reach me, so I kill you on my screen while you end up dying while in cover.
Always make the assumption at least some people will take the most trivial interpretation of your comment on the internet. You have to balance between addressing them and not wasting time.
Sure, if you’re interested in simulating the effects of rifling and turbulence on the bullet, then you’re getting into fluid mechanics where the temperature and composition of the atmosphere make a difference. That seems like overkill for a game.
That is basic abstraction which underlies all software...
I’m not sure I would I agree with this.
Even hitscan projectiles for a game like Call of Duty or Battlefield is intense. Dozens of players running around with high rate of fire machine guns in complex geometric environments. It’s a significant cost.
Ballistic trajectories are pretty complex. Adding primitive bullet drop is definitely a huge increase in computational cost.
And that’s just for fake ballistic. Real bullet ballistics are “solved” empirically. There’s a bunch of formulas with a bunch of coefficients. And real bullets are fired at a real range to calculate the coefficients. It’s crazy complex.
https://www.jbmballistics.com/ballistics/calculators/calcula...
Fortnite used to have pretty bad early game performance. Games are defined by their worst case. Early game could have a few dozen players firing high-rate of fire weapons. 100 server shots per second would be a regular occurrence.
Non-hitscan projectiles might also increase networking costs. Although for fast-moving invisible bullets you could probably don’t need to send them.
The actual server cost for shooters is generally resimulating the world for each player. Adding simulated bullets would make this even more expensive.
Why are a few hundred raycasts per frame expensive? In detail? I was doing a few hundred raycasts per frame back in 2008 at 60fps. So all this talk about expensive raycasts strikes me as “someone hasn’t tried it.”
Physics engines are so advanced that it’s mind boggling just how much work goes into their efficiency. There are legions of programmer-physicists who have spent their entire working careers just getting another 5% efficiency out of their algorithms. I could buy that 100k raycasts at 20fps might be expensive on modern machines, in specific circumstances. But 100? No chance.
Game servers often run at a mere 20Hz or 30Hz. Getting to 60 is hard. The question isn’t merely “is it expensive”. It’s “what’s the worst case and how expensive it is to add on top of what we already do”. Is 1 millisecond a lot or a little? (Spoiler: it’s a lot)
Modern CPUs are fast. But single threaded performance hasn’t improved exponentially. You could technically throw cores at the probably. But games want to maximize total server instances. You’re not likely going to throw 8 cores at one instance.
Go download Unity and find a reasonably complex scene. Start calling Physics.Raycast with different locations and directions. See how many calls you can make in 1ms.
If you drop by 1ms for 100 raycasts, the physics engine is broken.
I mean this in the nicest way: have you tried it? If you do, you’ll discover you can cast almost as many rays as you want, against almost arbitrarily complex scenes. Whatever the server is using for its physics representation (which you need anyway) is what rays will use. And you’re already simulating some physics at 20Hz.
I used 60Hz to point out I was already casting hundreds of rays at 60Hz in 2008. Servers have only gotten better and faster, and the scenes have become exponentially more complex.
But if you won’t try it, you won’t try it. I can’t really think of any other way to make the point, short of pulling up a chart showing how many millions of raycasts you can do now against scenes with millions of triangles.
The whole point of spatial data structures is that you don’t have to check millions of triangles, even if your scene has millions of triangles.
I think unity has caused a lot of harm in the sense that devs have no idea what it’s actually doing. Ray.Cast might as well be black magic. Is it expensive? Who knows? Maybe it takes 16ms per raycast!
The worse part is that Ray.Cast also becomes the lens through which devs view the world. If unity’s raycast system is slow, then suddenly “all games everywhere cannot do this thing.” But unity is often slow!
We’re a bit off the original point. Which is whether ballistics are computationally complex. I’d say so. Lots of players, lots of guns, complex geometry (static and dynamic). Pretty much everyone has had to deal with optimizing raycasts.
Parabolic arcs are even more expensive to intersect. And we’ve not even thrown AI into the mix. I’m not sure I’ve ever seen an AI drop a bullet through a narrow gap across a map. But TBH not many games have ballistics to begin with. Much less ballistics plus AI. I’m sure there’s a few. But it isn’t common.
When you send out the raycast and get a list of all objects hit, you can iterate over the objects hit and reduce damage value until the first enemy object is hit (pending any distance restrictions).
Raycasting instead takes the light-speed-line information and runs some process like "What could we do to make this play out convincingly?" Then based on that information, it adds the gravity effects and other stuff to what plays out.
You might raycast right before a jump to determine what landing animation your player will ultimately use. That's important during the jump because it makes it look more convincing.
Precomputing a trajectory loses the dynamics of collision and the cheapness of rays.
Fixing projected actions into the future from one point in time can make for weird lag effects and unpredictable results for the player when a moveable piece interrupts a fixed bullet path.
Games run in discreet time steps called frames or ticks. Bullets travel can then be simulated in several ways for example using numerical integration to apply forces to each bullet for the time step to calculate its new position, collision testing the line segment (“raycasting”) between the position of the last frame and the new position and calculating and displaying the results.
You have spent the past month or three writing and optimizing some very slick code that draws a first-person view of a maze, with textured walls and floors. Everyone's jaws drop when you show it to them. It takes about 75-90ms to draw a frame on that 80286.
You have next to no time left to run game logic in. Simulating a handful of active enemies and processing player inputs pretty much eat up the rest of the time. But you have this raycasting routine that you optimized the hell out of because it's in the middle of one of the hottest parts of the display-rendering code. So you reuse that as your "is the player aimed at an enemy when they clicked" check. It's good enough, especially since the game's largely set in a tight labyrinth with few spaces large enough that a more realistically simulated bullet wouldn't get to your target in the time between one frame and the next anyway.
When you upgrade your view renderer to handle non-grid-aligned walls and arbitrary heights for your next game, you don't bother simulating better bullets. It's still Good Enough - you're targeting a faster CPU now but you're still doing all the rendering yourself because GPUs don't even exist yet, and your rendering is more complicated now and you still only have about 5% of the CPU time left for game logic.
You start licensing your view renderer to other game companies. ("You", in this story, are pretty much John Romero.) Other people start writing similar game engines but they make similar decisions for similar reasons; "realistic bullet physics" would be nice to have but that's a lot less impressive than "this game can actually render objects with a triple-digit number of polygons while maintaining a decent framerate and resolution".
This situation persists for quite some time until "3D accelerator cards" become something you can expect the average computer owner to have, and you can start spending CPU time on "simulating a more complex world".
(It is also worth noting that 2D games written in this timeframe would generally show bullets as visible objects with an exaggeratedly slow travel time, so the player had a chance to dodge them. Rendering 2D stuff is a lot cheaper.)
Doom did a lot better, hence the monster infighting
HN users tend to think deeper/more complex simulation is directly correlated to better gameplay (see the sword conversation above), but one of the interesting things about games is abstraction.
That said more simulation focused games with larger maps (some Battlefield games, ARMA) have bullets with travel velocities and bullet drop.
There is death in the series, end-of-battle fainting is explicitly a different thing (probably better thought of as "knocked unconscious").
The first generation even had the tower in Lavender Town, filled with the graves of dead pokemon.
In any case, GP's comment stands: Pokemon is neither a shooter nor focused on killing.
There's a place for those things but there's a different balance of pacing and tension. Most games more closely resemble thrillers because there's more intense experiences packed in.
I'm not gonna stop enjoying my murder sprees through hordes of monsters powered by a google-maps-worthy talent tree and several spreadsheets worth of magic sword optimization out of some moral objection to violence, but I'd be very happy to see the same degree of sophistication and mechanical depth applied to other game mechanics as well, and probably feel better about that hobby of mine as a whole then.
Tense situations are generally dangerous, and games tend to thrive on tension. Beyond abstract puzzles, simulations tend towards activities which are actually dangerous and discouraged in the real world; if it's not violence, it might be theft (Thief / Dishonored), high wire acrobatics (Mirror's Edge), high speed driving, etc.
Besides shooters, combat dominates adventure and open world games, which could be done differently too.
> Besides shooters, combat dominates adventure and open world games, which could be done differently too.
Could you elaborate on this a bit? To contrast, I think of Fallout 3. Sure, there is a lot of violence out in the wasteland and it kind of stinks that I can't, say, reason with mutants. But at the same time, I would not characterize the dominant expression of agency being mediated through violence, but dialog. Are there any games specifically (besides those with a shooting focus like Battlefield, Call of Duty, etc) that capture your sentiments?
https://www.google.com/amp/s/venturebeat.com/2019/01/22/npd-...
It includes doing a medieval quest, becoming an action mercenary, becoming a ninja, managing a top football team, building a city, building a theme park, participating in World Wars, building a space program, rescuing hostages etc.
The focus on violence means that such violence is percieved as beyond the reach of most in real life, which is good news.
The article also provides examples answering your second demand.
https://www.reddit.com/r/FortNiteBR/comments/73ar5d/the_guns...
> "A lot of “casual” games end up using the hitscan method as it simplifies the learning curve for most beginner players. But what about games that aim to create an “immersive and realistic” shooting experience? They cannot achieve their goals within these constraints. We need to use an alternative method."
It's not saying casual games are the only games to use hitscan but it's usually easier and quicker to implement hitscans than projectiles (and more intuitive for casual gamers).
Half Life and Halo both use the hybrid system depending on the weapon, as written in the article.
Guns in Battlefield are far easier to use in comparison.
tl;dr hitscan or not does not correlate with ease of use.
It's free to play, download it and see for yourself how "point and shoot" weapons in CS are.
Slightly less snarky - in CS shooting while moving (as practiced in most other shooters, including BF and CoD) is extremely inaccurate, sometimes comically so (close up, you will miss your opponent, despite your gun barrel visually sticking into their player model). This means that just to fire a gun accurately you require good left/right hand coordination (you move with the left hand, and aim and shoot with the right). For example, you might strafe left to check a corner, register an enemy, you will then flick on their had and synchronize your counterstrafing with your shot. This might sound simple, but the skill ceiling is extremely high.
As a long time player of both BF, CoD and CS (all versions) I can tell you that the gunplay of CS is by far the most difficult to master (or rather, get to a half decent level) out of all popular shooters.
The time to kill in CS is very low - often zero.
> Burst fire weapons (which aren't very popular in CS afaik) take slightly more skill, but still, projectile weapons are objectively more difficult.
In most games burst fire weapons are easier to use than their full-auto counterparts, since their bursts are often artificially more accurate than manual bursts
I think you might be getting things backwards. The fact that it has a low time to kill means it takes less skill to get a kill. When a fight takes longer, there are more opportunities for the higher skill player to increase their advantage over a lower skill player. This is a pretty well-known relationship in game design.
To put it another way, if you look at a game with a long time to kill, like a fighting game or moba, if you put a top 1% player vs a top 5% player in a 1v1, the better player will ALWAYS win every single encounter (assuming equal start). This is because even if the better makes a mistake, or the worse player gets lucky, the fight is long enough to compensate for that.
In a game like CS, because the time to kill is so fast, it only takes one single mistake by the better player and the worse player will win the encounter.
I should clarify that like most games, I think CS still has a very high skill ceiling, but a ton of it is in communication/positioning/knowledge and also the kind of "raw skill" like reaction time that can't fully be trained.
> When a fight takes longer, there are more opportunities for the higher skill player to increase their advantage over a lower skill player. [Therefore making the game more skillful]
I very much disagree. Letting your opponent get the drop on you is a major mistake. The game giving you opportunities to plaster over huge blunders easily does not make it more skillful.
In CS you have short time to kill, long time to reset, precisely to make positioning and game sense more important and to heavily punish whiffing. If a slightly better player in terms of mechanical skill could always just do a 180° and get the kill regardless of how poor their positioning was, you are clearly not increasing the skill gap of the game. Rather you end up with a CoD-style experience.
Similarly, the importance of a single kill in CS varies widely. It could be relatively inconsequential, or it could decide the round (even if it is the first kill in a 5v5).
> In a game like CS, because the time to kill is so fast, it only takes one single mistake by the better player and the worse player will win the encounter.
That's the point of the game's design. You can't and shouldn't expect raw mechanical skill to save you every single time if you get yourself into a bad situation. Sometimes it might, some bad situations are also very hard to avoid. But if you keep getting into bad situations w.r.t. to your opponent you are clearly not the better CS player. Similar to racing, if you get off the track in a corner, your mistake was seven corners before that.
This original thread started with a discussion about the mechanical complexity ("skill") of CS. Not positioning, game sense, etc. Though other games have that stuff too!
> The game giving you opportunities to plaster over huge blunders easily does not make it more skillful.
The thing is, having a long time to kill doesn't really allow you to plaster over anything, at least not at a high enough level. Once you're at the highest tier of a game, every single one of those positioning + game sense decisions matters too... but then raw mechanics wise, those long ttk games are more complex than CS.
The battlefield series in turn, while not really realistic, has way more moving parts in it thus making it less arcadey.
> The battlefield series in turn, while not really realistic, has way more moving parts in it thus making it less arcadey.
I think you vastly underestimate just how complex CS is and how many gameplay elements are intermingled to make plays happen at higher levels of play. As a long time player of both BF and CS... BF has more "stuff" and more things going on at the same time (mostly due to large number of players and vehicles), but is definitely not the more complex game.
On top of that, CS even at medium levels of play, is more about game sense (strategy, understanding your enemies positioning and reactions to stimuli, timing, ... game sense in itself is a vast sea of complexity) and communication than raw mechanical skill, although the latter can to some extent compensate for the lack of the former. At high levels of play, purely mechanically skilled players are... worthless.
Just because people play a game competitively, it doesn't make the game inherently competitive. For example, many people play Minecraft competitively; that doesn't make Minecraft a competitive game, just a game that you can play competitively.