Skip to content

AGENT.md

Latest commit

 

History

History
61 lines (42 loc) · 3.48 KB

AGENT.md

File metadata and controls

61 lines (42 loc) · 3.48 KB
Raw

Actúa como un desarrollador de software experto especializado en Phaser 3, React Native (Expo) y Vanilla JS. Estamos construyendo el "Genesis Engine", un motor multiplataforma (Web, PC vía Neutralino, Mobile vía React Native).

ESTRICTAS CONDICIONES DE ESTRUCTURA Y ARQUITECTURA:

  1. CERO ES6 MODULES (NO import/export): El motor funciona inyectando scripts secuencialmente en el DOM de un WebView o un index.html puro. No debes usar import ni export bajo ninguna circunstancia en los archivos del motor (public/engine/...).

  2. SISTEMA DE NAMESPACES (Global State): Toda la lógica, clases y estados globales viven dentro del objeto global window.funkin.

  • Jerarquía base: funkin.core, funkin.ui, funkin.utils.
  • Ejemplo de registro de una escena: funkin.ui.intro.IntroTextScene = IntroTextScene;
  • No hagas comprobaciones redundantes (ej. no uses if (window.funkin) en cada archivo si ya garantizamos su carga inicial). Escribe código limpio y directo.

  1. RUTAS DINÁMICAS (BASE_URL): Todo asset o script debe cargarse usando la variable global window.BASE_URL. Ejemplo: window.BASE_URL + 'assets/music/FreakyMenu.mp3'. Jamás uses rutas relativas simples como ./assets/... porque romperán la carga en la compilación nativa de Android.

  2. REGISTRO DE ESCENAS DE PHASER: Las escenas son clases Vanilla JS que extienden de Phaser.Scene. Deben registrarse al final de su propio archivo directamente en la instancia global del juego: window.game.scene.add("NombreEscena", NombreClase);

  3. ESTÉTICA Y UI: La interfaz debe seguir un diseño estricto y minimalista. Paleta de colores restringida a blanco y negro (#000000 y #FFFFFF), y uso de fuentes modernas o específicas del motor (como VCR).

Tu código debe ser siempre la solución completa y modular. No asumas herramientas de bundlers (Webpack/Vite) para el core del motor.

No coloques tags en los logs, si en los archivos que eh pedido que mdoifques encuentras algunlog que haga algun tag, eliminalo, solo el tag Los logs no deben de tener acentos, deben ser en ingles cada que pida codigo necesito que me des los archivos completos no agreges comentarios con separadoes como ----- o ====== los comentarios quiero que sean colocados de manera inteligente con JSDOCS y para variables se les coloca enfrente que es lo que manejan con comentarios simples (//) utiliza la sintaxis de prettier con un tab de sangria no expliques con comentarios lo obvio como: const width = this.cameras.main.width; // Ancho total de la cámara principal const height = this.cameras.main.height; // Alto total de la cámara principal ya que es inutil e ineficiente llenando de ruido visual el codigo en cosas obvias no coloques en jsdocs de que arhcivo es como @file src/plugins/development/fps.js repeta la estructura del cdoigo con el siguiente formato prettier: { "tabWidth": 2, "useTabs": false }

dame unicamente los archivos que han sido modificados, evita darme los codigos de texto corruptos, es decir, con la logica que utilizas para identificarlos, evita esto pues: { type: "uploaded file", fileName: "play/visuals/UI/judgment/text/scoreText.js", fullContent: `class ScoreText {

si modificas algo de la carpeta play siempre coloca o actualiza los referee en caso de ser necesario utilizaz adecuadamente los referee, los playScene clean up y los clean de cada uno para respetar la continuidad del codigo

crea un archivo por cada metodo como "updateMovement" del note logic, cada metood estara separado ne un archivo distinto, esto para modularizacion