Alle artikelen
Tutorials · 7 min read

Een bibliotheek van 100.000 assets temmen voor ze jou temt

Naamgevingsconventies die zichzelf sorteren, mappen versus tags, thumbnail-pipelines, het duplicatenbeleid en opportunistische migratie: een praktisch systeem om een enorme game-assetbibliotheek vindbaar te houden, en waarom zoeksnelheid bepaalt hoe gevarieerd je levels eruitzien.

Illustration of an asset thumbnail grid with a search field and tag chips

Kort gezegd: omgevingskwaliteit wordt begrensd door wat artiesten in onder een minuut kunnen vinden. Voorbij een paar duizend assets schaalt mapdiscipline niet meer: zoeken plus tags neemt het over, thumbnails bepalen de scansnelheid, duplicaten hebben een beleid nodig in plaats van een opschoning, en migratie moet opportunistisch zijn in plaats van heldhaftig. Hier is een systeem dat groei overleeft, met de concrete conventies die het kopiëren waard zijn en de redenen waarom elke op schaal telt.

Leeszaal van een bibliotheek, rekken in warm licht Een bibliotheek is geen stapel boeken: het zijn boeken plus een vindsysteem. Je assetcollectie is alleen een bibliotheek als het tweede deel bestaat; anders is het een zeer dure stapel.

De echte kosten van een rommelige bibliotheek

Wanneer het vinden van de juiste rots vier minuten duurt, stoppen artiesten na één met zoeken: scènes convergeren op dezelfde twintig onthouden assets terwijl duizenden gekochte packs ongeopend liggen.*

De schade is zichtbaar op het scherm: herhaling die spelers voelen, geld besteed aan packs die nooit uitkomen, en een stille belasting op elk set-dressinguur. Er is een scherpere manier om de regel te stellen: een asset dat niet binnen ongeveer een minuut gevonden kan worden bestaat feitelijk niet. Je betaalde ervoor, je slaat het op, je back-upt het, en het zal nooit in een level verschijnen. Vindbaarheid is geen huishouden; het is de bovengrens van je visuele variatie. Twee studio's met identieke assetbudgetten brengen zichtbaar anders ogende games uit als de een zijn assets kan vinden en de ander niet.

Naamgeving: saai, sorteerbaar, ondubbelzinnig

Een conventie werkt alleen als ze nuttig sorteert in een platte lijst: typeprefix, categorie, materiaal of soort, grootte, index. Geen spaties, geen "final_v2_NEW".*

Een beproefde vorm:

SM_Rock_Granite_Large_01        (static mesh)
SM_Rock_Granite_Large_01_LOD1
T_Rock_Granite_D / _N / _R      (textures: diffuse, normal, roughness)
M_Rock_Granite                  (material)
MI_Rock_Granite_Mossy           (material instance)

Regels die het op schaal doen werken: één woord per concept (Rock, niet Rock/Stone/Boulder door elkaar gebruikt), zet het meest-gefilterde veld vroeg zodat sortering nuttig groepeert, vul indices aan met nullen (01, niet 1) zodat 10 niet voor 2 sorteert, en schrijf de conventie op één pagina die iedereen op dag één leest. Het exacte schema telt veel minder dan dat er precies één is, en om vandaag te beginnen, op welke grootte je ook bent, want namen achteraf op 50.000 bestanden aanbrengen is het project dat niemand ooit afmaakt en dat iedereen betreurt te hebben uitgesteld.

Mappen zeggen één ding; tags zeggen de rest

Een bestand leeft in ÉÉN map maar heeft veel eigenschappen: mappen zouden eigendom en pipeline moeten coderen (welk pack, welk project), tags coderen alles waarop je zou zoeken: bioom, materiaal, sfeer, grootte, stijl.*

Multidimensionaliteit bestrijden met diepere mapbomen produceert het klassieke Props/Nature/Trees/Dead/Moss/- kerkhof waar nooit meer iets gevonden wordt, want een bemoste dode berk hoort in vijf mappen tegelijk en kan maar in één leven, dus zit hij altijd in de verkeerde vier. De werkende splitsing maakt zoeken de primaire toegang en de mapboom louter leidingwerk.

Een tagvocabulaire dat het meeste omgevingswerk dekt is kleiner dan teams verwachten: bioom (bos, woestijn, urbaan…), materiaal (hout, graniet, verroest…), conditie (smetteloos, versleten, geruïneerd), grootteklasse en stijl: vijf assen, misschien veertig termen, eenmaal afgesproken en afgedwongen. De discipline is het vocabulaire gesloten houden: elk nieuw synoniem dat iemand verzint ("verweerd" naast "versleten") halveert de waarde van beide tags, want een zoekopdracht naar de een mist de ander.

Thumbnails bepalen de zoekkwaliteit

Een lijst bestandsnamen is geen bibliotheek: consistente thumbnails (zelfde hoek, neutrale belichting) laten het oog honderden kandidaten per minuut scannen, wat de werkelijke snelheid is die set-dressing nodig heeft.*

Menselijk zien beoordeelt een thumbnailraster veel sneller dan het namen ontleedt; de consistentie is wat het doet werken, want verschillen in het asset blijven zichtbaar wanneer de presentatie identiek is. Een rots geschoten vanuit een willekeurige hoek in willekeurige belichting verbergt zijn eigen vorm; dezelfde rots in een standaard driekwartaanzicht onder neutraal licht onthult hem meteen. Render ze in batch: een thumbnail-pipeline betaalt zich terug in de eerste week van elk groot project.

Thumbnails zijn ook precies waar schaal pijn doet: honderdduizend ervan doorbladeren vereist virtualisatie, caching en een pipeline die op de achtergrond rendert in plaats van de editor te laten stokken terwijl hij bijbeent. Dat engineeringprobleem is letterlijk waarom we een content browser in Numivo bouwden die soepel blijft bij een miljoen assets, met instant thumbnails en optionele AI-tagging die "dat bemoste kliffstuk ergens" verandert in een zoekopdracht van twee woorden. Het browserprobleem en het naamgevingsprobleem zijn hetzelfde probleem op verschillende lagen: beide gaan over het samenvouwen van de afstand tussen "ik heb een ding nodig" en "ik kijk naar het ding".

Bakstenen muur van duizenden bijna identieke eenheden Het duplicatenprobleem, fysiek gemaakt: duizenden bijna identieke eenheden. De vaardigheid is één vindbare canonieke versie behouden en de rest stilletjes degraderen, niet iets verwijderen waar een muur nog op leunt.

Duplicaten: één houden, de rest taggen

Verwijder bijna-duplicaten niet op zicht (referenties breken): kies een canonieke versie, tag de andere duplicate, filter ze uit de standaardzoekopdracht, en trek ze pas echt terug als niets ze meer referenceert.*

Elk langlopend project verzamelt overlappende packs: vier granietkeien van vier leveranciers, drie vaten die alleen verschillen in een handvat. Het tweestappenbeleid (nu degraderen, later verwijderen) vangt de vindbaarheidswinst direct op tegen nul breukrisico: de duplicaten verdwijnen uit het zoeken maar blijven op schijf voor elke scène die ze al referenceert. Voer de referentiescan per kwartaal uit; zes maanden zonder referenties ruimt het kerkhof meestal in één keer veilig op.

De te vermijden faalmodus is duplicaten verwijderen op de dag dat je ze vindt: iets referenceert altijd degene die je verwijderde, een level breekt, en het team leert de opschoning te vrezen, waarna niemand nog iets opschoont. Degraderen-dan-verwijderen houdt opschonen veilig, en veilig opschonen is de enige opschoning die blijft gebeuren.

Migratie: van chaos naar systeem

Pauzeer nooit de productie voor een big-bangopschoning: pas de conventie vanaf vandaag toe op alles NIEUWS, migreer dan oude content opportunistisch: wat een level binnenhaalt wordt onderweg hernoemd en getagd.*

De opportunistische regel heeft een prachtige eigenschap: de assets die ertoe doen migreren eerst, per definitie, want zij zijn degene die gebruikt worden. Alles wat na een jaar onaangeraakt is hoort in koude opslag, niet in zoekresultaten, en hoefde nooit te migreren. Teams die in plaats daarvan de heldhaftige weekendopschoning proberen, produceren doorgaans een half-hernoemde bibliotheek: strikt slechter dan beide extremen, want nu mengen de zoekresultaten twee conventies en is geen te vertrouwen.

Veldcijfers die het waard zijn te stelen

  • Vindbaarheidsbudget: onder 1 minuut, anders bestaat het asset functioneel niet
  • Tagvocabulaire dat omgevingswerk dekt: ~5 assen, ~40 gesloten termen
  • Thumbnail-scansnelheid met consistente rendering: honderden per minuut
  • Duplicatenbeleid: direct degraderen, na ~6 maanden ongerefereerd verwijderen
  • Naamgeving: met nullen aangevulde indices, één woord per concept, één pagina regels

Mini-FAQ

Zijn AI-tags goed genoeg om handmatig taggen te vervangen? Goed genoeg om het meeste ervan te vervangen: geautomatiseerde tags dragen het gros (onderwerp, materiaal, kleur) terwijl mensen de oordelen toevoegen (stijlpassing, projectspecifieke termen). De combinatie verslaat elk alleen, daarom werkt AI-tagging het best als opt-in-hulplaag in plaats van volledige vervanging.

Eén gedeelde bibliotheek of per project? Gedeelde bronbibliotheek, imports per project. De bibliotheek houdt alles met volledige tags; een project haalt alleen binnen wat het uitbrengt, houdt builds slank en cook-tijden kort. De twee mengen (een project dat de hele bibliotheek referenceert) is hoe buildgroottes opzwellen.

En het versiebeheer van binaire assets? De bibliotheek is een tuin, geen archief: versiebeheer de bronbestanden in je DCC-pipeline, houd de bibliotheek als alleen-huidig-beste. Historische versies die in zoekresultaten leven zijn ruis met een naamplaatje, en ze vertragen elke zoekopdracht voor iedereen.

Hoe krijg ik een team de conventie echt te laten volgen? Maak het juiste het makkelijke: een opslag-/importsjabloon dat het naampatroon voorinvult, een lint-stap die bestanden buiten conventie markeert, en thumbnails die conventieconforme assets vindbaar en niet-conforme onzichtbaar maken. Conventie afgedwongen door gereedschap blijft; conventie afgedwongen door zeuren niet.

Begin lelijk, begin nu: een naamgevingsblad van één pagina, tien kern-tags en consistente thumbnails verslaan een mooie taxonomie die volgend kwartaal begint. Bibliotheken zijn tuinen: constant klein wieden, nooit één heldhaftige opschoning.