Search Unity

Last week was Unity’s sixth ‘Ninja Camp’. A chance for the developers in the company to get together from our various worldwide offices, and take a break from their usual work on Unity to work on a mix of random ideas, long lost feature requests, and cool new opportunities. Those in attendance have the full use of our main HQ in Copenhagen, and had the entire week to experiment, relax and create. This time around, we create a mini-site for you to browse the various projects being undertaken. Check it out here –

http://www.unity3d.com/ninjacamp

This site allowed developers to comment on progress made, and post images and video of their progress – we’ll also be posting on the blog to elaborate upon individual projects, so that you get more of an idea of where some of the ideas may go. To get a better taste of the what and why of Ninja Camp, we also made this video to give you a flavour of what it’s like at one of our camps and general life at Unity!

27 Comments

Subscribe to comments

Comments are closed.

  1. http://unity3d.com/ninjacamp/projects/10160 .

    The interactive indirect illumination from the ninjacamp videos seems very promising.
    Can we see some more demos about that too ?
    Does the interactive indirect illumination take a lot of GPU/CPU power and Memory and Draw Calls ?

  2. It would be nice if unity could let us see some more demos of the upcoming “behaviour trees” feature.

  3. Oh, they wouldn’t get sued – MSBuild is an open standard (otherwise Mono wouldn’t have XBuild). I just meant that it’d be silly for them to waste time rolling their own solution if they’re just going to end up with something identical to an existing tool.

    The situation you’re describing for bigger teams won’t happen though. Teams – especially when they’re large – have to standardise on the languages they use, because it’s not practical for everyone to use a different language. Maintenance becomes impossible. And really, any coder worth hiring will have no problem learning the project’s language anyway; any programmer who can’t translate standard code concepts into a new language is not someone I want to let anywhere near my codebase.

    It’s more valuable to the solo guys, because they can focus on learning the concepts and behaviour in Unity’s API, and so become familiar with Unity more quickly, instead of being distracted by language. That’s good for the studios, because it means more people familiar with Unity available for hire. It’s also good for those studios who are willing to standardise on other languages; I for one am quite interested in attempting to write some F# code for Unity at some point.

  4. Well if we keep our fingers crossed, this might just ship with Unity 4 :-) The implementation details are simple enough (I hope). I don’t think they’re too keen on being sued by MS so, they’ll probably have to end up reinventing it. this would be great news for bigger teams as each member can code in the language they are most comfortable with thus speeding up development time. Studios would hire based on ability & not knowledge of one programming language or another.

    @Jason good luck with the tall list, especially Dynamic Fluid Surfaces/Interactive Fluid Surfaces

  5. @koblavi: It’s a bit more involved than that, because scripts aren’t compiled in isolation – they have to be combined into assemblies, and then you have to figure out how to handle dependencies between assemblies; i.e. if I write some components in Lua and want to reference them from C#, I have to compile the Lua scripts to an assembly that is then referenced by the C# script, so I have to make sure they get built first, but maybe I have some other Lua scripts that I need to be able to reference the C# scripts from, so they need to be in an assembly that is built *after* the C# scripts… and so on. That’s why I think they’ll have to strengthen the ‘build phase’ system in particular before custom languages will really be usable.

    It hopefully won’t take much though – being able to define build phases, specify the compiler (or other tool) to be run for each phase, and then specify per-script (or per-folder-hierarchy) which build phase the script is included in, ought to do the job. Ship with the 4 standard build phases already defined, and automatically make any folder called ‘Editor’ or ‘Plugins’ select the appropriate standard build phase. I guess they should probably be careful that they don’t just end up reinventing MSBuild/XBuild, but it’s not like switching to that properly would be a bad thing either :-)

  6. – Destructible Geometry.
    – Interactive Fluid Surfaces.
    – Material Instancing.
    – Visual Script Editor.
    – Matinee style cinematic editor.
    – Normal Mapping for terrain.
    – Multi-texturing Shader.
    – Unity’s own optimized node style material editor.
    – Realtime Reflections (so without a render texture).
    – Voxel Clouds.
    – Underwater god rays and caustics.
    – Realtime Global illumination.
    – More realistic glass shader.

  7. I like what you guys are doing with a week of Camp is great, we used to do the same in the middle 90’s at a company called Time2Talk whenever we started a new large project, Great to see others use this as well, hopefully I will see some of you at unite 12

  8. Is there a way we can get a hold of the Draw Call Stepper project so we can use it in our own projects, and if not will it be part of unity any time soon? btw nice project Tomas! (and any others who may have worked on it!)

  9. Lars Steenhoff

    June 11, 2012 at 5:30 pm

    Wacom support for the texture painting tool is a must!

  10. What you guys are talking about is not hard to add at all because it should just compile codes after changes and create assembly files and attach them to the main engine. Even it’s somehow possible to do it now.
    Create an editor script which monitors for a special file extension and changes in those files and after each change compiles an assembly using the specific language compiler.
    Surely it can be more easier by for example having the option of adding file extension and compiler path and assembly name to unity or even easier but even now it’s possible.

  11. @koblavi That’s an impressive list of CLI-supported languages.

    The issue for UT might be that they can’t provide support for each of the languages. Therefore a plugin compilation logic seems to be THE way to go.

    To extend the idea, I would like to have a fully customizable workflow from asset import to game export, with a dedicated API.

  12. @Richard Fine: My point exactly. Whether third parties do this or unity does it, it would call for a change and the editor’s script compilation logic in order to make this happen:

    *Examine the file extension (and/or contents if necessary)
    * Look up an adequate compiler and Bam!
    *Interestingly it is already doing this for the default 3 languages so implementing it shouldn’t be too much hassle

    I’m guessing the editor uses reflection to expose public members so there is no dependence on the actual source file . I know the idea sounds pretty ‘romantic’. I myself am very comfortable with C#. but think of all the other developers who are saying no to Unity because they have to learn yet another language. I for one have rejected some engines for that reason. More and more languages are being ported to .Net/Mono now a days (http://en.wikipedia.org/wiki/List_of_CLI_languages). Even PHP is supported thanks to DLR (http://phalanger.codeplex.com/). Unity would be the first engine to boast that level of language independence.

    If Unity is really serious about it’s vision of democratizing game development, then “Language” shouldn’t be a barrier!

  13. I’d rather see Unity add whatever’s needed to allow third parties to add support for other languages, than for them to do it themselves. Being able to plug custom compilation logic into the editor could be very powerful.

  14. @Koblavi I myself am using C# and the rest of the team here is happy with C# too but i agree that having VB, Lua and python added is really awesome. VB because many .NET developers which want to switch are using VB in their daily job and Lua and python because many game engines out there are using them and some middlewares like roarengine and EKIOne are using them too. One might want to do the whole thing in LUA if is using EKIOne for AI and codes Lua there.

  15. @Richard Fine: I know this is possible currently. But I was hoping for the feature to be integrated into the editor itself. Unity can simply include some Mono(CIL) compilers (F#, Ruby, IronPython) as part of the default install package or have them as optional downloadable packages. Integration should be seamless such that I can just double click on my script and be able to edit on the fly, just like I can with C# & UnityScript. It would be nice if you could just do this without having to compile a class library outside of unity.

  16. @koblavi: FWIW, you *can* code for Unity in any language for which there is a CIL compiler – F#, IronPython, whatever – you just have to compile to a class library outside of Unity. That’s actually the same situation as for artists – they *can’t* work in “what ever package they choose” unless they manually export to a common format (FBX), but a handful of packages have more direct integration.

    Also I second Jason’s request for a better troll filter on the blog…

  17. @Rodrigo… I will offer a lifetime supply of Red Bull to what ever team works on this. Think about it… if artists can work in what ever package they choose and even import in native formats, why can’t programmers do the same? Think about how many more developers will switch to unity just because it “Speaks” their language

  18. @koblavi, about “team working on language independence for Unity”, it was actually one of the ninja camp candidate projects but I don’t think it has been working on. It is something we definitely want to have.

  19. 2D physics would be awesome!

  20. It’s a really amazing concept and culture from a developer point of view. For a week anyone is allowed to experiment with anything he/she wants to make new cool stuff. T
    The 2D framework is awesome. Want to know more about the various other stuff which don’t have video and have less info too. Please update us more.

  21. Impressive stuff…I like the inbuilt editor the most. Mono develop Carries too much unneeded baggage. A light weight inbuilt editor with Code Highlighting & Completion and Debugging.

    I wish there was a team working on language independence for Unity. There is no reason why unity should be limited to just 3 languages. Scripts compile to CIL anyway so the language they’re written in really don’t matter. Anybody should be able to pick Unity up and program in the language they are most comfortable with.

  22. I mean a part of Unity 3D yet.

  23. @Chris

    Yes some of them are there on the list,but remember that they are not of Unity 3D yet.

  24. Go 2D go!

  25. Jason, did you read the list of items on the ninjacamp page before making your list? Some of them are indeed on there.

  26. It is also important to note that Unity must also start testing these things for the next release of Unity 3D:

    – Better Troll filter on the blog
    – Destructible Geometry.
    – Interactive Fluid Surfaces.
    – Material Instancing.
    – Visual Script Editor.
    – Matinee style cinematic editor.
    – Normal Mapping for terrain.
    – Multi-texturing Shader.
    – Unity’s own optimized node style material editor.
    – Realtime Reflections (so without a render texture).
    – Voxel Clouds.
    – Underwater god rays and caustics.
    – Realtime Global illumination.
    – More realistic glass shader.

  27. Martijn Dekker

    June 6, 2012 at 10:49 pm

    Ninjacamp is a great concept!! Keep doing it!