blitz project naming and organizational guidelines

Project Naming Conventions & Organizational Guidelines

DATE: 8/27/2005 3:26 AMAUTHOR: Ivan TodorovVERSION: 2.1.0

Last Revised by: Ivan Todorov

Document Purpose:The purpose of this document is to outline BLITZ’s Network Organizational Guidelines. It provides an overview of network connectivity and best development practices. This document can be shared with everyone.

Your File Server: \\SERVERNAME

The File server can be accessed from computers connected to your domain either directly on-site or when logged into the network via VPN. Once can access the server by pointing explorer to \\SERVERNAME or by going to the START Menu > Run > Open: \\SERVERNAME.

Here is a brief description of each share and its purpose:

-Branding_&_Identity-Contains YOUR COMPANY’s logos, style guides, branding, identity and marketing materials.

-Company-Contains HR Related and other company files.

-Creative&Technical_Resources-Contains collections of Images and Links used as resources or references by the development teams.

-Installs-Contains installation files for various programs. Please contact the network administrator to obtain a license for your computer.

-IT-Contains files, drivers and documentation used by the Information Technology Department

-Portfolio-A collection of all projects completed over the years.

-Project_Data-Contains Project Data used by Project managers, including legal agreements, budgets and schedules and statements of work.

-Project_Files-Contains project files used by the creative and technology teams, such as Photoshop files, Flash files, documentation and client assets.

-Stock_Content-Contains assets such, as stock photography, which has been purchased and owned by the company.

-Texture_Maps-Contains image maps and textures mainly used by the 3D and design teams.

INITIAL HERE ↑ Page ©2005 BLITZ Agency2

PROJECT_FILES Directory Structure and Naming Conventions

A well organized folder structure with clear naming conventions is critical for internal and client communications. This reduces errors, distractions and duplication of efforts. It is the responsibility of all team members to ensure organization on-the-fly so things are organized and labeled properly at all times and should not be put off for later, or for someone else. This system is designed to resolve some of the following common issues and is largely based on common sense. It should be able to answer these questions:

I need to upload the latest build, but I don’t know what’s needed and what’s not. Where is the latest comp? I need to send this out ASAP to the client! Where can I find the latest spec document so I can update it? Where is the latest QA spreadsheet with all revisions so I can add new comments? Which one is newer? The PSD or the ZIP with the same filename?

And it should also significantly help with:

Making sure everyone is always working or updating the latest file Archiving and Restoring only necessary files and folders from your Backup Client Project Delivery CD containing only final files, thus eliminating confusion When updating your portfolios, it will be a snap adding a new projects

Client Level Directory Structure: ClientName\TYPE_ProjectNameThe Top level directory structure begins with the ClientName (no spaces, underscore(_) allowed). Inside add the TYPE_ProjectName folders (separate with “_”), clearly labeled. The type is always in CAPS, where the project name is Initial Caps (no spaces and no underscores). This naming convention makes it easy for everyone at a glance to go to the right folder without hesitation or a need to ask a project manager where to look.


TYPE Prefix DescriptionANIM_ Animation projects (webisodes, or other animation only projects)APP_ Application (may be internet enabled, but doesn’t live on the internet)BROADCAST_ Broadcast project (TV)CDROM_ CD Rom Project (director or Flash or any other technology)DEMO_ Demo or prototypesDVD_ DVD or DVD Rom projectECARD_ E-Card System (front end and backend files)GAME_ Game – (flash, 3d , any, including backend files)ID_ Identity (brand development)NEWSLETTER_ Newsletter project (html & creative)PITCH_ Pitch Materials (assets and documents used in a pitch)PPT_ Power point designRIA_ Rich Internet Application (Flash Applications)RM_ Rich Media Banner & advertising campaigns (Flash and static images)WWW_ Website or Microsite

In addition to the TYPE_ProjectName folder – we also add the overall client brand guides and logo files. This helps centralize all client branding guides into one location. In conclusion, a brand new client folder should have the following items:

Project Level: TYPE_ProjectName Folders Once inside the TYPE_ProjectName folder, the user should ONLY see clearly labeled folders. No files should be present on this level. The folders should clearly indicate what type of files & content is inside them. Folders prefixed with -– means no content is inside them yet. The user who first starts adding content to a folder prefixed with -- should remove the double dashes.

BEFORE: DURING PRODUCTION:

TYPE Prefix DescriptionAD_ Folder belongs to Art Department & Art DirectorDEV_ Folder belongs to Developers / ProgrammersPM_ Folder belongs to Project ManagerSND _ Folder belongs to Sound Director

AD_Fonts


Owned & maintained by Creative Lead / Art Director Contains fonts used in comps and source files Critical to be up-to-date since client deliveries often require all fonts. It also ensures

programmers have the necessary fonts to export the Flash files.

AD_Production Owned & maintained by Creative Lead / Art Director Contains folders and files created by the creative team for integration by the

developers Comps, Video, Storyboards and other creative elements go here Photoshop comps, Flash assets and transitions animations, reference imagery goes

here. Tests, R&D experiments, scrap files and such. This folder should be watched with extra care as often too many people change and update files to where it is easy to get unorganized.

DEV_Source Owned & maintained by the Technical Lead (Developer) Contains all source files including Flash FLAs, ActionScript Classes There should be no orphaned files in this folder, older versions should be placed in an _old

folder. Old build should be stored here in a /_build#### folder

DEV_Deploy Owned & maintained by the Technical Lead (Developer) Contains ONLY deployment necessary files, such as SWFs, MP3s, FLVs, XML, JavaScript

and HTML files that are needed to be placed on the final deployment environment (be it a web server, CD Rom).

There should be no orphaned files in this folder, older versions should be placed in an _old folder.

Deploy build archiving should happen in DEV_Source in the /_build#### folder.

DEV_Repository Owned & maintained by the Technical Lead (Developer) Contains SubVersion (Version Control Repository Data / Database) SVN URL should be:

svn://SERVERNAME/<ClientName>/TYPE_ProjectName/DEV_Repository/ This folder should only be modified by SubVersion only, do not ever directly manipulate

the files / contents of this folder, or it will likely corrupt your repository.

PM_ClientAssets Owned & maintained by Project Manager

Contains folders & documents of any assets delivered by the client. The person unzipping or un-archiving the client provided content should carefully create an intuitive directory structure that would be clear to all users.

PM_DOCs Owned & maintained by Project Manager Contains folders & documents for asset lists, project specs, creative briefs, business

requirements, use case scenarios, wireframes, QA revs and more.

SND_Audio Owned & maintained by Audio Engineer


Contains folders and files for project music and sound design. It should also contain uncompressed raw versions as well as the compressed versions.

Naming Conventions & LabelingThe file naming convention should be simple, logical, intuitive and straight to the point.

Projects often require file dependencies where spaces in filenames and case sensitivity can be an issue. Therefore the DEV_Deploy folder for all project have unique requirements:

All required for launch sub folders are all lower case, and spaces are defined with “_”


Only deployment files are to be organized in logical folders. ActionScript class files (.as) should not be posted, nor should be FLAs, PSDs or other source files.

Single word files names are lowercaseAll filename details are separated by “_”

singleword.filetype – DEV_Deploy main.swf home.swf gadgets.swf

section_pageNumber.filetype - DEV_Deployexample: gameplay_p1.swfexample: gameplay_p2.swfexample: gameplay_p3.swfexample: gameplay_p4.swf

section_content.filetype - DEV_Deployexample: gameplay_video1.swfexample: gameplay_joeBio.swfexample: gameplay_joeSpecs.swf*Note: for easier readability, Capitalization of second word is encouraged. This is

common approach in programming languages, such as ActionScript.

section_function.filetype - DEV_Deploy example: gameplay_wireframes.swf example: gameplay_music.swf example: gameplay_sfx.swf

DEV_Source Version Naming Convention

When working without a source control / version software, saving new versions of the same FLA, add a two digit version number (ex: _v05) to the end. Move the older file into the _Old folder. For example:

main_v01.FLA (should always be set to export to main.swf in DEV_Deploy) main_v02.FLA (should always be set to export to main.swf in DEV_Deploy) main_v03.FLA (should always be set to export to main.swf in DEV_Deploy) gameplay_p1_v19 (should always be set to export to gameplay_01.swf in

DEV_Deploy)

Date Sensitive Naming Convention

Some date sensitive documents, such as QA reports should have the date attached to the end, in addition to a revision number:

ClientName_ProjectName_yymmdd_v1.XLS (example: Atari_MI_030801_v1.xls)

When Sharing a Source file Naming Convention

Sometimes, files such as FLAs need to be bounced back and forth between designers and programmers. In these cases, we track build numbers attached to the initials of the people who worked on them. For example:

myGame_v001_MG.fla myGame_v002_IT.fla


myGame_v003_CG.fla myGame_v004_MG.fla (would indicate that this is a build where this is the programmer – Mark Gardner Build

001 and Ivan Todorov build 002. *Note that if this SWF is sitting in an HTML file, the export settings need to be set to

always export to the same SWF file name, such as myGame.swf.

Keeping the revision number before any owner’s initials ensures the progression is easy to follow and ensures proper sorting. Simply having the initials of the last person to work on the file shows obvious ownership and a simple glance over the _old directory will show who made changes and at what revision those changes were made by a given owner.

Every time someone takes ownership to do a revision the number would be increase and initials changes appropriately. Having 3 spaces for revisions ensures that there are more than enough numbers available for several people to make many revisions. Two spaces allows for only 99 revisions. This should be enough for many files but 3 spaces allows for up to 999 revisions and ensures consistency on those hopefully rare occasions that there are more than 99 revisions needed on a file being modified by potentially 3 or more individuals. Theoretically if there were 2 developers, 2 designers a 3D artist and audio artist there would only be roughly 16 revisions on average available to each with a two number space setup. Should be enough, but might not be. With a 3 number space setup there would be over 160 revisions available to each person on average. Hopefully this would never be necessary but in any case it keeps the file name lengths more consistent, shows ownership per revision, makes finding the latest revision easy and the first or last revision for a given owner simple and obvious.


PROJECT_DATA Directory Structure and Naming Conventions

The project data folder is reserved for usage by account managers, producers and business development. It contains contracts, legal agreements, budgets & schedules, proposals, quotes, RFP and other similar documents. The file naming conventions is identical to the project files, the exception is the directory organizational structure.


blitz project naming and organizational guidelines

Documents