Объектно-ориентированный подход при создании игровых программных приложений

Так как целью данной курсовой работы является демонстрирование возможностей и особенностей объектно-ориентированного подхода для создания компьютерной игры, то мы можем отказаться от непосредственного кодирования игры, в пользу специальных утилит упрощающих создание игровых приложений. Таких как Multimedia Fusion 2. Данный продукт - целый набор инструментов по созданию полновесных приложений (он ориентирован на игростроение, но с его помощью можно создать так же и обыкновенную программу). Способ создания игр в нем - объектно-ориентированный, что полностью позволяет оценить плюсы и минусы данного подхода при создании игр на ПК.

1. Введение в Mutlimedia Fusion 2

1.1 Общие сведения

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

1.2 Интерфейс

Рисунок 1 - окно MMF2

В workspace toolbar отражаются наши проекты (есть возможность работы с несколькими проектами параллельно). Каждое приложение делится на фреймы (в игровом представлении - различные уровни игры). В свою очередь каждый фрейм раскрывается как набор объектов в этом фрейме.

Окно Properties - как видно из названия, есть свойства выбранного нами объекта\фрейма\проекта.

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

1.3 Объекты и классы в MMF2

Щелкнув правой кнопкой мыши по рабочему окну открывается меню, где основным элементом является «Insert Object». Нажав его, открывается новое окошка выбора класса объекта. Наиболее используемый класс, «Active» - используется для описания основных игровых объектов, будь то монстры которых нужно убивать, или игральные карты, кости и т.д.

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

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

Рисунок 2 - ветка классов

Так же часто используется «Counter» - счетчик. Это может быть счетчик очков, патронов, жизней (но для последнего существует специальный класс «Lives»). Еще нужно отметить объект класса «Window Control» - он позволяет работать с размерами, ориентацией, приоритетом и другими свойствами окна. Я его использовал для изменения размера окна, а так же эффекта необычности в случае проигрыша.

Объект же класса «Backdrop» - обычно используется как «обои» для окна.

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

ѕ ActiveX - класс позволяющий использовать в своем приложении одноименные методы

ѕ Analog Joystick - позволяет использовать как способ управления джойстик и иные аналоговые устройства ввода

ѕ Animation - все понятно из названия, позволяет загружать *.avi файлы

ѕ Button - кнопки, radio-кнопки, чек боксы

ѕ Cursor - изменение курсора мышки

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

ѕ Ini - возможность сохранять / загружать какие либо данные в/из *.ini файла, настраивается для создания «saves»

ѕ Lives - количество жизней

ѕ Mixer - так же обязательный элемент практически во всех играх, позволяет настраивать звук

ѕ Moo - набор иснтрументов для создания игр в стиле MMO (Massive Mutliplayer Online Game), требует высокой квалификации для настройки компонентов, позволяет создавать отдельно сервер игры и клиент

ѕ Network - упрощенный способ создания сетевой игры

ѕ Search - поиск файлов, строк, объектов

ѕ Sub-application - подпрограмма внутри нашего проекта (пример - всплывающее окно с подсказкой)

ѕ Window Shape - изменение внешнего вида нашего окна, всяческая стилизация и украшение.

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

2. О процессе разработки компьютерной игры

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

В начале, Заказчик дает основную идею игры, и пожелания к определенным ключевым моментам (жанр, геймплей, фичи). На этом этапе гейм-дизайнер пытается выведать все мысли заказчика, чтобы в процессе разработки не пришлось переделывать половину проекта. Дальше влияние заказчика на развитие проекта видится только в финансировании (оплате труда разработчиков).

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

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

Далее, уже по готовому сюжету дописывается концепт. На этом этапе появляется более-менее законченный вид игры, т.е. имея сюжет о какой ни будь войне (битве, сражении), дизайнер подбирает информацию об этом эпизоде истории (если это, конечно, исторический момент), выбирает оружие которое использовалось в то время, находит топографические карты местности, униформу сторон, виды техники, соотношение сил и т.д. Потом, когда с энциклопедичной рутиной покончено берется за дело творческая мысль. Придумываются неожиданные ходы, фичи (features), геймплей. Вообще, фичи - это основной предмет душевных терзаний дизайнера, потому если с геймплеем практически все ясно, придумать что-то новое уже сложно, то с фичами все по другому обстоит. Каждую такую фичу необходимо просчитывать, как правило это баланс с другими фичами, и риски, которые она может привести в коммерческую часть вопроса, потому что бывает из-за одного минуса игра полностью проваливается. На протяжении всей разработки концепта, дизайнер должен стараться делать все модульно, что бы была возможность изменить\убрать\добавить какие либо части в любой момент.

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

Собственно, теперь начинается работа кодировщиков и т.п. Они приводят мысли и задумки дизайнера в жизнь. А тут все происходит как при любой разработке любого программного продукта: кодирование, дебаггинг, тестирование, снова дебаггинг (повторять n раз) презентование заказчику и собственно выпуск игры.

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

3. Процесс создания нашей игры