Along the way, I’ve noticed a few things that I thought would be worth writing about – and a few potential caveats and ‘gotchas’ that might be of interest if you are working with Unity yourselves, specifically about the Art Pipeline and how it works with 3ds Max and other external tools.

First off – I have multiple workstations setup – my primary desktop at the office, and a few mobile / portable options.  The primary machine that I carry with me is an Acer W500 – a 10″ windows tablet doohickey that has been absolutely great as a portable device.  Having a small tablet with a real keyboard and a real operating system is very slick.  Say what you will about Android and iTablet things, but when it comes to doing some REAL WORK – those devices are expensive toys.  You can PLAY games on them, but MAKE games?  Not likely.

Short version of my setup is that I have Unity setup on the desktop and the tablet and use Subversion to sync projects.  The one downside to the Tablet is the (lack) of harddrive space – the whole system drive is all of 32 Gb – so I haven’t installed the Adobe Creative Suite or 3ds Max on it because there literally is no space for them.  After the windows setup, the primary drive has all of 15 Gb total for all my apps / content etc – so even installing Photoshop on the sucker would eat up the majority of that drive.  So, for the time being, I’ve kept most of the creative apps off the tablet.

Which leads me to the first major issue that I have run into with Unity.

Unity’s Native 3ds Max Support IS NOT What it Claims to be

So the marketing folks decided to write up a claim that Unity can load native 3ds Max files, which at first it seems like it is doing perfectly fine – except that it isn’t.

What Unity does when you import a 3ds Max file is a behind-the-scenes FBX export from Max at load.  So every time you refresh your asset tree in Unity, it does a dynamic call to Max in order to get it to export all of your Max files into FBX and THEN loads the FBX files into Unity.

Now this is all fine & great – and for alot of people, probably works like a dream.  In fact, it’s a pretty slick solution for what has always been an annoying Art Pipeline nightmare.  UNLESS – you don’t have Max installed on your machine.  If you don’t have Max installed, Unity barfs completely and you suddenly have no content in your game.

Let’s go through the process in a bit more detail:

Workstation 1  (artists workstation)

Software Installed:
- Autodesk 3ds Max
- Unity 3D

Workstation 2 (Programmers Workstation)

Software Installed:
- Unity 3D

Artist creates a new 3d model in Max, saves the native .max file in the Assets/Resources directory of the Unity project.  Unity loads it up seamlessly on the artists workstation, artist proceeds to spend hours of time building a fancy scene, populating it, lighting it, etc.

At the end of the day, the Artist does an SVN COMMIT of the awesome new Scene so that the programmers can work on the gameplay the next day.

Programmer comes in, updates the SVN repository on their machine and sees all this amazing new work that the artist has done coming down the pipeline.  Having heard through the grapevine that this level is a masterpiece, the programmer then proceeds to fire up Unity so they can check out the progress on the game.  The scene loads, except there’s nothing visible.  After poking around a bit, the programmer finally happens to see this tiny message in the status bar:

That’s the ONLY indication of what might have gone wrong with the scene load.

Now, Unity will still load the scene, and (theoretically) not lose any work – except for the fact that all the programmer sees is basically a bunch of empty Game Objects with no meshes associated with them.  Not exactly a productive way to get some gameplay implemented.

So if you have a team of say 3 artists and 3 programmers – it doesn’t matter – you need to install 3ds Max on EVERY SINGLE MACHINE irregardless because Unity fails unless you have Max installed.

What do you mean?  Just get your artists to export to FBX?

Now there is an easy fix for this of course – simply export your content to FBX in the first place.

Ok fine, sure this works. But it also kind of DEFEATS THE PURPOSE of having Native loading of Max files does it not?

Which is all fine and dandy as well – except that Unity will CONTINUE to import and load the Max files anyways, whether you want it to or not.  There is no way to get Unity to ‘ignore’ any files in the Assets/Resources folder – that’s the whole point of it – so you’re kind of in a chicken & the egg position.  You want to setup your content so that it’s easily Streamable – so you put it in the Assets/Resources folder – but you only want Unity to load the actual stuff that you are using.

It would be nice if Unity somehow stored the cached’ mesh files that it generates somewhere useful so that you could check them into version control etc.  This would not only speed up the first load of a project infinitely, but would also fix team based development with the system.

With GameCore, we simply saved the cache files for each object in the same location as the source objects – both textures & objects – so you knew immediately what files went with which and, worst case, if you needed to clean / delete OR SAVE them – you could.  When you publish your final game, the engine simply packages up the cache files where available and ignores the source files for that content.  I’m not suggesting that this is an ideal solution, but it’s definitely A potential solution.

Now Unity has billions of random incomprehensible cache files stored in that libraries folder – including I’m assuming the cache’d versions of the FBX files – but you can’t simply check that folder into Subversion because Unity will utterly fail.

There doesn’t seem to be any work around for this that I can see.  You either have Max installed on every single machine you are working on your game with, or you don’t use the native Max loading.  It’s one or the other.

Unity does not give you any indication of the source file format for a particular object

Enter major annoyance #2.  Being a good artist, you have all of your Max files in the project, organized nicely.  You export each piece of content to FBX so that your programmers can actually see the content on their end.

What does this end up looking like?

To the right is an example folder for one of my vehicle sets.  There are 3 wrecked cars, in .Max and .FBX format.  Which is which?

Do you know?  I don’t know (unless I manually look outside of Unity) – does Unity tell us?  No – whether it’s a Max file or an ACTUAL fbx file, both have 2 components added – an Animation component and an FBX Importer component.

In fact this is what led to me finally figuring out why my content wasn’t loading on the programmer machine – the fact that both Max files and FBX files have an FBX Importer component applied.

So, even if you are exporting to FBX and want to ONLY use FBX files so that your team members can load the scene on their machines – you have to be VERY careful to only load the appropriate content into the scene, because Unity sure as hell isn’t going to tell you.

Additionally, whether you are using the native Max files or not – they will always be present in the project folder because Unity forces you to load all of the content in the resources folder, whether you want it to or not.

I know, I know, I get WHY they want to load all of the resources folder content – but seriously, it wouldn’t exactly take much to have a flag to NOT include certain objects – they have all of these .Meta files for everything – why not a simple bit flag for specific pieces of content to IGNORE them, even if they are present in the Resources folder?

The revised Art Pipeline / Asset Workflow

The only solution to the above issues is quite simply to NOT include your Max files in the Unity Project hierarchy at all.  This goes against literally EVERYTHING that I believe to be important when it comes to asset organization for a project.

Now for asset organization purposes over the years, I’ve spent a LOT of time trying to train (berate / beat) artists into making sure that they are working on their game content IN PLACE – in the project – and NOT on some random location – like their desktop folder or wherever.

Having an identical folder structure from one development workstation to another goes a HUGE way towards streamlining the development process.  If you forgot to commit a piece of art into the game, you KNOW where it is located – in the project folder – and don’t have to hunt randomly around your computer for it.   I can’t count the number of times that I’ve had to go onto an artists machine and do content hunting because something wasn’t checked into a project.

Interns in particular love doing this  - I swear that if there was one thing that so-called ‘Art schools’ should teach – it’s content organization.

Work around / Potential Solution

As a work-around and potential solution for the above situation is as follows – what I’ve started doing is a slightly revised folder structure for the game that goes like so:

• Unity Project Folder
• Assets
• Editor
• Resources
• Objects
• Mesh
• Textures
• Materials
• GUI
• FX
• etc
• Scenes
• Scripts
• Shaders
• Library
• Temp
• Content

The new top-level ‘Content’ folder is basically a mirror of the Resources folder that stores the native Max files for the scenes / content that I am producing for the game.  All content gets exported from Max to FBX (I have a few max scripts that streamline this process) into the appropriate folder in Objects.

The Content folder literally JUST includes the .Max files for the content – which in most cases for me are parent-level inventory objects that store all related content of a specific type – so all of the building Awnings are in an Awnings.max file, etc.

I’m a bit of a content organization freak so I’ve also come up with what I feel is a good way to organize the individual content folders for a scene.

For example, I’m working on content for an Arab Town setting for the game.  Normally I’d simply store all of the models & textures in the same folder and just go from there – saves having to remap textures to materials and all that fun, but also makes for some messy directories, so what I have setup for the main Arab Town folder is like so:

This way, whenever I’m adding content to a scene, I know that the proper object that I want to include is the one in the top-level ‘prefab’ folder – in this case ‘Assets/Resources/Maps/Arab-Town’ and can be 100% sure that the content not only works, but is setup and exported properly so that when I commit the content, it will work across the development network on the programmer’s workstations etc.

I’ve only started doing this in the past few days, so I’m not 100% sure whether it’s going to work completely for all content – I will say that the manual organization does take a little longer than just dumping everything into random folders, but I am fairly confident that the amount of time that it will save in the long run will be well worth it.

Now that I have my art pipeline cleaned up and figured out – I’ve started to dive into procedural generation of the game worlds for my project using a similar technique to what we used for Boomtown Takedown, my last game.  I’ll write up something about how that works and how you can use something similar for next time.

Until next time…

Ideas?  Comments?  Do you have any Art Pipeline tips for working with Unity that you want to share?

Now to begin, I’ll throw a quick caveat by saying that I’ve been using Unity fulltime for about 3 months now, and have been diving fairly heavily into the PC / Web based aspects of development.  I don’t have an iPhone, so I can’t comment specifically on the platform specific nature of the book’s content.

Having said that, one of Unity’s strong points is the simple fact that the vast majority of the development that you will be doing carries across from one platform to another and is (by it’s very nature) designed to be seamless from the porting standpoint.

For example, my personal development target currently is Facebook / Social Web deployment – and since I am targeting the largest possible audience with my games, much of the books material regarding content organization / optimzation and so on has been very useful.

The E-Book is available from PacktPub, which apparently is an e-book publisher – I’ve never heard of them or used them in the past, but the process of grabbing the book was fairly straightforward.  You are offered the choice of either .mobi or a .pdf versions to download.

Update:  There is also a print version – which has the same layout & design as the PDF I would assume.

Before we dive into much more detail, I can’t stop myself from going on a bit of a rant (as I’m wont to do).  Now I’ve only recently begun checking out .mobi e-books, having just migrated from my old laptop to an Acer W500 tablet PC / thingy, but when you compare the layout & formatting of a PDF e-book versus the .mobi version, it’s embarassingly bad.  I’m assuming that there’s some kind of batch converter thing that companies use to convert from pdf’s to .mobi files, but (and this isn’t just a problem with this book, but EVERY .mobi book I’ve checked out so far) the formatting / page layout and so on is absolutely horrible in the .mobi version.

If you have a choice, I’d say go with the .pdf version any day of the week – I mean the .mobi is fine for a standard novel or something (even though it still massacres the page layout / formatting and other overall structure), but for a chart-heavy and layout-heavy book like a software manual, the .mobi file is often unreadable, by no fault of the author.

Unity iOS Essentials is a great read for anyone building games with Unity – whether you are targeting the iOS platform or not.  Aside from a few small platform-specific sections in the book, the vast majority of the content is very well laid out and contains enough useful tips and information that it would be useful regardless of your target platform.

The book is structured well – starting with a general overview called ‘Planning Ahead for a Unity3D iOS Game’ that provides an excellent breakdown of the various features that Unity provides and the differences (if any) that you will encounter when working with the iOS version.   The author also provides a good breakdown of potential differences that you may run into across the various iOS devices themselves (iPod Touch, iPad, older iPhones versus the new retina display phones and so on).

Topics covered include configuring Unity to emulate the particular platform you are targeting, processor speeds & screen sizes of the various devices etc.

It’s well laid out and do a good job of not only introducing Unity’s featureset and how it applies to iOS development, but also breaking down the iOS platform itself and giving some under the hood technical details that are available elsewhere on the `net, but often annoying to track down and find readily.

The author also includes a few useful scripts and tips (adding an FPS counter to your game) and other useful tidbits that are applicable whether you are building iOS games or not.  Also covered is the process of setting up the iOS development platform, grabbing the appropriate SDK’s and whatnot.  I skimmed these parts simply because I don’t have any need for them at the moment, but knowing that the info is available is handy for when I end up firing up my Mac in the future.

Other tips that are useful for anyone building Unity games is information on building your levels properly to support streaming, how to ensure that your content can be both streamed in at load and easily unloaded afterwards.

The second chapter is called the iOS Performance Guide.  This section of the book is almost 50%  ’intro to game design’ type of material – providing brainstorming material for how to plan & implement your game, with a limited target platform like mobile devices in mind.  The other 50% is low-level technical details and strategies for implementating features.

For myself, the jump between high-level theory and low-level technical details is fairly welcome – the high-level concepts are sort of things that I’d assume that the reader would already know for their own game, but can be used as a ‘best practices’ guide for designing your iOS game as well, including a healthy low-level  Do’s and Don’ts section covering co-routines, cache’ing and some of the data structures like Hashtables that Unity / C# provide.

Chapter 3 covers topics like iOS / mobile specific input handling / testing your iOS game in the editor etc – I sort of skimmed this section because it’s not very applicable to me, but it seemed fairly comprehensive.

Chapter 4 is where we move from theory to implementation, starting to setup a project in Unity, testing it out and starting to get things happening.   Even if it is a very simple project, it’s nice to see an ‘end to end’ walkthrough from setup to deployment.

Chapter 5 deals with UI details – seemingly a never ending issue with Unity projects.  I’m still to this day astounded by the lame Unity GUI – but that’s a discussion for another day ;}

The author does a good job of trying to emphasis MVC style development – separating the code from the content essentially – and this is particularly important when implementing UI elements in your game.

Chapter 6 introduces a few .NET classes that you are probably aware of already – XML loading and so on – and even if you are, it’s nice to see some real-world implementation details for managing player preferences and platform-specific details about where save games & whatnot should be stored for the iOS devices.

Chapter 7 is focused on building the framework of a racing game – and covers vehicle setup, building your game environment (tracks) and other details like how to handle things like foliage for mobile devices (ie building foliage without using transparency).  Also covered is how to setup Culling and using layers to breakdown your scenes so they can be properly culled – crucial details for limited platforms where every little bit of performance is essential.

Chapter 8 covers lighting & particles, starting with wrangling the included ‘Beast’ lightmapping system, including tips on UV’ing your objects so they lightmap properly (something I have found to be very annoying in Unity versus other engines) and how to configure your lights for lightmapping.  Optimizing particle systems is often tricky – and building nice looking particle systems without bringing a system to it’s knees is a fine art even on desktop platforms, so it’s nice to see attention paid to the topic.

The author also covers a breakdown of the various shaders that are available and briefly covers the importance of selecting optimal shaders for your content.  This is obviously a very technical and large topic in itself, but I found the breakdown good and should be useful for artists & designers looking to squeeze extra FPS from their games.  The low-level nature of the shader scripts and the math involved may make a few brains explode, but the author does a good overall job of covering the Unity shader system and tweaks that you can do to optimize shaders for your game.

A topic of particular interest that I’m sure will get healthy use is the section ‘Water that works’ – that covers implementing nice looking water for the mobile platforms.

Chapter 9 ‘Putting it all Together’ has some nice extras that I wasn’t expecting that are very much up my alley, including saving high-scores to an online database – and provides a nice introduction to how you can use php & mysql to build leaderboards and the tie-in scripts for the Unity game to access & post scores.  This is the chapter that I am getting the most use out of personally – since everything that I’m working on is built around a custom web back-end, the sample scripts are great reference.

Overall I am extremely pleased with the book.  The PDF version has a nice hotlinked table of contents and index at the end, and the layout & structure is both attractive and easy to read.  The .mobi version has some serious limitations, but I’m not sure if this is simply due to the bare-bones format itself or not – but the information and content is still obviously there, and when it comes down to it – that’s the important part.

I’d definitely recommend this book to anyone looking to get into Unity as a development platform and obviously for anyone looking to build iOS games with Unity even more so. The only thing that would be nice to include would be downloadable sample scripts / content – but that’s fairly minor in the long term.

Go grab a copy for yourself from PacktPub.com!

Unity has been a breathe of fresh air frankly.  The community is impressive in just about every way imaginable.  There are some very talented developers building on the tech, and the way that Unity manages extensions and plugins really means that just about anything is possible as far as being able to take the basic tool and run with it.   I am truly and pleasantly surprised with what the community has been able to accomplish with the system, and also feel that it’s an ideal time to be jumping into the engine and getting started with it.

Having spent the past couple of months learning the fundamentals of the toolset and get some basic game mechanics implemented, I’m finally at the point where I’m going to begin fleshing out one of the game designs that I had been working on previously.  I’ll leave ‘which one’ open at the moment, until I have something to show for it, but I’m pretty pleased with what I’ve been able to accomplish in such a short period of time.  Looking forward to getting feedback if you so care.

More soon!