SCL: Sean Tracy | ficha técnica

1) Sean Tracy: qué cubre su rol

Cambia de título a Managing Director of Technical Operations: junta tools + tech + animation tech + character tech.
CTG es “gigante” y está dividido para no caer en un “200 reports to one manager”: menciona a Benoit arriba y que Marco y él dividen áreas.

Lectura útil: esto refuerza la idea de que “Core Tech” se está tratando como un producto en sí mismo (equipos, ownership, división clara), que es exactamente lo que necesitas cuando el objetivo es escalar sistemas/planetas/contenido.

2) Character customizer: scars primero; “Body DNA” como visión

Scars y Blood/Sweat/Tears

“Blood, sweat, and tears” no es solo VFX: habilita decal support para personajes, lo que abre la puerta a scars.
Dice claro: tech lo permite, pero lo “dinámico” (cuándo aparece, cuánto dura, relación con Death of a Spaceman) necesita diseño.

Body DNA

Separó “height adjustment” de “thin/fat variations”.
La visión es DNA para el cuerpo, similar a DNA de la cara, para rangos y mezclas, no “dos modelos y blend”.
La barrera es brutal: ropa/armaduras son un ecosistema de assets con skinning, orden de vértices, LODs, estados distintos, etc. Menciona que están cerca de ~1200 assets de cuerpo en el PU.

Lectura útil: aquí está la verdad incómoda: no es “hacer un slider”, es re-hacer compatibilidad de todo el armario. Body DNA es un proyecto de “años”, aunque vayan soltando piezas (scars/decals) antes.

3) Cybernetics: “fácil” técnicamente, difícil en gameplay/animación

Dice que ya existen personajes con cybernetics (PU y quizá Squadron).
Tech no es el freno; la pregunta es diseño: ¿se quitan? ¿qué pasa si te quitas un brazo? ¿cómo se anima el uso de armas?

Lectura útil: típico de SC: cuando un sistema toca animación + gameplay, se vuelve una decisión de diseño/consistencia del universo, no de “si se puede”.

4) Face scanning: no “scan directo”, sino “aproximación por DNA”

Menciona explícitamente el ejemplo de NBA 2K15 como advertencia de resultados feos.
Propone algo más realista: usar FOIP/webcam/imagen para empujar el DNA “lo más cerca posible”, y luego aplicar textura/tono.

Lectura útil: esto suena a “evitar el valle inquietante” y también a evitar que la gente convierta el ‘verse en un desfile de caras rotas. Es un “sí, pero solo si queda bien”.

5) Paridad male/female: rigs distintos = assets duplicados = errores inevitables

Explica que hay rigs similares, pero alturas/offsets/controllers diferentes, y por eso se “skinnean” por separado.
Muchas veces lo que pasa es simple: alguien se equivoca o un asset queda solo para uno.
Tech debt por assets viejos de la era donde no existía player femenino.

Lectura útil: su explicación es útil para contestar comunidad: no es mala fe, es duplicación real y un pipeline enorme.

6) Tools & pipeline: “cuántas herramientas” = “cuántos multiplicadores”

Esta parte está buenísima para tu línea editorial (tú eres de infra/ops, esto te habla el idioma).

“Tool” puede ser: ejecutable, script Python, plugin de Maya, MEL, proceso…
Dice que podrían ser cientos o miles, dependiendo de cómo cuentes.
Te dibuja equipos:
- Editor team (plugins, Python, outliner, level design tools, etc.)
- CTG Tools UK (herramientas globales fuera del editor)
- Montreal Tools (Staritect, profilers, “Tiny Machine” smart assets)
- OST/Live tools (Bootstrapper para backend local)

Herramientas que menciona y para qué sirven (en lenguaje humano):

CopyBuild: distribución/patching de builds (evolución desde “copiar del network drive”).
DataForge: manejo de records/entidades/datos (base de muchas cosas).
Staritect: propagación/escala de locations (muy alineado a Genesis y a poder construir más rápido).
Tiny Machine: “smart assets” con awareness contextual (ej: una escalera que se ajusta a la pared sin escoger 10m/15m).
Bootstrapper: levantar backend local para dev/testing (cada vez más pesado por tamaño del universo).

Lectura útil: esto es munición perfecta para explicar por qué “hacer el juego” no es solo “hacer naves”: es construir la fábrica.

7) StarWear/Starware: la actualización más “jugable” del episodio

Aquí es donde suelta lo más directo:

Dice que se hizo mucho de contenido, pero faltaba soporte de ingeniería y diseño para cerrarlo.
Ahora hay strike team, agenda “super rígida”, y apunta a salir dentro del año (sin fecha).
Reconoce que la comunidad presionó y eso ayudó a priorizar.
Menciona el “invisible undersuit” como “accidente” que dejó ver parte de lo que StarWear quiere ser.
También menciona que al separar assets “a la manera StarWear”, queda habilitado el markup para que sistemas procedurales vistan NPCs de forma coherente (ropa de calor/frío, shorts en calor, sunglasses con sol, etc.).

Nota de archivo: el nombre correcto en marketing/comunidad suele verse como StarWear, mostrado en CitizenCon 2954 (“Dressed to Kill”).

Lectura útil: si esto sale “bien”, no es solo fashion: es el inicio de “gear con propósito” (especializaciones, contexto ambiental, NPCs más coherentes).

8) Creature Tech: hacia “Creature DNA” + más critters simples

Dice que “no sabe” si hay criaturas nuevas este año (literal, no “koi”).
Tech: creatures están cerca de funcionar “como un character”.
Dirección: skeleton scaling + Creature DNA para variación masiva.
Además: sumar “critters” simples (no IA compleja) para poblar.

Lectura útil: esto es “sistematizar vida” para planetas. Menos “una criatura artesanal”, más “un sistema que genera variedad”.

9) Vegetación destruible y Maelstrom

No van por el approach viejo de boolean subtraction del CryEngine clásico.
Maelstrom: fracturas 2D/3D procedurales, y lo usan fuerte en Squadron.
Dice que está trabajando una parte de Maelstrom para armadura destructible en un caso específico (un personaje que necesita que se rompa algo).
Espera que eventualmente se puedan romper árboles/vegetación, pero depende de physics + planet tech.

Lectura útil: esto es “la infraestructura para destrucción”, y el primer paso real es conectarlo a personajes/armadura.

10) VR: sí es visión a largo plazo; el reto es la coherencia social (1P/3P unificado)

VR es “nuevo” para ellos; menciona OpenXR y que salió en 4.5 (sin controllers).
Dice que el deseo inmediato en VR es interactuar con manos/controles, pero el problema es que en SC todo es unificado: lo que haces en first person lo verán otros en third person.
Referencia juegos tipo Boneworks / Half-Life Alyx como barra, pero advierte “wackiness tolerance”.

Lectura útil: la barrera no es solo técnica, es experiencia multiplayer consistente. Si un VR user se ve “poseído” en 3P, eso rompe el universo.

11) Facial idles (blinks/saccades) y bugs de “cara muerta”

Dice que sí: deberían existir blinks/eyebrows/body shifts cuando FOIP no está activo.
Menciona que a veces “se rompe el contexto” (por casco/armadura/cambios) y la cara queda “dead”.
Si no lo ves en otros, puede ser culling.

Lectura útil: aquí hay un mini “bug taxonomy”: si tu cara está muerta siempre, es bug; si no ves animación en otros, puede ser culling.

12) Blood/Sweat/Tears también para players (y se ve demasiado real)

Confirma que no es solo NPC: la intención es players también.
Cuenta anécdota de gore “demasiado real” al cortar cara con cuchillo; tuvieron que blur.
Dice que esto es importante para cerrar Squadron por humanos + combate.

Lectura útil: esto sugiere que veremos primero madurar esto por Squadron y luego caer al PU cuando esté “presentable”.

13) StarCloth: la mejora real fue meter el control en Maya + rigid areas

Antes: tooling básico “debug GUI” en engine para paint/markup.
Ahora: plugin de Maya que replica StarCloth y deja iterar mucho más fino, viendo comportamiento real.
“Rigid objects on cloth”: botones/grommets rígidos que afectan la simulación y cambian el look.

Lectura útil: esto es exactamente lo que Sean repite: tools = calidad + velocidad + menos sufrimiento.

14) Cierre: “aprecien a los tools people”

Dice que están orgullosos de no depender de middleware, y que a veces al compararse con Unreal/Unity se dan cuenta que están “en la cima” en varias áreas.
Frase potente: editor stability depende de game stability (“el cliente corre dentro del editor”).
CopiaBuild se lleva culpas que no son suyas (network/build store/patcher).

Lectura útil: es una defensa pública del “trabajo invisible”. Ideal para un segmento editorial tuyo (y te calza por tu rol real).

Impacto en profesiones industriales y de logística

Mis notas sobre como podrían impactar los temas presentados las profesiones industriales y de logística.

1) Minería

StarWear puede terminar afectando minería más de lo que parece: si el sistema trae specializations + ropa contextual (calor/frío), eso abre la puerta a equipamiento con bonificaciones reales (resistencia térmica, stamina, manejo de herramientas). Eso impacta minería FPS (cuevas) y minería de superficie por exposición ambiental.
VR: si madura a interacción física, minería en cockpit (Prospector/MOLE) y lectura de MFDs/starmap en VR se vuelve una ventaja de inmersión brutal, pero solo si resuelven controllers y animación consistente.

2) Salvage

Maelstrom + destrucción: cuando conecten destrucción a objetos/armaduras y luego a entorno, salvage puede ganar “materialidad”: partes que se rompen/fragmentan de forma más coherente y luego se recuperan. No es promesa directa, pero el camino (fractura + pipelines) apunta a ese tipo de mundo más “tangible”.
Tools/pipeline: todo lo que acelere creación de assets/smart assets reduce el tiempo de iteración de features de salvage (módulos, piezas, props, interiores industriales).

3) Carga / hauling / logística

Staritect + tools (y la idea de escalar locations): si realmente acelera construcción de lugares, la logística se beneficia de más nodos, más rutas, más variación de puntos de entrega/recogida, y por ende un “mapa económico” más rico.
CopyBuild / DataForge / records (a nivel meta): todo lo que ordena data y records suele traducirse (eventualmente) en economía/misiones más consistentes y menos “parches rotos”.

4) Exploración (en un futuro)

Creature DNA + critters: exploración gana cuando los planetas tienen vida variable y no “el mismo bicho siempre”. Incluso critters simples mejoran el “feeling” de planeta vivo.
VR: exploración es probablemente el rol que más se transforma con VR por percepción espacial: cuevas, derelicts, lectura de cockpit, spotting en superficie.