Purpose: The purpose of this document is to define formal best practices for art assets across studio projects.
All of these policies share a common goal which is to reduce the cost of projects and increase productivity of artists. It is worth mentioning that the cost of ignoring these policies can be hidden to artists in their day to day work and can include:
Tech time for fixing the project builds because an artist did not test their work
Tech time to address issues because the project environment is is cluttered and unorganized
Other artists time if the assets they inherited do not have the most recent source art or DCC files are not properly set-up
Other artists time trying to sort out inherited confusion due to a unorganized folder structures
Other artists time trying to sort out inherited confusion due to the existence of deprecated files
Check-in policy
Why have a Check in policy:
Being able to go back through changelist histories allows for easier debugging of issues related to game assets.
Checking in all source art assures ability to go back to older version if design or art direction requires it
Assets get lost if not checked in. Hard drives can fail. Individuals can swap to a new machine and inadvertently lose work from their prior machine. People move off a project and forget to check work in…
All of the files that are needed to make a game asset are owned either by the studio or someone we are contracted to work with and need to be in source control.
What is the check in policy:
● All assets that are needed to create a game asset need to be included in the same changlist as the game asset. An Example of this would be an Unreal asset that is created by importing an FBX into Unreal and the FBX file was exported from Maya. The Maya file, The FBX file and the Unreal game asset need to all be in the same change list.
● Changelists need to clearly be labeled describing what they contain.
Testing policy
Why have a testing policy:
Breaking a build not only costs time for the individuals who have to debug it but also can have a negative downstream impact on everyone working on the project including other vendors or contractors. If the build breaks at an inopportune time it can cause a project to miss deadlines
What is the testing policy:
Do not check in without making sure your changes have been tested.
Use a testing buddy. If you think your changes may break the build but need to check them in, get a testing buddy. A testing buddy is an individual who will help test your asset on their pc. You can accomplish this by shelving your work and the testing buddy unshelve and test. This can also be done if you have to leave and do not have time to test.
Do both Visual and Build testing
Visual testing - Run the build and visually confirm that all changes work as expected
Build testing - Run a build either locally or in Jenkins to make sure changes do not break the build
Cleanliness policy
Why have a cleanliness policy:
The long term health of a project is partially based on maintaining an organized and up-to-date development environment. This is especially true on larger projects.
If deprecated files are not removed from a project they can cause bloat and confusion.
What is the cleanliness policy: