I've noticed a few tools which talk about using scripting for game logic, but the scripting is done through a 'real' language. For example Unity3D supports scripting through C#. How is this 'scripting' different from just writing your app on top of an existing engine?

I don't think there's a difference -- it's just an API, or more like a framework in most cases. Like, it doesn't matter what .NET is written in, people who use it can choose whatever .NET compatible language they want to call into the framework.

I think the distinction is basically that scripts have only higher level access to stuff like memory for ease and safety. Additionally, scripts can generally be changed on the fly, so you don't have to rebuild the core (or rebuild at all maybe) every time you tweak a gameplay variable. C# makes sense to me because aside from the compiling thing, it qualifies as a pretty gentle, safe, yet powerful language.

Scripting languages such as Lua, Python and AngelScript a 'real' languages in much the same way that C# is.

The difference is usually that the scripting language runtime is embedded into the main executable. With Unity for example the engine is written in a lower level language (assuming its C++) and mono is embedded into the engine. This means that scripts can be written without having to recompile the entire engine or even without having to have access to the engine code or know how it works. It also means in some cases that scripts can be written on the fly as the game is running like in the Gamebryo Lightspeed engine.

Most game engines use the philosophy of everything is an Actor(Entity/GameObject whatever) which usually just inherits and extends from a base class. Based on that, you have tons of Actors to write for even the moderately sized game and a significant portion of those Actors have very simple functionality.

After writing many Actors using C++ in my game engine, I arrived at the conclusion that C++ isn't cut for this, it's just too tedious and annoying, you find yourself spending most of the time worrying which source should include which headers and what parameters should the constructor take...etc.

When allowing developers to write high-level scripts to define their Actors, you get a very good productivity bonus because you can limit the repetitive stuff that the developer has to write for every Actor.

I find that the same analogy also applies to GUI code, because in effect, the building blocks of any GUI makes it pretty much similar to Actors, for starters all GUI components inherit from a base window component (most APIs do that), for that reason, the process of building a GUI application straight-forward (hard coding it) is inferior compared to building the same GUI application using a visual editor where you double click components to add functionality to pre-written skeleton code.

So I think it's more than just modifying scripts at runtime.

Quote: Original post by Buster2000
With Unity for example the engine is written in a lower level language (assuming its C++) and mono is embedded into the engine.

I was under the impression that Unity used Mono's static compilation feature, and compiled your C#/JScript.NET/Boo code into native code rather than run it on an implementation of the CLR.

you do not have to recompile every time you change the code.
And other people could mod your game with the script.

I think it does use static compilation but I thought this was only when using it on the iPhone as Apple dont allow you to run any VMs or JIT compilers.