LINUX.ORG.RU

Архитектура сервера и ЯП для ее реализации


0

1

Возникла необходимость написать игровой сервер для РПГ с неграфическим интерфейсом.

На него будут возложены такие задачи: интерактивное общение с пользователями, задачи по глубокой обработке текстовых данных — парсинг с помощью регулярных выражений, генерация ответов пользователю, создание «текстовых» уровней-лабиринтов, модификация сценария развития событий налету, достаточно сложная генерация сюжетных линий исходя из действий пользователя.

Требования:

  • Высокая надежность со стороны ЯП и используемых технологий. В случае сбоя отдельных частей программной логики, необходимо, чтобы существовали какие-нибудь Супервизоры, работа которых происходит достаточно быстро для того, чтобы игрок не заметил «горячей замены» (возможно, выражение не совсем точное) кода, действующего узла, генератора карты, «отвалившегося» NPC-босса и так далее.
  • Относительная проста написания игрового мира в терминах происходящих процессов.
  • Красивая работа с многопоточностью, сетью и регулярными выражениями.

P.S.: Есть идея использовать для этой задачи связку из CL + Erlang или Java/Clojure + Erlang. Или просто CL.

На интуитивном уровне, вроде бы, понятно, что CL будет отвечать за логику, разбор регулярных выражений, работу с графами, генерацию мира, имитацию ИИ, а Erlang за работу с сетью и всевозможную многопоточность. Но интуиции свойственно ошибаться, поэтому интересует мнение людей, у которых есть опыт написания чего-то подобного.

И да, всячески приветствуется литература (желательно русскоязычная) по теории построения таких серверов. Можно с примерами на С.

Ответ на: комментарий от recon88

Haskell для логики + Erlang(или Haskell) для многопоточности

Слишком высокий порог вхождения, я пока воздержусь. Да и хочется динамической типизации. Ну и Лев Валкин как-то рассказывал о том, как Ocaml показал себя для real world весьма шустрее, чем Haskell.

alienclaster ★★★ ()
Ответ на: комментарий от alienclaster

ИМХО, для эффективной разработки порог вхождения будет большой для любого языка. К тому же, из моего опыта, статическая типизация значительно упрощает разработку, особенно алгоритмов. Вобщем задача у вас довольно объемная, и вы еще десять раз передумаете пока будете писать.

На счет Ocaml : 1) он статически типизирован 2) у него более слаба система типов(сам не сталкивался, но встречал сообщения о проблемах) 3) согласно недавнему сообщению на russian lambda planet, инструментарий у него тоже похуже.

То что вы собираетесь делать можно эффективно делать на любом из упомянутых ранее языков. Методы конечно будут специфические, но в целом более или менее равнозначные. Так что не вижу смысла такого серьезного подхода к выбору. Хочется динамики - CL. Надо сервер - попробуйте на CL, а если не понравится - Erlang.

recon88 ()
Ответ на: комментарий от recon88

Спасибо за развернутый ответ. Выбор языка из упомянутых выше действительно не самый сложный и скорее решение будет принято исходя из вкусовых предпочтений.

Интересует прежде всего литература по архитектуре подобных сервисов. Что бы почитать такого?

alienclaster ★★★ ()
Ответ на: комментарий от recon88

>К тому же, из моего опыта, статическая типизация значительно упрощает разработку, особенно алгоритмов.

Очень спорное высказывание.

anonymous ()
Ответ на: комментарий от recon88

> К тому же, из моего опыта, статическая типизация значительно упрощает разработку, особенно алгоритмов.

скорее упрощает реализацию уже написанного алгоритма.

anonymous ()

У вас прям тендер, как в россии.

«Нам нужен язык программирования абсолютно любой, но подходящий под критерии: работа с регулярными выражениями, работа с сетью, открытие закрытие файлов, что бы название начиналось на 'e', кончалось на 'g'.»

Zubchick ()

Могу еще в дополнение предложить связку Java/Scala. Там есть

  • встроенный XML в синтаксис языка;
  • хорошая библиотека коллекций, включая мутабельные и иммутабельные варианты коллекций. Последние полезны для многопоточного сервера и вообще;
  • библиотека акторов как реализация эрланговского message passing, но ограниченная пределами одного сервера;
  • встроенные парсер-комбинаторы, где можно использовать также регулярные выражения для парсинга;
  • очень продвинутое ООП (есть вариантность);
  • хорошая поддержка функционального программирования (можно даже имитировать хаскелевские классы типов через ООП и implicts);
  • хорошая интеграция с явой в обоих направлениях.

Фиг знает, как с горячей заменой. Наверное, также как в самой яве.

dave ★★★★★ ()

Я не понял, ты MUD http://en.wikipedia.org/wiki/MUD что ли, хочешь написать? Если да, скачай исходники DikuMUD/СircleMUD/LPmud на MUDConnector'e http://www.mudconnect.com/ http://www.mudconnector.su/ и посмотри

на лиспе есть некий LMUD http://common-lisp.net/project/lmud/

Устроены они обычно очень просто, почти как http сервер, только даже проще. Один процесс принимает запросы от клиентов и форкает вспомогательные или запускает отдельные нити (как вариант, можно сделать конечный автомат для обработки запросов). Запросы от клиентов — команды, отклики — изменения в профиле игрока + описания карты + режим боя. Ещё по таймеру отрабатываются тики, закончился цикл (тик) — запускается реген маны/хп. В режиме боя изменяется цикл тиков, подсчитывается attack/damage бросанием костей вроде 1d10 attacker_nDm+attacker_damage_modifier-target_ac_modifier, вычисляется damage roll, количество аттак, ac защиты, модификаторы вроде спеллов/уязвимостей. Изменяются хиты-мана, по скорости изменения вычисляется уровень аттак и готовится сообщение.

Из тех MUD серверов, исходники которых я видел (штук 5), там обычно не используется ни Erlang, ни толком CL, голый Си. Иногда встречается интерпретируемый Pike http://en.wikipedia.org/wiki/Pike_(programming_language) как язык расширения, иногда другие языки, но редко, в основном пишут на голом Си. (В итоге, как понимаешь, никакого обновления вживую, сервера перезагружают).

Ещё можно посмотреть исходники Mud клиентов http://en.wikipedia.org/wiki/MUD_client. Там обычно простой telnet, но клиенты умеют алиасы, кнопки, карты, базы с инвертарём и прочие вкусности. Устроены они настолько же примитивно, как и серверы, даже ещё проще.

anonymous ()
Ответ на: комментарий от dave

Парсер-комбинаторы «встроены» в том смысле, что входят в стандартную библиотеку, а особенности самого языка делают их как бы действительно выглядящими как встроенные конструкции.

dave ★★★★★ ()

> задачи по глубокой обработке текстовых данных — парсинг с помощью регулярных выражений

нафига? обычно есть база с миром, и что-то ищется уже там, как объект со свойствами, а не plain text

модификация сценария развития событий налету, достаточно сложная генерация сюжетных линий исходя из действий пользователя.


можно пример? обычно так не делают. Делают квесты или миссии с чётко заданными действиями и вариантами действий, включая нетривиальные (вы видите туман — взять артефакт в руки и войти в туман; а какой артефакт и куда войти где-то может быть раскидана подсказка).
В квестах то же самое, вся сюжетная линия прописана заранее и выбирается в момент взятия квеста.
Хотя это была бы интересная фишка, например, разные персонажи разных классов могли бы по разному отыгрывать, разные сюжеты.

anonymous ()

> имитацию ИИ

у NPC обычно ИИ тупой конечный автомат, со всеми вытекающими. Ещё есть разница aggro mob/shy mob, атакует всех кого видит, не атакует, или убегает при первой возможности (aggo и shy одновременно — это жесть).

anonymous ()

>Возникла необходимость написать __игровой сервер__ для РПГ

Когдаж вы начнёте наконец делом заниматься.

anonymous ()

> И да, всячески приветствуется литература (желательно русскоязычная) по теории построения таких серверов. Можно с примерами на С.

(желательно русскоязычная)

You shall not pass!!!

anonymous ()
Ответ на: комментарий от Deleted

> Очень интересно. Вынашиваем похожую идею, но пока не хватает времени.

Проект JFF или коммерческий? Можете, вкратце рассказать, «в чем суть»?

alienclaster ★★★ ()
Ответ на: комментарий от Zubchick

> начиналось на 'e', кончалось на 'g'."

работа с регулярными выражениями

Вряд ли erlang хорош в разборе регулярных выражений. Поэтому все не так

У вас прям тендер, как в россии.

alienclaster ★★★ ()
Ответ на: комментарий от dave

> Могу еще в дополнение предложить связку Java/Scala

По-хорошему, Java хотелось бы использовать в крайнем случае

встроенный XML в синтаксис языка;

XML предполагается не использовать вообще

встроенные парсер-комбинаторы, где можно использовать также регулярные выражения для парсинга;

В CL вроде тоже есть

очень продвинутое ООП

Продвинутее CLOS?

Наверное, также как в самой яве.

Я не знаю как в Java, можете подробнее рассказать?

alienclaster ★★★ ()
Ответ на: комментарий от alienclaster

Да и хочется динамической типизации.

Высокая надежность со стороны ЯП и используемых технологий.

Взаимоисключающие параграфы.

Deleted ()
Ответ на: комментарий от alienclaster

> По-хорошему, Java хотелось бы использовать в крайнем случае

Ява может быть использована лишь как пускалка кода на Scala.

> Продвинутее CLOS?

Там типы. Продвинутое статически типизированное ООП. Например, в динамическом лиспе ковариантность и контрвариантность предполагаются сами по себе. Для этого ничего не надо изобретать. А вот, в статически типизированных языках такое есть далеко не везде.

> Я не знаю как в Java, можете подробнее рассказать?

В том смысле, что встроенных средств в Sun JDK мне неизвестно.

Нет, CL мне нравится. Просто хорошо иметь выбор при принятии решения.

dave ★★★★★ ()

Если проект Just For Fun, то любой понравившийся инструмент в руки в вперед. Если-же проект коммерческий, то java (на крайний случай scala/clojure но я бы не советовал) в руки. Иначе замучаетесь потом искать людей на проект, а это как показывает практика препятствие похуже любых технических.

Nagwal ★★★★ ()
Ответ на: комментарий от Deleted

ну вроде программы erlang зарекомендовали себя как надежные, главное сделать хорошую систему обработки ошибок. Да и типизация довольно грубый/сложный инструмент(зависит от степени вашего желания контроля над ошибками)

anonymous ()
Ответ на: комментарий от anonymous

> нафига? обычно есть база с миром, и что-то ищется уже там, как объект со свойствами, а не plain text

Персонаж сможет задавать собственные карты, предполагается так же генератор персонажей, конфиги к игре и, возможно, будет веб-бот для отдельных так сказать нужд

модификация сценария развития событий налету, достаточно сложная генерация сюжетных линий исходя из действий пользователя.

можно пример? обычно так не делают.

Изменение отношения NPC, их заинтересованность персонажем завист от его действий. Так же, предполагается, что NPC и «общий сценарий игры» будут _самостоятельно_ разрабатывать неповторяющиеся (или редко повторяющиеся) квесты (это и будет тот самый ИИ, его имитация)

В квестах то же самое, вся сюжетная линия прописана заранее и выбирается в момент взятия квеста.

Хочется, чтобы квесты были действительно не предопределены или точнее предопределялись на небольшой промежуток времени вперед. Квесту будут генерировать сами NPC и Игровой Мир вокруг, исходя из действий перса.

Хотя это была бы интересная фишка, например, разные персонажи разных классов могли бы по разному отыгрывать, разные сюжеты.

В идеале - разные персонажи _одинаковых_ классов отыгрывают по-разному, этакий игровой экзистенциализм :)

alienclaster ★★★ ()
Ответ на: комментарий от alienclaster

Человек! Ты напиши сначала диздок к своей игре. А то у тебя выходит, что язык программирования влияет на саму игру, что как-то глупо.

stave ★★★★★ ()
Ответ на: комментарий от anonymous

имитацию ИИ

у NPC обычно ИИ тупой конечный автомат, со всеми вытекающими.

Алена С++ не так давно рассказывала, что в игровой логике по сути нет единых алгоритмов для реализации поведения NPC. Есть только набор грубых хаков, заведомо фейловых с точки зрения и теории конечных автоматов и теории вероятности. Нейронные сети и прочие алгоритмы, по ее словам, для самообучения практически не используются.

Я предполагаю сделать просто набор более «веселых» хаков. Если это удастся выразить через конечные автоматы - будет здорово. Нет - будет набор костылей.

alienclaster ★★★ ()

Mono/.net/java, если планируется будущее у игры. Можно еще python попробовать, опыт EVE благо есть.

stave ★★★★★ ()
Ответ на: комментарий от anonymous

> Я не понял, ты MUD

MUD я не видел, предполагался ADOM с улучшенной графиков и более интерактивный, не пошаговый в том числе

alienclaster ★★★ ()
Ответ на: комментарий от anonymous

> You shall not pass!!!

На родном языке быстрее разбираться с неизвестной областью, думаю, это не секрет

alienclaster ★★★ ()
Ответ на: комментарий от Deleted

> Взаимоисключающие параграфы.

У Erlang плохо с надежностью? :) У кого лучше-то?

alienclaster ★★★ ()
Ответ на: комментарий от stave

> А то у тебя выходит, что язык программирования влияет на саму игру, что как-то глупо.

Не влияет язык на игру. А на удовольствие от процесса разработки повлиять может

alienclaster ★★★ ()
Ответ на: комментарий от stave

> Mono/.net/java, если планируется будущее у игры. Можно еще python попробовать, опыт EVE благо есть.

Mono/.net/java, если планируется будущее у игры.

FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

anonymous ()
Ответ на: комментарий от dave

> Например, в динамическом лиспе ковариантность и контрвариантность предполагаются сами по себе.

Неправда, там ковариативные типы, но в методах можно сделать любую вариативность (хоть в рандомном порядке) с помощью комбинаторов методов.

anonymous ()
Ответ на: комментарий от kelyar

> так и надо. погугли сначала.

Ничего, что в современном разговорном английском это *уже* считается архаизмом?

anonymous ()
Ответ на: комментарий от anonymous

Список - ковариантность, массив и вектор - ковариантность, функция/лямбда - контрвариантность по аргументу и ковариантность по результату.

dave ★★★★★ ()
Ответ на: комментарий от anonymous

в современном американском английском. британцы вполне себе используют shall.

val-amart ★★★★★ ()
Ответ на: комментарий от dave

Список - ковариантность, массив и вектор - ковариантность, функция/лямбда - контрвариантность по аргументу и ковариантность по результату.

Да конечно.

CL-USER> (defparameter *list* (list 1 2))                                                                                                        
          
*LIST*                                                                                                                                           
CL-USER> (pushnew "ha" *list*)         ;; STRING to T                                                                                                               
          
("ha" 1 2)                                                                                                                                       
CL-USER> (type-of "ha")
(SIMPLE-ARRAY CHARACTER (2))                                                                                                                     
CL-USER> (aref (first *list*) 0)      ;; T to STRING
#\h                                                                                                                                                   
CL-USER> 

Лисп напрочь инвариантен, потому что он динамический. И смысл имеет говорить только говорить о варинатности методов класса по аргументу, при использовании стандартного комбинатора методов получается контрвариативность. Хотя даже :after, :before и :around нарушают всякую вариантность.

anonymous ()
Ответ на: комментарий от anonymous

Контрвариантность аргумента функции, в том числе обычной необобщенной функции, имеет свойство передаваться другим типам. По-моему это проявляется на разного рода каналах. Но напоминаю, что мысль была в том, что для этого не нужно специальных средств как в статически типизированной Скале.

dave ★★★★★ ()
Ответ на: комментарий от anonymous

> You shall not pass!!!

shall > shall


—No, no thou hast not felt the lapse of hours!
For what wears out the life of mortal men?
'Tis that from change to change their being rolls;
'Tis that repeated shocks, again, again,
Exhaust the energy of strongest souls
And numb the elastic powers.

anonymous ()
Ответ на: комментарий от alienclaster

> Вряд ли erlang хорош в разборе регулярных выражений.

при желании, можно сделать DCG грамматики: http://en.wikibooks.org/wiki/Prolog/Definite_Clause_Grammars http://ru.wikipedia.org/wiki/DC-грамматика http://en.wikipedia.org/wiki/Definite_clause_grammar http://www.cs.sunysb.edu/~warren/xsbbook/node10.html

потом, можно реализовать регэкспы через Thompson NFA, см. сравнение производительности: http://swtch.com/~rsc/regexp/regexp1.html и далее по ссылкам,
сравнение «фичастости» http://en.wikipedia.org/wiki/Comparison_of_regular_expression_engines .

Erlang: http://patricklogan.blogspot.com/2007/09/apparently-fast-erlang-file-read-and... http://www.erlang.org/doc/man/re.html

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.