Пишем редактор уровней. Вступление
Разработка практически любой игры начинается с разработки редактора уровней, если конечно он для игры необходим. Редакторы уровней я разделяю на два типа: встроенный непосредственно в игру и внешний являющийся самостоятельным приложением.
Встроенный редактор уровней — очень удобен тем, что если правильно спроектировать классы редактора и классы игры, то при внесении изменений в саму игру или в редактор уровней, работы будет существенно меньше. А все потому что редактор уровней и игра могут (и должны) использовать общие классы игровых объектов. У встроенного редактора уровней в игре есть прямой доступ к игровому движку, что позволяет легко и быстро сделать возможность запуска только что сделанного уровня и провести его тестирование на прохождение. Но у такого редактора есть некоторые недостатки. Дело в том, что в редакторе уровней могут быть дополнительные служебные функции, которые порой занимают не одну тысячу строк исходного кода, а для игры они совсем не нужны. Большое количество лишних функций и методов предназначенных только для редактора, могут сильно сказаться на читаемости и запутанности исходного кода, что в свою очередь очень критично для крупных проектов.
Внешний редактор уровней — удобен тем, что это отдельное приложение, которым возможно кроме разработчиков никто не будет пользоваться. Его не обязательно отлаживать чтобы он работал идеально и не нужно думать об оптимизации. Его задача выполнять свою работу, а как он это будет делать — уже никому не важно кроме разработчика. На качество игры в целом внешний редактор не повлияет. Основное неудобство внешнего редактора в том, что при добавлении новых игровых объектов в игру необходимо редактировать два приложения: вносить изменения в редактор, а после вносить изменения уже непосредственно в игру — порой на это требуется больше времени, чем на подобные изменения во встроенном в игру редакторе.
Так выглядит внешний редактор уровней для игры "Грибоед" (Carl The Caveman). Для казуальной игры — казуальный редактор, установка и удаление объектов в один клик, что позволяет не отвлекаться на настройку параметров для объектов и полностью погрузится в создание уровней.
Какой редактор сделать в своей игре?
Чтобы определится с тем какой тип редактора сделать в своей игре, достаточно решить, будет ли редактор уровней доступен игрокам для создания своих уровней. Если есть желание сделать редактор уровней общедоступным, чтобы пользователи могли создавать свои уровни, то редактор конечно же стоит сделать встроенным, чтобы пользователям было удобнее с ним работать. Так же следует предусмотреть возможность быстрого тестирования уровней, поскольку игроки которым понравится ваша игра, могут играться в редакторе уровней как в "песочнице" не имея желания публиковать свое баловство.
Если редактор уровней не планируется делать публичным, то это совсем не значит, что его нужно делать отдельным приложением, ведь его достоинство еще и в том, что именно встроенный редактор может сэкономить силы и время не только при разработке, но и при создании и отладке уровней. Если планируется простая игра вроде платформера или бродилки-стрелялки с простыми игровыми уровнями и небольшим количеством разных объектов, то редактор будет также легко и удобно сделать встроенным.
Но если в планах большой проект с серьезным редактором уровней, в котором предполагается множество различных функций, к примеру, редактирование ландшафта, расстановка спец-эффектов, создание квестов, настройка тиггеров и т.п., то внеший редактор — это лучшее решение. Ведь в таком случае редактор получится серьезным инструментом для создания уровней, который может иметь разнообразие функций упрощающих создание уровней, свой интерфейс для доступа к этим функциям и т.п. Если совмещать сложный редактор уровней с игрой в одном флаконе, то одно другому может сильно мешать не только читаемостью и запутанностью кода, но и порождением различных неприятных багов.
Ранее в своих проектах я в основном использовал только внешние редакторы уровней, даже для простых игр. ?гры были 3D и для редактора в формате уровней хранилось намного больше информации, чем это требовалось для игры. Уровни в игру попадали через функцию экспорта при этом из уровней удалялась вся лишняя информация, которая была необходима для редактирования. В 2D играх практически нет необходимости в хранении дополнительной информации, чтобы производить последующие изменения уровней. Поэтому я все же склоняюсь к тому, что встроенные редакторы уровней — это удобнее, чем внешние, при условии, что игра не требует создания сложных уровней.
Но вернемся к Flash. В среде Flash пока чаще разрабатываются маленькие игры и Flash сильно облегчает разработку таких игр, тем что имеет отличную визуальную среду в которой можно конструировать уровни визуально. Можно перетаскивать нужные объекты на сцену, вращать, масштабировать и устанавливать их как хочется, а каждый новый уровень легко размещать в своем ключевом кадре на временной шкале. Далее достаточно прописать объектам уникальные имена чтобы из кода игры можно было их обрабатывать. Но на деле не все так здорово как на словах. Я сам не разу таким образом уровней не создавал, но видел игры которые сделаны по такому принципу. ? считаю что такой вариант больше подходит для квестовых игр где каждая комната, локация и игровые объекты уникальны и чтобы расставить игровые объекты в локации, совсем не нужно писать редактор. Но чтобы делать красивые, интересные и играбельные уровни в среде Flash, например, в жанре платформер, то прийдется серьезно поработать используя визуальную среду Flash создавая уровни.
? так, я предлагаю рассмотреть пример простого редактора уровней встроенного в игру, на основе игры "Грибник" в жанре платформер, над которой я в данное время работаю.
Далее по теме: Пример редактора уровней →
@Платон, вопрос сохранения уровней — очень интересная тема. Когда я начал писать первый редактор уровней на Flash, я плотно столкнулся с этим вопросом и постарался найти все возможные способы сохранения уровней в редакторе через Flash. Но об этом я хочу написать чуть позже :)
Единственно верный способ хранить пользовательские уровни — это безусловно только на сервере. Только вот я считаю что записывать xml на свой сервер не очень безопасное занятие. Я бы наверное предпочел передавать данные php скрипту который бы сохранял уровни непосредственно в базу данных с проверкой на корректность передаваемых данных, чтобы избежать SQL-иньекций. В целом можно пярмо xml и писать в БД. ? так же точно через скрипт извлекать уровни из БД ;)
Вариант хранения уровней прямо в классах .as — это как мне кажется самый оптимальный вариант чтобы сделать Flash игру всю в одном файле и не переживать далее о том что в один прекрасный момент с сервером что-нибудь случится и игра сломается. Только вот возможность создания пользовательских уровней исключается. Но можно хранить пользовательские уровни на сервере, а авторские непосредственно в классах игры. Есть еще способ как вшить уровни в swf, но я о нем знаю только в теории :))
А вот про редактор на Delphi интересно. В приложение на Delphi вы вставляли флешку чтобы производить запись уровней в файлы, или редактор уровней полностью писался на Delphi?
Не понятны два момента из статьи, не могли бы поподробнее о них рассказать?
1. "В 2D играх практически нет необходимости в хранении дополнительной информации"
Что имеется в виду под дополнительной информацией? Чего такого хитрого есть в 3д-уровнях, чего нет в 2д-уровнях?
2. "Но чтобы делать красивые, интересные и играбильные уровни в среде Flash, например, в жанре платформер, то прийдется серьезно поработать используя визуальную среду Flash создавая уровни."
Тоже не вполне понятна мысль. Чем создание платформерного уровня сложнее создания уровня для квеста? По мне так использование Flash IDE, как редактора уровней плохо только одним - нет возможности предоставить этот редактор игрокам. В остальном одни плюсы. Начиная от удобства расстановки объектов и заканчивая возможностью экспортировать готовые уровни в XML или любой другой формат использую JSFL.
В целом очень интересный блог, с уовольствием читаю, спасибо.
P.S. Сделай иконку сайту, чтобы он белым листочкам в табах браузера не выглядел. (:
@elmortem,
1. Под данным текстом я конечно подразумевал не флешевую 3D графику :) А хитрое там то, что уровни так же стоят из разных объектов и совмещая эти объекты у них были такие стороны которые игрок никогда не увидит, но при этом на их просчеты и рендер затрачиваются ресурсы. При экспорте уровней все не попадающие в область видимости полигоны удалялись. Экспортированные уровни не подлежали редактированию потому что, удаляя или переставляя объекты местами, получались настоящие дырки, как будто другие объекты поели червяки :) В общем в формате уровней для редактора хранилась вся информация о форме объектов, а для игры все лишнее удалялось.
2. В первую очередь сложность создания уровня в Flash IDE зависит от самой игры. На примере платформера, вот у нас есть набор тайлов для создания ландшафта уровня, если создавать уровень во Flash IDE, даже если все эти тайлы будут разложены аккуратно по папочкам в библиотеки клипов, то при сборке уровня нам прийдется все равно искать подходящие тайлы и перетягивать их в рабочую область. Поиск тайлов, перетягивание, с последующим выравниваем (по хорошему координаты объектов не должны содержать дробной части — что скорее всего прийдется править в ручную) у нас будет занимать очень много времени. К тому же у нас может быть несколько тайлов разных вариаций для большего разнообразия. ? так, чтобы сделать уровень во Flash IDE нам нужно как минимум найти нужный клип в библиотеке, перетянуть его в рабочую область, установить в нужное место, убрать дробные у координат и размеров, возможно сменить разновидность.
Например, у меня в игре используется шахматный порядок установки тайлов, таким образом мне еще прийдется следить за тем, в какой последовательности я ставлю тайлы :) А если делать редактор уровней, то такие мелочи как раз и реализуются небольшими методами (функциями) которые оптимизируют работу дизайнера уровней, беря эти простые и нудные задачи на себя. Вот я ставлю тайл скалы, если за скалой есть задник, то значит скала должна отбрасывать на него тень, в редакторе есть небольшая функция которая проверяет наличие задников и устанавливает тени автоматом, к тому же тени могут состоять из разных составных частей в зависимости от того, стоит ли рядом еще скала — это позволяет создать мягкие переходы между тенями. Если все это делать в ручуню, то на один уровень будет уходит пол дня, а то и весь день. А если немного покряхтеть над редактором, то можно сделать создание всех этих вкусностей в один клик. То есть устанавливая новый тайл, окружающие тайлы могут узнавать о появлении нового объекта и автоматически подстраиваться под его появление меняя свою разновидность и тем самым создавая цельную картинку. В общем я боюсь что оним комментарием всю пользу собственного редактора перед Flash IDE мне не передать :) Тема очень широкая и я надеюсь далее мне удастся раскрыть некоторые тонкости.
Ну и самое вкусное что можно сделать в редакторе уровней и что нельзя сделать во Flash IDE — это оптимизация! В чем фишка оптимизации: в редакторе уровней мы расставляем теже самые объекты из библиотеки, сохраняем в наш формат уровней, а при загрузке уровня в игре не динамические объекты мы можем собрать в одну группу, сделать с них копию в Bitmap, словно фотографию фотоаппаратом, после чего все объекты тут же удалить, а в место них подставить их копию в виде сделанного снимка :) То есть в место ~400 векторных объектов мы получим одну большую картинку выполняющую роль задника и при этом размер самого swf не изменится и скорость рендера возрастает.
До иконки пока руки не дошли, сделаю. Спасибо :)
1. Без ПХП однозначно не обойтись, а вот что с этими данными дальше делать - уже дело программиста ;) В моем случае удобнее было формировать xml через ПХП, и считывать ее из флешки, а БД не пользоваться.
2. дельфи и флэш. Я делал 98% редактора на флеше. Дельфи только получает исходный код для сохранения в файл. В сети достаточно информации по их стыковке. Например, тут: http://www.citforum.ru/internet/flash/flash_delphi/ Если вкратце, в дельфе размещается swf как activeX компонент, и через fsCommand изет передача данных. На деле, правда, все несколько сложнее :)
Кроме того, есть специальные библиотеки для работы с свф в дельфе - насколько помню, Delphi SWF SDK.
Понятно.
По последнему абзацу могу только добавить, что если всё-таки использовать Flash IDE вместо редактора (иногда просто нет времени на написание редактора, а несколько уровней надо сделать уже вчера), то сделав экспорт в XML (используя JSFL) можно так же затем реализовать все фишки ручного кеширования статической графики.
Но вообще я согласен, что по хорошему нужно писать специализированный редактор и желательно встроенный. Благо это проще, чем написать саму игру. ^__^
@Платон, все понятно, в целом так и подумал. Только при связке swf с Delphi еще тот получается "велосипед" наверное :) Но опыт интересный. Спасибо.
Я сам ничего против разработки уровней во Flash IDE не имею. Это действительно удобно и экономно для простых игр, или когда уровни проще создавать в среде Flash, чем писать для этого редактор специально. В общем это надо решать исходя из того какая будет игра и какие там будут уровни.
По поводу экспорта в xml — действительно таким образом можно будет реализовать оптимизацию графики, об этом я не подумал :)
А ещё можно, чтобы флэш выводил значения массива уровня на экран, а оттуда копировать в .as файл =)
На флеше я знаю только один нормальный вариант формирования встроенных уровней пользователями - загрузка и выгрузка через xml. при этом, т.к. ограничения безопасности флеша запрещают напрямую создавать файлы на диске, приходится иметь на подхвате сервер, на котором эти пользовательские xmlки будут размещаться. Вполне неплохой вариант - если есть сервер и руки прямые :)
Для формирования уровней и монстров в одной незаконченной игрушке я сделал внешний редактор, который встроил в дельфи - и вносил правки непосредственно в as файлы с уровнями (сохранял данные в виде массивов) для последующей компиляции. Тоже неплохой вариант.
27 Августа 2009
— 11:37
#