MMO basados ​​en navegador (WebGL, WebSocket) [cerrado]

¿Crees que es técnicamente posible escribir un cliente MMO 3D completo con JavaScript del navegador: WebGL para gráficos y WebSocket para redes?

• ¿Crees que los futuros MMO (y los juegos en general) se escribirán con WebGL?
• ¿El rendimiento de JavaScript de hoy lo permite?
• Digamos que su equipo de desarrollo fue usted como desarrollador y otro creador de modelos (artista). ¿ Usaría una biblioteca como SceneJS para el juego, o escribiría WebGL directamente? Si usaría una biblioteca, pero no SceneJS, especifique cuál.

ACTUALIZACIÓN (septiembre de 2012): RuneScape, que es un MMORPG basado en navegador 3D muy popular que usó Applets Java hasta ahora, ha anunciado que usará HTML5 para su cliente ( fuente ).

Java (izquierda) y HTML5 (derecha)

ACTUALIZACIÓN (junio de 2013): he escrito un prototipo de un MMO basado en WebGL / WebSocket: https://github.com/alongubkin/xylose

¿Crees que es técnicamente posible escribir un cliente MMO 3D completo con JavaScript del navegador: WebGL para gráficos y WebSocket para redes?

Si, absolutamente. No hay ninguna razón por la que la tecnología WebGL o WebSocket le impida crear un cliente MMOG 3D, o cualquier cliente de juegos para el caso.

¿Crees que los futuros MMO (y los juegos en general) se escribirán con WebGL?

Sí. Creo que en los próximos cinco años, la mayoría de los juegos de navegador 3D se escribirán con WebGL. La razón es simple: WebGL es la única tecnología 3D estandarizada que tendrá implementaciones disponibles en todos los principales navegadores web (Chrome 9, Firefox 4, Safari 6 e Internet Explorer a través de Chrome Frame).

¿El rendimiento de JavaScript de hoy lo permite?

Sí. El rendimiento de JavaScript en los navegadores modernos ha aumentado hasta el punto en que el desarrollo de juegos 3D es factible. Por ejemplo, vea el proyecto Three.js .

Digamos que su equipo de desarrollo fue usted como desarrollador y otro creador de modelos (artista). ¿Usaría una biblioteca como SceneJS para el juego, o escribiría WebGL directamente? Si usaría una biblioteca, pero no SceneJS, especifique cuál. ¡Gracias!

Use una biblioteca para ahorrar tiempo. No hay ninguna razón para escribir su propio código de gráficos WebGL a menos que a una biblioteca existente le falten las características que necesita. Incluso en ese caso, probablemente sería más eficiente en tiempo extender la biblioteca existente.

Para mi proyecto, estoy usando GLGE, ya que admite muchos efectos gráficos diferentes y se actualiza constantemente con otros nuevos.

Ya hay varios MMO basados ​​en navegador por ahí. Sin embargo, generalmente no usan gráficos 3D.

Soy un poco escéptico cuando se trata de WebGL. La actual cosecha de navegadores no admite WebGL en sus versiones de lanzamiento normales. Tendrá que obtener compilaciones especiales o meterse con archivos de configuración, lo que es más complicado para el usuario promedio que descargar un complemento.

Hablando de complementos: varias personas mencionaron Unity, pero no olviden Flash. Un próximo lanzamiento del reproductor Flash (nombre en clave molehill ) tendrá 3D acelerado por GPU. Supongo que ese flash proporcionará gráficos 3D acelerados por hardware en el navegador antes de que despegue WebGL.

¿Técnicamente posible? Sí. Pero, ¿por qué molestarse cuando hay soluciones web como Unity disponibles?

¿MMOs futuros escritos en WebGL? No. Ok, tal vez, pero hay complementos basados ​​en la web como Unity que funcionan bien en este momento.

¿El rendimiento de JavaScript de hoy permite esto? No. Ok, sí, si mantienes tu juego simple.

¿Usaría una biblioteca como SceneJS [...] o escribiría directamente WebGL? Ninguno. Usaría una aplicación de terceros como Unity.

Esto no es factible en este momento (principios de 2011). No puede crear un MMO 3D en tiempo real en tecnologías de navegador nativas (es decir, sin complementos).

No especularé sobre el futuro. Así es como se ve ahora. Suponiendo que solo se dirige a los navegadores modernos (IE9, FF4, etc.). Si planeas soportar IE7, estás loco. Eso nunca funcionará.

Cosas faltantes:

• control total sobre el teclado y el mouse (capacidad de establecer la posición del mouse, intercepción de teclas)
• pantalla completa
• 3D

Áreas / soluciones con problemas serios:

• WebSockets ahora desactivado en los pocos navegadores que lo admiten
  • sin él: ahora baja latencia, comunicación bidireccional cliente-servidor
• problemas de audio
  • codec mess, necesitas ogg y mp3
  • frecuencias comunes no compatibles
  • concurrencia
  • retrasar
• rendimiento del lienzo (en algunos casos, hacer transformaciones divs y css es más rápido)

Sí, pero con grandes advertencias.

No tendrá control total del teclado, y para muchos fanáticos del control, esto podría ser un factor decisivo. Las teclas F, por ejemplo, probablemente permanecerán fuera del alcance durante bastante tiempo.

Tampoco podrás acceder a la mayoría de los navegadores. WebGL aún no está bien soportado, y el soporte websocket es impredecible en estos días, con algunos proveedores de navegadores que lo habilitan para una versión y luego la deshabilitan para la siguiente.

Pero puedes armar algo simple, seguro. Agregue un juego atractivo y no importará que los gráficos sean un poco discretos. Runescape comenzó bastante simple y se convirtió en un MMO complejo, divertido e increíblemente popular, cuando todos decían que un MMO creado en un complemento de navegador era un sueño imposible.

Un MMO construido dentro de los límites actuales para los navegadores que se adapta a medida que las cosas cambian sin duda tendrá una ventaja para cuando los navegadores estén lo suficientemente lejos como para soportar un MMO "AAA".

Absolutamente sí.

WebGL se incluye en versiones nocturnas de WebKit (Chrome / Safari) y Gecko (Firefox). Actualmente, WebSockets está deshabilitado debido a problemas de seguridad, pero no hay ninguna razón por la que no deba volver a habilitarse una vez que se resuelvan los problemas. Mientras tanto, siempre hay HTTP.

¿Todos los juegos se escribirán de esta manera? No, pero un número significativo lo será. Una vez que WebGL esté en las versiones finales de Chrome y Firefox, la penetración ya será mayor que la de los complementos nativos como Unity.

El rendimiento de JavaScript depende absolutamente de escribir juegos. Probablemente no verá un nivel de gráficos de Crysis por un tiempo, pero recuerde que con WebGL, la reducción de números se descarga a la GPU.

Para un equipo pequeño de 2 personas, deberá estar preparado para codificar mucho el motor que utilice. Actualmente no hay motores WebGL / JavaScript que realmente cubran gran parte del código del juego. SceneJS, three.js y similares son envoltorios sobre la capa de gráficos, pero no proporcionan nada para colisiones, física, audio, carga de recursos, redes o herramientas que constituyen la mayor parte de un producto como Unreal Engine o Unity.

Es temprano en este momento, esperaría ver más middleware emergente durante el próximo año.

No creo que muchos futuros MMO se escriban con ninguna tecnología de navegador del lado del cliente, ya que la mayoría de los desarrolladores de MMO querrán usar el mismo idioma en el cliente y el servidor, y la mayoría de los desarrolladores de juegos dominan idiomas que no son web como C ++. De todos modos, hay demasiado código de cliente involucrado para que sea muy práctico en Javascript, a excepción de simulaciones bastante triviales. También hay otras limitaciones impuestas al ejecutarse en el navegador que son desagradables para un desarrollador de juegos típico.

Sin embargo, estoy seguro de que habrá algunos juegos como este. Simplemente no van a tomar el control de WoW o juegos similares durante bastante tiempo. Probablemente serán más desarrollados por los desarrolladores web que ingresen a los juegos en lugar de los desarrolladores de juegos que ingresen a la web.

La pregunta que debes hacerte es por qué los desarrolladores de juegos querrán depender de la tecnología web que no dominan y no tienen control, ¿los idiomas actuales te permiten incluso en un navegador web hacer juegos increíbles?

Sí, pero la tecnología aún necesita estabilizarse y probablemente seguirá habiendo compensaciones de rendimiento frente a las aplicaciones nativas.

La unidad es buena. Ver también Shiva y el primer motor.