I am not sure if this is the right forum for my question, but since I could not find a web development forum, I figured the windows one would be my best bet.
I wish to understand how publishing through the Unity web player works and how it differs from publishing through a stand alone desktop download.
Googling around this topic I could not find a description clear enough for a noob. The Unity doc pages returned by my googling mostly contains click here/click there instruction recipes without detailed explanations of what’s going on under the hood after each click that makes the recipe work.
From what I partially gathered it seems that:
a web player build creates a file with extension .unity3d which URL must be embedded in some HTML page which own URL will be requested by the gamer’s browser to start playing the game ;
this .unity3d file is a proprietary format archive that contains a main CIL file plus some other files of various extensions containing the game assets used by this main file ;
the web player uncompresses this .unity3d file, JIT compiles the main CIL file that it contains it into an executable binary file (i.e., .exe when the browser runs on windows), creates a folder on the gamer’s computer containing the asset files, and runs the binary file to start the game using the Mono CLR that was installed on the gamer’s computer when (s)he accepted downloading the web player.
Is that it in essence? Or am I confused ?
If this is it, then can I conclude that in terms of gamer experience game piracy the main difference between web player deployment and stand alone deployment are :
With the former (web) the gamer has to explicitly download Unity’s web player browser plugin while with the latter (desktop) (s)he has to explicilty download the game’s .exe file + asset file folder
With the former (web) the main game file transfered to the gamer’s computer is a compressed .cil file while with the latter (desktop) it an .exe file that is transfered which makes it a bit harder to decompile and pirate ?
What is the advantage then for a game studio to deploy its Unity game as a browser game rather than as a stand alone desktop game in terms of the trade-off between frictionless first-time gamer experience vs. piracy protection ?
As for the Unity game engine classes that the game classes specializes or calls, where are they found ? Compiled to CIL in the .unity3d archive for web player deployment vs. compiled to native code in .exe (or perhaps .dll) binary file for stand-alone Windows deployment ?
Thanks a lot in advance for helping me understand of all this stuff.
you got most of it correctly, except on standalone game, CIL code is not embedded into .exe file - it is inside separate DLLs.
As for the piracy protection: I wouldn’t compromise gamer experience just in spite of increased piracy protection as preventing piracy is almost impossible, while making stuff harder for legit customers really hurts your image.
Thanks for your answer. By CIL code been “embedded” do you mean compiled?
And do you refer to the game own code? Isn’t there a need for some .exe file in addition to the .dlls?
So what does this .exe file contains then? The compile code of the Unity game engine core?
I hear you but my question was that it seems that now that the browser providers (Google, Mozilla, MS) have turned-off web plugins by default, deploying through the web player seems to be the worst option on both front: easier piracy (cil file on the user’s disk instead of exe/dll file) and just as much friction for the legit gamer.
But I am probably missing some key other aspects/differences that still justify using the web player for deployment. I wish to hear from them.
Concerning piracy, don’t you think that a distributed deployment as a (web or desktop) client + authoritative server requiring online authentication before play makes it considerably harder? Even though the complexity overhead and hence development + sys admin cost overhead of such solution (using for example uLink and some server hosting service) may be higher than the revenue loss through piracy :sad:
The .exe file on the standalone game is Unity player code, and it is not compiled when you press build, but rather it comes precompiled when you install Unity. C#/JS code gets compiled to CIL DLLs, which are put in a folder near the .exe file. On Webplayer, the same DLL files would get extracted to user disk, so there’s no difference in code format there.
As for piracy: it’s always up to you, but remember, your protection efforts are very likely to go in vain, as popular games get pretty much cracked within 24 hours of their official release. Look at it from another perspective: how many gamers who usually pirate stuff would instead buy the game just because there is no pirated copy available? I personally think that the number is pretty low. And requiring online authentication for single player game usually results in very negative gamer reactions. Check SimCity story, for example :).
OK, thanks a lot for your explanation. So what are the advantages of a web player distribution as opposed to a stand alone distribution? (in general not just wrt piracy ease)
Even if carefully obfuscated?
I look at it from this perspective: how many people who want to play a game (or listen to a song, or watch a movie, or read a book) will pay for it when they can have it for free by just scrolling down a few google result pages and then follow a few clicks instructions?
Wouldn’t THAT be very low indeed? Unless the selling price is so ridiculously low as to not cover for development, maintenance, distribution, marketing and tax costs.
Well, I had to authenticate myself on this forum to post my questions. I authenticate to read my email, to shop online. I authenticate myself all day for most of what I do online. What’s the problem with authenticating to play? Besides, aren’t most PC gamers today play on Steam and hence don’t mind both paying and authenticate themselves?
IMHO, the problem with the botched SimCity launch was not requiring authentication. It was EA vastly underestimating the success the launch will be and hence not provisioning enough servers to handle it. And then not proposing refund to compensate paying customers for this mistake.
Thanks again for the time you spend discussing these issues w/ the naive noob I am
I suppose that depends on your distribution model. The only advantage I can think of is that users won’t have to explicitly download stuff for your game, as Unity web player works across many games and we have a huge install base. It may also be easier to attract users to actually the try game with webplayer.
Let’s put it this way: the only non pirated games AFAIK are those that are either free, not popular at all or requiring constant server connection (like Diablo 3), and you can count the latter on fingers. Furthermore, even they get pirated as somebody will manage to make a server side for them eventually (thinking World of Warcraft, SimCity).
Well, my reasoning would be because piracy breaks the law and paying supports the developer who created the game. Pirated software is really easy to get if that’s your intention.
If you’re distributing it as standalone game, one would expect to be able to play without internet connection :). Steam lets you do that, by the way, as long as you authenticated once.
The Windows forum is for WP8-related stuff; the web player can’t run there and normal stand-alone Windows executables are a different thing.
This has already been discussed to death, but: Everything is already available like for free like that, so what makes you think you can be the exception? The SimCity debacle had such a negative effect on EA that they are specifically advertising the new Sims game as “an offline single-player experience”, like it’s a new feature or something. The only way to make a game “unhackable” is to have all the logic run entirely on a server.
In any case, the reason for web player vs. standalone isn’t related to piracy. Think about the kinds of games you typically find on the web (Flash, Unity, and so on) vs. the kinds of games you typically find distributed as stand-alones. There’s a certain amount of overlap, but consider what a typical “web” experience would be and why you might want a game embedded in a website.
