Sunday, April 7, 2013

The joys of sub-projecting in Unity


Let's say you have a personal Unity framework full of useful models, prefabs, shaders, scripts, etc. that you'd like to use across several projects. How do you best deploy that framework?

If you use version control, then maybe in each Unity project folder you'd also have a special folder hooked up to an SVN or a Git submodule. (Though I find Git submodules to be scary and unwieldy and more trouble than they're worth.) If you don't use version control, maybe you'll keep a separate Unity project just for your framework and from that you'll export a new Unity package every now and then, then separately import and update the Unity packages across your different projects as needed.

There's a third way that I'm trying, inspired slightly by how the Source Engine's filesystem works: basically, you keep all your projects *inside* a main Unity project, so they exist more as "mods" or "sub-projects", and they interface with each other as well as a main framework folder that has core prefabs and scripts.

... then, when you want to build out, just check/uncheck which scenes you're building out, and let Unity figure out which assets to include. This is what I'm doing for my first person framework and it seems to be working fairly well.

For example: I have a first person controller prefab that automatically plays footstep sounds and particles and stuff. For one mod, I've set increased the speed and head-bob strength to simulate a galloping movement. In another mod, I disable jumping and crouching because it's more like a Dear Esther thing. For both mods, I have a "sound library" prefab, full of various arrays of sounds -- and to play a sound, I just call Sound.Play("footstep_grass"); from any script -- and boom, footsteps. This kind of workflow, I think, has helped me get started on prototyping first person stuff faster because that way I don't have to re-invent or re-import the wheel all the time.

The pros: to start a new project, I just make a new "mod" folder, and drop-in some prefabs from the main "radiator" folder, and I'm more or less ready to get started. It's much faster preparation and setup, as well as a shared art / sound / etc. base of assets and code that's ready immediately. No packages to maintain or folders to copy and paste or silly Asset Store business.

(My stance on Unity Asset Store stuff: buyer beware. The free art and plugins can be great values, but the paid stuff is rarely worth it unless it's fairly popular and thus well-maintained... If I want art, I'd want to make it personally for my own game. If I want code, I'd just find an open source C# library and import that instead.)

The cons: you're essentially bypassing all the strengths of keeping separate Unity project folders. Also, all files in \Resources\ will get  included in all builds, no matter which scenes you choose to export. Also, it takes some mental overhead to structure your project so that your main framework folder doesn't depend on anything in the various mod folders, and to keep your mod folders relatively isolated. If you're working in a team, this'll probably just result in a mess.

Recommended use: if you're making a bunch of slightly similar small-ish games, alone or with a partner, then sub-project. If you're making a large 2-year game with 15 people around the world, then you probably should NOT sub-project.