Очень интересная система. Вы, таким образом, облегчаете нагрузку на клиента, а это, в свою очередь, облегчает мультиплеер между игроками со слабой конфигурацией железа. Ещё в далёком 2014 мы с друзьями испытывали проблемы с игрой в Майнкрафт по сети, так как, почему-то, у обладателей пк со слабым железом, мультиплеер работал гораздо хуже, чем одиночная игра. В подобных компаниях почти всегда есть человек, у которого компьютер много мощнее, чем у остальных. И если он будет держать сервер, то именно он будет просчитывать перемещение клиентов, облегчая работу клиентским пк. Это очень здорово. Но есть и обратная сторона медали. Общественные сервера. Представьте сервер на 100 человек и серверу приходится думать за каждого. К тому же, подобная система ( с просчетом только на сервере) будет всё менее и менее играбельная с ростом ping клиента. Даже с ping в 100 мс уже будет ощутимая задержка в отклике, так как что бы даже сдвинуться с места, клиент должен получить следующую свою позицию с сервера. Это может вызвать неприятный инпут лаг. Мне кажется, всё таки нужно, что бы и клиент и сервер делали расчеты, а затем синхронизировали значения, если они не совпали. Путь при плохом соединении человек будет лагать, но не будет инпут лага и сам для себя человек лагать не будет и управление останется отзывчивым. Лагать он будет только для наблюдателя. И если Вы уже отдали все расчеты серверу, то почему бы не дать пользователю самостоятельно выбирать способ расчетов? При запуске сервера (из клиента игры в будущем или из исполняемого файла сервера) выбрать расчет только на сервере или асинхронный расчет и на сервере и на клиенте. И в текстовом файле написать пояснение, что это за способы и когда какой нужно использовать.
Обработка физики на сервере обязательно нужна, это защита от читеров. Физика для клиента нужна только при плохой связи с сервером, чтоб сделать картинку мягче. Мы уже по тестировали через интернет, единственное я не сделал пинг сигнал, не могу сказать какой был пинг. Фризы были когда загружались чанки, в одном чанке перемещения отрабатывали на крепкую 4. Покуда игру делаю приоритет на локальную сеть. Тут ставлю паузу. Но для интернета, я ещё вернусь и изменю, для комфортной игры.
Изначально я так же рассуждал, но после ряд тестов, оказывается не обязательно, как минимум для локальной игры. И это ускорит реализацию игры, не надо отвлекаться на синхронизацию.
Без предсказания на клиенте при пинге даже 50-100 (туда-обратно - около 200мс, что очень заметно) уже будет абсолютно неиграбельное управление. Нельзя просто слать на сервер что игрок нажал кнопку, двигать его там и возвращать ему новую координату. Для локальной сети - ок, для интернета - не подойдет.
Я сразу тоже думал туда- обратно *2. Хотя пинг считается как раз туда и обратно. По этому тут вопрос реализации, сразу же идёт отправление серверу инпут, сервер фиксирует, и в своём же TPS отправляет уже позицию и прочее. Итого пинг + 0-50 мс время тпс сервера. Если пинг до 50 мс, выше 100 мс не будет. Сейчас в любом случае мне это очень удобно, не надо терять время на синхронизацию, а срази реализовывать сингл и многопользовательскую для локальной сети, для интернета надо будут доработки.
Стиль естественно будет схож с minecraft. Но ветка квестов, разновидность мобов, инструмент, будут отличаться сильно. Крафт будет другой. Пока имеются наброски эскизы. Сейчас упор сделать более качественный движок для игры.
:) Арочную не приходилось считать, а вот стропильную систему рассчитывал. Когда играл первый раз в майнкрафт, я боялся крышу делать, боялся свалиться на меня, и не мог понять сразу как крепить, чтоб не упала. И меня иногда приходит мысль, а если что-то подобное реализовать. Сложно конечно, но зато как интересно.
Очень интересная система. Вы, таким образом, облегчаете нагрузку на клиента, а это, в свою очередь, облегчает мультиплеер между игроками со слабой конфигурацией железа. Ещё в далёком 2014 мы с друзьями испытывали проблемы с игрой в Майнкрафт по сети, так как, почему-то, у обладателей пк со слабым железом, мультиплеер работал гораздо хуже, чем одиночная игра. В подобных компаниях почти всегда есть человек, у которого компьютер много мощнее, чем у остальных. И если он будет держать сервер, то именно он будет просчитывать перемещение клиентов, облегчая работу клиентским пк. Это очень здорово.
Но есть и обратная сторона медали. Общественные сервера. Представьте сервер на 100 человек и серверу приходится думать за каждого. К тому же, подобная система ( с просчетом только на сервере) будет всё менее и менее играбельная с ростом ping клиента. Даже с ping в 100 мс уже будет ощутимая задержка в отклике, так как что бы даже сдвинуться с места, клиент должен получить следующую свою позицию с сервера. Это может вызвать неприятный инпут лаг.
Мне кажется, всё таки нужно, что бы и клиент и сервер делали расчеты, а затем синхронизировали значения, если они не совпали. Путь при плохом соединении человек будет лагать, но не будет инпут лага и сам для себя человек лагать не будет и управление останется отзывчивым. Лагать он будет только для наблюдателя.
И если Вы уже отдали все расчеты серверу, то почему бы не дать пользователю самостоятельно выбирать способ расчетов? При запуске сервера (из клиента игры в будущем или из исполняемого файла сервера) выбрать расчет только на сервере или асинхронный расчет и на сервере и на клиенте. И в текстовом файле написать пояснение, что это за способы и когда какой нужно использовать.
Обработка физики на сервере обязательно нужна, это защита от читеров.
Физика для клиента нужна только при плохой связи с сервером, чтоб сделать картинку мягче. Мы уже по тестировали через интернет, единственное я не сделал пинг сигнал, не могу сказать какой был пинг. Фризы были когда загружались чанки, в одном чанке перемещения отрабатывали на крепкую 4.
Покуда игру делаю приоритет на локальную сеть. Тут ставлю паузу. Но для интернета, я ещё вернусь и изменю, для комфортной игры.
Было бы прекрасно, если бы подробнее рассказали о нюансах написания кода для создания физических механик.
Очень круто! Но как по мне, всегда лучший вариант это держать асинхронный просчет физики, на клиентской и серверной стороне, чтобы смягчить задержку.
Изначально я так же рассуждал, но после ряд тестов, оказывается не обязательно, как минимум для локальной игры. И это ускорит реализацию игры, не надо отвлекаться на синхронизацию.
Подробные видосы о физике нужны:)
Интересно было бы увидеть туториал по обработке коллизий(не по нахождению пересечений хитбоксов, это в любой статье есть)
Сделаю.
Без предсказания на клиенте при пинге даже 50-100 (туда-обратно - около 200мс, что очень заметно) уже будет абсолютно неиграбельное управление. Нельзя просто слать на сервер что игрок нажал кнопку, двигать его там и возвращать ему новую координату. Для локальной сети - ок, для интернета - не подойдет.
Я сразу тоже думал туда- обратно *2. Хотя пинг считается как раз туда и обратно. По этому тут вопрос реализации, сразу же идёт отправление серверу инпут, сервер фиксирует, и в своём же TPS отправляет уже позицию и прочее. Итого пинг + 0-50 мс время тпс сервера. Если пинг до 50 мс, выше 100 мс не будет.
Сейчас в любом случае мне это очень удобно, не надо терять время на синхронизацию, а срази реализовывать сингл и многопользовательскую для локальной сети, для интернета надо будут доработки.
@@SuperAnt2012 сервер-то меняет позицию, но игрок увидит изменения у себя на экране только когда ему придёт пакет обратно)
Уже определились с жанрами игры?
Стиль естественно будет схож с minecraft. Но ветка квестов, разновидность мобов, инструмент, будут отличаться сильно. Крафт будет другой. Пока имеются наброски эскизы. Сейчас упор сделать более качественный движок для игры.
Здравствуйте, можете помочь с созданием арочной фермы пж?
:) Арочную не приходилось считать, а вот стропильную систему рассчитывал.
Когда играл первый раз в майнкрафт, я боялся крышу делать, боялся свалиться на меня, и не мог понять сразу как крепить, чтоб не упала. И меня иногда приходит мысль, а если что-то подобное реализовать. Сложно конечно, но зато как интересно.