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

Игра с дополненной реальностью (2 стр)

Страницы: 1 2 3 Следующая »
#15
18:43, 18 окт. 2016

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


#16
20:46, 18 окт. 2016

Zab
Я немного не понимаю, что именно значит в "лоб"?

#17
21:22, 18 окт. 2016

"В лоб" это значит запустить всех на одну арену. Загибаться сервер начнет уже на нескольких десятках игроков, если не предпринять никаких мер против квадратичного нарастания трафика на сервере.

#18
22:46, 18 окт. 2016

Zab
Если смотреть на механику покемонов, то квадратичной роста трафика там нету, т.к. нету практически никакого взаимодействия игроков. Даже если инициаторы захотят пвп запилить, то все равно на одной "арене" будет два игрока, а не все. Так что преждевременная оптимизация)

#19
22:54, 18 окт. 2016

Zab
> "В лоб" это значит запустить всех на одну арену. Загибаться сервер начнет уже
> на нескольких десятках игроков, если не предпринять никаких мер против
> квадратичного нарастания трафика на сервере.
Какое нарастание, ты о чем вообще? В любой базе данных есть spatial запросы, раз в N секунд приложение отправляет апдейт координат и делает sql запрос в базу чтобы получить есть ли рядом точки интереса. Там тупой CRUD, само приложение не сильно сложнее какой-нибудь таблицы рекордов.

update coordinates set location = GeomFromText('POINT(50.9874  -0.12345)') -- сохранить координаты

-- получить ближайшие 3 точки в радиусе 50 метров
SELECT * 
FROM coordinates AS c
WHERE ST_DWithin (:mylocation, с.location, 50) -- 50 метров
ORDER BY ST_Distance (:mylocation, с.location)
LIMIT 3

Если игроки не взаимодействуют друг с другом и не планируется искать игрока по последним координатам то первый запрос не нужен.

#20
22:55, 18 окт. 2016

rtishman
Насчёт сервера. Вам не нужны ни смартфокс, ни фотон, т.к. они работают по принципу комнат - n игроков (где n условно небольшое, до 32 скажем) взаимодействуют друг с другом. Это хорошо для экшн игр. У тебя же не совсем реалтайм, если ты смотришь на покемонов, да и взаимодействия игроков почти нету. Так что пиши свой сервер. Бери какую-нибудь библиотеку с реализацией хоть tcp, хоть udp, соединений, реализовывай протокол общения и всю соответствующую логику. Игровой движок не обязательно брать unity3d, бери что знаешь. Если ничего не знаешь тогда unity3d наверное лучший вариант для быстрой реализации и освоения. Соответственно и язык программирования тот, который используется в движке, чтобы сразу два не учить

#21
23:05, 18 окт. 2016

MANAB
> Так что пиши свой сервер. Бери какую-нибудь библиотеку с реализацией хоть tcp,
> хоть udp, соединений, реализовывай протокол общения и всю соответствующую
> логику. Игровой движок не обязательно брать unity3d, бери что знаешь. Если
> ничего не знаешь тогда unity3d наверное лучший вариант для быстрой реализации и
> освоения. Соответственно и язык программирования тот, который используется в
> движке, чтобы сразу два не учить
Охренеть. Ты серьезно? TCP и UDP? Свой протокол?

На каком-нибудь php этот сервер займет строчек 30 не считая авторизации. SQL запросы выше я уже написал.

#22
23:16, 18 окт. 2016

Стоит еще добавить, что на php написанный сервер можно развернуть на бесплатном хостинге.
Само собой, не любые возможности php можно использовать в этом случае, чтобы не сняли с выполнения по таймауту. Работа ограничена схемой запрос-ответ, без возможности инициации связи со стороны сервера. Очень может быть что вам этого хватит.

#23
23:21, 18 окт. 2016

Zab
> Работа ограничена схемой запрос-ответ,
Нет конечно. Сервер-сайд эвенты придумали лет 20 уже как в вебе.

>без возможности инициации связи со
> стороны сервера
Ну строго говоря сервер от клиента именно этим и отличается, что соединение инициирует всегда клиент. И есть комет, раз уж так пошло.

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

#24
23:28, 18 окт. 2016

9К720
> Нет конечно. Сервер-сайд эвенты придумали лет 20 уже как в вебе.
Для этого на сервере должен постоянно крутиться твой код, не важно на чем написанный. Бесплатные хостинги это сделать не позволяют, снимают с выполнения по таймауту.

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

#25
23:30, 18 окт. 2016

9К720
Именно так. Хотя бы потому, что обращаться с каждым запросом к БД не хорошо, т.к. она одна, лучше создать сервак, который для каждого клиента создаёт сессию, подгружает данные клиента из бд в память и рабатает с памятью - и быстрее, и масштабируемо, т.к. запусть можно много инстансов таких серверов. К тому же человеку еще и учить php в дополнение к языку движка

#26
23:42, 18 окт. 2016

MANAB
> лучше создать сервак, который для каждого клиента создаёт сессию, подгружает
Чем лучше?

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

Ты ведь никогда не писал таких систем, правда? Иначе бы не говорил об этом как об альтернативе человеку который не знает с чего начать. Для работы с каким-нибудь зукипером или игнайтом или с прочими решениями для распределенных вычислений требуются нехилые скиллы, чтобы писать корректный код и уметь доказывать его корректность. Очевидно, что автору до такого уровня лет 10 расти как минимум. У местных говнокодеров тут даже многопоточный код проблемы вызывает, обсуждают критические секции и атомики вон в тредах.
Особенно про масштабирование порадовало. Нельзя запустить много инстансов, у тебя расхождения по данным начнутся если ты будешь в базу писать.

> Хотя бы потому, что обращаться с каждым запросом к БД не хорошо, т.к. она одна,
С чего это она одна? Запусти много инстансов таких баз, лол.

>К тому же человеку еще и учить php в дополнение к языку движка
Это при нулевом знании пхп пишется за 2 дня.

#27
0:02, 19 окт. 2016

9К720
Плюсую по всем пунктам :) но в базу можно писать из разных инстансов, надо игрока в качестве ключа блокировки записей использовать, по сути набор комнатных серверов получается

#28
0:05, 19 окт. 2016

9К720
> Ты ведь никогда не писал таких систем, правда?
Я об этом пишу именно потому, что я именно такие системы и писал, поэтому пожалуйста спокойнее реагируй, сколько людей столько и мнений.
Все поднятые тобой вопросы довольно просто решаются, в т.ч. через пересылку сообщений между серверами, либо обновление сессий из бд раз в несколько минут, что имхо лучше, чем дергать каждый раз бд. А вот насчёт большого количества инстансов баз - тут мне кажется нужны нетривиальные навыки для организации того, чтобы все инсьансы баз синхронизировались между собой.

#29
1:30, 19 окт. 2016

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

MANAB
> А вот насчёт большого количества инстансов баз - тут мне кажется нужны
> нетривиальные навыки для организации того, чтобы все инсьансы баз
> синхронизировались между собой.
Как раз таки гораздо менее нетривиальные, чем написание своего распределенного кеша с устойчивостью к разделению, горизонтальной масштабируемостью и желатьтельно высокой доступностью. Впрочем, зарплаты разработчиков таких систем начинаются от 5к в России, так что автору это грозит не скоро.

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумСеть

Тема в архиве.