java concurrency distributed

java - ¿El proyecto Darkstar es realista?



concurrency distributed (7)

El Proyecto Darkstar fue el tema de la reunión mensual de JavaSIG en las oficinas de Google en Nueva York anoche. Para aquellos que no conocen (probablemente a todos), Project Darkstar es un marco para los juegos multijugador en línea masivos que intenta hacerse cargo de todas las "cosas difíciles". La idea básica es que usted escriba la lógica de su servidor de juego de tal manera que todas las operaciones se dividan en pequeñas tareas. Transfiere estas tareas al marco Project Darkstar, que maneja la distribución a un nodo específico en el clúster, cualquier problema de concurrencia y finalmente persiste la información.

Aparentemente, hacer este tipo de cosas es un problema muy diferente para los videojuegos que para las aplicaciones empresariales. Jim Waldo, quien pronunció la conferencia, afirma que los juegos MMO tienen una proporción de lectura / escritura de DB de 50/50, mientras que las aplicaciones empresariales son más como 90% de lectura, 10% de escritura. También afirma que la mayoría de los MMO existentes guardan todo en la memoria de forma exlcusiva, y solo se vuelcan a un DB cada 6 horas. Esto significa que si un servidor se cae, usted perdería todo el trabajo desde el último volcado de DB.

Ahora, el proyecto en sí suena genial, pero no creo que la industria lo acepte. Primero, debes escribir tu código de servidor en Java. El código del cliente se puede escribir en cualquier cosa (Jim afirma que ActionScript 3 es el más popular, seguido por C ++), pero el material del servidor tiene que ser Java. Me parece bien, pero realmente tengo la impresión de que todos en la industria de los juegos odian Java.

En segundo lugar, a diferencia de otras industrias en las que los desarrolladores prefieren usar marcos y bibliotecas existentes, a los chicos de la industria de los juegos les gusta escribir todo ellos mismos. No solo eso, les gusta reescribir todo para cada nuevo juego que producen. Las cosas están empezando a cambiar donde los desarrolladores están usando Havok para física, Unreal Engine 3 como su plataforma, etc., pero en su mayor parte parece que todo sigue siendo propiedad.

Entonces, ¿los chicos del Proyecto Darkstar están perdiendo el tiempo? ¿Puede un marco general como este realmente funcionar para juegos complejos con el rendimiento que se requiere? Incluso si funciona, ¿las compañías de juegos están dispuestas a usarlo?


No trabajo en la industria de los juegos, pero me parece que esto hará lo mismo para los videojuegos que los motores Quake y Half-Life. Es decir, promoverán que los jóvenes desarrolladores se interesen en la industria y promoverán el desarrollo de juegos independientes.

Por lo que puedo decir, las compañías de videojuegos no reutilizan la mayor parte de su código, porque si lo hacen implica que su nuevo juego es solo una repetición de uno anterior. Todo el mundo quiere un nuevo y genial motor de física, mejores gráficos, nuevas formas de jugar. La mayoría de los motores y frameworks de videojuegos están hechos para un escenario específico y, por lo tanto, no son muy flexibles para otras situaciones.

Sin embargo, quizás Darkstar lo haga bien, pero lo dudo, ya que generalizar solo funciona para tanto.


Me suena a tecnología inútil. El mundo de los MMO está controlado por unas pocas grandes compañías de juegos que ya cuentan con su propia tecnología. A los desarrolladores de juegos independientes les encanta intentar crear MMO y a veces lo hacen, pero esos juegos raramente ganan tracción. Las compañías más grandes que se introduzcan en el mundo de los MMO probablemente otorgarán licencias de tecnología "probada" o ampliarán la suya propia.

Las compañías de juegos reutilizan grandes cantidades de código de juego en juego. La mayoría de las compañías de juegos han desarrollado su propia tecnología internamente y la utilizan en todos los juegos que producen. Ocasionalmente, harán algo así como reemplazar su código de física con un motor de física de un tercero. Si su base de código interno (motor de juego, herramientas de diseño, canalización interna) comienza a envejecer demasiado, o se vuelven difíciles de manejar, podrían cambiar a uno de los motores de juegos grandes como Unreal. Incluso entonces, grandes trozos de código continuarán siendo reutilizados de juego en juego.


Es muy común que los juegos reutilicen los "motores de juego", incluso los de terceros. Esto suena como un paso más en esa dirección.


Suena divertido diseñar y codificar, pero creo que finalmente se reduce a abstracciones inútiles (para robarle a Joel).


Creo que es algo grandioso de hacer. Los desarrolladores no tienen que preocuparse por todas estas cosas que el proyecto darkstar se ocupa, y es muy fácil de usar. Pero no solo se trata de hacer que funcione y no tener que aprender todo sobre la comunicación por Internet, también se trata de rendimiento. El proyecto darkstar ha estado en desarrollo por más de 2 años y sigue mejorando, más rápido y más robusto.

Creo que será difícil y probablemente no valga la pena escribir estas cosas cuando se apunta a un juego específico, cuando en su lugar se pueden usar tecnologías como esta. Y también obtienes buena información durante el tiempo de ejecución indicándote en qué parte de una aplicación hay una causa de desaceleración o interbloqueos para que puedas mejorarla.


Editar: Esto fue escrito antes de que Oracle comprara Sun y comenzara un alboroto para matar todo lo que no los convierte en mil millones de dólares por día. Vea los comentarios para un Tenedor de OSS. Todavía estoy de acuerdo con mi opinión de que cosas como esa (MMO Middleware) son realistas, solo necesitas una compañía que no la deje atrás.

El mercado puede estar dominado por pocos juegos grandes, pero eso no significa que no haya mucho espacio para más juegos de nicho. Seamos realistas: si quieres llegar a más de 100.000 jugadores, terminas construyendo tu propia tecnología, al menos para el núcleo crítico. Eso es lo que hizo CCP para EVE Online ( StacklessIO ), eso es lo que Blizzard hizo para World of Warcraft (aunque usan muchas bibliotecas de terceros), eso es lo que Mythic hizo para Warhammer Online (aunque están basados ​​en Gamebryo).

Sin embargo, si pretendes ser un pequeño MMO de nicho (como las docenas de MMOs de Free-to-Play / Itemshop), entonces hacer que la red funcione correctamente es increíblemente difícil, la consistencia de los datos es aún más difícil y la escalabilidad es la mayor b * tch.

Pero la tecnología del juego no es su único problema; también debe abordar la facturación. Solo tarjeta de credito? Diviértete vendiendo en Alemania, la gente allí quiere ELV. Ahí es donde necesita un proveedor de facturación confiable, pero aún necesita conectar la aplicación de facturación con sus cuentas para asegurarse de que las cuentas se bloqueen / reactiven cuando falla la facturación.

Hay algunas compañías que ya ofrecen "Servicios de infraestructura de MMO" (es decir , EEIS de Arvato ), pero la conclusión es: Cosas como el Proyecto Darkstar ES realistas, pero suponiendo que se puede construir un multimillonario totalmente en una pila de terceros es optimista posiblemente idealista

Pero, una vez más, inventar completamente toda la tecnología es aún más estúpido: use las cosas de terceros que necesita (es decir, Facturación, Renderización de fuentes, Salida de audio ...), pero escriba las cosas que realmente hacen o quebrantan su negocio (es decir, Pila de red, interfaz de usuario, etc.) por su cuenta. (Nota: la publicación de Jeff puede ser un poco defectuosa , pero la dirección general es correcta en mi humilde opinión).

Adición: Además, la industria de los juegos licencia y reutiliza mucho los motores. Los motores de juego más destacados son el Unreal Engine , Source Engine y id Tech , que alimentan docenas, sino cientos de juegos. Pero hay algunos motores menos conocidos (fuera de la industria). Hay Gamebryo , Middleware detrás de juegos como Civilization 4 y Fallout 3, RenderWare ahora es solo EA-in-House, pero se usa en juegos como Battlefield 2 o The Sims 3. Existe el código abierto Ogre3d , que se usó en algunos títulos comerciales. Si solo está buscando sonido, hay cosas como FMOD o si quiere hacer un renderizado de fuentes, ¿por qué no darle un giro a FreeType ?

Lo que estoy diciendo es: Third-Party Engines / Middleware sí existen, y ESTÁN siendo utilizados con éxito desde hace más de una década (sé con certeza que el Motor Wolfenstein de id se licenció para otras compañías, y eso fue en 1992), incluso por grandes compañías en títulos multimillonarios. Lo importante es el soporte, porque un buen motor sin ayuda en caso de un problema no tiene ningún valor o al menos es muy caro si el desarrollador tiene que pasar su tiempo de desarrollo del juego con la depuración innecesaria del motor.

Si la gente de Darkstar logra obtener el lado de soporte correcto y 2 o 3 títulos de perfil más alto, creo que podría tener éxito al abrir el mercado de MMO a desarrolladores e independientes mucho más pequeños.


Por lo que puedo decir, las compañías de videojuegos no reutilizan la mayor parte de su código, porque si lo hacen implica que su nuevo juego es solo una repetición de uno anterior.

Um ... si te refieres a la larga cola de las compañías de videojuegos, tal vez. Dentro de una empresa que ha tenido una serie de juegos exitosos, generalmente hay un poco de reutilización. Los cambios importantes en el hardware pueden dar como resultado abandonar mucho trabajo, pero realmente depende de la compañía.