Как стать автором
Обновить

Комментарии 20

Думал я все же прикупить казаков на распродаже, сейчас за 5$ стоят, но что-то как-то…
А вам не кажется, что это какая-то дичь, что написано одно, а в игре всё происходит по другому. Как в такие игры играть, как просчитывать стратегию?
Как в дьябле-2 — проверять, что есть по факту, потом учитывать то, что в реальности происходит, а не то, что написано в мануале. Там подобных косяков (местами именно косяков, а не просто фич вроде EIAS threshold или багофич вроде mastery amplification при атаке врукопашную, если атакующий с этой же mastery на себя энчант кастил) воз и маленькая тележка.

В данном случае следует учитывать, что скрипты игры до сих пор активно дорабатываются (что не может не радовать). Например, в версии 2.0.8 файл unit.script имел размер в 131 KB, а в анализированной здесь версии 2.1.4 — 546 KB.

Опять арифметическое складывание в знаменателе вида Y=X/(1-A-B). Этим грешат примерно половина* разработчиков, которые получают на вход задание вида «на A% чаще/быстрее», интерпретируют его как «задержка становится на A% короче» и игнорируют изменения соседних фич такого же класса. Тут ещё и усугубили округлениями (так что тики-таки остались, внутренняя механика продолжает считаться в тиках).

Мне интересно, к чему приведёт отказ от округления? Из публикации не особенно понятно как юнит решает что пора сделать выстрел?


Если там используется некоторый параметр времени отката, который обнуляется при выстреле, то из-за дискретных тиков реально он будет округляться как floor или ceil, что может быть хуже чем round.


Или вдруг там делается сравнение с целочисленными тиками, и из-за дробного интервала проверка никогда не вернёт true и стрельба станет невозможной.

Смотря в самом деле, как именно запилена логика разрешения стрельбы. Я, когда TD пилил, делал целочисленный аккумулятор, в который каждый тик прибавлялась скорость стрельбы, здесь явно не так. Скорее всего, здесь применена логика с параметром «время до следующего выстрела», которое подтягивается из таблицы типов юнитов, куда записываются данные после проведенных исследований, например, и время это целое (с шансом 95%, остальные 5% на вещественное и логику сравнения «меньше нуля» при проверке разрешения на стрельбу). Т.е. параметр времени отката есть, при проверке сравнивается с нулем, и при выстреле заполняется значением из таблицы, которое при отсутствии округления по умолчанию будет работать как floor. ИМХО.

Ну как минимум, одно из округлений надо точно убирать — нормально прочитал таблицу и увидел, что округление идет до секунд вместо тиков, и вот это невыразимый пипец.

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

Насколько я понял, тики всё же атавизм, движок третьих Казаков работает с секундами. Скорее всего, раньше параметр интервала хранился в тиках и пересчитывался в секунды непосредственно перед применением в _unit_ApplyAttackPause(). Потом в каком-то обновлении, скорее всего, изменили логику и стали хранить интервалы сразу в секундах, но вот код применения апгрейда оставили тем же.

Тогда понятно, зачем округление, и пока вся механика была в тиках, оно было нужно. А как на секунды поменяли, о нем не вспомнили, а эффект от него в 32 раза больше, чем на тиках, в результате исходные 1-2% погрешности выросли в 30-60%, и при двукратном применении добрались до 210%. Нормальная поддержка легаси-кода, baseline сменили, выстрелило в ногу.
Согласен. Ещё меня интересует, как это осталось незамеченным.
Производитель газировки думает привлечь новых клиентов и имеет два варианата:
1) Увеличить объем воды на 10% со старой ценой.
2) Уменьшить стоимость на 10% при том-же объеме.
Что для покупателя выгоднее?
очевидно уменьшить стоимость.
всегда для подобных задач/вопросов меняю цифры на граничные и сравниваю результат)
например, если уменьшить цену на 99% — получим в 100 раз меньше цену, увеличим объём на 99% — получим почти в два раза больше воды.

это просто, что б на калькуляторе не считать, а интуитивно сразу ответить)
Да, я так-же решил. Это всего-лишь пример разницы "*1,3" и "/0,7"
Ага. Мне понравилось, что в Age of Empires II интерфейс заявляет у японцев +25% к скорости атаки пехоты, а на деле их самураи рубят на 33% чаще. Должно было быть t/1.25, а сделали t*0.75.
А потом: «Математика программистам не нужна»
Вчера вышло обновление 2.1.5, есть изменения в балансе. По всей видимости, у юнитов категории X после улучшений интервал становится меньше времени анимации. Это приводит к тому, что стрелки подвисают после первого выстрела и перестают стрелять: видео.
Видать, округление не убрали и после округления получили 0.0 :D
Казаки были хороши. Но вторая эпоха империй нравилась больше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории