Почитаем...

Какая среда проектирования является наилучшей для программистов, занимающихся созданием игр?

Естественно, однозначного ответа на этот вопрос не существует. Все зависит от команды, проекта, платформы, движка - все эти переменные должны приниматься во внимание при выборе среды проектирования. Например, если вы занимаетесь разработкой консольной игры, вам придется использовать тот набор инструментов, который навязывает разработчик "железа", дополненный любыми доступными "хаками", обеспечивающими возможность работы с привычными инструментами. Если вы занимаетесь разработкой игры для Mac, забудьте об инструментах компании Microsoft! А если вы разрабатываете игру на Flash, ну, тогда вы создаете с помощью Flash, если, конечно, вы не нашли средства превратить OpenLaszlo в компоновщик игр.

Допустим, у вас есть движок на С++, и вы работаете на платформе PC, что является стандартной ситуацией для большинства разработчиков игр ввиду открытости и доступности такой платформы. Наилучшей средой проектирования игры, в данном случае, несомненно будет Visual Studio. Замечательный компилятор, у которого есть полезные расширения языка С++, поддержка .NET для быстрого написания вспомогательных утилит, и лучший отладчик на рынке. Несмотря на то, что VS является коммерческим, в отличие от Eclipse или Emacs, и дополнительные компоненты, расширяющие технические возможности Visual Studio (такие как VisualAssist от WholeTomato, который я обожаю) тоже стоят денег, даже без них можно работать эффективно. Если вы будете пользоваться им постоянно, то вам придется научиться обходить некоторые странные особенности среды, в основном, связанные со скоростью работы интерфейса, но оно того стоит.

Среда проектирования - это нечто большее, чем просто инструменты и утилиты, которые Вы покупаете или скачиваете. Это целая экосистема, состоящая из инструментов, работников, процессов, стандартов, конвейеров контента, в общем, всего, что входит в процесс создания игры. "Лучшая" среда проектирования - это среда, которая позволяет разработчикам предельно быстро и безошибочно выразить дизайн игры в виде работающих функциональностей.

Под словом "быстро" подразумевается, что используемая среда проектирования даёт возможность быстро добавить в игру те или иные функциональности, укорачивая временной интервал между рождением идеи, работой над ней и реализацией идеи в игре. Ключом к успеху являются частые итерации - чем больше идей вы можете испытать в короткие сроки, тем лучше. И вот тут вам понадобятся такие вещи, как автоматизация (для экспорта графики и сборки игр), динамическая компиляция (динамический язык сценариев (dynamic scripting language) или VC++ Edit & Continue, перезагрузка контента на ходу и снисходительный движок, который сможет работать при нехватке или отсутствии ресурсов. Создайте работающий и шустрый движок и забудьте на время о его точности.

"Безошибочно" означает, что среда проверяет контент в процессе загрузки, выявляет ошибки и выдает развернутый отчёт, показывающий разработчику простой и удобный метод устранения обнаруженных ошибок. Игра не должна падать, если есть ошибки в каких-либо простых вещах (например, ошибка в написании имени объекта). Среда проектирования должна: а) выявить проблему и предупредить о ней, предоставив эффективную информацию о том, как устранить ошибку; и б) сделать это наглядно и таким образом, чтобы разработчик обязательно заметил это предупреждение. Качественная система контроля и протоколирования, вкупе с эффективными экранными элементами (такими, как счетчики ошибок/предупреждений, которые остаются на экране) будет тут очень полезна. Это позволит сэкономить массу времени и нервов, и даст возможность проектировщикам больше концентрироваться на написании кода и меньше времени посвящать диагностике проблем.

Какие меры вы предлагаете для отладки игры, которая падает, виснет или частично не работает?

Первое, что приходит в голову - купите книгу Джона Роббинса (John Robbins) "Debugging Applications for Microsoft .NET and Microsoft Windows" и прочитайте ее от корки до корки. В книге рассматривается множество сценариев и процедур по диагностике крэшей. Эта книга обязательно должна быть у Вас в наличии.

Существует множество различных проблем, которые могут возникнуть в игре, и огромное количество способов для выявления и устранения их, и рассмотреть их все здесь и сейчас не представляется возможным. Однако, давайте разберем некоторые из них.

Поговорим о крэшах. Первым делом, выясните, действительно ли это именно крэш. Большинство - даже многие разработчики - называют "крэшем" практически все, что работает не так, как требуется, от простого сообщения об ошибке при повисшем приложении до "голубого экрана смерти" Windows. На самом же деле, настоящий крэш означает, что игра прерывается по причине недопустимой операции (например, нарушение прав доступа или переполнение буфера). Поэтому, для начала, нужно получить подтверждение тому, что мы столкнулись именно с крэшем, а не ошибкой в игре. Точно определите тип проблемы, прежде чем начинать отладку, иначе вы только зря потратите массу времени.

Большинство крэшей можно выявить элементарно путем обращения к стеку вызовов и регистрам, и изучению строчки кода, которая приводит к крэшу. Верхняя часть стека говорит о том, что именно поломалось, всё остальное обычно говорит, как именно. Из регистров билдов отладчика часто можно узнать, не является ли проблемой ссылка на нулевой указатель или на удаленный или неинициализированный указатель адреса ячейки памяти (если указатель регистрируется как 0xDDDDDDDD или 0xCDCDCDCD - это именно такой случай). Простой обработчик исключений верхнего уровня может показать пользователю стек (с символами, вынесенными из PDB) и регистры процессора на момент крэша, и в 80% случаев инженер может моментально определить, в чем дело, без нужды тратить время на изучение проблемы. Более продвинутая диагностика проблемы может включать в себя обращение к крэш-дампу для "произведения вскрытия" и анализа. Поскольку это занимает достаточно много времени, к прямой отладке (непосредственному просмотру машинного кода) нужно прибегать только в крайнем случае. В большинстве же случаев определить источник проблемы представляется возможным с помощью простого просмотра данных.

Более сложные крэши происходят при задействовании большого количества потоков или при наличии "латентных багов" (проблем с синхронизацией). В таких случаях, происходит Что-то Ужасное, но игра не крэшится сразу. Такие крэши бывает достаточно сложно отладить, и кроме имплементации упреждающих проверок однозначности данных по всему коду, что само по себе является передовой практикой, единственным надежным методом отлова таких багов является периодическое протоколирование состояния систем, которые имеют отношение к крэшу, и исследование данных лога после крэша в поисках ключей к разгадке - старый добрый "printf debugging". Существует множество решений для особых случаев, но в этой статье нет места, чтобы перечислить их все. Читайте книгу Джона!

Относительно "зависаний" - я предполагаю, что мы говорим о временных проблемах, таких как неоднородности в работе системы или периодические подвисания. Это обычно решается имплементацией в игру подпрограммы протоколирования, которая показывает затраты на работу тех или иных крупных систем с течением времени, желательно в виде простенького непрерывно перемещающегося графика, отображающего историю подвисаний в разных системах. Просто налюдая за тем, что происходит в игре, можно примерно определить, что временами заставляет игру тормозить. Например, клик мышкой часто инициирует загрузку ресурса, что дает скачок в той части подпрограммы протоколирования, которая следит за файловой системой. Понятно, что чтобы получить реальные данные, нужно обратиться к программам, осуществляющим контроль за ресурсами, и подпрограммам протоколирования графов вызова.

И, в заключение, лучший способ отладить "лок" зависит от типа "лока". Если речь идет о зависании (deadlock) в потоках, то могу сказать, что на эту тему опубликовано множество статей (включая и очень хорошую статью Джона Роббинса), где говорится о том, как решить такую проблему с помощью небольших изменений в синхронизированных классах. Если причиной "лока" служит бесконечный цикл, который загружает процессор на 100%, подключитесь туда программой-отладчиком. Или, если вы занимаетесь отладкой на системе, предназначенной для обычных пользователей, простым способом найти причину зависания будет использование отдельного потока, который следит за отрабатыванием определенных последовательностей нажатия клавиш, таких как Ctrl-Break (которую обычно нажимают при зависании). При улавливании "лока" все потоки замораживаются и всплывает диалог со стеками для каждого потока. На этом этапе проблема становится очень похожей на отладку крэша. И, наконец, если игра кажется повисшей, но при этом не занимает 100% процессора, проблема скорее всего в интерфейсе, который не обновляется - возможно, потому что он "залочен" в ожидании вызова от другого потока или одновременного вызова API. К такому случаю применим метод использования hang-watchdog потока, или всегда можно просто подключиться туда программой-отладчиком и посмотреть, в чем проблема. Проблемы с "локами" обычно не требуют поиска нетривиальных решений.

Имеет ли значение, какой язык программирования я использую?

Да, имеет значение, по множеству причин, некторые из которых - простота в приеме на работу/заключении временного контракта с программистами, которые будут работать над вашей игрой, простота в комплексировании сторонних библиотек, улучшение показателей эффективности (процессор, использование памяти, требуемый объем диска), обеспечение поддержки, набор характеристик, функциональные возможности, и еще миллион других вещей.

В некоторых случаях, у вас нет выбора. Если создается Flash-игра, то код нужно писать на Actionscript. Если вы работаете с Unreal, то вам придется писать на Unrealscript. Иногда нужно плясать от обратного: выбирая язык, вы принуждаете к использованию определенного движка. Например, если вы хотите создать игру на С++, вам придется заставить пользователей проинсталлировать огромный .NET Runtime, чтобы они могли играть. Это не такая уж и большая проблема для игр, выпускающихся на CD, но игры, которые доступны только путем скачивания, сильно пострадают. Хотя я слышал, что компоновщики .NET с каждым днем становятся все более компактными.

Однако на практике практически все предпочитают работать на С++, и не зря: это чуть ли не лучший из существующих языков, универсальный, высокоэффективный и с широкой поддержкой. Практически все нынешние движки главным образом пишутся на С++, и многие из них дополняются языком сценариев для поддержки проблемно-ориентированных особенностей, обеспечивают возможность динамической компиляции, упрощенное программирование и т. д. Интегрирование и эффективное использование движка С++ - дело не простое, так что будьте очень осторожны. Очень легко закинуть язык сценариев в игровой движок и обеспечить вызовы скриптами С++ функций, но гораздо сложнее облегчить поддержку и понимание интеграции - или, в сущности, подогнать под архитектуру движка.

Сколько времени удастся мне сэкономить при использовании стандартного движка?

В начале - очень много. Гораздо быстрее купить лицензионный движок и собрать на нем игру, чем перед созданием игры "с нуля" выкатывать свой собственный движок. При отсутствии нужного опыта для создания такого движка, вы получите на выходе тяжелую в обслуживании базу кода, которая ведёт к использованию "хаков" и наличию ошибок в коде игры, и в то же время затрудняет добавление новых особенностей. Создание движка и наблюдение результатов на экране, несомненно, приносит массу удовольствия, но разработка и обслуживание технологии движка - это совсем другой вид работы, нежели создание игр, и он не является удачным стратегическим ходом для каждой студии. В конце концов, собственный игровой движок может принести гораздо больше неудобств, чем пользы.