I know that many game engines like Unity3d use scripting languages like c# or java script but does that mean that a game engine is just an interpreter?
If so, does that mean that if I move the executable of a game made with Unity to the folder of another game made with the same engine then the game will run fine because all the engine is doing is interpreting the code?
If not does the engine just ship with a compiler and turns scripting code into compiled code?
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 Data\Managed folder.
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.
Some platforms don't allow runtime generation of code, either due to capabilities, permissions, or policy, so for these platforms Unity uses Ahead-of-Time compilation (AOT) to build executable machine code (or for WebGL, a low-level dialect of JavaScript called asm.js, via Emscripten).
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.
Most game engine packages simply build/compile the code you write. But engines that let you use Lua for example are parsed and interpreted to the underlying system your engine is build with.
The game engine is at its core nothing more than a heap of libraries working together. You can still build scripting environment on top of you game, regardless of engine.
If so, does that mean that if I move the executable of a game made with Unity to the folder of another game made with the same engine then the game will run fine because all the engine is doing is interpreting the code?
No. Unity builds an executable containing project specific compiled code.
If not does the engine just ship with a compiler and turns scripting code into compiled code?
Scripting languages are bound to your source code. When you parse your script under the hood there are all sorts of calls made to your game. For example you can have a function to spawn enemies -> in your implementation you expose this function to your scripting environment. Then when you call this function in your script after being parsed it actually calls the "native" function to spawn an enemy.
Here is a good answer.
