MUD Questions de programmation

Question

J'avais l'habitude de jouer un MUD basé sur le Smaug Codebase. Il était hautement personnalisé, mais était le même au cœur. J'ai le code source pour ce MUD, et je suis intéressé à écrire le mien (Juste pour un projet amusant). J'ai quelques questions cependant, surtout sur les aspects de conception. Peut-être que quelqu'un peut me donner un coup de main?

1. Quelle langue dois-je utiliser? Interprété ou compilé? Est-ce que cela fait une différence? SMAUG est écrit en C. Je suis à l'aise avec beaucoup de langues, et je n'ai aucun problème à apprendre plus.
2. Y a-t-il une approche particulière que je devrais suivre pour ne pas entraver les performances? Orienté objet, fonctionnel, etc?
3. Quel support dois-je utiliser pour stocker des données? Fichiers plats (c'est ce que SMAUG utilise), ou quelque chose comme SQLite. Quels sont les avantages/inconvénients des performances des deux?
4. Y a-t-il des guides que vous connaissez sur la façon de démarrer un projet comme celui-ci?

Je veux qu'il évolue pour permettre à 50 joueurs en ligne à la fois sans perte de performance. Si j'utilisais Ruby 1.8 (très lent), cela ferait-il une différence par rapport à l'utilisation de Python 3.1 (plus rapide), ou compilé en C/C++?

Si quelqu'un peut donner un coup de main et donner des informations ou des conseils, je serais éternellement reconnaissant.

Answer 1

Je vais vous donner un coup de feu ce:

1. En 2009, pour un jeu de 50 joueurs, peu importe. Vous voudrez peut-être choisir une langue pour laquelle vous êtes familier avec les outils de profilage, si vous voulez la développer davantage, mais comme la RAM est si bon marché de nos jours, les contraintes qui gèrent le début LPMUD (dont j'ai l'expérience) et DikuMUD (qui votre Smaug est dérivé de) ne s'applique pas. (LPMUD pourrait gérer ~ 10-15 joueurs sur une machine avec 8 Mo de RAM)
2. Le style de programmation ne conduit pas nécessairement à des difficultés de performance, les grands sites comme Amazon's 'obidos' webserver sont écrits en C, mais les sites aussi grands que l'original Les magasins Yahoo ont été écrits en Lisp, StackOverflow est écrit en ASP.NET, etc. Je/personnellement/j'utiliserais C mais beaucoup de gens m'appelleraient un sadique.
3. Les fichiers plats sont un peu inutiles à l'heure actuelle pour beaucoup de stockage de données, il existe des exceptions spécifiques (Les gros serveurs de courrier utilisent parfois 'maildir' qui est des fichiers plats structurés, par exemple). La taille de votre jeu signifie probablement que vous ne serez pas confronté à une énorme lenteur due à des retards de récupération de données, mais l'intégrité des données en cas de crash va probablement faire l'argument le plus convaincant.
4. Je ne connais aucun guide, mais ce que je ferais, c'est d'essayer de lancer le jeu en tant que serveur de discussion, de m'assurer que les utilisateurs puissent se connecter et faire quelque chose (prendre leur d'autres utilisateurs), puis construisez-le pour permettre des connexions spécifiques, ainsi vous commencerez à relever le défi de la manipulation de nom d'utilisateur/mot de passe et de l'option/stockage/récupération d'options d'utilisateur ... commencer à ajouter les éléments de gamingriver travailler dans le jeu), puis aller un peu plus complexe (obtenir une installation de 5 pièces en travaillant avec des objets que vous pouvez ramasser/déposer/se chamailler avec), puis ajouter des personnages non-joueurs, puis s'inquiéter de se dorer dans le Diku -derived smaug châteaux/etc et travailler avec eux. :)

Ceci est un peu à l'écart, je suis sûr qu'il y a des opinions divergentes. :) Bonne chance!

Answer 2

Ceci est un jeu basé sur le texte, non? Dans ce cas, avec le matériel actuel, il semble que tout ce dont vous avez à vous soucier n'est pas de créer accidentellement un algorithme O (n ** 2). Même cela ne serait probablement pas trop mal avec 50 utilisateurs.