Desarrollo de videojuegos/The Programming of Patrick's Parabox - Patrick Traynor (ThinkyCon 2025)
The Programming of Patrick's Parabox - Patrick Traynor (ThinkyCon 2025)

The Programming of Patrick's Parabox - Patrick Traynor (ThinkyCon 2025)

Thinky Games14 min10 nov 2025
Eh, me gustaría compartir con ustedes algunas cosas interesantes de programación del desarrollo de Patrick's Parabox.
9 capitulos
  • Introducción y concepto del juego(0'00 → 1'40)
    Patrick Traynor presenta una charla relámpago en ThinkyCon 2025 sobre aspectos interesantes de programación detrás del desarrollo de Patrick's Parabox.
    • Parabox es un juego tipo Sokoban donde las cajas pueden contener otras cajas. • Las cajas se pueden empujar dentro y fuera una de otra, anidándolas en cualquier configuración. • Algunas cajas pueden contenerse a sí mismas directamente, permitiendo entrar y salir repetidamente manteniendo la misma lógica de Sokoban.
    • En lugar de un array bidimensional, hay un array 2D para cada caja del juego. • Esto forma un array 2D de punteros a arrays 2D. • Los espacios en los bordes se conectan entre sí, y los niveles recursivos usan la misma estructura, con una caja refiriéndose a sí misma.
    La charla plantea la pregunta de cómo renderizar realmente una escena construida sobre esta estructura de datos anidada.
  • Renderizado con coordenadas de pantalla(1'40 → 3'41)
    Todo se renderiza en coordenadas de pantalla, anclado a un único rectángulo de referencia que representa la vista actual.
    • Una función llamada dibujar bloque dibuja un bloque específico y todos sus hijos dentro de un rectángulo dado. • Cuando un hijo contiene otros bloques, dibujar bloque se llama de nuevo recursivamente en un rectángulo más pequeño. • La recursión se detiene una vez que los bloques alcanzan un tamaño de uno o dos píxeles.
    • Para renderizar objetos más grandes fuera de la vista actual, el cuadrado se mueve conceptualmente al nivel padre, luego al padre del padre, saliendo tres niveles en total. • Esto produce un rectángulo mucho más grande que la pantalla; la mayor parte no aparece en pantalla, pero recurre correctamente al cuadrado inicial.
    Mientras cada bloque esté posicionado en relación con su padre, con una única coordenada absoluta (el cuadrado de anclaje), el renderizado funciona correctamente.
  • Animación de encogimiento recursivo(3'41 → 5'44)
    Empujar un bloque que se contiene a sí mismo dentro de otra caja produce una animación de encogimiento, y los bordes de la pantalla muestran un efecto de aplastamiento coincidente en el mundo exterior.
    • Se utiliza el mismo algoritmo de dibujar bloque, manteniendo todo relativo al punto de anclaje. • En lugar de dibujar el bloque azul en su posición real, se desplaza hacia abajo y se escala (se encoge o crece) antes de llamar a dibujar bloque nuevamente. • Los mismos desplazamientos y compensaciones de crecimiento se aplican al salir a los tres niveles padre.
    Se requiere ordenamiento por profundidad para asegurar que el bloque que se encoge siempre se dibuje encima de otros bloques como los rojos.
    Una cita del colega desarrollador de Sokoban Marcos Donatini: "coordenadas relativas equals dicha absoluta."
  • Detalles de técnica de renderizado y preguntas del chat(5'44 → 7'16)
    Los objetos grandes y nítidos fuera de la pantalla no son gráficos vectoriales sino PNGs grandes dimensionados lo suficientemente grandes para evitar borrosidad visible.
    Una pregunta de chat de Don preguntaba por qué el algoritmo sale tres niveles padre en lugar de uno.
    • Salir solo un nivel padre perdería ciertos elementos, como un token de jugador dos capas hacia afuera. • Salir dos capas cubriría ese caso. • Tres no es un número mágico; simplemente son suficientes niveles para cubrir la mayoría de situaciones comunes en el juego.
    Se mostró pseudocódigo del algoritmo de renderizado explicado para que los espectadores lo revisaran.
  • Casos especiales: bloques autocontenidos y limitación(7'16 → 8'52)
    Algunos niveles tienen una caja que contiene múltiples copias de sí misma; el algoritmo de dibujar bloque existente lo maneja sin problema.
    Inicialmente, un objeto de jugador aparecía instantáneamente en todas las copias antes de encogerse, lo que se veía mal.
    • Se utilizó un modo de tijera (común en APIs gráficas) para limitar los hijos dentro del cuadrado. • Se añadió un caso especial para evitar escalar el rectángulo grande hacia abajo al centro; en su lugar se utilizó un enfoque solo posicional que sigue siendo limitado.
    La corrección produjo un efecto de aspecto natural mientras se preservaba la respuesta visual recursiva a la entrada del jugador, después de muchos errores durante el desarrollo.
  • Caso especial: autocontención volteada horizontalmente(8'52 → 10'18)
    Algunos bloques se contienen a sí mismos volteados horizontalmente: salir por la izquierda resulta en aparecer por la derecha, y viceversa.
    Esto es fácil de implementar intercambiando las posiciones de salida lógicas.
    • La función dibujar bloque obtiene un parámetro verdadero/falso sobre si dibujar un bloque y sus hijos volteados. • Implementar esto correctamente requirió fragmentos de código en todo el código base multiplicando por -1 e invirtiendo banderas.
    Esto fue inesperadamente difícil de programar; una característica de rotación de 90° planeada fue descartada porque el volteo horizontal por sí solo fue lo suficientemente difícil.
  • Mecanismo de bloques que contienen al jugador(10'18 → 10'52)
    Otro mecanismo permite que el jugador mismo contenga otros bloques.
    El jugador fue refactorizado para ser el mismo objeto que un bloque, distinguido solo por una bandera booleana sobre si es el jugador.
    Tanto la lógica de Sokoban como la lógica de renderizado funcionaron con este enfoque con relativa facilidad, en contraste con la dificultad de la característica de volteo horizontal.
    Este mecanismo fue implementado muy temprano en el desarrollo.
  • Demostración de herramientas del editor de niveles(10'52 → 12'52)
    Patrick demuestra las herramientas del editor de niveles que construyó, señalando que no son estrictamente programación pero están relacionadas.
    • Crear bloques nuevos y editar sus hijos. • Colocar bloques dentro de otros bloques y sacarlos. • Un bloque referencial se representa simplemente por la letra R, actuando como un puntero.
    • Un atajo recarga el juego y reproduce el nivel para una iteración rápida. • Las teclas de volteo horizontal y vertical voltean un objeto y todos sus hijos. • Un atajo salta para ver el nivel en el hub, y los niveles pueden reordenarse rápidamente.
    Un atajo aumenta o disminuye el tamaño de los bloques, ayudando en la iteración rápida sobre la dificultad y el diseño del rompecabezas.
  • Observaciones finales y preguntas(12'52 → 14'16)
    Patrick agradece a la audiencia por seguir la charla y comparte su información de contacto.
    Una pregunta de chat de Scrupulous preguntaba si alguien más ayudó con el código.
    • El estudio de portado Plastic Fern manejó los puertos de consola del juego, incluida la versión de Switch. • Hubo algunas optimizaciones de rendimiento para el puerto, pero sin cambios importantes; Patrick señala que no es un experto en optimización.
    Patrick confirma que el código del juego base fue completamente su propio trabajo.