Diseña un ciclo de ecosistema ficticio que se pueda revisar

Empieza con un ciclo de hábitat interconectado

Un prompt de simulación de ecosistemas necesita más que una lista de animales y plantas. Debe incluir una variable del hábitat que el jugador pueda cambiar, una cadena breve de respuestas, un orden fijo para actualizarlas y una condición que indique si el hábitat se mantiene. Define ese ciclo antes de pedir un mundo más amplio.

Mireglass Fen es un ejemplo de juego ficticio creado para esta guía. Moonreed, Glimmerwings y Glassbacks, sus relaciones y todas las cifras son reglas de diseño inventadas. No son especies reales ni consejos ecológicos. Los prompts son plantillas para probar; aquí no se muestra su ejecución, un juego jugable ni una prueba. El ejemplo de v0 a v1 es un cálculo manual, claramente identificado como simulación.

El jugador gestiona una compuerta en un pequeño pantano. Subir, bajar o mantener el nivel del agua modifica primero Moonreed; la cantidad de plantas afecta después a Glimmerwings, cuya población influye a su vez en Glassbacks. No se trata de equilibrar un ecosistema real, sino de hacer que un ciclo de juego ficticio sea lo bastante predecible como para revisarlo.

Define el estado del hábitat ficticio

Mantén pequeña la primera versión: un nivel de agua, tres contadores de población y un objetivo de cuatro turnos. Limita cada valor para evitar que la solicitud genere un crecimiento descontrolado.

El objetivo es mantener las tres poblaciones en 2 o más durante dos turnos seguidos, dentro de un máximo de cuatro. Es una condición de victoria inventada, no una afirmación sobre la salud de un pantano. Los límites, el tope de turnos y la racha dan al prompt un final comprobable en vez de una indicación abierta como «haz prosperar el ecosistema».

Pide primero el contrato de reglas

Antes de crear la escena, pide al generador que reformule las transiciones sin añadir especies ni sistemas. Así se distingue una regla incompleta de una escena que aún no está terminada.

Trata Mireglass Fen como un ecosistema de juego inventado, no como un modelo de un humedal real. Convierte las reglas en una tabla de estados compacta y en un orden de turnos determinista. Conserva solo T, R, G, F y la racha de estabilidad; no añadas especies, estaciones, cadenas alimentarias, eventos ni afirmaciones ecológicas. Define cada límite y umbral. Calcula a mano el estado T=2, R=2, G=2, F=1 con la acción mantener, usando F0, el valor de inicio del turno, para la presión sobre Glimmerwings. Devuelve el estado esperado y señala cualquier ambigüedad antes de proponer una versión jugable. Etiqueta esto como análisis de reglas, no como prueba.

Comprueba que la respuesta use la cantidad inicial de Glassbacks para la presión sobre Glimmerwings y que actualice Glassbacks después. Si se añaden clima, migración, alimento u otros hábitats, elimínalos antes de seguir: cada añadido requeriría verificar otra transición.

Solicita una versión mínima del hábitat

Una vez cerradas las reglas, pide una sola pantalla y la interacción mínima que permita comprobarlas. Especifica controles, contadores, límite de turnos y reinicio. Indica qué sistemas deben quedar fuera para mantener acotada la primera solicitud.

Crea el concepto de un juego ficticio de gestión del ecosistema Mireglass Fen en una sola pantalla. En cada turno, el jugador puede subir, bajar o mantener una compuerta. Muestra el control del agua y contadores claros para Moonreed, Glimmerwings, Glassbacks y la racha de estabilidad de dos turnos. Aplica exactamente las reglas de actualización de cuatro turnos y su orden fijo; limita todos los valores de 0 a 5. Incluye un reinicio y una victoria clara cuando la racha llegue a 2. No añadas especies reales, explicaciones científicas, crecimiento de asentamientos, comercio, desbloqueos, recursos extra, clima ni eventos aleatorios. Permite inspeccionar el estado al principio y al final de cada turno para compararlo con las reglas.

Estas instrucciones describen una primera versión propuesta, no garantizan funciones. Cuando alguien la pruebe, conviene comprobar si subir la compuerta cambia primero solo el agua, si las poblaciones se actualizan después en el orden indicado y si la racha se reinicia cuando cualquier población termina por debajo de 2.

Comprueba a mano un turno del hábitat

Antes de pedir una versión, haz el cálculo en papel. Empieza enT=2, R=2, G=2, F=1, elige mantener y aplica las reglas en orden. La cantidad inicial de Glassbacks está por debajo del umbral de presión.

El estado se predice a partir de las reglas escritas; no demuestra que una implementación las cumpla. Mantener el agua en el turno siguiente produciríaT=2, R=4, G=3, F=3y una racha de 2, que alcanzaría el objetivo ficticio.

Revisa una discrepancia hipotética en las reglas

El primer borrador indica que Glassbacks responden a Glimmerwings y reducen su población, pero no aclara si esa presión usa la cantidad inicial de Glassbacks o la cantidad posterior a la actualización del turno. La omisión permite dos cálculos distintos:

La revisión simulada añade una línea: la presión sobre Glimmerwings usa el valor de inicio del turnoF0. Con esa regla, el estado esperado de v1 esT=2, R=3, G=3, F=2, racha 1.

Este recorrido de v0 a v1 es una simulación creada por la autora, no un prompt ejecutado, un juego creado, una prueba de juego ni un resultado medido. Si más adelante hay una versión real, se puede sustituir el estado hipotético por una acción y un resultado observados antes de pedir corregir una sola regla.

Es una ambigüedad hipotética de las reglas, no un resultado observado: desde T=2, R=2, G=2, F=1 con la acción mantener, una interpretación termina en T=2, R=3, G=3, F=2 y otra en T=2, R=3, G=2, F=2, porque el borrador no define qué cantidad de Glassbacks determina la presión sobre Glimmerwings. Haz un solo cambio: especifica que la presión usa F0, el valor al inicio del turno. Conserva las demás reglas y devuelve la transición y el estado esperado. No afirmes que se probó ni midió el cambio.

Lleva las reglas a un espacio de creación

Cuando el encargo esté listo, describe al público y el formato del juego, nombra la primera acción, define la escena y el estado y añade límites para mantener pequeña la primera versión. Después inspecciona el resultado real: ¿los contadores siguen el orden de transición? ¿La racha se reinicia según la condición indicada?

La página actual deCreador de juegos con IA gratuitode SEELE describe un flujo general: explicar una idea en inglés sencillo, revisar un resultado jugable en 2D o 3D, iterar en Workspace y comprobar el modelo seleccionado, el saldo disponible de Koin y el coste de generación antes de enviar. No documenta Mireglass Fen, el comportamiento de un ecosistema ni las reglas de este ejemplo. Usa los prompts como instrucciones iniciales y verifica el resultado por tu cuenta.

Preguntas frecuentes sobre prompts de simulación de ecosistemas

¿Cuántas especies debería incluir el primer prompt de ecosistema?

Empieza con el mínimo de contadores que permita mostrar una cadena de dependencias. Mireglass Fen utiliza tres poblaciones inventadas para representar un cambio del hábitat, una respuesta de crecimiento y una regla de presión. Añade otra población solo si permite una decisión que el ciclo actual no expresa.

¿Las especies de un juego de ecosistema deberían ser reales?

Podrían serlo, pero las afirmaciones sobre especies reales y sus relaciones necesitan fuentes fiables. Este ejemplo usa nombres y reglas inventados, así que no debe presentarse como orientación ecológica ni como modelo realista de un humedal. Si eliges especies reales, cita una fuente para cada relación y separa los hechos documentados de las reglas inventadas.

¿Qué debe especificar primero un prompt de simulación de ecosistema?

Nombra las variables del hábitat, los límites de población, la acción del jugador, el orden de transición y la condición de victoria. Después incluye un estado inicial exacto y pregunta cuál sería el estado tras un turno. Así es más fácil revisar el resultado que con un prompt basado solo en la ambientación.

¿Cómo resuelvo resultados de población contradictorios?

Busca la primera regla cuyo momento de aplicación sea ambiguo. Especifica si una interacción utiliza la cantidad al inicio del turno o después de actualizar otra población, modifica solo esa regla y vuelve a calcular el mismo estado. Antes de llamar «probada» a la corrección, compruébala por separado en una versión real.

¿Se probaron los prompts y el ejemplo simulado?

No. Los prompts son plantillas para probar y el recorrido de v0 a v1 se calculó a mano. No muestra una versión jugable, una prueba de juego ni un resultado medido. Compara tu resultado con el contrato de reglas antes de describir su comportamiento como verificado. Solo afirma que algo se observó tras registrar una acción y un resultado exactos en una implementación real.