En esta página
Quería que un comerciante de Shopify pudiera acompañar un pedido por un almacén, ver qué ocurre cuando cambia y llevarse algo útil para su tienda. Eso se convirtió en Warehouse Rush, nuestro juego gratuito para navegador, disponible solo en inglés.
Recoges productos, montas kits, empaquetas paquetes, cargas furgonetas e inviertes el dinero que consigues. Maple Depot crece hasta convertirse en Riverside Warehouse y Aurora Fulfillment. El juego incluye The Nine-Figure Upsell Playbook, una guía práctica para elegir y probar una oferta.
Si quieres crear un juego 3D para navegador con agentes de programación de IA, este es nuestro registro de desarrollo. Abarca Three.js, Codex, Claude, Higgsfield y ElevenLabs, incluidas las partes que cambiaron durante el desarrollo.
La imagen anterior es una ilustración promocional principal. Las capturas del almacén que aparecen a continuación muestran el mundo jugable.
Por qué una app de Shopify creó un juego de almacén
Quería un recurso de captación cuya actividad explicase el flujo del pedido y cuya recompensa ayudase al comerciante a aplicarlo.
Revize permite a los clientes editar pedidos aptos de Shopify antes de la preparación. La pregunta operativa interesante es qué ocurre entre el cambio de un pedido por parte del cliente y su envío por el almacén. Nuestra guía sobre un pedido cuya extracción de productos por el 3PL ya está en curso explica la coordinación en el mundo real.
El juego hace visible una versión más pequeña. Los productos pertenecen a pedidos concretos. Los pedidos modificados necesitan una corrección y una etiqueta actual antes del despacho. El empaquetado, las existencias y la entrega son acciones conectadas.
El manual aporta el trabajo del comerciante después de esa ilustración. Su portada dice “Elegir / Crear / Verificar / Decidir” y “Lecciones prácticas de nuestro trabajo con marcas de nueve cifras”. En 16 páginas, sus seis misiones abarcan elegir una combinación útil, crear y colocar la oferta, hacer que prevalezca la oferta prevista, verificar el pago, diagnosticar el resultado y decidir a partir de tu propia ficha de resultados.
Entra en el juego con tu correo electrónico y la URL de tu tienda. El primer paquete enviado te da acceso al manual de upsell. Es una introducción jugable al tema; no tenemos resultados medidos de formación laboral que comunicar.
La tecnología y la separación que importa
Three.js dibuja el almacén, TypeScript contiene sus reglas y Vite empaqueta el proyecto independiente para navegador.
El juego tiene su propio código fuente, archivo de bloqueo de dependencias, pruebas y recursos, separados del proyecto Astro del sitio web. Vite produce el paquete para navegador con rutas relativas de recursos, de acuerdo con su flujo de compilación estática para producción.
La división principal está entre la simulación y su presentación:
tycoon-model.tsse encarga de los pedidos, las cantidades, la pertenencia de los paquetes, las revisiones, los trabajadores, el dinero y la validación del guardado.tycoon-world.tsdibuja ese estado y gestiona los recursos visuales de la escena.tycoon-entry.tsconecta la entrada, los menús, el guardado, el audio y el bucle de fotogramas.
Un callback de animación nunca concede existencias ni dinero. Una libreta que vuela es una señal visual de un cambio del modelo. Mantener esa distinción permite diferenciar un efecto visual que no se muestra de un artículo perdido.
La cámara de juego es una THREE.PerspectiveCamera, la cámara en perspectiva de Three.js; la cámara ortográfica del renderizador se usa solo para las sombras del sol.
Rapier aparece en el historial de licencias del proyecto de origen. El modo de gestión activo no lo importa; la colisión, la navegación y el movimiento acotado de los objetos se implementan directamente.
Qué creamos con código y qué generamos
El almacén y los personajes animados están creados con código, mientras que algunas imágenes, un modelo de cinta transportadora, el vídeo del portal y los efectos de sonido proceden de herramientas de generación.
La distinción importa cuando alguien pregunta cómo se hizo el juego. Un retrato, una estructura de animación de personaje y un vídeo son entregables distintos con trabajos de integración distintos.
| Parte | Fuente documentada | Trabajo que sigue correspondiendo al juego |
|---|---|---|
| Almacén, productos y personajes activos | Geometría original de Three.js, con texturas Canvas dibujadas localmente | Distribución, movimiento, transporte de objetos, maquinaria y animación según el estado |
| Póster original y conjunto portrait-v2 | image_gen integrado / generación de imágenes de OpenAI, registrado en ASSETS.md |
Preparación de recursos y colocación en la interfaz |
| Cinta transportadora de despacho | Escena Higgsfield 3D Jutsu del propietario, exportada como GLB | Integración como objeto estático; los paquetes y las interacciones siguen bajo el control del juego |
| Suelo de hormigón anterior | Conjunto de texturas PBR de Higgsfield del propietario | Recurso histórico; los tratamientos posteriores del suelo están creados con código |
| Portal | Recursos de Higgsfield de la cuenta del propietario y clips de Kling 3.0 | Sustitución de la portada, edición de bucles, codificación y sincronización de la entrada |
| Banco de muestras de sonido del juego | eleven_text_to_sound_v2 de ElevenLabs |
Carga, mezcla, conexión de eventos y alternativas sintetizadas |
El historial de recursos incluye un conjunto intermedio de personajes ilustrados. Claude Opus creó un atlas Canvas2D y una animación de recortes; Codex los integró. La documentación actual de entrega indica que esas capas planas se han eliminado desde entonces y que los personajes activos usan geometría de Three.js. El atlas forma parte del historial de desarrollo, no del renderizador de personajes actual.
Las ilustraciones principales actuales en formato horizontal y vertical se generaron el 24 de octubre de 2026 con Codex gpt-6-astra, usando su herramienta integrada de generación de imágenes de OpenAI, con el render del juego “Cozy Soft”, propio y aprobado, como referencia de estilo y retratos v2 propios de los personajes como referencia de identidad. Los archivos distribuidos son codificaciones WebP y los prompts se conservan en art-src/menu-v3/jobs.tsv. El retrato siguiente pertenece al conjunto v2 generado y documentado.
Cómo usé Codex y Claude sin perder el historial de desarrollo
El flujo útil con agentes asignaba trabajo concreto y permitía atribuir la dirección, la implementación y la verificación.
Los registros respaldan créditos específicos. ASSETS.md atribuye a Astra y Claude Opus la dirección editorial de los manuales prácticos. Sol implementó su contenido, el renderizador compartido y la presentación en el menú del juego. El historial de personajes ilustrados nombra a Claude Opus como autor y a Codex como integrador. El registro también recoge cómo Claude Opus refinó esos personajes tomando como referencia mi ilustración principal del almacén.
La verificación de la expansión registra un cierre posterior de Opus tras las correcciones aprobadas. Estas entradas describen contribuciones reales; no demuestran que un agente crease o revisase cada parte del juego.
Mi proceso reutilizable a partir de esos registros es:
- Define el comportamiento y quién controla su estado antes de pedir trabajo visual.
- Asigna a la tarea de implementación un módulo o recurso concreto y una condición de aceptación visible.
- Revisa la integración, incluidos los guardados antiguos, la liberación de recursos y las rutas de fallo.
- Conserva pruebas de la versión resultante. Marca un experimento anterior como histórico cuando se sustituya.
Ese último paso detectó aquí un desfase real de la documentación: una técnica antigua de personajes puede seguir documentada después de que cambie el renderizador. El relato del desarrollo necesita el mismo cuidado que una entrega.
Los medios generados siguieron necesitando edición y diseño de ejecución
La generación aportó el material de origen; el posprocesamiento y la conexión de eventos lo hicieron utilizable en el navegador.
La exportación de la cinta transportadora de Higgsfield elimina de la escena activa los paquetes de muestra, las cámaras y las luces. De lo contrario, un modelo de presentación podría duplicar los paquetes del juego o aportar su propia iluminación. La cinta sigue siendo un recurso estático mientras la simulación controla los productos en movimiento.
El portal requirió otro tipo de limpieza. Su flujo registrado usa vídeo de Higgsfield/Kling, proyecta la portada real del manual en las imágenes y crea bucles de movimiento hacia delante. También mantiene fija la arquitectura pintada fuera de la abertura en movimiento para eliminar las fluctuaciones de textura. Los fotogramas de portada y las codificaciones finales reciben comprobaciones independientes.
La entrada también tiene un contrato funcional. Tanto la aceptación del registro de contacto como la preparación del juego deben completarse correctamente. El portal se desvanece solo después de que el juego activo confirme un fotograma renderizado. Que termine una cinemática no demuestra que el almacén esté listo para recibir controles.
Para el sonido, la documentación de entrega activa registra 23 efectos distribuidos de ElevenLabs generados con eleven_text_to_sound_v2. ElevenLabs documenta los efectos generados a partir de texto para juegos y medios interactivos. Nuestras muestras cubren acciones como recoger, cerrar paquetes, la salida de furgonetas y la finalización de mejoras.
Una entrada anterior del registro indica 24 efectos generados. La documentación de entrega explica el número distribuido: ui-tap se generó pero se omitió porque no había un punto central de conexión para los clics de botones.
El navegador carga y decodifica el banco de muestras después de un gesto que desbloquea el audio. Los eventos llaman a las muestras; las muestras no disponibles usan alternativas sintetizadas. No se necesita ninguna llamada a la API de ElevenLabs ni clave durante la ejecución. La música y los pequeños sonidos de materiales se sintetizan con código, con controles de música y efectos guardados por separado.
El trabajo de rendimiento empezó por la disposición y la carga
Eliminar el trabajo repetido de cálculo de disposición del navegador y reducir los bytes de recursos necesarios también fue importante, junto con el presupuesto de la escena 3D.
El informe registrado docs/perf-report.md identifica una medición repetida del canvas dentro del posicionamiento de los botones de puestos. Las lecturas de getBoundingClientRect() seguían a escrituras de estilos durante el fotograma. Guardar en caché el rectángulo del canvas e invalidarlo al cambiar el tamaño eliminó ese trabajo repetido de disposición.
Ese informe también registra calidad adaptativa, descargas paralelas de recursos y objetos estáticos combinados. Los niveles de calidad reducen la proporción de píxeles y después las sombras y partículas cuando el tiempo por fotograma sigue superando el presupuesto.
Como referencia de escala, la compilación de prueba del informe enumera un paquete JavaScript de 1.072 KB, o 308 KB comprimido con gzip. Su celda de Maple inicial con un área de visualización de teléfono registra 59 llamadas de dibujo, incluida la pasada de sombras. Son mediciones históricas de Chrome sin interfaz gráfica en Apple Silicon, con muestras de 20 segundos. No son una auditoría reciente de la compilación de lanzamiento ni mediciones en un teléfono físico.
La cinta transportadora cambió después de ese informe. ASSETS.md registra una compresión meshopt de 641.960 a 51.044 bytes, sin simplificación de geometría ni texturas. El cargador registra el MeshoptDecoder de Three.js para el GLB comprimido. El tamaño de la cinta sin comprimir del informe antiguo no debe presentarse como actual.
Mantendría ambas comprobaciones en una futura compilación: qué envía la escena para dibujar cada fotograma y qué debe descargar el navegador antes del primer fotograma jugable.
Las pruebas siguieron el paquete por todo el recorrido
Las pruebas del modelo comprobaron la pertenencia y la contabilidad, mientras que las comprobaciones en navegador abarcaron el recorrido renderizado y los controles.
La batería de pruebas de Node abarca la simulación, la lección guiada, las recompensas, el estado guardado y el comportamiento del controlador. El verificador de recorridos más largos sigue rutas reales del modelo, consigue mejoras y termina el trabajo aceptado antes de cambiar de almacén. Comprueba las existencias, el dinero y el guardado y recarga en puntos de control.
La verificación de la expansión registra una campaña completada de 48 envíos y ejecuciones de continuación que alcanzan 300 entregas totales en rutas de Riverside y Aurora. Son ejecuciones de verificación de corrección, no cifras de jugadores ni pruebas de que un principiante complete el capítulo cómodamente.
La verificación en navegador añade lo que un recorrido del modelo no puede mostrar: si cabe la hoja de pedido, si se puede desplazar un diálogo, si un control sigue siendo accesible y si el portal revela un fotograma real. Las comprobaciones registradas de Chrome usan áreas de visualización de escritorio y de tamaño de teléfono, incluidos los casos de movimiento reducido y de fallo.
Como caso de prueba ilustrativo, imagina una tienda de regalos que envía dos tazas y una libreta. Cambia el requisito de la libreta después de la extracción de productos. La aserción útil es que el paquete final coincida con el pedido y la etiqueta actuales, mientras los productos no afectados siguen contabilizados. Una animación correcta por sí sola no puede demostrarlo.
El montaje también hace visible esa distinción. La captura muestra el minijuego del conjunto de regalo con oso de peluche; su presentación sigue teniendo que coincidir con el contenido subyacente del paquete.
Decisiones humanas y qué haría de otra manera
Conciliaría la documentación antes y daría prioridad a las pruebas en dispositivos físicos frente a más decoración.
Los registros de desarrollo contienen decisiones humanas que un resultado generado no puede resolver. Aporté ilustraciones de referencia propias. La revisión del portal rechazó una ampliación de resolución con defectos en las letras y los bordes. El proceso de medios comprueba la legibilidad de la portada y el movimiento, además de las medidas de los archivos. Son decisiones de aceptación, no consecuencias de una exportación correcta.
La documentación de entrega actual también mantiene abiertos límites concretos. Al caminar manualmente se puede atravesar parte de un camión aparcado en el borde ampliado de despacho, aunque las entregas con rutas siguen funcionando. Un problema comunicado de lentitud y fallos visuales en teléfono carece de los detalles del dispositivo necesarios para reproducirlo. Las comprobaciones con un área de visualización de escritorio no resuelven ni el rendimiento en dispositivos ni ese informe.
El progreso es local al navegador. No hay sincronización de guardados en la nube ni multijugador. Las ofertas de socios siguen pendientes. Esos límites deben formar parte del relato del desarrollo junto a las pantallas terminadas.
Para los comerciantes, el juego es una ilustración. Usa la guía de ubicaciones de upsell poscompra para el flujo comercial; las funciones de upsell de Revize requieren Pro. Verifica el recorrido de tu propia oferta en un pedido de prueba.
Qué hacer esta semana
Crea y verifica un ciclo completo de pedido antes de ampliar el almacén o encargar más recursos.
- Escribe quién controla el estado del pedido, las existencias, el paquete y la recompensa.
- Haz que la extracción de productos, el empaquetado y el despacho funcionen en un recorrido visible.
- Registra la fuente, el procesamiento y el uso actual de cada recurso generado.
- Comprueba una recarga, una carga fallida y el movimiento reducido, y prueba después en un teléfono físico.
Juega a Warehouse Rush para inspeccionar nuestro resultado. Entra con tu correo electrónico y la URL de tu tienda, envía tu primer paquete y consigue The Nine-Figure Upsell Playbook. Sus seis misiones convierten la tarea del comerciante en una oferta con nombre, un recorrido de pago probado y una decisión basada en tus propias adiciones que se mantienen y tus costes.
Preguntas frecuentes
Estas respuestas distinguen el juego distribuido de los experimentos anteriores y las condiciones de prueba registradas.
¿Puedo crear un juego 3D para navegador con agentes de programación de IA?
Sí, pero la implementación sigue necesitando reglas explícitas, trabajo de integración y verificación. Warehouse Rush separa la simulación de su renderizador, usa agentes para tareas documentadas y comprueba recorridos completos. El arte generado no demuestra que las existencias, la pertenencia de los paquetes o el progreso guardado se comporten correctamente.
¿Todo el material gráfico de Warehouse Rush se generó con IA?
No, el almacén activo y los personajes animados son trabajo de Three.js creado con código. El registro recoge por separado recursos generados de pósteres y retratos, una cinta de Higgsfield y medios del portal. Un atlas anterior de personajes Canvas también se creó con código. Distingue ese historial del renderizador activo.
¿Usa Warehouse Rush la física de Rapier?
El modo de gestión activo no importa Rapier. Aparece en el historial del proyecto de origen y en los registros de licencias. La colisión, la navegación y el movimiento visual acotado actuales se implementan directamente, así que conservar un aviso de licencia no demuestra una dependencia activa de física.
¿Cómo usasteis los efectos de sonido de ElevenLabs para el juego?
Generamos efectos fuera de la compilación para navegador y conectamos las muestras distribuidas a eventos del juego. La documentación de entrega registra 23 efectos con eleven_text_to_sound_v2. La reproducción sigue las preferencias de efectos y usa alternativas sintetizadas cuando las muestras no están disponibles. El navegador no llama a la API de generación.
¿Vuestras pruebas de rendimiento demuestran que funciona bien en mi teléfono?
No, Chrome de escritorio con un área de visualización del tamaño de un teléfono no demuestra el rendimiento en un teléfono físico. El informe de rendimiento identifica el equipo, las condiciones de muestreo y los límites pendientes. Prueba el juego en tu dispositivo real; el informe de teléfono sin resolver sigue necesitando un caso reproducible con dispositivo y navegador.
¿Cómo consigo The Nine-Figure Upsell Playbook?
Entra en Warehouse Rush con tu correo electrónico y la URL de tu tienda y envía después el primer paquete para conseguir el manual. La guía tiene 16 páginas y seis misiones. Lleva una oferta por el encaje del producto, la ubicación, la prioridad, las comprobaciones de pago, el diagnóstico y una decisión basada en la ficha de resultados.