Managing a Cosmetic Catalog Across Multiple Game Seasons

The catalog grows faster than you plan for

Season 1 ships 80 items and everything is manageable. Season 2 adds 60 more and it still holds. By season 4 you have 300 variants across 80 assets: some locked to past battle passes, some eligible for rerelease, some retired, and a handful commissioned for Season 2 that never shipped. The artist who made them has left, and the Slack channel where the pricing was agreed is archived.

That is the normal condition of a live game shipping on a seasonal cadence. The catalog accumulates history, exceptions and ambiguity along with items, and without maintenance it turns from an operational tool into a place where questions go to die.

Below are the practices that keep a multi-season catalog usable.

Tagging for seasonal context

Tags carry the answer to which items belong to which season, and on what terms.

Season membership

Tag every variant with its origin season: Season with the value 3. Origin means the season it was made for, whichever season it eventually shipped in. An item commissioned for Season 3 and delayed into Season 4 keeps the Season 3 tag, because that is the context it came from.

PolyDrobe tags take optional values, so one filter returns the complete Season 3 roster: everything planned and produced in that window.

Availability classification

Availability rules differ item by item, and a tag can hold the rule:

• Availability: Permanent, always purchasable
• Availability: Battle Pass Exclusive, locked to that season's pass and never returning
• Availability: Limited, eligible to return after a cooldown
• Availability: Retired, gone and not planned to come back

That tag answers the question liveops asks most: can we bring this back? Without it, the answer means reading old design docs, searching Slack, or finding someone who was there.

Event association

Items built for a seasonal event carry a second tag: Event with "Halloween 2026" or "Anniversary Year 2". Combined with the season tag, one query returns every Halloween item across every season, which is what you want in front of you while planning this year's.

The item lifecycle across seasons

A variant's life continues past Released. In a multi-season game the arc runs longer:

Concept → In Progress → Review → Approved → Released → Active → Vaulted → (Rereleased | Retired)

The first five are production. The last three describe life after launch:

Active. Purchasable or earnable right now, whether from the permanent store, the current battle pass or a rotating offer.

Vaulted. Pulled from availability and eligible to return in a later rotation, event or rerelease. Nobody can obtain it today.

Retired. Gone for good, kept as a historical record. This fits promotional items tied to a real-world partnership, and battle pass exclusives the community was promised would never return.

PolyDrobe's status field is configurable per project, so you can define the statuses your game's lifecycle needs. What matters is that Vaulted and Retired are stated, queryable and distinct, instead of a blank field somebody has to interpret.

When to vault

Vault an item once six months have passed without a store appearance and nothing upcoming calls for it. The item stays in the catalog, and rotation queries stop returning it.

Vaulting on a schedule keeps the Active catalog to the items in play, which makes rotation planning quicker and search results cleaner.

When to retire

Retire an item when you can name the reason it will not return:

• The partnership or licence has expired
• The community was told the item was exclusive, and the battle pass promised it
• Its visual quality has fallen behind the game's current bar and no update is planned

Make retirement a decision rather than a default. Vault anything you are unsure about, because a Vaulted item promotes back to Active cleanly, and a Retired one that reappears tells players your exclusivity means little.

Tracking exclusivity commitments

Exclusivity is a promise, and breaking it costs trust. A battle pass item advertised as exclusive stays exclusive. A one-week offer should not turn up in the permanent store a month later without a public word about the change.

Those promises are usually made in marketing copy, community posts and design docs, none of which touch the asset catalog. Six months on, a new liveops manager finds a popular Legendary in the Vaulted state and asks whether it can come back, and answering means archaeology.

Put the commitment on the variant. A tag or the metadata JSON field will hold it:

• Exclusivity: "Battle Pass S2, permanent exclusive"
• Exclusivity: "Limited offer, can return after 90 days"
• Exclusivity: "None, permanent catalog item"

Or in metadata: {"exclusivity": "Battle Pass S2", "can_return": false, "reason": "Marketed as exclusive in Season 2 trailer"}

The commitment is then on screen at the moment somebody asks.

Catalog health metrics

A healthy multi-season catalog has numbers you can read. Check them quarterly at least.

Distribution by status

Active outnumbering Vaulted and Retired combined makes for an overwhelming store. Vaulted dominating leaves the Active catalog thin, and the rotations repeat themselves.

Rarity distribution per season

Compare the tiers season over season:

• Season 1: 40% Common, 25% Uncommon, 20% Rare, 10% Epic, 5% Legendary
• Season 2: 35% Common, 20% Uncommon, 25% Rare, 15% Epic, 5% Legendary
• Season 3: 20% Common, 15% Uncommon, 25% Rare, 30% Epic, 10% Legendary

That is rarity inflation, each season leaning further into the premium tiers. Follow the curve far enough and the tiers stop meaning anything, because a catalog where most things are Epic has no Epics.

Filter by season tag and rarity to get the counts. Export to Excel for the cross-season chart, or ask through the MCP server:

"Compare rarity distribution between Season 2 and Season 3 items. Is there rarity inflation?"

Category coverage per season

Every season should add items across categories. Fifteen new Headwear variants and no Accessories means accessory players got nothing for three months. Track the per-season spread and the blind spots show up.

Orphan and incomplete records

Hunt for variants missing data: no thumbnail, no price, no rarity, still sitting at Concept two seasons after somebody created them. They clutter search results and confuse whoever finds them.

Filter for Concept records older than 90 days, or search for variants without a thumbnail. Then act: move them to a backlog, push them into production, or delete the abandoned ones.

Institutional memory and team turnover

Knowledge loss does the quiet damage. The producer who knows why the Phantom Jacket costs 2500 instead of the standard 2000 for an Epic moves on. The artist who remembers the Chrome variant came from a collaboration with a contractual restriction joins another team.

A structured catalog holds what they knew:

Activity history. Every field change carries a user, a timestamp and the old and new values. The next producer wondering about that odd price reads who set it and when.

Metadata for context. The variant's metadata JSON takes what the standard fields cannot: pricing rationale, collaboration details, references to an external agreement, notes on design intent.

Tags for classification. Exclusivity, Event, Season and Availability encode decisions somebody made for a reason. The tag records the decision, and the metadata or history explains it.

Consistent naming. Name every Season 3 item "S3 / Item Name / Variant" and the origin travels with the item. A new teammate reads it off the list without opening anything.

None of that adds process. It uses fields the variant already has. Typing "pricing_rationale": "Collab with StudioX, premium pricing per contract" costs you ten seconds now, against the hours it costs to reconstruct six months from now.

When the catalog outgrows a single project

Some games pass the point where one project holds the catalog comfortably. Past 1,000 variants, split by content type:

• Project: Character Skins for outfits and full-body cosmetics
• Project: Accessories for gloves, belts, backpacks and trinkets
• Project: Weapons for weapon skins and charms

Each project carries its own taxonomy, roles and settings, and the same people can join all of them. The catalogs stay focused and searchable, and cross-project planning runs through export or MCP queries.

Key takeaways

• Tag every variant with its origin season, availability class and event, and you answer the two recurring questions: what can we bring back, and when was this made.
• Define explicit post-launch statuses (Active, Vaulted, Retired) so no item sits in a state nobody can read.
• Record exclusivity commitments on the variant, where the next person will find them.
• Read the health metrics quarterly: status distribution, rarity inflation across seasons, category coverage and orphan records.
• Lean on activity history, metadata and naming conventions to carry knowledge across team turnover.
• Split into multiple projects once the catalog passes 1,000 variants and the workflows diverge by content type.