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 = сколько осталось до повышения, отформатировали в дни/часы, как вам удобно и все.
Можно и за полгода, можно и за год с "продвинутого юзера". Конечно наличие опыта помогает ибо есть базовые понятия что такое программирование вообще, а это важнее чем синтаксис.
Вы можете сделать каждые три дня через крон сброс таймера.
Вешаете на крон скрипт, который берет каждые три дня в нужное вам время таймстамп и запоминает его. Потом отсчитываете от него три дня (3 дня * 24 часа * 60 минут * 60 секунд)
и считайте
Артем: На хабре поищите статьи типа "как мы писали xx"
Книжек такого рода будет мало, в основном заметки про какие-то проекты. А комментарии разработчиков в основном в коде...
Все действия просчитываются сервером.
Действия просчитываются не в порядке получения пакетов от клиента, а согласно внутренннему таймингу сервера - у каждого действия игрока есть продолжительность. На сервере в цикле идут "тики", каждый тик - что-то в мире происходит (кто-то колданул, где-то заспавнился моб, что-то передвинулось, что-то скрафтилось, какое-то кол-во здоровья восстановилось). Все крутится вокруг тиков.
Сервер принимает от игроков команды, которые скапливаются в очереди каждого игрока. Но сервер знает (рассчитывает) что будет выполняться каждый тик. Следовательно, он может эти очереди проанализировать и отправлять каждому игроку очередь на ближайшие несколько тиков про всех игроков, которые находятся достаточно близко от него.
Если какой-то игрокA решил выполнить команду, которая выполняет противоположное действие - значит со следующим пакетом игрокБ об этом узнает и его клиент начнет отрисовывать другое действие.
В зависимости от количества народу, пропускной способности, и насколько у вас оптимизирован и продуман трафик, это будет практически мгновенно.