109 lines
3.4 KiB
Markdown
109 lines
3.4 KiB
Markdown
---
|
|
id: "0072l"
|
|
title: "gamedev — scripting opcional (wren / lua / hot reload C++ dylib)"
|
|
status: deferred
|
|
type: feature
|
|
domain:
|
|
- gamedev
|
|
scope: multi-app
|
|
priority: baja
|
|
depends:
|
|
- "0072k"
|
|
blocks: []
|
|
related: []
|
|
created: 2026-05-10
|
|
updated: 2026-05-17
|
|
tags:
|
|
- gamedev
|
|
- cpp
|
|
- scripting
|
|
---
|
|
|
|
## Objetivo
|
|
|
|
Decidir si vale la pena añadir scripting al stack y, en su caso, integrarlo. Es un sub-issue **diferido**: solo se aborda cuando la fricción de iterar gameplay en C++ (recompilar) sea concretamente dolorosa, no antes.
|
|
|
|
## Cuando reconsiderar
|
|
|
|
Triggers para sacar este issue del modo `deferred`:
|
|
- Recompilar `engine_demo` tras un cambio gameplay supera consistentemente 10s incluso con ccache + unity build.
|
|
- Aparece un caso real de iterar gameplay en runtime sin reiniciar (designers no-developers tocando logica).
|
|
- Aparece la necesidad de modding por usuarios finales.
|
|
|
|
Mientras eso no pasa: **no añadir scripting**. Cada lenguaje de scripting:
|
|
- Suma ~50-200 KB al wasm.
|
|
- Multiplica superficie de bugs (FFI bindings).
|
|
- Confunde la cultura del registry (¿dónde vive el "codigo de juego"? ¿C++ o scripts?).
|
|
|
|
## Opciones
|
|
|
|
### Opcion A — wren
|
|
|
|
- Pequeño (~50 KB).
|
|
- Sintaxis tipo Lua/Smalltalk.
|
|
- API C limpia.
|
|
- Single-author (Bob Nystrom), actualizaciones lentas.
|
|
|
|
### Opcion B — lua / luajit
|
|
|
|
- Lua estandar: ~200 KB. LuaJIT no compila a WASM, descartar.
|
|
- Mas usuarios, mas docs.
|
|
- Sintaxis familiar.
|
|
- Bindings: sol2 (~5K LoC, pero header-only) o tolua manual.
|
|
|
|
### Opcion C — quickjs
|
|
|
|
- JS subset.
|
|
- ~700 KB. Demasiado para nuestro budget.
|
|
- Descartar a menos que necesitemos JS por compatibilidad con codigo crypto.
|
|
|
|
### Opcion D — hot reload C++ via dylib
|
|
|
|
- Compilar el codigo de juego como `.so` / `.dll` y recargar al cambiar.
|
|
- 0 KB extra runtime.
|
|
- No funciona en WASM (no hay dylib loading dinamico).
|
|
- No funciona en iOS (no se permite carga dinamica de codigo).
|
|
- Solo util en desktop dev workflow.
|
|
|
|
### Opcion E — sin scripting + ccache + unity build
|
|
|
|
- Compilar todo C++ con ccache. Cambios incrementales tipicos < 3s.
|
|
- Unity build de la app reduce LTO time.
|
|
- Hot reload de **assets y shaders** (que es lo que mas se itera) NO necesita scripting.
|
|
|
|
## Recomendacion previa
|
|
|
|
Empezar con Opcion E. Solo si el dolor real aparece, evaluar A (wren) por ser la mas pequeña y compatible WASM.
|
|
|
|
## Si se aborda: scope minimo
|
|
|
|
1. Scripting solo en niveles altos (gameplay logic, AI scripts, dialogos).
|
|
2. Codigo "de motor" (rendering, physics, input) sigue en C++.
|
|
3. Bindings expuestos via funciones del registry (`script_register_*` para cada subsistema).
|
|
4. Hot reload de scripts en dev mode (file watcher).
|
|
5. Empaquetar scripts en el `.pak` de assets.
|
|
|
|
## Funciones (cuando llegue el momento)
|
|
|
|
- `cpp/functions/gamedev/wren_vm.{cpp,h,md}` — VM lifecycle
|
|
- `cpp/functions/gamedev/wren_bind.{cpp,h,md}` — registrar funciones C++ a wren
|
|
- `cpp/functions/gamedev/wren_call.{cpp,h,md}` — invocar funciones wren desde C++
|
|
|
|
## Tamaño objetivo si se hace
|
|
|
|
- Wren: ~60 KB total (vm + bindings).
|
|
- Bindings de juego: ~10 KB.
|
|
- Maximo aceptable: 100 KB.
|
|
|
|
## Criterio para cerrar este issue
|
|
|
|
- Decision tomada: si o no.
|
|
- Si si: VM integrada, bindings minimos, demo de un script de AI cargado en runtime.
|
|
- Si no: documentar el por qué en `cpp/GAMEDEV.md` (helpful no future contributors).
|
|
|
|
## No-objetivos
|
|
|
|
- Visual scripting (Blueprints style).
|
|
- Scripting para todo el juego.
|
|
- Multiples lenguajes de scripting.
|