Компьютерные ресурсы ценны. даже если они бесплатны, вы не должны тратить их впустую. рассмотрим случай, когда два или более сервера работают одновременно на одном компьютере. Если один экземпляр сервера потребляет все циклы ЦП, другие экземпляры просто не будут работать. Surly OS будет пытаться справиться с этим своего рода жадным поведением, но это будет стоить дорого. Вы не будете знать, где ОС остановит ваш процесс и передаст циклы ЦП другому. Также вы можете захотеть выпустить свой сервер вместе с самой игрой, чтобы игроки могли запускать свои собственные игры по локальной сети. Немного раздражает, если я выделил одно из своих процессорных ядер только для запуска игрового сервера!
В большинстве игр, особенно в синхронизированных сетевых играх, используется фиксированный временной шаг. просто потому, что они хотят быть в состоянии предсказать, что произойдет на стороне клиента. Динамический шаг по времени хорош по многим причинам, если вы запускаете один экземпляр вашей игры, и он не будет синхронизироваться ни с чем другим. Это предоставит вам всю мощь системы, запускающей игру. Но опять же есть цена за это. Вы не сможете предсказать, что произойдет, если вы снова запустите игру. рассмотрим простую физическую коллизию, когда одна коробка попадает в другую. Даже малейшее изменение шага по времени приведет к большим различиям в результирующем разрешении столкновения.
Существует простая причина, по которой люди используют Thread.Sleep, как вы и предлагали, потому что добавление большей точности не приведет к лучшей игре. Когда вы играете в игру, вы обычно не замечаете, находится ли объект на расстоянии одного или двух пикселей. Так что вы ничего не получите, увеличив точность. Также существует ограничение ширины полосы сети, как на стороне сервера, так и на стороне клиента. Это означает, что вы обычно не сможете отправлять более 30-60 обновлений в секунду. Поэтому я могу спросить, почему вы должны вычислять состояния, которые вы просто собираетесь выбросить?
Есть много случаев, когда повышение точности может вызвать проблемы. Например, люди, как правило, используют «Вертикальную синхронизацию», чтобы графический буфер не обновлялся во время отправки данных на монитор (что может привести к разрушению). Кроме того, большинство игр используют числа с плавающей точкой в качестве основного контейнера, но они не точны. Вы можете не заметить, когда числа находятся между 2 ^ -20 и 2 ^ 20, но за пределами этого диапазона вы увидите неточное поведение. Например, если вы попытаетесь добавить 10 ^ -5 к 10 ^ 5, это просто проигнорирует ваше добавление. Подобные ошибки обычно не видны, но когда вы не имеете полного контроля над своим шагом времени, все может стать уродливым. В вашем случае, поскольку не требуется рендеринг, я предполагаю, что ваше время обновления должно быть не более 10 ^ -4, то есть все изменения для чисел выше 100 будут испорчены!
В некоторых играх только команды игрока могут привести к непредсказуемым изменениям. поэтому вы можете использовать ваш сервер только для передачи команд каждого игрока другим игрокам. В этих случаях вы можете просто подождать, пока один из клиентов не отправит серверу обновление. Между этими обновлениями ничего не просчитывается, это означает, что клиенты могут делать все (кроме широкого вещания), поэтому пусть сервер выполняет только свою работу и оставляет все остальное клиентам.