Estructura de un paquete

Un juego de Green Games es un paquete de datos y scripts. No es una página web: no trae HTML, CSS ni código que toque el navegador o tu equipo. El juego declara su mundo en archivos JSON y su lógica en un script que solo conoce la API de Green Games. El programa que lo muestra (el portal, el launcher o el editor) es el único que dibuja, lee el teclado y guarda datos.

Esta sección es para quien escribe esos archivos a mano. Si prefieres armar el juego sin código, el editor escribe los mismos archivos por ti: Recorrido del editor.

Qué necesitas#

Disponibilidad#

El contrato (formato 1, API 1) creció desde su primera versión, siempre sumando cosas. Hoy todo lo que se usa o se descarga trae el mismo motor:

Esta sección de la documentación describe ese contrato completo, que hoy es la versión 1.2: actores, cámara, rótulos, vistas (tercera persona, primera persona, 2D de lado, desde arriba, isométrica), láminas, mapas de baldosas, multijugador en el mismo equipo y, con la versión 1.1, el terreno de cubos del mundo abierto, el puntero y la barra rápida, y con la versión 1.2, los modelos, las texturas y los sonidos grabados. Un .ggx que valida corre igual en los cuatro.

Lo que todavía no ofrece ninguna aplicación publicada es el multijugador en línea: el formato ya deja declararlo (multijugador.enLinea), pero no hay salas por internet. Ver Hoja de ruta.

Las carpetas de un juego#

Cada juego vive en su propio directorio. El nombre del directorio es el id del juego.

mi-juego/
  juego.json               manifiesto: nombre, dificultades, controles, tablas, textos
  escenas/principal.json   una o más escenas: piezas, apariciones, zonas, luces, vista y mapas de baldosas
  laminas/moneda.json      opcional: láminas, dibujos de píxeles escritos como texto
  scripts/principal.ts     la lógica, en TypeScript o JavaScript, con la API de Green Games
  recursos/portada.svg     recursos empaquetados (hoy: la imagen de la portada)
  modelos/robot.glb        opcional: modelos 3D (versión 1.2)
  texturas/ladrillo.png    opcional: imágenes para el material de las piezas (versión 1.2)
  sonidos/campana.wav      opcional: sonidos grabados (versión 1.2)
  creditos.json            autor y licencia de cada modelo, textura y sonido (versión 1.2)
  pruebas/bot.json         guion del bot que juega la partida de principio a fin

greengames empaquetar (o Exportar en el editor) convierte esa carpeta en un archivo .ggx. El mismo .ggx corre en el portal, en el launcher y en el editor. Qué lleva dentro: El formato .ggx.

Unidades y ejes#

• Y es arriba. El avatar mira hacia +Z cuando su rotacionY es 0.
• Una unidad es más o menos medio avatar de ancho. El avatar mide 0,8 de ancho y 1,8 de alto.
• Las rotaciones van en grados, en orden Y-X-Z (primero gira sobre Y).
• La simulación avanza a 60 cuadros por segundo fijos: el paso de tiempo dt siempre vale 1/60. Por qué: Determinismo.

Medidas para diseñar niveles#

Con estos números decides el ancho de un hueco o la altura de un escalón antes de probar. Son los valores por defecto; el script puede cambiar la rapidez y el salto de cada jugador, y la escena su gravedad.

Un jugador que cae por debajo de alturaCaida vuelve a su punto de aparición.

El ciclo de vida de una partida#

1. El reproductor carga el .ggx, lo valida y muestra la pantalla de inicio (portada, dificultad, controles). Esa pantalla, la pausa y el panel de fin los pone el reproductor: el juego no los programa.
2. Al pulsar Jugar crea la sala aislada y le entrega el paquete, las opciones (dificultad, idioma, semilla, modo) y lo guardado (progreso y puntajes).
3. La sala carga la escena inicial, solo con las piezas de la dificultad elegida, y crea a los jugadores en la primera aparición.
4. Se ejecuta el script una vez (el código de nivel superior) y luego lo registrado con juego.alIniciar.
5. Cada cuadro, en este orden: movimientos de piezas, jugadores (entrada, salto, gravedad), actores, física, toques y zonas de jugadores, toques de actores, choques entre piezas, acciones, temporizadores, cronómetros y, al final, juego.cadaCuadro.
6. juego.terminar(...) detiene la sala. El reproductor muestra el panel de fin.

Tres cosas que se desprenden de ese orden:

• Los cambios que hace el script en un cuadro se ven en el siguiente.
• Si un evento del script lanza un error, la partida sigue, el error se informa y greengames probar falla.
• Una pulsación más corta que un cuadro no se pierde: llega igual al salto y a jugadores.alAccion.

El camino completo#

1. Crea el juego. greengames crear mi-juego --nombre "Mi juego" deja una carpeta con un juego pequeño y completo (juntar monedas contra el reloj) que ya pasa la validación y la prueba. Con --tipo eliges otra plantilla de partida (primera persona, 2D de plataformas, vista desde arriba, isométrico, híbrido o multijugador): crear.
2. Decide el juego en una frase. Qué hace el jugador, cómo gana, cómo pierde y qué número mide lo bien que le fue. Ejemplo: "Cruza el circuito hasta la meta; gana al llegar, pierde si se acaba el tiempo; el puntaje es el tiempo".
3. Arma la escena en escenas/principal.json: primero el suelo y las apariciones, después lo demás. Ver Escenas.
4. Escribe el script en scripts/principal.ts. Ver Scripts y la referencia de la API.
5. Escribe el guion del bot en pruebas/bot.json: el bot debe poder ganar en todas las dificultades. Ver Pruebas con el bot.
6. Valida. greengames validar mi-juego revisa archivos, esquemas, tipos del script y reglas. Corrige cada error y lee cada aviso. Qué significa cada código: El validador.
7. Prueba. greengames probar mi-juego juega la partida sin pantalla, en cada dificultad y con dos semillas. Para verla con tus ojos: greengames previsualizar mi-juego.
8. Empaqueta. greengames empaquetar mi-juego escribe el .ggx. Un juego con errores no se empaqueta.

Todas las órdenes, con sus opciones y sus salidas reales: La herramienta greengames.

Sigue con#

• El manifiesto: la ficha del juego, propiedad por propiedad.
• Caso de estudio: un juego real, leído de principio a fin.
• Límites: cuánto cabe en un paquete y en una partida.