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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

Pro Java:

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

Pro Erlang:

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

Contra Erlang:

• незнакомый синтаксис и парадигма программирования
• не так хорошо известен; трудно найти опытных программистов для
• ВМ не так быстро, как Java

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

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

Answer 8

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

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

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

Это не решает вашу проблему «питон не многопоточен», но дает вам больше возможностей.

Answer 9

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

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

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

Answer 10

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

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

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