Best Place To Learn JS With Unity

UnityEngine.Array is not the same thing as System.Array and the confusion that this causes for folks who don't know to consult MSDN are well documented on this forum.

The fact that Unity uses .NET/Mono is the basis for the argument to use MSDN as a resource when developing in Unity. The main reason folks suggest beginners try C# is so that they may take example code from MSDN (and other sources) and directly use it in their projects without having to translate it. Translation can easily lead to bugs, sloppy code, and increased confusion.

It's pointless continuing this conversation because it's become abundantly clear that you're arguing from a position that lacks a fundamental understanding of the subject matter. And that lack of understanding has caused you to dole out very poor advice to the new members in this thread.

 

Again. Show me where Unity requires the MSDN API. It is simply wrong to say Unity requires the MSDN API. That's nonsense. And one of those untrue myths that i have meant.

It's the opposite. It's your lack of understanding the issue that makes a communication here so hard. For you this discussion is still the Versus debate. And you try to argue at this fundament. My point is the thread hijacking. Not the choice of language.

 

I just point at what exists. Thread hijacking JS threads is common here at this board. And one of the reasons why JS vanishes here.

 

I have. Multiple times. I gave you a concrete example. Physics.OverlapSphere is part of of the Unity API but it returns a System.Array. If I wanted to know what methods and properties are available to System.Array I would have to go to MSDN. I would again challenge you to find a game that exclusively uses the Unity API. Hell - the default script template adds the System.Collections namespace to the top of the file for you!

I'd also ask you to go count the number of posts in this forum section that are not Unity specific. A NullReferenceException is not Unity specific. "How do I sort a list?" is not Unity specific. "How do I find a particular item in a list?" is not Unity specific. "How do I load a file from the hard disk?" is not Unity specific.

The only versus debate I'm engaged in is fact versus the idea that operating with less information is somehow better for new users. You're worried about someone getting confused about learning that Java != JavaScript != UnityScript. I'm worried about that user following your advice and subsequently asking what a NullReferenceException means for the ten thousandth time. And then that user follows more of your advice and asks why they keep getting "Property XYZ is not a member of Object" when they use UnityEngine.Array because "Tiles told me it's the same thing as a System.Array or a List". "And how come the push() method doesn't work to add Colliders to what comes back from Physics.OverlapSphere? It's the same thing right?"

 

But this still does not mean that a user has to fire up MSDN to develop his game. You can do a thousand games with just using the Unity API. There is no need to fire up MSDN. You don't have to go to Microsoft's MSDN page to get an array to work or to develop your game. All there in the Unity API.

Again, it is not about what is under the hood. It is what the Unity user has to use. A NullReferenceException in Unity is definitely Unity specific. Loading a file in Unity is also definitely Unity specific, System.IO is part of the Unity api. And even using a List in Unity is Unity specific. It's just miserable documented. As told, it works also with JS, and should be imho documented in the Unity API.

I think we can agree at this point that we simply disagree about splitting hairs about definitions here.

Could you please stop this trolling attempts to put things into my mouth? The x-th time, i did not say that. No matter how hard you try.

There could be worse. I've always got my projects finished. And i develop games and apps since several years.

The worst thing that could happen is that they follow your advice, and wastes years of learning for no reason.

 

No it isn't. And if you wanted information on what is contained in System.IO you should go here because you won't find it in Unity's documentation anywhere. http://msdn.microsoft.com/en-us/library/system.io(v=vs.90).aspx

I'm done. There's no value in discussing the merits of development resources and documentation with someone who can't even define what an API is correctly and whose entire argument is centered around the concept of "this isn't important because I don't use it".

To anyone looking at this thread later and who actually managed to make it all the way through it - congratulations first of all; hopefully you didn't kill too many brain cells on the way here. If you can take one thing away from this inane bantering make it this: Regardless of what language you choose to write your game in, know that the tools available to you are not limited to what is documented in the Unity manual and Scripting Reference. The more information you have, the more successful you're going to be.

 

Oh, Please ... http://docs.unity3d.com/ScriptReference/30_search.html?q=System.IO

You could at least have had a look.

The argument that you refer to is not "this isn't important because I don't use it". It is "I will never ever need it, and i know it. so it isn't important to me".

I even agree to some degree. It is important to know that you can extend the Unity posibilities behind the Unity API. But then again, Unity is complete enough that you normally don' t have to do so. And we are at the difference between Programming and Developing.

A programmer needs to know as much as possible. He is a specialist. Your boss does not pay you for learning. But for doing. And you never know what your next job requires.

A developer is somebody who searches for the fastest and most efficient way to finish his project. This could even mean that he just buys/borrows all the components and puts them together. I know quite a few folks who makes a living from that without knowing a single line of code.

Much more important to learn it all is to learn how to find the bit that you need for your project. "Google fu" beats "learning it all". To learn the complete MSDN API just to rotate a cube in Unity is definitely wasted time and money since this doesn't require MSDN at all.

And we really have no fundament for a further discussion as long as you haven't understood the difference between programmer and developer.

 

You'll notice that the results coming back for the search you linked point to classes in the UnityEngine.Windows namespace, not System.IO; and the documentation even says This is an alternative to System.IO.*****. You're again demonstrating a fundamental lack of understanding on the subject.

Furthermore, your entirely fabricated definitions for "programmer" and "developer" show that you don't have much, if any, experience in any technology-based industry. The viewpoints are flawed to such an incredible degree that it's difficult to even comment on. It's akin to discussing space exploration with someone who still believes that the sun revolves around the earth.

Ultimately, I'm more interested in trying to help people than arguing semantics or explaining the difference between consulting documentation outside of Unity and learning the entire "MSDN API" (whatever that even means) to rotate a cube.

 

To successfully write code that works in Unity you should be referring to MSDN on a regular basis. Trying to stick to the Unity API is ridiculous, and technically speaking impossible, as Unity relies on various classes from outside of the API. Something as basic as a float is not part of Unity, it's part of the underlying frame work.

Just making it clear that @Tiles opinion is not shared by the majority of programmers working within Unity.

 

... and when you don't visit the MSDN god once a day, then your working Unity code magically quits working!!!

It stays nonsense, sorry

 

lol

Yes or No
Black or White
Your suggestion to check out MSDN is tantamount to memorizing the entire contents of the .Net API

 

And you still don't accept that all is there in the Unity API, that there is simply no need to rely at the MSDN API.

You manage to be a programmer, which is fine. I manage to be a programmer, a musician, a graphics artist, a story writer and a overall game deveoper. At a relative high level. And get away with it. I get my projects finished. So whose method was more succesful?

I know that the industry does not work that way. Here the specialists are asked. So i know completely where you come from. But who says that the industry is all? I would say that minimum 50% of all Unity users are hobbyists. They don't need to study programming for twelve semesters to get their pong done. That's an insane advice.

This means that somebody who develops the usual casual games from Pong to Pac Man up to a simple ego shooter does never ever need any code line from MSDN. Since you can get your job done with just the Unity API.

 

That's the first time we agree in this thread here. There is more than just black and white.

But you don't need MSDN at all. There is simply no need to learn it. Not even small parts of it. Except your current project requires it. Which is not the case for 99% of all Unity games.

 

Just to clear something up, JS actually does have full access to the .net libraries. Not just System.IO.

 

Yes, that's another important point. Also JS has access to the Mono stuff. But that would be the versus debate again.

The current argument here is about how to learn programming in general, and if you need MSDN to write a game in Unity.

 

I'll concede if you can show me - somewhere in the official Unity documentation - how to sort a list of GameObjects (List<GameObject>) based on their distance from a given position.

Bonus points if you can provide multiple ways of doing it and say which one is going to be the most efficient (assuming I have to sort every frame).

 

Tiles pointed out that there is a Javascript array class:
http://docs.unity3d.com/ScriptReference/Array.html

That is actually a bit odd to me, I never knew of this. It's an Array class that is only accessible by Javascript, and not C#. And it's mimicking the web javascript arrays (via having lowercase methods). Seems as if they made it for people who are accustomed to using arrays in javascript for the web.

 

That's exactly why they did it. Unfortunately, they're slower and not typesafe.

 

The general advice is this class should not be used. Built in arrays or generic lists are faster, depending on the application.

 

Okay, so it's more of a sales pitch than anything: "Hey you can make web javascript arrays in unity!" But in practice should be avoided.

 

You totally missed the point.

No one said you NEED to use MSDN. And no one certainly said to learn MSDN (MSDN is just a documentation... you should learn .Net, the framework).

Things is, because we said MSDN is a very useful resource, and you took it to mean us saying that you MUST LEARN ALL OF MSDN TOP TO BOTTOM, OH MY GOSH, DO YOU EVEN LIFT... CODE... MSDN!!!!!!!

Black & White
Yes & No
Suggesting to use a useful resource is saying you must learn the entirity of it, and you shouldn't have to learn it all, so don't learn it at all!

 

Yes, I pointed that out ages ago.

That's where the whole, MSDN is a great resource even if you write Javascript, because U/JS accesses the damn .Net/Mono framework!

See... I said it there. "may I be writing U/JS or C#".

As well as this fateful comment.

That you even quoted and criticized by saying:

Which ironically is where you didn't know the difference between .net/mono arrays, and the UnityEngine.Array. Two fundamentally different things, and completely dismissed .net/mono because you don't use it (even though you ACTUALLY do).

 

SO... to get this straight for you. You said:

No one is saying you NEED MSDN to write a game. We're saying it's a useful resource, and hey, if you want to know anything outside of the UnityEngine/UnityEditor namespace (like System.Collections for instance), MSDN is probably the best place to go since it's from the guys who designed it.

If I want to know about the classes in UnityEngine namespace... I'd probably go to Unity, because they're the ones who designed THAT.

SO, argument over?

Or will you continue telling us why our suggestions are so wrong, and your suggestions are right, because MSDN is somehow a conspiracy to force C# down your throat.

 

They DO work, it's not just sales pitching. But as pointed out, they are much slower. Around as half as slow, i ran into it in the past and tested it out. No problem for a few datasets like Player name and stuff. But a big problem when you work with let's say the vertices data of a megapolymesh. Double as fast by using a List is a great optimization then.

Slower yes, not typesave no. That's one of those myths again. That's what #pragma strict is good for.

Umm, could you please tell this BoredMormon too?

And my point stays: in Unity you don't need MSDN at all, it's no requirement. When you really need to refer to MSDN on a regular basis then you should rethink if Unity is the right tool for the job. It's a game engine with the purpose to develop games with, not a C# IDE to develop text editors with.

Was i really this bad with my explanations? Your suggestions are not wrong in general, i never said that. It's not Black and White. It's just that your way is not the only working way. It depends of your goals. BOTH ways are valid, dependand of your goal. To write code and to develop a game is two different goals.

You can completely get away with just learning in and staying inside Unity and its API, and get your game done. That's what i did for years, that's what nearly all hobbyists and also lots of professional Indie developer does. Which are also a big fraction of Unity Users. And this also means that JS is a completely valid solution. Even nowadays. You can still do the same game with it in Unity. It will look the same, it will run the same speed. You will not be able to say which was what afterwards.

The path of becoming a professional programmer, somebody who most likely does not only write Unity games in his life, requires to have a bigger fundament though. No wonder that a programmer usually needs to study several semesters.Then it's a good idea to learn all the stuff behind. Then it's also a good idea to learn and to use C# and MSDN, because it is not proprietary, and can be used outside of Unity too.

As told, i completely understand where you come from. Now we just need to manage that you undestand where i come from.

Gah, in every second answer is stuff that i never said or meant. Do you need me for the discussion at all? Or is my name enough to have an enemie to punch around?

MSDN as a source is not a conspiracy. I never said that, and you know it. It's in fact a good source to extend Unity to some degree, in case you run into one of the Unity limits or API gaps. That you need to know MSDN and C# to get your Pong done in Unity is one of those myths though.

Depends if we have found a consensus here. You and i are not this far away from each other really. Different story with some others here.

 

should be is not need be

really... you need a consensus brah? really? Is it that important to you?

Just let it go dude. It's not the end of the world.

 

I'm listening. However I totally discounted pretty much all of your points based on your demonstrated lack of knowledge. There is nothing you can add further to this conversation that will make me change my mind.

You may have had a successful game development career without touching MSDN. More power to you for that. I refer to it on a regular basis. I'm still going to maintain that its an essential resource, and ignoring it is throwing out half the tools in your tool box.

Our thoughts obviously differ quite dramatically on this. There is enough material here for anyone to read both sides and get a feel for the various opinions. Its entirely possible our differing ideas come from different backgrounds and different goals.

 

Ah, semantics ...

NOT needed is NOT needed.

True. My method works even without your permission. And vice versa ...

I meant more the consensus that all is said now.

 

Internally, UnityEngine.Array stores everything as an Object. #pragma strict doesn't change that. A type-safe collection has its type declared and delivers compile-time exceptions when you try to add items of a different type. Unless they've dramatically refactored UnityEngine.Array then this does not happen.

Laughably, you'll notice that this wiki page from Unity has numerous links to MSDN articles - http://wiki.unity3d.com/index.php?title=Which_Kind_Of_Array_Or_Collection_Should_I_Use?


Oh - and I'm still waiting for my answer

 

Dunno where's the problem here. #pragma strict makes the script still type save. But yeah, maybe i miss a bit here.

Oh, is the Wiki the new Unity API?

Did i overlook something?

 

It's honestly difficult to tell what your definition of "API" is throughout this conversation....

 

Also - if you're so staunchly against using MSDN as a development resource for Unity then go edit those wiki pages and see how that fairs.

 

Funny, i read the thread title here, and yep, fits. So one more answer that is really on topic, yay \o/

List is not part of the Unity API. So that's mission impossible. And i know that you know. Means this one was rhetoric. And did not require an answer.

You folks are really great to put words into my mouth. I am not against MSDN, i've used it too. I am just against the myth that you eagerly need MSDN to get a cube rotated in Unity.

As told, when you really need to go to MSDN every day instead of the Unity Scripting API then you most probably use the wrong engine for your job. Unity is a game engine. Designed to speed up the process of making a game.

Of course you can reuse it for other things, and extend Unity by MSDN. But that's not for what it is meant and built. And does definitely not mean that MSDN is required to develop a game in Unity.

Wiki, heh. Obtained from Unity, and put under CC, unasked. Thanks Unity for stealing my contribution

I will not touch the Unity wiki with even the longest stick anymore.

 

Now who's putting words in whose mouth?

Again with the either/or argument. Why can't you use both? The entire point I, @lordofduct and @BoredMormon have been attempting to drive home is that you should use all of the resources at your disposal.

Ultimately - I fail to see the logic behind your statement. MSDN is the official documentation for .NET. Unity uses a cross-plaform .NET. Yet somehow using MSDN a lot means you've chosen the wrong engine? Can you explain that? How would you articulate that concept to a new user?

Here's what this entire conversation boils down to. You said "You should never have to use MSDN to make a game in Unity". Three different people, all of whom work in Unity and also have experience creating software professionally, immediately jumped in and said "This is bad advice. We use MSDN all the time". In the interim, you've used muddied terminology and displayed a remarkable lack of knowledge on the subject of game (and software) development all while arguing with people, who - quite frankly - know more about this stuff than you do, simply for the sake of arguing.

To the question I asked you. I was providing a very common, but slightly complex, use case that would require you to consult resources beyond the official Unity documentation. I knew you were going to fail to find an answer because the rules you've set out for finding that answer are flawed. That was the point. And it worked because you've gone from saying "You should never have to use MSDN" to just now saying "I'm not against MSDN, I've used it too".

 

Still you:

That's not exactly how i remember the current conversation.

Yes, i know that you tried to trap me here. And i said before that List should be in the Unity API. And again i never said that i am against the MSDN. I said and still say it is not required to make a game in Unity.

And yes, i used MSDN too. I went behind the Unity limits and have implemented a Windows file browser that uses icons.

It was NOT a game. I have misused Unity for something that it is not made for.

 

Explain to me how you're going "behind the Unity limits" (I'm assuming you meant 'beyond') by writing code that uses the libraries included in the platform Unity was architected on.

Explain to me why a resource is invalid because one time you used it to make something in Unity that wasn't a game.

 

I already did a thousand times. Why do you expect another answer now?

 

Don't dodge the question. Articulate your reasoning succinctly and concisely without quoting someone else's previous post or using "because this is how I did it once" logic.

 

I guess Tiles never wrote a Coroutine... can't write one with out accessing classes outside the... cough... "unity api".

 

So why do you artficilly constrain yourself when .net is already there and is loaded with tons of useful tools, especially the different collections, linq and io

Not to mention tons of unity's own methods return .net types and even the coroutines require IEnumerator which is interface that is part of .net.

 

While technically true, coroutines are one place where the documentation outside of Unity is less then helpful. I looked over the documentation for IEnumerator on MSDN a dozen times, before giving it up as magic. There is no easy logical connection between the regular use of IEnumerator and the way its used in coroutines. Since then I've figured it out, and even gone on to write my own coroutine implementation.

Coroutines are a primary example of why MSDN should not be your first point of call for learning scripting in Unity. Get familiar with the interface and API first. Pick up the weird things Unity does with its magic functions. Then go to MSDN to delve into the details of the underlying frame work.

 

You ask the same question again and again just with other words. You already got your answer.

 

You're still dodging. Sum everything up in one post for me.

 

You ask the same question again and again just with other words. You already got your answer.

 

I don't understand your answer. Explain it to me again. Pretend I'm a brand new user and I asked the question "How much should I be using MSDN and other non-Unity resources?"

 

You already got your answer.

You really don't need me in this conversation anymore, do you? I start to scratch my own head about all the things that i should have said here. And i start to get a somehow sandy taste into my mouth.

I did nowhere say that you cannot use MSDN and that you have to avoid it under all circumstances. Allowed is what works. All i say is that MSDN is not required to develop a game in Unity. And when you need to use MSDN in Unity, then chances are big that you use the wrong tool for the job. Unity is a game engine, made to develop games.

 

System.IO is not part of the Unity API. It's part of .net, which Unity can use. Locked.