Игры и CASE-технологии
Современная программная индустрия за последнее десятилетие сделала огромные шаги. Мы подчас не замечаем этого, работая с привычным Нортоном, текстовыми процессорами типа WinWord, компиляторами VC++ 4.2 и BC++ 5.0 под Windows, и считаем, что прогресс компьютерных технологий ограничивается совершенствованием оболочек, увеличением скорости компиляции, расширением возможностей библиотек OWL или MFC и появлением пакетов типа GameSDK.
Однако, современные технологии разработки больших программных комплексов достигли не виданных пару лет назад высот. А сегодняшние игры, представляющие из себя подчас очень сложные информационно-моделирующие системы, разрабатываются подчас по старинке. Тратятся огромные суммы на доведение проекта до коммерческой версии, и с опозданием на полгода-год, а то и пару лет на рынок выбрасывается продукт, полный багов. Руководители крупнейших игровых фирм стонут в поисках хороших project-менеджеров, считая, что все их проблемы проистекают только из-за нехватки квалифицированных руководителей и постановщиков.
Однако уже давно известно, что проблемы реализации крупных проектов заключаются не столько в нехватке кадров, сколько в физической невозможности человеческого мозга отслеживать все взаимосвязи в программе. Не помогает структурное программирование, объектный подход, которые полезны только на уровне локального программирования, кодирования или продумывания структуры кода (Programming in Small), но ничего не дают, когда размер программы начинает исчисляться миллионами строк.
Кроме того, большое значение играет способ организации интерфейса с пользователем, накладывающий ряд ограничений на структуру программы. Для Windows-игр ядро должно быть событийно-ориентированным, для DOS это не обязательно (хотя желательно). Многое зависит от «идеологии» графического механизма: в DirectX используется одна методика выделения этапа отрисовки экрана, в трехмерных ДОСовских библиотеках все устроено совсем по-другому.
Обычно, эти вещи начинают учитываться на этапе кодирования, когда гэйм-менеджер примерно распределил роли (ты пишешь алгоритмы поведения, ты трехмерный механизм, ты ваяешь спрайтики) и начинает «давить». В результате на этапе стыковки разных частей игры возникают непредвиденные противоречия типа: «А чего это ты нарисовал по десять спрайтов на каждую базу? У меня они все статичные,» — или, — «А че твои мужики так долго думают? у меня экраны еле-еле сменяются».
Это самые примитивные примеры. Наиболее серьезные ошибки на этапе проектирования в дальнейшем обычно приводят к полной неработоспособности программы и необходимости переписывания ее с самого начала. Преимущество объектного подхода на уровне Programming in Large — лишь фикция, так как неправильно спланированная структура объектов и их взаимосвязей все равно приводит к необходимости переделки, что подчас при объектном подходе к созданию игры еще сложнее. Хотя во многих современных играх намечается тенденция к их упрощению в сторону многомегабайтного «омультимедиовывания», появляются игры и с довольно сложными внутренними моделями, например, GeneWars или амбициозный проект Shattered Legacy (Ultima On-Line) от Origin.
Даже несколько ведущих гэйм-менеджеров и бригадный подряд, придуманный IBM, не спасут такие проекты от краха без использования полноценных технологий разработки ПО. Наивно думать, что ведущие игровые компании создают свои наиболее крупные продукты «дедовским способом». Внутрифирменные технологии являются секретной конфиденциальной информацией, оберегаемой значительно более тщательно, чем исходные тексты трехмерных механизмов и алгоритмов ИИ.
Для ряда неигровых областей программной индустрии имеются специализированные средства (CASE-системы, Computer Aided Software/System Engineering), позволяющие на визуальном уровне разрабатывать огромные программные комплексы, не содержащие на уровне кода ни одной ошибки. Основной упор здесь делается на создание МОДЕЛИ проекта. Эта модель описывается с помощью стандартных нотаций (SADT (IDEF), DFD, диаграмм Чена, Йордона/ДеМарко, Гэйна/Сарсона и так далее), позволяющих в формальном виде представить на экране компьютера любые особенности модели, начиная от информационной структуры данных, функциональных зависимостей или процессов, протекающих в реальном времени (стандарт STD, диаграммы перехода состояний).
В дальнейшем CASE-система сама генерирует код для созданной в визуальном редакторе модели. Любые изменения вносятся в программу только на ее уровне, не вызывая логических ошибок на этапе отсутствующего ручного кодирования, что позволяет легко менять внутреннюю структуру программного продукта без боязни побочных эффектов.
Уже давно проверено опытом, что без построения тщательно продуманной модели фактически невозможно успешно и без ошибок реализовать крупный проект. Особенно это актуально для сложных систем управления движением, контроля за функционированием АЭС и так далее. К счастью, имеющиеся на сегодняшний день CASE-системы позволяют реализовывать подобные проекты с очень высокой степенью надежности.
Некоторые особенности CASE-идеологии прямо-таки напрашиваются быть использованными для создания игр. Дело в том, что системы автоматического создания программ нередко малоэффективны в областях, плохо поддающихся формализации, особенно в России, где практически во всех областях царит полный бардак, причем даже банковская система — отнюдь не исключение. Но для строго формализуемых задач CASE-системы просто незаменимы, а игры и являются именно такими задачами, так как все действие происходит в виртуальном и соответственно предельно детализированном мире.
При этом плюсы CASE-подхода очевидны. Это, прежде всего, очень быстрое создание игр, не содержащих ошибок, и возможность многократного использования наработанных моделей (на уровне объектной идеологии этот подход, к сожалению, пока совершенно не оправдал себя) в последующих играх. Формальные нотации позволяют описывать абсолютно все типы игр, например, большинство CASE-систем дают возможность создавать полноценные адвентюры, где действие легко описывается, например, графом. Для описания real-time игр (и не только игр, а множества динамических процессов) существует, как уже говорилось, STD-нотация. Конечно, трудно найти CASE-инструментарий для автоматического создания Dune-подобных игр, но по крайней мере для поддержки соответствующей модели на протяжении всего этапа создания проекта это делать сегодня просто необходимо.
Выигрыш в скорости разработки достигает порядков. Это реальные практические цифры. Однако не стоит, конечно, считать, что достаточно купить CASE-систему, и она сама напишет для Вас игру. Не следует забывать, прежде всего, что эти системы стоят довольно дорого. Одно клиентское место подчас может обойтись в 5-7 тысяч долларов. Но самое важное значение приобретает процесс создания безошибочной модели.
И здесь никакие программные продукты уже не помогают, на первое место выходит человек-специалист. Их называют обычно системными аналитиками. Это очень дефицитная и высоко оплачиваемая специальность. Например, московское представительство компании Price WaterHouse, занимающейся системным анализом, реинженирингом бизнес-процессов (кардинальным улучшением работы компании с помощью исследования ее структуры и реорганизации деятельности — чем не некая динамическая деловая игра?), берет за один день работы своего системного аналитика полторы тысячи долларов. И эти деньги окупаются очень быстро.
Интересно, что уже выпускаются специализированные, можно так сказать, игровые CASE-системы типа Klik’n’Play. Они пока не обладают полнофункциональными возможностями для создания, например, коммерческой адвентюры, но уже демонстрируют нечто, близкое к высокоуровневой технологии разработки программ.
Вывод, собственно, достаточно очевиден. При создании достаточно сложной игры просто необходимо иметь формализованную модель, описывающую все игровые взаимосвязи. Важно понимать отличие понятия «модель» от всем привычного «Технического Задания», описывающего, ЧТО должно получиться. Модель же детально описывает, КАК игра должна работать. Конечно, покупать CASE-системы в ряде случаев нерационально, но иметь формальное описание модели нужно обязательно.
Иначе проект может растянуться на годы, или не завершиться вообще. Начинать, в принципе, можно с формальных описаний на листочках в клеточку, даже на таком уровне формализации время, потраченное на продумывание модели, окупится сторицей. Главное, чтобы описания эти осуществлялись с помощью строгих правил. Имеется ряд книг по различным нотациям (наиболее распространены IDEF-описания), переведенных на русский, их хоть и не много, но они, к счастью, начинают появляться. На английском же соответствующую информацию можно выкачать из Интернета.
Одним из краеугольных камней системного анализа является фундаментальный вопрос «какая модель первична — информационная или функциональная», или что же описывать — объекты и взаимосвязи между ними или движение информации между объектами. Обе эти модели имеют право на существование, и способы выбора адекватной модели — тема отдельного разговора.
Резюмируя, можно сказать, что использование CASE-технологий в самых разнообразных программистских (и не только!) проектах дает однозначный существенный выигрыш. Как реализовать его для быстрой разработки надежных игр? Надо пробовать, начинать с небольших проектиков, постепенно осознавая все преимущества использования формальных моделей игровых процессов, и постепенно переходить к крупномасштабным проектам. Это известный итерационный процесс обучения, касающийся не только «кэйзов», но и любых других отраслей человеческого знания. Ведь имеющиеся программные комплексы и технологии могут очень и очень существенно помочь многим разработчикам компьютерных игр.
Сергей Бобровский, 1996
Советуем почитать:
- REAL-TIME-STRATEGY: кризис перепроизводства
- Хороших игр много, а выбрать нечего!
- Новости PC. Навигатор игрового мира, №1 1997
- В потоке новостей. PC-REVIEW выпуск 30, 1996
- Как сделать компьютерную игру и надо ли ее делать вообще
- Цивилизация в коротких штанишках. В ожидании игры Age of Empires. Первый взгляд | Game.EXE
- Обзор Sid Meier’s Gettysburg | Страна игр