C# Scripting or Programming

Started by
13 comments, last by DvDmanDT 10 years, 2 months ago

Hi all. Getting into C# with the intention of making some simple games to get me started. I've been mainly using XNA to make little bits n bobs as I learn.

One thing is getting me confused though. Been reading up on Unity 3D and C#, and when talking about C# they refer to it as scripting.

So, is it a scripting language or a programming language? What is the difference between the two even? Is it called Scripting when used in Unity because its not the main language?

I'm sure it doesn't matter just wanted some opinions.

Cheers people!

Advertisement

A scripting language is just a programming language that is used for scripting. PHP, JavaScript etc are all programming languages, just that they are normally used in a scripting manner and are therefore called scripting languages. Perhaps it would be better to referr to them as languages suitable for scripting usage.

C# is normally compiled into an .exe or a .dll, but you can also compile a C# program/script/whatever from your own program and then run the result. This is what Unity (and many others) do.

If you've ever written programs that integrate four different languages at once (C++, C++/CLI, C# and F#), "scripting" starts feeling like a totally inadaquate description of what's going on.

The different parts of a program are all just as important as the rest. There is no "main" language. If the core game loop, rendering, and physics code happens to be implemented in C++, but the remaining 80% of the code is in C#, does the concept of "scripting" have any useful meaning anymore?

So, is it a scripting language or a programming language? What is the difference between the two even?

Meh, there isn't really a difference, all are programming languages without exception. A language is just designated as being a "scripting" language based on the context of how it's used.

For me a scripting language is just any language that is dynamically compiled/interpreted either at runtime or immediately (to give instant feedback as you code) by another application - usually to separate out a particular kind of logic (in Unity's case: game logic). Often it will be a different language to the one that is really hosting things, but that isn't a requirement (I saw a video of the Unreal Engine showing off dynamic re-compilation of C++ code, they were using C++ for their scripts).

As Nypyren points out, when you have a few different languages integrated together then the idea that any of them are for "scripting" is woefully inadequate.

That said, some languages pretty much always have to be hosted by another, Lua is an example that springs to mind. I dare say that there are ways to make a standalone Lua application but it is almost always loaded by some other language, usually C++.

OK cool. That's all I needed to hear. Pretty much what I thought was the case too.

Thanks for the answers everyone!

I thought the difference was originally used to compare compiled and interpreted languages. With c# and Java being in a sort of grey area since they are "compiled" into an "interpreted" language (CLR for C#, Java virtual machine code for Java). Interpreted languages where originally easier to use as scripting languages because the environment was much more heavily controlled by the interpreter... but now, because reflection is more common just about any language can be used as a scripting language.

Also, (even though they very likely could) unity doesn't Actually use C#... it uses Mono-c# which tries to be as identical to c# as possible (with the advantage of being cross-platform)... but technically works a bit differently deep under the hood.

Compiled vs interpreted is not relevant to how the terms were originally meant, though clearly everybody today has their own unofficial version of what they mean.

A scripting language is used to glue together functionality of a host application. C# is normally a programming language as the application itself is in C#. In Unity3D, the application (the engine) is all in C++ with a bridge to C# to allow hooking up the various C++ engine modules in interesting ways (making a full game).

Interpreted languages can still have "full" compilers (semantic analysis, optimization passes, etc.), like Java does. "Native" languages like C++ can be interpreted with something like Clint and it can be transpiled into JavaScript (which is interpreted). PHP is an interpreted language that can be transpiled into native code via the likes of Roadsend. Interpreters can also perform just-in-time (JIT) compilation, further blurring the lines between native and interpreted code. Even simple interpreted languages like Lua still have a compiler that has to parse the source and generate code for the VM. Outside of some simplistic command shells, there is no real language around that is literally interpreted from source at runtime anymore.

All in all, the line is vague and not clearly defined. It's mostly a matter of taste.

Sean Middleditch – Game Systems Engineer – Join my team!

Scripting languages were meant to be special purpose domain specific languages but as games became more and more complex and the availability of flexible complete high level embeddable solutions (Lua, Python, etc. ) were available people migrated to those or branched implementations of such for their own purpose.

Interpreted or compiled is more a matter of performance requirement, but "scripting languages" are still domain specific and you can very well have several scripting languages within a single game ( one for the AI for example, camera and another for gameplay logic etc ).

At the high level you can use any language as a "scripting" language but usually there is some requirement for high productivity which leads developers to create a domain specific language or API with am embeddable language and that is what eventually evolves to their "scripting" language.

I prefer to use the term "extension language".

Any language can be a scripting/extension language. It's a way that a language is used, not a description of the language itself.

Some languages were designed specifically for this purpose (e.g. Lua, JavaScript), but others can be forced into the role.

e.g. Half-Life 1 had a game engine written in C, which would then load user-written game code written in C++. The game was extended (scripted) using C++ code.

Unreal Engine 4 uses C++ in the same way, but they actually allow you to modify your C++ code at runtime, which is another feature that "scripting languages" are said to often have.

And yes, anywhere where I see the word "scripting", I mentally replace it with "programming".

And yes, anywhere where I see the word "scripting", I mentally replace it with "programming".


That's actually a good point. Too many game developers think awful thoughts like "we'll just add a scripting language and then a designer can do it!" ignoring the part where a majority of designers are not trained as programmers but "scripting" is still programming.

Just because something is an high-level language intended mostly for glue doesn't negate the need to be mindful of code structure or algorithmic complexity and such. Too many game developers have found out late in the product cycle that an engineer had to go in and rewrite or fix up thousands of lines of designer-written scripts. You have to provide some way for designers to configure game logic, certainly, and even the most "fool proof" of those are no match for designer ingenuity if they need to get something done you either chose not to support or didn't explain how to do properly, but a programming language is probably not the right choice.

Sean Middleditch – Game Systems Engineer – Join my team!

This topic is closed to new replies.

Advertisement