Сервер для многопользовательской игры?

Question

[Nick2015]

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

- Прежде всего каким образом должен работать сервер? Он должен все действия пользователей в момент их выполнения сразу синхронизировать сервер и сохранять в ту же mysql?
- Технология для самого сервера? В интернете очень много видел отзывов о nodejs как хороших так и плохих. Поэтому есть некоторая неопределенность на счет NodeJs. Также еще интересует такая вещь как ASP.НЕТ. Подходит она для таких целей и оправдано ее использовать?
- Допустим при выборе Node, в самом клиенте я должен обрабатывать ответ сервера. С этим понятно, но в каком формате будет этот ответ JSON( все верно) или я не правильно понимаю???
Для додатка(не игры) я использовал php + mysql "сервера для хранения данных". Правильно ли я делал?
Хотел бы от вас услышать некие советы в построение, оптимизации, правильном выборе технологий для подобного сервера который предназначен для сетевой игры.

Comments

[Владислав]

Товарищ! Научитесь формулировать главный вопрос, уважайте других участников, если хотите, чтобы вам помогали!!!

[Станислав Силин]

Nick2015 что должен делать ваш сервер?

[Pantene742]

насчет скорости Node. будет не медленее чем ASP может даже и скорее. так как в отличие от PHP, программа (сервер написан на Node) интерпритируется и после запуска стает нативной как та что написана на C++. отсутсвие многопоточности для выполнения кода. также не беда. так как можно обойтись несколькими форками. молненостность виполнения настколько велика что я думаю даже такую игру как Контра можно поднять на ноде и это будет в одном процесе/потоке. но вообще если это будет что то крупное то просто современем переписать на С++. C# и Java в пару раз дорожже сервак надо. Мне кажется что даже на многопоточных языках, на каждого игрока не делают отдельный поток. потоки разбиваются на инструкции и поочередно по чючють выполняются в процессоре. и перед тем как взятся за новый поток процессор прерывается записывая данные в кеш. и это перезаписывание (сохранение состояния потока) времязатратно.

Answer 1

[Gizmothron]

Подходит и Node.JS и PHP и C++ и Ruby и ASP.NET и Python и Java и пр. и пр. и пр.

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

И есть хорошая документация и шаблоны по взаимодействию сервера и Android для Google AppEngine.

Из минусов - привяжитесь к Google AppEngine. Из плюсов - там очень многое есть из коробки и уже заточено под Android, а у Android заточено под Google AppEngine.

Comments

[Nick2015]

За время вашей работы с Google AppEngine вы использовали платную версию??

[Gizmothron]

Nick2015: Часть проектов так и не выходят за платные лимиты.
Но карту банковскую там нужно привязать все равно.

Часть проектов посещаемые - и уже платные. Что самое смешное - за посетителей мы платим копейки (ну там на уровне 40 рублей в месяц), а основные затраты идут на нашу собственную логику (т.н. backend instance)

Можно еще хитрее - взаимодействие с пользователями реализовать через Google AppEngine, а основную логику повесить тут же у Гугля на обычном VDS.

[Nick2015]

Опыта роботы с сервисами гугл не имел юзал только API авторизации, тому сори за возможно тупой вопрос... Если я юзаю APP ENGINE там реализовую некую логику сервера, потом создав игру на кросплатформеном движке, сервак будет и работать с ios, win, android или только android? И если можно то некий материал по этой теме, полезный по вашему мнению, а то незнающий человек может наткнутся на то что ему точно не нужно...

[Nick2015]

Gizmothron: Увидел следующую вещь "Вы получите кредит в 300 долларов США на 60 дней. Средства с вашего фактического счета не будут списываться до тех пор, пока вы не перейдете на платный аккаунт. Отменить пробный период можно в любой момент." - Я думал там есть некий лимит на один день, а не на аккаунт в целом... Об это можно по подробней?

[Gizmothron]

Nick2015:
https://cloud.google.com/appengine/docs/quotas
Пока не превышаете Free Limits - это бесплатно. Навсегда.

Лимиты (так и деньги при их превышении) считаются на все отдельно - на трафик, на процессорное время, на БД и пр.

Это не имеет ограничений по времени.

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

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

Но банковскую карту все равно привязать нужно. С нее снимут какие-то копейки, чтобы убедиться, что у вас серьезные намерения.

[Gizmothron]

Nick2015:
Хостинг Гугля называется Google Cloud Platform.
Там много разных видов хостинга. Тот, о котором мы с вами разговариваем называется Google AppEngine.

Тот что ближе к классическому хостингу, называется Google Container Engine, Compute Engine...

Но мы говорим не о нем.

Google AppEngine - это хостинг типа PaaS, то есть в отличие от классических хостингов, которые IaaS, вам не нужно заниматься администрированием.

Так называемое нулевое администрирование. Это очень удобно. И можно вписаться в бесплатные лимиты, если правильно напрограммировать.

Но это требует разработки строго по правилам Google. Классическое веб-приложение/веб-сервис/веб-сайт - быстро выйдет за бесплатные лимиты. Поэтому настоятельно рекомендую следовать примерам для Google AppEngine. Таких примеров полно.

Google Endpoints - это взаимодействие с внешним миром. По сути это RESTful API с некоторыми наворотами.

Оно совместимо с кем угодно - с Android, с iOS, c веб-сайтами на JavaScript.

Конкретно под Android - есть примеры как использовать Google Endpoints. Думаю, но не помню, что должны быть примеры и под iOS.

Физических ограничений на операционные системы клиентов никаких нет, так как Google Endpoints это самый что ни на есть универсальный REST.

[Gizmothron]

Nick2015: В официальной документации на Google AppEngine есть хорошие примеры. Берите конкретно под Go. Есть еще там и другие языки программирования, но они больше жрут ресурсов сервера.

[Gizmothron]

Есть так и примеры как организовать чат и пр. и т.п.
Связь с приложениями на смартфонах.
Аутентификация
и пр.
и др.

[Nick2015]

Gizmothron: С Go я ничего не делал и через это все таки спрошу на сколько больше, ресурсов жрет:
- java;
- php;
- javascript;
- pyton.
Где можно посмотреть такую статистику..

[Gizmothron]

Nick2015:
Из этого списка

Java быстра и надежна. Но любит оперативную память.
Остальные примерно равны.

[Gizmothron]

Nick2015: На Google AppEngine можно и Яву запускать.

[Nick2015]

Gizmothron: я знаю что ее там можно запускать, те все языки если не ошибаюсь там можно, но в неком соотношение в сравнение с Go сколько для этого всего понадобиться ресурсов или чего оно там жрет :)

[Gizmothron]

Nick2015:
Go самый экономичный по использованию ресурсов по сравнению со всеми вышеперечисленными.

Разница - существенна. Рекомендую все же изучить.

[Gizmothron]

Nick2015:
Он - простой.

[Gizmothron]

Nick2015:
Дело в том, что Go компилируется в нативный бинарник и испольняется на процессоре безо всякой виртуальной машины и без интерпретатора, в отличие от РHP/Java/JavaScript/Python/Ruby/Perl/Erlang.

[Nick2015]

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

[Nick2015]

Gizmothron: И очень страная вещь, чесно говоря еще в гугле не искал но все ж какую среду юзать??? Eclipse + плагин или есть что то другое и мощное аля Intelllij for java....

[Gizmothron]

Nick2015:
Документация - хорошая
https://cloud.google.com/appengine/docs/go/
https://golang.org/doc/

Инструментарий для работы с Google AppEngine
https://cloud.google.com/appengine/downloads
Там есть examples

Вот как раз пример про связь сервера с клиентом,
если вам требуется постоянное и быстрое взаимодействие с сервером
https://cloud.google.com/appengine/docs/go/channel...

[Gizmothron]

Nick2015:
Что привычнее, то и используйте.

Допускаю, даже Android Studio с плагином для Go можно (это же то же самое что и Intellij IDEA, только заточенная).

Можно использовать LiteIDE. Легкую и быструю, написанную с использованием самого Go.

Насколько я знаю, большинство предпочитает использовать Intellij IDEA.

Плагины для Go имеются для основных программистских редакторов: для Sublime, для Emacs, для Atom, для Vim.

[Nick2015]

Gizmothron: Отлично, пока что буду изучать, большое спасибо, если что я вам напишу :)

Answer 2

[OnYourLips]

Для начала стоит определиться, будет ли игра требовать real-time сетевой код, или нет.
Если нет (99% ситуаций), то пишете сервер на любом удобном языке в вебе (PHP, Java, C#, Python, Ruby) с REST API. Специфические асинхронные решения (Node.js, Go) лучше не брать.

Если требует, то инструменты будут уже другими, стоит ограничиться java.nio, Go или Node.js. На других стеках тоже можно, например с помощью ReactPHP, но это не самые популярные решения.

Comments

[Nick2015]

Как по мне, после каждого задания должно сохранят некий результат, так же будет некая игровая локация в который будет до 20 человек "аля турнир" и между этим персонажами будет некое действие, я та понимаю надо real-time, и юзать что то с ( java.nio, Go или Node.js.)?

[Gizmothron]

Это почему Go лучше не брать?
Потому что лично вы его не осилили, что ли?
Go как раз хорошо для игры тем, что эффективнее использует ресурсы сервера, чем Java, PHP, Net, Python, Ruby. Для игры это, имхо, важно.

Внешняя часть - RESTful, к примеру - от языка вообще ну никак не зависит.

[OnYourLips]

Gizmothron: я написал, что Go хороший вариант, и даже написал, в каких ситуациях.
Вы мой ответ до конца прочитали?
Или вы любитель применять недавно изученные технологии для всего подряд, не думая, что для определенных задач некоторые средства подходят лучше, чем другие?

Nick2015: если подразумевается взаимодействие между игроками в реальном времени, то вам нужны решения типа java.nio, Go или Node.js.

[Nick2015]

OnYourLips: с js, java - все норм, писать можно, с Go не пробивал. И несмотря на все это посоветуйте с чего лучше начать изучение... А то щас легко найду в гугле пое**сь неделю другую, и потом узнаю что это все не то, плохой подход и т.д.

[OnYourLips]

Nick2015: лучше делегировать такую задачу человеку с опытом.
Статья поможет с выбором, посмотрите на примеры кода, чтобы понять, какой язык вам больше нравится: https://habrahabr.ru/post/197926/
Node.js я бы рассматривать не стал, если вы не имели раньше дел с JS.

[Gizmothron]

Nick2015:
Можете и с Java, но больше ресурсов жрет.

[Gizmothron]

OnYourLips:
Сам ты новый. Я с Go уже 4-й год.

[OnYourLips]

Gizmothron: но сообщения до конца так читать и не научился. Ведь надо быстрее ответить, а читать незачем.

[Gizmothron]

OnYourLips: Пишите проще и люди будут вас понимать.

[OnYourLips]

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

[Gizmothron]

OnYourLips:
Да не будет ни в одном из вариантов плохим.

Кроме одного - если вы круто лучше знаете другой язык.

[OnYourLips]

Gizmothron: первая ситуация - обычный сайт с API.
С каких пор Go стал хорошим инструментом для написания сайтов вне сферы хайлоада, для обычной бизнес-логики?

[Gizmothron]

OnYourLips:
Если вы про примитивные сайты, где можно HTML и движок сервера перемешивать - то там PHP лучше всех.

Для всех остальных задач - что Python, что JavaScript (Node.Js), что Java, что PHP, что Ruby, что Go - все равны с точки зрения удобства написания.

[Gizmothron]

OnYourLips:
Ну и CMS как то принято с PHP...

[OnYourLips]

Gizmothron: не равны. В некоторых областях (ху*к, ху*к и в продакшен) лучше справляются PHP, Python и Ruby, в других (кровавый энтерпрайз) Java, C# и PHP, в третьих (хайлоад) - Java, Go и Node.js.
Универсальных инструментов нет. Для разных задач - разные инструменты.

[Gizmothron]

OnYourLips:
PHP - потому что проще для простейших сайтов благодаря встроенному HTML.

Все же "обычные" языки - равны по возможностям.
Я не понимаю, что мешает использовать Highload-языки на простых задачах.
Go - не Erlang какой-нибудь. Там такие же простые как и в Python, Ruby, Node.Js, Java.

[OnYourLips]

Gizmothron: почему простейших? Для сложнейших он тоже один из лучших вариантов (вместе с Java и C#). Код на современном PHP совсем не похож на код PHP 4, который вы имеете ввиду.
Я работал с огромным проектом на PHP (один из полусотни разработчиков в компании), и не представляю его даже на экосистемах Python или Ruby. А писать такое на Node.js или Go - это просто самоубийство.
Кстати, запрещались любые оптимизации кода, которые шли во вред читаемости ;)

[Gizmothron]

OnYourLips:
У PHP есть одно родовое отличие - с ним проще прочих перечисленных выше на простейших сайтах.

Что PHP не пригоден для сложных сайтов - я не писал.

[Gizmothron]

OnYourLips:

Я работал с огромным проектом на PHP (один из полусотни разработчиков в компании), и не представляю его даже на экосистемах Python или Ruby. А писать такое на Node.js или Go - это просто самоубийство.

Если проект заточен на "живые" HTML-шаблоны PHP, то да. Для других языков была бы другая архитектура.

[OnYourLips]

Gizmothron:
> с ним проще прочих перечисленных выше на простейших сайтах
не согласен. Безосновательное суждение, ни на чем не основанное.

> Если проект заточен на "живые" HTML-шаблоны PHP, то да. Для других языков была бы другая архитектура.
И снова ты не прав.
Писать систему на сотни человеколет с монолитным приложением? Я надеюсь, что ты шутишь.

> Для других языков была бы другая архитектура.
Очередная порция выводов, основанных на непонимании того, как сейчас используется язык.
Я повторю: не путай современный PHP и PHP 4.

[Gizmothron]

OnYourLips:

Писать систему на сотни человеколет с монолитным приложением? Я надеюсь, что ты шутишь.

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

Бредятина.

[Gizmothron]

OnYourLips:

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

Заинтриговал. Опиши архитектуру того проекта на PHP.
Не верю, что нельзя написать эффективно на других языках.

[OnYourLips]

Gizmothron:

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

> Заинтриговал. Опиши архитектуру того проекта на PHP.
Десяток приложений, связанных между собой и приложениями на других языках (там, где нужна высокая производительность) по SOAP и шине, некоторые из них смотрят в корпоративную сеть через REST API (т.к. SPA). И только один сервис смотрит в интернет и рендерит странички на сервере.

[Gizmothron]

OnYourLips:

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

У нас тут разговор о языках.
Вот я и спрашиваю - к чему вы привели пример про монолит/немонолит в контексте языков?
У языков есть какие-то ограничения?

[Gizmothron]

OnYourLips:

Десяток приложений, связанных между собой и приложениями на других языках (там, где нужна высокая производительность) по SOAP и шине, некоторые из них смотрят в корпоративную сеть через REST API (т.к. SPA). И только один сервис смотрит в интернет и рендерит странички на сервере.

А в чем же здесь ограничение? Вы писали, что "только под PHP задача ложиться и вы не представляете как ее реализовать на Go"

[OnYourLips]

Gizmothron:
> к чему вы привели пример про монолит/немонолит в контексте языков?
Про это начал говорить ты:

Если проект заточен на "живые" HTML-шаблоны PHP, то да. Для других языков была бы другая архитектура.

> Вы писали, что
Не надо свои слова мне в рот вкладывать. Я такого не писал.

[Gizmothron]

OnYourLips:

Не надо свои слова мне в рот вкладывать. Я такого не писал.

Да ты че:

Я работал с огромным проектом на PHP (один из полусотни разработчиков в компании), и не представляю его даже на экосистемах Python или Ruby. А писать такое на Node.js или Go - это просто самоубийство.

Вы так и не привели пример - а почему, собственно нельзя на Go или Python.

[OnYourLips]

Gizmothron: переформулирую: не представляю ее в аналогичных качественно-временных рамках (т.к. это невозможно). Хотя и предыдущая формулировка была вполне понятной.

Еще раз скажу: для разных задач лучше подходят разные инструменты. Писать стартапы на java так же неуместно, как энтерпрайз на ruby.

[Gizmothron]

OnYourLips:

в аналогичных качественно-временных рамках (т.к. это невозможно)

кроме огромного количества дешевых пхп-кодеров других причин не вижу. но доверять дешевым пхп-кодерам сложную систему.....?

Писать стартапы на java так же неуместно,

LinkedIn

как энтерпрайз на ruby.

Вам известна история становления Ruby как серьезного и удобного инструмента? С появлением Rails пошла на него мода.

А почему появились Рельсы? Потому что писался Basecamp, который далеко не homepage.

[OnYourLips]

Gizmothron: такое чувство, что ты нахватал где-то обрывочных знаний, но опыта у тебя нет.
Ради интереса узнай, сколько получают PHP-разработчики с опытом 5+ лет.
Ты застрял в прошлом веке, во временах PHP 4.

> LinkedIn
Не хочешь освежить себе память и почитать, когда он был основан, и в каком тысячелетии был основан другой проект Хоффмана, ему предшествующий?

> писался Basecamp, который далеко не homepage
В котором бизнес-логика на уровне CRUD.

[Gizmothron]

OnYourLips:

Ради интереса узнай, сколько получают PHP-разработчики с опытом 5+ лет.

Закон спроса и предложения. ПХП-истов полным-полно, по сравнению с Goшниками. Зарплаты в Гоу в полтора раза больше. Проверено.

[OnYourLips]

Gizmothron: посмотрел hh по Москве, отфильтровав по 175+. Нет вакансий для программистов Go. Вакансии для программистов PHP есть.

[Gizmothron]

OnYourLips:

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

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

В котором бизнес-логика на уровне CRUD.

Вы про взаимодействие пользователей?
;)

[Gizmothron]

OnYourLips:

посмотрел hh по Москве, отфильтровав по 175+. Нет вакансий для программистов Go. Вакансии для программистов PHP есть.

Патамушто PHP занимает 85% рынка. А Go - вовсе не оставшиеся 15%, а поменьше.

Я не возражаю. Заблуждайтесь дальше. Мне конкуренции меньше.
Работа есть.

[OnYourLips]

Gizmothron: работы очень мало, платят мало, либо зарплатная вилка не указана.
Или данные самой крупной биржи труда в России для тебя не авторитет?
К слову говоря, мы не конкуренты.

[Gizmothron]

OnYourLips:
Вы видите объявления, то есть только то, о чем мечтают работодатели. Вы видите объявления потому что они висят месяцами.

Все отлично с работой.
)))

[Gizmothron]

OnYourLips:

Писать систему на сотни человеколет с монолитным приложением? Я надеюсь, что ты шутишь.

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

Ох уж эта мода на микросервисы и завись к Цукербергу - все мнят себя вторым Фейсбуком и смолода готовятся к горизонтальному масштабированию.

До идеи микросервисов прекрасно писали огромные приложения где тысячи программистов работали годами.

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

Монолитное приложение само по себе и работает шустрее и проще в разработке. Если не нужно горизонтальное масштабирование.

Сотни человеко лет - не при чем совершенно.

Answer 3

[Saboteur]

"Пришло время когда нужно разработать сервер для онлайн игры"

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

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

Answer 4

[Виктор Королев]

nodejs+socket.io - очень хороший выбор для собственного сервера. Также полно готовых решений.
Советую познакомиться с этим циклом статей. Много интересного.

Answer 5

[Владимир Грабко]

у меня php + go + mysql + redis + nginx