Monday, March 7, 2016

Unity Project Organization Part One: N+1 Different Answers

I believe there are two topics at the root of a discussion of Unity project structures.  These are:  file organization and game (code) organisation.

Note that this is all simply my opinion, mostly based on a slow evolution through several projects.  That, and many years of general software development practice.

You'll find as many opinions on this are there are people offering them (someone posted on the Unity forums that "If n people reply to this thread, you're going to get at least n+1 different answers. ;-)").  As an aside, here is a decent article that has some opinions on the subject:  50 Tips for Working with Unity (Best Practices).

Anyway, like I said, I want to break this down into two main topics.

Physical and Logical


Physical

The first is the matter of how the physical folders and files are organized in your project directory.  It's worth noting that, for the most part, this has little to do with how your project compiles and runs.  With the exceptions of a few special folders (Resources, Plugins, etc), folders are just folders.  Theoretically you could just lump every script, model and texture in one directory and not worry about it.  That would be a bad idea.

Logical

The second is the logical layout of the program. This is the structure of classes and namespaces that you use.  I'm not talking about the project file structure (auto-created by MonoDevelop or Visual Studio), but rather the logical structure of the game (where is player information stored?  High scores?  Level information?  Enemy definitions, etc.).

Both of these structures are important, and getting them muddled can cause a great deal of confusion when a project becomes complex.  Hopefully this will help anyone reading it to think about how they want to handle these issues.

Thus, on to Part Two:  Physical

1 comment: