Hi - I'm Nicholas Francis, one of the Unity founders. First, I was the graphics programmer, as well as writing a fairly big chunk of the editng functionality. Now I'm the "User Experience" guy, which means I design & implement the Unity Editor GUI, handle the website, docs, etc... Basically, all the touchy-feely bits. In between these 2 roles, I was game director on Global Conflicts: Palestine - doing the game design and a fair amount of programming. Oh and I also code quite a lot ;)

Unity is designed to be an integrated tool for developing and publishing games to Windows, Mac, Web and Nintendo Wii. Unity is an integrated development environment where you assemble all your assets & set up your game code scripts to pull your game together. 3D models are either exported from your app as .fbx files, or in many cases just saved in their native format - then Unity will import the models. Textures can be any format - including multi-layer photoshop files. You assemble scenes in Unity, Setting up lighting, triggers, sound, etc. You also script your game code using JavaScript, C# or Boo. Unity is designed to be an intuitive tool that will enable a lot of people to make games - our rule of thumb is that if you've created a game in Flash, you'll be able to make it in Unity...

Unity got started by Joachim Ante and me joining forces to create a game engine. We were working on different games at the time, so Unity was an engine that was made to do a top-down racing game and an underwater top-gun flight simulator. Both these projects got scrapped - but they still forced us to constantly think in terms of making things flexible and not tying Unity down to a specific genre. After that, we wanted to do a futuristic helicopter sim, a Wipeout clone and an incredible machine-like domino-toppling game. All of these got scrapped as well ;) - before we did GooBall. Each of these projects matured Unity and made sure it was never linked to a specific kind of game.

None of us (which at that point was 3 people) were really busy to be shipping a game. That meant that we not only made an engine, but did a complete editor as well - we thought it sucked too much if you had to edit properties in text files (seriously, XML sucks), so we spent a lot of time making sure that if you have a gamecode script, all properties automatically show up in the editor. We also wanted to keep artists in the creative flow, so we made sure we could import all graphic formats (including layered PSD files) with no loss in performance. Same for 3D models - just save a maya binary file (or about 5 other formats) in your project, and Unity will automatically import it and update it across the entire game - in 2 seconds flat.

At that point in time, we still considered Unity to be an in-house tool. However, we had showed it to some talented graphic artists and were amazed at what they were able to do with it - without any introduction.

It all ties together - I have this theory: When creative people grow up, we want to create the media we consumed as kids (quite a few of us start doing that before we grow up ;). In films, when the DV cameras started appearing suddenly everyone was able to make movies - and a lot of people (myself included) went and did just that. With games, there still was a huge initial investment - it was like everyone was busy building their own camera from scratch. We sat down and saw that Unity was user-friendly enough to be able to kickstart this process for a whole generation. Hence, we had this hope of starting a game-making revolution. Once we looked at it like that, how could we not release it?

It just works. You don't need to spend a lot of time installing developer tools, compiling some source code you don't really know what does, digging into complex C++ code. All of these things are basically keeping you from making your game. At first, you think this is a necessary step to game crafting, but once you've tried Unity, you'll wonder why no-one else has done it this good.

The main thing that makes Unity tick is that the entire OtEE crew are passionate perfectionists. We want to create the best tech, give the best editor interface to this tech and even write the best docs about it. About 50% of our source code commits are done at 2AM because we just love Unity so much.

If I have to pull out a specific feature it would be our scripting interface: We use Mono to get C#, JavaScript and Boo languages in there for gamecode. This means you get a scripting language running incredibly fast (*footnote: Initially, we used Python for GooBall. With that we were spending 50% of the CPU time inside scripting code. When we switched to Mono, the same functionality dropped to 1-2% CPU usage - we were completely blown away with how fast it is.) so this is what you make your games in (we also have C++ plugins for people who are passionate about C++ or need to use an existing library). When you make a Mono class, all public variables show up in the inspector for easy modification. So basically, Scripts are 1st class citizens of Unity. We're also using Mono for extending Unity - It really is that good.

It's what we had!

Right now, our highest priority is making the upcoming 2.0 release of Unity the best it can be!

This is one of those questions where the dream world meets the real one: We would love to have the editor running on Windows, but actually making that happen is not something that is easily done by a long shot...

Someday - we would love to have a Windows version of the Unity Editor, and we are continually thinking "is now the time to start it?". In the ideal world, it would be coming real soon. In the real world, however, we only have a limited number of people - and the focus so far has been to make the Unity Engine be the best it can possibly be. It's getting better and better, but right now starting a Windows port would mean just focusing the development team on porting the editor - effectively halting all new features for a long time. We are just not ready to do that to the people who showed faith in us by purchasing Unity - and especially the people who showed the faith to ditch their Windows machine, buying a Mac to get Unity.

So yeah, one day. The sooner the better! But you won't find us announcing it's coming until we're well underway. In the meantime, get a Mac - they're really great machines and with the Mac/Unity combo, there's a nice and easy path to actually making complete games.

Basically, Ageia has the best cross-platform software-based physics engine out there. If they can get their accelerated cards going, all the better. But even if they don't, their software physics are world class.

I think the main reason the Unity-Wii combo is interesting is that they share a common trait: creativity. With the Wii, we've got this great new platform to develop on that radically changes the way people are meant to interact with games. This puts some interesting challenges on developers to rethink which games we make. As a games designer, I know that for each good idea you discard at least ten bad ones - so this means lots and lots of testing. Fortunately, the core feature of Unity is the quick develop-test-debug cycle. Therefore, Unity is positioned to be the tool for all these creative people to get their dreams out.

Unity is not trying to be like XNA - XNA is basically a slow version of DirectX targetted at hobbyists. Unity is a complete authoring environment with an integrated editor targeted at small and medium-sized professional game development teams. All the hard parts are done. Good people can make a game in a weekend - and we've seen this happen several times: we introduce Unity on a Friday afternoon, and Sunday night people have a game that looks good and plays nice.

The main thing is that when you're developing, you'll see the game exactly as it appears on the Wii - we're emulating the Wii graphics chip on the GPU in your development machine.... So if it looks great in Unity, it'll look great on the Wii.

What I've seen is that people develop their game inside Unity - the controllers get integrated into the authoring environment, so you keep the niceness of Unity; pausing the game, examining & changing variables, moving the camera around the paused scene to get a better perspective on what's going on. While developing, Unity will show the graphics just like they appear on the Wii. Once a feature or section of gameplay is done, you run it on your devkit (one button click) to make sure that it runs exactly the same way.

With WiiWare Nintendo is the first console maker who is actually opening up the business for small developers. With WiiWare, Nintendo is opening up a channel to actually sell games on a console to the small developer. We were extremely impressed that Nintendo specifically said that they will not do screening of ideas, but just bugtesting. I'm not seeing any other console makers actually embracing the indie development scene in that way!

Unity is the perfect tool to create those games - we've got fast development iteration solved, so you can tweak your game until its perfect.

More deployment platforms...

For our 2.x releases, The goal is to be adding more Shock and Awe features. With Unity 2.0, we finally have the complete package (networking? done. shadows? done. ease of use? done). I really think with 2.0, we're the best tool out there. For me, the goal is to make sure that we're the best tool in every single category. A lot of that is really leveraging the features we have - we have users who script, say, heat distortion from particles. I want to make that as easy as enabling it in a checkbox.

And then we also have some larger features planned, but we're not ready to go on the record about those :)