fn_registry/dev/issues/0072-gamedev-stack-roadmap.md

id, title, status, priority, created, tags, related_issues

id	title	status	priority	created	tags	related_issues
0072	Stack gamedev ligero multi-plataforma + crypto (roadmap)	pending	medium	2026-05-10	gamedev roadmap	0072a 0072b 0072c 0072d 0072e 0072f 0072g 0072h 0072i 0072j 0072k 0072l

Contexto

Objetivo: poder publicar juegos 2D con shaders vistosos en PC (Win/Lin/Mac), Web (WASM), Android, iOS desde el mismo codigo C++17, integrando el fn_registry como librería de funciones y el patron de apps ImGui ya existente.

Restricciones duras del usuario:

• Solo C/C++ o capa fina sobre C. NO Godot empotrado, NO Bevy, NO LOVE.
• Paquetes finales lo mas ligeros posible — WASM es prioritario para distribución web + integración con sistemas de criptomonedas (wallets, NFTs, pagos on-chain).
• Editor visual propio como app del registry (estilo shaders_lab/chart_demo), no editor externo.
• Mantener integración total con el registry (funciones componibles, dos SQLite DBs, agentes).

Decision arquitectonica

Hibrido C++ minimo, sin engine empotrado:

Capa	Eleccion	Razón
Windowing/input	SDL3	Cubre Win/Lin/Mac/Android/iOS/Emscripten, MIT, ~1-2MB
Graphics	sokol_gfx (single-header)	GL/GLES/WebGL2/Metal/D3D11 bajo una API. Encaja con cultura "single-file function"
Audio	miniaudio (single-header)	Todas las plataformas, MIT, ~200KB
Physics 2D	box2d	MIT, ~200KB
UI/editor/debug	Dear ImGui (ya en stack)	Backends SDL3 + sokol oficiales
Scripting (opcional)	wren o lua	~50-100KB, hot reload
Crypto bridge	Web3.js / ethers.js / @solana/web3.js via Emscripten JS interop en WASM; secp256k1 + ed25519 standalone para firma offline en native	Sin libs Web3 nativas C++ maduras; mejor delegar a JS en web y firmar offline en mobile

Por qué NO motor desde cero

• Engine 4 plataformas = 1-2 años solo runtime.
• Box2D, sokol, miniaudio, SDL3, ImGui ya resuelven 80% del trabajo. Ensamblar > reescribir.
• Mantenemos la cultura registry: cada pieza es funcion en cpp/functions/gfx/, cpp/functions/gamedev/, etc.

Por qué NO Godot empotrado

• Binario PC: ~60-90 MB. WASM Godot: ~20-40 MB. Hibrido propio: 5-15 MB PC, 2-5 MB WASM.
• GDScript fuera de la cultura del registry.
• Crypto integration en Godot existe pero requiere modulos custom GDExtension, perdiendo la "ventaja" inicial.

Sub-issues (orden recomendado)

#	Issue	Fase	Plataformas
0072a	SDL3 + sokol_gfx + ImGui smoke (engine_smoke app)	0 — Reconocimiento	PC + WASM
0072b	Runtime nucleo: sprite batcher, audio, input unificado, game loop	1 — Runtime minimo	PC + WASM
0072c	Asset pipeline: atlas packer, MSDF fonts, tilemap compile	1 — Runtime minimo	(host)
0072d	WASM build pipeline + size budget (emscripten, gzip < 2MB)	1 — WASM-first	WASM
0072e	Crypto bridge Web3 (wallets, sign tx) via JS interop en WASM	2 — Crypto web	WASM
0072f	Crypto on-chain: NFT asset loading, payments, leaderboards firmadas	2 — Crypto integration	WASM + native
0072g	Mobile Android: NDK build + touch input + virtual gamepad	3 — Mobile	Android
0072h	Mobile iOS: Xcode toolchain + Metal via sokol + safe area	3 — Mobile	iOS
0072i	Editor visual game_editor (scene tree, asset browser, inspector)	4 — Tooling	PC
0072j	Physics 2D: Box2D integration (physics_world_cpp_gfx)	4 — Features	todas
0072k	Demo plataformero engine_demo (referencia de stack completo)	5 — Validacion	todas
0072l	Scripting opcional (wren/lua) — diferido hasta validar necesidad	6 — Diferido	todas

Presupuestos de tamaño (objetivos no negociables)

• WASM gzip: < 2 MB runtime + < 5 MB con assets minimos
• PC binario: < 15 MB stripped
• Android APK base: < 20 MB
• iOS IPA base: < 25 MB

Cada sub-issue declara su contribucion al budget. Si una feature no cabe, se discute trade-off antes de mergear.

Reutilizacion del registry actual

Funciones que entran tal cual o con migracion mecanica:

• cpp/functions/gfx/dag_* (node editor shaders) → editor de shaders del juego
• cpp/functions/gfx/uniform_* → sigue valiendo
• cpp/functions/gfx/gl_shader, gl_framebuffer, gl_texture_load → marcar cpp_legacy, migrar a sg_* (sokol) progresivamente. NO borrar — apps desktop existentes siguen vivas
• fn_framework (app shell, layouts, panels) → forkear fn_framework_mobile con SDL3 backend; mismo API publico. Las apps PC siguen funcionando

Funciones nuevas (ver sub-issues):

• sg_init_cpp_gfx, sg_shader_cpp_gfx, sg_pipeline_cpp_gfx, sg_buffer_cpp_gfx, sg_image_load_cpp_gfx
• sdl_window_cpp_gfx, sdl_input_state_cpp_gfx, input_unified_cpp_gfx (touch + kb + gamepad → mismo struct)
• sprite_batch_cpp_gfx, tilemap_render_cpp_gfx, particle_2d_cpp_gfx
• audio_play_cpp_gfx, audio_load_cpp_gfx
• game_loop_cpp_gfx (fixed timestep)
• Asset pipeline: sprite_atlas_pack_cpp_gfx, ttf_to_msdf_cpp_gfx, tilemap_compile_cpp_gfx, shader_translate_cpp_gfx, audio_encode_cpp_gfx
• Crypto: secp256k1_sign_cpp_crypto, ed25519_sign_cpp_crypto, web3_bridge_js_cpp_crypto (WASM only)

Riesgos identificados

1. iOS sin mac — bloqueante. Mitigacion: GitHub Actions con macos-latest runner.
2. Crypto libs C++ maduras escasas — secp256k1 (Bitcoin/ETH) y ed25519 (Solana) son single-file libs. El resto (RPC, encoding, EIP-712) se delega a JS en WASM o se reescribe minimo.
3. Shader cross-compile — GLSL→MSL/HLSL/WGSL via SPIRV-Cross funciona pero hay edge cases. Plan B: escribir solo en GLSL ES 300 (subset comun a sokol).
4. WASM size creep — cada lib añade KB. Vigilar con wasm-objdump -h y twiggy en cada PR.
5. Crypto wallet UX en mobile — WalletConnect deep links son fragil. Validar pronto.

Salida esperada

Al cerrar todos los sub-issues:

• Una app engine_demo (plataformero) corriendo en PC, navegador, Android, iOS desde el mismo codebase.
• Una app game_editor (PC) que abre/edita/exporta proyectos.
• Funciones del registry reusables para futuros juegos.
• Pipeline de build: build_pc_cpp_pipelines, build_wasm_cpp_pipelines, build_android_cpp_pipelines, build_ios_cpp_pipelines.
• Documentacion: cpp/GAMEDEV.md con patrones especificos y cpp/PATTERNS.md actualizado.