Unity accepts scripts written in C #, UnityScript (based on JavaScript) or Boo (based on Python), and compiles them in monoblocks. These assemblies + 3D models, sounds and textures necessary for your game are compressed into a .unity3d file, uploaded by their browser plug-in. Since almost all of the game’s logic is in controlled all-in-ones, it launches a cross-platform with very few specific platform features.
They recently rewrote their plugin detection and installation code, so it’s very easy to drop the javascript block on a web page that displays Unity content if the user has a plugin or other content (image, flash, video) if they don’t. I believe that their plug-in supports all A-class browsers on Mac and Windows, and the plug-in can be installed without restarting the browser.
One of the advantages of the Unity engine is that you can take many ready-made managed assemblies and include them in your project and call them Unity code. But you should know that these assemblies can really inflate the size of the .unity3d file.
Another advantage is that you can easily write components that display customizable parameters that can be changed by non-technical people.
And another advantage is that a well-written project can be ported to / from iPhone, Standalone, Android, Web, etc. during the day. I personally made an iPhone on the Internet simply by changing the input handler and changing the texture compression.
One of the big drawbacks is that since the application uses managed code, it is not difficult for a curious or malicious person to decompile assemblies into fully readable code. Therefore, you need to think about what someone can do with this information (cheat in multiplayer, write bots, fake high scores, etc.). It is possible to obfuscate your assemblies, but there is no need to add this step to the assembly process.