Posts by Sam Kalman

Here we are again, putting the final touches on the latest and greatest release of Unity — version 2.6. The team is already amazed at how many new games are being made today! They’re being rolled out so quickly that we can’t always keep up. So to help us make sure that everything in the 2.6 release is going to be 100% silky smooth compatible with all the published webplayer games out there, we’d like to ask the Unity community for some help once again.

If you want to help make Unity 2.6.0 a flawless release, there are two simple things you can do.

1) Auto-update to the 2.6 webplayer plugin by visiting this Auto-Update test page.
2) Go play as many webplayers as possible.  Try out lots of players old and new!

If you have any problems at all during the auto-update process or running a webplayer, we want to know about it immediately. Please post about it in a reply to this thread on the Unity forums. Include the URL of the problematic webplayer, and the OS, browser, and graphics card you’re using. We really want to fix everything so if you run into problems, don’t forget to post! And thanks!

Everyone knows the internet is made up of a series of tubes.  Since Unity has such a strong internet component in the webplayer, nothing but the fastest of all tubes are acceptable to deliver Unity webplayers to you and your players.

To harness the power of these tubes, Unity Tech has begun working with a content delivery service called Akamai.  Akamai provides server mirrors with fast connections around the world in order to make sure your downloads are as speedy as possible.  They do this for lots of big, well-known companies that you can see on their web site: http://www.akamai.com/html/customers/index.html

Because this download service affects users globally, we’d like everyone to help us make sure there are no kinks in the system.  If you can spare a moment, we have two tests for you to run.

Test #1: Download the Unity 2.5.0 webplayer installer through Akamai:

• For Mac: http://webplayer2.unity3d.com/download_webplayer-2.x/webplayer-universal.dmg
• For Windows: http://webplayer2.unity3d.com/download_webplayer-2.x/UnityWebPlayer.exe

Test #2: Auto-update from 2.1.0 to 2.5.0 using Akamai

Steps:

1. Download the 2.1.0 webplayer (not using the Akamai service)
   * For Mac: http://unity3d.com/download_archived_webplayer/2.1.0/webplayer-universal.dmg
   * For Windows: http://unity3d.com/download_archived_webplayer/2.1.0/UnityWebPlayer.exe
2. Install the 2.1.0 webplayer
3. Restart your browser
4. Visit this url to auto-update using Akamai: http://beta.unity3d.com/AkamaiTest/

Both test #1 and #2 should be blazing fast.  If you can, please leave a comment about where you’re located and your average download speed, we’d greatly appreciate it!

With Unity 2.5.1 quickly wrapping up development, the last item on our to-do list is verifying webplayer compatibility.  As a team we do systematic testing on a broad range of weplayers.  However, we really want 200% confidence instead of a measly 100%.  So we’re asking for a little help — from you!

If you want to help make Unity 2.5.1 a flawless release, there are two simple things you can do.

1) Auto-update to the 2.5.1 webplayer plugin by visiting this Auto-Update test page.

2) Go play as many webplayers as possible.  Your own or someone else’s, published or unpublished, anything you can find.

Every game you play should look and behave exactly the same as it did before the update.  In fact, if you see any differences (or problems) at all, write us an email at support@unity3d.com.  Include the url of the problematic webplayer, and the OS, browser, and graphics card you’re using.  It’s best to let us know right away so we can fix it immediately!

We already know the Unity community is amazing, and this is your chance to actively participate along with the development team to ship a new version.  Rock ‘n roll, and send your pre-release 2.5.1 webplayer bugs to support@unity3d.com!

Assuring quality is a tricky task, and involves a lot of people — testers, developers, and even you the users! There are thousands of you and only a few of us, so today I want to talk to you about this:

If you see this Bug Reporter appear, odds are that you’ve just experienced a problem in Unity. I can honestly say that whatever it is, we want to fix it. As part of our QA processes, the test team (currently: me, Jens, Caitlyn, Rasmus, and Oleg) constantly review “the queue” of publicly submitted bugs in our QA/support database. We can do more with some bugs and less with others, and I want to help everyone understand how to tell us about their problem so we can actually fix it.  When we review bugs, here’s what we think about:

What happened to this user and how did it happen?

Can I force Unity to do it again for me?

If we can answer both of these questions then we have enough information to investigate the issue and communicate our findings to you the user, or to a developer when discussing a fix for the issue. For this reason, the information you write in details 1) and 2) in the bug report is critical in helping us squash the bug forever.

Now, if we can’t understand what happened in the first place then there isn’t much we can do about the problem. So under detail 1) we ask that you thoroughly and completely describe the problem, using as much detail as you possibly can. The worst thing you can do here is write nothing. Writing anything you think is relevant to the problem is always better than writing nothing.

Once we understand the issue, we want to reproduce it. When we try to reproduce it, we perform a series of actions or “repro steps” to make the bug occur again. The first place we look for help determining the right set of repro steps is under detail 2). If the bug you’re reporting is frequently or consistently occurring, the best thing you can do is describe a discreet series of steps that we can take in order to reproduce the bug.

Sometimes a bug is specific to the scripts or assets in your project folder.  In case it is, we ask that you always attach your project folder so we can make our test environment match your development environment as closely as possible. The bug reporter will automatically zip your folder and upload it, even if it’s as large as 500MB. And don’t worry, your project will only be used for testing purposes and it will never be shared outside of the Unity Tech office. If you can isolate the problem down to an extremely simple project folder that contains only the assets and objects relevant to the bug, even better!  Either way, providing a project folder will greatly increase the likelihood that we can successfully reproduce the bug and fix it. But I’ll reiterate: if we cannot reproduce the bug, we cannot fix the bug.  So pretty please with sugar on top, attach your project folder because we hate not fixing bugs.

I hope this has been an insightful look into our QA processes and you understand a bit more about the purpose of the bug reporter. To learn even more about bug reporting and the Unity QA processes, please watch the “How to Get Your Bugs Fixed” presentation video from Unite ‘08.