Сердце любого графического движка — его сцена, набор объектов, взаимодействующих с пользователем. Обычно, сложнее подобрать реалистичные параметры сцены, а не реализовать требуемые возможности. Движок может быть мощным по скорости прорисовки, с качественным выходным изображением, но плохая команда трехмерных художников, команда сопровождения и недостаточная проработка параметров реалистичности может свести на нет все усилия программистов. При этом рисование сцены должно быть масштабируемым, то есть добавить треугольников в модель персонажа достаточно просто, но переделать модель рисования неба, эффектов и теней может быть затруднительно. Пример — вода в M&M IX, по-моему, если говорить об убогости реализации LithTech + M&M IX это сладкая парочка, там, где движок не глючит — там недоработки художников и дизайнеров, а там где у них это все более-менее прилично, вылезает ущербность реализации LithTech. Я думаю назвать конкретные места нет никакой необходимости, все прекрасно их видели.
4. Использовать файл настроек для инициализации.Здесь все просто, все изменяемые параметры должны применяться при следующей загрузке, и тогда без применения инициализационного файла не обойтись. Инициализационный файл не погибает при переустановке системы, его можно легко перенести с машины на машину. Сложностей в его реализации нет, там все просто. Либо ждите, когда будет выложена моя статья с реализацией, либо реализуйте сами, либо обращайтесь прямо ко мне, я вышлю.
5. Проводить проверку состояния устройства и выдавать ошибку при их несоблюдении.В текстовом инициализационном файле (редактируемом как программой, так и вручную) могут быть ошибки, поэтому мы должны контролировать состояние файла при загрузке и хранить твердую копию (жестко закрепленные параметры, хранящиеся в программе). Реализуется в любом движке и просто требует аккуратности.
6. Современный графический движок не должен в реальном времени изменять параметры устройства или режим работы (оконный/полноэкранный).Нет необходимости в изменении устройства из приложения, мы можем упростить эту часть, и направить усилия на другие более важные части. Пользователи привыкли, и могут безропотно выйти из программы, чтобы сменить режим с оконного на полноэкранный или изменить глубины цвета (все равно почти вся информация загружается заново). Это упрощение и скорее упрощает жизнь программистам. Вообще говоря, команда разработчиков единое целое, но у каждой части свои задачи (все помнят модель разработки Microsoft Solution Framework), поэтому ни одна из частей не должна идти на поводу у другой, но в тоже время должны вырабатываться разумные компромиссы (если дизайнером нужно рисовать по 200 KPolys за фрейм при 60 Hz на GeForce 2, то программисты должны обеспечить такую производительность, но если программистам нужно рисовать по 200+ за раз, то модели должны быть сделаны с этим расчетом).
7. Уметь загружать файлы из сжатого файла, причем делать это асинхронно.В основном, это культура программирования, нет необходимости пользователям видеть структуру организации приложения (кроме того, при шифровании усложняется жизнь производителей контрафактной продукции и часто это требование издателя). Асинхронность необходима для одновременной работы с несколькими файлами (фоновое проигрывание музыки и загрузка сцены).
8. Вести файл протокола.Протоколирование сильно упрощает отладку приложения и систематизирует работу программистов. Очень легкая задача. В одной из общих статей обязательно будет реализация, если нет мочи ждать, то пишите мне, ищите в Сети или пишите сами.
9. Уметь в реальном времени изменять параметры, не требующие изменения устройства.Скорее приведен как пример правильного поведения устройства. Движок должен предоставлять широкий набор параметров для изменения, касающихся как внешнего вида, так и производительности. Игровые проекты двигают рынок аппаратуры, а не наоборот. Мы должны предоставить человеку веский довод для улучшения аппаратуры, и слабая аппаратура это не повод лишать себя и "смежников" дополнительного заработка. Игрок, он как девушка — нет игроков, которые не играют, есть игроки, которые не играют в твою игру (это твоя вина).
10. Контролировать ошибки и правильно их обходить.Повисание и вылетание (а тем более, вылетание без предупреждения) приложения — это безалаберность программистов, и их лень во всех необходимых местах реализовать проверку на соответствие параметров (часто они не знают где необходимо проверять, но чаще просто не хотят). Главное, писать обработку ошибок вместе с приложением. Например, если используется спиральная модель разработки, то к следующей итерации можно переходить только тогда, когда не только реализованные все возможности внутреннего релиза, но и проведено тестирование на стабильность приложения.
11. Корректно чистить после себя при загрузке дополнительной информации.