Special Folder Names in your Assets Folder

http://wiki.unity3d.com/index.php/Special_Folder_Names_in_your_Assets_Folder

 Standard Assets

Scripts in here are always compiled first. Scripts are output to either Assembly-CSharp-firstpass, Assembly-UnityScript-firstpass, or Assembly-Boo-firstpass, depending on the language. See http://docs.unity3d.com/Documentation/Manual/ScriptCompileOrderFolders.html

Scripts inside the Standard Assets folder will be compiled earlier than your other scripts. So, placing scripts in Standard Assets is one way for C# scripts to be able to access .js scripts or vice-versa.

Pro Standard Assets

Same with Standard Assets, only files here are meant for the Pro version. This means assets here make use of Pro-only features like render textures and screen-space effects.

Again, scripts here are compiled earlier, allowing them to be accessed by other scripts (of any language) that are outside the Pro Standard Assets folder.

Editor

The Editor folder name is a special name which allows your scripts access to the Unity Editor Scripting API. If your script uses any classes or functionality from the UnityEditor namespace, it has to be placed in a folder called Editor.

Scripts inside an Editor folder will not be included in your game's build. They are only used in the Unity Editor.

You can have multiple Editor folders throughout your project.

Plugins

The "Plugins" folder is where you must put any native plugins, which you want to be accessible by your scripts. They will also be automatically included in your build. Take note that this folder may not be in any subfolder (it has to reside within the top-level Assets folder).

In Windows, native plugins exist as .dll files, in Mac OS X, they are .bundle files, and in Linux, they are .so files.

Like the Standard Assets folder, any scripts in here are compiled earlier, allowing them to be accessed by other scripts (of any language) that are outside the Plugins folder.

Plugins/x86

If you are building for 32-bit or a universal (both 32 and 64 bit) platform, and if this subfolder exists, any native plugin files in this folder will automatically be included in your build. If this folder does not exist, Unity will look for native plugins inside the parent Plugins folder instead.

Plugins/x86_64

If you are building for 64-bit or a universal (both 32 and 64 bit) platform, and if this subfolder exists, any native plugin files in this folder will automatically be included in your build. If this folder does not exist, Unity will look for native plugins inside the parent Plugins folder instead.

If you are making a universal build, it's recommended you make both the x86 and x86_64 subfolders. Then have the 32-bit and 64-bit versions of your native plugins in the proper subfolder correspondingly.

Plugins/Android

Place here any Java .jar files you want included in your Android project, used for Java-based plugins. Any .so file (when having Android NDK-based plugins) will also be included. See http://docs.unity3d.com/Documentation/Manual/PluginsForAndroid.html

Plugins/iOS

A limited, simple way to automatically add (as symbolic links) any .a, .m, .mm, .c, or .cpp files into the generated Xcode project. See http://docs.unity3d.com/Documentation/Manual/PluginsForIOS.html

If you need more control how to automatically add files to the Xcode project, you should make use of the PostprocessBuildPlayer feature. Doing so does not require you to place such files in the Plugins/iOS folder. See http://docs.unity3d.com/Documentation/Manual/BuildPlayerPipeline.html

Resources

The Resources folder is a special folder which allows you to access assets by file path and name in your scripts, rather than by the usual (and recommended) method of direct references (as variables in scripts via drag-and-drop in the Unity Editor).

For this reason, caution is advised when using it. All assets you put in the Resources folder are always included in your build (even unused ones), because Unity has no way of determining which Resources-based assets are used or not.

One distinction though, is that when assets are accessed as variables of MonoBehaviour scripts, those assets get loaded into memory once that MonoBehaviour script is instantiated (i.e. its game object or prefab is now in the scene). If you need more control of when to load it into memory (perhaps for low-spec devices), consider putting them in a Resources folder and loading them via Resources.Load.

You can have multiple Resources folders throughout your project, so it is not recommended to have an asset in one Resources folder and have another asset with that same name in another Resources folder.

Once your game is built, all assets in all Resources folders get packed into the game's archive for assets. This means the Resources folder technically doesn't exist anymore in your final build, even though your code will still access them via the paths that existed while it was in your project.

Also see http://docs.unity3d.com/Documentation/Manual/LoadingResourcesatRuntime.html

Gizmos

The gizmos folder holds all the texture/icon assets for use with Gizmos.DrawIcon(). Texture assets placed inside this folder can be called by name, and drawn on-screen as a gizmo in the editor.

WebPlayerTemplates

Used to replace the default web page used for web builds. Any scripts placed here will not be compiled at all. This folder has to be in your top-level Assets folder (it should not be in any subfolder in your Assets directory).

StreamingAssets

Any files in here are copied to the build folder as is, without any changes (except for mobile and web builds, where they get embedded into the final build file). The path where they are can vary per platform but is accessible via Application.streamingAssetsPath (http://docs.unity3d.com/Documentation/ScriptReference/Application-streamingAssetsPath.html) Also see http://docs.unity3d.com/Documentation/Manual/StreamingAssets.html