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.
Related
i have a nearly full developed program written in python it uses the Kivy framework which however does not employ a webplayer.
I want to migrate it to a webplayer and decided to try it on unity with ironpython.
This however does not work since the webplayer has a limited subset not the full subset from .net.
Sadly the unity community has little interest in python and cannot really help with this.
So my question is:
What else could i try?
could i write most code in python compile it to a library and access it from c# or has someone an other idea to integrate it with unity?
Is there a way at all with unity, if not what would you suggest then to make a python webplayer?
Note i want to use a platform which i can use to compile to mobilephones too thats why i did go with unity.
My company is looking into CXXI for creating C# bindings to C++ libraries which will be used in Linux Mono. The main reason is the ease of use and simple looking bindings code. The main problem with CXXI is that its not finished, has no documentation, does not even compile in Ubuntu 12.04 and after making it compile, the tests and examples supplied don't even run.......
I know using Swig or creating the bindings manually is probably better than using CXXI at this point. I am just wondering if anyone has experience in using CXXI and can share their knowledge before I discard CXXI and move on.
I've seen C# communicating with native libraries on several platforms(iOS,Android) through SWIG, IMHO I think that this is the easiest path
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.
I've been playing with Java for years as a means of developing quick and easy tools for repetitive tasks. I am not a true "developer" in the traditional sense, but I have lots of experience creating a wide assortment of tools and PoCs.
Unfortunately for me, I have noticed many shops are specifically looking for experience with C#, and not so many for Java. Even here on SO, there are more questions and more followers to C# related issues than Java. My preference will always be Java over C# simply for the cross-platform compatibility, but since the languages are so similar, I believe it would be beneficial for me to cross-train. I have already dabbled in other languages and scripts (VB and other BASIC flavors, Javascript, VBScript, ASP, JSP, PHP, etc.) so adding another isn't out of the question.
My current Java environment simply consists of a text editor (primarily jEdit for its plugins and layout) and homemade scripts to compile/jar my projects. I don't like to use IDEs because I want full control over my code and don't want a program writing code for me. (I also prefer to write my own code as opposed to using any sort of external library/package, if feasible. It helps me learn and greatly reduces unnecessary code.)
Therefore, what are my options for a non-IDE C# SDK? Libraries are obviously not that important to me. I've heard of Mono, which appears to separate the functions, but haven't tried it yet. What other SDKs exist that are similar to a simple Java SDK combined with a text editor?
Using an IDE doesn't have to mean anything writing code for you. I'm not generally keen on designer-generated code, but unless you decide to use a designer (or snippets etc), Visual Studio won't be writing code for you. Of course it will create a skeleton class for you when you create one, add the appropriate method signatures when you implement an interface etc - but is that boilerplate really something you want to write yourself?
I'd also suggest that your policy of not using external libraries is a bad one. I agree that it's useful for educational purposes to sometimes reimplement something, but it means that the code quality is likely to end up being worse... why would you not want to use code that has already been used and improved by many other people? Yes, you need to be careful about what libraries you use - but you really don't want to do everything yourself... not if you want to be productive, anyway.
I often use a text editor and command line myself for simple test code (e.g. for Stack Overflow questions) but I wouldn't dream of doing that for "real" code that I plan to keep.
Honestly, a lot of C# and .NET is about learning the tools; Visual Studio gives you a lot that you wouldn't be able to do with a text editor. There's a free version, and I highly suggest you check it out! People hiring will want to know that you're familiar with the tools they'll most likely be using.
You can just start with Notepad and csc.exe, the the command-line C# compiler that ships with the .NET SDK.
However, IDE is not necessarily synonym for code generator. I would download Visual Studio Express and start with empty Console projects.
Have fun!
Don't forget you can build/assemble C# projects using MSBuild and a .sln file if you really want. But the IDEs will make life a lot easier.
The IDE will not write code for you, it will help you writing code. Using libraries will help you concentrate on what you really want to program, not the things that already have been done.
Check into AvalonEdit, the text editor component of SharpDevelop. It is an open source text editor that has classes that could implement features such as intellisense and syntax highlighting. You would only have to use as much of it as you wanted and you could embed it anywhere you would use a text box control.
If you are familiar with Ant from Java then you could also check out NAnt to do your compile phase.
As far as I know, with Visual Studio you also get a command line C# compiler, csc. You could use a text editor and manually compile your C# code with that on the command line if you really want - that wouldn't be very practical however when your project contains more than a handful of source files.
If your project becomes bigger, you could use a tool like NAnt, which is a .NET version of the popular Java build tool Ant.
I agree with Jon Skeet about that your way of working is not very practical. If you are really looking for a software development job, you'd better learn to use the tools that other developers use. An employer will also not accept the fact that you'd want to write all the code yourself instead of using libraries. By using libraries instead of writing it all yourself you save lots of time, you are reusing well-tested code and your code will be much easier to maintain by other developers.
I've used PerlNet for a data extraction project. Perl is a powerful language for extracting data and text manipulation with a huge CPAN module. However, my program need some kind of UI, thread... which I decided to use .NET C#. With Perl Dev Kit, we have an option to wrap an Perl module to a .NET DLL and use this DLL directly from C#.
Everything was ok but I have one question about PerlNet architecture. As far as I know, PerlNet was a research project between ActiveState and Microsoft for running Perl code in .NET but I did not find any document for this.
What is limitation of PerlNet? How was PerlNet constructed?
Thanks,
Minh.
There's a book "Programming Perl in the .NET Environment" that may help you.
ActiveState doesn't seem to have any publicly accessible documentation online that gives any kind of details about PerlNET. But I'd be very surprised if there wasn't some doc included with the Perl Dev Kit, even though it sounds like they aren't providing any support for it anymore.
You may find answers to your questions on the perl.net#listserv.activestate.com mailing list or in its archives.
While I can't really say more about the way PerlNet is built than is readily available, I will say that from my experience, it is fairly clunky and not very reliable.
If it's a "real" project, i.e. money is involved, I would steer away from using PerlNet.
Specifically, it seemed to trash shared memory in .NET, and would cause crashes erratically.
That said, I haven't used PerlNet for some time so it could be a much better product now.