Как можно оптимизировать работу с итератором цикла в моем случае?

Question

[lambakean]

Здравствуйте, я для интереса пишу небольшую 2D игру, в процессе работы появился вопрос.
На игровом поле должна спавниться еда, которую едят юниты.
В игре есть основной цикл - бесконечный, который прерывается лишь при закрытии игрового окна. Одна итерация цикла проходит раз в 1/20 секунды, то есть в игре 20 ФПС. Мне нужно, чтобы раз в 25 кадров на игровом поле спавнилась еда. Точнее, мне это не нужно, я это уже сделал, но сделал я это с помощью остатка от деления итератора на 25. На Python'е это i%25. Каждый раз при выполнении цикла проверяется остаток от деления итератора на 25, и если этот остаток равен нулю - пора спавнить еду.
Так вот, можно ли каким-нибудь образом оптимизировать это? Может быть, конкретно у языка Python есть для этого какие-нибудь инструменты? Возможно, искать остаток от деления 20 раз в секунду это не очень хорошее решение, учитывая то, что у меня есть несколько видов еды, каждый из которых спавнится на поле с разным промежутком времени, для каждого вида приходится вот так вот искать остаток.

Answer 1

[twobomb]

Искать остаток от деления 20 раз в секунду это незаметная мелочь. Но у меня вопрос другой, почему вы не сделали спаун еды по времени и почему всего 20 фпс?
А если у меня очень слабый компуктер и выдает всего 10фпс, то играя в вашу игру я буду получать еды меньше чем другие в два раза...
Обычно как делается, есть переменная deltaTime, можете сами ее высчитывать. Это время прошедшее с последнего кадра, до этого (1 итерация). В идеале в вашей игре это 0,05, но если игра зависнет на 2 секунды то оно будет равно 2.
Так вот, желательно бы делать движения, спаун еды и все остальное относительно этого времени.
То есть создаем переменную, типа buffSpawnFoodTime. Прибавляем каждую итерацию к ней deltaTime.
К примеру спаун еды идет каждые 1,5 секунды. Количество спаунов еды на этой итерации равно

count = int(buffSpawnFoodTime/ 1.5)
buffSpawnFoodTime -= int(buffSpawnFoodTime/ 1.5) * 1.5

В таком случае если игра зависнет на 6 секунд, то после развисания произойдет положенные 4 раздачи еды.
И вообще зависимость игры от фпс это очень не хорошо.

Comments

[lambakean]

Спасибо, этот способ гораздо более правильный. У меня сейчас принятие юнитами решений ("Что лучше всего сделать в данный момент?") происходит строго перед отрисовкой очередного кадра, то есть тоже 20 раз в секунду, поэтому при увеличении частоты кадров юниты начинают чаще принимать решения и, соответственно, скорость игры увеличивается. Поэтому пришлось строго задать 20 ФПС. Сейчас переделаю всё и сделаю частоту ходов юнитов независимой от ФПС.

[twobomb]

lambakean, Есть еще такой прием, когда разделяют эти самые, главные циклы. Например один отвечает за рендер(отрисовку), другой за физику, можно сделать один за логику.При чем тот который за физику может работать быстрее, а тот например который рендер медленее.
По поводу принятия решения, я не знаю как и что там у вас. Ну можно например так.
Определяется рандомное число к примеру от 5 до 10 , это будет время в сек когда следующий раз юнит будет принимать решение. Обсчитываем это время всё по тому же принципу, или можно по такому, у каждого юнита переменная lastTimeAction. Содержит к примеру timestamp (кол-во секунд от начала работы программы или от 70 го года не важно), тоесть проще говоря время когда этот юнит последний раз принимал решение. Далее переменная secToAction, это то самое рандомное число через которое он будет действовать. И на каждой итерации проверяем если текущеее время минус lastTimeAction >= secToAction тогда юнит принимает решение и мы ему в secToAction генерим новое число от 5 до 10, и в lastTimeAction = текущее время. Если есть выбор сложности, то можно менять этот диапазон 5-10/ 3-6/ 1-3 к пример легко/средне/сложно, чтобы на легком уровне все слегка тупил, а на сложном раздавали...

[lambakean]

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

Как ты советовал, я сдеал так, чтобы высчитывалось, сколько раз прошло, допустим, 1200 мс с прошлого спавна еды - столько раз новая еда и будет спавниться, поэтому при лагах меньше еды не будет.

Осталось только доделать ограничение частоты кадров. 60 фпс, наверное, будет достаточно