Что нужно знать для написания backend игрового сервера?

В качестве хобби занимаюсь разработкой игр, чуть junior знаю c# (в основном использую в написании игровой логики в Unity3d) и java (использую для работы с libgdx). Имею базовые знания в javascript, html и css. Есть стойкое желание познакомиться в python.

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

  1. В каком направлении начать копать, т.е. что нужно почитать из теории для созданию backend'ов?
  2. Какой ЯП и фреймворк подходит для написания подобного рода backend'а? Подходит ли связка java + spring или python + django или JavaScript + node.js? Если да, что что предпочтительнее?


З.Ы. пока начал с того что решил почитать про REST и RESTful сервисы.

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

Примерно то, что хочется реализовать в качестве затравки:

Задача минимум есть некое игровое приложение в котором игрок может создать учетную запись для хранения определённого набора данных в облаке (на сервере) например: личные достижения и возможность сохранить процесс прохождения игры (так как допускается что игра будет как для десктопа, так и для смартфона на базе андройд). Это в общем задача минимум. На на этой задаче мне хочется понять каким образом пишется серверная часть игры, что для этого нужно знать.
  • Вопрос задан
  • 4372 просмотра
Решения вопроса 2
Nipheris
@Nipheris Куратор тега C#
Александр Александров к сожалению, вынужден присоединиться к Сергей в том, что вы не знаете, что вам нужно от сервера.

Понимаете, все эти архитектурные паттерны - "бэкенды" в web-понимании, REST-ы - это все хорошо и удобно, но стандартные подходы web - это не всегда про игры и риалтайм-приложения.

Вы должны принять много различных решений, прежде чем браться что-то делать.

> есть сервер, к которому обращается игровое приложение что бы записать или извлечь определенных данные игрока
Вот в этих "определенных данных" и вся суть. Можно по-разному распределять логику между клиентом и сервером, но нередко, особенно в играх, где нужна устойчивость к мошенничеству, большая часть игровой логики находится на сервере. Это гораздо больше, чем "извлечь данные игрока". Если игровая логика находится на сервере, то тогда и требования к процессу обмена данными соответствующие - в REST особого смысла нет, т.к. все равно придется вводить понятие "сессии" или "соединения" с сервером, и хранить его состояние. И ваша основная задача будет не в легкой масштабируемости на заранее неизвестное число клиентов, а наоборот, в поддержании максимально комфортного игрового процесса для имеющихся игроков, а масштабирование будет на втором месте и будет достигаться немного иными архитектурными решениями.

Многие крупные игровые проекты с большой долей логики на сервере используют свои протоколы обмена (как правило, бинарные) поверх обычного TCP-соединения. Многие применяют различные языки описания таких протоколов, чтобы было проще управлять разработкой, и вносить изменения в протокол (например, по таким описаниям можно автоматически генерировать часть серверного и клиентского кода). Например, Близзы, насколько мне известно, используют Protocol Buffers для Diablo 3.

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

возможность сохранить процесс прохождения игры

вам нужно решить, какой уровень доверия у этих данных. Это во многом и будет определять архитектуру. Если ваш проект соревновательного характера, и подмена данных о достижениях или подтасовка результатов отдельных игр или матчей может поставить крест на всем проекте, то тогда клиент не может быть доверенной стороной, и критичная логика должна быть на сервере.
Ответ написан
saboteur_kiev
@saboteur_kiev Куратор тега Python
software engineer
"что бы достичь желаемого :( "

А вы конкретизируйте желаемое.
Если вы хотите браузерку, это одно.
Если вы хотите писать свой клиент - на чем сможете осилить? И следовательно какой протокол обмена данными будете делать? Свой? Тогда копайте в нетворк
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
dima9595
@dima9595
Junior PHP
С первым пунктом помочь к сожалению не могу, а вот со вторым - могу посоветовать: Что хорошо знаешь, на том и пиши сервер. Можешь хоть на C#, Java, Python или на JS написать сервер...
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы