Бесплатная реклама

Автор: Андрей Коротков «DRON»

Опубликовано: 01.06.2011

Изменено: 01.06.2011

Постоянная ссылка

Комментарии [4]

Философия движка DGLE2


В статье автор рассказывает про движок DGLE2 и его идеологию - отвечает на вопросы зачем существует этот проект, какова его цель и каких принципов он придерживается.


Игровой движок DGLE2

Введение

Что же такое DGLE2? Я думаю есть необходимость сразу расставить все точки над "и".

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

Порой доходит до абсурда, вот вам реальный случай с одного форума; Человек выкладывает один файл написанный на Delphi, в файле содержится класс из 150 строк кода, по сути он только и умеет что выводить картинки двигающиеся сверху вниз по экрану, но именуется это все гордо - "движок дождя"! Ну и подобных примеров можно привести великое множество. Не мудрено, что подобная ситуация вокруг терминологии может легко запутать неискушенного разработчика, хотя на самом деле все достаточно просто и понятно, во многих случаях просто используется подмена понятий или некомпетентность разработчика и пользователя. Сейчас я постараюсь объяснить, как все обстоит на самом деле...

Существует всего четыре ключевых понятия это: Враппер, Фреймворк, Графический движок и Игровой движок.

Конечно этот список можно расширить, если добавить такие понятия, как "Звуковой движок", "Физический движок", "Конструктор игр" и т.д., но я не стану этого делать – я просто ниже дам определение слову "движок" и надеюсь, что после этого читатель сам четко сможет понимать разницу.

Теперь я просто поясню очень кратко каждое понятие, так что бы было ясно каждому ;-)

Враппер - способ работать с каким либо сложным API (обычно низкоуровневым) в более простой форме, за меньшее количество вызовов, но, как правило, с некоторой потерей гибкости. Примером враппера может служить библиотека GLUT.

Фреймворк - каркас или готовая основа(среда) для разработки чего либо. Представляет из себя, как правило, внушительный объем инструментов и библиотек объединенных в единое целое, в идеале должна быть очень гибкой и настраиваемой. Задача фреймворка удовлетворять максимальному количеству возможных задач. Пример большого фреймворка - хорошо известный .NET Framework.

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

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

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

Теперь, когда я пояснил основные понятия можно вернуться к вопросу "Что же такое DGLE2?".

DGLE2 это - Игровой Движок или Фреймворк таким, каким его вижу я. Вообще, движок не только игровой, расчет делается и на проекты требующие ресурсоемкую компьютерную графику реального времени, и не игровые проекты на движке есть, хоть их и на порядок меньше игровых.

Теперь думаю стоит пояснить каким я вижу идеальный движок для игр и мультимедийных приложений реального времени, но сперва немного предыстории.

Это видение мне пришло спустя несколько лет работы и экспериментов. Мне довелось попробовать множество как бесплатных, так и платных движков, связано это было с теми задачами, которые я решал на работе. Многие движки потрясали сперва, но быстро разочаровывали, когда стоило копнуть их нутро поглубже за красивой обложкой творился сущий ад. Некоторые были хороши всем, но не получалось добавить необходимые возможности или для этого нужно было разобраться во всем объеме кода, а он порой был просто недоступен или стоил немеренно денег. Справедливости ради стоит отметить, что задача под которую подбирался движок была весьма нетривиальна, по этому видимо часто и вскрывала огрехи разработчиков.

В итоге пришлось разрабатывать силами компании свой движок, который спустя несколько лет разработок превратился в монстрика способного потягаться с некоторыми крутыми коммерческими движками, и по сей день он используется и развивается этой компанией, как закрытый движок для внутреннего применения.

Шишек в процессе разработки было набито не мало :-) Это все с одной стороны, с другой стороны в качестве хобби я давно занимаюсь играми и перепробовал массу движков помельче и без пафоса. Когда я еще учился в университете я написал свой первый движок это был графический движок DGLEngine или DGLE1 – было это много лет назад, тогда я много чего еще не знал и не понимал, но после разработки нескольких игр на сторонних движках, мне просто ничего не оставалось, как написать свой, сейчас поясню почему.

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

Так появилась первая версия DGLE. В нем тогда не было ни редакторов, ни объектной модели, просто - минимальный необходимый набор функций, практически враппер над OpenGL. Даже не смотря на то, что я практически забросил движок сразу после первой версии он снискал себе популярность и даже последователей, которые повторяли и развивали заложенные мною архитектурные идеи.

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

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

Философия проекта

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

1. "Keep It Simple" - не нужно ничего усложнять, нужно делать настолько просто, на сколько это вообще возможно.
2. Несколько уровней абстракции - у разных разработчиков - разные навыки, должно быть четкое разделение между уровнями движка. Чем выше уровень - тем меньше гибкость, но тем проще использование. Каждый подбирает для себя (подробнее о этом будет рассказано ниже).
3. Простая объектная модель для пользователя - процедурная модель для подобных систем не годится(проверено на собственном опыте :), а экспортируемые классы - не позволяют использовать движок для разных языков и на разных платформах. К тому же, переусложненная ООП модель это с моей точки зрения - плохо. По этому я использую интерфейсы.
4. Расширяемость - в моем случае это поддержка гибкой системы плагинов, которая позволяет добавлять новые возможности в движок, тем более, плагины удобно распространять через интернет.
5. Уверенность в качестве - важно что бы система была стабильной, QA тесты и обработка всех возможных ошибок - необходимы.

Теперь расскажу о том, как основные из этих принципов работают на деле. И к чему я стремлюсь, т.е. опишу то самое свое идеальное виденье. В движке имеются следующие уровни абстракции, от самого верхнего к самому нижнему.

Редакторы
Набор редакторов Уровней, Интерфейсов, Частиц, Префабсов, Материалов, Спрайтов и т.д. Все эти редакторы работают с форматами файлов которые поддерживает движок и каждый их редакторов не зависим друг от друга. Все эти редакторы объединяются в единой программе - Конструкторе. Конструктор позволяет пользоваться редакторами, как единым целым, а игра в этом случае делается только лишь при помощи мышки и блоков визуального программирования. На этом же уровне пользователь может подключать плагины и расширять как возможности движка, так и конструктора. Для использования редакторов и конструктора не нужны какие то специальные навыки.

Скрипты
На самом деле визуальное программирование в Конструкторе генерирует скрипты, которые просто затем выполняются движком. Пользователь может редактировать сгенерированные или писать свои скрипты с чистого листа, что значительно увеличивает гибкость. В качестве скриптового языка используется хорошо зарекомендовавший себя во многих играх и приложениях Lua.

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

Разработка плагинов
Если есть необходимость реализовать что-то специфичное или просто добавить недостающую функциональность и сделать это частью движка, то самое простое это - написать плагин. Удобство заключается в том, что плагин может скрывать в себе достаточно сложные вещи, но в конечному пользователю достаточно просто подключить его к движку и использовать новые возможности не задумываясь о том, как они работают внутри.

Исходные коды движка
Движок имеет открытый исходный код, а значит любой компетентный разработчик может адаптировать его под себя и реализовать то, что невозможно на любом из более высоких уровней абстракции. Хотя я себе слабо представляю в каких случаях может возникнуть такая необходимость :-)

Теперь расскажу об архитектуре движка.

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

Интерфейсы также позволяют сделать движок кроссплатформенным, а сами интерфейсы могут использоваться в любом современном языке программирования.

Объектная модель на основе интерфейсов позволяет легко расширять функциональные возможности движка. Приведу пример. Предположим, нужно добавить поддержку видеофайлов (avi) в движок. Для этого разрабатывается плагин который регистрирует в менеджере ресурсов движка расширение "*.avi" и сообщает движку, что на выходе это будет текстура. Теперь, когда пользователь загрузит через менеджер ресурсов видеофайл он получит обычный интерфейс текстуры, который он сможет использовать как обычную текстуру загруженную из, например, BMP файла. Но вместо картинки в этой текстуре будет проигрываться загруженный видеофайл, в данном случае всю работу на себе берет плагин, а для пользователя все очень просто. Но что делать если методов в интерфейсе текстуры не достаточно, например хочется управлять воспроизводимым видео? Для этого достаточно просто сделать свой интерфейс текстуры, но понаследовать его от интерфейса текстуры движка. Тогда новый интерфейс с одной стороны будет полностью совместим с интерфейсом движка, но с другой стороны добавит новый функционал в текстуру полученную после загрузки видеофайла.

Архитектура построена таким образом, что если использовать только лишь API движка, то при портировании на другую платформу достаточно будет просто перекомпилировать приложение и все сразу должно заработать.

P.S.

Я начал разработку движка не с целью делать очередной "велосипед", а именно по тому, что считаю, что подобных проектов на данный момент нет. Есть большие навороченные коммерческие движки, которые обладают всем что хочется и имеют отличную архитектуру, но нет чего-то такого легковесного, простого для понимания и освоения, бесплатного и в тоже время удовлетворяющего тем же высоким идеалам что и дорогие движки. Именно эту нишу и стремится заполнить этот проект :-)

 


 

Другие статьи про игровой движок DGLE2 читайте здесь:
http://dron.deeprosoft.com/dgle2_articles