Java JavaScript?

He wasn't exactly selling you on it...

you said:

You admitted ignorance to benefits of certain features. So npsf pointed out those benefits so you are no longer ignorant of them.

You may not like it, but I wouldn't call it snake oil. Snake oil is useless and a scam. LINQ is the shizz-nizzy... I love it for XML, holy god do I love it for XML. My day job deals with XML constantly, and if it weren't for linq my days would be far more unbearable. I wouldn't call that useless!

 

Geez louise.

 

lol... Rawr

Holy Rusted metal Batman!!

OP Just use the language u feel comfortable with ultimately the choice is yours... Hoped this thread helped you.

 

I don't really give a damn about language features, what I do give a damn about is what those features mean for my project.

Although its important to consider the end game (pun intended), you also need to consider the path to get there. Do these features make the project quicker to build? Is it easier to find local contractors for a given language? Do they make the project easier to maintain? Do I even care about maintenance?

The questions you need to ask depend on your own situation, as will the answers.

... Hows that for some fence sitting ...

As for a recommendations:

If you aren't already a programmer and your interest is in building games I'd say start with JS just because the initial hurdles are a little lower.

If your main interest is in becoming a programmer C# is probably a better choice.

If you are already a programmer you should be able to make the decision yourself, given the information here and elsewhere.

And if you have the time learn both, its really not that much effort ​

 

We have already found out that tjhe difference is irrelevant for the result. There is no game that runs any better when it is written in C#. It`s a thing of personal experience and preference.

I don`t wanted to go on with the discussion because we already go in circles again. And i am tired to lead this childish discussion with you. Tired to get lied at with C# propaganda. Tired to battle against the nonsense that you talk here. Tired of your insults and dirty tricks.

But okay, just for the sake, let`s have a look at your oh so relevant lametta:

These are C# solutions for C# problems. And not needed to make a game in Unity. Proof? Have a look at all games that are made with JS. They run perfectly fine. Without this lametta. Your hot loved uber features are as useful as a third knee when you want to make a game in Unity. Unity is a Game Engine. Not a C# Ide.

I have no doubt that you are glad to have this lametta in C#. But you just BELIEVE that nobody else can live without those features in Unity. We already know that C# is your religion.

By the way, i doubt that you will find lots of Unity C# users that knows all terms which you are using so proudly here.

Now for the propaganda section ...

1) This is C# propaganda. It`s the oppposite. All books about Unity are written with using JS, not C#. At least i know not a single one that uses C#. Maybe there even exists one now. But a book about how to write a calculator in C# is definitely no valid book to teach you how to code a game in Unity.

2) This is C# propaganda. C# has as many or as few video tutorials as JS when it comes to Unity.

3) This is C# propaganda. Pages like Stackoverflow are made for C# users. Not for Unity users. And are nearly useless for Unity. This is like you would note a Web resource page for Javascript as a relevant example how strong Unity`s Javascript is supported.

4) This is C# propaganda. MSDN, eh? Not for Unity.
5) This is C# propaganda. Unity is NOT a NET Ide, it`s also no C# Ide. It`s a game engine.
6) This is C# propaganda. It doesn`t help me to know how to write a calculator outside of Unity. I want to make a game with and inside Unity

7) This is C# propaganda. Same point again. I want to make a game with and inside Unity That`s why i use Unity at all.

8) This is C# propaganda. As told before, the C# lametta to solve C# problems is not needed to create a similar game with JS in Unity.

9) Err, what? I don`t confuse it, the other tons of JS users don`t confuse it neither. Possible that C# users gets confused though. It`s not C# , And so completely alien ...

10) This is C# propaganda. The valid examples, like the Lerpz Tutorial at the Unity page are still JS. So it`s the opposite. There are more valid JS examples to dig into.

11) This is C# propaganda. JS doesn`t even need a editor monster like Visual Studio. I am perfectly fine with using Uniscite. Besides that, you can also use Visual Studio to write Javascript code. It`s supported.

Sir Propagandaminster Sir, there`s not this much left from your C# glory. In Unity your C# messiah is as good or bad as JS or BOO. No matter how hard you try to personally discredit and attack me. No matter how many dirty tricks you use. No matter how much propaganda you introduce.

You should try to understand what a strawman argument really is. And not misuse the term just because you cannot find a way to disprove the facts. And this below here is fact:

Stop your C# mission. You are wrong!

 

Tiles, how can you use such precise language and have no idea what you're saying half the time

I am confusion.

If you'd just drop all the emotionally-heavy words - like propaganda and... lametta? really? that's pretty condescending or... something... - it'd be a lot easier to try to take your side.

Also, wow. "You are wrong!" Have you seen the video game reviews by Navigator (with some digits instead of letters, i forget where)? He ends the Donkey Kong Country review with "If you don't like this game, YOU are STUPID." For some reason I am reminded of that. Can't say why.

C# provides tools to the programmer which can ease their job. US is missing some of these. You can get by with US, and it's easier to wield, but if you get accustomed to C# you can use -that- knowledge in more applications, even though it takes a little more initial investment.

 

Thanks for the feedback. I will try to not use those harsh words in the future anymore. I have said what i wanted to say anyways. The rest is going in circles. But it may be a good idea to tell this towards npsf too. Because my harsh words are a direct reaction at his harsh words.

What you see as a pro is also a con from another angle. The price for C# is a syntax that is lots harder to read and to understand. At least for my brain, which is the important bit when it comes to my personal decision. And you need to write much more text to write the same things than in JS. What you win with your special C# tools is something that you loose by using C#. And in the end you win nothing really.

What language to use in Unity is a thing of personal preference. And dependand of what do you want to achieve and where you want to go to. The people are different. They have different needs. And different point of views.

 

Source? You've proven no such thing.

So you accuse me of being childish, or lying, of talking nonsense, of insulting you and of pulling dirty tricks. That's much better than discussion the various mertis of the languages.

Seriously? So the ability to create generics... that's a 'C# problem'? The ability to create helper methods... a 'C#' problem? So on and so forth. These are tools in your arsenal to solve the problem you face when coding. US by and large has the same problems - it just doesn't have as many tools to deal with them.

Correct. However the question is about the languages, which mean's it's not limited to the game engine.

http://en.wikipedia.org/wiki/Straw_man

I know that people can live without these features in Unity. However, that's not the point being made.

You know nothing of the sort, this has been refuted repeatedly.

Which is why I continually promote these features by giving use-cases and sample code. Do you prefer people live in ignorance of the tool at their disposal? Should a carpenter try to cut would with a hammer simply because he didn't see the saw in his toolbox?

'propaganda' - Interesting word choice.

Propaganda often presents facts selectively (thus possibly lying by omission) to encourage a particular synthesis, or uses loaded messages to produce an emotional rather than rational response to the information presented.

Incorrect, you failed to read what I said:

C# has books written on the language. US does not.

Unity is a game engine. It has a API.

C#/US are languages.

They are separate things, and *both* need to be studied. To put it another way, the books on Unity use English and some basic mathematics in their text. Does this mean that one does not need to learn english or maths from alternative sources?

As above.

False.

Unity users use C# [if they choose] and the .Net framework [thanks to Mono's implementation] - for both of which much information can be found on stack overflow. All unity presents is an API - one small part of the programming experience.

On the other hand, a web resource on javascript is dealing with an entirely different language than US. This means the amount of info that can be learned is generally minimal [though it can be useful for a limited set of syntax].

False, as above.

Covered earlier.

False. Using C# outside unity a completely valid use case. Why learn multiple languages if one will suffice?

False. The concept that C# features are designed to solve 'C# problems' ignore that many of the problems are faced by programmers of both C# and US.

Regardless the confusion exists. You may think it's low, and therefor not a significant factor, but you cannot deny it exists.

False. The existing code base for C# is vastly huger than the code base for US. You're argument that there is a single JS tutorial [note there are far more] ignores issues of scale and coverage. Just as a hypothetical - can you find a US implementation of a circular list?

False. This ignores the very real productivity benefits of using a full featured IDE over what basically amounts to a basic text editor such as UniScite. Just because you don't *have* to use it doesn't mean it's worthless.

...

Again, straw man argument.

After my corrections, you'll find that I am not.

 

Please, I ask you but one favor. Go over the last couple posts of yours and mine. Quote every single 'harsh word' of mine, and every single 'harsh word' of yours. Then post them for comparison.

While I disagree that C# is 'lots harder to read' - this is a valid consideration when choosing a language.

Could you provide some examples? Or alternatively, try to rewrite the various C# snippets I've provided into a shorter, cleaner US form? I do do comparisons between peoples code on a regular basis and find that by and large C# is cleaner, shorter and sweeter.

Correct. Unfortunately some peoples POV are 'propaganda' apparently.

 

This is a really weird answer.

Do you use the standard collection classes like List, Dictionary, HashSet, Queue, etc? Where do you go when you want to know more about them? Answer: MSDN. Unity's documentation has nothing to offer, and even if it has some information it references MSDN for more details.

Where would you go to get information about String class and its methods? Unity's manual or MSDN?

How to parse a string into integer? Go to MSDN and read.

Where would you go for C# full language reference, to learn everything about syntax, keywords and all the stuff? MSDN. And for UnityScript? Release notes, wikis, faqs, forums, answers, etc. There's no single solid source of information about the language.

 

VB fo' life!

(goes back to writing vb.net for day job... ugh)

 

I pity you. Why on earth would you choose to work with XML all day? I'd go crazy.

 

UnityScript actually reminds me VB.Net just with JavaScript syntax.

 

Fact!

 

I write software all day. Some of our software deals with XML. I deal with it because I love writing software and XML is often used in contemporary software. I personally like XML, I have no problem with it what so ever... I also like linq because it makes modifying and searching xml in code easy.

 

a lot of "I have yet to" and "I haven't seen".

Anecdotal evidence is not "Fact!".



Furthermore, as far as I can tell npsf isn't stating that there is a game that can ONLY be written in C#. He's stating that C# has more features. That is fact.

More features doesn't make C# better perse. Because being "better" is opinion. It just means there are more features. It's up to YOU to make the choice of which you prefer. Obviously you like Unityscript. NPSF is just using facts like the existing features to support why he prefers C# and thinks it's better.

You obviously don't know how to separate fact from opinion. Note that it is valid to use the FACT that C# has more features to be why you dislike C#. A fact can sway an opinion in opposite directions depending on preference.

Example.

Fact - car A is red. Red cars stand out.

Opinion - Joe like car A because he likes red cars because he wants to stand out in a group. Jason dislikes car A because he thinks red cars draw unwanted attention from cops.

 

If you need to chop down a tree you can use an axe, but if you do it on a daily basis why don't you take a chainsaw?

 

The choice is between a green chainsaw and a yellow chainsaw, not the choice between chainsaw and axe.

And this here is still valid. And fact. Like it or not:

 

It's still not fact. You are giving anecdotal evidence.

"I have yet to see..." is anecdotal!

I have yet to see an aurora... doesn't mean they don't happen.

 

Try to disprove it, and you will find out that it is fact.

 

I already disproved it based on the logical fallacy you used.

Failing to disprove something doesn't make it fact. Failing to disprove something means that up to this point the theory has yet to be disproved.

Facts are recordable instances of data.

Facts are things like:
Your username is Tiles
The temperature outside in my area is recorded at 83 degrees fahrenheit.
The spelling of the word fact is 'F-A-C-T'

Argument from anecdote is not a fact. Nor is it rational either. You can not argue truth by anecdote as it only proves that YOU haven't witnessed the contrary. That there is the ONLY fact... it's a fact about your experiences in life.

Are you understanding what facts are yet? Are you understanding what logical fallacies are yet?




NOTE - my disproving that doesn't prove the opposite. That too would be a logical fallacy. We don't know if there is a game that can only be written in C# and not in Unityscript. We lack the evidence to prove one way or the other.


I'm starting to get the feeling you've yet to learn simple logistics relative to argument and debate. Please go study the common logical fallacies before returning:

http://en.wikipedia.org/wiki/List_of_fallacies

You've used:
Strawmen
Burden of Truth
Argument from anecdote
Argument from ignorance
False Attribution
... plus many many more (especially review the 'appeal to' section of fallacies, which you seem to enjoy using)

 

Correct.

US C# are both turing complete. Same as PHP, C++, C, BrainFuck, Whitespace so on and so forth. Therefor in theory there's nothing that any of these languages can't compute given sufficient time resources.

Code (csharp):

1. Being turing complete doesn't mean much in terms of efficiency!++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

That said, given the vast quantities of restrictions that Tiles has placed on C# - you can't use MSDN, you can't write external tools/services, you can't look for information on stackoverflow etc. I'm quite happy to say there are plenty of games that couldn't be made in US given such a set of arbitrary limitations, and some reasonable resource limitations. In fact -the majority of Unity projects I've been involved in requires access to C# external services. And I can't think of a single project made in Unity, with code, that doesn't use the .NET library [mono].

Code (csharp):

1.  
2. var x = 5;  //Uses the .NET framework
3.  

So I think in his zeal to discount C#'s advantages... he's just proven his own straw-man argument wrong.

 

It's Turing complete, as in Alan Turing.

http://en.wikipedia.org/wiki/Alan_Turing

 

Fixed.

 

* operator overloading, impicit/explicit conversion operators

My project heavily uses two custom classes IntVector2/IntVector3 which are like Vector2/Vector3 but based on integers instead of floats. And these integer vectors can be implicitly converted to float vectors when needed.

Code (csharp):

1. var position = IntVector3.North * 3 + new IntVector3(2,10,2);
2. transform.position = position;

* lock { } statement

It's a nice syntax sugar if you work with multi-threading.

Code (csharp):

1.  
2. lock (synchronizationObject)
3. {
4.     // ...
5. }

vs

Code (csharp):

1. import System.Threading;
2. ...
3.  
4. Monitor.Enter(synchronizationObject);
5. // ...
6. Monitor.Exit(synchronizationObject);

BTW, UnityScript also lacks volatile keyword.

* using { } statement

It's useful not only for accessing unmanaged resources, but it's also a convenient way to automatically call an object's destructor/finalizer. For example, much of my code is performance-critical, so I have to measure and control the performance of all the critical areas.

Without using it looks like this:

Code (csharp):

1. void PerformanceCriticalFunction()
2. {
3.     var timer = Stopwatch.StartNew();
4.     // calculations
5.     if (someConditionIsMet)
6.     {
7.         goto exit;
8.     }
9.     // more calculations
10. exit:
11.     timer.Stop();
12.     PerformanceMonitor.IncrementCounter("name", timer.ElapsedMilliseconds);
13. }
14.  

With using it's much cleaner.

Code (csharp):

1. void PerformanceCriticalFunction()
2. {
3.     using (new Timer("name"))
4.     {
5.         // calculations
6.         if (someConditionIsMet)
7.         {
8.             return;
9.         }
10.         // more calculations
11.     }
12. }
13.  

Code (csharp):

1. using System;
2. using System.Diagnostics;
3.  
4. internal class Timer : Stopwatch, IDisposable
5. {
6.     private readonly string name;
7.  
8.     public Timer(string name)
9.     {
10.         this.name = name;
11.         Start();
12.     }
13.  
14.     public void Dispose()
15.     {
16.         PerformanceMonitor.IncrementCounter(name, ElapsedMilliseconds);
17.     }
18. }

Now all I have to do, in order to measure performance of some code section, is to embrace it with

Code (csharp):

1. using (new Timer("timer's name"))
2. {
3. }

and that's it.

* interoperating with unmanaged code

A nice little example

Code (csharp):

1. [DllImport("__Internal")]
2. public static extern long mono_gc_get_heap_size();
3.  
4. [DllImport("__Internal")]
5. public static extern long mono_gc_get_used_size();
6.  

Place these line somewhere in one of your classes (it also works in free version of Unity). The first function is not very useful because it returns exactly what GC.GetTotalMemory() does. The second one returns the size of used memory, there's no other way you can get this counter. You can monitor in real-time how fast it grows, and if it gets close to "total memory" this means that the GC will awake pretty soon, so you can call GC.Collect() by yourself if you know that right now is a more suitable moment for garbage collection than it will be later.

 

Nice.

We also forgot about ref/out keywords.

Just a nice piece of trivia, did you know using can be good for rendering GUI?

Code (csharp):

1.  
2. GUILayout.BeginArea (someRect);
3. {
4.   //Some code
5. }GUILayout.EndArea();
6. ...
7. using (GUILayout.BeginArea (someRect))
8. {
9.   //Some code
10. }  //The dispose method calls end area.
11.  
12.  

This doesn't work with the Unity API's [soz] but I discovered the concept when leaning ASP MVC.

 

Hate to come in on this, as I think your site is a fantastic resource , and I agree with the general thrust of your point (either language is fine)...

I'm pretty sure (although not certain) you need c# to bind native code, which means any iOS game which uses a native feature (for example GameCentre) isn't doable without using c#.

Of course you could just write a few lines of binding in c#, but if we put in the simple rule of no C#, then that is a pretty real and hard constraint.

Personally I use both, even using both in the same project in a couple of projects.

 

A bit faster is a bit of an understatement. My tests showed C# to be 4X faster with loose scripts and 12.5X faster when dealing with a bunch of projects compiling dlls.

This makes a huge difference for me. I was running 15s compile times before moving to C#. Now I'm down to 3s. Multiply that by 100x day and you're talking about almost 2 hours a week saved in compiling. If you're talking dlls, 3.5s vs 44s is a very big deal indeed. Sure, if your game is really small you're not going to notice.

I've coded for over 2 years in UnityScript and just recently switched to C# and I've got to say I'm surprised at how many useful things I was missing out on and completely unaware of. But I have to say by far and away the biggest plus points for C# compared to UnityScript for me are the IDE and proper documentation. My gosh I feel like an idiot slogging through the mud all this time on UniSciTe, Notepad2, Notepad++, UnityDevelop, and (the unholy) MonoDevelop. Once you try VS, you just can't go back. When I was a newB, the lack of language documentation for UnityScript made the learning process very slow and frustrating and one big reason I think C# is better for newcomers. The closest thing UnityScript has to a language documentation is Eric5h5.

 

Thanks. But this doesn´t belong here, don`t you think? Or do you really want to start discussing at this level?

LOL. I just wait for the F# example again now ...

I have seen very fast pages with javascript code snippets. But they don`t belong to Unity. Writing DLL´s doesn`t belong to Unity, as long as they are not part of the game. And Unity brings everything needed to write a game without DLL`s normally. Loose scripts definitely doesn`t belong to Unity.

And again the try to disprove failed. I have yet to see a Unity Game that runs any faster than a Unity game made with JS or Boo.

And i`m pretty sure that i can do a Game with Javascript and it nevertheless compiles and exports fine to iOS. Without loosing any functionality compared to the same game written in C#.


It stays as it is. We already know that there is no benefit at the output end. There is no Unity game that runs any faster or better because it is written with C#. There is no game that can be done with C# but not with JS or Boo in Unity.

So the benefit must be at another end. More features for example, as always stated here. Or a higher development speed. Or a better documentation. Unity internal Documentation is as good or bad for all three languages. (More bad. Man i wish you could comment on the Script reference). And C# documentation is no valid source for me as the html / Javascript documentation or the Python documentation is no valid Unity source to me neither. We have talked about the lametta and the documentation before. Remains the last point which we haven`t discussed yet. Higher development speed.

Just for the sake of the lametta: some of the told features may indeed save you a few minutes or even hours per game. Sorry, have to ask: how much games do you make per day?
C# is more complex. It has a steeper learning curve. This needs MORE development time compared to Javascript.
C# is harder to read and to understand than JS. This needs MORE development time compared to Javascript.
Writing C# code uses more letters. Just a few, but it`s more. This needs MORE development time compared to Javascript.

All in all i end in a higher development time with C# when i count one and one together.

Last point can be checked everywhere where you can find a code example for the same things. Script reference for example. Or Wiki. Let`s use the Charactercontroller Move code as an example:

C# uses 839 characters, including the spacebars *.
JS uses 677 characters, including the spacebars.

* Haven`t found an editor that does the character count without the spacebars. Maybe somebody knows one that counts just the letters. But since the two snippets are equal formatted the count should still show where it goes.

Let`s resume. The only valid reasons to use C# over JS are all personal reasons. And not because you can`t get the job done.

Time to extend my lists of facts ...

Yes, i know, this hurt some religious feelings here. But reality is hard sometimes.

 

Not sure of your point. The information I provided was accurate and there's no reason you should blow it off as irrelevant. If you're expecting to spend years compiling over and over again, it makes sense to know how the different languages perform. If F# is added to Unity, I will benchmark that because I want to have all the information at my disposal. Anyone seriously comparing the languages would.

Neither have I because they're all compiled in the end. Nobody ever said C# games run faster.

I don't understand what you are saying here but clearly you misunderstood me.

This is incorrect. Unity does support creating and using DLLs. It's in the official manual here. DLLs can be created for many purposes and do make use of Unity's classes by linking to UnityEngine.dll and UnityEditor.dll. They're essential for add-on developers (all the stuff in the Unity asset store). You can also compile portions of your code to DLL to offload some burden on the compiler. Once the DLL has been compiled, you don't have to keep compiling the same code when you edit one of your loose scripts.

You are misunderstanding me. "Loose scripts" refers to the .js, .cs, and .boo script files in your assets folder that are compiled to make your game run. These definitely DO "belong to Unity" as this is the prescribed method for coding. Using these "loose scripts", C# was 4X faster at compiling than US in a real-world scenario -- namely, I converted my entire game consisting of over 160 script files to C#. It makes a huge difference to my productivity.

The speed test is definitely proven. I spent a LOT of time doing it. Test it yourself and see if you don't believe me.

I completely disagree with this statement 100%. My productivity in C# is vastly improved over UnityScript because I don't have to deal with MonoDevelop's garbage anymore. My compile times are vastly improved as well. So much wasted time saved means the game gets done sooner.

Let me ask you a question. Have you spent any significant amount of time coding in C#? I ask because you sound like how I thought 2 years ago when I didn't understand C# and chose US. I was just plain scared of it because of some people on this forum making it sound terrifying. When I finally started to dabble in it, it took me just one day to get used to the differences between the two languages and I was flying. It's not complicated. You don't HAVE to use all the extra features.

I don't believe C# has a steeper learning curve than US at all. In fact, I think the opposite is true. The availability of C# language documentation really helps compared to poking around blindly like I did in US trying to figure out how things work. This makes it much faster to get started. Yes, Unity tutorials are available in US, but those usually deal more with Unity classes than the language itself. Also, the strong typing of C# prevents new programmers from getting confused and doing wacky things with their variables and getting confused. (And no, #pragma strict doesn't solve this.) The compiler warns you about all kinds of stuff the US compiler just overlooks.

C# is also not harder to read than US. Like I said, it took me all of 1 day to get used to the differences in syntax from US to C#. They're VERY similar. C, C#, CScript, MEL, UnityScript, Javascript, PHP... They're all very similar looking and its not hard to switch among them as syntax goes. Obviously, this varies person to person, but I didn't find it hard to get used to at all. It makes me wonder what all the fuss on the forums was about making it sound so complex and scary.

Why do you think these criteria are not the only valid criteria for determining which language to choose? Clearly, #3 is wrong in my experience. As for #1 and #2, that's all fine and good. Yes, any language can get the game done, nobody is debating that. That does not mean all languages are equal or that all languages will get you to the end of the project in the same amount of time. If I were trying to decide between the 3 languages, I'd want all the information I could get so I could make an informed decision. Saying they're all the same because you can make a complete game with any of them is not being helpful to the OP.

There's nothing personal about it. Abundant language documentation, a powerful and fast IDE, faster compile times, and a host of useful language features are all very real and very useful things that help with learning, increase productivity, and get you to the final goal of a finished game faster.

"Get the job done" should not be the only goal. "Get the job done in the quickest and most efficient way possible" is a much better goal. C# has many more tools and resources to help you get there than UnityScript. I'm sad to say it because there are a lot of things about UnityScript I like, but it's just not on the same level.

My post was meant to add a bit more information for those trying to choose between languages including the OP. I am speaking from my own experience from using both languages. I believe those searching for a language deserve more than to just be told they're all the same. With all the information laid out on the table, they can make an informed decision.

 

Not saying your right or wrong but please publish your tests. If you want to present a reasonable arguement you have to submit proof.
I see a lot of back and forth on this over some very petty differences which I find unconvincing (coming from a C# guy here). If you want to prove C# is condsiderably better in Unity I think the right thing to do is demonstrate it.

If you arent sure how I can give you a few ideas.

 

So are you saying that one can't use DLL'S when programming a game? WTF?

You do know that all code you write for unity - US, C# or BOO gets compiled down to a DLL? How about all the plugin's that use DLL's? What about the Mono functionality - for example accessing DB - that you have to import a DLL for manually? What abotu all the DLL's included by default by unity?

DLL's are part of normal game development, without them your US game wouldn't function.

Could you provide a list of the games you've compared? Identical game, written in C# US, that you've then gone and compared performance of?

Instead of being 'pretty sure' could you please show how you'd bind to native code using US?

Firstly: Strawman.
Secondly: Under the conditions you are imposing, even US games can't run. No native code access. No external tools/services. No .Net framework. No DLL's. If you wish to continue along this line, there are tons of games that I'd be happy to point you to.

This is simply wrong. The C# referances outside of unity apply to the C# used by unity. The JS Python references outside of unity DO NOT apply to the US and Boo unity has [because they are similar, but not the same language]. Why do you confuse this US limitation as a C# one?

We haven't discussed yet? Excuse me, this has been the key thing that's been discussed all along. Just because until now you've been fighting different lines doesn't meant this is new.

You're vastly underestimating the value of these 'lametta'.

Source?

Source?

Source?

All this proves is you know how to write, by your own metrics, poor code.

Code (csharp):

1.  
2. using UnityEngine;
3.  
4. public class Example : MonoBehaviour
5. {
6.     public float speed = 6, jumpSpeed = 8, gravity = 2;
7.  
8.     Vector3 moveDirection;
9.  
10.     void Update()
11.     {
12.         var controller = GetComponent<CharacterController>();
13.         if (controller.isGrounded)
14.         {
15.             moveDirection = new Vector3(Input.GetAxis("Horizontal"), 0, Input.GetAxis("Vertical"));
16.             moveDirection = transform.TransformDirection(moveDirection);
17.             moveDirection *= speed;
18.  
19.             if (Input.GetButton("Jump")) moveDirection.y = jumpSpeed;
20.         }
21.  
22.         moveDirection.y -= gravity * Time.deltaTime;
23.         controller.Move(moveDirection * Time.deltaTime);
24.     }
25. }
26.  

660 Characters inc. spaces. Fewer than your US version and 27% shorter than your given C# version! If you're going to make 'proof' can you please at least try to present decent code?

Except the myriad of practical reasons given.

Fact 1 is wrong given your own limitations. Fact 2 has no evidence presented. Fact 3 is proven wrong thanks to developer experience.

 

WTF? Why do you always try to twist my words in my mouth? There`s not a single sentence in this discussion where you don`t try it. And you ask yourself why i don`t want to discuss with you?

It makes no sense to discuss with religious fanatics like you.

Just in your religious nightmares.

Fact.

 

Writing DLL´s doesn`t belong to Unity, as long as they are not part of the game. And Unity brings everything needed to write a game without DLL`s normally.

DLL's are used in unity as part of 'the game'. Using DLL's when using third party code is standard practise. Using third party code is encouraged by Unity - see the asset store.

If you think I've 'twisted' your words, then explain where I've misunderstood you.

Evidence?

Nope.

Read up on defamation.

According to who? According to what evidence? Have you had any peer review etc?

 

You`re plain hilarious.

 

Thanks

 

It doesn't matter if the game works and the framerate is good. It only matters if you have to do extreme low level tweakage that translates to machine code gains. A little esoteric for most and sometimes needed as a final hammer to pound a game into shape. Awesome knowledge..when needed. The OP does not need this now so yer just showing off

 

The thread title was about Java and Javascript. Why did you spit C# all over this thread and why do you always spit C# over threads like this when it was not necessary nor a part of the thread topic till it was thrust into it by the likes of yerself? I don't need an answer. I am pointing out your habitual gambit of disruption.

HTH

 

Read through the start of this thread, then, if you think I've acted inappropriately inform me when and where. I've already decided I made some mistakes in my approach, but I'm happy to see what you see as erroneous.

For example, I would note that SkaredCreations, lordofduct, Batzarro, Morning, spiderclan123 [OP], BlakeChristensen [1 poster] and Tiles all mentioned C# before I entered the discussion.

My first two posts are merely corrections on what is IMO factually incorrect statements.

My third and forth posts merely extended a point made by lordofduct.

I suggest you take a look into the features mentioned in this thread, because few/none of them are aimed at low level performance optimization.

 

Because he is a C# troll. And he just has to spread the word of his god to have a good rest at the evening. With all possible and impossible weapons. With splitting hair until he hits the bone, with twisting words, introducing things that hasn`t anything to do with the issue, and so on.

 

Actually it got on C# because SkaredCreations said in 1st response:

And I followed that with in the 2nd response:

Because Java is essentially useless in unity.

Which resulted in OP saying:

This is all page 1, first three posts, you could have easily looked it up. But of course you failed to, because you fail to look anything up to support your case so far in this thread.


And who is the troll again? With your hyperbolic distreatment of everyone else's words. While at the same time accusing them of the same thing which they have not done.

And I notice you still have yet to learn what 'facts' are.

 

Reducing script compile time or a better workflow to reduce excessive recompiling
Problems compiling DLLs from MonoDevelop

These two links are threads of mine about the whole process of improving compile times. Not only does it show the final result of vastly improved compile times, but also demonstrates the great difficulty of getting DLLs compiled from UnityScript. That was only one of many situations over the years I've run into where UnityScript sent me jumping through hoops trying to find a solution when it was so straightforward in C#. That finally convinced me it was time to try C#.

 

Code (csharp):

1.  
2. public class GUIArea : IDisposable
3. {
4.     public GUIArea(Rect rect)
5.     {
6.         GUILayout.BeginArea(rect);
7.     }
8.  
9.     public void Dispose()
10.     {
11.         GUILayout.EndArea();
12.     }
13. }
14.  

Code (csharp):

1. using (new GUIArea(someRect))
2. {
3. }

 

Oops, I think I must have edited my previous post to Tiles several times an hour after others had already responded to it last night so probably some of my added points were missed after it started getting buried in the other responses. (I didn't realize the discussion was still going on so vigorously at that time.)

 

Oh, is there another word for somebody who hijacks every possible thread to convince the kids to C#, is trying to remove JS completely from Unity, is twisting words and uses every dirty polemic trick? I call this a troll.

Funny one, from my angle it`s you who has no clue about facts. These points are still not disproven.

A dll doesn`t really fit in our concept of comparing the languages because you usually write and use the code without to compile it into a external dll. This may be necessary for exotic stuff like to write Unity plugins, to protect the source code of them. But usually not for a game. That`s at least my opinion when it comes to dlls.

 

Just because something has yet to be disproven doesn't make it fact.

That's not what facts are.

Facts are recordable instances. We can not record if there is "no unity game that can be done with C# but not with JS or Boo"... why, because there is an infinite number of games that can be created, so thusly we can't record them all, so thusly we can't prove that is a fact.

If you said that you know not of any games that can be done with C# but not with JS or Boo. Then that's a fact. Because it pertains to your personal knowledge. But that doesn't mean there is no game... it means you know not of any.





And who is "trying to remove JS completely from Unity"? NO ONE HAS SAID THAT. You're an idiot.

 

BUT THEY HAVE ALREADY TRIED THAT!

And this hijacking of every available JS thread is just the same with other weapons.

And as told in this insane make JS deprecated thread, i will resist. Live and let live. Not Live and kill. Stop this insane JS witchhunt.

You`re welcome

To quote the wiki: A fact is something that has really occurred or is actually the case. The usual test for a statement of fact is verifiability, that is whether it can be shown to correspond to experience via proof.

That there is currently no game made with C# that runs faster than the same game made with JS in Unity is actually the case.
That there is currently no game that can be done with C# and not with JS in Unity is actually the case.

So we can savely say that these two points are fact.

You may notice that i removed the third point. Would cost too much time to discuss this one.

 

That is not this thread.

This thread was not hijacked. This thread WAS on topic until you came along.

No one in this thread has said JS should be eradicated. They're just stating their opinions for C#. And using facts to support their opinions. You've used lies and conjecture as an attempt to make them out as bullies.

 

First of all, it's not up to npsf3000 or anyone else to have to disprove your statements. It's up to you to prove them. You demand that others prove their statements, so why should you be allowed to have it opposite where you can make a blanket statement, call it fact, and have it stand until someone proves it otherwise? That's a double standard.

I gave you one example where this is disproven. You say "no Unity game that gets faster developed". I say there is. It's mine. As I stated in my previous post:

"My productivity in C# is vastly improved over UnityScript because I don't have to deal with MonoDevelop's garbage anymore. My compile times are vastly improved as well. So much wasted time saved means the game gets done sooner."

My Unity game gets developed faster because of C#.

And as another example, a programmer coming into Unity with prior knowlege of C# would most certainly get his game done faster in C# than UnityScript because he already knows the language. There may be some cases where a game gets done faster in UnityScript, and there are other cases where the game gets done faster in C#. Saying no game gets done faster in C# is not a fact.

Just because you don't use them doesn't make them exotic. And compiling DLLs is not so far removed from Unity as you think. You compile them right from MonoDevelop, in your choice of UnityScript, Boo, or C#. It can be game code, plugin code, or whatever you choose. Unity even made it easy for you by making each DLL have its own drop-down list of MonoBehaviours inside it so you can drag and drop them onto your objects in the editor just like any other script.

Not using or knowing about "exotic" features is just another symptom of the limitations of the language. Some C# features may seem "exotic" to UnityScript users because they're not supported, but could be very useful and time saving if they were (which incidentally is the reason Unity keeps adding features to US). Someone who only uses UnityScript all the time simply does not know. All the time I was using UnityScript, I did quite a few things in roundabout ways because UnityScript just simply did not directly support things I wanted to do. When I moved to C#, it was like a big "OH" moment where it suddenly hit me. I could see that there was a better, more direct way to do that task that didn't involve jumping through hoops like in UnityScript.

 

I have nothing against this part. I have something against the witchhunt against JS though. And this thread is nothing else than the same witchhunt like in so many other threads where it`s about what language to use.

Now you talk really nonsense. Not that your input was this much better since you started to take the discussion between npsf and me as a personal attack towards you and C#.

My proof are the thousands and thousands of games out there. You just need to pick ONE to disproof my points. When i am this obvious wrong then this shouldn`t be too hard

But you can`t blame JS for Monodevelop here. I use Uniscite, and am more than fine!

Anyways. I cannot prove or disprove it. And take this one back.

Nope, just a measurement how eager the dll feature is really needed. I don`t need it. It gots introduced with 3.1 from what i know. And before that the people have made games too.

I am still not really convinced. But i take your word that it is useful for you. And accept that writing dlls is part of making a game.