Редакторы для казуальных и независимых игр. Адаптация открытого непрофильного софта под нужды разработчика игр
Введение
Часто инди-разработчики или разработчики казуальных игр сталкиваются с проблемой нехватки специализированных редакторов, инструментов, утилит и т.д. ( так называемого middleware ) для создания контента для своих игр. Пример такого контента - это уровни, сложные анимации, 2d монстры и техника, а также параметры настройки и конфигурации всего этого. Прописывать всё это вручную в текстовых, редакторах (или скажем xml-редакторах) это не всегда удобно. В самом деле не будешь же ручками прописывать координаты полигонов в двухмерном уровне. Или задавать цвет глаз в шестнадцатеричном коде в xml-файле описания эльфа.
Обычно бывает сложно найти удовлетворяющий всем нуждам редактор или тулзу. Самые частые проблемы это:
Часто принимается решение писать свой собственный редактор и набор утилит, но такое решение не всегда рационально. Для небольших игрушек писать самостоятельный редактор слишком накладно. Потому как это может занять больше времени чем написание собственно игры. Полноценный редактор 2d уровней можно писать пол года - это реальные сроки, каким бы хорошим программистом вы не были ( ну ок, если простой редактор, то 2 месяца и получится редактор, которым сможете пользоваться только вы, т.к. нажатие только определенной последовательности кнопок будет приводить при заданных условиях к преполагаемому результату, а не к вылету :) ).
Но существует одно ( но не единственное :) ) интересное решение этой проблемы - это адаптация существующего открытого непрофильного софта под нужды разработчика игр.Это решение позволит вам получить мощный инструмент для вашей игры с наименьшими затратами на разработку. Об этом пойдёт речь в данной статье.
Создание бесплатной игры с помощью бесплатного ПО, не ориентированного на данные цели
Рассмотрим данный подход на примере реального применения по ходу разбавляя его вариантами развития событий возможных в вашем проекте. Есть игра x-moto ( это опенсорсная версия игры elastomania ) про мотоцикл продвигающийся от уровня к уровню через двухмерное пространство по физическим законам. Изначально разработчики данной игры пошли по пути написания собственного редактора. И что мы имеем? Крайне неудобный редактор изобилующий багами, часто приводящими к потере изменений в уровне. Если открыть его исходный код и поизучать его, можно представить сколько горя принесло его написание бедным программистам :) . Я адаптировал это редактор для своей инди игры hellycopter ( http://yarilostudio.ru/games/hellycopter ) и прочувствовал на своей шкуре его неудобство.
Но вдруг (внезапно) некто со светлой головой из сообщества разработчиков x-moto применил подход, рассматриваемый далее в этой статье. И, о чудо! Стали появляться чудесные уровни, в игру вдохнулась новая жизнь и она задышала полной грудью :).Появилась возможность создавать уровни с физическими объектами ( динамичные блоки, завалы и т.д. ) и другие возможности редактирования, которых раньше не было.
Как это делается?
Берем редактор inkscape. Как гласит информация с его официального сайта:
"Inkscape — открытый редактор векторной графики, функционально схожий с Illustrator, Freehand, CorelDraw или Xara X и использующий стандарт W3C под названием Scalable Vector Graphics (SVG). В программе поддерживаются такие возможности SVG как фигуры, контуры, текст, маркеры, клоны, альфа-канал, трансформации, градиенты, текстуры и группировка."
Действительно приличный набор возможностей! А что если применить эти возможности для редактирования уровня игры? Это правильный ход мыслей. Во первых сам по себе редактор поставляется с открытым исходным, кодом, но главное у него есть python обвязка. Т.е. вся объектная модель редактора доступна из скриптов на python. Таким образом мы можем расширять возможности редактора не меняя его код. С использованием python мы вносим в редактор функционал специфичный для конкретной игры. Это могут быть такие возможности как:
После этого мы рисуем уровень в inkscape, предварительно решив, например, что границы документа это будут границы нашего уровня, красные кружочки - это враги, синие друзья, а, скажем, жёлтый это главный герой. Мы можем даже создать отдельный документ - импровезированную "панель инструментов игры", где будут нарисованы эти кружочки, определенного, размера, стиля, возможно даже с глазками и ручками и т.д. И во время создания уровня переносить их из этой панели копированием в наш уровень. После того как мы нарисовали уровень, мы можем сохранить его в исходном виде (для дальнейшего редактирования) в svg или же применить наш скрипт и сохранить его (save as...) как уровень нашей игры. При этом скрипт уже знает что такое синий, жёлтый и т.д. кружочки и умеет корректно сохранять уровень, выводя предупреждения в случае логической противоречивости уровня.
Также с помощью скрипта мы можем ввести в inkscape дополнительные команды, которые могут преобразовывать стандартные объекты (фигуры на листе) в наши игровые объекты.
Например нам нужно сделать зону - круг, при вхождении в которую главным героем, показывается сообщение на экране.
Это обеспечивается добавлением меток и различных свойств в xml-представление объекта в текущем документе. Например, мы рисуем кружочек, выделяем его и вызываем из меню inkscape команду преобразовать в "зону показа сообщения". Предварительно, разумеется, мы пишем скрипт для того чтобы эта команда появилась в меню inkscape. Далее у нас вызывается окно, где мы вводим текст этого сообщения, кружочек делается прозрачным, в его xml представление вносится тэг или атрибут наподобие:
< MessageZone text="hello world"/>
В самом простом случае мы можем даже не расширять inkscape а просто экспортировать svg-файл с уровнем в наш игровой уровень.Для этого нам всего лишь нужно придерживаться разработанных нами же соглашений на создание объектов во время редактирования уровня. Формат svg открыт и хорошо документирован и по сути является xml-файлом. Мы можем написать на любом языке программирования экспортер в наш формат уровня. На вход такому экспортёру передаётся svg-файл уровня, а на выходе получаем уровень в нашем формате. А в процессе экспорта такая программа может выводить предупреждения и сообщения об ошибках, которые обеспечивают соблюдение соглашений по созданию уровня (например обязательное наличие точки начала уровня и других специальных объектов, проверка на логическую непротиворечивость уровня, его проходимость и др.).
Возможности и инструменты
Также на sourceforge можно найти различные редакторы подходящие под проблемную область вашей игры, нужно только подумать как их расширить в контексте конкретной игры.
Кандидаты редакторов, которые можно также использовать для редактирования игры:
Выводы
Эффективность такого метода я оцениваю очень высоко - это быстрее чем писать редактор с нуля. Часто хватает базовых возможностей редактора - достаточно лишь ввести свои соглашения по представлению игровых объектов средствами редактора. Также это достаточно ошибкоустойчивый метод - вы во многом полагаетесь на редактор и его средства оповещения об ошибках.
Из недостатков - не всегда можно представить средствами редактора игровые объекты с требуемой степенью детализации. Т.е. если крайне важно чтобы при редактировании всё выглядело также как и в игре, такой подход может не подойти. Но эта проблема решается например написанием внешнего визуализатора на движке игры, вызов которого можно встроить в редактор.
PS.
Я намеренно не поместил в статью питоновские исходники, т.к. тогда бы статья превратилась в туториал и разраслась по размеру. Поэтому можно рассматривать данный опус как экскурс в вопрос и обзор метода.
Часто инди-разработчики или разработчики казуальных игр сталкиваются с проблемой нехватки специализированных редакторов, инструментов, утилит и т.д. ( так называемого middleware ) для создания контента для своих игр. Пример такого контента - это уровни, сложные анимации, 2d монстры и техника, а также параметры настройки и конфигурации всего этого. Прописывать всё это вручную в текстовых, редакторах (или скажем xml-редакторах) это не всегда удобно. В самом деле не будешь же ручками прописывать координаты полигонов в двухмерном уровне. Или задавать цвет глаз в шестнадцатеричном коде в xml-файле описания эльфа.
Обычно бывает сложно найти удовлетворяющий всем нуждам редактор или тулзу. Самые частые проблемы это:
- закрытый код
- недостаточные возможности для конкретно вашей игры (ограничения по редактированию)
- навязываемый api и библиотеки от создателей middleware
Часто принимается решение писать свой собственный редактор и набор утилит, но такое решение не всегда рационально. Для небольших игрушек писать самостоятельный редактор слишком накладно. Потому как это может занять больше времени чем написание собственно игры. Полноценный редактор 2d уровней можно писать пол года - это реальные сроки, каким бы хорошим программистом вы не были ( ну ок, если простой редактор, то 2 месяца и получится редактор, которым сможете пользоваться только вы, т.к. нажатие только определенной последовательности кнопок будет приводить при заданных условиях к преполагаемому результату, а не к вылету :) ).
Но существует одно ( но не единственное :) ) интересное решение этой проблемы - это адаптация существующего открытого непрофильного софта под нужды разработчика игр.Это решение позволит вам получить мощный инструмент для вашей игры с наименьшими затратами на разработку. Об этом пойдёт речь в данной статье.
Создание бесплатной игры с помощью бесплатного ПО, не ориентированного на данные цели
Рассмотрим данный подход на примере реального применения по ходу разбавляя его вариантами развития событий возможных в вашем проекте. Есть игра x-moto ( это опенсорсная версия игры elastomania ) про мотоцикл продвигающийся от уровня к уровню через двухмерное пространство по физическим законам. Изначально разработчики данной игры пошли по пути написания собственного редактора. И что мы имеем? Крайне неудобный редактор изобилующий багами, часто приводящими к потере изменений в уровне. Если открыть его исходный код и поизучать его, можно представить сколько горя принесло его написание бедным программистам :) . Я адаптировал это редактор для своей инди игры hellycopter ( http://yarilostudio.ru/games/hellycopter ) и прочувствовал на своей шкуре его неудобство.
Но вдруг (внезапно) некто со светлой головой из сообщества разработчиков x-moto применил подход, рассматриваемый далее в этой статье. И, о чудо! Стали появляться чудесные уровни, в игру вдохнулась новая жизнь и она задышала полной грудью :).Появилась возможность создавать уровни с физическими объектами ( динамичные блоки, завалы и т.д. ) и другие возможности редактирования, которых раньше не было.
Как это делается?
Берем редактор inkscape. Как гласит информация с его официального сайта:
"Inkscape — открытый редактор векторной графики, функционально схожий с Illustrator, Freehand, CorelDraw или Xara X и использующий стандарт W3C под названием Scalable Vector Graphics (SVG). В программе поддерживаются такие возможности SVG как фигуры, контуры, текст, маркеры, клоны, альфа-канал, трансформации, градиенты, текстуры и группировка."
Действительно приличный набор возможностей! А что если применить эти возможности для редактирования уровня игры? Это правильный ход мыслей. Во первых сам по себе редактор поставляется с открытым исходным, кодом, но главное у него есть python обвязка. Т.е. вся объектная модель редактора доступна из скриптов на python. Таким образом мы можем расширять возможности редактора не меняя его код. С использованием python мы вносим в редактор функционал специфичный для конкретной игры. Это могут быть такие возможности как:
- Экспорт из svg в уровень игры;
- Конверт из уровня игры в svg ( не обязательно, т.к. редактируемые уровни лучше хранить в svg и только перед непосредственной вставкой в игру конвертировать их в игровой формат);
- дополнительные кнопки и окна для создания и редактирования игровых объектов в inkscape.
После этого мы рисуем уровень в inkscape, предварительно решив, например, что границы документа это будут границы нашего уровня, красные кружочки - это враги, синие друзья, а, скажем, жёлтый это главный герой. Мы можем даже создать отдельный документ - импровезированную "панель инструментов игры", где будут нарисованы эти кружочки, определенного, размера, стиля, возможно даже с глазками и ручками и т.д. И во время создания уровня переносить их из этой панели копированием в наш уровень. После того как мы нарисовали уровень, мы можем сохранить его в исходном виде (для дальнейшего редактирования) в svg или же применить наш скрипт и сохранить его (save as...) как уровень нашей игры. При этом скрипт уже знает что такое синий, жёлтый и т.д. кружочки и умеет корректно сохранять уровень, выводя предупреждения в случае логической противоречивости уровня.
Также с помощью скрипта мы можем ввести в inkscape дополнительные команды, которые могут преобразовывать стандартные объекты (фигуры на листе) в наши игровые объекты.
Например нам нужно сделать зону - круг, при вхождении в которую главным героем, показывается сообщение на экране.
Это обеспечивается добавлением меток и различных свойств в xml-представление объекта в текущем документе. Например, мы рисуем кружочек, выделяем его и вызываем из меню inkscape команду преобразовать в "зону показа сообщения". Предварительно, разумеется, мы пишем скрипт для того чтобы эта команда появилась в меню inkscape. Далее у нас вызывается окно, где мы вводим текст этого сообщения, кружочек делается прозрачным, в его xml представление вносится тэг или атрибут наподобие:
< MessageZone text="hello world"/>
В самом простом случае мы можем даже не расширять inkscape а просто экспортировать svg-файл с уровнем в наш игровой уровень.Для этого нам всего лишь нужно придерживаться разработанных нами же соглашений на создание объектов во время редактирования уровня. Формат svg открыт и хорошо документирован и по сути является xml-файлом. Мы можем написать на любом языке программирования экспортер в наш формат уровня. На вход такому экспортёру передаётся svg-файл уровня, а на выходе получаем уровень в нашем формате. А в процессе экспорта такая программа может выводить предупреждения и сообщения об ошибках, которые обеспечивают соблюдение соглашений по созданию уровня (например обязательное наличие точки начала уровня и других специальных объектов, проверка на логическую непротиворечивость уровня, его проходимость и др.).
Возможности и инструменты
Также на sourceforge можно найти различные редакторы подходящие под проблемную область вашей игры, нужно только подумать как их расширить в контексте конкретной игры.
Кандидаты редакторов, которые можно также использовать для редактирования игры:
- Photoshop - создание путей, карт, юнитов и т.д. Расширяется за счёт javascript (встроенный) и python
- Excel - редактирование диалогов, свойств передметов, локализуемого текста и др. Расширяется за счёт visual basic for application ( встроенный) и python
- Inkscape - редактирование уровней, юнитов ( смотреть пример выше )
- Blender, CAD системы, редакторы векторной графики и др.
- Штатное расширение. Обеспечивается за счёт предоставленных редактором средств и API. Например, написанием плагинов, скриптов для встроенного интерпретаторов и т.д.
- Экспортер из файлов редактора. Вы пишите внешний экспортёр, который трактует файлы созданные редактором как уровни вашей игры и пересохраняет их в формате уровня. Для этого нужно знать формат файла.
- Экспортер с использованием COM-интерфейсов редактора. Этот способ похож на первый, за следующим исключением. Редактор может не предоставлять API для своего расширения, но часто существуют обёртки для python, которые работают через COM-интерфейсы редактора. Таким образом можно программно запускать редактор python'ом, открывать в нём нужный файл и производить действия по экспорту оперируя объектами реадактора (как будто это делает пользователь вручную). Иногда это бывает удобнее чем парсить уже сохранённый файл (особенно если он бинарный или его формат закрыт :) ).
Выводы
Эффективность такого метода я оцениваю очень высоко - это быстрее чем писать редактор с нуля. Часто хватает базовых возможностей редактора - достаточно лишь ввести свои соглашения по представлению игровых объектов средствами редактора. Также это достаточно ошибкоустойчивый метод - вы во многом полагаетесь на редактор и его средства оповещения об ошибках.
Из недостатков - не всегда можно представить средствами редактора игровые объекты с требуемой степенью детализации. Т.е. если крайне важно чтобы при редактировании всё выглядело также как и в игре, такой подход может не подойти. Но эта проблема решается например написанием внешнего визуализатора на движке игры, вызов которого можно встроить в редактор.
PS.
Я намеренно не поместил в статью питоновские исходники, т.к. тогда бы статья превратилась в туториал и разраслась по размеру. Поэтому можно рассматривать данный опус как экскурс в вопрос и обзор метода.
Комментарии