Xorisu · Códice de combate

Gamepacks — DLC cosméticos de artistas

Properties1
tagssistemas, meta, diseño, negocio

Se lee en 5 min

La idea de una frase

Un artista digital crea sus animaciones, arte y sonido, los empaqueta como un gamepack (DLC) y los vende en el mercado de Xorisu. La lógica del combate es siempre la misma: el gamepack solo cambia cómo se ve y se oye, nunca cómo se juega.

Por qué es producto de valor

  • Adquisición externalizada — el artista trae su cartera de jugadores. Cada gamepack es un canal de marketing autónomo; pagas alcance con reparto, no con anuncios.
  • Coste marginal ≈ 0 — tú mantienes UN solo juego que balancear; ellos producen el contenido.
  • Ingreso recurrente y repartido — revenue-share: el artista cobra, la plataforma comisiona.

El caso está probado a escala (skins de Fortnite/CS, UGC de Roblox). La diferencia de Xorisu: el combate es minimalista y canónico, lo que hace el reskin trivial de empaquetar.

La regla de oro: dos capas que NO se tocan

Lógica canónica vs. piel vendible

La línea que hace viable el negocio (y que evita el pay-to-win) es separar limpiamente lo mecánico de lo cosmético.

CapaQuién la poseeQué incluye¿La lee el motor?
Canónica (mecánica)La plataforma. Fija, inmutable, balanceable.weapon type → perk, daño, críticos, veneno, ELOSí
Cosmética (presentación)El artista (gamepack)sprite, animación, sonido, emoji, tema de arenaNunca

Mismo combate, piel distinta. El jugador compra estética, jamás ventaja.

El desacople: perk → slot de arma, emoji → cosmético

Estado actual = acoplado

Hoy el perk está pegado al emoji: cada efecto se dispara con XXX_EMOJIS.includes(player.skinEmojis?.<arma>) (ver perks-y-skins). Equipar 🔨 Martillo te da el recoil. Si las skins las vendiera un tercero, eso es pay-to-win directo. Hay que romperlo antes de abrir el mercado.

El motor debe leer la identidad del perk, no el emoji. Se parte el slot en dos ejes ortogonales:

// ANTES (acoplado): el emoji ES el disparador
if (MARTILLO_EMOJIS.includes(p.skinEmojis?.bate)) { ... }
 
// DESPUÉS (desacoplado): el perk canónico es el disparador
if (p.perks?.bate === 'martillo') { ... }   // <- lógica, propiedad de la plataforma
// p.skin?.bate = { gamepackId, weapon } -> SOLO lo renderiza el cliente
  • player.perks = { puno, punal, bate } → id de perk canónico ('martillo', 'varita', 'base'…). Lo elige el jugador de un menú canónico (los ~20 efectos de hoy siguen igual). Balanceable, tuyo.
  • player.skin = { puno, punal, bate } → referencia cosmética { gamepackId, weapon } que resuelve a arte. El motor nunca la lee para mecánica; solo el cliente la pinta.

Resultado

Perk y aspecto quedan independientes: equipas el perk de recoil y llevas un bate dragón cyberpunk comprado a un artista. Como en Fortnite — la skin no toca el gameplay.

Migración (sin romper a nadie)

  1. Enum PERK_IDS por arma en game-logic.js; cada efecto pasa a leer perks.<arma> en vez de XXX_EMOJIS.includes(...). Un sitio cada vez, comportamiento idéntico.
  2. Inventarios actuales: quien hoy “posee” la skin Martillo recibe en la migración → (perk 'martillo' + cosmético equivalente). Mapeo weapon_skins → (grant de perk, grant de cosmético).
  3. Las constantes XXX_EMOJIS dejan de ser disparadores de perk (quedan, como mucho, de cosmético por defecto del set base).

El formato de gamepack (manifest)

Un gamepack no es código: es un bundle declarativo firmado de assets que mapea sobre slots canónicos.

{
  "id": "neon-cyberpunk",
  "version": "1.0.0",
  "title": "Neón Cyberpunk",
  "author": { "id": "artist_123", "handle": "@nova" },
  "type": "cosmetic",
  "engineApi": "1.x",
  "price": { "currency": "EUR", "amount": 4.99 },
  "assets": {
    "puno":  { "emoji": "👊", "sprite": "puno.png", "anim": "puno.json", "sfx": "puno.ogg" },
    "punal": { "emoji": "🗡️", "sprite": "punal.png", "anim": "punal.json", "sfx": "punal.ogg" },
    "bate":  { "emoji": "🏏", "sprite": "bate.png",  "anim": "bate.json",  "sfx": "bate.ogg" }
  },
  "theme": { "accent": "#00ffff", "bg": "arena-neon.png", "font": "Orbitron" },
  "signature": "<firmado por la plataforma tras moderación>"
}

Reglas que impone el validador de la plataforma

  1. type debe ser cosmetic — un tercero no puede declarar mecánica.
  2. Cero código ejecutable — los assets son datos (imagen/anim/sonido) que tu cliente pinta. Ningún JS del artista corre en el bucle de juego.
  3. Solo slots canónicos (puno/punal/bate) — no se inventan armas (eso sería mecánica).
  4. Schema-validado + versionado contra engineApi + firmado tras la revisión de moderación.

Plumbing del mercado (nombrado, aún sin construir)

graph LR
  A["Artista sube gamepack"] --> M["Moderación / firma"]
  M --> S["Tienda de gamepacks"]
  S --> P["Jugador compra"]
  P --> C["Stripe Connect: split"]
  C --> AR["Payout al artista"]
  C --> PL["Comisión plataforma"]
  P --> O["user_gamepacks (ownership)"]
  O --> R["Cliente renderiza skin"]
  • Ownership — extender el modelo de inventario (weapon_skins → gamepack_assets / user_gamepacks).
  • Pagos a terceros — aquí NO vale el patrón Stripe Checkout de las suscripciones propias; reparto a artistas = Stripe Connect (cuentas conectadas + payouts + split automático).
  • Moderación — abierto-con-revisión vs. curado-por-invitación (decisión de negocio pendiente).
  • Hosting de assets — y aquí resucita el uso real de cdn.xorisu.com: servir el arte de los gamepacks. El CDN vuelve cuando por fin tiene consumidor.

Conexiones

sistemas · perks-y-skins (la capa que se desacopla) · economia (ownership + monedas) · skins · objetos-funcionales

Vista Gráfica

Retroenlaces