Ещё можно заметить, что в ряду M-D-C-L-X-V-I те числа, которые участвуют в позиционном вычитании, находятся на позициях 2, 4 и 6. Я использовал это в своём решении.
У них добровольцы читали описание происшествий, в которых никто не пострадал, но при этом всё равно достойных порицания. Например, в одной истории родственники занимались безопасным сексом по обоюдному согласию, а в другой хозяин собаки приготовил и съел её после того, как ту насмерть сбила машина. Читавшие истории на чужом языке (английском или итальянском) осуждали их меньше, чем читавшие их на родном языке.
Эти истории что, действительно достойны порицания?
Если честно, я просто не хочу усложнять. Возможно, позже, через пару версий, добавлю методы, возвращающие Promise. Может, сделаете форк? Что-то в духе timestore-promises?
Даже если будут потери в 5-10 мс, это не критично для поведения, описанного выше. Естественно, все движения юнитов и коллизии должны считаться в game loop. Что касается путаницы, то можете глянуть код моего проекта из предыдущего поста. Мне кажется, там всё достаточно ясно.
В том-то и дело, что определённое поведение повторяется через разные промежутки времени. Допустим, есть юнит-матка, который генерирует юнита-пчелу каждые 10 секунд и выстреливает вокруг себя кислотой каждые 4 секунды. Если засунуть эти действия в функцию обновления сцены, то при 60 fps в 10-секундном цикле будет 599 холостых проверок вида «а не пора ли нам сгенерировать пчелу». Если же поведение юнита ещё сложнее, «пустых» проверок будет ещё больше.
Да, так тоже можно делать, но зачастую у объектов довольно много аспектов поведения, и проверять их все в каждом тике получается накладно по производительности.
То есть, допустим, общие аспекты, вроде гравитации, стоит применять в Object.tick(), а поведение, повторяющееся через какой-то промежуток времени, вроде атаки вражеского юнита в платформерах, удобно вынести в отдельный метод и управлять им через отдельный таймер.
Спасибо, очень здорово! Кстати, если много раз нажимать на Animate, рандомные анимации почти нейтрализуют друг друга, и стрелки едва дёргаются под напором противоположных по знаку чисел.
Заголовок настолько отчаянно-жёлтый, что даже и не вызывает отторжения.
Упс. Да, в этом, спасибо! Это я решил начисто опубликовать, без тестов и с комментариями.
Странно, я не параною, и мой телефон есть во многих профилях в сети, но в базе его нет.
Скорее, Валерина мухоловка.
Ещё можно заметить, что в ряду
M-D-C-L-X-V-Iте числа, которые участвуют в позиционном вычитании, находятся на позициях 2, 4 и 6. Я использовал это в своём решении.И да, спасибо за CheckiO!
Спасибо!
Потому что присутствует случайность выбора?
Я бы для анимации использовал что-то вроде PixiJS.
Каюсь, тут я опирался на старый стандарт. Скорее всего, добавлю метод
.callWith(arg1, arg2, ...), который можно будет использовать в цепочке:Вы про эти —
setTimeout(calback, delay, [arg1], [arg2], [arg3])— аргументы?Если честно, я просто не хочу усложнять. Возможно, позже, через пару версий, добавлю методы, возвращающие Promise. Может, сделаете форк? Что-то в духе timestore-promises?
Даже если будут потери в 5-10 мс, это не критично для поведения, описанного выше. Естественно, все движения юнитов и коллизии должны считаться в game loop. Что касается путаницы, то можете глянуть код моего проекта из предыдущего поста. Мне кажется, там всё достаточно ясно.
Да, так тоже можно делать, но зачастую у объектов довольно много аспектов поведения, и проверять их все в каждом тике получается накладно по производительности.
То есть, допустим, общие аспекты, вроде гравитации, стоит применять в
Object.tick(), а поведение, повторяющееся через какой-то промежуток времени, вроде атаки вражеского юнита в платформерах, удобно вынести в отдельный метод и управлять им через отдельный таймер.Спасибо, очень здорово! Кстати, если много раз нажимать на Animate, рандомные анимации почти нейтрализуют друг друга, и стрелки едва дёргаются под напором противоположных по знаку чисел.