I am starting with game dev using Unity3d and I can see there's 3 supported languages for creating scripts: C#, unityscript and Boo...
although, coming from a web-design past I am obviously used with javascript, but after few attempts I could notice Unity3d doesn't really have full support to the script language and some elements like new Date().valueOf() and some other statements within methods such as the attribute arguments and many other won't work properly, also it seems my file can't have a wrapper method that envolves all the other methods like:
(function (scope) {
function Start() {
...
}
...
}(this));
and when using something like new Date().valueOf() which is valid in JS I get:
MissingMethodException: Method not found: 'System.DateTime.valueOf'. Boo.Lang.Runtime.DynamicDispatching.MethodDispatcherFactory.ProduceExtensionDispatcher ()
So perhaps the compiler turns that initial 'unityscript' code into Boo language? so perhaps Boo is the right 'native' choice and maybe unityscript itself isn't the best way to go when developing unity3d apps?
I was thinking on a language that has full support to all known native classes and methods which will work without problem?
Sorry for any errors mentioned above and please let me know what you think.
Unity doesn't use 'real' Javascript per se. See:
http://forum.unity3d.com/threads/1117-Javascript-Version
UnityScript is based on javascript 2.0. There are a few things missing (switch statements, etc.), but they get half the speed of C++, which is way faster than Mozilla.
Once you get used to it, developing in 'JS' for unity is very very fast and flexible...but of course, if you're going to develop native components, or interface to anything in C, you'll need to use C# (in the end, C# is not difficult to learn).
If you want to be a developer in Unity and build a career on it, learn C# and use it - don't waste your time with UnityScript. You can use C# outside of Unity for programming. If your main career is already web development (or will be), then continue using javascript because ultimately C# and UnityScript have the same functionality but C# is much more widely used for programing games and applications.
The majority of the assets on the store that I have used are C# or offer both JS and C#. Mixing between the languages creates serious dependency problems because in order to use a class in either language it has to already have been processed by the Unity script loading order. To use a Javascript defined class in C#, that script file must have been processed prior to the C# script file. If the javscript class then later needs something from the C# class, you would have to find ways around it because its simply no longer possible from the javascript file. Unity has ways to define the script order.
I thought that I would warn you about mixing C# with UnityScript because if you don't focus on one or the other, you will run into this problem. Ultimately, C# is the middle ground between ambiguous languages like VB and JavaScript, and pedantic languages like C++ (I have a C/C++ background of about 10 years).
Your title "What is the best xxx" leads to opinionated answers, but I am trying to give the best advice possible without being subjective. C# will allow you to continue, even if Unity were to go away a year from now. UnityScript/JavaScript would only allow you to move into being a web developer. A C# developer can easily move into UnityScript/JavaScript, but the reverse is much harder (not impossible, just more difficult).
You should use c#. It is popular, mature, native to .NET. c# is what big teams use. Learning c# will be useful in the future. JS in Unity3D is not real JS as already mentioned and nobody heard of Boo.
JS is the most popular language for use with Unity. But the language is implemented in Mono, and so any restrictions in that implementation are going to affect Unity scripts too.
I don't know how the Mono implementation of JS works, but judging from the error message, it uses datatypes initially defined for Boo, at least. However, that doesn't mean that JS is "turned into Boo". Both are compiled into the same bytecode, which is JIT'ed and run by the Mono runtime. So neither language is "more native" than the other.
Checkout advantages and disadvantages of using c# and Java script from here.
C# is little bit faster than JavaScript and you get extra features provided by C#. You can get peoples opinion from here.
Developing with c# has advantage of Visual Studio 2010. It provides better code completion feature than Mono develop.
In JavaScript only, variables can have an unspecified type. This only occurs if you do not assign a value while declaring the variable.
Performance is slower with dynamically typed variables, and you can run into casting problems. Iif this is a concern, use #pragma strict.
Related
Basicly, I want to create code that I can compile from a STRING that I will be loading from a file.
Is that even possible?
I did my research and I couldn't find any answers.
Reading your follow-up comment, it sounds like what you would be looking for would be a scripting language rather than compiling C# code dynamically. A scripting language allows you to pass in and execute code as a string, while also allowing to tie in your current execution to that code. For instance, you can pass in the character's current health to the scripting language, and then read back the character's current state (dead? immune? etc). The two most popular languages to do scripting for games are Lua and Python. Both of these languages have .NET libraries/bindings to allow them to be used within C#.
It has been a bit of time since I have set up my own project in C# with Lua, but I believe this tutorial looks very similar to what I was using, and therefore how I answered my question (ie, being able to closely bind them). However, searching Google for "lua C# binding" or "python .NET binding" will give you lots of libraries and tutorials. Which one you ultimately decide upon really comes down to which of those two languages (though there are bound to be many other scripting languages out there as well) you feel more comfortable with using.
I suppose, as EZI said above, it would be possible to compile C# code dynamically. But from your question, it sounds like you'd be looking for a scripting language instead.
I'm programming a computer game in C#/Mono using OpenTK library. I want to use Lua for scripting for the game, so also those who know nothing about C# can edit the scripts, levels, etc. However, the problem is, that I can't find any way how to use Lua with C#/Mono. I found amazing LuaInterface, however it doesn't work on Mono. I've tried it and it works on Windows, but it doesn't on linux (Ubuntu). Replacing lua51.dll with linux alternates doesn't simply work.
I'd like to ask if there's any suitable way for using LuaInterface with Mono (I didn't find any source codes of LuaInterface to edit and rebuild it; I also heard that old versions of LuaInterface do work on Mono, however I didn't find them anywhere for download), or if there's any other suitable library for C#/Mono that you used before and you know it works. I've been searching for a long time, but I didn't find anything and I don't want to spend weeks programming it myself.
I guess it'd be however possible to use C# for scripting rather than Lua, but I don't like that idea very much, although I don't know why.
There is a feature in .Net (which is also included in Mono) called Dynamic Language Runtime.
I don't know about Lua being supported, but there are DLR implementations of Python and Ruby - both of these work on Mono as well as on Microsoft CLR.
Check out this question for information about using C# as scripting language.
EDIT: Actually, there is an IronLua project, but I don't know how complete it is.
You can use lua grammar and this answer as way to find compiler generator which creates c# code. As I think it is the best and the easiest way to make support for external language support. Why? You can fast add any events for grammatic constructions and add any language extensions you want.
I'm trying wrap my head around all of the different scripting technologies for Windows (what are they, and which are the most common) and ultimately to figure out what type of scripting to add to my application.
I've read that with .NET 4 it's easy to make your program scriptable via dynamic languages like IronRuby and IronPython (or even VB or C# which might be more confusing for a user?) My understanding is that pre .NET 4 the way to add scripting support for your application was to make it a COM/OLE object so people could use vbscript, winbatch, shell scripts, or another scripting language (or really any language that supported COM) to control your application? What are the common scripting languages use? I've heard a lot of people talk about VB for Applications. Is that a dynamic language or a compiled language and to allow my application to be scriptable via VB for Applications would I have to support COM/OLE? I think I'm leaning towards supporting IronRuby and IronPython since it seems simple to implement support for them, but can those languages also be used to script Windows or other applications in general (and thus scripts for your application could have more features than what you laid out)? How would you go about designing your application to be scriptable?
I know that seems like a thousands questions, but really what I'm looking for is just an explanation of the scripting technologies for windows (what are the main differences, how frequently are they used) and which ones are the most common/standard to support when making your application scriptable?
Thanks in advance everyone!!
I think it depends on what you are trying to do. Are you trying to create dynamic objects in your apppool or view the values of something in your memory. If you need access to you objects then I would say maybe you could put a scripting window in your program. If you are just trying to configure certain aspects of you program you and look at adding modules to windows powershell for your admins. That seems to be what microsoft is doing for things like sharepoint and sql server. I would look up if powershell can fit your needs so that users can use the language they are confortable with and write there own scripts but if not then take a look at adding one of the dynamic languages to your app. If slashdot is to be believed today then Microsoft is not going to be persuing them as agressively.
Scrolling Game Development Kit 2 will actually compile code entered in the UI rather than interpret it as script. (It uses the C# compiler provided with the framework.) It can then run and reflect on that code at runtime. Have you considered a solution like that?
I've been jumping from C# to Java an awful lot and the "differences" between the two are a bit of an annoyance.
Would it be possible to write a set of extentions/plugins that would merge the two languages syntaxes.
I'm talking about adding either IDE support or using language constructs that would for example:
treat these two lines equivalently:
System.out.println("Blah");
Console.out.writeline("Blah");
Automatically notice that when you type in string you mean String
Recognise common API calls and translate them in the background.
The end goal being to be able to write a java/C# program and to pick at compile time which VM/Runtime you are targeting.
If you could do this would it be a good idea?
If not why not?
The two languages are so similar it's painful in some aspects but in other aspects they are really different.
I've seen Code that will translate a C# project into Java and I'm assuming there is probably the reverse, what I am proposing is a middle ground, so we can all just "get along".
No, absolutely not. Certainly not in the languages themselves (as implied by the title) and preferably (IMO) not in the IDEs (as requested in the body).
They are different languages. The idioms and conventions are subtly different. I don't want to be thinking in Java when I'm writing C# or vice versa. I believe developers should be actively encouraged to separate their thinking. It's not too hard to switch between the two, but that switch should be present, IMO.
While I totally agree with Jon Skeet, if you must have this why not create your own library of Java API so you can create System.out namespace which has a method call printLn which calls Console.Writeline()?
That gets you close to what you want.
Just because Java and C# share some similar syntax you need to see past this and think in terms of Java Platform and .NET Platform. The two are distinctly different, so my answer is definitely not.
There actually already is a Java language for the .NET framework, developed by microsoft: J#
This way you get the java-syntax but you are still developing with the .NET framework.
But i am not recommending anyone to use it.
I knew Java before i knew C# so i tried out J# because i thought it would be an easier transition. At first I liked it but after I tried C# I'm never going back. First of all, nobody uses J# so it's kinda hard to find examples and tutorials. Second, C# has (IMO) much more convenient syntax, specially for events, properties, lambda, anonymus methods and alot of other things, it's also being updated every now and then with even more syntax sugar which i don't think J# is.
Maybe if you often write Java and sometimes have to write a .net app it might be a good option.
I think no. I also switch from java to c#. But if the syntax is identical was is to stop someone from trying to compile c# in a Java compiler, or vice-versa.
Visual Studio actually ships with a Java to C# converter, which tries to do some of the things you mention. Unfortunately it fails miserably (1) for anything beyond the simple hello world application.
Despite being very similar on the surface, there are many significant differences between Java and C#, so you would achieve very little by doing what you suggest imo.
(1) To be fair, it actually does a fairly good job if you consider the limitations given for such a task, but in practice the resulting code is of limited use and you have to do a lot of clean up after the conversion.
Firstly what you are describing is not a difference in language syntax but a differences in class libraries. Both languages are relatively simple in terms of keywords and features but understanding or knowing the libraries and how they operate requires considerable learning.
The mistakes you are describing are things that the developer should not be making to begin with - the IDE should not be guessing. There are going to be many cases where you can't easily / trivially translate between java or dotnet. In the end a skilled developer learns and knows when and which class libraries to use.
Actually in the beginning there was no dotnet - microsoft was behind java. They however proceeded to change java in ways not compatible with the java plstform standard. To paraphrase sun sued microsoft and won I'm court. Following that ms proceeded to create dotnet and particularly c# which became microsofts VM platform. Of course along the way a whole stack of things got changed. Microsoft introduced many things which broke Javas run anywhere etc. They have done the same thing with dotnet which have cause problems for the mono team to be able to faithfully reimplemwnt everything for other non windows platforms.
• String vs string.
• lowercase method names (java) v uppercase method names(dotnet).
• Giving java keywords new names - "package".
In the end dotnet was microsoft response so they can control the platform and do their own thing instead of following a standar
I have a little game written in C#. It uses a database as back-end. It's
a trading card game, and I wanted to implement the function of the cards as a script.
What I mean is that I essentially have an interface, ICard, which a card class implements (public class Card056: ICard) and which contains a function that is called by the game.
Now, to make the thing maintainable/moddable, I would like to have the class for each card as source code in the database and essentially compile it on first use. So when I have to add/change a card, I'll just add it to the database and tell my application to refresh, without needing any assembly deployment (especially since we would be talking about 1 assembly per card which means hundreds of assemblies).
Is that possible? Register a class from a source file and then instantiate it, etc.
ICard Cards[current] = new MyGame.CardLibrary.Card056();
Cards[current].OnEnterPlay(ref currentGameState);
The language is C# but extra bonus if it's possible to write the script in any .NET language.
Oleg Shilo's C# Script solution (at The Code Project) really is a great introduction to providing script abilities in your application.
A different approach would be to consider a language that is specifically built for scripting, such as IronRuby, IronPython, or Lua.
IronPython and IronRuby are both available today.
For a guide to embedding IronPython read
How to embed IronPython script support in your existing app in 10 easy steps.
Lua is a scripting language commonly used in games. There is a Lua compiler for .NET, available from CodePlex -- http://www.codeplex.com/Nua
That codebase is a great read if you want to learn about building a compiler in .NET.
A different angle altogether is to try PowerShell. There are numerous examples of embedding PowerShell into an application -- here's a thorough project on the topic:
Powershell Tunnel
You might be able to use IronRuby for that.
Otherwise I'd suggest you have a directory where you place precompiled assemblies. Then you could have a reference in the DB to the assembly and class, and use reflection to load the proper assemblies at runtime.
If you really want to compile at run-time you could use the CodeDOM, then you could use reflection to load the dynamic assembly. Microsoft documentation article which might help.
If you don't want to use the DLR you can use Boo (which has an interpreter) or you could consider the Script.NET (S#) project on CodePlex. With the Boo solution you can choose between compiled scripts or using the interpreter, and Boo makes a nice scripting language, has a flexible syntax and an extensible language via its open compiler architecture. Script.NET looks nice too, though, and you could easily extend that language as well as its an open source project and uses a very friendly Compiler Generator (Irony.net).
You could use any of the DLR languages, which provide a way to really easily host your own scripting platform. However, you don't have to use a scripting language for this. You could use C# and compile it with the C# code provider. As long as you load it in its own AppDomain, you can load and unload it to your heart's content.
I'd suggest using LuaInterface as it has fully implemented Lua where it appears that Nua is not complete and likely does not implement some very useful functionality (coroutines, etc).
If you want to use some of the outside prepacked Lua modules, I'd suggest using something along the lines of 1.5.x as opposed to the 2.x series that builds fully managed code and cannot expose the necessary C API.
I'm using LuaInterface1.3 + Lua 5.0 for a NET 1.1 application.
The issue with Boo is that every time you parse/compile/eval your code on the fly, it creates a set of boo classes so you will get memory leaks.
Lua in the other hand, does not do that, so it's very very stable and works wonderful (I can pass objects from C# to Lua and backwards).
So far I haven't put it in PROD yet, but seems very promising.
I did have memory leaks issues in PROD using LuaInterface + Lua 5.0, therefore I used Lua 5.2 and linked directly into C# with DllImport. The memory leaks were inside the LuaInterface library.
Lua 5.2: from http://luabinaries.sourceforge.net and http://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download
Once I did this, all my memory leaks were gone and the application was very stable.
The main application that my division sells does something very similar to provide client customisations (which means that I can't post any source). We have a C# application that loads dynamic VB.NET scripts (although any .NET language could be easily supported - VB was chosen because the customisation team came from an ASP background).
Using .NET's CodeDom we compile the scripts from the database, using the VB CodeDomProvider (annoyingly it defaults to .NET 2, if you want to support 3.5 features you need to pass a dictionary with "CompilerVersion" = "v3.5" to its constructor). Use the CodeDomProvider.CompileAssemblyFromSource method to compile it (you can pass settings to force it to compile in memory only.
This would result in hundreds of assemblies in memory, but you could put all the dynamic classes' code together into a single assembly, and recompile the whole lot when any change. This has the advantage that you could add a flag to compile on disk with a PDB for when you're testing, allowing you to debug through the dynamic code.
Yes, I thought about that, but I soon figured out that another Domain-Specific-Language (DSL) would be a bit too much.
Essentially, they need to interact with my gamestate in possibly unpredictable ways. For example, a card could have a rule "When this cards enter play, all your undead minions gain +3 attack against flying enemies, except when the enemy is blessed". As trading card games are turn based, the GameState Manager will fire OnStageX events and let the cards modify other cards or the GameState in whatever way the card needs.
If I try to create a DSL, I have to implement a rather large feature set and possibly constantly update it, which shifts the maintenance work to another part without actually removing it.
That's why I wanted to stay with a "real" .NET language to essentially be able to just fire the event and let the card manipulate the gamestate in whatever way (within the limits of the code access security).
The next version of .NET (5.0?) has had a lot of talk about opening the "compiler as a service" which would make things like direct script evaluation possible.