For the case of Unity specifically, C# and UnityScript code is compiled to what's called CIL, or Common Intermediate Language, a kind of "pre-digested" version of the code that's not quite machine code yet, but easy to translate that final step.
For desktop versions (Windows, Mac, and Linux), this intermediate representation can be stored directly in the built game as a .NET-style managed assembly. On Windows you'll see them as
.dll files inside your game's
When you run the game, this managed code is Just-In-Time Compiled (or "jitted") into actual machine code for your specific hardware. This is the usual flow for .NET applications on Windows, though Unity uses a cross-platform runtime called Mono to perform the same trick everywhere.
The ahead-of-time / just-in-time distinction doesn't make much of a difference for most things we do in games.
Hypothetically, compiling just-in-time lets the game take advantage of features of the specific CPU that it's running on, without us needing to generate separate builds for every variation of chip out there, but this type of optimization is generally low-impact compared to, say, making good architecture and algorithm choices, like picking an efficient pathfinding strategy for our game AI.
There are some (questionable) tricks we can pull on platforms that can compile code at runtime which won't work on platforms where our machine code must be generated in advance. There are also some gotchas described here where we need to hint the ahead-of-time compiler to generate certain code that it can't automatically detect is needed.
See this forum post for another explanation, going into a bit more depth.
Unity also does a compilation-like process for all your non-script content, like textures/sprites, sounds, meshes, scene files, etc., turning them into a format that's more readily processed by the game at runtime. This is called data baking, and I explain a little about the reasons for it here.