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

Название	Курсовой проект по дисциплине Разработка графических компьютерных приложений
Анкор	Реализация паттерна State Unity
Дата	04.06.2022
Размер	128.84 Kb.
Формат файла
Имя файла	курсовая.docx
Тип	Курсовой проект #569564

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«КАБАРДИНО-БАЛКАРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

им. Х.М. БЕРБЕКОВА»

Институт информатики, электроники и робототехники

Кафедра компьютерных технологий и информационной безопасности

КУРСОВОЙ ПРОЕКТ

по дисциплине «Разработка графических компьютерных приложений»

на тему:

«Реализация паттерна State в Unity»

Выполнил:

ст-т 3 курса Тебуев Майыл Расулович

напр. ИВТ (АСОИиУ)

ФИО

Проверил:

ст. преподаватель

каф. КТиИБ

Нагоев К.Н

Нальчик 2021.

Содержание

Содержание 2

1.Введение 3

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

2.1.Выбор языка и среды программирования 7

2.2.Различные паттерны 7

2.3.Паттерн State. 11

3. Программная реализация паттерна. 18

4.Заключение. 24

5.Список литературы. 25

1.Введение

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

Так как целью курсовой работы является реализация паттерна State (Состояние) в Unity, для начала необходимо понять, что же такое паттерн.

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

Имя. Сославшись на него, мы можем сразу описать проблему проектирования; ее решения и их последствия. Присваивание паттернам имен позволяет проектировать на более высоком уровне абстракции. С помощью словаря паттернов можно вести обсуждение с коллегами, упоминать паттерны в документации, в тонкостях представлять дизайн системы. Название паттерна должно четко отражать его назначение.
Задача. Описание того, когда следует применять паттерн. Необходимо сформулировать задачу и ее контекст. Может описываться конкретная проблема проектирования или перечень условий, при выполнении которых имеет смысл применять данный паттерн.
Решение. Описание элементов, отношений между ними, функций каждого элемента. Конкретный дизайн или реализация не имеются в виду, поскольку паттерн применим в самых разных ситуациях. Дается абстрактное описание задачи проектирования и того, как она может быть решена с помощью некоего весьма обобщенного сочетания классов и объектов.
Результаты — это следствия применения паттерна и разного рода компромиссы. Хотя при описании проектных решений о последствиях часто не упоминают, знать о них необходимо, чтобы можно было выбрать между различными вариантами и оценить преимущества и недостатки данного паттерна.

Можно отметить четыре основных преимущества паттернов:

они позволяют суммировать опыт экспертов и сделать его доступным рядовым разработчикам;
имена паттернов образуют своего рода словарь, который позволяет разработчикам лучше понимать друг друга;
если в документации системы указано, какие паттерны в ней используются, это позволяет читателю быстрее понять систему;
паттерны упрощают реструктуризацию системы независимо от того, использовались ли паттерны при ее проектировании или нет.

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

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

Кроме того, паттерны отличаются и предназначением. В этой книге будут рассмотрены три основные группы паттернов:

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

Впервые концепцию паттернов описал Кристофер Александр в книге “Язык шаблонов. Города. Здания. Строительство”. В этой книге паттерны отвечают на различные архитектурные вопросы. Далее в 1984 году Эрих Гамм, Ричард Хелм, Ральф Джонсон, Джон Влиссидес, вдохновившись идеей, написали книгу “Приемы объектно-ориентированного программирования. Паттерны проектирования”, в которой были описаны 23 паттерна. С тех пор были найдены десятки других объектных паттернов. «Паттерновый» подход стал популярен и в других областях программирования, поэтому сейчас можно встретить всевозможные паттерны и за пределами объектного проектирования.

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

2.1.Выбор языка и среды программирования

Паттерны можно реализовать на множестве языков программирования: Java, Python, Java Script, C++, C#, PHP и т.д. В данной курсовой работе для реализации паттерна state будет выбран язык С#, так как с ним удобнее взаимодействовать со средой разработки Unity.

2.2.Различные паттерны

В C# Unity существуют следующие паттерны:

Abstract Factory - это порождающий паттерн проектирования, который позволяет создавать семейства связанных объектов, не привязываясь к конкретным классам создаваемых объектов. Преимущества: гарантирует сочетаемость создаваемых продуктов, избавляет клиентский код от привязки к конкретным классам продуктов, выделяет код производства продуктов в одно место, упрощая поддержку кода, упрощает добавление новых продуктов в программу, реализует принцип открытости/закрытости. Недостатки: усложняет код программы из-за введения множества дополнительных классов, требует наличия всех типов продуктов в каждой вариации.
Factory Method - это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов. Преимущества: избавляет класс от привязки к конкретным классам продуктов, выделяет код производства продуктов в одно место, упрощая поддержку кода, упрощает добавление новых продуктов в программу, реализует принцип открытости/закрытости. Недостатки: Может привести к созданию больших параллельных иерархий классов, так как для каждого класса продукта надо создать свой подкласс создателя.
Builder - это порождающий паттерн проектирования, который позволяет создавать сложные объекты пошагово. Строитель даёт возможность использовать один и тот же код строительства для получения разных представлений объектов. Преимущества: позволяет создавать продукты пошагово, позволяет использовать один и тот же код для создания разных продуктов, изолирует сложный код сборки продукта от его основной бизнес-логики. Недостатки: усложняет код программы за счет введения дополнительных классов, клиент будет привязан к конкретным классам строителей, так как в интерфейсе директора может не быть метода получения результата.
Prototype - это порождающий паттерн проектирования, который позволяет копировать объекты, не вдаваясь в подробности их реализации. Преимущества: позволяет клонировать объекты без привязывки к их конкретным классам, Менее повторяющийся код инициализации объекта, усокряет создание объектов, альтернатива подклассам для построения сложных объектов. Неостатки: клонировать составные объекты, имеющие ссылки на другие объекты, сложно.
Observer – это поведенческий шаблон проектирования, который создает механизм подписки, который позволяет одному объекту отслеживать и реагировать на события, происходящие в других объектах. Преимущества: издатели не зависят от определенных классов подписчиков и наоборот, вы можете подписаться и отписаться от получателей на лету, реализует принцип открытости/закрытости. Недостатки: подписчики оповещаются в случайном порядке.
Iterator - это поведенческий паттерн проектирования, который даёт возможность последовательно обходить элементы составных объектов, не раскрывая их внутреннего представления. Преимущества: упрощает классы хранения данных, позволяет реализовать различные способы обхода структуры данных, позволяет одновременно перемещаться по структуре данных в разных направлениях. Недостатки: можно обойтись простым циклом.
Strategy - это поведенческий паттерн проектирования, который определяет семейство похожих алгоритмов и помещает каждый из них в свой собственный класс, после чего алгоритмы можно менять местами прямо во время выполнения. Преимущества: изолирует код и данные алгоритмов от остальных классов, уход от наседования к делегированию, код и данные изолированы от остальных классов. Недостатки: для выбора подходящей стратегии, клиенту необходимо знать различия между стратегиями, усложняет прогармму за счет дополнительных классов.
Controller - это поведенческий паттерн проектирования, который позволяет уменьшить связь многих классов друг с другом, перемещая эти отношения в один класс-посредник. Преимущества: упрощает взаимодействие между компонентами, централизует управление в одном месте, позволяет повторно использовать компоненты.
Visitor - это поведенческий паттерн проектирования, который позволяет вам добавлять новые операции в вашу программу, не изменяя классы объектов, над которыми эти операции могут выполняться. Преимущества: объединяет родственные операции в одном классе, посетитель может накапливать состояние при обходе структуры элемента, упрощает операции добавления, которые имеют дело со сложными структурами объектов. Недостатки: может привести к нарушению инкапсуляции элементов, паттерн не оправдан, если иерархия элементов часто меняется.
Template Method - это поведенческий паттерн проектирования, который определяет каркас алгоритма, перекладывая ответственность за некоторые из его шагов на подклассы. Паттерн позволяет подклассам отменять шаги алгоритма без изменения его общей структуры. Приемущества: облегчает повторное использование кода. Недостатки: по мере увеличения количества шагов стандартный метод становится слишком сложным в обслуживании, Вы жестко ограничены скелетом существующего алгоритма.
Memento - это поведенческий паттерн проектирования, который позволяет сохранять и восстанавливать прошлые состояния объектов, не раскрывая деталей их реализации. Приемущества: не нарушает инкапсуляции исходного объекта, упрощает структуру исходного объекта, ему не нужно вести историю версий своего состояния. Недостатки: требует много памяти, если клиенты слишком часто создают снимки, могут возникнуть дополнительные накладные расходы на память, если исторические объекты не освобождают ресурсы, занятые устаревшими снимками.
Chain of Command - это поведенческий паттерн проектирования, который позволяет последовательно передавать запросы через цепочку обработчиков. Каждый последующий обработчик решает, сможет ли он обработать сам запрос и стоит ли передавать запрос дальше по цепочке. Приемущества: уменьшает зависимость между клиентом и обработчиками, реализует принцип единственной обязанности, реализует принцип открытости/закрытости. Недостатки: запрос может быть никем не обраотан.
Adapter - это структурный паттерн проектирования, который позволяет объектам с несовместимыми интерфейсами работать вместе. Приемущества: Отделяет и скрывает детали преобразования различных интерфейсов от клиента. Недостки: усложняет программный код за счет введения дополнительных классов.
Bridge - это структурный паттерн проектирования, который разделяет один или несколько классов на две отдельные иерархии — абстракцию и реализацию, позволяя изменять их независимо друг от друга. Приемущства: позволяет строить платформо-независимые программы, скрывает ненужные или опасные детали реализации из клиентского кода, реализует принцип открытости/закрытости. Недостатки: Усложняет код программы из-за введения дополнительных классов.
Composite - это структурный паттерн проектирования, который позволяет сгруппировать множество объектов в древовидную структуру, а затем работать с ней так, как будто это единичный объект. Приемущства: упрощает клиентскую архитектуру при работе со сложным деревом компонентов, облегчает добавление новых видов компонентов. Недостатки: Создает слишком общий дизайн классов.
Decorator - это структурный паттерн проектирования, который позволяет динамически добавлять объектам новую функциональность, оборачивая их в полезные «оболочки». Приемущества: большая гибкость, чем у наследования, позволяет по ходу добавлять обязанности, можно добавлять сразу добавлять несколько обязанностей, позволяет иметь несколько небольших предметов вместо одного на все случаи жизни. Недостатки: обилие крошечных классов, трудно конфигурировать многократно обёрнутые объекты.
Facade - это структурный паттерн проектирования, который предоставляет простой интерфейс к сложной системе классов, библиотеке или фреймворку. Приемущества: изолирует клиентов от компонентов сложной подсистемы. Недостатки: фасад рискует стать божественным объектом, привязанным ко всем классам программы.
Flyweight - это структурный паттерн проектирования, который позволяет вместить бóльшее количество объектов в отведённую оперативную память. Легковес экономит память, разделяя общее состояние объектов между собой, вместо хранения одинаковых данных в каждом объекте. Приемущества: экономит оперативную память. Недостатки: расходует процессорное время на поиск/вычисление контекста, усложняет код программы из-за введения множества дополнительных классов.

2.3.Паттерн State.

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

Пример из жизни: Ваш смартфон ведёт себя по-разному, в зависимости от текущего состояния:

Когда телефон разблокирован, нажатие кнопок телефона приводит к каким-то действиям.
Когда телефон заблокирован, нажатие кнопок приводит к экрану разблокировки.
Когда телефон разряжен, нажатие кнопок приводит к экрану зарядки.

UML схема паттерна "Состояние":

Шаги реализации:

Определитесь с классом, который будет действовать в качестве контекста. Это может быть, как существующий класс, в котором уже есть зависимость от состояния, так и новый класс, если код состояния распределен по нескольким классам.
Создайте общий интерфейс состояния. Он должен описывать методы, общие для всех состояний, найденных в контексте. Обратите внимание, что не все поведение контекста необходимо передавать в состояние, а только то, которое зависит от состояний.
Для каждого фактического состояния создайте класс, реализующий интерфейс состояния. Переместите код, связанный с определенными состояниями, в нужные классы. В конце концов, все методы интерфейса состояний должны быть реализованы во всех классах состояний.
Создайте поле в контексте для хранения объектов состояния, а также открытый метод для изменения значения этого поля.
Замените старые методы контекста, в котором находился зависимый от состояния код, вызовами соответствующих методов объекта состояния.
В зависимости от вашей бизнес-логики разместите код, который переключает состояние контекста, либо внутри контекста, либо внутри конкретных классов состояний.

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

// Общий интерфейс всех состояний.

abstract class State is

protected field player: AudioPlayer

// Контекст передаёт себя в конструктор состояния, чтобы

// состояние могло обращаться к его данным и методам в

// будущем, если потребуется.

constructor State(player) is

this.player = player

abstract method clickLock()

abstract method clickPlay()

abstract method clickNext()

abstract method clickPrevious()

// Конкретные состояния реализуют методы абстрактного состояния

// по-своему.

class LockedState extends State is

// При разблокировке проигрователя с заблокированными

// клавишами он может принять одно из двух состояний.

method clickLock() is

if (player.playing)

player.changeState(new PlayingState(player))

else

player.changeState(new ReadyState(player))

method clickPlay() is

// Ничего не делать.

method clickNext() is

// Ничего не делать.

method clickPrevious() is

// Ничего не делать.

// Конкретные состояния сами могут переводить контекст в другое

// состояние.

class ReadyState extends State is

method clickLock() is

player.changeState(new LockedState(player))

method clickPlay() is

player.startPlayback()

player.changeState(new PlayingState(player))

method clickNext() is

player.nextSong()

method clickPrevious() is

player.previousSong()

class PlayingState extends State is

method clickLock() is

player.changeState(new LockedState(player))

method clickPlay() is

player.stopPlayback()

player.changeState(new ReadyState(player))

method clickNext() is

if (event.doubleclick)

player.nextSong()

else

player.fastForward(5)

method clickPrevious() is

if (event.doubleclick)

player.previous()

else

player.rewind(5)

// Проигрыватель выступает в роли контекста.

class AudioPlayer is

field state: State

field UI, volume, playlist, currentSong

constructor AudioPlayer() is

this.state = new ReadyState(this)

// Контекст заставляет состояние реагировать на

// пользовательский ввод вместо себя. Реакция может быть

// разной, в зависимости от того, какое состояние сейчас

// активно.

UI = new UserInterface()

UI.lockButton.onClick(this.clickLock)

UI.playButton.onClick(this.clickPlay)

UI.nextButton.onClick(this.clickNext)

UI.prevButton.onClick(this.clickPrevious)

// Другие объекты тоже должны иметь возможность заменять

// состояние проигрывателя.

method changeState(state: State) is

this.state = state

// Методы UI будут делегировать работу активному состоянию.

method clickLock() is

state.clickLock()

method clickPlay() is

state.clickPlay()

method clickNext() is

state.clickNext()

method clickPrevious() is

state.clickPrevious()

// Сервисные методы контекста, вызываемые состояниями.

method startPlayback() is

// ...

method stopPlayback() is

// ...

method nextSong() is

// ...

method previousSong() is

// ...

method fastForward(time) is

// ...

method rewind(time) is

// ...

3. Программная реализация паттерна.

Рассмотрим на конкретном примере реализацию паттерна State (Состояние) в С#.

public virtual void Enter()

{

DisplayOnUI(UIManager.Alignment.Left);

}

public virtual void HandleInput()

{

}

public virtual void LogicUpdate()

{

}

public virtual void PhysicsUpdate()

{

}

public virtual void Exit()

{

}

Данные виртуальные методы описывают ключевые пункты состояния. Когда машина состояний выполняет переход между состояниями, мы вызываем Exit для предыдущего состояния и Enter нового активного состояния. HandleInput обрабатывает ввод игрока. LogicUpdate обрабатывает базовую логику, а PhyiscsUpdate обрабатывает логику и вычисления физики.

public void Initialize(State startingState)

{

CurrentState = startingState;

startingState.Enter();

}

public void ChangeState(State newState)

{

CurrentState.Exit();

CurrentState = newState;

newState.Enter();

}

Initialize настраивает машину состояний, а ChangeState обрабатывает переходы между этими состояниями.

private void Start()

{

movementSM = new StateMachine();

standing = new StandingState(this, movementSM);

jumping = new JumpingState(this, movementSM);

movementSM.Initialize(standing);

}

private void Update()

{

movementSM.CurrentState.HandleInput();

movementSM.CurrentState.LogicUpdate();

}

private void FixedUpdate()

{

movementSM.CurrentState.PhysicsUpdate();

}

В Start код создаёт экземпляр State Machine и присваивает его movementSM, а также создаёт экземпляры различных состояний движения. При создании каждого из состояний движения мы передаём ссылки на экземпляр Character при помощи ключевого слова this, а также экземпляра movementSM. public override void Enter(). В конце мы передаем Standing в Initialize в качестве начального состояния.

public override void Enter()

{

base.Enter();

horizontalInput = verticalInput = 0.0f;

}

public override void Exit()

{

base.Exit();

character.ResetMoveParams();

}

public override void HandleInput()

{

base.HandleInput();

verticalInput = Input.GetAxis("Vertical");

horizontalInput = Input.GetAxis("Horizontal");

}

public override void PhysicsUpdate()

{

base.PhysicsUpdate();

character.Move(verticalInput * speed, horizontalInput * rotationSpeed);

}

В методе HandleInput переменные horizontalInput и verticalInput кешируют значения горизонтальной и вертикальной осей ввода, соответственно. Благодаря этому игрок может управлять персонажем при помощи клавиш W, A, S и D. В PhysicsUpdate мы выполняем вызов Move, передавая переменные horizontalInput и verticalInput, умноженные на соответствующие скорости. В переменной speed хранится скорость перемещения, а в rotationSpeed — угловая скорость.

public override void Enter()

{

base.Enter();

speed = character.MovementSpeed;

rotationSpeed = character.RotationSpeed;

jump = false;

}

public override void HandleInput()

{

base.HandleInput();

jump = Input.GetButtonDown("Jump");

}

public override void LogicUpdate()

{

if (jump)

{

stateMachine.ChangeState(character.jumping);

}

}

В HandleInput при нажатии Space состояние меняется на прыжок.

public override void Enter()

{

base.Enter();

SoundManager.Instance.PlaySound(SoundManager.Instance.jumpSounds);

grounded = false;

Jump();

}

public override void LogicUpdate()

{

base.LogicUpdate();

if (grounded)

{

character.TriggerAnimation(landParam);

SoundManager.Instance.PlaySound(SoundManager.Instance.landing);

stateMachine.ChangeState(character.standing);

}

}

public override void PhysicsUpdate()

{

base.PhysicsUpdate();

grounded = character.CheckCollisionOverlap(character.transform.position);

}

Внутри Enter синглтон SoundManager воспроизводит звук прыжка. Затем grounded сбрасывается на значение по умолчанию. В конце вызывается Jump. Внутри PhysicsUpdate точка Vector3 рядом с ногами персонажа отправляется в CheckCollisionOverlap, и это значит, что когда персонаж находится на земле, grounded будет присвоено значение true. В LogicUpdate, если grounded равно true, мы вызываем TriggerAnimation для включения анимации приземления, воспроизводится звук приземления, а movementSM.CurrentState изменяется на character.standing.

4.Заключение.

Подводя итог, можно вкратце сказать, что паттерн State – некий шаблон заранее прописанных состояний, в результате которых объект меняет свое поведение. Данный паттерн призван сделать более гибкой архитектуру систем, которые описывают подобные объекты и манипулируют ими. при использовании паттерна State вся программная логика, которая отвечает за его поведения в том или ином состоянии инкапсулирована в отдельные классы. Объект и его поведение в различных состояниях могут изменяться независимо друг от друга. Это обеспечивает высокую гибкость архитектуры и удобство при сопровождении программы и её модернизации. По вышеперечисленным причинам этот паттерн отлично подходит для создания объектов в GameDev.

5.Список литературы.

habr.com
refactoring.guru/ru
github.com
ru.wikipedia