Convenciones de nombres para recursos UI de minijuegos: transparentes, botones, iconos y sprites

¿Tu carpeta de proyecto tiene archivos como btn_ok.png, button_confirm.png y 按钮_确定.png? Tres estilos de nomenclatura, tres formas de interpretarlos y el inicio de tres desastres de colaboración.

Yo caí en esa trampa. Al terminar mi primer proyecto de minijuego, la carpeta de arte tenía más de 200 assets: la mitad con abreviaturas en inglés, la otra mitad con traducciones literales al chino, y algunos simplemente llamados 新建文件夹 (2).png. Encontrar un archivo era como buscar una aguja en un pajar; cada cambio de UI costaba medio día solo para confirmar qué asset correspondía a qué estado.

Este artículo resuelve una pregunta: cómo usar una fórmula de nombres para que tus recursos UI sean claros de un vistazo. Prefijo, categoría, función y estado: cuatro elementos, y basta.

Capítulo 1: El coste real del caos en los nombres — por qué importa tanto la convención

Empiezo con una historia real.

El año pasado, con dos amigos hicimos un minijuego casual: yo código, Lao Wang arte y Xiao Li diseño. Al segundo mes, Lao Wang envió un lote de botones: 12 archivos, todos llamados 按钮1.png a 按钮12.png. Le pregunté cuál era confirmar y cuál cancelar. Me dijo: «Mira las imágenes y ya sabrás.»

Me quedé mirando 12 imágenes en pantalla: rectángulos redondeados del mismo tamaño, con colores apenas distintos. Tardé 15 minutos en ordenar la correspondencia. Tras el lanzamiento, Lao Wang cambió la paleta de botones y mandó 12 imágenes nuevas: 新按钮1.png a 新按钮12.png. No borró las viejas; acabé con 24 «botones» mezclados.

El equipo de WeChat Games de Tencent midió que una nomenclatura coherente ahorra un 80% del tiempo de búsqueda de archivos. No es poco. Si buscas assets 10 veces al día, 3 minutos cada vez, son 30 minutos diarios. Con convenciones claras, baja a 6 minutos. En un mes ahorras 12 horas, suficientes para prototipar una función nueva.

El problema crece con scripts de automatización. Escribí una herramienta para reemplazar botones en lote: buscar todos los PNG que empiecen por btn_ y sustituirlos. El script no encontró nada: Lao Wang no usaba btn_, solo chino. El script quedó inútil; reemplacé todo a mano en dos horas.

En el código, el problema es aún más visible. Compara estas dos líneas:

// Nomenclatura coherente
this.confirmButton.spriteFrame = assets.get('btn_ok_pressed');

// Sin convención
this.confirmButton.spriteFrame = assets.get('button2');

La primera deja claro que es el estado presionado del botón de confirmación. La segunda: ¿qué es button2? Abres la carpeta de arte, localizas button2.png, lo abres y recién entonces lo sabes. Cada cambio de UI repite ese ritual y la legibilidad del código se desmorona.

Capítulo 2: Fórmula general de nombres — una regla para todos los escenarios

No te dejes intimidar por la palabra «convención». La fórmula central es simple:

prefijo_función_estado.png

O, de forma más completa:

módulo_categoría_funció[email protected]

Cuatro elementos, de izquierda a derecha, cada capa más específica. Ejemplo: [email protected]. Desglosado: módulo de correo, categoría icono, función búsqueda, estado presionado, imagen @2x. Cada parte tiene significado claro.

Tabla rápida de prefijos habituales

Recopilé 15 abreviaturas muy usadas, combinando el tutorial básico de Cocos Creator de Tencent Cloud y recomendaciones de normas UI:

Abreviatura	Nombre completo	Uso
bg	background	Fondos de pantalla, fondos de diálogos
nav	navbar	Elementos de barra de navegación
tab	tabbar	Iconos de barra de pestañas
btn	button	Botones de todo tipo
icon	icon	Iconos funcionales, iconos de estado
img	image	Imágenes genéricas
txt	text	Imágenes de texto (p. ej. títulos)
pop	popup	Elementos de ventanas emergentes
bar	bar	Barras de progreso, barras de estado
mask	mask	Capas de máscara
sep	separator	Líneas separadoras
del	delete	Botones o iconos de eliminar
add	add	Botones o iconos de añadir
msg	message	Mensajes, globos de aviso
logo	logo	Imágenes de logo

Comparten un rasgo: cortas, fáciles de recordar, significado obvio. Usa btn, no button; bg, no background. Cuanto más largo, más errores al escribir y más caracteres ocupa.

Recursos propios del módulo vs. genéricos

Antes de nombrar, pregúntate: ¿este asset solo se usa en un módulo o en todo el proyecto?

Recursos genéricos: sin prefijo de módulo; empiezan por categoría. El fondo de la pantalla principal es bg_home.png, no home_bg.png. Los fondos pueden reutilizarse; agrupar por categoría facilita encontrarlos.

Recursos propios del módulo: con prefijo de módulo para procesamiento en lote. El icono de búsqueda del módulo de correo: mail_icon_search.png. Al cambiar toda la UI de correo, buscas el prefijo mail_ y reemplazas todos los assets relacionados.

Nombres cuando hay varias tallas

A veces el mismo botón existe en dos tamaños. Mi enfoque: añadir la talla después de la función:

btn_ok_big_n.png      # Botón confirmar grande (estado normal)
btn_ok_small_n.png    # Botón confirmar pequeño (estado normal)

O con medidas concretas:

btn_ok_128_n.png      # Botón confirmar de 128 px de ancho
btn_ok_64_n.png       # Botón confirmar de 64 px de ancho

Cualquiera vale; lo crucial es unificarlo en el proyecto. No alternes big/small, números y l/s. El caos no viene de la regla en sí, sino de no aplicarla igual para todos.

Capítulo 3: Botones e iconos — estados claros de un vistazo

Los botones son el tipo de asset UI más numeroso y con más estados. Un botón suele tener cuatro: normal, presionado, seleccionado y deshabilitado. Las normas UI de Douban recomiendan palabras en inglés o abreviaturas unificadas:

Estado	Nombre completo	Abreviatura	Ejemplo
Normal	normal	n / def	btn_ok_n.png
Hover	hover	h	btn_ok_h.png
Presionado	pressed	p / pre	btn_ok_p.png
Seleccionado	selected	s / sel	btn_ok_s.png
Deshabilitado	disabled	d / dis	btn_ok_d.png

Yo uso abreviaturas de una letra: son cortas. btn_ok_n.png lleva 5 caracteres menos que btn_ok_normal.png; escribes más rápido y se lee mejor. Si tu equipo prefiere nombres completos, úsalos en todo el proyecto. No mezcles btn_ok_normal con btn_ok_n: buscar se vuelve un lío.

Nomenclatura de botones en la práctica

Supón un botón «Confirmar», azul y redondeado, con los cuatro estados:

btn_ok_n.png          # Estado normal
btn_ok_p.png          # Estado presionado
btn_ok_s.png          # Estado seleccionado
btn_ok_d.png          # Estado deshabilitado

Si hay versiones roja y verde:

btn_blue_ok_n.png     # Confirmar azul (normal)
btn_red_ok_n.png      # Confirmar rojo (normal)
btn_green_ok_n.png    # Confirmar verde (normal)

Orden: categoría (btn) + color (blue) + función (ok) + estado (n). Al ordenar alfabéticamente, los botones del mismo color quedan juntos y el reemplazo masivo es más fácil.

Iconos: la función primero

Los iconos suelen tener solo dos estados: normal y deshabilitado.

icon_search_n.png     # Icono búsqueda (normal)
icon_search_d.png     # Icono búsqueda (deshabilitado)

Lo importante es describir bien la función. No icon1.png, sino icon_search.png o icon_delete.png. El nombre debe decir para qué sirve sin abrir la imagen.

Un error habitual

He visto nombres como button_确认_正常.png: prefijo en inglés, función y estado en chino. Parece claro, pero:

1. Orden impredecible: el orden de caracteres chinos en el sistema de archivos no es estable.
2. Scripts incómodos: el procesamiento por lotes suele usar regex; los caracteres chinos complican las reglas.
3. Colaboración difícil: si el proyecto se internacionaliza, hay que renombrar todo.

Lo más seguro: inglés en minúsculas, guiones bajos. btn_ok_n.png: breve, ordenable, compatible con regex e i18n.

Capítulo 4: Sprites de personajes — secuencias de frames sin caos

Los sprites de personajes son más complejos que botones UI. Un protagonista puede tener siete u ocho acciones (idle, caminar, correr, atacar, daño, muerte, salto), cada una en varias direcciones, y cada dirección con muchos frames.

Mi mayor error fue la numeración de un solo dígito:

hero_run_left_1.png
hero_run_left_2.png
hero_run_left_3.png
...
hero_run_left_10.png

Parece normal hasta que abres la carpeta: hero_run_left_10.png queda entre hero_run_left_1.png y hero_run_left_2.png, porque el orden es alfabético y 10 empieza por 1.

Un desastre total.

Desde entonces uso siempre dos dígitos:

hero_run_left_00.png
hero_run_left_01.png
hero_run_left_02.png
...
hero_run_left_09.png
hero_run_left_10.png

De 00 a 09 todos van antes que 10. Si superas 100 frames, usa tres dígitos (000 a 999).

Fórmula para personajes

nombrePersonaje_acción_dirección_frame.png

Ejemplos:

• hero_idle_down_00.png — héroe, idle, abajo, frame 0
• player_run_left_01.png — jugador, correr, izquierda, frame 1
• enemy_attack_right_02.png — enemigo, atacar, derecha, frame 2

Vocabulario de acciones

Acción	Inglés	Abreviatura (opcional)
Idle	idle	—
Caminar	walk	—
Correr	run	—
Atacar	attack	atk
Daño	hurt	—
Muerte	death	die
Salto	jump	—
Lanzar hechizo	cast	—

Las abreviaturas dependen del equipo. atk es más corto que attack, pero un miembro nuevo puede no reconocerla. Los nombres completos son más universales; las abreviaturas, más compactas. Con menos de 20 frames por animación uso nombres completos; con más, considero abreviar para que la ruta no se trunque.

Identificadores de dirección

Lo más simple: cuatro direcciones — up, down, left, right.

En ocho direcciones puedes numerar de 0 a 7 (0 = arriba, 1 = arriba-derecha, etc.), pero hay que consultar la tabla cada vez. Prefiero nombres explícitos:

hero_attack_up.png
hero_attack_upright.png
hero_attack_right.png
hero_attack_downright.png
hero_attack_down.png
hero_attack_downleft.png
hero_attack_left.png
hero_attack_upleft.png

Los nombres de ocho direcciones son largos, pero no hay que adivinar. Con pocas direcciones (cuatro o solo izquierda/derecha), los nombres son lo más seguro. Con muchas direcciones, la numeración puede ser más compacta.

Capítulo 5: Estructura de directorios en Cocos Creator — clasificar para ir más rápido

La convención de nombres responde a «cómo se llama el archivo». La estructura de directorios responde a «dónde está». Necesitas ambas para encontrar assets de verdad rápido.

El tutorial básico de Cocos Creator de Tencent Cloud propone algo así:

assets/
├── textures/           # Texturas
│   ├── ui/             # UI (botones, barras de progreso)
│   ├── icons/          # Iconos funcionales
│   ├── backgrounds/    # Fondos
│   └── characters/     # Sprites de personajes
├── audio/              # Audio
│   ├── effects/        # Efectos de sonido
│   └── music/          # Música de fondo
├── animations/         # Clips de animación
├── prefabs/            # Prefabs
└── scripts/            # Scripts TypeScript

Genéricos vs. propios del módulo: carpetas separadas

Metí todos los assets en textures/ui/ y acabé con 300 archivos en una carpeta. Abrir, desplazarse y buscar costaba una eternidad.

Mejor separar genéricos y propios del módulo:

Genéricos en subdirectorios de primer nivel bajo textures/, p. ej. textures/icons/ para iconos compartidos.

Propios del módulo en carpetas dedicadas:

assets/
├── modules/
│   ├── login/          # Módulo login
│   │   ├── textures/   # Assets exclusivos del login
│   │   ├── prefabs/    # Prefabs del login
│   │   └── scripts/    # Scripts del login
│   ├── battle/         # Módulo batalla
│   │   ├── textures/   # Assets de batalla
│   │   ├── prefabs/    # Prefabs de batalla
│   │   └── scripts/    # Scripts de batalla

Al cambiar un módulo no recorres todo assets. Batalla: solo modules/battle; login: solo modules/login.

No subdividas en exceso

A veces demasiados niveles empeoran las cosas. Vi textures/ui/buttons/blue/rounded/ con cinco niveles y dos o tres archivos por carpeta. Encontrar un asset exige hacer clic capa tras capa, más lento que leer el nombre del archivo.

Mi recomendación: un nivel de clasificación basta, salvo categorías enormes (más de 50 sprites de personajes). Botones, barras y separadores en textures/ui/; iconos en textures/icons/; fondos en textures/backgrounds/. Tres niveles como máximo, claros de un vistazo.

Prefabs y scripts cerca de sus assets

Coloca prefabs y scripts junto a los assets del mismo módulo. El prefab de botones de login en modules/login/prefabs/ y los textures en modules/login/textures/. Rutas cortas, menos saltos entre carpetas al editar.

La documentación oficial de Cocos Creator insiste: archivos relacionados cerca, menos referencias cruzadas. Cuanto más corta la ruta, más claro el proyecto y más fácil migrar o refactorizar.

Capítulo 6: Siete reglas de oro — experiencia del equipo de Tencent Games

El equipo de WeChat Games de Tencent resumió siete reglas; aquí las interpreto con mi experiencia.

1. Breve pero informativo

El nombre debe transmitir lo esencial sin alargarse.

Bueno: btn_ok_n.png — botón, confirmar, normal.

Malo: button_confirm_normal_state_blue_rounded_large.png — demasiada información, difícil de leer y de escribir.

Mi regla: 3-5 segmentos de palabra. Si pasas de 5, elimina detalles secundarios (p. ej. «rounded» puede ir en un comentario del código).

2. De lo general a lo específico

El orden debe seguir la lógica: categoría grande, función pequeña, detalle al final.

environment_forest_tree_01.png

Entorno → bosque → árbol → primera variante.

Así los archivos de la misma categoría quedan juntos. Buscar environment_forest devuelve todo el material del bosque.

3. Orden útil para búsqueda alfabética

El prefijo afecta al agrupamiento. Para personajes, hero_ agrupa mejor que character_hero_: todo el héroe queda en la zona de la «h», no mezclado bajo «c».

4. Formato uniforme: snake_case o camelCase

Elige uno y úsalo en todo el proyecto.

Yo uso snake_case (minúsculas + guiones bajos):

• Buena compatibilidad con sistemas de archivos (menos problemas de mayúsculas)
• Buena legibilidad (límites de palabra claros)
• Regex simples (separador _)

Si el equipo prefiere camelCase, úsalo en todas partes. No mezcles formatos o los scripts fallarán.

5. Numeración uniforme: 01/02 o 001/002, nunca un solo dígito

Ya lo detallé en el capítulo 4. Un dígito desordena el listado; hay que rellenar con ceros.

• Hasta 99 frames: dos dígitos (00–99)
• Más de 99: tres dígitos (000–999)

6. Gramática coherente: misma forma verbal

Algunas acciones tienen dos formas: spin y spinning, attack y attacking.

Elige una y manténla.

Incorrecto:

cha_sonic_spin_01.png
cha_sonic_spinning_02.png

Misma acción, nombres distintos; un script puede omitir uno.

Correcto:

cha_sonic_spin_01.png
cha_sonic_spin_02.png

7. Ortografía coherente

Inglés británico y americano divergen: ambience vs ambiance, colour vs color.

Elige un estándar (suele recomendarse americano por ser más universal) y no alternes bg_ambience.png con bg_ambiance.png.

Capítulo 7: Transparentes y assets especiales

Algunos assets UI necesitan convenciones extra.

PNG transparentes

Muy habituales en UI de juegos: botones, iconos, overlays. Sufijos _trans o _overlay:

btn_trans_round.png        # Botón redondo transparente (sin borde)
icon_overlay_star.png      # Icono estrella superpuesto (badge)

La transparencia no siempre se ve en el nombre; el sufijo avisa antes de abrir el archivo.

Máscaras

Las máscaras recortan o redondean imágenes:

mask_rounded.png           # Máscara redondeada
mask_circle.png            # Máscara circular
mask_gradient.png          # Máscara con degradado

Suelen ser pocas; van en textures/ui/masks/ o directamente en textures/ui/.

Recursos multilingües

Proyectos i18n con varias versiones de texto en imagen:

title_zh.png               # Título en chino
title_en.png               # Título en inglés
title_ja.png               # Título en japonés

O códigos ISO:

btn_start_zh-CN.png        # Chino simplificado
btn_start_zh-TW.png        # Chino tradicional
btn_start_en-US.png        # Inglés (EE. UU.)
btn_start_ja-JP.png        # Japonés

Los ISO completos son más precisos pero alargan el nombre. Con cinco idiomas o menos, zh/en/ja bastan.

Varias densidades de pantalla

En móvil hace falta @1x, @2x, @3x. Cocos Creator recomienda esos sufijos:

[email protected]            # Densidad normal
[email protected]            # Alta densidad
[email protected]            # Muy alta densidad

Coincide con iOS/Android y herramientas como TexturePacker.

Nota: el sufijo de escala va después del estado: [email protected], no btn_ok@2x_n.png. Primero qué asset es (confirmar, normal); después la escala.

Caracteres especiales

Evita espacios, paréntesis y chino en nombres de archivo.

Espacios → guiones bajos. btn ok.png → btn_ok.png.

Paréntesis → eliminar o numerar. btn_ok(1).png → btn_ok_01.png.

Chino → inglés. 按钮_确定.png → btn_ok.png.

En Windows a veces funciona el chino; en algunos servidores Linux no. FTP puede corromper caracteres; CI/CD puede fallar al parsear rutas. Lo más seguro: inglés, minúsculas, sin caracteres especiales.

Resumen

La fórmula central son cuatro elementos: prefijo, función, estado y detalle.

btn_ok_n.png — categoría (botón) + función (confirmar) + estado (normal). hero_run_left_00.png — personaje + acción + dirección + frame. Con esto cubres el 90% de la nomenclatura UI.

El 10% restante son detalles: dos dígitos para ordenar bien, inglés para multiplataforma, abreviaturas unificadas para que los scripts funcionen. No cambian la fórmula, pero sí la eficiencia real.

Puedes empezar con tres pasos:

1. Revisar el proyecto actual: busca archivos mal nombrados y renómbralos con la fórmula de este artículo.
2. Crear un glosario de abreviaturas: acuerda bg/btn/icon/nav con el equipo y colócalo donde todos lo vean.
3. Organizar directorios: separa genéricos y propios del módulo; no amontones todo en una carpeta.

La convención de nombres no es un trabajo único, sino un hábito. Cuando btn_ok_n.png, la numeración de dos dígitos y el inglés se vuelvan automáticos, tus archivos serán más claros y encontrar assets, más rápido.