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.
- ¿Qué opinas de la empresa Boring de Elon Musk?
- Cómo probar mi sitio web (receptivo) en diferentes dispositivos, de diferentes tamaños de pantalla
- ¿Cuáles serán los efectos de la prohibición de las tarifas de roaming móvil en la UE?
- ¿Qué está impidiendo que las principales compañías de tecnología como Samsung, Apple, etc. desarrollen una mejor duración de la batería para teléfonos, computadoras portátiles, tabletas, etc.?
- Los servicios de Google están prohibidos en China, entonces, ¿por qué las empresas chinas usan Android en sus teléfonos móviles?
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.]