The web-build process in Unity

edited in General
To those of you who use Unity: what is the process of creating a web-player build? Do you just press a button, and have an html document and collection of files dumped into a folder somewhere (presumably relevant to the project, or nominated by you)? Is there more involved?

I ask because I'm struggling a little with Panda3D's approach to creating a web-player build -- don't ask, I still haven't figured it out and thus am not in a position to relate it ^^; -- and would like to get an idea of what it looks like in Unity, which seems to have a fairly mature web-player and which is fairly user-friendly, and which I therefore imagine has a decent process.

In all fairness, I strongly suspect that a big part of the problem that I'm having is simply that I have very little experience with building for the web: it's not something that overmuch interests me, and I have no real intention of any of my currently-planned projects being distributed as web-builds outside of demos on this forum. (Being rather tired at the moment probably isn't helping. ^^;; ) I therefore don't really know what to expect, or what I should expect.

(For what it's worth, I'm currently having trouble with the step of getting the browser to automatically detect and offer the Panda3D plugin, rather than asking people to go to the Panda3D download page themselves and download it. Unity seems to do this -- I seem to recall that it provides a button that redirects you to their download page if you don't have the plugin -- and I'm told, I believe, that Panda has this functionality, but am struggling with the tool that is apparently supposed to provide it. While I wait for a response on their forum (which shouldn't take long) I thought that I'd ask for information on Unity for comparison.)

Comments

  • To those of you who use Unity: what is the process of creating a web-player build? Do you just press a button, and have an html document and collection of files dumped into a folder somewhere (presumably relevant to the project, or nominated by you)? Is there more involved?
    Yup.

    The exact sequence is as follows: File -> Build Settings, select Web Player, click Switch Platform, click Build. Select output directory.

    Done.
  • And then you just upload all the resultant files to a web host of your choice -- no additional html files to create, or anything like that?
  • Yes, you can embed the game in your own html files if you want however. Also the output lets you choose between a white and a black background.
  • There's a bunch of other options that the plugin gives you, like whether you want the right-click menu to be active or not, those are pretty easy to access as settings in Unity itself.

    We've got our webplayer include embedded in a wordpress page on our site and all I do every friday is upload a new file with a different number at the end and change the reference on the page once the file's on our server :)
  • Random curiosity @dislekcia how big is your compiled project now?
  • Ah, I see -- thank you both. ^_^

    Well, that leaves me rather disappointed with the Panda3D process of making web-builds -- and I believe that I've just found out why that is in the reply to my post on their fora:

    Simply put, it looks as though I was wrong about web-builds being their primary focus in build targets. A mechanism (which they do describe as clumsy, as I recall) does exist for creating web-builds, but it's something that they put together specifically for the Disney Online games that were built using Panda.

    So, it looks as though I can probably still produce web builds, but it looks as though it means having users accept a self-signed certificate (which means a dialogue box popping up to check that they're okay with this non-authority-sourced certificate; I really don't want to deal with getting a proper authorised certificate for a demo that's only intended to be shown on this forum), and downloading and installing the Panda3D runtime via a link that I should be able to provide on the embedding page.

    If that's strongly preferred, then fair enough, although I still think that a single-download, offline installer should be much simpler, and I doubt that it installs much, if anything, that the plugin wouldn't install anyway.
  • @tbulford: Just over 26MB. We don't have any music in the beta right now, our textures are pretty large though, have to do everything uncompressed, otherwise our pixel art looks horrible.
  • everything uncompressed
    I can only dream.

    :D

    @Thaumaturge: I think the point is to have it be (1) easy and (2) transparent. Why people seem to like web builds is that it's both: you load the game in one click, and it's kind of running in a little sandbox and is unlikely to fiddle with the rest of the computer. Some kind of zip file's next best because it's simple and self-contained. Unzip, play and delete if I wish, and I can be more confident that there's no extraneous stuff left behind. (Although if your game is pitched super amazingly, I imagine I'd jump through a few extra loops or put up with risks to play it.)
  • edited
    I've just been given some clarification on the Panda fora:

    In short, the web-build is their intended primary distribution method, with users being intended to donwload and install the plugin themselves (which they apparently feel allows the user to feel more comfortable about what's being installed on their computer). As to automatic plugin detection, let alone for all platforms and (I presume major) browsers, they simply don't have the manpower that Unity has to maintain such a thing. They're apparently open to community maintenance -- indeed, Panda seems to be very open to community participation, and the community has provided some very useful fixes and features, I believe -- but don't have someone at the moment.

    [edit]
    @Elyaradine: Erm... While I could see some degree of sandboxing (but then where do save-games go?), I can be pretty confident that the plugin itself will install engine components, just as the installer would. While it's possible that game-specific stuff might be left behind, most of what would be likely to be left behind -- dlls, saves-games, log files, etc. -- are things that I'd expect a plugin to leave behind too, with the possible exception of the save-games.

    [edit 2]
    I can see some worry about game files, admittedly, but with a decent engine surely that would involve explicitly putting things in directories outside the game directory, which would be a potential problem with a zip file too?
  • @dislekcia all the sprite texture for Toxic Bunny HD in unity are also uncompressed Texture compression not good for pixel art or gui. Background textures we can compress at least.

    @Thaumaturge you can save data into player prefs or you should be able to create a web service you can call with the save data (I don't know if there are some specific limitations there.)
  • This whole discussion over the past couple of days has got me thinking about dev tools again. I've always taken a lot of time to select tools that allow for easy exporting and releasing, but it seems like for many people this isn't really that much of a concern when picking stuff to work in.

    I feel like it's actually one of the primary things that makes a project succeed or fail. If giving a build to friends to test is as easy as pushing a button and giving them 1 file that just fucking runs, no matter what, that's going to result in a lot better feedback, more often and from more people. We know that's what games need (just like electrolytes, yo) but so often just putting a build out there is an almost-insurmountable hurdle.

    I have some anecdotal stuff floating around in my head about how projects built where making a build = 1 button push get way less up their own butts than projects where making a build = sacrificing correctly-sourced root vegetable virgins to the dark apparition Yth-jnochm'el on the winter solstice, but that might well be bias on my part.
    Thanked by 1tbulford
  • @dislekcia ohh I remember doing builds like that back in 1996 make files tasm, two different c and c++ compilers dos4gw and several of our own file formats. Not fun was about 15m a build just to test.
  • @tbulford:
    you can save data into player prefs or you should be able to create a web service you can call with the save data (I don't know if there are some specific limitations there.)
    Ah, thank you. Given my inexperience with web-based development, the web service sounds rather more involved than I'm inclined to invest in for a small demo of a project that I don't intend to release as a browser-based game in the end...

    As to player preferences, it's entirely possible that that's something that the plugin handles automatically -- I would imagine so. The problem, of course, is that this removes the sandboxing that was given as a point in favour of web-builds.

    @dislekcia:

    ... I'm honestly not sure of how to interpret the idiom in your final paragraph. I get the general idea, just not what, precisely, you're saying the result of such things is. (Are you saying that such developers tend to become blinded to the problems in their chosen engine? Lost in their own project, lacking feedback? Arrogant? Something else entirely?)

    That said, I think that you have some fair points there.

    I do feel the desire to respond with regards to my own choice of Panda3D, and the build process thereof:

    First of all, as far as I recall -- I chose Panda quite some time ago now, I believe -- it's true that I didn't consider the build process in picking Panda. I was less experienced then, and looking for something to fit a specific project (since put aside), I believe. For what it's worth, I'm not sure of whether Unity was available for Windows at the time -- Wikipedia indicates that it was first released in 2005, but only for Mac, and I don't see mention of when it was first released for Windows.

    However, I don't think that Panda's build process is as bad as you seem to have inferred -- it's far from perfect, admittedly, and not a single-button system, but it's not all that bad.

    The main point that I have against Panda is that, unlike Unity, it lacks a development environment: editor, asset-manager, version control, etc. (I think that an early version of one has been produced by a member of the Panda community, but I haven't looked closely at it.)

    As a result, all building is, alas, command-line driven.

    The build process:
    * To start with, run one command (with a few parameters, such as output file-name, full project name, version, etc.) to produce a .p3d file.

    --- If you want a self-contained installer, as I was producing for ArcanoTrack, run one more command (again with various parameters) to produce the installer. If you don't specify, it will attempt to produce them for every platform that it supports, which I believe amounts Linux (i386 and amd64), Windows and Mac (i386 and ppc, although I think that they're dropping the latter). Note that producing a Windows build on Linux calls for installing the "makensis" utility.

    --- If you want a web-build, and don't mind a manual link to the plugin, then produce a web certificate, either self-signed or produced by a certificate authority. Due to my unfamiliarity with such things, I won't attempt to go into detail, save to say that self-signing involved two more commands.

    What I've been struggling with is something specific: not just making a web-build, but making one that automatically offers the option to download the player (as part of the plugin, not as a separate link on the page).

    As to "one file" distribution:
    From my point of view the "one file" method that you describe is what I was doing when building the installer version, but that version was disliked for potentially installing elements to parts of one's hard drive other than the installation directory, as I understand it -- but then, as I've said, I imagine that a web plugin does much the same.

    I've been working on the principle of making things easy for users, and to reduce the number of steps involved, even when those users are no more than the members of this forum, hence my desire to make installation of the web-player automatic.

    ~~~~~

    Now, in all fairness I seem to recall that I did fairly recently re-evaluate my choice of Panda as my personal development engine: I have experience with Unity, and recall rather enjoying it. As far as I recall, the important points for me were these (leaving out weighting -- this post is getting long enough as it is ^^; ):

    Panda:
    + Is the engine that I'm more familiar with.
    + Has an active and helpful community.
    + Is entirely free -- no "pro version" that I'm required to pay for.
    + Seemed to have a preferable licence.
    - Lacks a development environment.

    Unity:
    + Is very user-friendly, including a full development environment.
    + Is an engine that I am familiar with.

    (Perhaps Unity has a similarly enjoyable community -- I don't know, not having experience of it.)

    ~~~~~

    My apologies that this post became so long! I felt, I fear, that I had a fair bit to say in response; thank you if you took the time to read the above.
  • @Thaumaturge
    As to player preferences, it's entirely possible that that's something that the plugin handles automatically -- I would imagine so. The problem, of course, is that this removes the sandboxing that was given as a point in favor of web-builds.
    Actually the web player still keeps you in a sandbox the PlayerPrefs are saves to the local machine but it doesn't give you access to anything other then the PlayerPrefs. Essentially its just a large set of properties. Forgive me if you know these links already just here for completeness. http://docs.unity3d.com/Documentation/ScriptReference/PlayerPrefs.html

    As for the Unity community its extensive and very active. Right down to building plugins and extensions for unity as well as assisting on there forums. http://udn.unity3d.com/

    I have not worked in Panda3D having said that I have built my own engines in c++ and Java and now use Unity. I hardly see Unity as a one stop for all things. We have one game engine built in Mono now too. I think the point @dislekcia made was more about how important an easy build cycle is and that it helps get new versions easily to your testers or players.

    Build your game in any language or as many as you can. I just want to see it and play it. I doubt anyone here feels you need to defend you choice of using one engine over the other. That said debating the merits of each engine can be useful for us all.
  • Actually the web player still keeps you in a sandbox the PlayerPrefs are saves to the local machine but it doesn't give you access to anything other then the PlayerPrefs. Essentially its just a large set of properties. Forgive me if you know these links already just here for completeness. http://docs.unity3d.com/Documentation/ScriptReference/PlayerPrefs.html
    Ah, I see, I believe -- can you actually write a file to that, though? My save-games are... well, large, I'm afraid. ^^;

    As to the build cycle, I do understand -- and agree -- that an easy build cycle is a significant boon to a developer. (Indeed, I've passed on the sentiment on the Panda forums.)

    I apologise if I was overly defensive regarding Panda -- it's entirely possible that my mood and lack of sleep of late affected my perception there.

    Nevertheless, even my own choice of engine aside, I get the feeling that I'm giving a poorer impression of Panda than is perhaps entirely fair to it: I've complained about difficulties, but not really mentioned its positive aspects, the things that I enjoy about it, and additionally in those complaints may have made the related problems seem worse than they are.

    As to my game, I'm getting there, I think. Aside from my teething troubles with the build process I've also discovered bugs on my side that don't really show up in the development version. For example, I recall that I had two places in which I was programmatically loading Python modules by looking through a directory and importing the Python files there found. Of course, I wanted to attempt to load only Python files, so I was checking for the extension ".py". This works well during development.

    Unfortunately, once the game has been built, those .py files become optimised .pyo files...
Sign In or Register to comment.