Archive for the ‘General’ Category

A long held dream in the development world has been the idea of “author once, deploy anywhere”. To explain what is meant by that is simple, it’s the notion of being able to author your content one time, then through the simple click of a button deploy your content on any platform you like, whether that’s on the desktop, the web, gaming consoles or mobile devices. Nobody is quite there yet and there is more work to be done, but with that in mind Unity Technologies is making tremendous progress in making this dream a reality, and Unity is already used by thousands to distribute content across a variety of platforms. While the benefits of this author once deploy anywhere notion might seem clear at first blush, there are a few points worth discussing in particular, so let’s look at those in a bit more detail.

Read the rest of this entry »

In my other recent blog post I described the webplayer regression rig which we are building.  When we find regressions it is extremely helpful if we have access to the project folder used to create the game we have broken.  Seeing exactly how assets are handled and the script involved can save us a lot of time.  Also, we’d love to extend the regression rig and get it to test daily builds of the editor, too.  We would love to launch Unity, load up your project file and check that everything still works, including asset importing and building the game. Testing real world project files will help us make Unity better.

If you felt able to provide us your project folder please contact us at support@unity3d.com, let us know who you are and where your game is online.  We can then talk to you about how best to get us the project folder.  We see the benefit to you is knowing that future Unity release work seamlessly with your project and your upgrade costs are minimized.  This can save you some frustration too.

Possibly you might feel uncomfortable sending us your assets.  I have written a short FAQ that should help answer some of your concerns.  Feel free to ping me on the forum (handle is dendrophile) if you want to know more.

One of the unwritten commitments we make to our customers is that our webplayer will play back their content identically in all versions we publish.  We constantly tweak and improve the webplayer. For example webplayer 2.6 added threaded background loading and improved animation culling. Each change that we make intending to improve the webplayer has the potential to break a customer game, and we don’t like that.  Remember, webplayer 2.6.1 can play content authored with Unity 2.0, 2.1, 2.5 and so on.  To make sure that we don’t break customer games with new webplayers we have to do a shed load of regression testing.  Lots and lots and lots.  So much so we have built a dedicated test rig to do the testing for us.

The regression rig has a server and multiple clients. The clients are PCs and Macs with our internal daily build webplayer installed. A server has a big list of our customer games, and sends jobs to each client that basically say “play this customer game”. Through a little bit of magic the clients take screen shots every second that the game runs, and these screen shots are forwarded onto the server as a record of the test execution. Currently we have nine clients (7 windows and 2 mac) in the rig.  Seven of these are physically located in our UK “test room”, the other two machines are under developers’ desks.  We are slowly adding more machines. When a webplayer is installed we get a snapshop of the machine configuration.  Using this database we can make sure we have the most popular machine specs represented in the rig.

Photo of the regression rig

Obviously, the games require inputs such as keyboard and mouse entry, random numbers, assets fetched from remote websites.  These inputs are all faked up when the regression rig runs.  What we do when we first get our hands on a customer game is give it to one of our testers who plays the game for us on the rig using the latest released webplayer.  In this manual first-run mode we capture all the inputs and store them in an input file.  Once we have this, we then generate a “golden” set of screen shots and know that these inputs generate these images.  The idea is that we now know what images the game should generate with a given set of inputs.  The regression rig can then compare images obtained from a customer game played back using the daily build webplayer against the golden set and we can tell quickly when one of our talented developers has broken something.  When we find we have broken the webplayer we can iterate back through code checkins looking for the commit that first introduced the problem.

The regression rig should help us find problems with the webplayer before you do, but as always, please let us know (by sending in a detailed bug report) if you have issues when you publish your game to the web. Oh, and for the record we do have people employed to do testing, it is not all done with the rig.

…I took a plane to Copenhagen.

Well ok, it all started a bit before: Read the rest of this entry »

The UK Office

Hello everyone!

My first blog post is to announce that our UK office is open and rocking already. There are now five of us working for Unity Technologies from the UK, and we have started recruiting heavily to fill more positions. I will talk about what we are doing at this office in a separate blog post, but put simply we are doing a lot of community, support and QA work here. The office is in a converted convent, at least according to local legend. There is certainly a statue of the Virgin Mary on the end wall of the building. Some of the offices are small and are meant to be where the nuns slept.

Yesterday we had Samantha and Oleg visiting us, so we took a photo to prove to the Danes that we do exist.  Sadly Matt was ill, so the photo only shows 6 of us.

This may not be our final home, but it is convenient for now. As we grow we will look for more permanent and scalable offices. I am thrilled to be involved in the start of this UK arm of Unity Technologies.

Thanks,

Graham

UK office crew — (From left, Oleg, Samantha, Chris, Dave, Graham and Andy).

Recently, some Unity customers who have been very anxious to get their iPhone game approved by Apple, have received a rejection notice because they use something that was no longer approved by the Apple rules.

We have been working hard on this issue as it stalls and affects our iPhone developer customers. We were able to correct the issue 2 days after we first heard about it and delivered that fix to those who had reported the problem. Many of them have been already resubmitted their application to Apple. The first Unity game to completely pass the App Store Submission Process is “Star Wars: Trench Run”.

We will be releasing this new version, Unity iPhone 1.5.1, publicly on our website sometime next week. In the meantime, if you have an urgent need or concern, please contact oleg@unity3d.com and request an iPhone build with this issue fixed.

Note that Unity games already on the app store are not affected by this.

For those who are interested here are the technical details:

What do those functions actually do?

_NSGetEnviron is used by the Mono runtime to provide an implementation of the .NET core API method: Environment.GetEnvironmentVariable(). On UNIX environment variables are often used to pass arguments to applications. Due to how the function is exposed, it does not let developers do any data collection.

exc_server is used by the Mono runtime to provide graceful NULL reference exception handling. This is useful for developers, when they dereference a null pointer, we can avoid a crash and instead throw an exception and continue the game.

While those functions are useful for debugging purposes, Apple now rejects Apps that use them.

In order for us to solve this problem we simply removed any calls to _NSGetEnviron and exc_server. Update Unity iPhone 1.5.1 was sent out to developers days ago. Most of them have already resubmitted their Apps to the AppStore with the functions removed. Unity iPhone 1.5.1 will go live this week. The first Unity game to completely pass the App Store Submission Process is “Star Wars: Trench Run”.

Hi guys & gals.

I’m giving a talk about the inner workings of immediate-mode GUIs at GDC Europe tomorrow (in Cologne). Looking forward to doing it – it’s been my main Unity development area for the past 2 years, so I guess I somehow ended up being an expert on that subject It’s Monday at 2:10 – 3:00 PM

If any of you are there, I hope you come – and if you want to meet up in Cologne, drop me a mail or a PM on our forum, and I’ll try to squeeze you in.

I interact with the WordPress blog engine both here at work as well as at home for my personal blog. Given that WordPress experience, and the fact that I work at Unity Technologies, makers of the Unity Web Player, I guess it’s only fitting that I created a WordPress plugin to allow blog authors to easily include Unity Web Player content in their posts. My point of shame in this is the fact that I created the plugin last Fall and haven’t really done much with it since, my bad!

Example: The Island
Here is an example file that you developers should recognize, it’s a published version of the Island demo we include when you install Unity:

Description
The plugin is simple to use and requires some straightforward mark-up tags within your blog post. Those tags are read by WordPress when showing the post and the needed page edits will be made to show your Unity Web Player content. The plugin includes support for both Unity Web Player 1.x and 2.x content. The plugin allows you all the same options as the native object/embed tags so you can enable/disable the context menu or the ability to go fullscreen, to use custom loading screen graphics or to specify your own install prompt image and more.

Download
Please feel free to download my WordPress plugin and put it to use right away:

WP_UnityObject

The download contains a readme file with instructions, have fun!

Edit Note (May 20, 2009): the download link has now been changed as the plugin is available from the Resources area on our website.

I always thought that the license comparison page on the Unity website was – well, not confusing, but at least not quite as clear as it could be. That’s why I have spent the last few days creating a new Unity License Comparison table with the help of my colleagues, where the differences can be seen absolutely clearly between Unity Pro, Unity Indie, Unity iPhone Advanced, Unity iPhone Basic, and even Unity Wii.

So if you’re in doubt about which features come with which licenses, head straight to:
Unity License Comparison

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.