2 раздел анализ предметной области 5



Скачать 11.53 Mb.
страница3/4
Дата27.10.2016
Размер11.53 Mb.
Просмотров304
Скачиваний0
ТипДипломная работа
1   2   3   4

Итог

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


Объекты взаимодействия обладают некоторой общностью:

  • Способ взаимодействия (автоматический, нахождения объекта на сцене, использование инструмента поиска или RayCasting);

  • Состояние объекта (определяет текущее поведение);

  • Коммуникация (приём и отправка сообщения для обмена информация между объектами);

  • Условие взаимодействия (Определённые условия для взаимодействия с объектом, например, клавиша мыши, значения определённых переменных и т.д.);

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


РАЗДЕЛ 2. КОНЦЕПЦИЯ



  1. Концепция

Для обеспечения коммуникации между игровыми объектами используется система обмена сообщениями.

Сообщения – это цифровая информация виртуального мира, которую можно передавать, получать и обрабатывать её. Ниже представлен пример обмена сообщениями:

Рисунок 2.. Общая концепция обмена сообщениями.


Как видно из схемы (рисунок 2.1), сообщения могут быть глобальными (передаваться всем объектам взаимодействий) или быть локальными (передаваться только слушателям).

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

Сообщения могут порождать события, которые происходят с объектами: например мы можем подать сигнал смены погоды, взять предмет или открыть дверь.

Основной алгоритм взаимодействия с объектом:



c:\users\asus\desktop\f1.png

Рисунок 2.. Основной алгоритм взаимодействия с объектом.


Каждый интерактивный объект, может совершать какие-либо действия. Чтобы действие произошло, оно проходит ряд проверок, одно из них: условие взаимодействия.

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

Условия и события зависят от состояния объекта. Состояния строятся в простой детерминированный конечный автомат и содержат в себе условия и событие для данного состояния:
c:\users\asus\desktop\f5.png

Рисунок 2.. Диаграмма состояний объекта.


На примере игровой двери:

c:\users\asus\desktop\f4_cr.png

Рисунок 2.. Диаграмма состояний объекта на примере двери.


С помощью данной концепции можно построить гибкую и расширяемую модель взаимодействия между объектами в виртуальном пространстве. Так же концепция обеспечит независимость объектов с помощью обмена информацией между ними и сложное поведение с помощью состояний.


  1. Постановка задачи

Разработка модели взаимодействия объектов в виртуальном пространстве.

Основная цель: добиться гибкости и масштабируемости.

Рисунок 2.. Общая схема архитектуры взаимодействий.


Реализовать главный объект иерархии InteractiveObject.

Он должен включать в себя базовую концепцию и обладать:



  • Набором состояний с условиями взаимодействия и запуска, а так же самим событием;

  • Добавление и удаление состояний;

  • Подписываться и отписываться для прослушивания сообщений;

  • Добавлять слушателей сообщений;

  • Отправлять и обрабатывать сообщения.

На основе архитектуры выделить и реализовать основные интерактивные объекты, с помощью которых, можно строить более сложные модели.

Объект Player:


  • Условие взаимодействия: взгляд (Raycast);

  • Условие запуска: клавиши ввода, дополнительные условия, такие как предметы, сообщения отличаются типом.

Управляемые и управляющие объекты.


Управляемые объекты:

  • Предоставление данных, которые можно изменять (посредством передачи сообщений);

  • Смена управляющих объектов “на лету”;

  • Удаление управляющих объектов;

  • Запрет на изменение данных.

Управляющие объекты:



  • Независимое представление управляемого объекта;

  • Изменение данных управляемого объекта посредством сообщений.


РАЗДЕЛ 3. РАЗРАБОТКА АРХИТЕКТУРЫ



  1. Инструментальные средства

Unity 3D


unity-engine.jpg

Рисунок 3.1. Логотип Unity3D.
Unity — это мультиплатформенный инструмент для разработки двух- и трёхмерных приложений и игр, работающий под операционными системами Windows и OS X. Игры, созданные на данном инструменте можно портировать на: Windows, OS X, Android, Apple iOS, Linux, а также на игровые приставки Wii, PlayStation 3 и XBox 360. Так же можно создавать игры, работающие в браузере, для этого надо установить специальный модуль Unity Web Player. Также приложения созданные, с помощью Unity3D поддерживают обе спецификации 3D графики DirectX и OpenGL.
Особенности


  • Несколько сценарных языков программирования: C#, JavaScript (модификация) и Boo;

  • Возможность мгновенного запуска игры;

  • Простая работа с ресурсами через Drag-and-Drop;

  • широкие возможности импорта

  • полностью настраиваемый и доступный большинству людей интерфейс

  • кроссплатформенность

  • мощь, гибкость и бесконечная расширяемость

  • наличие бесплатной версии с некоторыми ограничениями


c:\users\asus\desktop\сохраненное изображение 2013-5-28_22-24-21.556.jpg

Рисунок 3.2. Графический интерфейс Unity3D.

Visual Studio 2012



c:\users\asus\desktop\сохраненное изображение 2013-5-28_22-26-20.307_cr.jpg

Рисунок 3.3. Логотип Visual Studio 2012.

Microsoft Visual Studio — линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств.


Visual Studio включает в себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный отладчик может работать как отладчик уровня исходного кода, так и как отладчик машинного уровня. Остальные встраиваемые инструменты включают в себя редактор форм для упрощения создания графического интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы данных. Visual Studio позволяет создавать и подключать сторонние дополнения (плагины) для расширения функциональности практически на каждом уровне, включая добавление поддержки систем контроля версий исходного кода (как например, Subversion и Visual SourceSafe), добавление новых наборов инструментов (например, для редактирования и визуального проектирования кода на предметно-ориентированных языках программирования или инструментов для прочих аспектов процесса разработки программного обеспечения (например, клиент Team Explorer для работы с Team Foundation Server). В данной работе Visual Studio 2012 используется как лучшая альтернатива MonoDevelop, которую использует Unity3D “из коробки”.
c:\users\asus\desktop\сохраненное изображение 2013-5-28_23-9-21.254.jpg

Рисунок 3.4. Графический интерфейс Visual Studio 2012.
Язык программирования C#

C# (произносится си шарп) — объектно-ориентированный язык программирования. Разработан в 1998—2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как язык разработки приложений для платформы Microsoft .NET Framework и впоследствии был стандартизирован как ECMA-334 и ISO/IEC 23270.


C# относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов (в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщённые типы и методы, итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.
Переняв многое от своих предшественников — языков C++, Java, Delphi, Модула и Smalltalk — С#, опираясь на практику их использования, исключает некоторые модели, зарекомендовавшие себя как проблематичные при разработке программных систем, например, C# в отличие от C++ не поддерживает множественное наследование классов (между тем допускается множественное наследование интерфейсов).
Данный язык был выбран в качестве основного, так как обладает нужными качествами для реализации, имеет встроенную поддержку обобщений, делегатов и событий, что облегчит реализацию.



  1. Основная модель

“Стремитесь к слабой связанности взаимодействующих объектов”

Head First Java Patterns
Обычно в играх очень много различных взаимодействующих объектов.

Чем меньше они знают друг о друге, тем гибче система. Одному компоненту нет необходимости знать о внутреннем устройстве другого.


Коммуникации
Для обеспечения коммуникации для взаимодействующих объектов используем паттерн “Наблюдатель”.
Наблюдатель (Observer) — поведенческий шаблон проектирования. Также известен как «подчинённые» (Dependents), «издатель-подписчик» (Publisher-Subscriber).

Определяет зависимость типа «один ко многим» между объектами таким образом, что при изменении состояния одного объекта все зависящие от него оповещаются об этом событии.


Создадим интерфейс для независимости от реализации.
public interface Observer {



void AddListener(string eventType, Callback handler);

void AddListener(string eventType, Callback handler);

void AddListener(string eventType, Callback handler);

void AddListener(string eventType, Callback handler);
void RemoveListener(string eventType, Callback handler);

void RemoveListener(string eventType, Callback handler);

void RemoveListener(string eventType, Callback handler);

void RemoveListener(string eventType, Callback handler);
void Fire(string eventType);

void Fire(string eventType, T arg1);

void Fire(string eventType, T arg1, U arg2);

void Fire(string eventType, T arg1, U arg2, V arg3);
}

Observer представляет собой очень гибкий интерфейс на основе обобщений, в качестве первого аргумента передается тип события, второй аргумент Callback – перегруженный делегат (метод) на основе обобщений.


public delegate void Callback();
public delegate void Callback(T arg1);
public delegate void Callback(T arg1, U arg2);
public delegate void Callback(T arg1, U arg2, V arg3);

Проанализировав предметную область, выделим временную составляющую взаимодействий:

- Долговременные взаимодействия (Должна быть возможность получить коммуникации для обмена сообщения с объектом);

- Мгновенные взаимодействия;

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

На основе этих доводов определим, интерфейс для интерактивного объекта:


interface INteractive {

void Connect(IDispatcher from);
void Disconnect(IDispatcher from);
void Send(string eventType);
void Send(string eventType, T arg);
void Send(string eventType, T arg1, U arg2);
void Send(string eventType, T arg1, U arg2, V arg3);

}

Connect – Получение коммуникаций для дальнейшего обмена информацией.

Disconnect – Разрыв коммуникаций для прекращения обмена.

Send – Мгновенная отправка информации без установления коммуникаций.

Является очень гибким и на его основе можно создавать различные виды коммуникаций.
Для реализации механизма работы “Обозревателя” агрегируем специально подготовленный объект Messager.

c:\users\asus\desktop\mainobject_cr.png

Диаграмма 3.1. Абстрактная модель обмена сообщениями.

Состояния

Для обеспечения смены состояний взаимодействующих объектов требуется разработать механизм. На данный случай можно воспользоваться конечным автоматом.
Конечный автомат — абстрактный автомат без выходного потока, число возможных состояний которого конечно. Результат работы автомата определяется по его конечному состоянию.

Для начала опишем требования к автомату:

- Добавление/Удаление состояний;

- Смена состояния;

- Обновление состояния;

- Доступ к владельцу;


Требования к состояниям конечного автомата:

- Доступ к владельцу;

- Перехват входа/выхода состояния;

- Исполнение обязанностей состояния;


Добавим возможность смены состояний для основной модели взаимодействий.

c:\users\asus\desktop\intobj.png

Диаграмма 3.2. Абстрактная модель с поддержкой состояний.

Теперь все требования учтены, рассмотрим полную картину:



c:\users\asus\desktop\full main.png

Диаграмма 3.3. Финальная диаграмма интерактивного объекта.
Данная модель обладает коммуникациями для обмена информацией с другими объектами, построенными на этой модели.

Возможность смены состояний на основе конечных автоматов.

InteractiveObject включает в себя все требования. Частные случаи создания объектов взаимодействий будут рассмотрены в следующем разделе.


  1. Реализация частных случаев объектов взаимодействий

Для примера возьмём игровой объект “Дверь” (Door).

Door – является объектом взаимодействия, а значит мы можем передавать информацию двери, например, чтобы она открылась. Из этого следует, что дверь обладает состояниями.
Состояния двери:


  • Открыта;

  • Закрыта;

  • Открывается/Закрывается;

Состояние “Открывается/Закрывается” являются одинаковыми, так как это переходное состояние.

Состояниями двери не являются: заблокирована, сломана, цвет и т.д.

Это параметры двери.


Рассмотрим диаграмму состояний двери:
c:\users\asus\desktop\doorstates_cr.png

Диаграмма 3.4. Диаграмма состояний двери.


      1. Переход из состояния “Открыта” в состояние “Открывается”.

      2. Переход из состояния “Закрывается” в состояние “Закрыта”.

      3. Переход из состояния “Закрыта” в состояние “Открывается”.

      4. Переход из состояния “Открывается” в состояние “Открыта”.

А каким образом дверь будет открываться или закрываться?

Здесь нам понадобится механизм взаимодействий, а точнее коммуникации для передачи информации, например сигнала двери, чтобы она начала открываться или закрываться.

К InteractiveObject могут подключаться любые объекты реализующие интерфейс Observer. Для того чтобы подключится к объекту надо вызвать метод Connect. Но чтобы объект, к которому мы подключились, мог получать наши сообщения, он должен настроить определённые соглашения.
Например:
protected override void Connect(Observer from) {

from.AddListenerstring>(“Action”, OnAction); }
protected override void Disconnect(Observer from) {

from.RemoveListenerstring>(“Action”, OnAction);

}
protected virtual void OnAction(MainObject from, string type) {

}
Метод Connect(Observer from) принимает в качестве аргумента источник сообщений. Формат получения сообщений: from.AddListener(“Action”, OnAction).

Рассмотрим подробнее:

Если произошло событие типа “Action”, то получить сообщение в метод OnAction(MainObject from, string type), с полями MainObject from – От кого, string type – Тип действия.

Метод Disconnect(Observer from) разрывает эту связь.


Таким образом, мы можем реагировать на события типа “Action”, и принимать информацию в виде MainObject from – От кого, string type – Тип действия.

Это позволит нам реагировать на различные типы действий.

Предположим, что у нас есть объект взаимодействий Player, который может передавать информацию другим объектам. Мы хотим, что бы объект Door получал информацию от объекта Player, для этого нам всего лишь нужно подключиться к объекту Door с помощью метода Connect(Observer from):

Door.Connect(Player)

Теперь чтобы передать сообщение Door нам надо вызвать метод Fire на стороне Player:

Fire(“Action”, Player, “Action”)



c:\users\asus\desktop\fire_cr.png

Диаграмма 3.5. Диаграмма обмена информацией с дверью.
С помощью этой информации изложенной в этом разделе мы можем смоделировать дверь отвечающую следующим требованиям:

- Обладание состояниями (Дверь имеет несколько состояний, а так же переходы между ними);

- Реакция на внешние воздействия (с помощью метода Connect можно получать сообщения извне в метод OnConnect и реагировать на информацию);

- Слабая связанность (Объекту неважно, откуда приходят сообщения).

Финальная диаграмма классов для объекта Door:

c:\users\asus\desktop\doorfinal_cr.png

Диаграмма 3.6. Финальная диаграмма интерактивной двери.
Пояснения к диаграмме:
Именно к двери подключаются внешние источники сообщений для передачи информации, но состояния двери тоже должны реагировать на различные воздействия через метод OnAction(), поэтому целесообразно делегировать вызовов всем состояниям, а не слушать каждым состоянием события в метод OnAction().
Код из класса Door:

OnAction(Observer from, string type) {

var state = _fsm.CurrentState() as Actionable; // Получаем текущее состояние
if (state != null) {

state.OnAction(from, type); // Делегируем вызов текущему состоянию

}

}
AbstractDoorState – абстрактный класс состояния двери, в нем можно определить логику общую для всех состояний двери.
OpenDoorState, CloseDoorState, OpeningDoorState – классы состояний двери, в каждом из них можно определить переходы в другие состояния. Каждое состояние может реагировать на внешние источники, например реализация открытия двери (переход из состояния “Закрыта” в “Открывается”):
OnAction(Observer from, string type) {

if (type == “Action”) { // Если тип действия “Action”



Entity.ChangeState(Door.States.Opening); // Получаем доступ к владельцу и изменяем его состояние на “Opening” (Открывается)
}

}

c:\users\asus\desktop\сохраненное изображение 2013-5-30_0-29-10.759_cr.jpg

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

Fire(“Action”, Player, “Action”)


c:\users\asus\desktop\сохраненное изображение 2013-5-30_0-34-5.190_cr.jpg

Рисунок 3.6. Дверь реагирует и начинает открываться.
Но каким способом мы получаем канал связи с дверью?

В этом нам поможет специальный инструмент, который упомянут ранее это - Ray Casting. Назовём данный инструмент Laser.

Этот независимый компонент, который ищет объект взаимодействий и сообщает своим слушателям, что она нашёл новый.
Чтобы объект Player мог использовать данный компонент, достаточно наладить с ним связь (в контексте Player):

Laser.AddListener<INteractive>(newItem, OnNewItem) // Теперь каждый раз, когда объект Laser найдёт новый объект взаимодействий он передаст новую информацию в метод OnNewItem
private void OnNewItem(INteractive item) // Получаем информацию о новом интер. объекте

{

if (_currentItem != null) // Если текущий существует

_currentItem.Disconnect(this); // Разрываем с ним связь
if (_currentItem != item) { // Если, это новый или пустой

_currentItem = item;

if (_currentItem != null) { // Если не пустой

_currentItem.Connect(this); // Налаживаем связь с ним

}

}

Теперь объект Player обладает свойствами Ray Casting. И ему не надо реализовывать весь функционал. Данный алгоритм инкапсулирован объекту Laser.

Рассмотрим объект поиска предметов подробнее:

c:\users\asus\desktop\raycasting_cr.png

Диаграмма 3.7. Основная схема объекта Laser.
Объект Laser реализует паттерн “Стратегия”, который позволяет изменять поведение поиска “на лету”:

RayCaster = new CenterRayCaster(); // Сейчас стратегией поиска занимается объект CenterRayCaster


Класс CenterRayCaster реализует интерфейс IRayCaster и поэтому может быть использован в качестве объекта стратегии:

class CenterRayCaster : IRayCaster
// Данная стратегия достаточно проста

// Получаем центр экрана



_horizontalWidth = Screen.width / 2;

_verticalWidth = Screen.height / 2;
_castVector = new Vector3(_horizontalWidth, _verticalWidth);
// Получаем луч относительно “взгляда”, а точнее направления камеры

_ray = Camera.main.ScreenPointToRay(_castVector);

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

Можно выделить следующие шаги алгоритма взаимодействий для Player c внешним окружением:

- Получить новый объект взаимодействий;

- Если есть связь с текущим объектом, то прервать коммуникации;

- Если найден новый объект, то связаться с ним;

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



  1. Выводы

В данном разделе была разработана модель взаимодействий между объектами. Созданы средства коммуникации через асинхронную передачу сообщений, что позволяет объектам быть независимыми от других объектов взаимодействий. Каждый новый слушатель или получатель может “на лету” подключен или отключен от источника. Так же мы имеем очень гибкий интерфейс обмена информацией, что позволяет объектам самим определять интерфейс. Так же существует возможность мгновенной отправки сообщения без предварительного соединения (когда долгосрочный обмен сообщениям не требуется). Объекты обладают состояниями, что позволяет изменять их поведение во время работы программы. Система состояний является очень гибкой, так как может быть подключена к любому объекту посредством агрегирования. Позволяет добавлять новые состояния и удалять старые. Дает возможность смены состояний, как мгновенно, так и через некоторое время. Это позволяет нам планировать изменение поведения. Для поиска предметов был использован инструмент Laser, который может изменять стратегию поиска “на лету”. Так же была оставлена возможность для смены “природы” поиска объектов, путём агрегирования инструмента поиска. Что является очень гибким и независимым от реализации.




Поделитесь с Вашими друзьями:
1   2   3   4


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал