Metal Gear

Как уже было сказано, роль этапа разработки технических требований заключается в четкой формулировке проблемы. При этом следует избегать очень распространенной ошибки, когда в технические требования включаются те или иные положения, навязывающие какие-то конкретные методы решения проблемы. Следует прилагать усилия к тому, чтобы технические требования носили как можно более выраженный описательный характер и содержали лишь общие формулировки, чтобы свести к минимуму их влияние на кон1фетные архитектурно-проектные решения создаваемой системы ИИ. Конечно, подготавливая технические требования, мы уже можем представить, как будем решать тот или иной аспект проблемы. Однако при этом нужно воздержаться от соблазна отражать эти предварительные соображения непосредственно в технических требованиях. Главная причина применения такого подхода состоит в том, что решения, которые на этапе разработки технических требований нам кажутся блестящими и единственно верными, на поверку часто оказываются непригодными к реализации и (или) неэффективными.
При этом не следует рассматривать этап разработки технических требований как некий сверхсложный мыслительный процесс, с которым могуг справиться лишь избранные. Подготовка технических требований — это достаточно простая и интуитивно понятная задача, с которой справится любой человек, имеющий достаточный опыт использования и разработки компьютерных игр и владеющий десятком-другим соответствующих терминов. Для изложения на бумаге вполне приемлемых технических требований нужно лишь потратить некоторое время на исследование и анализ задачи, а также учесть общий контекст проекта, для которого будет создана система ИИ. Затем, как рассказано в двух предыдущих разделах этой главы, нужно формализовать полученные результаты и выводы и изложить их в письменном виде. Следует заметить, что на этом этапе очень важно ознакомиться с потребностями других разработчиков, которые необходимо учесть в будущей системе, а также с проблемами, которые волнуют художников или проектировщиков (будьте готовы к тому, что формулировки этих проблем могут оказаться весьма расплывчатыми и нечеткими).
Как правило, получившийся перечень технических требований оказывается в той или иной степени неоднозначным. С одной стороны, это неизбежный результат применения текстовых описаний, для которых характерна неоднозначность трактовок и интерпретаций. Однако с другой стороны, можно рассматривать эту неоднозначность как преимущество, поскольку она позволяет впоследствии, не меняя технических требований, гибко изменять решение, если в этом возникает необходимость. Конечно, следует учитывать и оборотную сторону такой гибкости, которая заключается в неверной трактовке или недопонимании технических требований, что может привести к нарушению технических условий и поставить под угрозу срыва весь игровой проект в целом. Поэтому особое внимание следует уделять тем критериям, которые в значительной степени связаны с другими аспектами архитектурно-проектных решений игры, стараясь в формулировках таких критериев избегать неоднозначности настолько, насколько это возможно.