deathstar

Stellar Abyss es un prototipo de combate espacial 3D orientado a escritorio que se ejecuta en el navegador, construido con Babylon.js, TypeScript y Vite. Las naves, el entorno, el universo y el audio se describen como originales y procedimentales; el README establece explícitamente que el proyecto no utiliza naves, personajes, logotipos, música ni efectos de sonido protegidos de franquicias existentes. **Historia y configuración** El juego se enmarca en un entorno original de space-opera: un navegador exiliado de la Order of the Threshold sigue una señal hacia el Náris Belt, donde una fuerza militar anónima custodia el paso a casa. Al iniciar, el jugador elige entre dos naves, la Arthur Comet y la Gael Ray. Un vuelo de reconocimiento escala hasta convertirse en batallas contra escuadrones de cazas y, finalmente, contra el Obelisk, una gran nave capital. **Controles y combate** El vuelo se controla con el ratón, donde la distancia desde el centro de la pantalla controla la intensidad del giro; devolver el ratón al centro hace que se vuele en línea recta y no se utiliza el bloqueo del puntero. Las asignaciones del teclado cubren la velocidad de crucero (W/S), el balanceo (A/D), el desplazamiento lateral (Q/E), el pulso de láser dual (clic izquierdo), el cañón de plasma tras el desbloqueo (clic derecho), la ruptura de energía tras el desbloqueo (R), el impulso con recarga (Shift izquierdo), una esquiva con invulnerabilidad breve y un tiempo de enfriamiento de tres segundos (Espacio), la selección y el ciclo de objetivos (F, Tab), la pausa (Esc), el silencio (M) y un interruptor de diagnósticos (F3). El plasma inflige daño de área y la ruptura de energía es un torpedo rápido con un tiempo de enfriamiento de ocho segundos. La misión se pausa automáticamente cuando la ventana pierde el foco. **Estructura de la misión** Seis etapas progresan desde el reconocimiento y la interceptación de exploradores, pasando por patrullas más grandes y cazas de asalto, hasta el desbloqueo del cañón de plasma, el enfrentamiento con cazas de élite y el desbloqueo de la ruptura de energía, la eliminación de refuerzos y, finalmente, el desmantelamiento del Obelisk subsistema por subsistema (torretas de defensa, generadores de escudos, motores iónicos y reactor), seguido de una reacción en cadena y la finalización de la misión. **Reglas y retroalimentación** Los escudos se regeneran cinco segundos después de recibir daño, mientras que la integridad del casco no se regenera. Destruir un caza restaura siete puntos de escudo. Los asteroides y la nave capital causan daño por colisión que no es una muerte instantánea. Una opción de Test Flight adelanta el tiempo de la misión a una velocidad de 4× manteniendo sin cambios el movimiento, las armas, el daño y los tiempos de enfriamiento. **Interfaz y localización** El juego comienza en inglés y ofrece un selector EN / PT-BR en el menú y la pantalla de pausa, persistiendo la elección en el navegador. Los nombres propios del entorno permanecen sin traducir. **Ejecución y construcción** El desarrollo local requiere Node.js 22.12+ o Node.js 24; el flujo documentado es `npm install` y luego `npm run dev`, sirviendo en `http://127.0.0.1:5173`. Añadir `?renderer=webgl&debug` fuerza WebGL2 y habilita los diagnósticos. Una compilación de producción puede servirse con `npm run build` y `npm run preview`. Un flujo de trabajo de GitHub Actions en `.github/workflows/deploy.yml` compila y publica `dist/` en GitHub Pages cuando se hace push a `main`, y el README señala que el flujo de trabajo solicita solo los permisos de lectura, escritura de Pages e identidad de despliegue que requiere GitHub Pages. **Arquitectura** El código está organizado en módulos que incluyen core (motor, bucle, entrada, activos), player (vuelo y salud), enemies (IA y formaciones), weapons (proyectiles agrupados y colisión), world (entorno espacial), effects, audio, progression, boss y ui. Las constantes del juego residen en `src/config.ts`; las pruebas de combate y progresión están en `tests/` y una prueba de humo del navegador está en `scripts/`. `AssetManager.ship()` crea modelos primitivos temporales, y `AssetManager.loadModel(url, parent)` carga glTF/GLB para un futuro reemplazo visual. Los modelos miran hacia el +Z local y no se requiere ningún modelo externo para jugar. Se intenta WebGPU primero con una alternativa automática a WebGL2. **Verificación** Las comprobaciones documentadas son `npm test`, `npm run build`, `npm run dev` y `node scripts/browser-smoke.mjs`. La prueba de humo necesita un servidor local y Chrome, y cubre el inicio, la aceleración, el impulso, el giro mientras se dispara, bajas reales, pausa, reanudación, reinicio y errores del navegador, escribiendo capturas de pantalla en rutas temporales. El README indica que pasan seis pruebas lógicas y que la validación de Chrome/WebGL2 confirmó el disparo, el giro mientras se dispara, tres bajas con puntuación, pausa, reanudación, reinicio y ausencia de errores en tiempo de ejecución, con una compilación de producción exitosa; también señala que WebGPU y una partida completa en el navegador de la batalla de la nave capital no fueron validadas en este entorno. **Estado y limitaciones** El prototipo tiene una misión completa con estados de victoria, derrota y reinicio. Las naves y el audio se describen como marcadores de posición procedimentales funcionales. Las texturas artísticas, los LODs, los controles táctiles y los controles de mando aún no están implementados, y el paquete principal es de unos 6.3 MB, o 1.38 MB gzip, con la optimización de carga pendiente. El objetivo establecido es de 60 FPS en un escritorio razonable, con WebGL2 como ruta de diagnóstico de referencia y alternativas locales para Google Fonts. Los diagnósticos pueden mostrar FPS, posición, velocidad, enemigos activos, proyectiles, mallas activas y tiempo de misión. **Contribuciones** Se aceptan contribuciones a través de fork-and-pull-request contra `jeffotoni/deathstar`; el README pide a los colaboradores que no envíen ramas de características al repositorio oficial, que utilicen Conventional Commits, que mantengan las refactorizaciones no relacionadas fuera de un PR y que expliquen el resultado visible para el jugador junto con los comandos de validación y una captura de pantalla o grabación para cambios visuales o de jugabilidad. También recomienda proteger la rama `main`, mantener los permisos de Actions como solo lectura por defecto, evitar secretos en código de forks no confiables, no hacer commit de credenciales o salida de compilación generada, y reportar vulnerabilidades privadamente según `SECURITY.md`.