Using Git for Unity 3D projects

I was recently asked by a collaborator why we’d switched to using Git for our Unity projects, and I thought the bullet points I passed to him might serve useful to someone else considering the switch, so here we go:

We previously used Asset Server (via VPN) but switched to Git due to a number of advantages, including:
  • Easy remote access from anywhere, highly performant on most networks. Important for our highly distributed team, and frequent access requests from non-team individuals.
  • Supports branching, allowing us to safely work on multiple features without breaking our main build. This has become particularly important to us since we’ll need to be able to support a main release with hotfixes while safely working on future version features.
  •  Excellent support for tagging and selective reverts. Has already saved us a number of times :)
  • Supports offline work beautifully, it’s still possible to commit when the network goes down, move onto other tasks, and handle merges later.
  • History is available offline as well.
  • Diff based versioning, as opposed to Asset Server’s timestamp based versioning.
  • Better merge and conflict handling.
  • No need for additional per seat client licensing.
  • 3rd party cloud hosted packages available (GitHub in our case) to take management off our hands.
It’s by no means perfect of course, and does take some adjustments to workflow, for example:
  • Know what belongs in Git and what doesn’t. Basically everything in /Assets and /ProjectSettings, nothing from /Library or other temp locations, and nothing that is frequently autogenerated like Mono projects. 
  • .meta files must always be committed with their assets, some simple rules:
  • Always open the project in Unity before a commit, to allow it to update metas.
  • If you add an asset or folder, it’s up to you to commit the meta
  • Move/delete objects in Unity, not the filesystem, so it updates metas accordingly (git detects these actions correctly, moves actually show up as moves in history)
  • If you delete an asset or folder, it’s up to you to commit the meta deletion
  • Always delete folders that no longer contain assets and commit the meta deletion
  • Notify the team before you push (we use our Skype group status for this) to avoid pushblocking someone that’s doing a large push with something small and trivial.
  • Ideally when starting on what could be a large/time consuming feature, create a local branch so if you need to switch back to master to fix something small you can.
    • Regardless of workflow, there are some difficulties/disadvantages that need to be taken into account when considering the switch:
    • Since each user clones the entire repository, much more disk space is required.
    • It’s essential for all users to understand the commit/pull/resolve conflicts/push process, or they can potentially cause serious damage.
    • Not built into Unity, so one more tool to learn.
    • Since game project assets are so large, occasional cleanup is needed to keep repo size down. 

    Git vs Asset Server for Unity 3D projects

    I was recently asked by a collaborator why we’d switched to using Git for our Unity projects, and I thought the bullet points I passed to him might serve useful to someone else considering the switch, so here we go:

    We previously used Asset Server (via VPN) but switched to Git due to a number of advantages, including:
    • Easy remote access from anywhere, highly performant on most networks. Important for our highly distributed team, and frequent access requests from non-team individuals.
    • Supports branching, allowing us to safely work on multiple features without breaking our main build. This has become particularly important to us since we’ll need to be able to support a main release with hotfixes while safely working on future version features.
    •  Excellent support for tagging and selective reverts. Has already saved us a number of times :)
    • Supports offline work beautifully, it’s still possible to commit when the network goes down, move onto other tasks, and handle merges later.
    • History is available offline as well.
    • Diff based versioning, as opposed to Asset Server’s timestamp based versioning.
    • Better merge and conflict handling.
    • No need for additional per seat client licensing.
    • 3rd party cloud hosted packages available (GitHub in our case) to take management off our hands.
    It’s by no means perfect of course, and does take some adjustments to workflow, for example:
    • Know what belongs in Git and what doesn’t. Basically everything in /Assets and /ProjectSettings, nothing from /Library or other temp locations, and nothing that is frequently autogenerated like Mono projects. 
    • .meta files must always be committed with their assets, some simple rules:
    • Always open the project in Unity before a commit, to allow it to update metas.
    • If you add an asset or folder, it’s up to you to commit the meta
    • Move/delete objects in Unity, not the filesystem, so it updates metas accordingly (git detects these actions correctly, moves actually show up as moves in history)
    • If you delete an asset or folder, it’s up to you to commit the meta deletion
    • Always delete folders that no longer contain assets and commit the meta deletion
  • Notify the team before you push (we use our Skype group status for this) to avoid pushblocking someone that’s doing a large push with something small and trivial.
  • Ideally when starting on what could be a large/time consuming feature, create a local branch so if you need to switch back to master to fix something small you can.
    • Regardless of workflow, there are some difficulties/disadvantages that need to be taken into account when considering the switch:
    • Since each user clones the entire repository, much more disk space is required.
    • It’s essential for all users to understand the commit/pull/resolve conflicts/push process, or they can potentially cause serious damage.
    • Not built into Unity, so one more tool to learn.
    • Since game project assets are so large, occasional cleanup is needed to keep repo size down. 

    iSkinned with Decalgirl

    P301 P303 P305
    See the full gallery on Posterous
    When I still had a PSP, the thing attracted dirt and fingerprints like mad and it felt like I spent more time cleaning it than playing on it. I tried a couple of skin solutions, but they all had some issue or other-too thick so the analog stick got blocked, began peeling off too easily, etc. Then I stumbled on decalgirl.com, read rave reviews about their skins and decided to import a kit. It turned out to be a great choice, and together with a screen guard changed the way I used my PSP.
    So when @justinpaver was going to be heading over from the states for a visit I jumped at the chance to have him bring some decalgirl skins over.
    In addition to skinning my and Nat’s phones, I got a skin kit for my MacBook too.
    Applying the skins is not a task to be rushed, I had to set aside about 30 minutes per device. The phone kits also come with a code for a matching desktop background, which is pretty cool (pity the same isn’t available for the MacBook). The result is pretty cool, and with no sticky residue being left behind on the devices after the covers are removed, it’s a great way to keep them in good nick.

    The Gift Of Life - Thanks Dad

    Ten years ago today, I was on the receiving end of a miracle. A miracle made possible by my Dad’s generosity, the awesome skills of medical professionals and the Lord’s good grace. After spending my life to that point dealing with sick kidneys, they finally failed me completely and I needed a new kidney - which my Dad selflessly offered to donate. I was 21 at the time, and without the new kidney I quite simply wouldn’t be here today-or at least would be living my life dependent on a dialysis regime (which is not fun). My kidney is now ten years old and going strong.

    Those of you that know me, and didn’t know about this are quite possibly amazed (most people are when they find out), because I live a normal and healthy life. I don’t seem ‘sick’ - and that’s because I’m not. The transplant gave me what I’d never had- a completely healthy kidney- and I’ve been careful to look after it since. The negative “effects” are limited to regular checkups with a specialist and taking daily immuno-suppressants, not a bad deal :)

    I’m one of the lucky ones. There are hundreds, if not thousands of people of all ages, from all walks of life, that desperately need transplants and can’t get one from a family member for whatever reason. They have their names on a list, and are hoping and praying to be the lucky recipient of a ‘cadaver’ organ. 
    YOU CAN GIVE THESE PEOPLE A NEW LIFE LIKE I GOT. All you need to do is:
    1. Register as an organ donor with your local donor organization. In SA that’s the Organ Donor Foundation (http://www.odf.org.za)
    2. Carry your donor card in your wallet or bag at all times
    3. Discuss your choice with your family. They will ultimately be the ones that have to give the go ahead to harvest your organs, so they need to know about and your wishes and know to respect them.
    Please, don’t believe the rubbish some people insist on spreading about donation: 
    • Doctors and paramedics will not give you inferior treatment to secure organs.
    • Your organs will not be sold for some crazy profit to the highest bidder. 
    • Your body will be treated with the utmost respect and will be perfectly fine for open casket display if that’s what you want.

    Is Unity 3D ready for console game dev?

    Over the last couple of months I’ve been getting my hands dirty with Unity 3D on a project for Luma Arcade, and for the most part it’s been a fantastic experience. Unity’s 5 or so years of building their tools and having a large user base to test it and provide feedback really shines through. Getting simple concepts going is laughably easy (as evidenced by 48 hour gameplay challenges like the recent Game.Dev one) thanks to the intuitive interface. The powerful art tools and C# scripting also allow those early efforts to be extended and polished into top notch products.
    Unity has a reputation in some circles of being a tool limited to mobile, web, or relatively simple PC and Mac games. Their recent push into the traditional console market, with versions of their engine for Xbox 360 and PS3 (there is already a Wii version) is set to change that. For the most part, I would say they are ready for the jump and many developers will welcome their powerful toolchain as another option when targeting these platforms. There are however, some issues I personally feel need serious attention before Unity becomes the ideal tool for medium- and large scale console development which I would like to point out here. Please note that these are my own views, and not necessarily those of Luma, it’s directors or employees.

    Outdated and unstable IDE support
    Unity has the developer-friendly ability to generate project files that allow devs to work with a Unity project file in Monodevelop (which is bundled with Unity) or Visual Studio. These projects can be fully debugged like a natively developed project as well. This is the theory anyway and I’ve seen the system in work on other developers’ systems. My personal experience however (and based on reports online I’m far from being alone alone in this) is that Monodevelop will crash within minutes of trying to debug a unity project. The generated projects are also in the outdated Visual Studio 2008 format, and are re-generated whenever a file is added within Unity so manually upgrading the projects to 2010 format is not a practical option. This leaves those of us with up to date software out in the dark. Considering the importance of being able to debug properly, this is a huge issue that needs addressing. Giving developers the option to output 2010 format projects should be a fairly trivial improvement, the stability issues on Monodevelop will of course be more of a challenge.
    C# as second class citizen
    Unity has script/code support for JavaScript, C# and Boo. The focus in documentation and samples is quite heavily skewed towards JavaScript, and there are some areas (such as lack of proper support for namespaces, quirks trying to import C# code and  outdated API support) that point to C# being a second class citizen as far as Unity scripting is concerned. Moving into the console development space, C# is the natural language choice for most teams due to it’s similarity with the still-dominant C++. There is no doubt that javascipt’s flexible nature holds some advantages over C#’s more traditional rigidity, but I’d wager familiarity will win out in this case and console teams will go with C#. For this reason I believe Unity would benefit from a greater focus on it’s C# support. It does appear this is already happening, as online documentation at least now (mostly) includes examples from both languages.

    Non nestable prefabs
    Unity’s excellent prefab system allows the creation of reusable template objects called prefabs that can easily be added to a scene and then have minor changes applied per instance, but still benefit from later tweaks to the prefab. The problem here is that these prefabs can’t be nested, so for example if a wheel prefab is created, then added to a car which is then prefabbed, the connection to the wheel template is lost and any future changes to the wheel prefab will not be passed on to the wheel instances in the car. This diminishes the value of prefabs somewhat, and ideally support should be added for this.
    Binary object formats
    Unity’s scene and object files (including their reusable prefabs) are binary, and as such not mergeable by typical version control systems. Considering the modular component model Unity uses, multiple developers or artists often need simultaneous change access to these files as they work on different functionality on the same object. This leads to blocking cases which would potentially get even more acute with larger teams. Ideally these should be an easily mergeable text format such as XML. There are of course potential performance advantages to using a binary format, but there’s no reason these can’t be generated when doing a build for the target platform, with the working format being XML.

    Asset server
    Sticking with the topic of version control, there is Unity’s integrated asset control system called Asset Server (for which an extra seat license is required). Now while the idea of asset control built into the development environment is appealing, the reality is that this system is not nearly as extensive as the likes of SVN. It also has some serious issues such as updating of certain project files (particularly .asset files defining project wide behavior) causing a project to become unusable. I for one would welcome the replacement of the proprietary asset server system with a more common standard like SVN, or possibly even something like Git or Mercurial that supports distributed teams-an increasingly common occurrence in our industry.
    Focus on non-paying customers
    Free license Indie developers have taken Unity a long way, and their admirable support for the indie market has arguably been a massive part on getting the platform to where it is today (and for that reason the following is likely to be flame bait). There comes a time however, when paying customers have to take precedence, and if Unity want to push into the console market that change of direction will have to come sooner rather than later. Unity’s brilliant feedback system in which users vote for for improvements and new features is a prime example of a place where this change is needed. Free users get the same weight in this system as paying customers, and as a result blue-sky features that matter less to professional developers (such as Linux support) end up drowning out improvements that would help professional development such as some of the changes mentioned above.

    Licensing model
    Another example of unity’s heritage in smaller developers is their license model. They typically charge a per-seat, per platform license. Recently they also announced a mass licensing deal with EA that gives all of that publisher’s in-house devs full access to Unity’s tools. Sadly not all professional developers have the clout EA does, and this leaves a big gap for medium to large studios that would rather buy a group license than deal with seat licenses. A bulk license system is needed, ideally with discounts in place as the group size increases.

    Fun with initialization order

    Here’s something I meant to post ages ago, when I was doing J2ME to Flash conversions, and got caught out by assumptions about the evaluation order of values passed to a method or to initialize an array. It’s one of those really subtle issues that had me scratching my head to figure out what had gone wrong in a piece of code.
    Consider the following (pseudo)code:
    Now what would you expect the output to be? I had unwittingly assumed the result would consistently be:
    arr: [1, 2, 3]
    val1: 1, val2: 2, val3: 3

    As it turns out, the answer varies from language to language (which is why I got snagged by code working ‘correctly’ in one language but ‘breaking’ in another):
    Java:
    Result:
    arr: [1, 2, 3]
    val1: 1, val2: 2, val3: 3
     
    Actionscript:
    Result:
    arr: [3, 2, 1]
    val1: 3, val2: 2, val3: 1
     
    Some others:
    C++ undefined:
    C# guaranteed to be right to left:

    DSTV Mobile on Nokia N96

    With all the marketing Multichoice is doing around DSTV Mobile, I thought I’d brush off the N96 and put it’s DVB-H receiver to the test again (previous attempts proved fuitless). This time around it all worked pretty smoothly on the first attempt-if a bit confusingly. Nokia’s “Live TV” allowed me to purchase a DSTV Mobile subscription (currently free). I did find though that on restarting the phone after removing and reinserting the SIM, the app had lost my subscription data-no big deal for free promos, but I can see some really irritated users when their paid subscription goes missing. Note that while the app doesn’t use 3G to receive the actual TV signal, it does need a cellular data connection to validate licensing (which means no using the service out in the bundus to catch the cricket or rugby).
    The app itself is actually pretty well put together, with different program guide views in portrait and landscape, the ability to set program alarms and auto-tuning events, and both fullscreen and windowed (with programming info) views. Parental controls are enabled by default, and set to an age limit of 15, so it’s possible first time viewers will have to hunt around for the default unlock code (12345 in case anyone gets here searching for it). Another interesting quirk is that the app locks the video down against both screenshots of content (note the attached shaky cam files taken from my iPhone) and TV out. I suppose I’m not entirely surprised, but this level of lockdown seems seriously ridiculous considering you’ll ultimately need a full DSTV subscription anyway when the service goes paid in a couple of months.
    The content available in the DSTV mobile package is fairly limited, with the focus heavily on sports, but what’s there comes through clearly. I have to say I was pleasantly surprised at both the video and audio quality and the glitch-free nature of the experience, this is no frustrating streamed video. Not being much of a TV watcher, and given the content, I can’t say I could see myself paying for the service but I can definitely see the value to avid sports fans and even the ‘distract the kids’ value of Cartoon Network.
    Notvout ProgramguidelandscapeProgramguideportraitPrograminfoloadingSecuritylocksscreenshotsSs2cricket Cnr2d2 Enews
    See the full gallery on Posterous

    ChannelO.mov Watch on Posterous

    Testing out the new posterous app

    P117P119
    See the full gallery on Posterous
    Posterous has for some time had an app on the iPhone called “PicPosterous”, focused on posting multiple images from the device direct to a posterous album (and of course optionally adding a blog post). Checking on the app store today, I saw the sneaky buggers had at some point released a new app called (imaginatively enough) “Posterous”.
    This is my first post from that app, so let’s see how it goes. I’m most interested in seeing if autoposting of multiple images works (in the past, in Facebook for example, a new album would be created by PicPosterous with just the first image, the rest would all make it to posterous but not facebook). To test this I’ve added two hopefully prescient screenshots from the incredibly awesome and devilishly addictive iPhone game, “game Dev Story”. If you haven’t checked it out yet, do so now (but first warn your loved ones they may not see you for a couple of days. Or weeks)!
    From an editing point of view, the new posterous app uses the standard iPhone editor (so no text styling), and allows enabling or disabling geotagging, autoposting and private settings for the post. Tags can be added (with a nifty chooser that shows past tags), and of course media can be attached. At this stage only photos and videos can be attached (new or from the library) but no audio recordings. There’s also unfortunately no multiple-select for images and videos, so each has to be added individually.
    In addition to posting to any of your posterous blogs, the app also allows you to view past posts. I’ve yet to check if they can be edited, and since there’s no way to save a draft, I’ll try it after posting this.
    Like posterous itself, the app is dead simple and intuitive, just what you need (well, most of it) and no more.

    Top