Страницы

пятница, 11 сентября 2009 г.

Прикладные программы

При созданий игры, вам может не хватить встроенных инструментов (к примеру, встроенного редактора уровней) и тогда на помощь приходят - прикладные программы.

Когда только-только развивалась 3д графика, приходилось вручную расставлять вершины, их координаты, их свойства (надо было самому писать текстовый файл). Всё бы хорошо, но кол-во вершин увеличивалось, а кол-во рук нет. И тогда придумали 3д редактор, который был направлен на ускорение работы человека, на исполнение рутинных задач, на автоматизацию. Со временем, там появились такие инструменты, которые позволяют вам сделать многомиллионную модель(красивую) менее чем за сутки. Как вы думаете, сколько бы вам потребовалось времени, чтобы сделать такую модель вручную(т.е. в текстовом редакторе)? Если вы пишете быстро, знаете положение всех вершин, то потребуется около 2 месяцев чистого времени. По самым скромным расчётам, разница в 60 раз! Поэтому если у вас объектов с которыми надо работать более нескольких десятков и времени не вагон и маленькая тележка, то вам нужно будет создавать стороннее ПО.

Одним из таких видов этого ПО являются редактор уровней. Знакомо? Но оно им не ограничивается. Есть редакторы юнитов, тайлов, частиц, диалогов и др. Все эти инструменты помогают: ускорить и упростить работу.

Первое что надо понять, это то что сама игра и его дополнительное ПО(типа редакторов) - совершенно независимы. Они не влияют друг на друга. Никак. Но! У них есть общая точка соприкосновения, которую вам необходимо сделать. Эта точка является, какой-либо внешний файл. Давайте разберём на примере редактора юнитов.

Что у нас есть? У нас есть игра с кучей юнитов. Чего у нас нет? Программы для работы с этой кучей. Делаем редактор, главное удобный интерфейс для рабочего. т.е. программу которая нам предоставляет возможности по изменению параметров юнитов, их внешнего облика и других нужных вам параметров. Когда такая программа будет готова, нужно будет сделать "точку соприкосновения", т.е. переход от редактора к игре. В этом вам поможет раздел про интерфейсы в статье "Азбука Геймдизайнера". Эта "точка" будет файл с общим алгоритмом сохранения\загрузки, как для редактора, так и для игры. Смотрите:



Делаем юнита в редакторе (слева): Атака = 10, Защита = 4, Скорость = 5, выбираем спрайт и способность. Сохраняем. Стрелочка между игрой и редактором - переходник, точка соприкосновения, интерфейс, в данном случае, файл. В файле хранится следующая информация: первый байт - номер спрайта, второй, третий, четвёртый байты атака, защита, скорость и последний байт способность. Над стрелочкой показано в каком порядке сохранён файл. Загрузка в редакторе и в игре идентичны. Идём в том же порядке: спрайт, атака, защита, скорость, способность. Единственное в чём они различаются это в использований информаций: в редакторе все данные записываются в текстовые боксы для редактирования, а в игре создаётся объект(юнит) с данными параметрами. Это единственное и глобальное отличие.

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

Сейчас поговорим о тех параметрах которые не укладываются в простые числа, как записать спрайт? или сложную способность? Здесь будут подводные камни и вам придётся хорошенько продумать всё. Сохранить спрайт можно несколькими способами. Например, сохранить весь спрайт в этом файле. Объём файла увеличиться намного, да и доступ к спрайту извне будет осложнён, зато вы его не потеряете. А можно сохранить только ссылку в том или ином виде. Ссылку на файл, вы тратите несколько байт на строку такого вида: data\sprite.png . Т.е. вы указываете где находится сам файл. Ссылка должна быть локальной, чтобы переместив игру, ссылка осталась рабочей. Минус - файла может не оказаться. Есть ссылка в другом виде, допустим у вас есть некое хранилище спрайтов в игре, тогда вы оставляете в файле номер спрайта в этом хранилище(как и сделано в примере на картинке, наш спрайт находится в хранилище под номером 1).

Со способностью можно сделать также как в последнем примере со спрайтом, т.е. сделать ссылку в хранилище(на рисунке, номер способности 2). В созданий объекта(юнита) проверяете загрузку той или иной способности. Есть такая способность? Если да, то открываем её, если нет, то нет. А если есть способность, а у ней ещё параметры, то применяем их. Способ хранения сложных переменных смотрите на форуме.

Смысл в том, что надо преобразовать в число, так или иначе. Если вы забываете под каким числом что храниться, то записывайте:

1) Регенерация.
2) Невидимость.
3) Летающий.
4) ...

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

И последнее что я хочу затронуть это изменение файла(интерфейса). Вещь не однозначная, но порою необходимая. Здесь вам поможет пост о версий файла. Старайтесь продумать структуру полностью изначально, это поможет вам избежать изменений в дальнейшем. Но если всё же есть необходимость дорабатывать интерфейс, то готовьтесь к несовместимости с предыдущими версиями файла (подробнее в "Азбуке Геймдизайнера").

Кстати, это хороший пример! Допустим вы поменяли структуру файла, но не критически, т.е. совместимо. Файлов целая куча, вручную слишком долго. Тогда проще написать программу, которая ищет файл в директорий и поддиректорий и пересохраняет в новую версию, если версия файла старая. Это пример прикладного ПО без участия рабочего, запустил и программа сама всё сделает. Быстро и удобно.

P.S.: Хочу объяснить почему именно файл выбран в виде общего интерфейса. В Game Maker нет иного интерфейса передачи информаций, кроме файла. В принципе, этот вид интерфейса должна предоставить Ось, что она и делает в виде интерфейса OLE, через который вы можете передавать информацию прямо налету, но я ею пользоваться не умею, поэтому вам придётся самим извчать этот способ передачи информаций. Вполне возможно, что есть и другие способы передачи информаций на лету кроме OLE. Ищите, если нужно. Но это уже будет через более совершенные языки программирования типа Delphi, а лучше C++.

Комментариев нет:

Отправить комментарий