Фаербол тоже может быть объектом, который куда-то летит. Не нужно передавать, если известно в кого он летит. Но есть же вещи которые взаимодействуют с площадью.
Всегда вся карта делится по квадратикам. С радиусом взаимодействия объектов нужно работать.
Нужно же отправлять не только про игроков, но и про NPC/MOB/items - все объекты.
Создаете для каждого клиента список объектов и поддерживаете его актуальным. Когда доходит время до отправки информации клиенту, по этому списку и пробегаетесь, смотрите что критично отправлять, что можно в следующий раз.
Выбираете какие действия могут обновлять список (например передвижение должно проверять что можно добавить/выкинуть).
К сожалению, у меня реального опыта разработки такого уровня не было. Я в детстве MUD писал, и чуть позже участвовал в разработке одного из java-серверов линейки, но больше как админ а не дев.
Просто был немного в курсе основных проблем и нагрузки.
Padaboo: Какой-то игрок подключился с удаленного сервера, в некий момент или пакеты могли пойти по другому, более медленному маршруту, или просто пару пакетов потерялось, вот и мелкий лаг.
20 игроков в шутерах, при требовании апдейта по 10 раз в секунду - все же трафик.
"Все параметры тогда должны хранится на сервере а на клиенте только графика и отправка пакетов."
КОНЕЧНО,
иначе я влезу в пакет, подправлю параметры и поубиваю всех на сервере с одного удара.
На клиенте никакой деструктирующей логики быть не должно. Он может что-то предполагать для плавности отрисовки, но он не должен считать и отправлять результаты на сервер как истину, только команды игрока.
Вы еще не встречались с дупами (кучи багов в играх от самых крутых производителей), где из-за ошибок во время синхронизации можно сдублировать предметы, ресурсы, действия. Это тот еще океан для дебагов.
Но вы как-то еще пишете "игроки дерутся", хотя надо смотреть с другой стороны.
Игроки не дерутся, они отправляют команды на сервер.
Сервер вычисляет все взаимодействующие между собой объекты, и отправляет каждому игроку с каждым тиком результат.
Игроки могут и не драться, а например общаться.
Игрок может драться с мобом, а может покупать в магазине предмет - суть не меняется. Игрок отправляет команды, сервер отправляет результат ТИКА, а не именно этого действия игрока, поскольку действие должно быть просчитано с учетом всех остальных действий (например удар заблокирован, или игрок был уже заморожен).
Как-то так.
Padaboo:
Клавиша зажатая в квейк отправляется как команда "вперед". К ней можно добавлять синхронизаци в виде направления. Клик мышкой "бежать сюда" также команда, просто ее нужно дольше просчитать - зато гораздо меньше инфы передавать.
Но игры типа квейк, большой онлайн не поддерживают (20 игроков уже напряг), пинг свыше 30 - уже плохо, свыше 50 - играть уже невозможно.
Поэтому вам нужно определиться с типом игры, которую вы делаете.
Тики есть в любой игре. Не может же пулемет стрелять со скоростью клика мышки - он будет стрелять с установленной скоростью.
Клиент-серверу по TCP (каждое действие должно быть отправлено и отресолвлено)
Сервер-клиенту по UDP (не все пакеты должны дойти, но среди пакетов будут или каждый с синхронизаций действий, или например каждый 5-й или 10й или по времени с более детализированной информацией. Вы же видели, что в квейке бывают лаги, после которых вроде ты вроде как "телепортируешься" на пару шагов после лага - это показатель, что сервер команды просчитывает.
Волшебства в любом случае не будет, все упирается в онлайн, поэтому в квейке и подобных играх на карту стоит ограничение максимального онлайна, обычно до 20-30 игроков.
Написано только что
Вам нужно продумать пакет, который будет отправляться для игрока.
Например объект игрока будет содержать ссылки на объекты, связанные с этим игроком.
Подошел на расстояние - добавляем.
Игроки в группе - добавляем.
Сражение с врагом - добавляем.
Везде таймстампы от последнего действия и тип.
Некоторое время нет действия и тип позволяет - удаляем.
Подошло время отправить нужному игроку пакет - у нас уже есть готовый список объектов про которые нужно отправлять информацию.
Все состояния кодируются.
Все действия сглаживаются анимацией. Время сервера и клиента не обязательно должно совпадать, но вы можете сверять номер "тика" который сейчас резолвится на сервере и на клиенте, и отталкиваться от него.
"Нет, хочу сделать один раз что то серьезное - локации это не очень хорошо, единый мир лучше всего. "
Суть в том, что вы мыслите стереотипами.
Локация не обязательно смена места, это еще и location - местоположение.
Вычисляете РАССТОЯНИЕ между игроками, и конкретному клиенту высылать то, что касается его текущего местоположения и интерактивных объектов на определенном расстоянии X от него. Можно даже сделать так, чтобы это расстояние X было не статичным, а например уменьшалось автоматически, если рядом много объектов. То есть "в городе" например 20 метров, за городом 100 метров. Добавить исключения для тех объектов, которые контактируют непосредственно с ним или контактировали последние xx секунд
А вообще, IMHO вы беретесь за крупный проект вообще без опыта подобной работы.
В результате есть вероятность около 95%, что проект останется недоделанным, так как получить хотя бы первоначальную рабочую версию у вас получиться очень нескоро, а без заметных успехов, мотивация падает и все останется на бумажке.
Padaboo: неважно как выглядить сеть.
Все действия просчитываются сервером.
Действия просчитываются не в порядке получения пакетов от клиента, а согласно внутренннему таймингу сервера - у каждого действия игрока есть продолжительность. На сервере в цикле идут "тики", каждый тик - что-то в мире происходит (кто-то колданул, где-то заспавнился моб, что-то передвинулось, что-то скрафтилось, какое-то кол-во здоровья восстановилось). Все крутится вокруг тиков.
Сервер принимает от игроков команды, которые скапливаются в очереди каждого игрока. Но сервер знает (рассчитывает) что будет выполняться каждый тик. Следовательно, он может эти очереди проанализировать и отправлять каждому игроку очередь на ближайшие несколько тиков про всех игроков, которые находятся достаточно близко от него.
Если какой-то игрокA решил выполнить команду, которая выполняет противоположное действие - значит со следующим пакетом игрокБ об этом узнает и его клиент начнет отрисовывать другое действие.
В зависимости от количества народу, пропускной способности, и насколько у вас оптимизирован и продуман трафик, это будет практически мгновенно.
Мне кажется вы взялись за слишком сложную задачу в лоб.
Сервер в любом случае тут является главным оптимизатором.
Он должен решать какому игроку про что слать. Ограничивать запросы по расстоянию. Если игрок А ничего не может сделать игроку Б, то высылать им информацию друг про друга или не обязательно или можно в 10 раз реже. Подойдут поближе - будет больше деталей.
Периодически должны приходить синхронизирующие пакеты с более полной информацией, но в основном - дельта между прошлым и текущим.
Часто используется UDP
В общем нюансов много. Вы действительно сразу хотите делать именно такое решение?
100 игроков вполне можно и в синхронизации передавать, серьезные лаги начинаются в районе от 500 и выше в одной локации.
Если же что-то вроде квейка, где критичны миллисекунды, там пару десятков и КАК бы не оптимизировать критичен пинг от игрока к серверу, а со всеми <30ms не сделать.
Padaboo: координаты - сеточкой. Плавное передвижение - это просто анимация.
Даже если сетка мелкая, нужно передавать клик игрока на координаты x,y. Сервер просчитывает путь игрока и передает ключевые параметры - куда двигаться. Клиент отрисовывает это перемещение плавно, но переданы только
игрок на xy, двигается на x1y1, скорость z - грубо говоря 5 или 10 байт.
Padaboo: А так и бывает, когда подлагивает.
Но вы путаете количество сообщений, которые нужно отправлять.
Игрок отправляет на сервер свои действия.
Несколько действий могут быть отправлены за один пакет. Сервер отправляет игрокам сразу очередь действий, а не по каждому игроку отдельно.
Увеличиваем длительность минимального тика - сразу все становится проще.
В большинстве MUD-ов, тик идет пол-секунды. Это просто хватает.
HoHsi: артефакты, которые создает дженкинс, и которые доступны для скачивания через его веб UI, скачиваются через java-веб сервер, и могут создавать большую нагрузку. Я сталкивался, когда дженкинс тормозил именно из-за этого.
Решили вопрос тем, что во время билда артефакты просто выкладывались на отдельный фтп сервер, и пользователи качали билды уже с фтп. Нагрузки как не бывало.
Но 500 мбайт.. на таком дженкинс не запускал, тем не менее неужели он столько занимает?
unlik: "Если я сделаю сброс таймера через крон, то работать он будет не верно. Он не сможет мне на данный момент показать, что осталось менее 3 дней. "
Неправда.
Во-первых вы с каждым ответом добавляете новые условия. Вы можете нормально свой вопрос описать, чтобы в нем была поставлена задача, а не вам отвечают, а вы дописываете - именно таких техзаданий не любят.
Во-вторых, во время срабатывания скрипта вы можете просто сохранить в переменную или базу создать таймстамп от текущей даты плюс три дня
Затем в сайте его использовать для вывода типа
timestamp - currentdate = сколько осталось до повышения, отформатировали в дни/часы, как вам удобно и все.
"Жалоба со стороны майкрасофта?"
Ваш домашний комп лицензионный? Он жаловался в майкрософт?
Насчет риска решайте сами - насколько критично будет потом докупить лицензию и что за клиенты.
Конечно спокойнее с лицензией. Тем более что можно взять хостинг с уже лицензионной виндой.