Объектно-ориентированный подход при создании игровых программных приложений
КУРСОВОЙ
ПРОЕКТ
Тема
«Объектно-ориентированный подход при создании игровых программных приложений»
Введение
Так как целью данной курсовой работы
является демонстрирование возможностей и особенностей объектно-ориентированного
подхода для создания компьютерной игры, то мы можем отказаться от
непосредственного кодирования игры, в пользу специальных утилит упрощающих
создание игровых приложений. Таких как 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»
- он позволяет работать с размерами, ориентацией, приоритетом и другими
свойствами окна. Я его использовал для изменения размера окна, а так же эффекта
необычности в случае проигрыша.
Это что о классах,
которые использовались в данной работе. Теперь кратко о других, несомненно
важных классах, но не использованных в нашей игре.
¾ 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. Процесс создания
нашей игры
Итак, у нас есть пустое окно
Multimedia Fusion 2
Создаем новый проект с пустым
фреймом
Как Вы можете видеть, разрешение
данного фрейма 640*480, его легко изменить, но мы не станем этого делать,
потому что именно такое разрешение нам подходит.
Теперь поместим на рабочее поле
новый объект. Нам понадобится объект класса «Active»:
На рабочем поле появится зеленый
ромб, дважды щелкнув по нему, мы приступим к его изменению:
Итак, мы придали нашему объекту
необходимый вид, теперь надо задать тип его движения, в нашем случае это будет
простое отталкивание:
Так же, как Вы видите, есть возможно
задать разные типы движений, но мы не будем останавливаться на этом. Нам
необходимо «научить» шарик отталкиваться от стенок окна. Для этого мы заходим в
меню «Event editor», его пиктограмма выглядит так - . Далее мы ищем необходимый нам пункт меню:
Выбираем «Test position of Players Robot», нам открывается
окошко, в котором мы выбираем условия.
Теперь, мы будем набрасывать на наш
фрейм все необходимые объекты и в конце концов получим такую картину:
Положение же Window Contol не суть
важно, потому что оно не влияет на ход игры, и в самой игре мы его не увидим.
Чтобы просмотреть все «эвенты»
связанные с каким либо объектом, надо щелкнуть по нему мышкой:
Так же, для более удобного
восприятия есть возможность просмотра действий сразу, без захода в действие
определенного объекта:
Довольно интересным будет способ
задания направления, его можно задать визуально, либо формулой (в ММF2 есть сильный калькулятор
поддерживающий различные функции - тригонометрические, логарифмические и т.п.),
но в нашем случае это будет визуальный способ.
Данное направление задается при
нажатии клавиши «Вверх», как видите движение будет равновероятностным в пяти
направлениях.
Теперь пару слов о фрейме «Game Over». У меня с самого
начала была мысль сделать его необычным, удивляющим, и идея о том, чтобы
поместить туда известный всем опытным Win пользователям BSOD (Blue Screen Of Death - Синий Экран Смерти, так его «любя» называют пользователи),
пришлась весьма кстати. Найдя картину в интернете, прикрепил ее к объекту «Backdrop».
Таким образом, наше приложение было
закончено и осталось только превратить его в *.ехе файл.
Заключение
Итак, проделав данную работу, мы
научились использовать Multimedia Fusion 2. Данный программный продукт
позволяет в полной мере осознать структуру и смысл объектно-ориентированного
подхода при создании игровых и не только приложений.