Dagaz: Ошибки

Дело помощи утопающим —  
дело рук самих утопающих.

И.Ильф и Е.Петров.
 
 
Ошибки ошибкам рознь. Работая над проектом ^[1], я веду свой личный рейтинг ошибок ^[2]. Что-то исправляется совсем легко, при первом запуске, что-то намертво прибито гвоздями к архитектуре и потому отравляет жизнь годами. Некоторые ошибки просто вымораживают. Когда их исправляешь — чувствуешь, что живешь. Я люблю такие ошибки.

Всё время писать одинаковые игры было бы не интересно. К счастью, игры разные. Некоторые игры более разные чем другие. Честно говоря, я и берусь то за них, в основном, из за уникальности их игровых механик. Для меня такие игры — своего рода вызов.

Всё дело в этих самых «стреляющих» фигурах. Сам по себе «выстрел» кодируется довольно просто, но для того, чтобы появилась возможность «стрелять» два раза подряд, пришлось залезть в ядро ^[5]. Дело в том, что ещё со времён с Zillions ^[6], такая последовательность действий трактуется как составной ход, то есть последовательность частичных ходов, выполняемых одной фигурой, а «выстрел» — это, по сути, перемещение той же фигуры на другую позицию. Не на ту, с которой должен выполняться следующий частичный ход (второй «выстрел»). С этим пришлось повозиться.

Поскольку я пока не придумал, как реализовать бота для этой игры, то сделал её в режиме «интеллектуальной доски», контролирующей соблюдение правил, но без игрового AI. Это сыграло со мной злую шутку. Ошибка совершенно никак не проявлялась при ручном управлении фигурами, но стала очевидна, как только я начал делать бота для "Амазонок ^[7]".

Строго говоря есть ещё одна игра с похожей механикой

Но для неё ^[8] я бота тоже не делал. Думаю, вы понимаете почему.

В случае с «Амазонками» я нашёл обходной путь ^[9] и не стал лазать в ядро, но для Hanga Roa такое решение не подходило. Поскольку бота для игры всё равно не было, я забросил это дело в долгий ящик (и оно продолжало грызть меня изнутри). Так бы и продолжалось, если бы, работая над "Квантовым Моррисом ^[10]", я не наткнулся на такое вот паскудство:

Проблема усугублялась тем, что ошибка, по всей видимости, проявлялась в зависимости от фаз Луны. Это (а также ряд других случаев) наглядно показало, что пришло время для переписывания кода анимации перемещения фигур, с которого проект практически начинался. Поймите меня правильно, я не ринулся переписывать view ^[11] сразу. Я убеждал себя в том, что это необходимо, ещё около месяца. И в конце концов, убедил ^[12]. Код стал проще и понятнее. Попутно, стали более очевидны и другие ошибки, мучившие меня долгое время.

Картинка кликабельна. Полюбуйтесь, как чёрный шарик, завершив ход, превращается в белый (хотя и совсем не должен этого делать). Со старым view он оставался чёрным и ошибка была не так очевидна. На view фигура оставалась чёрной, но управлять ей игрок более не мог (поскольку, в model то она была белой) и это бесило. Строго говоря, это ошибка модели, но к ней (как и к утилите конвертации ZRF-кода в JavaScript) уже и так накопилось много вопросов.

По хорошему, там всё надо переписывать, но я к этому пока морально не готов. Поэтому, я сделал очередной "быстрый фикс ^[13]" и в Фанорону ^[14], теперь, можно играть нормально, без сопутствующих чудес. В "Русские шашки ^[15]", кстати, тоже. Там был баг, связанный с реализацией правила "турецкого удара ^[16]", неожиданно легко исправленная этим ^[17] простым фиксом. Так я работаю над ошибками. Так я делаю проект лучше.

Автор: GlukKazan

Источник ^[18]