В посте, посвященном плану работы, я вскользь коснулся темы ошибок, которые можно допустить на тех или иных этапах разработки игры, и об их влиянии на все последующие этапы. Здесь я бы хотел остановиться на этом вопросе более подробно и обсудить последствия ошибок (самого широкого класса, не обязательно связанных с написанием кода), и некоторые способы их предотвращения и своевременного устранения.
Неизбежность ошибок
Как известно, ошибки есть во всех реальных приложениях, и это объективный факт. Мы можем только сказать, что в хорошо отлаженных приложениях процент ошибок приемлемо низок. В идеале они всплывают очень редко и последствия их оказываются сравнительно безвредными.
Конечно, нам хотелось бы вовсе избежать наличия ошибок, но на деле это оказывается практически невозможно. Единственный реальный способ получить абсолютно безошибочный код - это составить его точную математическую модель и затем математически же доказать, что в коде нет ошибок.
Примером может служить проект seL4, созданный австралийскими учеными из центра NICTA, представляющий собой ядро операционной системы общего назначения, отсутствие ошибок в котором было доказано с помощью специальной машинной системы доказательств (Isabelle). Согласно пресс-релизу, при проверке имеющихся 7500 строк Си-кода (сейчас их около 8700) было доказано более 10,000 промежуточных теорем в более чем 200,000 строк формального доказательства.
Естественно, что такую точность может позволить себе далеко не каждый разработчик, поэтому обычно мы стараемся просто минимизировать количество ошибок различными средствами, но не тешим себя надеждами, что однажды сможем полностью от них избавиться.
Впрочем, в дальнейшем мы будем говорить об ошибках не только в коде, но и вообще об ошибках, возникающих во время всего процесса разработки.
От чего зависят масштабы бедствия
Итак, в нашем проекте есть ошибки, и это плохо. Возникает естественный вопрос - насколько? В первом приближении мы можем легко сказать - чем больше ошибок, тем хуже. Но количество - далеко не единственный фактор, влияющий на серьезность проблем, которые ошибки влекут за собой.
Другим важным фактором является их время жизни. Как я уже говорил, чем оно больше, тем больше дальнейших наработок испытает влияние этой ошибки, и тем труднее будет нивелировать все ее последствия.
Из этого можно сделать два очень важных вывода. Первое - ошибки необходимо обнаруживать как можно быстрее. Второе - вовремя не обнаруженная ошибка имеет тем более глобальные последствия, чем на более раннем этапе она была допущена. Именно в этом ключе необходимо понимать все мои высказывания относительно степени важности тех или иных этапов разработки: решения, принятые на более поздних этапах, зависят от решений, принятых на более ранних, а те в свою очередь зависят от еще более ранних (мнение о том, что на ранних этапах нельзя допускать ошибок, а на поздних можно, неверно - ошибок нельзя допускать ни на одном этапе).
Скажем, если у нас есть последовательность этапов A -> B -> C (решения на этапе C зависят от решений, принятых на этапе B, а те в свою очередь - от принятых на этапе A), то допустив ошибку на этапе A, мы вынуждены исправлять как ее, так и последствия, возникшие на этапах B и затем C. Ошибившись на этапе B, нужно исправить ошибку в B и ее последствия в C. Ошибившись в C, нужно исправить только саму ошибку.
Именно поэтому самые ранние этапы разработки самые важные - если после того, как игра будет уже готова к релизу, мы решим изменить ее жанр... Или даже если мы в этот же момент решили сделать игру кроссплатформенной, а она вся написана на WinAPI и DirectX (а движок, если он и есть, вовсю оперирует винапишными структурами и его функции повсеместно возвращают именно их) - что ж, нам придется писать игру заново.
Другое дело, если мы решим просто изменить ТТХ одного из монстров или текстуру главного героя. Сделать это будет очень просто, поскольку от этих действий практически ничего не зависит, кроме конечного результата, который мы увидим в игре. Немного больший объем работ придется провести, если окажется, что какой-то игровой уровень окажется слишком легким/сложным (тогда придется менять ТТХ или количество всех монстров на этом уровне) или если модель героя смотрится плохо в каком-то из ракурсов (вместе с моделью придется менять и текстуру, и, возможно, анимацию). Но все же это тоже сравнительно простые задачи.
Что же делать?
Итак, какие практические выводы можно сделать из всего вышесказанного?
Главный из них заключается в том, что ошибки необходимо обнаруживать как можно раньше. Один из способов это сделать - проводить тестирование как можно раньше и как можно чаще. Каждую сложную систему проверяйте с самого начала ее создания на простых прототипах, не ждите завершения работы над ней. Во-первых, когда система создана еще не целиком, обнаруживать и локализовывать проблемы гораздо проще, чем когда она достигнет финальных размеров; во-вторых, не придется исправлять то, что, как было сказано выше, окажется завязано на ошибочную часть.
Пишите код так, чтобы ошибки проявлялись на как можно более раннем этапе - желательно на этапе компиляции. Для этого как можно подробнее объясняйте компилятору, чего вы хотите добиться, и какими свойствами должен обладать ваш код (к примеру, в C++ вы можете делать это с помощью ключевых слов const, explicit, применения enum-ов, запрета на использование ненужных конструкторов или operator= и т.п.), и тогда он сможет отловить многие ошибки уже во время компиляции. Статическая проверка типов также льет воду на нашу мельницу.
Если функция могла вернуть неправильный или недопустимый результат - проверяйте полученное значение (если мы не смогли открыть файл на чтение, гораздо лучше узнать об этом сразу, а не когда мы начнем работать с данными, которые должны были быть из него считаны, но оказались заполнены старыми значениями или мусором).
На самом деле, можно многое сказать по поводу выявления и обработки ошибок, не относящееся напрямую к вышеизложенному, однако я отложу это до другого случая. Главная рекомендация на сегодня - ищите и находите ошибки как можно раньше и используйте для этого все доступные средства.
Комментарии
Гений не ошибается, умный - учится на чужих ошибках, дурак на своих, а идиоты не обучаемы (с)
Главное решать проблему сразу, а не хвататься за голову и рыдая думать "а что было бы если бы" - трата времени и нервов, лучше потратить их на устранение проблемы!
RSS лента комментариев этой записи