.
si el planteamiento es una aplicación nativa, lo que no se puede hacer es descargar código que no haya sido validado por la store antes, esto implica que la lógica del juego debe estar ya añadida y sólo se podrían descargar las reglas y los assets, cosa muy común en un lenguaje como LUA, donde se envía constantemente "código" desde el backend al frontend.
un engine ya escrito en lua es defold
más info de Android. policy
An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).
iOS es aún más restrictivo
No sé si he entendido, ando con algo de migraña. Pero sin salir de JS, un contenedor en Electron y dentro vais cargando los mini-juegos?
#5 Es que estoy en la parra, si lo queréis para Andrid / iOS no os sirve Electron xD
Pero creo que lo suyo va a ser eso, no salir del JS, si la intención es ir metiendo via http los mini-juegos en la aplicación principal.
Con Unity los juegos salen muy pesados.
Lo que quieres hacer es exactamente lo mismo que hace Facebook Instant Games o los juegos de SnapChat. Para IG Unity esá prácticamente descartado porque la gente no tiene paciencia para esperar a que cargue todo el motor. Para SnapChat se usa solamente PlayCanvas porque es el único motor soportado oficialmente (y lo compraron expresamente para eso).
Yo lo veo un caso muy claro para usar HTML5. Se pueden hacer juegos que parecen nativos con WebGL (incluyendo el engine que sea) y el futuro es que cada vez va a haber más exportación a WASM.
Llevo trabajando bastantes años con estas tecnologías, si necesitas ayuda mándame un PM.
Yo creo que unity es una buena alternativa siempre que se cumplan las siguientes condiciones:
- Toda la lógica core ya está en la aplicación base
- La mecánica del juego descargado se puede desarrollar a nivel de scripting (LUA o sucedaneo).
- Implementar una capa visual (como un iframe) para representar una ejecución externa (limitada por no usar API del propio juego al estar en otro contexto)
Esta parte se puede solucionar desarrollando una API a nivel de motor y conectándolo con el lenguaje de scripting que queráis, de la misma manera que World of Warcraft permite la creación de Addons que capacitan incluso el desarrollo de minijuegos dentro del propio juego, aunque aquí se verá comprometido el rendimiento más pensando que es un dispositivo móvil.
Esta opción también genera un problema de seguridad que hay que considerar, si ya es fácil desarrollar hacks para los juegos actuales, imagina si además le damos a los hackers una API que puedan explorar y beneficiarse.
La idea parece cojonuda y lo es en un entorno menos comprometido como un web-browser que de manera nativa está limitado el acceso que puede tener, pero si queréis ir por una manera más nativa la cosa tiende a complicarse no sólo por el sistema operativo sino por el nivel de detalle a nivel de seguridad.
Mi recomendación, si aún así lo queréis desarrollar, es que investigueis mucho LUA, cuando trabajaba en King teniamos varios prototipos sobre el mismo código LUA que funcionaba a nivel de backend y como cliente en el móvil y podían "compartir" código, saltándose en cierta medida las limitaciones de las stores.
#11 Yo he portado juegos de Phaser a nativo con Cordova y tiraban muy bien, era imposible distinguir si eran nativos o no. Para mi gusto el problema era configurar los plugins hasta que todo funcionaba como quería, pero una vez preparado el flujo de trabajo era muy bueno y el rendimiento también.
De Vue ni idea porque me centro en el desarrollo de juegos, no de frontend. Algunos frameworks interacionan mal con Phaser. Recuerdo un juego que hice para un portal que usaba React y no sé exactamente qué parte del framework era, pero descolocaba completamente el timer (con requestAnimationFrame) que usaba Phaser, con lo que intentaba renderizar miles de frames por segundo y el rendimiento caía a lo bestia.
#13 ¿Para qué usas Cordova?
Nosotros lo usábamos para generar un proyecto en XCode o un .apk y de ahí publicar los juegos como apps en la AppStore o Google Play.
#15 Sí, a eso me refiero. Que una vez metidos en el webview de Cordova no era capaz de decir si el juego era nativo o HTML5, cargaban muy rápido, se ejecutaban a 60fps y la experiencia era idéntica a nativo, eso sí después de configurar 10 plugins incluyendo el de splash screen para que no saliese la pantalla gris xD
También estuve colaborando con Lucky Kat en algunos juegos y ellos tenían un workflow muy claro con Cordova. Su juego Road Crash ahí donde lo ves, está desarrollado sobre Three.js y empaquetado con Cordova.