¿Cuál fue la pila de tecnología que impulsaba los servidores originales de Ultima Online?

Mi memoria sobre todo esto es borrosa, por lo tanto, tenga cuidado.

El servidor de juegos era un servidor C o C ++ personalizado (no recuerdo cuál), que se ejecutaba en Solaris. Algún tipo de Sparcs locos, creo. Teníamos una pequeña oficina o armario que convertimos en una sala de servidores con un ventilador. Solíamos pasar una pelota de playa sobre el escape.

Cada fragmento (el término fragmento probablemente se originó con UO) era en realidad múltiples servidores de juegos que apuntaban a una base de datos de persistencia, y eso reflejaba los datos a través de los límites. El equilibrio de carga dentro de un fragmento estaba determinado estáticamente por los archivos de configuración, y era simplemente cuadros en el mapa, nada de lujos. Las condiciones de carrera aquí llevaron a la mayoría de los errores de engaño, por cierto.

Juego de bases de datos estáticas de archivos de texto plano (definiciones de criaturas y objetos). Los editamos en vi.

Mapas y ubicaciones de objetos almacenados en archivos binarios (archivos .MUL). Estos fueron editados usando el “cliente de Dios”. El formato de archivo está disponible ahora, ingeniería inversa para los fragmentos grises. Estos fueron tomados y colocados en el disco del juego.

La mayoría de los desarrolladores ejecutaron una copia del servidor en Linux allí mismo, para que pudieran hacer un trabajo de desarrollo. Entonces todo se fusionó.

Dos lenguajes de script. El principal se llamaba Wombat, de cosecha propia. Un lenguaje de sintaxis C basado en eventos con su filosofía derivada arquitectónicamente de los lenguajes de secuencias de comandos MUD en DikuMUD, específicamente Worlds of Carnage y LegendMUD (ver http://www.raphkoster.com/gaming…). Esta arquitectura básica de secuencias de comandos es una especie de estándar de la industria ahora, en realidad. Toda la interactividad de los objetos, la mayoría de la lógica del juego, la mayoría de la IA, etc., se escribió en Wombat. Las excepciones incluyeron movimiento, combate y toda la IA “común”.

El otro fue pirateado durante la noche más o menos la noche antes de lanzar el pre-alfa, llamado escript. Sin él, no habríamos terminado el mapa a tiempo. Literalmente leyó el disco y analizó a medida que avanzaba. Fue específicamente para realizar ediciones de procedimientos a gran escala en el mapa. Tenía bucles, aleatorio, mosaico de consulta, mosaico establecido, objeto de generación, y eso fue todo. La sintaxis era horrible: cada comando con @@ alrededor, cada variable con ## alrededor, ese tipo de cosas. Eventualmente (período de la Segunda Edad) escribí un guión que sirvió como front-end para hacer las cosas más comunes (llenar con árboles, elevar / bajar / aplanar áreas, colocar los mosaicos de transición entre diferentes mosaicos … este último porque el terreno alfa la mezcla no estaba en el motor).

Sinceramente, no me acuerdo de la base de datos de tiempo de ejecución.

Para una imagen de cómo todo esto encaja, vea aquí: http://www.raphkoster.com/gaming…

Cliente escrito en C.

El protocolo de red era paquetes personalizados hechos a mano diseñados para guardar cada byte. Nuestro extremo inferior era un módem de 28.8, por lo que apuntamos a 400 bytes por segundo, si mal no recuerdo. Corrimos sobre TCP. Cambiar un paquete significaba actualizaciones coordinadas del cliente y el servidor.

El control de origen fue SourceSafe en la PC y CVS para los datos del servidor.

No sé sobre cosas como la base de datos de facturación, y había algún tipo de servidor de inicio de sesión en el frente. Sin embargo, podría ejecutar un archivo de configuración del cliente para apuntar a servidores alternativos.

[Editar: Realmente necesito agregar que todo el crédito por lo anterior debe ir, en primer lugar, a Rick Delashmit, quien probablemente escribió el 80% del código para el cliente y el servidor; y Scott Phillips, Ed Meinfelder, Jeff Posey y Jason Spangler del equipo central original. Después de eso, contribuyó una pila gigante de más programadores: verifique los créditos.]

El cliente y el servidor eran una mezcla heterogénea de C y C ++. Para cuando estaba en el equipo (varios meses después del lanzamiento del juego), estábamos corriendo (en producción Y desarrollo) en servidores Linux, en lugar de Solaris.

Realmente había muy poco en el camino del “equilibrio de carga”: el equipo definió fragmentos rectangulares del mundo que eran administrados por “servidores de áreas”. Cuando cruzaste un límite entre uno de estos servidores de áreas y otro, tu estado (que incluía la representación de tu personaje, sus objetos Y el estado de ejecución de los scripts de Wombat que se adjuntaron a ti; sin embargo, piensa en variables globales aquí, nada sexy como las continuaciones) embalado en un gran blob de texto y enviado a la nueva área.

En términos de comunicación, el protocolo era todo TCP. Como sugiere Raph, los datos que se montan sobre TCP se sintonizaron byte a byte, pero no se cifraron de ninguna otra manera, al menos no inicialmente. Linux en ese momento (y Solaris, también, iirc) tenía un límite de descriptores de archivo por proceso, ¡con un límite de 256! Y eso, solo si cerró STDIN, STDOUT y STDERR. Esa limitación requirió el despliegue de “servidores de jugador”, una especie de equilibrador de carga (carga de conexión, sin embargo, no carga de servidor, por desgracia), que hizo una desinfección muy simple, y más allá de eso no hizo nada más que administrar cientos de conexiones (253 o así que, iirc, por playerserv, con muchos playerservs por fragmento, suficiente para unos pocos miles de jugadores), canalizando el tráfico de un lado a otro.

Como también señala Raph, no había bases de datos originalmente involucradas en el almacenamiento del estado del juego o los datos del jugador para UO (sin tener en cuenta el análisis aquí), todo se mantuvo en archivos planos. Las copias de seguridad funcionaron marcando un momento en el tiempo en el que a nadie se le permitió cruzar los límites del servidor; durante ese momento, se ordenó a cada servidor de área que se bifurcara (), esencialmente duplicándose en la memoria (es más complicado que esto, gracias a Copy-on- Escribe, pero simplifiquemos). Después de que todo el mundo tuviera fork () ed, se eliminó el “bloqueo” que evitaba el cruce de límites. Luego, cada areaserv comenzó a volcar su enorme porción de estado de memoria en un archivo en un servidor NFS. Esos archivos fueron todos alquilados y guardados como una “copia de seguridad” del estado del servidor. Estas copias de seguridad pesadas ocurrieron a intervalos de media hora, creo.

Los casos límite y las condiciones de carrera del límite del servidor persistieron durante mucho tiempo, lo que permitió duplicar el oro y los artículos, aunque creo que habíamos erradicado en gran medida los grandes para cuando me mudé a UO2.

Muchas de las piezas de simulación de servicio pesado en el juego finalmente se apagaron o se atenuaron para más implementaciones de humo y espejos. Un gran ejemplo de uno que en su mayoría no era funcional cuando me uní al juego fue la lógica de “los guardias de la ciudad adoran los pasteles”, en la que los guardias de la ciudad (policías) seguían despreocupadamente a los jugadores que poseían pasteles (donas) … muchas cosas muy interesantes , pero también caro en términos de simulación. Incluso el combate monstruo contra monstruo finalmente se cerró por la proximidad del jugador, sin pelear a menos que alguien estuviera cerca para verlo.

La copia de seguridad en realidad tomó una hora, como la mayoría de los jugadores recordará como “tiempo de reversión”. Si el juego se caía, normalmente perdías una hora de juego. A las 5 a. M. CST, la mayoría de los servidores tomarían una foto y se produciría un caos (debido a que el juego anunciaba que se caería). Podrías luchar sin consecuencias durante una hora y luego ser feliz con tu personaje completamente restaurado al día siguiente (después de que se completara el ciclo de inactividad).

Jason Spangler luego escribió un sistema de respaldo distribuido que hizo que el ciclo de tiempo de inactividad se redujera a menos de 7 minutos. Pasó muchos meses escribiendo y probando el sistema. Después de que se introdujo, se eliminó el mismo ciclo para los jugadores que alguna vez fue un pasatiempo de lucha durante una hora. Esto causó que muchos jugadores comenzaran al día siguiente desnudos, debido a que perdieron todos sus artículos de pvp / pve. Habían esperado un ciclo de tiempo de respaldo de una hora, pero el ciclo en realidad solo tomó unos minutos (aproximadamente 6 minutos, pero a medida que se introdujo el hardware más nuevo, mucho menos).

Además, durante nuestro tiempo de desarrollo, estábamos escribiendo guiones y probándolos. El tiempo de compilación de los scripts de Wombat tomó unos minutos. Jason de alguna manera redujo el tiempo de compilación de nuestros guiones a unos segundos. Esto aumentó nuestro tiempo de desarrollo al reducir el tiempo de espera para que los scripts se compilen en un orden de 10x a 20x veces.

Me gustaría decir que Jason Spangler fue el programador más beneficioso para la productividad del equipo de diseño de cualquier programador en el equipo. Es uno de los muchos programadores que trabajaron en el juego, lo que hizo que fuera un placer ser diseñador en el juego y nos ayudó a producir un producto que no se ha replicado hasta el día de hoy.

Esos servidores originales eran Sun Ultra II con Solaris. Si no recuerdo mal, era una caja de proceso dual (rara en esos días), 300 mhz, con 256 MB de ram (que posteriormente actualizamos a 512 MB por un bote de efectivo). El servidor pesaba una tonelada, y ciertamente no se podía montar en bastidor. y cuestan alrededor de $ 30k cada uno, lo que hace que un fragmento de UO cueste alrededor de $ 150k (sin incluir el almacenamiento externo), que es una cantidad ridícula de dinero en estos días por un solo fragmento. Eventualmente construimos fragmentos de MMO por mucho menos costo (incluido MCO, TSO, ENB y, por supuesto, SWTOR) por fragmento. Las copias de seguridad se mantuvieron en almacenamiento interno, por lo que sudamos cubos cada vez que perdíamos un disco. finalmente, centralizamos las copias de seguridad en una matriz de almacenamiento de Hitachi que era un monstruo y pesaba fácilmente 100 libras y proporcionó la friolera de ~ 10 GB de espacio en bruto.
Creo que donde revolucionamos la administración de un MMO distribuido fue en el lado de la red, específicamente a través de la VPN, que era muy nuevo en ese momento. A falta de pedir circuitos PTP en todo el país y el mundo, utilizamos un software VPN para crear esos túneles a través de nuestra conexión a Internet pública en ese momento (un SINGLE DS3: ¡no fue hasta finales de 1998 que tuvimos un segundo circuito!) Permitir la transferencia de inicio de sesión, la administración, las copias de seguridad, las publicaciones, etc. Nuestro hub y el diseño de VPN y el diseño posterior de malla completa fueron lo que hizo que la distribución de fragmentos fuera económicamente factible.
Creo que fue a mediados de 1999 cuando nos convertimos a Linux, pero no antes de usar Solaris x86 por primera vez. Compramos Dell Towers para que actuaran como servidores (creo que Dell no envió un verdadero servidor de montaje en bastidor hasta el año siguiente, o eso creo) y tenían una velocidad ligeramente mejor que los Suns y a un costo mucho menor. Pero creo que necesitábamos más de ellos por fragmento, especialmente cuando lanzamos paquetes de expansión (que en esos días, significaban agregar un nuevo servidor para manejar la masa de tierra adicional). Probablemente estábamos más cerca de 10 servidores / fragmento alrededor de 2000/1.
Gracias a Mark Rizzo por la arquitectura y construcción del backend de UO. Estaba muy adelantado a su tiempo, y las innovaciones que reunimos en ese momento se dan por sentado en estos días (¡¿pero eso no es cierto para todo ?!).

La base de datos de back-end para iniciar sesión y análisis de juegos era un servidor Microsoft SQL, versión 6.

Estaba trabajando para Texas. Net en Austin en ese momento (’97 -’98), y recuerde estar de vacaciones cuando le prestamos una tarjeta de interfaz de enrutador de emergencia (T3, ¿o algo así?) Para que pueda volver a jugar parte del juego: los chicos que llegó a entregarlo terminó con una gira y todos los juegos gratuitos que podían llevar IIRC 🙂 Nunca había estado tan molesto por estar de vacaciones …

Solo tengo una cosa que agregar a la respuesta de Raph. El hardware era una combinación de diferentes tipos (SPARC e Intel) y sistemas operativos (Solaris y Linux), por lo que tuvimos que distribuir el código fuente a las máquinas para que se compilaran durante una publicación. Esto agregó mucho tiempo a nuestro proceso de publicación e implementación ya que no pudimos distribuir archivos binarios. Una vez que pudimos unificar los servidores y hacer que todos se ejecutaran en la arquitectura Intel y Linux, pudimos detener el envío de la fuente a todos los puntos finales y distribuir solo binarios.

Omg, el Raphmeister sigue vivo y coleando. <—- Zenscrotum de Lumthemad, hilo de agua, blahblahblah ......