Asset Storage

Last updated: 26/09/2025

This document outlines the standardized file organization system for all art assets in our game development pipeline. Following these conventions ensures consistency, easy asset location, and efficient collaboration across the team.

Directory Structure

Root Organization

The project root is “Roekoe Games” containing the main “Art” folder with the following structure:

• Archive: Deprecated or unused assets (never delete—archive instead)
• Biomes: World-specific environments and assets
• Concept: Conceptual artwork and design references
• Global: Assets used across multiple biomes or game-wide

Biome Organization

Each biome folder contains:

• Background: Environmental backdrop elements
• Characters: Biome-specific character assets
• Foreground: Elements that appear in front of characters
• Environment: Interactive platforms and terrain
• Props: Decorative and functional objects
• Rooms: Room-specific organizational folders (e.g., R01, R02, R03)

Asset Placement Guidelines

Environment Folder: Interactive elements like platforms, ledges, and terrain that characters can interact with

Props Folder: Non-interactive decorative elements like barrels, signs, vegetation clusters, and ambient objects

Multi-Location Assets:

• If used throughout a single biome: Create a Props folder at the biome level
• If used globally: Create a Props folder at the Global level

This organization enables efficient asset bundling and memory optimization.

Source vs Export Folders

Every art folder contains two subfolders:

Source Folder

• Contains working files: .PSD, .PSB, .AI
• Editable, layered files for future modifications
• Create these folders if missing

Export Folder

• Contains flattened .PNG files for Unity import
• Final, optimized assets ready for implementation
• Create these folders if missing

Important: Source and export files must have identical names (excluding file extension).

Example:

• Source: WIP_B-FOREST-R03_BG_TreesCluster_v002_JMB.psd
• Export: WIP_B-FOREST-R03_BG_TreesCluster_v002_JMB.png

File Naming Convention

Format Structure

{STAGE}_{SCOPE}-{BIOME}-{ROOM}_{TYPE}_{ShortName}_v{NNN}_{Initials}.{ext}

Field Definitions

Field	Values	Description
STAGE	PH, WIP, FINAL	Asset development stage
SCOPE	G, B, R	Usage scope (Global, Biome, Room)
BIOME	FOREST, CAVES, etc.	Target biome name
ROOM	R01, R02, R03	Specific room (optional)
TYPE	BG, FG, PROP, CHAR, UI, ATLAS, ANIM	Asset category
ShortName	Descriptive name	Brief asset description (use hyphens for spaces)
vNNN	v001, v002, etc.	Version number (3 digits)
Initials	Artist’s initials	Creator identification
ext	.png, .psd, etc.	File extension

Naming Rules

• Use underscores (_) between main fields
• Use Pascal Case within field values instead of spaces
  • Pascal Case is when you don’t use spaces but use a capital letter. So instead of “tree cluster” it becomes “TreeCluster”
• Version numbers must be 3 digits with leading zeros

Examples

Work in Progress:

WIP_R_FOREST_R03_BG_TreesCluster_v002_JMB.png

Final Version:

FINAL_R_FOREST_R03_BG_TreesCluster_v002_JMB.png

Example Explained

WIPR_FOREST_R03_BG_TreesCluster_v002_JMB.png

This means it is a Work in Progress file, whose scope is a Room meaning it is only used in that specific room in the Forest biome, specifically in room R03, the file has as a name TreesCluster and is the second version of that file. The file was made by Juan-Miguel Bauwens and has a .png extension. Normally you don’t have to add the extension manually.

Finalization Process

When marking an asset as FINAL:

1. Change WIP to FINAL
2. Reset version number to v001
3. Apply to both source and export files
4. Subsequent revisions increment from v001 (keeping FINAL prefix)

Asset Management Rules

Never Delete Assets

• Move unused assets to the Archive folder
• Maintain complete project history
• Preserve all development iterations

Version Control

• Never overwrite existing files
• Always increment version numbers for changes
• Update both source and export files simultaneously

Exception for Quick Fixes

Minor corrections may overwrite files only when:

• Error discovered within reasonable timeframe
• Low probability of Unity import/usage
• Change is clearly an error correction, not an iteration

Best Practices

1. Consistency: Follow naming conventions exactly
2. Organization: Place assets in correct folders based on function
3. Documentation: Use descriptive short names
4. Version Control: Always increment versions for changes
5. Backup: Never delete, always archive instead