Комментарии 36
Что такое ping я постарался простым и понятным языком описать в видео:
Вы опять наступаете на те же грабли. На овертехническом ресурсе рассказывать что такое ping и как он работает, да еще и в формате видео. В прошлый раз вы в картинках рассказывали, чем udp от tcp отличается.
В общем как вам еще в первой статье заметил MegaMANGO, это не статья, а реклама своего ютубканала. Тут такому как правило не рады.
ну при всем негативе с вашей стороны вы прочитали все мои статьи. Подписывайтесь что бы обругать не пропустить следующие :)
Сделайте хороший разбор, исправьте лексику/грамматику. Сложные вещи выносите в отдельные блоки/статьи (не видео). И будет счастье.
А блок подписки можно в конце добавить
Я желаю успехов в ваших начинаниях, да и в принципе всем кто хоть что-то желает, ибо не ошибается тот кто ничего не делает.
Но. Как и сказал 'iamkisly' в комментариях к 1 статье - у вас нет понимания как и что происходит в геймдеве. Складывается ощущение что вы наспех прочитали несколько статей и теперь пытаетесь пересказать нам то как вы их поняли.
Команды вида [8,117,17] труднее читаются чем move_right, но куда правильнее, имхо. Я бы вообще использовал бы пакеты вида '13FFAC0D'.
Дальше вы утверждаете 'но так же можно атаковать через всю карту' и тут вы правы только частично. Можно попробовать атаковать через всю карту, но задача сервера как раз проверить может ли игрок атаковать, хватает ли дальности, можно ли вообще атаковать данный объект и т.д. и желательно ещё вести статистику таких вот выкрутасов от игрока. Если их много то кик с сервера, если это повторяется регулярно там бан.
В вашем же апи используют команды 'иди влево', 'иди вправо', 'иди вверх', 'иди вниз'. Это конечно прекрасно (нет), но мы пишем не 'черепашку' а ММО (хотя на вашем бы месте прежде чем бросаться такими словами, я бы попробовал написать сервер хотя бы на пару десятков человек).
Тут я вижу 2 варианта на какие пакеты заменить: 1) это координаты и дальше сервер уже двигает персонажа постепенно туда (как в стратегиях например, или в МОБА), и вариант 2) это вектор куда и с какой скоростью движется персонаж.
Идём дальше, редис.. вот тут ничего не скажу, вещь полезная, и когда я занимался попытками создать сервер для игры, то я о подобных технологиях не знал. Но имхо вы используете редис не правильно. Незачем хранить там то, что и так может лежать в оперативной памяти.
Количество НПС влияет на пинг - а вот так быть не должно. Это говорит нам о том, что у вас неправильная архетиктура.
П.с. читаются ваши статьи достаточно трудно, ибо то что связано с сетью и разработкой сетевых игр вы пытаетесь объяснить словно маленьким детям (и делаете это на техническом ресурса, как сказали ранее), а то, что на мой взгляд не относится к разработке сервера напрямую, а скорее имеет отношение именно к PHP вы наоборот описываете наиболее подробно, только вот не понятно зачем. Мы и так поняли что PHP вы знаете. Но к разработке ММО это именно очень посредственное отношение.
Будь я на вашем месте, то писал бы статью которая не привязана к языку, и если были бы какие-то ключевые моменты в языке который использую я, то выносил бы это под спойлер отдельно.
Ну как то так. Жду вашу 5 статью.
Я занимаюсь этим уже 2 года и работаю в геймдеве.
И считаю что бы сделать сервер с поддержкой 100.000 онлайн не нужно "понимать" игроков - для создания интересных игр есть гейм дизайнеры и др люди
По поводу куда правильнее - правильнее для чего ? Для уменьшения размера пакета да. Но сейчас режим разработки и читать такое в Debug затруднительно...следовательно правильнее в этот момент времени строками
Про черепашку - можно ткнуть на карту (координаты) пойдет туда. Играя джойстиком - надо указывать направление (джойстик - ваша "черепашка"). Я не делал диагональное движение пока.
Вы пишите что не должны влиять NPC (которые пишут в базу данные и читают из нее) на PING - любая строчка кода, любая переменная все это влияет на скорость работы сервера. И следовательно вообще ВСЕ влияет на пинг (сколько у вас процессоров, какое железо, где находится). Вы рассуждаете поверхностно.
Когда у вас игра на 100-500 игроков и на экране 10 NPC - вы можете не замечать влияния на игру и не увидите отличие при Ping 50ms и 60ms а вот если сразу на карте будет 1000 NPC у вас как минимум на клиенте игра начнет медленнее отрабатывать (надо же больше данных отрисовывать) и ping увеличится (тк сервер с большими данными работает)
При грамотной архитектуре на клиенте не должно быть разницы 1 НПС или 1000, или вы на движение каждого НПС собираетесь слать отдельный пакет на клиент ?
Ладно бы вы сказали 1000 игроков, там то хоть понятно, что количество пакетов будет N*(N-1), из-за чего собственно и случаются лаги в людных местах в мморпг.
Зачем у вас НПС что-то читают и пишут в базу тоже не понятно.
В общем я начинаю сомневаться в вашей квалификации на счёт геймдева.
Если вы внимательно смотрели мои предыдущие статьи то могли заметить что NPC в онлайн игре - эти те же игроки, с искусственным интеллектом
Они ходят по карте, смотрят кто на карте есть и кто это (запрашивая данные) , атакуют и тп
Тем не менее вы так и не ответили причём тут база данных и зачем что-то читать из неё.
И что значит НПС это те же игроки ? Допустим у вас есть сущность character с набором действий от которой наследуются персонажи игрока и НПС, но это не делает НПС игроком и обращаться к базе или гонять пакеты по сети им тоже не нужно. (Есть конечно исключения, но не в данном случае).
Потому , что архитектура разделенная.
Сервер - один процесс, он не выполняет никакой логики и за это может 1млн соединения обрабатывать. И он знает только о websocket соединениях и если пришла команда - шлет ее в "сервисы"
Сервисы - ничего не знают от сервере , могут физически находится на разных серверах. Они работаю параллельно, запускаются по команде от игроков и уничтожаются по завершению. Сервисы читают из общего источника данных (база данных). Когда в них выполнится логика игровая, она выполняется например 3-10 мс - сервис вносить эти изменения в базу, шлет результат работы на Сервер (а он разошлет всем игрокам, тк результат должны все увидеть. например что игрок шагнул)
Процессы NPC - должны жить постоянно (тк игра не пошаговая и они должны работать не зависимо от того нажимает игрок сейчас кнопки или стоит). Эти процессы - некий один сервис который не завершает свою работу. Он обрабатывает все NPC и живые объекты , смотрит не пришла ли пора им двигаться или атаковать кого то а может быть самим нападать на друг друга и тп (те игровая логика) . И когда обработает - записать в бд (что бы и игроки новые запоганенные увидели новые что все npc уже на другой конец карты ушли или часть уже умерло) и отправить все изменения на Сервер (что бы игрокам разослать)
я считаю это грамотной архитектурой. А НЕ грамотной - когда один из игроков является сервером. и на клиенте рассчитывается все и шлется на сервер (то можно подделать) обновленное состояние мира. Dead By Daylight похожим образом работает (на демо серверах там игроки сами собой воскрешаются и летают по карте)
А еще НЕ грамотная архитектура это когда на Сервере выполняются сервисы (и он ждет эти 3-10 мс а не обрабатывает новые соединения) - это пример игры от workerman (в статье ссылка на нее).Ну и NPC там стоят пока их не дернуть
Хотя при малом количестве онлайна это работает на ура, а при большом...создается копия игры (те отдельный процесс выступавший вторым третьим и тп Сервером) и там свои игроки которые никогда не пересекаться
При этом, надо сказать, что лично у меня сложилось ощущение, что BrowserQuest сильно выигрывает у вашего Игоря по отзывчивости (и там и там было по одному игроку).
Вам нужно сделать что-то аналогичное, потому что техническая демка - это не то, чем нужно заманивать, а вот на BrowserQuest я залип надолго (и соответственно тыкался в ней минут 30, в отличие от вашей игры, где меня хватило на пару минут)
Так Игорь же не закончен. BrowserQuest закончен. и там стоит фикс 50 игроков. Плюс на фото виден рассинхрон
Игра мне тоже понравилось. Но я делаю сервер. Сами игры я делать не умею (а то что сделал для демонстрации)
Идея в том что можно любую игру потом сделать с грамотным сервером и API к нему
Я занимаюсь этим уже 2 года и работаю в геймдеве.
Сами игры я делать не умею
Ну вы уж определитесь пожалуйста
И может всё таки стоит сделать что-то более менее рабочее и похожее на BrowserQuest. А не то что есть сейчас, и потом уже писать статьи ?
2 года я занимаюсь СЕРВЕРНОЙ частью ДЛЯ игр :)
Сами игры (механики, балансы, графика , Unity, анимация) я могу делать просто что бы вывести демонстрацию работы сервера (те КЛИЕНТ игры я по сути сделать могу но это будет не игра а так....).
Те Сервер - это некий набор библиотек, фаилов - скриптов хранящихся на удаленном ресурсы
Есть хорошие игры. но нет публичной технологии на которую можно поставить игру и сделать в ней онлайн жанра ММО
Думал что https://www.photonengine.com/ единственная более менее, а там оказывается до 100 человек
Если сейчас в том состоянии что есть сервер убрать все что я там химичу, оставить Redis и не тратить время на изменение архитектуры - можно сделать любую игру жанра ММО с онлайном до 500 человек и +- столько же NPC (не которые стоят а живых именно. если стоячих то там "условно" бесконечно можно было бы)
Давайте определимся что мы имеем ввиду под онлайном. Ибо онлайн может быть общий (на условных 10 серверах).
Онлайн на 1 сервере (но при этом игроки распределены по серверу равномерно) (тут кстати сервер тоже может быть на нескольких физических машинах)
Онлайн а 1 локации.
Онлайн на 1 локации где все игроки видят друг друга.
Если вы думаете что у Фотона ограничение в 100 человек из-за того что сервер не тянет, то вы ошибаетесь.
100 человек это всего лишь бесплатная лицензия, ибо люди хотят денег за свой труд и я их понимаю.
Я даже готов поспорить что если вы сделаете своё популярное решение на уровне Фотона, то вы тоже рано или поздно захотите с этого иметь денег.
Кстати хочу заметить что Фотон делал явно не один человек. Думаете в одиночку сможете лучше ?
Да вот нет, там не бесплатно а в прицепе это максимум (я честно сказать не вникал , ссылку взял из кометов)
Разумеется, в задумке есть и коммерческая выгода. Онлайн имеется в виду 1 сервер, одно ядро 4 Гб оперативной памяти (на одной локации или разбросанных по миру 500 игроков по моим подсчётам сервер выдержит и в текущем состоянии, но я ориентируюсь на другие цифры)
Ну а почему бы не сделать. Время тут главный ресурс. Определюсь с архитектурой и технологиями - пойдет дело быстрее (сами игровые механики делаются за пару дней. с технологиями для хранения данных сижу неделю с тестами и исследованиями)
Да вот нет, там не бесплатно а в прицепе это максимум (я честно сказать не вникал , ссылку взял из кометов)
'Я не вникал, но буду спорить'.
Если вы всё же прочтёте то что вы скинули то заметите что речь во первых про Photon Cloud, во вторых там говорится что для одной игры бесплатный лимит это 100 человек, а следующий (уже платный) доступный пакет это 500 человек. А в третьих там же на примере комнат говорится что считать количество подключений несколько не правильно, и правильнее будет считать количество пакетов за единицу времени.
Ну и извиняюсь если где обидел или могу обидеть в спорах, просто очень люблю дискутировать на интересующие меня темы.
П.с. ваши статьи мотивируют, но скорее мотивируют сделать и показать 'как надо' 😊
у меня тоже будет Облачное решение. Как сервис. И мне кажется что фотон основан на том что сервером выступает экземпляр игры...что довольно требовательно по ресурсам
Плюс мне показалось достаточно сложно интегрировать в клиент...Те там библиотеки определенные
Я же смотрю в стороны REST API которая возвращает и получает только текстовые даныне. А тот кто делает игру сам решает что с ними делать и как там строить анимации и тп
То, что вы пишете - очень интересно, но вот пересылать текстовые данные между севером и клиентом в реалтайм играх слишком дорого. В целях отладки - да это удобно, но надо понимать, что, во первых, сеть не резиновая и отправить 1122 быстрее, чем {"command": "move_to_left", "count": 3 } (не забываем, что пробелы - это тоже символ), да и сериалищация/десериализация команд первого вида в разы быстрее, чем команд второго
в любом случае второй сервис , для простеньких 2Д игр сделать оказалось сложнее чем это кажется на первый взгляд
в споре раздается истина :)
Ну, кстати, из этого FAQ видно, что для вашей целевой аудитории не особо важно количество игроков онлайн
Most Photon multiplayer games have 2-16 players
There are Photon games live with 32 or even 64 players
Откуда желание повысить онлайн? Это какой-то запрос от реальных разработчиков игр? Или просто цель с потолка?
Я исследую технологии (типа Redis и фреймворки типа workerman), сравниваю что сколько может обработать в секунду. И если что то сильно отстаёт - смотрю чем заменить
Отсюда берутся цифры (например есть возможность второй сервер сделать где будут хранится данные и обращаться к нему по тому же websocket смогут Сервисы. но насколько это будет лучше redis - надо смотреть ) https://github.com/walkor/GlobalData
Мне кажется, вы отбрасываете саму игровую логику, которая и будет бутылочным горлышком. Я бы сначала сделал игру, со всеми фичами, которые хочу видеть. И уже на ней бы экспериментировал с технологиями
я не могу придумать такиех фичей и логик которые бы нельзя было реализовать если сервер быстрый...поэтому...делаю сервер )
плюс не только сервером будет хорош будущий сервис а админ панелью (не знаю есть ли в фотоне такое - скажите)
Админка позволяет редактировать контент игрового мира (новые карты добавлять . npc и тп). Притом игра может быть как браузерной так и устанавливаться на устройства
так что можно сказать...с потолка...пока потолок не достигнут
можете сомневаться, не верить, говорить что ничего не получится - это нормально (мне часто пишут в комментариях)
Главное - результат. Сейчас какой ни какой результат - есть.
Я рассказываю как построить архитектуру. Как писать код - человек уже должен иметь навыки. Кому моя манера кажется не правильной, но и я программист, не блогер (у меня нет советующих навыков)
Но даже того малого что успел написать мне бы в начале пути очень бы помогло (тк статей про архитектуру попросту нет, никто не делится)
Если кому-то поможет то что вы написали в текущих 4 статьях, то я ему сочувствую, ибо эта информация есть в открытом доступе в куда более понятном и более информативном виде.
А по именно архитектуре вы пока что ничего толкового не написали.
Так же вы говорите что вы программист а не блогер, но при этом ведёте себя полностью противоположно. Задумайтесь.
Ну вы сами пишите про Redis "вот тут ничего не скажу, вещь полезная" - получается информация была полезна
Я не навязываю своего мнения. Но аргументировано его отстаиваю.
Если считаете что есть решение лучше - скажите какое (какую базу для хранения использовать, как выстроить очередь отправки пакетов пользователям, покажите пример архитектуры ) или как минимум покажите статьи на эту же тему как с нуля писать сервера для игр и на каких технологиях
Если вы НЕ можете - значит ваше мнение субъективно и не обосновано
Я вижу много комментариев что так не надо и так не нужно.
Но за 9000 просмотров статей на 15.06.2022 я не увидел ни в одном комментарии как конкретно надо и почему именно (какие проблемы решатся и насколько станет лучше)
Следующая статья полагаю будет про ZeroMQ (очереди, что в замен REDIS Pub/Sub будут) и общую память Shared Memory - будем средствами PHP писать напрямую в блоки памяти оперативки
Создание сервера для онлайн ММО игр на PHP ч. 4 — Redis