Empieza con un ciclo funcional y haz que su progreso sea fiable
Un juego inactivo necesita algo más que un contador que crece mientras la página está abierta. Los jugadores esperan que las mejoras compradas sobrevivan a una recarga, que al regresar se conceda un progreso razonable y que las actualizaciones posteriores no borren su trabajo. Trata el guardado, la liquidación del tiempo sin conexión y la compatibilidad como comportamientos distintos con pruebas separadas.
Este flujo continúa un diseño ilustrativo de invernadero, no un proyecto ya generado o probado. Los clics otorgan monedas ficticias; cada jardinero comprado produce una moneda por segundo. El siguiente jardinero cuesta ceil(10 × 1.15^n), donde n es el número que ya se posee. Empieza con un ciclo de ganancias y compras funcional. Definirás un contrato de guardado, calcularás una recompensa de regreso con límite y conservarás el progreso tras un cambio posterior, sin confundir almacenamiento local con guardado en la nube.
Especifica lo que el juego debe recordar
Escribe el contrato de guardado antes de solicitar código. Una versión mínima incluye la versión del esquema, el saldo actual de monedas, el número de jardineros, las mejoras compradas y el momento hasta el que ya se han liquidado las ganancias. Mantén las reglas de producción junto a las definiciones de mejoras. Guarda las compras que sustentan el saldo mostrado, no copias contradictorias de estados derivados.
Durante el desarrollo, pide un resumen de guardado legible para comparar el estado del juego con el almacenado. Evita exponer información privada en la salida de diagnóstico. Distingue también un guardado local de uno asociado a una cuenta. El almacenamiento del navegador pertenece a un perfil y puede borrarse. No garantiza progreso entre dispositivos, saldos competitivos seguros ni recuperación después de que el jugador elimine los datos del sitio.
Usa esta solicitud acotada:
Añade un guardado local versionado para monedas, jardineros, mejoras compradas y última hora liquidada. Restaura el estado antes de mostrar una pantalla jugable. Valida los valores cargados. Si no existe un guardado, inicia una partida nueva. Si el guardado no es válido, explica cómo se recuperará en lugar de generar silenciosamente saldos imposibles. Mantén sin cambios el arte y las reglas de obtención existentes.
Guarda después de compras importantes y define un guardado periódico si el juego lo necesita. No dependas únicamente del evento de cierre de página: un navegador o dispositivo puede detenerse sin enviar el último evento esperado.
Calcula una sola vez las recompensas de ausencia, con un límite claro
El progreso sin conexión suele consistir en calcular una recompensa cuando el jugador regresa. No exige que el script del juego siga ejecutándose continuamente tras cerrar el navegador. Una regla transparente es:
recompensa = tasa de producción guardada elegible × min(max(hora de regreso − última hora liquidada, 0), ocho horas)
Decide antes de implementar qué significa la tasa elegible. En este diseño sencillo es la tasa de producción de los jardineros y mejoras guardados al salir. Deja las simulaciones complejas para después de que funcione la liquidación básica.
Como comprobación de valor esperado, dos jardineros que producen una moneda cada uno por segundo generarían 1.200 monedas durante un intervalo controlado de diez minutos. Diez horas de ausencia contarían solo como ocho con el límite del ejemplo. Usa el cálculo como valor esperado en el registro de ejecución.
Después de conceder el progreso, el juego debe actualizar el estado de liquidación para que una recarga no vuelva a premiar la misma ausencia. Solicita un mensaje de regreso que muestre la duración utilizada y la recompensa concedida. Describe la recompensa calculada sin dar a entender que existe un servidor funcionando continuamente.
Ejemplos resueltos: recompensas sin conexión
Estos ejemplos suponen una tasa de producción fija, monedas ficticias y un límite de dos horas cuando se indica. Describen cálculos esperados, no resultados medidos en un juego probado.
| Situación | Cálculo | Recompensa esperada |
|---|---|---|
| 1 jardinero, ausencia de 10 minutos | 1 moneda/segundo × 600 segundos | 600 monedas ficticias |
| 2 jardineros, ausencia de 30 minutos | 2 monedas/segundo × 1.800 segundos | 3.600 monedas ficticias |
| 1 jardinero, ausencia de 3 horas, límite de 2 horas | 1 moneda/segundo × min(10.800, 7.200) segundos | 7.200 monedas ficticias |
| Recargar inmediatamente tras la liquidación | El intervalo ya liquidado no vuelve a contarse. | 0 monedas adicionales por ese intervalo |
Prueba el guardado por separado de la liquidación del tiempo
Primero consigue un saldo conocido, compra un jardinero y recarga. Confirma que se conservan el saldo y la compra. Después cierra el navegador, espera un intervalo medido y regresa. Registra el estado inicial, el tiempo real transcurrido, la recompensa observada y el estado final. Recarga inmediatamente y comprueba que no se repita la misma recompensa.
Usa un reloj de prueba controlado para intervalos largos y una comprobación real de cierre y regreso para el caso normal. Prueba un intervalo transcurrido negativo, uno excesivamente grande, un guardado vacío y uno dañado. Explica cómo debe comportarse cada caso antes de observar el resultado. Un intervalo negativo no debe restar moneda ganada; uno grande no debe saltarse el límite.
El jugador puede cambiar la hora local del dispositivo. Limitar el tiempo transcurrido ayuda a prevenir errores evidentes, pero no convierte una economía local en una resistente a manipulaciones. Las economías competitivas o de pago necesitan un diseño independiente de liquidación autoritativa y seguridad.
Matriz de pruebas de regreso
| Acción | Comportamiento esperado | Si falla la comprobación |
|---|---|---|
| Comprar una mejora y recargar | El saldo guardado y la mejora comprada regresan juntos. | Inspecciona qué campos se guardaron y cuándo se realizó el guardado. |
| Regresar tras un intervalo medido | La recompensa sigue la tasa y el límite documentados. | Compara la marca de liquidación guardada, la tasa y el tiempo transcurrido. |
| Recargar inmediatamente tras la recompensa | El mismo intervalo no se recompensa dos veces. | Comprueba que la marca de liquidación avance junto con la recompensa. |
| Abrir otro navegador o dispositivo | El comportamiento coincide con el modelo de guardado local o por cuenta indicado. | Comprueba si existe un mecanismo de sincronización entre dispositivos. |
| Cargar un guardado antiguo tras cambiar una regla | Las compras y el saldo siguen la migración documentada. | Inspecciona la versión del guardado y la ruta de migración o recuperación. |
Añade una mejora posterior sin reiniciar al jugador
Cuando el guardado funcione, solicita un pequeño cambio de contenido:
Cambia el precio base de los jardineros de diez a ocho monedas para compras futuras, manteniendo el factor de crecimiento de 1,15. Conserva las monedas, jardineros, mejoras adquiridas, elementos visuales y liquidación sin conexión existentes. Admite la versión actual de los datos guardados. Muestra cómo se migra un guardado antiguo si el nuevo estado necesita campos adicionales.
Conserva un guardado real anterior al cambio y una versión funcional antes de hacer esta solicitud. Carga ese guardado en la versión revisada y compara el saldo, las compras y la tasa de producción resultantes. Añadir un campo no debería descartar todo el estado solo porque el guardado antiguo no lo contiene. Decide si las compras anteriores mantienen sus beneficios antes de cambiar la economía.
Si desaparecen mejoras, revisa la migración y la carga antes de añadir funciones. Un botón nuevo no demuestra compatibilidad de guardados.
Usa SEELE para cambios de persistencia acotados
SEELE ofrece un flujo basado en prompts para crear juegos y solicitar cambios posteriores. Aquí la entrada relevante es la economía funcional junto con un contrato de guardado específico; el resultado deseado es una revisión candidata cuyo comportamiento de carga y liquidación puedas inspeccionar. Pide el cambio de persistencia más pequeño antes de solicitar migraciones o mejoras nuevas.
Conserva una versión funcional y un guardado de referencia fuera de la modificación que evalúas. Cuando falle una prueba, comunica las diferencias exactas de estado e indica si ocurrieron al cargar, regresar o comprar. El posicionamiento del producto por sí solo no demuestra guardados en la nube, relojes seguros, garantías de migración ni la fiabilidad de una implementación concreta de almacenamiento local.
Continúa solo cuando el regreso tenga sentido
Un juego inactivo fiable debe explicar de dónde salen sus cifras: qué produjo la recompensa, qué intervalo de ausencia se contó y qué compras siguen siendo propiedad del jugador. Usa ayuda de IA para cambios acotados en esas reglas y evalúa cada cambio en el juego en ejecución. No sacrifiques un guardado funcional por una lista más larga de funciones.
Usa SEELE para solicitar un guardado local y una recompensa de regreso limitada en tu proyecto existente. Conserva una versión conocida y funcional antes de pedir otro cambio económico. El siguiente objetivo no es una promesa mayor, sino un regreso verificado que conserve el progreso anterior del jugador.
Preguntas frecuentes
¿El progreso sin conexión significa que el juego se ejecuta con el navegador cerrado?
No necesariamente. Un método habitual guarda el estado y la hora de liquidación, y calcula una recompensa en la siguiente visita. Esto permite diseñar recompensas sin conexión sin mantener un proceso de navegador en ejecución continua. Comprueba la implementación real antes de describirla. La simulación en servidor es otra arquitectura y no debe darse por supuesta a partir de una recompensa calculada localmente.
¿Un guardado del navegador se trasladará a otro dispositivo?
No lo des por hecho. El almacenamiento local del navegador normalmente está ligado al perfil y al almacenamiento de ese sitio. Los guardados entre dispositivos necesitan un sistema explícito de sincronización o cuentas, además de decisiones sobre conflictos y privacidad. Explica qué utiliza realmente la demostración probada en lugar de presentar un ejemplo de persistencia local como una función de guardado en la nube.
¿Puedo cambiar los precios de las mejoras cuando la gente ya ha jugado?
Sí, si el diseño revisado define cómo se tratarán las compras existentes y el estado guardado. Conserva un guardado de referencia, decide qué beneficios seguirán siendo del jugador y prueba la migración antes de publicar el cambio. Sobrescribir la lista de precios no demuestra por sí solo que el progreso anterior siga siendo válido. Si el comportamiento aún no se ha probado, descríbelo como requisito, no como una actualización exitosa.
