In addition to what Josh Petrie mentioned: if you're looking for more advanced ways to aim weapons, the center dot in your bottom image is also called a "pipper" in real-life applications.
This especially applies when some device is actively predicting where an arcing projectile will impact, like a bomb or grenade, instead of simply showing which direction ...
Simple answer: cheat or don't be that accurate!
If you've played some shooter online, you'll most likely have experienced the so called "rubber banding" if your connection to the server is bad.
This is caused by your client correcting your position from time to time.
Basically, what happens on the two sides:
The server will track your movement and send ...
Shoot a ray from the camera through the center/reticle into the world. Find out where in the world it hits. Fire the bullet from the gun's muzzle at that point instead of straight out of the gun.
Bonus points for animating the hands and gun to point in that direction while aiming around so the bullet still looks like it's firing straight out of the muzzle ...
Always assume the client is a lying, cheating, bastard.
The client is responsible for:
Receiving input from the player (and sending commands to the server, which validates)
Rendering the known gamestate
The client is in no way allowed to calculate the gamestate except as client-side interpolation for smooth animations.
The main problem is tunneling.
Game physics engines typically use discrete collisions. That means they advance all the bodies by one short time step, then check if they're intersecting, and handle collisions in response.
This works well for medium-sized objects at medium speeds.
But if you have a small object (like a bullet) moving very fast (like a ...
When dealing with different frames of reference interacting with each other instantaneously, you have to compromise somewhere, you cannot have everything consistent everywhere; that's a fact of life. The scenario you have outlined is basically this: the shooter thinks she has hit her target, but the target thinks she has successfully hidden behind an ...
To measure framerate you need two counts:
How many frames (not draw calls) have passed, and,
How much time has passed.
Your framerate is therefore calculated as:
frames / time
There are a few subtle complexities to this.
First thing is that you need a good, accurate, high resolution timer. You don't say what platform you're on so I'm not going to make ...
There are many reasons a designer/programmer would want to draw the crosshair on the exact center of screen, or a little lower. A hybrid system may even be implemented, taking advantage of the properties of these two systems in a game fich of different weapons, vehicles, interactive spots, and so on.
Drawing the crosshair centered or lowered can depend on ...
If you haven't already, I suggest you to read these two deep but understandable articles : https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking and http://fabiensanglard.net/quake3/network.php.
These explain why it's advised to use 'fixed interval' packet sending.
To be short, it's in fact mainly important for packets sent by the server.
When we implemented our networking engine we exploited a number of compression techniques:
First we write all of our snapshot bit-wise: bools are only 1 bit
instead of 1 byte (or more depending on compiler). We wrote a
bitstream class that reads and writes data to a stream. This saves a
fair bit of data all alone when packing flags down. For an example of ...
To have the gun heat up quickly but reach its overheat threshold slowly, you could take the gun's current temperature into account in the heat dissipation, rather than having a constant rate of heat dispersion. That's actually how it works in the real world: the rate of heat / thermal transfer is proportional to the difference in temperature. Wikipedia has a ...
Why has this happened?
This HASN'T happened.
Duke Nukem 3D and Unreal Tournament (to use your examples) were creative games, both were trying lots of exciting new things, in new themes, in new ways.
But most other games from those eras weren't doing that.
Quake 1, for example, had a pistol and a shotgun and a machine gun and a rocket launcher and etc. ...
This is what we ended up doing:
Detect player clicks button to shot missile
Immediatley simulate rocket visuals on client
In parallel, send command to server
Once predict hit something, destroy missile (no explosion)
Receive fire command
Save client ping data on missile
Fire missile, each frame accelerating the missile until we've ...
You're probably looking for a combination of the following concepts:
Particle system for the bullet hitting a surface (i.e. sparks on hitting metal, wood splints on hitting wood etc.)
Decals to allow projectiles to leave hit marks
Aside from Josh's answer you have to keep in mind something else: players know what each of these weapons does. If I pick up a sniper rifle I know what I can probably do with it (shoot long distances, scope) and when I pick up a shotgun I also know to use it on shorter distances. If these weapons are replaced by say a deathRay and a doomshooter I might not ...
You can use a model. Often, HUD elements, sometimes including weapons, are rendered seperately from the environment. In the simplest example you'd set up the animation so that the ironsights line up with the zero-axis, and align the model's zero axis with the camera.
Using Unity as an example, you'd put the weapon in the HUD layer so that it's drawn with a ...
Head bobbing consists of transformations to the camera to imply human movements of the player. The player would be using his/her feet to step from one foot to the other. This causes all sorts of changes to the viewpoint of the player but we're just going to look at a few.
Let's define a function to call with some time value which we can then plug into an ...
Most games allow you to manually spawn an invisible bot, and a lot of aimbots don't filter these out.
By spawning 3 different bots and checking if the user aims at them, you can check whether they have aimbot or not.
Technically changing the FOV isn't zooming, but it does the same thing, so let's not take that into account.
You can calculate the size of the view plane where the object lies using trigonometric functions:
width = tan(FOVX) * dist
height = tan(FOVY) * dist
(Make sure the angles are in radians, and FOVX is the horizontal FOV, which is equal to FOVY * ...
The best field of view depends on many variables. For instance, how large the monitor is, are you using eyefinity, is the aspect ratio nonstandard, how far you are from the screen.
Besides that, different people have different preferences for it, leading to some people feeling simulation sickness at 90 FOV while others feel it at 75 FOV.
There are two ways of achieving this, one would be a variable timestep, with that the game would seem consistent, regardless how fast the computer of the player is.
The other way would be a fixed timestep, there you will know how long each single timestep would be, also regardless how fast the computer is.
For more information on Game loops you can look at ...
I'd like to examine two multiplayer class-based FPS games with support classes as case studies: Wolfenstein: Enemy Territory and Team Fortress 2. Both have separate classes that give health and ammo, and I think it's helpful to consider both types of support.
Enemy Territory has three support functions - healing, reviving and ammo - given by two classes - ...
There are a few better ways to get players to share ammo, however your your example mechanisms wouldn't work that well, example 1 has the weakness of not really giving any reason towards player B has no reason the disperse ammo and therefor might not decide to share him ammo at all, example 2 can either be used for some really annoying grieving and could ...
Your weapon needs two values: the current heat value (int, probably) and a cooldown timer (float). Initialize both to 0.
When a shot is fired, add the bullet's heat value to the gun's. Cap it at 100. When this value reaches 100, set the cooldown value to your cooldown period time in seconds. Reduce this by your time delta every frame, clamped at a ...
As far as I know all those devices are able to show up to 60 fps, however, for mobile development you should think differently:
You've tagged your question with 'directx', but this won't work. iOS as well as Android both support OpenGL ES only, which is a more lightweight version of the desktop OpenGL.
The more frames you display, the more work the GPU has ...
More than likely, it works like this (major speculations):
Client sends Shoot command to server, along with parameters such as
position, direction, velocity, type, etc...
Server accepts command and broadcasts to all players on next frame.
Clients render the shot.
If shot hits a player, server broadcasts kill.
Can't tell for sure though, as I don't have ...
Note that most of us cannot answers specific questions about either of the games you mentioned. We aren't the authors of that code and can't reasonably know exactly how it was built.
Generally speaking, there are multiple approaches.
One approach is that the server is authoritative on everything. When a client wants to fire a weapon a round-trip to the ...