MUD preguntas de programación

Question

Yo solía jugar un MUD basado en la Smaug código base . Era muy personalizados, pero era la misma en el núcleo. Tengo el código fuente de este MUD, y estoy interesado en escribir mi propia (Sólo por un proyecto de la diversión). Tengo algunas preguntas, sin embargo, sobre todo acerca de aspectos de diseño. Tal vez alguien me puede dar una mano?

1. ¿Qué idioma debo usar? Interpretado o compilado? ¿Hace alguna diferencia? Smaug está escrito en C. Me siento cómodo con una gran cantidad de idiomas, y no tienen ningún problema en aprender más.
2. ¿Hay un enfoque particular, que debería seguir para no obstaculizar el rendimiento? Orientada a Objetos, funcional, etc.?
3. ¿Qué medio se debe utilizar para el almacenamiento de datos? Los archivos planos (esto es lo utiliza Smaug), o algo así como SQLite. ¿Cuáles son las ventajas de rendimiento / contras de ambos?
4. ¿Hay guías que alguien sabe de sobre cómo empezar a trabajar en un proyecto como este?

Lo quiero a escala para permitir que 50 jugadores en línea a la vez sin disminución de rendimiento. Si usara Rubí 1,8 (muy lento), habría que hacer una diferencia en comparación con el uso de Python 3.1 (más rápido), o compilado en C / C ++?

Si alguien puede dar una mano y darle algo de información o asesoramiento, estaría eternamente agradecido.

Answer 1

Voy a dar a este un tiro:

1. En el año 2009, para un juego de 50 jugador, no importa. Es posible que desee elegir un idioma que está familiarizado con las herramientas de perfilado para, si usted quiere hacer crecer aún más, pero ya que la memoria RAM es tan barato hoy en día, las restricciones de conducción principios LPMud (que no tengo experiencia con) y DikuMUD (que su Smaug se deriva de) no se aplican. (LPMud podía manejar ~ 10-15 jugadores en una máquina con 8 MB de RAM)
2. El estilo de programación no necesariamente conduce a dificultades de rendimiento, los sitios grandes como Amazon 'servidor web de Óbidos están escritos en C, pero sitios sólo-como-grandes, como las tiendas de Yahoo originales fueron escritos en Lisp, Stackoverflow está escrito en ASP.NET, etc me gustaría / personalmente / C uso pero muchas personas me llamaron un sádico.
3. Los archivos planos son una especie de sentido en los días de hoy y la edad para las porciones de almacenamiento de datos, hay excepciones de casos específicos (grandes servidores de correo utilizan a veces 'maildir' que se estructura ficheros planos, por ejemplo). El tamaño de su juego probablemente significa que no va a correr en gran lentitud impulsado por los retrasos de recuperación de datos, pero la integridad de los datos en caso de accidente, son probablemente va a hacer el argumento más convincente.
4. No sé de cualquier guía, pero lo que haría es tratar de conseguir el juego comenzó como un servidor de chat tonto para empezar, asegúrese de que los usuarios pueden iniciar sesión y hacer algo (tomar su entrada y lo descarga a todos otros usuarios), a continuación, construir que hasta permite inicios de sesión específicos, por lo que empezarán a afrontar el reto de nombre de usuario / contraseña de manejo y ajuste de la opción de usuario / almacenamiento / recuperación ... a continuación, empezar a añadir los elementos gamedriver (conseguir juegos de tres en raya trabajando en el juego), y luego ir un poco más complejo (obtener una configuración de 5 piezas a trabajar con objetos que se pueden recoger / dejar / bash entre sí con), a continuación, añadir algunos personajes no jugadores, y luego preocuparse por sorber en el Diku castillos smaug derivada de / etc y que trabajan con ellos. :)

Esto es un poco fruto de la casualidad, estoy seguro de que hay opiniones divergentes. :) Buena suerte!

Answer 2

Este es un juego basado en texto, ¿verdad? En ese caso, con el hardware actual, parece que todo lo que tendría que preocuparse por no se crea accidentalmente una O (n ** 2) algoritmo. Incluso que probablemente no sería tan malo con 50 usuarios.