Pytania dotyczące programowania MUD

Question

Kiedyś grałem Mudem opartym na Smaug Codebase. Został dostosowany w dużym stopniu, ale w jądrze był taki sam. Mam kod źródłowy do tego MUD'a i jestem zainteresowany pisaniem własnego (tylko dla fajnego projektu). Mam jednak kilka pytań, głównie dotyczących aspektów projektowych. Może ktoś może mi pomóc?

1. Jakiego języka powinienem użyć? Interpretowane lub kompilowane? Czy to robi różnicę? SMAUG jest napisany w języku C. Mam wiele języków i nie mam problemu z uczeniem się więcej.
2. Czy istnieje szczególne podejście, które powinienem zastosować, aby nie utrudniać działania? Object Oriented, functional, etc?
3. Jakiego nośnika użyć do przechowywania danych? Pliki płaskie (to właśnie używa SMAUG) lub coś w stylu SQLite. Jakie są plusy i minusy wydajności obu?
4. Czy są jakieś przewodniki, o których każdy wie, jak rozpocząć ten projekt?

Chcę, aby był skalowany, aby umożliwić dostęp do 50 graczy jednocześnie, bez spadku wydajności. Gdybym użył Ruby 1.8 (bardzo powolny), czy zrobiłby różnicę w porównaniu do Pythona 3.1 (Szybszy), czy skompilowanego C/C++?

Jeśli ktokolwiek może pożyczyć rękę i udzielić informacji lub porady, będę wdzięczny za wszystko.

Answer 1

dam ten strzał:

1. W 2009 roku do gry 50 graczy, to nie ma znaczenia. Możesz wybrać język, który znasz na temat narzędzi do profilowania, jeśli chcesz go dalej rozwijać, ale ponieważ pamięć RAM jest obecnie tak tania, ograniczenia napędzają wczesny LPMUD (z którym mam do czynienia) i DikuMUD (który twój Smaug pochodzi od) nie mają zastosowania. (LPMUD może obsłużyć ~ 10-15 graczy na maszynie z 8 MB pamięci RAM)
2. Styl programowania niekoniecznie prowadzi do problemów z wydajnością, duże witryny, takie jak Amazon's 'obidos' webserver, są zapisane w języku C, ale tylko tak duże witryny, jak oryginał Yahoo Stores zostały napisane w Lisp, StackOverflow jest napisany w ASP.NET, itp. Ja/osobiście/użyję C, ale wiele osób nazwałoby mnie sadystą.
3. Pliki płaskie są bezsensowne w dzisiejszych czasach, jeśli chodzi o przechowywanie dużej ilości danych, istnieją wyjątki od określonych przypadków (duże serwery pocztowe czasami używają "maildir", na przykład strukturalnych plików płaskich). Rozmiar twojej gry prawdopodobnie oznacza, że ​​nie będziesz w stanie osiągnąć olbrzymiej powolności spowodowanej opóźnieniami w pobieraniu danych, ale integralność danych w przypadku awarii może być prawdopodobnie najbardziej przekonującym argumentem.
4. Nie znam żadnego przewodnika, ale postaram się uruchomić grę jako głupi serwer czatu, aby upewnić się, że użytkownicy mogą się zalogować i zrobić coś (weź ich dane wejściowe i zrzuć je do wszystkich inni użytkownicy), a następnie skompilujcie to, aby umożliwić określone logowanie, abyście mogli zmierzyć się z wyzwaniem związanym z obsługą nazwy użytkownika/hasła oraz ustawieniem/przechowywaniem/odzyskiwaniem opcji użytkownika ... a następnie zacząć dodawać elementy gamedriver (uzyskać gry w kółko i krzyżyk praca w grze), a następnie przejść nieco bardziej skomplikowane (uzyskać 5-pokojową instalację pracującą z obiektami, które można podnieść/upuścić/zepchnąć się nawzajem), a następnie dodać kilka znaków spoza odtwarzacza, a WTEDY martwić się o slurping w Diku -edived smaug zamki/etc i praca z nimi. :)

To trochę poza mankietem, jestem pewien, że są zdania odrębne. :) Powodzenia!

Answer 2

To jest gra tekstowa, prawda? W takim przypadku, przy obecnym sprzęcie, wydaje się, że wszystko, o co musiałbyś się martwić, nie tworzy przypadkowo algorytmu O (n ** 2). Nawet to prawdopodobnie nie byłoby źle z 50 użytkownikami.