Primarily video games are a collection of calculus, trig, physics and algebra to have various things interact with eachother based on user input.
First off, games are multi-threaded, so at any point there are hundreds or thousands of messages being sent to the cpu intermittently by various independant functions and methods. Older 2-d games would have everything on a XY cartesian plane, with various artwork drawn to the screen in specific positions. input/output/ai subroutines would have players/characters change their specific x/y-axis position on the screen. Each character, enemy, and item have a "hit box", a set of XY co-ordinantes to test if there is a collision. Each subsequent input command would run against a function that changed the position of your character's sprite in the game world. Then a subroutine would run to take your character and test if any hazards OR power-ups were in your "hitbox", and if there is a "hit" it would run a subroutine to hurt/kill/powerup your character.
3-D gaming is more complex, and is obviously on an XYZ plane. Most gaming require complex pre-written engines that a lot of us could never program ourselves, it takes hundreds of people and it's inner workings would be impossible to explain here in a reasonable length.
99.9% of all games made in this day and age are done in an OOP programming language(C++, C#, Java). If you don't know what OOP means, you can check out wikipedia or many programming websites. Everythign in the game is represented by an Object, with individual variables and methods. Every item in the game is an object, with variables for that specific object. It can be applied to any game, but I think Fallout 3 makes a good illustrated example:
A rfile object has a value for it's name, it's condition, it's weight, it's minimum and maximum potential damage, it's 3-d model, it's textures, it's in-menu sprite etc. It inherits it's status as an item and a gun from it's ancestor objects, and a specific kind of rifle with unique functionality could be derived from this rifle object. Each rifle object created and used in the game is a unique object with a unique memory address. When you drop the rifle on the floor, the reason it stays there is the game engine keeps the reference to that specific object and always renders it there(many games with disapearing items or bodies have an engine that deletes unused objects when required)*. The rifle will have methods to interact with the game world, and interaction with the rifle is done only through it's methods.
A player object would have all it's variables to track it's data, but also contain references to a collection of objects. Your inventory is just a set of pointers to objects in the games memory. Your player's object has equipped item simply means the player's Attack() method will interact with the equipped item's attack() method. If you were to run the rifle's Attack() method, it would ask the player's inventory object to run the method to check if there is ammo to do so, then it would calculate the path and trajectory and factor in physics etc. Then it would create and fire a bullet object that would determine if there is a "hit" with another object's "hit" box. and so on.
OOP allows a complex system to develope which can mimic real-world enviroments.
A lot of this was written in generalities to give you a vauge idea of how things are done. A lot of game projects are far, far, far more complex. Very unlikely I even wrote the method of attack and fire in some games completely wrong, because I don't know how all FPS code runs and looks like.
Here's a cool look back on the original Wolfenstein with it's original creator:
http://www.youtube.com/watch?v=amDtAPHH-zE&feature=youtu.be
Hope this helps.
*as an aside, the reason old SNES/GENESIS and before had enemies that "respawned" is it helped with processor and memory issues to just have a subroutine recreate an enemy at a specific part, rather than to create and track that enemy over an extended period. If a Mario level had to create and track if each enemy is a live, and it's status for the entire level on load, that game would be impossible to play with that hardware.
Similarily the reason there is a "draw distance" in 3-D games is the same as above, there is limited processing and memory capabilities. Each time an object in the distance disapears, that object is distroyed. When they show up again, it has been recreated. There is never to many objects and models clogging up memory and processing.
