¿Qué es mejor para desarrollar juegos 3D basados ​​en web: Three.js o Unity3D?

Answer 1

Por mucho que sea fanático de Unity3D, tendría que decir Three.js.

Hace años, la respuesta sería Unity3D, debido a su reproductor web que replicaba la mayoría de las funcionalidades de su reproductor web basado en escritorio. Sin embargo, debido a que Chrome y FireFox eliminaron gradualmente la arquitectura del complemento en la que se basa el reproductor web, se suspendió.

La respuesta de Unity3D fue el reproductor WebGL; Tuvo un comienzo inestable, principalmente debido a:

• el largo tiempo para compilar los guiones
• errores que son difíciles de depurar
• todo: texturas, modelos, scripts, debe cargarse en la memoria del navegador. Unity3D es un motor pesado y pesado, y tuvo que quitar lo que no necesita para obtener una escena final que podría ser procesada por los navegadores
• Muchas funciones compatibles con el escritorio Unity3D no implementadas en el reproductor WebGL

De acuerdo, muchos de los problemas eran que el reproductor WebGL era una tecnología nueva, y los navegadores tenían soporte variable para varias optimizaciones. Sin embargo, mi mayor duda es que, dado que Unity3D es un marco pesado, y en un entorno de navegador, compite con otras pestañas por la memoria, por lo tanto, es realmente difícil optimizar el rendimiento.

Las cosas podrían haber mejorado para mejor desde que WebGL salió de la versión beta (los desarrolladores publican regularmente sobre cómo están mejorando la tecnología), aunque todavía no lo he probado personalmente, por lo que agradecería cualquier comentario al respecto.

Three.js podría no tener tantas funciones como Unity3D, sin embargo, usted tiene control desde cero sobre cuánta optimización desea. Con Unity3D, como es una caja negra, tienes que esperar a que los desarrolladores optimicen los cuellos de botella.

Answer 2

Es difícil de equilibrar, pero ofreceré mis 2 centavos.

Unity se encargará de la actualización de lo que los navegadores pueden hacer y manejar con el tiempo, para que no tenga que hacerlo. Three.js manejará alguna actualización, pero dependiendo de la actualización requerirá reescribir parte de su código para usarlo de diferentes maneras. Muchos sistemas JS a lo largo del tiempo son conocidos por no ser compatibles con versiones anteriores, incluso si dicen que lo son.

Si está comparando los dos, puede estar buscando desarrollar en JS para ambos, como se requiere en Three.js, pero es posible en Unity. No sería prudente planificar un nuevo desarrollo en Unity con JS, ya que el sistema “JS” en su interior no es exactamente JS. Y están eliminando gradualmente el soporte para ello de todos modos. C # es el gran lenguaje para ello. Si se siente más cómodo en un idioma que en otro, probablemente ya tenga su respuesta.

Three.js, por otro lado, está bien vinculado al lado JS de las cosas tal como está. Y aunque puedes interactuar con la página con Unity, no es muy robusto en cuanto a cómo. Si su juego vinculará gran parte de la página en varias piezas, o si desea dividirlo en las páginas de un sitio, será más fácil de administrar en un entorno JS puro.

Además, con JS, es muy fácil cargar los recursos que necesita cuando los necesita, recurriendo a ellos cuando, o justo antes de que necesite archivos de imágenes / audio / json, etc. Sin embargo, con Unity, el valor predeterminado es todo. cargando, por lo que lleva tiempo, e incluso puede experimentar el navegador / página efectivamente congelado durante ese tiempo.

Por supuesto, puede configurarlo haciendo que Unity cargue el contenido en partes, pero requiere esfuerzo y no es una función integrada. En cualquiera de los sistemas, la carga llevará trabajo, por lo que no es como Three.js está fuera de peligro, pero es algo natural escribir contenido que se carga en JS y no en Unity.

Dicho esto, creo firmemente que Unity será una mejor opción a largo plazo, ya que permite a un equipo de personas trabajar juntos para construir el juego. Diseñadores, Artistas, probadores, etc. En three.js. los diseñadores, artistas, etc., tienen que entregar los archivos del programador y cambiar las solicitudes, o su conocimiento debe incluir JS. Esto no es una limitación para un grupo independiente que ya es fuerte en esta área, pero Unity puede ser mucho más de arrastrar y soltar, y WYSIWYG puede designarse. Y si decides que quieres que tu juego se ejecute en dispositivos móviles o en una consola, (aparte de algunos cambios de interactividad / UI), es más que construirlo en ese entorno. A largo plazo, Unity seguirá empujando el sobre para mejorar estas cosas. Y en mi libro, permite una experiencia de desarrollo de juego mucho más natural que la que puedes obtener de un motor basado solo en código.

Answer 3

Emitiré mi voto sobre la Unidad.

Soy fanático desde hace mucho tiempo, pero lo que pasa aquí es ver un juego complejo hecho para dispositivos móviles que funciona bien en un navegador en relativamente poco tiempo, para mi propia incredulidad.

Webgl parece una solución mucho más completa ahora que cuando se introdujo por primera vez.