En qué consiste el juego
Cavas, vendes o guardas lo que encuentras, y completas el índice. Las monedas compran una pala mejor, y una pala mejor cava más rápido y llega a gemas más raras. Las monedas y los hitos del índice también desbloquean nuevas zonas, cada una con su propio catálogo de gemas. Más allá de cavar hay mascotas de huevos de zona, misiones diarias y semanales, una bóveda por la que puedes caminar para exhibir tus mejores hallazgos, y eventos por tiempo limitado. Un renacer reinicia tus monedas, herramientas y zonas a cambio de más suerte, mientras conserva tu índice, mascotas y cosméticos. Las zonas más lejanas son un conjunto de islas del Infierno, a las que se llega por un portal tras vencer a un jefe, para jugadores que han renacido lo suficiente como para querer un sitio nuevo donde cavar.
Probabilidades reales, y cómo demostrarlas
Toda la propuesta se resume en "cada gema muestra su probabilidad real. Sin secretos." Eso solo significa algo si las probabilidades en pantalla son las que el servidor realmente sortea. RollService, el módulo dueño de cada tirada, se prueba con una ejecución semillada de 1.000.000 de excavaciones que compara el resultado con la tabla de probabilidades: la peor desviación en todo el catálogo fue de 1,75 sigma, bien dentro de lo que produciría una tirada justa, a 168.000 tiradas por segundo en el arnés de línea de comandos. Ese arnés corre completamente fuera de Roblox, contra los mismos módulos de Luau que usa el juego en vivo, así que la prueba de probabilidades no está probando una copia de la lógica, está probando la lógica misma.
Todo es una tabla de configuración
Gemas, precios, probabilidades de caída, diseño de zonas y artículos de tienda viven en módulos de configuración de Luau en lugar de estar dispersos por la lógica del juego. Solo la primera zona, Meadow, es un catálogo de 49 filas, y el juego completo ya suma cientos de gemas en nueve islas del mundo exterior más el mundo del Infierno. Mantener cada número en configuración hace que una escala de rareza de ese tamaño sea algo que se puede equilibrar con un pase estilo hoja de cálculo, no algo que requiera cambiar una línea de código por cada gema.
Una wiki que solo puede mostrar lo que está en vivo
La wiki de
jugadores se genera directamente desde la configuración del propio juego, así que gemas, zonas,
mascotas, palas y códigos en la wiki coinciden exactamente con el juego, sin nada que sincronizar a mano. El
build lee la etiqueta de git live-v<version> más reciente, así que nada de lo que aún no
se haya publicado en Roblox puede aparecer en la wiki, aunque ya exista en el código. La trampa de ese
diseño: la herramienta que publica una nueva versión del lugar no crea esa etiqueta por sí sola, así que una
tanda de actualizaciones salió sin etiquetar y la wiki se quedó silenciosamente varias versiones atrás hasta
que se añadió la etiqueta a mano y se redesplegó el sitio. Ahora cada publicación va seguida de una etiqueta
y luego un redespliegue.
Lanzamientos en oleadas, como versiones del lugar
Las actualizaciones salen como versiones numeradas del lugar en Roblox, cada una un lote pequeño y con nombre de cambios en lugar de un único lanzamiento grande. Un pase de calidad de vida, un sistema de jefes y reliquias, una tanda de islas del Infierno: cada una llega como su propia versión, etiquetada y revisada antes de que empiece la siguiente. Eso mantiene cada cambio rastreable exactamente a lo que se publicó y cuándo, y permite ubicar un bug en la versión que lo introdujo.
Bugs que solo aparecen en vivo
Compilar limpio y pasar todas las pruebas fuera de línea no dice nada sobre cómo se ve realmente el juego una vez en marcha. Algunos bugs solo aparecieron al abrir Studio y jugar de verdad:
- Iluminación heredada. Un build se publicó sin fijar
Lighting.Technology, así que cargó con el renderizador Legacy antiguo, que nunca renderiza Atmosphere. La configuración de neblina de cada zona se ignoraba silenciosamente, y solo se hizo visible cuando alguien miró el mundo en Studio. - Una condición de carrera en el spawn detectada tras publicar. Un script aparte construía el escenario del mundo en paralelo con el script que colocaba los spawns de gemas, y a veces los spawners se ejecutaban primero. Una revisión en vivo tras publicar encontró 18 de 50 objetos recogibles metidos dentro de colinas y rocas. La solución fue construir el escenario justo después del propio mundo, en un orden fijo, y la siguiente versión lo confirmó.
- Un toque de mejora que parecía lag. Los jugadores reportaron que el botón de la tienda se retrasaba al mejorar rápido. El limitador de solicitudes de la tienda descartaba silenciosamente las solicitudes en cuanto un jugador tocaba más rápido de lo que su presupuesto permitía, así que el botón simplemente se quedaba quieto unos segundos. Subir el presupuesto de solicitudes arregló lo que parecía lag pero en realidad era un limitador sin retroalimentación.
Cómo está construido
Lo construyo en solitario, en Claude Code con subagentes haciendo el trabajo de implementación en paralelo mientras yo reviso y dirijo. Eso mantiene en movimiento un catálogo grande y un conjunto amplio de funciones sin que cada cambio pase por una única cola lineal.