Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Android игра через интернет . Нужен совет.

Android игра через интернет . Нужен совет.

Поделиться

Страницы: 1 2 Следующая

CrunkorПользовательwww23 апр. 201712:38#0
Добрый день.
Есть идея написать игру на Android. Вкратце напишу архитектуру:
1. Несколько человек нажимают кнопку "играть"
2. Из них выбирается главный.
3. Все данные передаются в формате json.

Теперь вопрос - как лучше это реализовать ? Я вижу тут 2 пути развития :
1. Создать какой-то сервер
2. Главный из игроков становится сервером.

Что из этого более практично ?
Какой библиотекой можно реализовать эти варианты ?

gambit_ozПостоялецwww23 апр. 201712:54#1
Вообще вариант 1. лучше всего, так как для варианта 2 все равно нужен промежуточный сервер чтобы узнать IP адреса игроков.
За вариант 1 придется платить денежку, тут несколько вариантов, либо комп с белым IP либо сервис предоставляющий эту услугу - место на их HDD под вашу игру.

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

по поводу библиотек - первое что приходит на ум Node.js - она мультиплатформенная.

Правка: 23 апр. 2017 12:55

CrunkorПользовательwww23 апр. 201713:31#2
gambit_oz
> За вариант 1 придется платить денежку, тут несколько вариантов, либо комп с
> белым IP либо сервис предоставляющий эту услугу - место на их HDD под вашу
> игру.
У меня есть один хостинг, думал повесить там какой-то php фреймворк.
А что должен делать этот сервер? Допустим один игрок начал действовать , все его действия записаны в json, он отправляет этот файл на сервер, сервер записывает эти данные в бд и другие игроки берут данные из этой бд? Это вообще именно так реализуется ?

Правка: 23 апр. 2017 13:32

ant0nПостоялецwww23 апр. 201717:16#3
Crunkor
Нет,  клиент отправляет информацию о действии серверу, а сервер производит вычисления и отправляет результат всем, включая себя
CrunkorПользовательwww23 апр. 201718:40#4
Примерно посчитав, выявил, что у меня будет примерно 20 запросов в секунду, т.е. 20 json файлов будут отправлены на сервер. PHP справится с такой нагрузкой? Играть-то будет не одна группа а множество.
Плюс еще вопрос по организации своего рода лобби. Я вижу это так:
1. Все игроки отправляют на сервер запрос о том что хотят найти игру.
2. Сервер выбирает из них группу из 5 человек.
3. Назначает им какую-то сессию
4. Все игроки с общей сессией объединяются в лобби и играют.

Скажите, пожалуйста, это правильный вариант? Или уже где-то есть примеры этого, что бы не придумывать велосипед?

ZabПостоялецwww24 апр. 20178:05#5
20 запросов в секунду - это многовато. Можно сделать и такой сервер, вопрос в стоимости его эксплуатации и требованию качества связи игроков. Трафик считать пробовал? Через gprs уже не проиграешь. Можно сильно сэкономить, отказавшись от json, создав свой специальный формат сообщений, оптимизированных побитно. В стрелялках так и делают.

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

Чаще всего клиенты могут посылать сообщения друг другу напрямую, через UDP. Серверу можно поручить только начальное установление связи, а вся сессия может идти без его участия. Такой вариант возможен и с php хостингом, наверное даже на бесплатном можно. Почитай где-нибудь про "пробивание NAT'а".

Учитывать надо еще и лаги. Задержки в доставке сообщений бывают до одной секунды, причем, у разных игроков они разные. 0.15 секунды - задержка обычная. UDP сообщения имеют еще и свойство пропадать по дороге. Могут поменяться местами в пути или размножиться.

Правка: 24 апр. 2017 8:08

gambit_ozПостоялецwww24 апр. 20178:58#6
Crunkor
Можно и так - использовать хостинг как промежуточный контейнер для json файлов. Тогда при создании сети клиенты должны конектиться к сайту, там должен создаваться файлик сессии в который записываются данные игроков. Далее клиенты мониторят этот файлик на наличие других игроков. Выбирают нужных - создается сессия (примитивно - папка в которую будут скидываться json файлы). Далее снова - клиенты мониторят файлик на наличие обновлений и если файлик изменился меняем состояние на игровом поле.
CrunkorПользовательwww24 апр. 20179:12#7
Zab
> Трафик считать пробовал?
Один json запрос весит 41 байт. Если убрать все лишние символы, то весит всего 14 байт.

gambit_oz
> Выбирают нужных - создается сессия (примитивно - папка в которую будут
> скидываться json файлы)
Для этой цели я хотел использовать базу данных

Пойду изучать php потоки и сокеты.

ZabПостоялецwww24 апр. 201710:27#8
Crunkor
> Пойду изучать php потоки и сокеты.
А толку, если тебе хостинг не даст ими воспользоваться? А там где даст, там вообще все позволит запускать, можно и на С++ написать.
Это только иллюзия, что на php можно все, что это универсальный язык программирования. Он действительно универсальный, действительно можно все, но не на хостинге. Хостингу надо чтобы исполнение одного запроса не сильно помешало исполнять остальные. Скрипты могут быть самыми кривыми, у них физически не должно быть возможности просадить сервер. Экспертизу скриптов то не проводят, позволяют запускать все что угодно...
CrunkorПользовательwww24 апр. 201710:42#9
Zab
> А толку, если тебе хостинг не даст ими воспользоваться?
Тогда, может, будет лучше найти хостинг, где возможно развернуть какой-нибудь TomCat ? Думаете с Java получится лучше это реализовать?
ZabПостоялецwww24 апр. 201710:58#10
Crunkor
> Тогда, может, будет лучше найти хостинг, где возможно развернуть какой-нибудь TomCat ? Думаете с Java получится лучше это реализовать?
Чем плохо на Си написать все что нужно? Не знаете Си? Можно без плюсов, простой Си. А можно и с плюсами, как пожелаете.
Работа с потоками и сокетами в любой среде будет примерно одинакова, но для Си препятствий меньше.
Не нужно же никуда встраиваться, просто открыть порт на прием, ждать, отвечать. Не нужен никакой веб-интерфейс. И с двоичным форматом сообщений проблем не будет, если таковыми захотите воспользоваться. При высокой нагрузке - захотите.

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

Правка: 24 апр. 2017 11:20

ChupakaberПостоялецwww24 апр. 201712:17#11
Crunkor
> Есть идея написать игру на Android.
вот исходя из этого второй вариант заведомо провальный
интернет на мобилке может быть не очень подходящим для организации сервера. и если будет скажем два игрока с хреновым интернетом, и один из них сервер, то второй будет вдвойне в невыгодном положении. если это конечно не пошаговая игра
а если игра пошаговая то вариант 1 мне кажется в любом случае предпочтительнее, проще в реализации и не так чудовищна нагрузка на серверное железо в сравнении с так или иначе применяемым сервером матчмейкинга с пробиванием nat-а и прочими прелестями.

Crunkor
> Допустим один игрок начал действовать , все его действия записаны в json, он отправляет этот файл на сервер, сервер записывает эти данные в бд и другие игроки берут данные из этой бд?
в бд стоит писать только существенные изменения в продвижении игрока, например результаты его состязаний с другими игроками, а промежуточные данные игровой сессии хранить в оперативной памяти до окончания игровой сессии
впрочем если в случае с php взять тот же redis. то это будет вобщем-то и запись-чтение в бд, но в то же время самый быстрый вариант хранения промежуточных данных. ну а для значительных данных использовать тот же mysql или postgresql, чтобы надежно сберечь и удобно использовать

Crunkor
> Примерно посчитав, выявил, что у меня будет примерно 20 запросов в секунду,
> т.е. 20 json файлов будут отправлены на сервер. PHP справится с такой
> нагрузкой?
это один игрок 20 запросов в секунду на php будет делать? это думаю очень много, посчитай размер заголовка http, и это самое меньшее что тебя должно беспокоить
я бы рекомендовал использовать постоянное подключение. хотя, php тоже умеет сокеты (8 , если хочешь так - пробуй, всё может быть, но http протокол это не для тебя

Crunkor
> Плюс еще вопрос по организации своего рода лобби. Я вижу это так:
> ...
> Скажите, пожалуйста, это правильный вариант? Или уже где-то есть примеры этого,
> что бы не придумывать велосипед?
лучше придумывай велосипед, если не уверен в том как всё должно быть реализовано - не бери сразу готовое решение. чаще всего это приводит к мучениям. попробуй своё, разберись как должно быть организовано и почему. а потом ты либо оставишь свой велосипед, т.к. он тебя удовлетворит. либо выберешь по настоящему подходящее для себя решение
мы же вряд ли тебе тут посоветуем прям то что тебе нужно, т.к. никто не знает что за игру ты задумал

Zab
> UDP сообщения имеют еще и свойство пропадать по дороге. Могут поменяться
> местами в пути или размножиться.
ещё часто встречался с тем, что udp менее приоритетно каким-то образом на маршрутизаторах, и скажем если канал забит tcp пакетами, то upd может не проходить наглухо. когда tcp пакеты будут доходить
тут вопрос отдельный и отдельная тема для холивара udp vs tcp. но в целом я бы предостерег от udp по началу. нюансов куда больше чем на первый взгляд

Zab
> Сейчас многие хостинги - не совсем хостинги, они дают в распоряжение клиента
> виртуальную машину с юниксом. Твори там все что хочешь, никому не помешаешь.
vps ? да vps нынче не дорогой
и можно все что нужно свое подтянуть, и redis поставить и postgresql и всё всё всё

ZabПостоялецwww24 апр. 201713:06#12
Chupakaber
> ещё часто встречался с тем, что udp менее приоритетно каким-то образом на
> маршрутизаторах, и скажем если канал забит tcp пакетами, то upd может не
> проходить наглухо. когда tcp пакеты будут доходить
Я тоже с таким встречался, но только в локальной сети под управлением виндового доменного сервера. Народ кругом бьет себя пяткой в грудь и утверждает что в большой сети все наоборот, udp имеет приоритет. Могу только верить или не верить, не проверял.

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

CrunkorПользовательwww24 апр. 201722:09#13
Chupakaber
> vps ? да vps нынче не дорогой
Обдумав всё, решил приобрести vps. Подниму там java сервер и буду обрабатывать сокеты.
Полазив в этом направлении наткнулся на такой проект как Netty. Может кто-нибудь сказать, кто имеет с ним опыт работы, стоит ли его использовать или лучше поставить какой-нибудь tomcat/spring ? Хотя, возможно, они все в принципе одинаковые, тогда встает вопрос о легкости в эксплуатации.
typhoondevПостоялецwww25 апр. 20175:46#14
Crunkor
> Netty. Может кто-нибудь сказать, кто имеет с ним опыт работы, стоит ли его
> использовать или лучше поставить какой-нибудь tomcat/spring ?
не надо тебе спрингов. Pure Java + Netty Всё это решает. Повозишься в любом случае, это целое море задач. И советую взять protobuf для игрового протокола, он легко интегрируется в разные языки (Java, C# и др). JSON слишком избыточен для такого объема трафика как у тебя.

Страницы: 1 2 Следующая

/ Форум / Программирование игр / Сеть

2001—2017 © GameDev.ru — Разработка игр