paint-brush
A Project Structure for Your Open Source Unity Packagesby@lordcodes
605 reads
605 reads

A Project Structure for Your Open Source Unity Packages

by Andrew LordNovember 20th, 2016
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

When you start writing the code for your package, you will find that there isn’t really any form of enforced project structure. A clear project structure that keeps things nice and organised is usually the best way to go, especially important if other people need to read through your code.

Company Mentioned

Mention Thumbnail
featured image - A Project Structure for Your Open Source Unity Packages
Andrew Lord HackerNoon profile picture

When you start writing the code for your package, you will find that there isn’t really any form of enforced project structure. A clear project structure that keeps things nice and organised is usually the best way to go, especially important if other people need to read through your code.

The project structure I use is:

  • build: any builds and log files
  • reports: any test result files
  • release: to store your package for download
  • scripts: for use by yourself or CI to build, run tests etc.
  • src: the source code of the package itself

From Unity, select to create a new project, where you will enter its name and choose the src folder from above as the project location. Doing this will create a folder within the source directory that contains the Unity project. Alongside these files you will want to put a Unity project .gitignore, such as the one I propose below.

Prepare Your Unity Project For Git

At the root you can add a very simple .gitignore so that the builds and tests results aren’t committed to Git.

build/
reports/

Moving onto the Unity project itself, you will have an Assets folder to contain all of your project’s assets, such as source files, images and materials. To ease the process of exporting the package later I like to have one folder within here for the package sources and another with a .UnitTests suffix for all the unit tests. Any scenes (for testing the build) or other files are kept within Assets but out of the package sources folder, so that you can export everything in there to make your package.

For example, for MySuperLibrary I would have:

  • Assets/MySuperLibrary/: Package sources
  • Assets/MySuperLibrary.UnitTests/: Unit test sources
  • build.scene: scene file to test the build

That’s about it, be sure to let me know if you can think of any improvements to the structure. Enjoy!