Today, I’d like to talk about what I do to try to keep a project as large as Dehoarder 2 organized. With this being my largest project to date, I’ve had to think and re-think about this subject several times. I’ve read a lot of wisdom on the nets, and have organically arrived at a system that seems to be working well, so I wanted to share.
Organize Asset Files Around Small Features
If you organize your asset files around small features, you’ll find that things will be much easier to work on because related things are closer together. The definition of “small feature” may vary depending on your project. For example, in Dehoarder 2 I have a pizza box object. When created, this pizza box may take on one of several brands. I consider the pizza box object template to be a feature, so it gets its own folder that contains all assets related to the pizza box (3D model, textures, materials, etc.).
When organizing this way, you may find some assets that are shared between multiple features. It is OK to move these shared assets to a common folder, Essentially making the shared assets themselves a feature. In Dehoarder 2, there are common materials that are used among many furnishings, things like wood materials, metal materials, and color patterns. These all become part of a “Shared Material” folder/feature. Be sure to keep this shared folder itself as small as possible and organized into sub-features. In Dehoarder 2, for instance, all wood materials and the texture files to support them are contained in one folder, and all metal materials are in another folder.
The other popular way to organize Unity projects seems to be to have folders for each asset type, and subfolders under those relating to features. The problem I found with this approach is that it becomes unwieldy to move features around, as the folder for every asset type needs to be touched.
If assets are organized by feature, moving the feature is as trivial as dragging one folder. This is great for when you decide to re-organize asset bundles and such.
One notable exception I use with this paradigm is with Script files. Script files, unless imported from a Unity Package, always go into the Scripts folder. The reason for this is largely due to the way Unity works: Unity does not allow scripts to be included in an asset bundle, so it does not make sense (to me) to keep them in a folder belonging to an asset bundle. Thus I keep Scripts in the Scripts folder, to keep it clear that the Scripts will always be built with the game itself and not with an asset bundle.
Adopt Consistent Naming Conventions At All Levels
This is one that I constantly have to put effort into. It is very easy just to name things without really thinking of the bigger picture. But when you have thousands of named objects in your project, you really need a systematic way of naming things. This includes names of things like submeshes in your 3D model files, because those get imported into your Unity project.
In my case, I may have several variants of a model, for instance, 5 different sizes of book, or 3 different styles of sofa. I adopted a simple convention where I tag each model variant with an A-Z letter. So my 5 book models become Book_A, Book_B, Book_C, Book_D, and Book_E. Similarly, my sofa models become Sofa_A, Sofa_B, and Sofa_C. If there are submeshes, I append a descriptor that tells me what the submesh is. For example, Sofa_A_Collider would be my simplified collider mesh that goes with Sofa_A.
Going further, when building my prefabs, each type of prefab may have several different variants that vary by material. For example, I may have three different variants of book all based on the Book_A model. For those, I am appending a number to distinguish a variant, so those three different book variants have the names Book_A_01, Book_A_02, and Book_A_03.
In the early days of developing the game, I would have (and did) name these books by the title of the book that was shown on the texture. That was a mistake. Whenever I wanted to do something to all books, I had to hunt through lists for all of the book titles, and hope I didn’t miss one. It was utter nonsense that was taking extra time, so the move to systematic naming was a very positive step for productivity. The name actually displayed to the player is indeed the proper book title, but it comes from the language resource file.
Many times, your naming convention will be influenced by the project you are working on. What worked for me with Dehoarder 2 probably won’t work with other projects that have different needs. The main takeaway here is to put some thought into your project’s naming conventions, and come up with something that will work well to keep you organized.
Use Asset Bundles to Separate Content from Engine
I’ve talked about this before, but I can’t stress it enough. For a project of any significant size, you are going to want to adopt Asset Bundles early, and keep a strong separation between the (minimal) assets that belong in the game engine, and the assets that represent your content. Most of your game engine assets will be things like scripts, libraries, and basic UI assets. Mostly everything else should be put into Asset Bundles. It is a lot easier to build in and enforce this separation in the beginning of the project than it is later in the project. I wish that Asset Bundles had been available to me from the start of development on Dehoarder 2. It would have saved me a lot of rework.
Organizing Your Workload
So far, I’ve talked about organizing your project files within your Unity project, but you also need to be organized in how you work if you are going to tackle a large project.
Make sure you always have a list of what you need to work on to bring the project to conclusion. To start out, the list may not be detailed. Keep this list arranged in priority order, and always work near the top of the prioritized list. It’s OK if you feel the very tippy-top thing on your priority list is not something you can work on today, especially if it’s creative work and you’re feeling technical that day, or vice-versa. Unless something is truly urgent, doing a slightly lower priority task and being productive at it is preferable to forcing yourself to work on the very top priority task and being non-productive or worse.
When you come across a task in your list that is too big to accomplish in one session, break it down into smaller tasks, and replace the task in your list with the smaller tasks. Prioritize those. Repeat as necessary. Do not start a bunch of tasks and leave them in the middle. If you start a task, work it to completion, or divide it into smaller tasks.
Go through your list and re-prioritize it often, as no battle plan survives contact with the enemy.
The best tool I’ve found to manage this for my individual projects are multicolor packs of 3×5 index cards. It may be very quaint, but it is very effective for me. I write each task out on a card, with any relevant notes. I color-code my cards by type of work. New tech work (coding and such) is pink, defects/fixes are yellow, asset work (graphics, music, etc.) is green, game design (levels, story, etc.) is blue, and marketing and business tasks are purple. The entire stack of cards represents my list. Re-prioritizing this list is easy and natural and strongly encouraged by the nature of the cards. When I complete a task, I write the completion date on the card, put a big green checkmark on it with a sharpie, and put it in my “done” pile.
Of course, index cards won’t cut it for team projects, especially if there are remote team members that may never get within arm’s length of the index cards. I would suggest a more digital means of organization for those cases.
Dehoarder 2 Monthly Progress Update
This month has been mostly about integrating the last batch of models from Arvex, and creating more parody products, especially in the media sector. Currently, I’m working on allowing access to the roof area of the house.
With the last batch of models from Arvex in place, 3D modeling work is complete. I still have about 20 more products to create in order to flesh out the variety of objects in the game. Once those are done, my main focus will be in deciding final layouts for the rooms and implementing story scripts. As usual, I’d hoped to be further along by now, especially with GDEX happening in a month. Also as usual, things tend to take longer than one expects.