• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Mordynak

C# Scripting or Programming

14 posts in this topic

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!

0

Share this post


Link to post
Share on other sites

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

 

Thanks for the answers everyone!

1

Share this post


Link to post
Share on other sites

 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. 

-2

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites

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.  

1

Share this post


Link to post
Share on other sites

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".

1

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites

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. 

 

I'm sorry to nitpick, but C# is a language and while there are two notable compilers for it (MS VC# and Mono MCS), the language is the same. What you probably mean is that it doesn't use .NET but instead uses the Mono Framework, which implements the same standards and therefore _should_ behave more or less identical to .NET for all standard libraries but ships with a different set of non-standard libraries and services. Just because it should behave the same doesn't mean it does though, which is probably why they stick with Mono on Windows even though they could have used .NET.

1

Share this post


Link to post
Share on other sites

I'm sorry to disagree with you, C# is normally associated with C#.net and the MS VC# compiler... leaving the .net off is pretty standard in the industry and making special note that it is Mono C# using Mono MCS is standard. It's like when someone says they have an SQL server you don't ask them if they are using an MS SQL server or a MySQL server... MS SQL Server is assumed unless otherwise noted. Or when you say C++ you have to specify it's VC++ to indicate your using microsofts compiler or it'll be assumed to be gcc. Especially when C#.net with the MS VC# compiler are the tools used to set the standard.

Edited by Paragon123
-2

Share this post


Link to post
Share on other sites
Those are just YOUR assumptions. I would especially never assume any particular compiler when talking about C++, after having used nine different C++ compilers so far (DJGPP, Intel, Watcom, Borland, MSVC++, clang, SN Systems, gcc, and CodeWarrior).

I would wager that the first time someone experiences using multiple compilers or execution environments, they stop making such assumptions. Edited by Nypyren
2

Share this post


Link to post
Share on other sites

leaving the .net off is pretty standard in the industry and making special note that it is Mono C# using Mono MCS is standard. It's like when someone says they have an SQL server you don't ask them if they are using an MS SQL server or a MySQL server... MS SQL Server is assumed unless otherwise noted. Or when you say C++ you have to specify it's VC++ to indicate your using microsofts compiler or it'll be assumed to be gcc.

Those particular assumptions may be less common/popular than you seem to think; they're certainly not universal to the profession as a whole.

Taking a couple of specific examples, it would actually surprise me if a professional programmer assumed my C++ code was compiled with gcc simply because I hadn't mentioned Visual Studio; that's a completely alien assumption to me that I've never encountered.  Depending on what sort of programming is being done, there are probably plenty of programmers who wouldn't assume gcc OR visual studio unless they were explicitly told so.

 

If someone wants me to work with an SQL server, asking whether they mean MS SQL, MySQL, or some other variant would be one of my first questions; and at least in my own experience, the answer often isn't MS.

 

 

unity doesn't Actually use C#... it uses Mono-c# which tries to be as identical to c# as possible

 

C# is a standardised language, and you're using the same language either way.  While it may be noteworthy that Unity uses Mono rather than the .NET runtime, in my own personal experience most programmers would consider it to be incorrect to suggest that you're actually using a different language -- it's just a different implementation.

 

To reiterate the above, your own assumptions may be less universally accepted than you seem to think. smile.png

1

Share this post


Link to post
Share on other sites

I'm sorry to disagree with you, C# is normally associated with C#.net and the MS VC# compiler... leaving the .net off is pretty standard in the industry and making special note that it is Mono C# using Mono MCS is standard. It's like when someone says they have an SQL server you don't ask them if they are using an MS SQL server or a MySQL server... MS SQL Server is assumed unless otherwise noted. Or when you say C++ you have to specify it's VC++ to indicate your using microsofts compiler or it'll be assumed to be gcc. Especially when C#.net with the MS VC# compiler are the tools used to set the standard.

 

SQL Server is a specific product by Microsoft. If someone talks about "an sql server" then I assume they are talking about a specific instance of MSSQL aka SQL Server. The more general term over here seems to be "SQL database" even though it's slightly weird/wrong. Perhaps "SQL solution" would be better..

 

As for C++, I assume VC++ on Windows and GCC on everything else, unless specified. This is _usually_ true in the fields I'm working in. For C++ though, there's a reason to distinguish between compilers however. They have different levels of standards conformance, shitloads of language extensions and very different performance characteristics (both for compilation and result).

 

For C#, I don't make any such assumptions mostly because it isn't (as) meaningful. You can switch out one compiler for the other without knowing it was done. You can compile with MCS and just attach to the exe from VS and debug it. VS probably can't even tell that it was compiled with MCS. The same way, you can use a VC# .exe on Mono without problems. The difference is not in the compilers but in the runtime.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0