Elige una herramienta de creación de juegos por el juego que puedes jugar, los cambios que puedes hacer y el proyecto que puedes conservar, no solo por una captura de pantalla. Una comparación justa parte de un mismo encargo pequeño y comprueba las mismas reglas visibles para el jugador antes de juzgar la apariencia. También registra el trabajo manual, las restricciones del plan y el contenido real de una exportación. Esta prueba propuesta abarca SEELE AI, Rosebud AI, GDevelop y Buildbox, las cuatro herramientas nombradas en la comparación existente. Para este borrador no se contó con ejecuciones controladas ni inspecciones de exportación. Por tanto, los resultados y las recomendaciones siguen pendientes: no hay puntuaciones, diferencias de capacidad observadas ni ganador. Las siguientes secciones definen qué ejecutar y conservar para que una comparación posterior pueda responder con honestidad a la pregunta de cuál elegir.
El encargo común y los controles
Usa un navegador de escritorio, un tamaño de ventana fijo y el mismo dispositivo de entrada en cada ejecución. Declara el plan permitido, el límite de gasto, el límite de intervenciones y la condición de parada antes de abrir una herramienta. Registra el nivel de cuenta, la fecha, la versión visible y los costes reales. No supongas que el mismo número de prompts implica el mismo esfuerzo cuando un flujo requiere edición visual.
Crea Lantern Delivery, un juego 2D de navegador, en una sola pantalla y con vista cenital. Usa un mensajero original y escenarios originales sencillos. Muévete con WASD o las flechas. Recoge cinco faroles mientras evitas un peligro móvil. Muestra la cantidad recogida y un temporizador de 45 segundos. El contacto con el peligro o el tiempo agotado termina el intento. Recoger los cinco da la victoria. Incluye instrucciones visibles y Reiniciar. Mantén el mismo mensajero y dirección artística en todo el juego. No uses personajes con licencia ni arte descargado protegido por derechos de autor.Trátalo como una especificación, no como un resultado generado. Para la prueba, inicia el temporizador con el primer movimiento, bloquea la entrada tras cualquiera de los dos finales y restaura todo el estado al reiniciar. Si una interfaz no acepta el encargo directamente, documenta cómo se implementa en su flujo nativo. No concedas silenciosamente preparación adicional a un candidato ni sustituyas el encargo por una plantilla más completa.
Los registros de los cuatro candidatos que hay que completar
SEELE AI: verificar la entrega tras el prompt
SEELE describe la creación en lenguaje natural de escenas, recursos y código de juego. Para esta comparación, la pregunta relevante es si ese flujo produce el ciclo especificado de Lantern Delivery y permite el cambio controlado en el mismo proyecto. Proporciona el encargo sin cambios mediante el flujo de creación disponible y conserva la solicitud original, el historial de respuestas, la primera versión accesible y las condiciones de la cuenta.
No deduzcas acceso al código fuente, compatibilidad con motores ni un inicio local satisfactorio a partir del posicionamiento del producto. Inspecciona la entrega real y registra su formato. Si hacen falta aclaraciones o reparaciones adicionales, cuéntalas y consérvalas antes de pasar a la edición del escudo. Una recomendación útil posterior relacionaría la jugabilidad observada, el esfuerzo de revisión y la reproducibilidad con las necesidades del lector. Por ahora no existen esas observaciones, así que este candidato no tiene puntuación ni ventaja asignada.
Rosebud AI: registrar la ruta real de creación y revisión
Ejecuta el encargo común con el flujo disponible en la cuenta de Rosebud AI utilizada. Registra el formato de entrada inicial, la preparación necesaria y cada intervención requerida para obtener una versión accesible. Consulta la documentación oficial vigente sobre las condiciones del plan, pero separa las afirmaciones documentadas de lo que observa la persona evaluadora. Este borrador no establece qué funciones actuales ni formatos de exportación están disponibles.
Cuando se pueda jugar una versión de referencia, consérvala antes de enviar la misma solicitud del escudo. Registra si la revisión modifica el proyecto existente y si se mantienen el mensajero, las reglas y el mapa. Para la entrega, inspecciona el artefacto que el flujo probado proporcione realmente; no llames «código fuente» a un enlace alojado. La falta de acceso en una cuenta es una observación específica del plan, no una prueba de que el producto nunca ofrezca una capacidad. Para este artículo no se ha ejecutado ninguna generación, revisión o exportación de Rosebud.
GDevelop: hacer visible el trabajo en el editor
Evalúa el flujo actual de GDevelop tal como se presenta a la persona que lo prueba, no como una supuesta copia de un generador conversacional. Registra la construcción de escenas, la edición de eventos, la preparación de recursos o la selección de plantillas necesarias para implementar el encargo. Si el flujo ofrece creación asistida, conserva sus entradas y salidas junto con las acciones manuales. Este artículo no ha verificado esas opciones actuales ni las condiciones de sus planes.
Una estructura de eventos editable puede ser la entrega pertinente para quien usa un editor visual; no debe descartarse solo por diferir de una carpeta de scripts escritos a mano. A la inversa, un proyecto de editor por sí solo no demuestra que funcione una versión compartida en el navegador. Registra por separado la versión de referencia, el cambio controlado de eventos o proyecto, las comprobaciones jugables y el contenido real de la exportación. La comparación posterior debe mostrar el esfuerzo y el resultado de este flujo, sin penalizarlo ni premiarlo por la etiqueta «sin código». Aquí no hay resultados de pruebas de GDevelop.
Buildbox: distinguir la edición del proyecto del resultado publicado
Usa el flujo real de la cuenta de Buildbox probada para implementar Lantern Delivery y documenta la preparación necesaria y cualquier comportamiento procedente de una plantilla. Verifica la documentación actual y las condiciones de la cuenta antes de describir las opciones de publicación o exportación. No supongas que se aplican aquí la interfaz de prompts, organización de archivos o instrucciones de ejecución local de otra herramienta. Conserva la primera revisión del proyecto que pueda evaluarse, incluida la preparación manual.
Para el cambio del escudo, registra la lógica editable o las diferencias del proyecto que implementan la protección, junto con pruebas de que las reglas iniciales permanecen intactas. Identifica con precisión la entrega: proyecto de editor, versión alojada, artefacto compilado o archivos fuente, según lo que se proporcione realmente. Si no se puede acceder a un destino o exportación, indica el plan probado y la restricción exacta observada. Así, otro lector podrá valorar el flujo según sus necesidades. Por ahora no se ha inspeccionado ninguna versión, revisión ni entrega de Buildbox, y no se justifica un veredicto sobre sus capacidades.
Realizar las mismas comprobaciones de juego, edición y entrega
Primero prueba las instrucciones, ambos sistemas de movimiento, la recogida única, el contacto con el peligro, la victoria al reunir cinco faroles, el tiempo agotado y el reinicio tras cada final. Repite tras una carga nueva. Marca cada comprobación como aprobada, fallida o no probada y adjunta la revisión de la versión. Conserva una grabación ininterrumpida que incluya los fallos. Una respuesta de página o una escena atractiva no equivalen a una comprobación completa del ciclo de juego.
Después aplica un cambio controlado: añade un escudo que se recoja, absorba exactamente un contacto con el peligro y desaparezca al ser recogido. Muestra si la protección está activa. Conserva el arte del mensajero, mapa, controles, número de faroles, temporizador y reinicio. Especifica que no aparece un segundo escudo antes del reinicio. Prueba la recogida, el primer contacto protegido, el siguiente contacto sin protección, el tiempo agotado con protección activa y la restauración al reiniciar. Repite todas las comprobaciones iniciales. Guarda la diferencia entre revisiones en formato nativo, ya sea código, eventos u otro artefacto de proyecto inspeccionable.
Por último, distingue entre enlace jugable, versión compilada, proyecto editable y código fuente legible por personas. Guarda e inspecciona la exportación proporcionada. Ábrela o ejecútala con las herramientas documentadas en una carpeta limpia y registra comandos reales, versiones, recursos ausentes y correcciones manuales. Una descarga satisfactoria por sí sola no demuestra que el proyecto sea reproducible. Conserva la documentación vigente junto a la observación sin sustituir la prueba por ella.
Compara elementos equivalentes: primer resultado accesible con primer resultado accesible, y resultado reparado con resultado reparado, declarando las intervenciones. Una persona principiante puede priorizar iteraciones comprensibles y un ciclo funcional; una desarrolladora puede priorizar código fuente reproducible; quien usa un editor puede preferir eventos inspeccionables. Expón esas compensaciones solo cuando existan los artefactos. Las cifras de tiempo y créditos necesitan reglas registradas de inicio y fin, no estimaciones hechas tras ver el resultado. Una sola ejecución puede sustentar una comparación limitada de casos, no una afirmación general de fiabilidad.
Lista de pruebas: ninguna celda de resultados está completa
- Por candidato: nivel de cuenta, fecha de prueba, versión visible, navegador, presupuesto e historial real de intervenciones.
- Encargo original, proyecto o versión de referencia y grabación completa de las comprobaciones de aceptación.
- Solicitud exacta del escudo, revisiones anteriores y posteriores, cambio inspeccionable y observaciones de regresión.
- Artefacto real de exportación o entrega, registro de instalación en un entorno limpio y resultado de inicio observado.
- Documentación oficial actual que respalde cualquier afirmación sobre planes o formatos.
- Conclusiones por herramienta y recomendaciones condicionadas redactadas solo después de estas comprobaciones.
Las cuatro pruebas de candidatos siguen sin realizarse para este artículo. La lista es un plan de recopilación, no una tabla de resultados. No hay clasificación probada, herramienta más rápida, juego completado más barato ni ganador de exportación verificado que comunicar.
Conclusión: aplazar la recomendación hasta contar con pruebas
La comparación útil no consiste en qué herramienta suena más completa, sino en qué flujo probado se ajusta al proyecto que quieres continuar. Conserva el encargo común, declara la ayuda recibida y separa el comportamiento jugable de la entrega que puedes inspeccionar. Este borrador no puede elegir un ganador: faltan las cuatro ejecuciones controladas, revisiones y exportaciones. Una vez autorizados el acceso y cualquier presupuesto necesario, utiliza el encargo común de Lantern Delivery en SEELE y repítelo sin cambios en los demás candidatos. Conserva los fallos y restricciones en el registro. Solo entonces reduce las opciones según la jugabilidad observada, el esfuerzo de edición y el acceso al proyecto, no según una clasificación supuesta.
Ficha de comparación: registra tus propias pruebas
Esta tabla organiza las comprobaciones propuestas en el artículo. No es un informe de una prueba completada.
| Evaluación | Aplicar la misma comprobación a cada candidato | Registrar |
|---|---|---|
| Resultado jugable | Ejecutar el encargo común y comprobar las reglas visibles para el jugador. | Qué funcionó, qué falló y las pruebas de cada ejecución. |
| Esfuerzo y coste | Registrar el plan, gasto real, prompts y ediciones manuales. | Nivel de cuenta, fecha, coste, intervenciones y esfuerzo en tiempo. |
| Revisión | Solicitar el mismo cambio limitado y repetir la prueba inicial. | Instrucciones del cambio y resultados antes y después. |
| Entrega | Inspeccionar lo que está disponible realmente tras exportar o recibir el proyecto. | Archivos, posibilidad de edición, dependencias y condiciones aplicables. |
| Decisión | Comparar las pruebas registradas con tus prioridades. | Indicar comprobaciones pendientes en lugar de asignar un ganador sin fundamento. |
Preguntas frecuentes
¿Un botón de exportación significa que recibiré código fuente editable?
No. La exportación puede ser una versión compilada o un proyecto destinado a un editor concreto. Descarga e inspecciona el artefacto real y después ábrelo o ejecútalo con las herramientas documentadas. Registra el plan y el formato probados para no confundir una observación limitada a una cuenta con una capacidad universal del producto.
¿Puede la documentación oficial sustituir una comparación práctica?
No. La documentación puede respaldar una afirmación sobre una función o plan actuales, pero no demuestra que este juego concreto funcionara correctamente o resistiera el cambio del escudo. Guarda la documentación y los resultados observados en notas separadas. Marca como no probado un escenario que no se haya ejecutado en lugar de tomar confianza de un ejemplo promocional o una lista de funciones.
¿Debe recibir cada candidato exactamente el mismo número de prompts?
Usa el mismo encargo inicial y la misma especificación de cambio, pero declara toda la ayuda adicional y el trabajo manual. Las interfaces pueden requerir acciones distintas, así que el número de prompts por sí solo no mide justamente el esfuerzo. Establece de antemano los límites de intervención y presupuesto y conserva el historial, en lugar de ajustar las reglas tras ver los resultados.
