Хороший язык для разработки игрового сервера?

Мне просто интересно, какой язык будет хорошим выбором для разработки игрового сервера для поддержки большого (тысячи) числа пользователей? Я баловался на python, но понял, что это будет слишком много неприятностей, так как это не порождает потоки по ядрам (что означает 8-ядерный сервер = 1 основной сервер). Мне также не очень нравился этот язык (что "я" собрал меня).

Я знаю, что С++ - это язык для работы с точки зрения производительности, но я ненавижу его. Я не хочу иметь дело с его неряшливым синтаксисом, и мне нравится, когда моя рука хранится на управляемых языках. Это приводит меня к С# и Java, но я открыт для других языков. Я обожаю простоту .NET, но мне было интересно, если бы скорость была мудрой, это было бы хорошо для этой работы. Имейте в виду, так как это будет развернуто на сервере Linux, оно будет работать в среде Mono - не уверен, что это важно. Я знаю, что Java синтаксически очень похож на .Net, но мой опыт с ним ограничен. Существуют ли какие-либо рамки для этого или все, что нужно для облегчения разработки?

Пожалуйста, помогите мне и моему придирчивому себе прийти на решение.

ОБНОВЛЕНИЕ: Я не хотел звучать так придирчиво, и я действительно не думаю, что был. Единственный язык, который я действительно исключил, был С++, Python мне не нравится из-за проблемы масштабируемости. Я знаю, что есть способы общения между процессами, но если у меня есть 8-ядерный сервер, зачем мне нужно делать 8 процессов? Есть ли более элегантное решение?

Ответ 1

Erlang - это язык, который разработан вокруг concurrency и распределяется по нескольким серверам, что идеально подходит для серверного программного обеспечения. Некоторые ссылки об Erlang и игровых серверах:

http://www.devmaster.net/articles/mmo-scalable-server/

http://www.erlang-consulting.com/euc2005/mmog/mmog_in_erlang.htm

Я подумываю написать игровой сервер в Эрланге.

Ответ 2

Мне очень жаль это говорить, и я знаю, что рискую здесь здесь, но это не похоже на то, что там есть язык. Все языки программирования имеют свои причуды, и программисты просто должны адаптироваться к ним. Полностью можно написать рабочий сервер в Python без классов (исключая ссылки на класс "self" ), а также так же легко написать С++ с чистым синтаксисом.

Если вы хотите развернуть кросс-платформу и хотите также развивать кросс-платформу, лучшим вариантом будет, вероятно, Java. Это более короткие циклы разработки, чем скомпилированные языки, такие как C и С++, но более высокая производительность (возможно, но я всегда был анти-Java = P), чем интерпретируемые языки, такие как Python и Perl, и вам не нужно работать с неофициальными реализациями, такими как Моно, которые могут время от времени не поддерживать все языковые функции.

Ответ 3

Возможно, я немного не по теме, но тема меня интересует, поскольку у меня есть (хобби-мудрый) работающий на довольно многих игровых серверах (серверы MMORPG) - на чужом коде, а также на моем. Там есть литература, которая будет интересна вам, напишите мне, если вы хотите получить некоторые ссылки.

Одна вещь, которая поражает меня в вашем вопросе, - это желание обслуживать тысячу пользователей от многопоточного приложения. Из моего скромного опыта это не работает слишком хорошо.:-)

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

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

  • Сделайте их независимыми, поэтому неудачный процесс будет неактуальен для службы.
  • Сделайте их маленькими, так что различные части службы и то, как они взаимодействуют, легко понять.
  • Не позволяйте пользователям напрямую общаться с гамелоговым OR DB. Записывать прокси - сетевые стеки могут и будут демонстрировать странное поведение на разных архитектурах, когда у вас множество пользователей. Также убедитесь, что позже вы можете "очистить" /отфильтровать прокси-серверы.
  • Имейте процесс, который будет контролировать только другие процессы, чтобы убедиться, что они все еще работают правильно, с возможностью перезапуска компонентов.
  • Сделайте их доступными для распространения. Координировать процессы через TCP с самого начала или вы столкнетесь с проблемами масштабируемости.
  • Если у вас большие ландшафты, рассмотрите возможность динамического разделения нагрузки путем деления серверов по географии. Не нужно, чтобы каждый серверный процесс сохранял все данные в памяти.

Я портировал несколько таких движков, написанных на С++ и С# для хостов, работающих на Linux, FreeBSD, а также Solaris (на старом UltraSparc IIi - да, моно все еще работает там:). По моему опыту, С# достаточно быстр, учитывая, какое старое оборудование работает на этой спаркерной машине.

Промышленность (насколько мне известно) имеет тенденцию использовать много С++ для работы в сервисе и внедряет языки сценариев для реальной игровой логики. Ах, написано слишком много - крутая тема.

Ответ 4

Говоря о чистой производительности, если вы можете запускать Java 6, вы получаете производительность около 1:1 по сравнению с оптимизированным С++ (несмотря на специальные случаи, иногда Java быстрее, иногда С++), единственная проблема, которую вы будете иметь, как библиотеки баз данных, взаимосвязь, масштабируемость и т.д. Я считаю, что для каждой из этих проблем существует множество полезных решений, но вы не найдете ни одного языка, который бы разрешил все для вас, поэтому я должен дать вам старый совет: выберите нужный вам язык и используйте его.

О, ты все еще читаешь это?:) Ну, вот некоторые дополнительные указатели.

  • EVE Online использует Python для своего клиентского и серверного кода, и он как с ошибкой, так и с запаздыванием, как-то я не думаю, что я должен напишите здесь, чтобы быть примером того, как Python может быть расширен (плохо) обслуживать огромное количество пользователей.
  • В то время как у Java есть отличные решения для различных связанных проблем, это действительно не лучший язык для огромного количества пользователей; он не масштабируется до крайностей без настройки. Однако, как говорят, решения для нескольких VM, которые несколько исправляют проблему, например Terracotta, хорошо выполняют эту работу.
  • В то время как С++ довольно громоздкий, он позволяет для такого взаимодействия на низком уровне с системой, что вы действительно можете найти себе то, что считаете невозможным. Я думаю о чем-то вроде динамического межкластерного микрокластерирования блоков кода времени выполнения для "максимально возможного заполнения" всех возможных тактовых циклов процессора для максимальной производительности и т.д.
  • Mono намного отстает от .NET VM/эквивалента на платформах Windows, поэтому вы не сможете использовать последние и самые интересные функции С#. Однако лицензии OEM-производителей Windows XP (x64) настолько смехотворны на данный момент, что с небольшими инвестициями вы можете получить кучу этих данных, и тогда вы можете запустить свой код на платформе, на которой он должен был быть. И не впадайте в обман Linux, Linux - ваш спаситель, только если вы действительно знаете, как его использовать, и особенно XP сейчас довольно прост и стабилен.

Ответ 5

Какая производительность вам нужна?

twisted отлично подходит для серверов, которым требуется много concurrency, как и erlang. Либо поддерживает массивный concurrency легко и имеет возможности для распределенных вычислений.

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

Ответ 6

Более подробная информация об этом игровом сервере может помочь людям лучше ответить на ваш вопрос. Является ли это игровым сервером в смысле чего-то вроде выделенного сервера Counter Strike, который сидит в фоновом режиме и поддерживает многопользовательские взаимодействия, или вы пишете что-то, что будет размещаться на веб-сервере HTTP?

Лично, если бы это был я, я бы рассматривал Java или С++. Мои личные предпочтения и навыки, вероятно, приведут меня к С++, потому что я нахожу Java неуклюжей для работы на обеих платформах (moreso на Linux) и не уверен, что С# уже готов к прайм-тайм в Linux.

Тем не менее, вам также нужно, чтобы на этом сервере было довольно значительное сообщество, прежде чем производительность вашего языка будет настолько проблематичной. Я бы посоветовал написать его на любом языке, который вы можете на данный момент, и если ваша игра будет иметь достаточный размер, тогда инвестируйте в переписывание.

Ответ 7

Вы также можете использовать Java и скомпилировать код с помощью GCC для собственного исполняемого файла.

Таким образом, вы не получаете удар по производительности в байт-коде. (Да, я знаю - Java из коробки работает так же быстро, как и С++. Должен быть только я, который всегда измеряет разницу в производительности фактора 5). Недостатком является то, что Java-интерфейс GCC не поддерживает все языковые функции Java 1.6.

Еще один выбор - использовать ваш язык по своему выбору, сначала запустить код, а затем перенести критически важные вещи в собственный код. Почти все языки поддерживают привязку к скомпилированным библиотекам.

Это не решает, что ваш "python не многопоточен" - проблема, но он дает вам больше возможностей.

Ответ 8

Очевидными кандидатами являются Java и Erlang:

Pro Java:

  • простота разработки
  • хорошие среды разработки
  • стабильность, хорошие трассировки стека
  • известный (легко найти опытных программистов, множество библиотек, книг,...)
  • довольно быстрая, зрелая VM

Pro Erlang:

  • доказано в системах, которым требуется время бесперебойной работы 99,9%
  • возможность обновления программного обеспечения без простоя
  • масштабируемый (не только многоядерный, но и многопроцессорный)

Contra Erlang:

  • незнакомый синтаксис и парадигма программирования
  • не так хорошо известно; трудно получить опытных программистов для
  • VM не так быстро, как java

Если ваш игровой сервер в основном работает диспетчером событий (с небольшим количеством базы данных, спрятанным), парадигма, управляемая сообщениями Erlang, должна быть хорошей.

В этот день и возраст я бы не стал использовать неуправляемый язык (например, C или С++); предельные преимущества производительности просто не стоят хлопот.

Ответ 9

Это может сильно зависеть от того, на каком языке ваша "игровая логика" (вы можете знать этот термин как "бизнес-логика" ) лучше всего выражать. Например, если логика игры лучше всего выражается в Python (или любой другой конкретной язык), лучше всего просто написать его в Python и решить проблемы производительности с помощью многопоточности или кластеризации. Несмотря на то, что это может стоить вам много времени, чтобы получить производительность, которую вы хотите использовать на Python, это будет меньше того, что время, которое вам понадобится, чтобы выразить "игрок A теперь бросает уровень 70 Заклинание тьмы в радиусе 7 единиц все подразделения, которые разговаривали с игроком B и...." в С++.

Что-то еще, чтобы рассмотреть, какой протокол вы будете использовать для общения с клиентами. Если у вас есть сложный двоичный протокол, С++ может быть проще (особенно если у вас уже был опыт перед этим), в то время как JSON (или аналогичный) может быть проще разобрать на Python. Да, я знаю, что С++ и python - это не языки, на которые вы ограничены (или даже учитываете), но я обычно отношусь к ним.

Наверное, спускается к тому, на каком языке вы лучше всего. Плохо написанная программа, вы ненавидели запись будет хуже, что один написано на языке, который вы знаете и наслаждаться, даже если плохо написано программой была в спорном более мощном языке.

Ответ 10

Вы также можете посмотреть jRuby. Он поставляется с множеством преимуществ Java и множеством преимуществ Ruby в одном аккуратном пакете. У вас будет доступ к огромным библиотекам с обоих языков.

Ответ 11

Каковы ваши цели? Не создание самой игры, но почему вы ее создаете?

Если вы делаете это, чтобы изучить новый язык, выберите тот, который вам кажется наиболее интересным (т.е. тот, который вы больше всего хотите изучить).

Если это по какой-либо другой причине, лучшим языком будет тот, который вы уже знаете лучше всего, и наслаждайтесь использованием большинства. Это позволит вам сосредоточиться на разработке логики игры и получении чего-то вверх и запуска, чтобы вы могли видеть прогресс и оставаться мотивированным продолжать, вместо того, чтобы увязнуть в деталях языка, который вы используете, и потери интереса.

Если ваш любимый язык в какой-то степени оказывается недостаточным (слишком медленный, недостаточно выразительный, любой), вы можете переписать разделы проблем на более подходящем языке, когда возникнут проблемы - и вы не будете знать лучший язык для обратитесь к конкретным проблемам, пока не узнаете, в чем проблема. Даже если ваш выбранный язык окажется совершенно непригодным для конечного использования в производстве, и все это нужно переписать, оно даст вам рабочий прототип с проверенной логикой игры, что значительно облегчит работу с новым языком.

Ответ 12

Вы можете посмотреть Stackless Python. Это альтернативный интерпретатор Python, который обеспечивает большую поддержку concurrency. Оба сервера EVE Online и клиентское программное обеспечение используют Stackless Python.

Отказ от ответственности: я не использовал Stackless Python самостоятельно, поэтому я не могу предоставить какие-либо из первых рук его эффективность.

Ответ 13

В разработке есть довольно классная среда, которая отвечает всем вашим потребностям:

Project Darkstar от Sun. Поэтому я бы сказал, что Java - хороший язык для разработки игрового сервера: -)

Ответ 14

Я знаю, что facebook использует комбинацию Erlang и С++ для своего движка чата.

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

http://incubator.apache.org/thrift/

Ответ 15

С++ и Java довольно медленны по сравнению с C. Язык должен быть инструментом, но не костылем.