Войти
ПроектыФорумСобираю команду

The Inmost Trail: MMORPG убийца Diablo 1, нужен геймдизайнер (30 стр)

Страницы: 129 30 31 32126 Следующая »
#435
16:03, 18 июня 2022

Вий
>Я по прежнему не понимаю
Так если почитать, что я пишу, то придет понимание.

Я пишу:
1. У клиента нельзя отнимать управление регистрируя не все события.
2. Плохо делать управление ватным
3. Нужно делить данные на те что нужно гарантированно отправить и на те, что нужно отправлять потоком актуальные значения.

Где тут про то что нужно отправить все 15000 позиций на сервер?

А вот ты говоришь про *троттлинг управления на клиенте*, не про передачу данных, а именно про регистрацию ни всех событий на клиенте - зачем так делать? Зачем намеренно ухудшать игровой опыт?

#436
16:04, 18 июня 2022

Вий
Покажи уже что там получается.

#437
(Правка: 17:29) 16:42, 18 июня 2022

>GGMaster

как вы планируете отличать кадры когда нужно регистрировать ввод игрока от тех где можно забить на желания игрока

Я хоть что-то про регистрацию событий говорил?
Вы видете разницу между обработать событие и получить событие?

Вы же мне вещаете, что получив событие, что происходит каждый кадр, его надо обработать.
Так вот достаточно несколько раз в секунду проверить нужно ли обработать событие или нет.

Но вы можете проверять это конечно 250 раз в секунду вместо 4х - 10ти  или 25ти скажем.
Вдруг игрок со секунду совершил 250 действий которые нужно все обработать.
Когда камера на 1 пиксель сдвинулась и мышка стала указывать на 1 пиксель в другое место, вдург нужно пересчитать маршрут и персонаж уже дошел до точки, вдруг в него что-то сейчас врежется в 1000 пикселях от него.

Actions | The Inmost Trail: MMORPG убийца Diablo 1, нужен геймдизайнер

Вот зачем мне 1000 раз за секунду, перерасчитывать маршрут, если камера на 1 пиксель сдвинулась?
Путь построен, игрок идет к заданной точке (с обходом всех препятсвий) предварительно расчитано, что в игрока ничего не врежется. Дошел до точки, получил новые координаты куда мышь указывает перерасчитал маршрут и пошел дальше. Подвинулась мышь (а это отдельное событие, которое влияет на движение), перерасчитали маршрут и пошли уже туда. Но выполнять изменение (не значит что мышь двигаться не будет) положении мыши я буду 8 раз в секунду или 4 раза или 25. Если вы будуте махать мышкой по экрану, то в 99% точек он просто не пойдет, пока вы не остановите указатель где-то на заданную паузу обработки или будет крутиться в сторону точки с заданным периодом обработки.
* В некоторых случаях связанных с движением камеры, могут выполняться вообще все события, что бы было плавно. По разному может быть.

И не надо спрашивать, как выбирать что обрабатывать.
Клик левой клавишей мыши это одно
Удержание это другое
Клик левой клавишей мыши при зажатом RShif это третье
Каждое обрабатывается отдельно.
На каждое наложены свои ограничения
Что-то 25 раз в секунду
Что-то 1 раз в секунду
Ну и так далее.

Но вы можете обрабатывать все каждый кадр, я не против, так можно. Но я пытаюсь объяснить, что не нужно. Только потом появляются рассказы о тяжелых моделях, кривых спец эффектах и о том, что все тормозит потому, что виноваты моделлеры, аниматоры и худохники.

* Это для одного типа события нарисовано.
Исполнение этого события не блокирует исполнение других, если придут другие.
Тут вам будет и подъем предмета, и питье маны с клавиатуры с попутным кастом магии или еще чего.
Но пока конкретное событие не выполнено, повторно оно выполянться не будет.

#438
16:56, 18 июня 2022

GGMaster
> Где тут про то что нужно отправить все 15000 позиций на сервер?
А что, не все надо отправлять? Часть не надо отправлять? А это разве не называется троттлинг на клиенской стороне? Опиши поподробнее, в чем суть предложения, сколько сообщений от клиента надо отправлять в секунду когда игрок зажал кнопку мышки и бешено возит курсором по всему экрану?

#439
17:01, 18 июня 2022

Alex2233
> Покажи уже что там получается.
Пока вот так
A.png | The Inmost Trail: MMORPG убийца Diablo 1, нужен геймдизайнер

#440
17:07, 18 июня 2022

Вий
Записал бы хоть видос где медведь бегает. Посмотреть что происходит вообще.

#441
17:18, 18 июня 2022

Alex2233
Я скоро мультиплеер сделаю и выложу посмотреть

#442
(Правка: 17:39) 17:34, 18 июня 2022

>Вий

бешено возит курсором по всему экрану

Во во.

Более интересно, как выбирать эти события? (какие отправлять в смысле)

#443
17:51, 18 июня 2022

FourGen
В вашем сообщении все прекрасно от банального не понимания слова "обработать", до ввода таймера на Input.
Просто испанский стыд...

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

Вий
> А что, не все надо отправлять? Часть не надо отправлять? А это разве не
> называется троттлинг на клиенской стороне? Опиши поподробнее, в чем суть
> предложения, сколько сообщений от клиента надо отправлять в секунду когда игрок
> зажал кнопку мышки и бешено возит курсором по всему экрану?
О-хо-хох... Все время спотыкаюсь о то, что ты не понимаешь базовых подходов к созданию сетевых игр.
Нужно исполнять все, что делает игрок на клиенте, не дожидаясь подтверждения *можно ли ему это сделать* от сервера. т.к. если игрок честный, то на его действие не придет блока, а если нет, то не так важно *ломается* ли у него картинка из-за откатов позиции. По этому еще раз скажу троттлить управление не нужно вообще!
А вот сколько сообщений оптимально отправлять нужно будет тестировать, т.к. много зависимостей, от общей динамики игры, возможностей сервера, до того сколько мусора в виде двух уникальных идентификаторов ты еще планируешь засунуть.

#444
(Правка: 18:42) 18:09, 18 июня 2022

>GGMaster

что вы будете делать если игроку не будет везти с вашими таймерами или планируете вы создавать очереди событий которые будете разом обрабатывать по наступлении таймера

Везти с каким таймером? Какие события я надо обрабатывать по найступлению таймера? Вы говорите про очередь, которую можно сделать если в этом будет необходимость?

что городить такие костыли во первых глупо, а во вторых менее эффективно, чем обрабатывать входящие события сразу

По скольку у меня компетенция значительно ниже вашей оценки, мне было бы все же интересно услышать ответ на вопрос заданный выше:

Игрок, рендомно махал мышкой по экрану 1 секунду. За секунду произошло 250 событий, которые были обработаны и создано 250 маршрутов к точке, но сервер должен проверить, можно ли туда идти или нет или вернуть маршрут готовый или еще чего в зависиости от реализации.
Что из этого надо отправить на сервер, что бы он это обработал/проверил/подтвердил? (Как это выбрать?)
Все 250? Первый? Последний? Или еще какие вариации, скажем, 1, 17й , 126й, 243й и 250й?

Можно подойти с другой стороны:
Скажем у нас 360 FPS
Персонаж двигается ровно в 60 раз в секунду, что бы скорость его перемещения не зависела от FPS и была фиксированная.
На каждое перемещение персонажа приходит 6 событий о необходимости его перемещения.
Что делать с еще 5ю пришедшими событиями, которые необходимо обязательно обработать сразу, как они пришли?

(* Предположу, что надо пересчитать маршрут обязательно)

#445
18:59, 18 июня 2022

FourGen
> По скольку у меня компетенция значительно ниже вашей оценки, мне было бы все же
> интересно услышать ответ на вопрос заданный выше
Ох, ну вот не могу отказать человеку в получении знаний...


FourGen
> Игрок, рендомно махал мышкой по экрану 1 секунду. За секунду произошло 250
> событий, которые были обработаны и создано 250 маршрутов к точке, но сервер
> должен проверить, можно ли туда идти или нет или вернуть маршрут готовый или
> еще чего в зависиости от реализации.
Не так. Было последовательно определено 250 позиций для конечной точки.
Определение пути *как я уже писал* - это отдельная задача и она запустится не раньше завершения текущего расчета пути если он есть. Запустится он для актуальной позиции конечной точки на момент старта расчета. Я даже больше скажу, нужно будет пересчитывать уже рассчитанный путь, т.к. он может перестать быть актуальным (закрылась дверь, разлили лужу яда и т.д...)
На клиенте должно быть достаточна данных, что бы он мог самостоятельно определить можно ли куда-то идти. Потому движение игрока выполняется клиентом сразу, что бы избежать ощущения ватного управления. Серверу отправляются актуальные данные о позиции игрока, который верифицирует, что они валидные (доступность позиции, скорость изменения позиций и т.д...).
Если игрок играет по правилам, то дожидаться разрешения на действие от сервера нет смысла, а если в действиях игрока замечены отклонения от нормы, то применяются меры пресечения - от отката позиции, до полного отключения игрока.

И да - это в общий чертах, и да - это не единственный вариант, но это точно лучше чем сразу закладывать в реализацию: игнорирование ввода игрока, ватное управление и т.д...

FourGen
> Можно подойти с другой стороны:
> Скажем у нас 360 FPS
> Персонаж двигается ровно в 60 раз в секунду, что бы скорость его перемещения не
> зависела от FPS и была фиксированная.
> На каждое перемещение персонажа приходит 6 событий о необходимости его
> перемещения.
> Что делать с еще 5ю пришедшими событиями, которые необходимо обязательно
> обработать сразу, как они пришли?
1. Сомнительный подход отвязывания скорости от FPS.
2. Мы не знаем придет 1,2... или 6 событий, потому обработаем каждое, это все равно будет дешевле, чем где-то копить/перезаписывать эти события.

#446
(Правка: 19:10) 19:07, 18 июня 2022

>GGMaster

Запустится он для актуальной позиции конечной точки на момент старта расчета.

она запустится не раньше завершения текущего расчета пути если он есть

События приходят 360 раз в секунду, то есть расчет пути надо выполнять 360 раз в секунду? (так его расчет завершится в тот же кадр)

А один тик перемещения персонажа 6 кадров в течение которых он не принимает изменений, так как не закончил выполнение прошлого действия.

Мы еще не пришли в первую точку, а у нас пришло еще 5 событий о необходимости перемещения персонажа и мы еще 5 раз перерасчитали маршрут. Что с этими данными делать?

где-то копить/перезаписывать эти события

Их копить не нужно. их просто нужно игнорировать, а не выполнять.

итого мы имеем:
360 раз посчитанный за секунду маршрут, а применить его можно всего 60 раз.

#447
(Правка: 19:13) 19:11, 18 июня 2022

GGMaster
А я все ещё не понял, давай я задам несколько пронумерованных вопросов, ответь пожалуйста на них.

1. Игрок зажал левую кнопку и шевелит мышкой. В программу приходит событие «нажата левая кнопка мышки» с координатами. Что с этими данными делает программа?
2. Игрок не успокаивается и шерудит мышкой как больной, приходит второе событие с новыми координатами мышки. Что с этими новыми координатами делает программа?
3. Видеокарта закончила отображать кадр и начинается рисование нового. Что в это время делает программа?
4. Поиск пути происходит безумно быстро, примерно за 1 микросекунду, то есть за секунду можно найти 1 миллион путей. Клиент должен отправлять сообщение о новом пункте назначения на сервер каждый раз когда он начинает искать путь или только когда он заканчивает искать путь?

#448
19:58, 18 июня 2022

FourGen
Что ж, я пытался. Вся информация есть, тренируйтесь в восприятии текста.

Вий
> 1. Игрок зажал левую кнопку и шевелит мышкой. В программу приходит событие
> «нажата левая кнопка мышки» с координатами. Что с этими данными делает
> программа?
Применяет пришедшие координаты как конечная точка пути.

Вий
> 2. Игрок не успокаивается и шерудит мышкой как больной, приходит второе событие
> с новыми координатами мышки. Что с этими новыми координатами делает программа?
Применяет пришедшие координаты как конечная точка пути.

Вий
> 3. Видеокарта закончила отображать кадр и начинается рисование нового. Что в
> это время делает программа?
Вот прям все-все описать? Производит расчеты для нового кадра  ;-)
> 4. Поиск пути происходит безумно быстро, примерно за 1 микросекунду, то есть за секунду можно найти 1 миллион путей.
Мы выше говорили про 250 кадров, т.е. про 4мс на кадр. т.е. ты готов потратить 25% от общего времени? не так уж это и безумно быстро.
> Клиент должен отправлять сообщение о новом пункте назначения на сервер каждый раз когда он начинает искать путь или только когда он заканчивает искать путь?
А я бы скорее всего так вообще не делал т.к. отправляя только начальную и конечную точку:
1. можешь ли ты гарантировать, что поиск пути у всех клиентов для одного персонажа отработает корректно?
2. сколько займет безумно быстрого времени у клиентов, что бы рассчитать путь для всех персонажей при наличии только начальной и конечной точки (+расчет подавления временного лага)?

#449
20:08, 18 июня 2022

Вий
> если она отличается от предыдущей отправленной
Вот с этим проблемы. Я такое делал. Эвристика "отличается - не отличается" может стать очень сложной как только ты реализуешь более или менее сложные команды. В конечном итоге у меня пришло к тому, что "не отличается" стало редким исключением. Может, конечно, у тебя там поменьше возможностей в управлении и реально можно будет много нафильтровать, но слабо верится.

FourGen
> то в 99% точек он просто не пойдет, пока вы не остановите указатель где-то на
> заданную паузу обработки или будет крутиться в сторону точки с заданным
> периодом обработки
Так это из-за таких как ты в некоторых играх мышь нормально не нажимается?
Несколько лет назад играл в доту. В одном из патчей завезли такую "оптимизацию". Я сначала не понял, а потом обплевался. Не представляю, как киберкотлеты с этим играют. Через шифт, наверно... Если АПМ высокий, то через шифт, наверно, можно.
В WC3R тоже это сломали. Благо, киберкотлеты ещё на бете максимально громко наныли, так что теперь можно указать при запуске флаг, который это говно отключает.
Чел, вот честно скажи, ты шутан делаешь же? А aRPG и RTS терпеть не можешь?

Страницы: 129 30 31 32126 Следующая »
ПроектыФорумСобираю команду