Project Darkstar es un framework de código abierto descontinuado para el desarrollo de MMOG , escrito en Java e implementado como middleware de motor de juego . Project Darkstar comenzó como un proyecto personal de Jeff Kesselman en 1999, y luego se convirtió en un proyecto de investigación en Sun Microsystems , [1] cuyo objetivo era "ayudar a los desarrolladores y operadores a evitar una variedad de problemas graves, aunque típicos, asociados con los juegos en línea a gran escala, los mundos virtuales y las aplicaciones de redes sociales actuales, incluida la sobrecarga de zonas, la corrupción de datos y la subutilización del servidor". [2] [3]
El proyecto Darkstar comenzó como un proyecto personal de Jeff Kesselman en 1999, mientras era el ingeniero de integración de juegos senior en Total Entertainment Network. En 2004, el director de juegos de Sun Microsystems, Chris Melissinos , formó el grupo de tecnología de juegos de Sun [4] y fue en ese momento que el Sr. Kesselman trajo la tercera versión del proyecto al grupo, donde se lo denominó "Sun Game Server" (SGS). (Las siglas sobrevivieron en los nombres de los paquetes del Project Darkstar Server hasta su desaparición).
Kesselman trabajó en la tercera versión durante un año como proyecto individual en Sun, y presentó una versión preliminar en la Game Developers' Conference (GDC) de ese año. Tras una reorganización de la oficina del director de tecnología de software en 2005, Melissinos y Kesselman trasladaron el proyecto a Sun Labs bajo la dirección de Karl Haberl, director de Sun Labs. Karl aumentó la mano de obra y añadió a Seth Proctor y Dan Ellard como coinvestigadores, así como a los contratistas James Megquier y Sten Anderson. Este equipo entregó lo que ahora se conoce como la versión Early Access, el primer servidor en funcionamiento, para la GDC 2005.
El 2 de febrero de 2010, tras la compra de Sun por parte de Oracle , Jim Waldo publicó en el foro "Project Announcement" que "el esfuerzo de ingeniería de Sun Labs ya no se aplica al desarrollo de Darkstar". Varios miembros del equipo de Sun Labs y varios miembros de la comunidad Darkstar trabajaron durante un tiempo en el servidor RedDwarf como sucesor de Darkstar. [5]
Cuando se ejecuta una implementación de servidor de Project Darkstar, inicia una nueva red o se une a una que se esté ejecutando actualmente. Todas las redes contienen clientes , implementaciones de servidor , una pila de Project Darkstar en la que se ejecutan las implementaciones de servidor y varios nodos de metaservicio que manejan el tráfico entre cada nodo de la pila de servidor. Una implementación de servidor es un programa creado por el usuario escrito con la API de Project Darkstar . Los clientes incluyen todas las aplicaciones y juegos del lado del cliente que están conectados a un servidor de juegos en la red.
El proyecto Darkstar fue diseñado para soportar todas las características vitales para un juego multijugador masivo y, al mismo tiempo, ser lo suficientemente escalable como para soportar juegos multijugador en línea no masivos . [6] Como tal, hay muchas características que admitía, con muchas características implementadas e integradas en él de forma activa. [ aclaración necesaria ]
La API de Project Darkstar fue el componente clave para los desarrolladores que utilizaron la tecnología. Con ella, podían desarrollar servidores de juegos para comunicarse correctamente con su tecnología cliente y tener un servidor en funcionamiento que se ejecuta sobre la pila de juegos de Project Darkstar. La API está escrita para ocultar la concurrencia del sistema subyacente que la pila realiza para el desarrollador, de modo que el programa se pueda escribir con la ilusión de que es de un solo subproceso, aunque la pila sea completamente paralela. Las partes principales de la API incluyen la gestión de tareas , la persistencia de datos y la comunicación de canales. [7]
El control de la información en un servidor de Project Darkstar generalmente se maneja mediante tareas, aunque en algunos casos especiales no son necesarias. Se utilizan en casos en los que el almacenamiento o la recuperación de datos deben protegerse de una caída o apagado del servidor , ya que las tareas se guardan y recuerdan cuando se ejecutan, y pueden volver a generarse cuando el servidor se reinicia en el mismo estado en el que estaban antes de la caída. [8] Esto es útil, por ejemplo, al actualizar la información del personaje. Si algo sale mal con el servidor internamente, la información del personaje se conserva y, al reiniciar el servidor, la información del personaje se restaurará desde el último estado en el que estaba antes de la caída. [ cita requerida ]
La base de datos Berkeley DB utilizada por Project Darkstar almacena todos los datos que se van a conservar. Todo lo que se vaya a almacenar en la base de datos también debe ser serializable , ya que la base de datos está programada para almacenar información binaria. Un objeto administrado puede ser cualquier cosa, desde datos de jugadores (es decir, posición, equipo) hasta datos internos del servidor y lógica de control (es decir, estructura de datos escalable, tareas). La utilidad de los objetos administrados se ve en el caso de una falla del servidor. Dado que los objetos administrados se actualizan transaccionalmente, cualquier dato dañado se descarta al reiniciar el servidor y el objeto administrado se revierte a su último estado de funcionamiento. [ cita requerida ]
Los canales ofrecen a los desarrolladores una forma sencilla de comunicarse con muchos clientes. Los canales funcionan de forma que los clientes puedan suscribirse a ellos para poder enviar mensajes al canal y recibir mensajes del canal. Cuando se envía un mensaje al canal desde un cliente o el servidor, el mensaje se envía por multidifusión a todos los clientes que están suscritos a él. Es una abstracción construida sobre la capa de comunicaciones para ayudar en el desarrollo de una comunicación fácil y extensible entre muchos clientes y el servidor. [ cita requerida ]
Algunos autores han sugerido que la gestión del almacén central de objetos y del acceso aleatorio distribuido podría no ser posible de manera realista en un entorno de juego altamente interactivo. [11]
RedDwarf Server era una solución de middleware de código abierto para desarrollar el lado servidor de juegos multijugador masivos en línea . Fue la bifurcación comunitaria oficial de Project Darkstar. Una vez que Oracle descontinuó el soporte para el proyecto, la comunidad renombró la última base de código de los repositorios de Project Darkstar y la lanzó como RedDwarf Server. [12] RedDwarf heredó el esquema de licencias de Project Darkstar, con RedDwarf Server distribuido bajo GPLv2 y las API del servidor disponibles bajo la Licencia Pública General GNU (GPL) con la excepción de classpath . Las API de cliente Java y C, disponibles como parte del proyecto RedDwarf, se distribuyeron bajo una licencia BSD . [13]
Los clientes pueden comunicarse con el servidor mediante una API de Java o C. La comunidad también publicó API de cliente para plataformas adicionales, entre las que se incluyen C# , Python , Objective-C y ActionScript . [14] RedDwarf Server utiliza un protocolo integrado para las comunicaciones de red. [15]
{{cite web}}: |last=tiene nombre genérico ( ayuda ).svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
