Alternative to hitscan?

I made a post in another thread with no feedback for a week, yet I found this topic interesting and decided to ask forumgoers in a new thread, because those that weren't interested in the halo 4 thread might be interested in this.

First, I will explain my understanding of how the Halo 3 and Reach systems worked based on old bungie.net pages. If I understood it correctly, In H3 every player's xbox would send the player's button presses and aiming direction to the host's xbox, which would then calculate everything and send all of the information in that match back to every player's xbox. Both transfers of information took an almost negligible (we wished it was) amount of time, which was referred to as latency.

In Reach, when a player pulls the fire trigger while looking in a certain direction, the player's box transmits a hit or miss signal based on whether or not their reticle was on target according to the player's screen. This negates the effect of latency, which is an unpredictable variable that, when large, denied players any certainty in aiming in H3. (in other words, it was the thing that was most likely to ruin an fps experience). If a player with a faster connection to the host strafed in H3, how much you would have to lead your BR reticle depended on the amount of latency, because those bullets are modeled with the player's future position on the host box. Reach's system was a "hitscan" system, just like H2. The disadvantage, however, is that Reach doesn't model the speed of a DMR bullet (by sending a hit or miss message it essentially causes an instant bullet travel time), eliminating the possibility of the "leading shots" dynamic at long range that was present in H3.

If a target was moving at a distance in one direction the whole time a player would have to place shots on where the target will be after the bullet travel time. If there happened to be insignificant latency, the only variable would be distance, which is easily noticed. The distance to the target would be proportional to the bullet travel time, equivalent to a constant (the bullet's speed) while the bullet travel time and the amount that the player has to lead are inversely proportional, equivalent to the target's speed. The leading dynamic not only provides a skill factor by making aiming much harder, it makes it less likely that players can be killed at long range, because even a player with perfect aim cannot kill a target that moves in an unpredictable way. This is even a better option than spread (for reducing long range BR power) because spread introduces randomness. Players will still take chances at long ranges if they might get a kill; both the shooter and the target may be considered unlucky or lucky frequently.

This was my post in the halo 4 thread:
If they can find a way to make a player lead a hitscan BR while actually modeling the speed of BR projectiles in order to mitigate the effect of lag [hitscan does this] while adding a skill factor and reducing the power of extremely-long range BRing [leading], they should do it. I'm not so sure that I know what I'm talking about, but perhaps every player's xbox could model its player's own br projectile trajectory and enemy movement in real time [and calculate a hit or no hit] while the host still receives the message of a player being hit and suffering damage, as in hitscan. You would receive player's positions with latency, but you would hit enemies as expected based on your screen after bullet speed is factored in. Bullets could even fall too, in accordance with real physics, such that one would have to lead ahead AND up.

You can ignore that last sentence because no one would expect bullets to fall if other plasma projectiles defy gravity in the game. If the host could synthesize information, including the host’s own actions, in the two systems, why can’t the non-host boxes add in their own information and calculate it? I know that if this was possible, they would have most likely tried it, so does anyone know why this can’t work?

 

I did not think that it would resolve latency issues, but I thought that it would force a player to lead depending exactly on what the player sees on screen. I know that there are latency paradoxes with Reach's hitscan: a faster-connection player may receive a "has been hit- apply damage" message from the host (who got it from the shooter) so late that the player is behind a wall or has already killed the shooter. The reason why this is preferable to H3 latency paradoxes is that the Reach paradox only happens to the player in certain situations, and that hitscan gives credit to every shooter's screen, where as the H3 latency affects accuracy on any moving target for slower-connection players. Corresponding H3 latency paradoxes are that a player shoots a target according to the player's screen, but it doesn't matter because the player is already dead or the target is already slightly to one side (as calculated by the host).

I notice that I mistyped where I typed "perhaps every players xbox could model its player's own br projectile trajectory and enemy movement in real time", where I meant that the player would constantly receive the enemy's position from the host, not that it would model the enemy's position. It would simply check if the received player position matches the calculated projectile position per frame(although it would be a line, creating a piece-wise vertical step distance vs. time function as opposed to a linear distance vs. time function, where each line would be a frame) for a period of time after firing, as opposed to the frame of firing, to send a hit or miss message.

Now that I have clarified, I do not see how two xboxes are modeling things between which the host has to choose. The host is never aware of a shooter's bullet position (perhaps to display a yellow tracer line it uses the latent H3 system, which wouldn't matter or agree with the damage message) in Reach hitscan or this proposed system, nor is the host aware of the things that the shooter sees on screen; the host only has to apply the hit message as damage to a player. This means that everyone is correct about who they hit, but everyone takes a hit from another dimension.

As for the DMR, bloom is horrendously flawed, fewer necessary bullets require less skill, and the crouching/scoping effects reward players for catching opponents off guard at very long ranges more than at closer (throw grenades or fire without a scope) ranges, but I already posted on that in much more detail in the TU thread. IMO, not considering hitscan, the BR is infinitely better than the DMR, and the DMR is stupid.

 

Where did you find that information? I tried looking for Bungie's page explaining whether or not the DMR was hitscan, because the forums gave conflicting responses. It took way too much time and I thought that it wasn't important enough, but as for the B.net forums where anyone can reply (as opposed to the B.net update articles), where did they get their information? I got the information about hitscan vs. H3 from a B.net weekly report about the BR in H2/3, before reach's time. I doubt that they would make the DMR bullet travel time that fast, because then it would almost never matter, and few would even notice that it was not hitscan. I have cross-mapped on Hemorrhage a lot and have never noticed a delay.

But your post revealed that you don't understand latency. Latency is not multiplied by the bullet travel time to produce the full time before a target is hit, latency is added. Increasing the bullet speed would not decrease latency.In an H3 match, if latency is significant at close range, then the full time it takes for the bullet to hit the target is proprtional to the distance of the target before latency is added. But if you increased the bullet speed, the effect of latency wouldn't decrease unless you made the system hitscan. The latency would still remain apparent at any distance.

Nutduster, not only was realism in a game not assumed in my posts, I clearly dismissed the significance of realism when I typed that no projectiles fall in Halo, and so BR bullets might as well not. As far as lag and bloom goes, bloom isn't quite necessary (this idea should be considered without bloom seeing as how it is hypothetical and not related to Reach bloom), and this idea also is supposed to force leading according to one's own screen, which means that the shooter doesn't have to worry about latency like they did in H3 (I've already reiterated that). So, it's less complicated than H3, even when you consider lag, because all possible systems would have possible lag. But I do agree with you about the sniper being overpowered, and that turning it into a laser with about 3 shots (in addition to its old function) was stupid, but its anti-infantry power could be balanced by reducing its clip quantity to 2 or placing it in the middle of a map.

Tantric Echo, non-host xboxes would not send information directly to each other in any of the two real or the hypothetical systems. There would not be more variables because the non-host boxes would each calculate their own fraction of what the host box would have had to calculate in H3, effectively reducing the number of bullet trajectory models that the host box would have to calculate to the host's own bullets. The information transferred for shots fired (once again, hit or no hit) is much simpler than from H3. I don't think I can explain further, nor do I want to anyway.

Also, the BR was simply not more powerful than the DMR. In my TU thread reply post I pointed out that the precise rate of fire increases as the target gets closer. I don't see why anyone can't understand this. A DMR user could consistently kill a rushing shotgun faster than the user could kill another, more distant DMR user. Bloom actually makes the DMR a counter to close range weapons. The shotgun's kill range was increased slightly in my experience, and there is sprint to make it seem more effective (although in both games the only way you wouldn't be taking a risk with the shotgun is if the enemy walked into you- didn't see you crouching around a corner). Before the TU update, the precise (fully pacing) kill time of the DMR seemed to me to be longer than that of the H3 BR, but it doesn't matter in Reach because the only other mid-range weapon is the needler (which could beat a rifle in both games- tell me if you can think of another mid-range weapon). Bungie made sure that the bloom didn't hinder it at long range by making crouching curtail bloom and scoping increase accuracy. Hasn't anyone played BTB before? The BR had a lesser range than the DMR considering (relative to) how far you could see and reasonably aim at an enemy without a scope in both games (think about why that's important, I won't spell it out like I usually do).

 

the re: overall good link seemed to be describing hitscan- saying that "the bullets are so fast that they are spent in one frame" is exactly hitscan. A frame is a processing instant, so saying that the bullets are so fast is a way to help us understand what it would be like, when really the speed is irrelevant, and abstract. Ricochets in a virtual world don't require time, but I guess that this is what you were saying in different words, Nutduster.

For me, leading shots would be no more complicated than H3, and hearing that bloom has another negative impact is frustrating when I also remember how many people still want it in the game. I'm surprised though that you didn't consider what I typed about long range DMRing; perhaps most posters on this site play only small 4v4 maps.

Think about this: the scale of Reach BTB maps and DMR range is so enormous that if you had to lead a considerable amount (I'd say 2 body widths ahead of a srafing target) at the extent of the range at which I have racked up many kills with a DMR (it's still precise at no aim assist ranges scoped/crouched), the distance that it would travel in one frame would still be quite long, such that DMRing without a scope wouldn't need leading at all, and that conscious leading wouldn't be necessary from spawn to spawn on Countdown or such 4v4 maps

 

What I meant by "exactly hitscan" was that the provided link described hitscan, because posts after that link seemed to be ambiguous on what the link meant by "so fast..." I didn't mean that an infinitely fast bullet was indicative of hitscan, but rather that hitscan needs an infinitely fast bullet (unless one considers the hypothetical system). I thought that I had demonstrated that I understood what hitscan was in my previous posts.

I was going to try to understand 4shot's first sentence before I read on and found out that 4shot was a troll.