Диаграммы прецедентов (Use case diagrams) - применяются для моделирования поведения системы, подсистемы или класса с точки зрения прецедентов (или вариантов использования).

Диаграммы прецедентов включают следующие элементы:

Прецеденты;

Участников (актеров);

Отношения зависимости, обобщения и ассоциации.

Прецедент , это описание множества последовательностей действий, выполняемых системой для того, чтобы актер (участник, исполнитель) смог получить опреде­ленный результат. Графическое отображение примера прецедентов приведено на рис. 3.5.6.1.

Рис. 3.5.6.1. Графическое отображение примера прецедентов в UML.

Участник (субъект, актер) - множество ролей, которые пользователи прецедентов исполняют при взаимодействии с ними. В качестве участника может выступать человек, устройство, другая программная система. Графическое отображение примера участников приведено на рис. 3.5.6.2.

Рис. 3.5.6.2. Графическое отображение примера участников в UML

Диаграммы прецедентов обычно применяются для решения сле­дующих задач:

Моделирование контекста системы, подразумевающего иденти­фикацию участников, взаимодействующих с системой, а также их ролей;

Моделирование требований – служит для определения функ­циональности системы со стороны внешнего наблюдателя, не рассматривая проблемы реализации функциональности.

Сущности, находящиеся вне моделируемой системы и взаимодей­ствующие с ней, составляют ее контекст. Важной задачей при модели­ровании контекста является идентификация сущностей, взаимодейст­вующих с системой, и их описание.

Моделирование системы необходимо проводить, следуя следую­щим этапам:

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

Рассмотреть и описать потоки событий для прецедентов отраженных на главной диаграмме прецедентов, а именно: предусловия, главный поток, подпотоки, альтернативные потоки, постусловия;

Организовать похожих участников с помощью отношений обобщения/специализа-ции;

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

Моделирование требований - это описание свойств и поведения системы, необходимых для осуществления проекта, не рассматриваю­щее механизмы реализации. Рабочая система должна выполнять все требования, изложенные в модели.

Моделирование требований к системе необходимо проводить, сле­дуя следующим этапам:

Установление контекста системы, идентификация окружающих систему участников;

Для каждого участника - рассмотрение поведения, которое он ожидает и требует от системы;

Именование выделенных вариантов поведения как прецедентов;

Выделение общего поведения в новые прецеденты, которые бу­дут использоваться другими;

Выделение вариации поведения в новые прецеденты, расширяющие основные потоки событий;

Моделирование выделенных прецедентов, участников, отноше­ний между ними на диаграмме прецедентов;

Дополнение прецедентов примечаниями, описывающими не­функциональные специфические требования к системе.

Моделирования диаграмм прецедентов на конкретных примерах приведены на рис. 3.5.6.3. и рис. 3.5.6.4.

Рис. 3.5.6.3. Графическое отображение прецедентов на примере обслуживания

абонентов сотовой телефонной связи.

Следует отметить дополнение прецедентов примечаниями, описывающими не­функциональные специфические требования, т.е.комментариями, которыми могут сопровождаться некоторые отношения между вариантами использования. Так, смысл отношения "include" состоит в том, что в данном примере «Подключение» включает в себя «Выбор оператора связи». Смысл же связи <> в том, что прецедент, например, «Рассмотрение анкеты» "расширяется" вариантом использования «Заключение договора». Это можно в данном случае объяснить тем, что «Заключить договор» можно только после проверки оператором анкеты. «Рассмотрение заявления» "расширяет" прецедент «Блокировка номера», «Замена sim-карты», «Детализация счета», «Замена абонентского номера». Таким образом, связь <> говорит о выполнении того или иного прецедента в зависимости от определенных условий.

Рис. 3.5.6.4. Графическое отображение прецедентов

на примере производственного участка.

Данные диаграммы прецедентов описывают участников при их взаи­модействии с системой на предприятиях.

Диаграмма прецедентов разрабатывается на этапе анализа основных процессов, которые под­держиваются средствами информационной системы.

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

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

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

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

Use Case описывает сценарий взаимодействия участников (как правило - пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

Мне нравится определение из книги Коберна (советую, ее, кстати, всем аналитикам): «Вариант использования фиксирует соглашение между участниками системы о ее поведении. Вариант использования описывает поведение системы при ее ответах на запрос одного из участников, называемого основным действующим лицом, в различных условиях».

В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовала диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:

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

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

Кому и в каких случаях нужны сценарии

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

- Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.

- Тестировщику. Почти готовый тест-кейс:-)

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

А также другим участникам процесса.

В каких случаях они нужны:

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

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

Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария. Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса. Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие - отклик системы», или даже совместить такую табличку со сценарием.

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Важные моменты

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

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

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

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

Перечитайте документ со сценариями, перед тем, как отдавать его разработчикам или заказчикам. Лучше даже несколько раз. Всегда находятся моменты, которые можно описать лаконичнее, или выявляются какие-то несоответствия. Или случайные «копипасты». Уважайте время и головы других людей.

Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а - это общее расширение к сценарию, не к конкретному.

Правильных и полезных вам сценариев! Вопросы, примеры, предложения, комментарии приветствуются. Спасибо за внимание.

При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

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

Назначение

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

При моделировании системы с помощью диаграммы прецедентов системный аналитик стремится:

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

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

Элементы

Для отражения модели прецедентов на диаграмме используются :

Отношения между прецедентами

Часть дублирующейся информации в модели прецедентов можно устранить указанием связей между прецедентами :

• обобщение прецедента - стрелка с незакрашенным треугольником (треугольник ставится у более общего прецедента),
• включение прецедента - пунктирная стрелка со стереотипом «include»,
• расширение прецедента - пунктирная стрелка со стереотипом «extend» (стрелка входит в расширяемый прецедент, в дополнительном разделе которого может быть указана точка расширения и, возможно в виде комментария, условие расширения)

Правила

При работе с вариантами использования важно помнить несколько простых правил:

• каждый прецедент относится как минимум к одному действующему лицу;
• каждый прецедент имеет инициатора;
• каждый прецедент приводит к соответствующему результату.

Напишите отзыв о статье "Диаграмма прецедентов"

Примечания

Отрывок, характеризующий Диаграмма прецедентов

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Введение

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

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

1.2 Алгоритмическое представление правил игры

1.3 Спецификация требований

1.4 Модель вариантов использования

1.4.1 Построение диаграммы прецедентов

1.5 Обзор инструментов разработки

1.6 Анализ аналогов

1.7 Выводы по главе

2. Проектирование игры

2.1 Модель проектирования

2.1.1 Архитектура игры

2.2 Разработка графического интерфейса пользователя.

2.2.1 Структура интерфейса

2.2.2 Главное меню

2.2.3 Экран игры

2.3 Реализация интерфейса в среде Unity

2.3.1 Главное меню

2.3.2 Экран игры

2.6 Выводы по главе

3. Разработка

3.1 Перемещение карт

3.2 Игровое поле игрока

3.3 Реализация алгоритма поведения компьютера.

3.4 Выводы по главе

Заключение

Библиографический список

ПРИЛОЖЕНИЕ A. Свойства базовой версии игры «Эволюция».

ПРИЛОЖЕНИЕ Б. Алгоритмическое описание правил игры.

ПРИЛОЖЕНИЕ В. Исходный код алгоритма поведения компьютера.

Введение

За последние 20 лет наблюдаются стремительные тенденции в развитии рынка видеоигр. Начиная свой путь от игровых автоматов, данная сфера постепенно охватила почти все цифровые устройства, которыми ежедневно пользуется каждый из нас: компьютеры, планшеты и мобильные телефоны. Помимо этого, существует также рынок настольных игр, который имеет значительное количество фанатов и интересных проектов. Исследования данной области показали, что около 62% людей, увлекающихся играми, предпочитают играть на компьютере, мобильном телефоне или планшете, около 14% любят играть в настольные игры в компании друзей, остальные 24%, предпочитают и то и другое . Данная разница в показателях говорит о потере интереса к настольным играм, что в свою очередь обусловлено следующими факторами:

· большинство людей не могут поиграть в настольную игру из-за отсутствия времени, места или необходимой компании, так как почти все настольные игры предназначены для игры от 2х до 4х человек;

· нет возможности попрактиковаться в одиночку и найти для себя новые выигрышные стратегии;

· коробка с настольной игрой может занимать много места, а некоторые карточки или фишки могут испортиться или потеряться.

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

В рамках выпускной квалификационной работы рассматривается настольная игра «Эволюция» - это симулятор развития жизни на Земле, основанный на дарвиновском принципе естественного отбора. Каждый игрок развивает собственную популяцию живых существ, наделяя их разнообразными свойствами -- приспособлениями к условиям окружающей среды.

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

В настоящее время существует большое количество различных инструментов для разработки компьютерных или мобильных игр. У каждого из них есть свои особенности, свои плюсы и минусы. Наиболее предпочтительным для реализации игры «Эволюция» оказался движок Unity, по причине его бесплатного распространения, огромного сообщества и возможности создавать кроссплатформенные игры на высокоуровневом языке программирования C#.

Объектом данного исследования является настольная игра «Эволюция», предметом исследования - разработка компьютерной версии данной игры с использованием игрового движка Unity.

Целью работы является разработка компьютерной версии настольной игры «Эволюция» на игровом движке Unity.

Для достижения данной цели необходимо выполнить следующие задачи:

1. Изучить правила настольной игры «Эволюция» и на их основе определить функциональные требования и описать сценарий использования.

2. Спроектировать архитектуру разрабатываемой игры.

3. Разработать дизайн игровых объектов и графический интерфейс пользователя.

4. Реализовать компьютерную версию игры на основе спроектированных моделей используя среду Unity.

На этапе анализа используются такие методы исследования, как абстракция и декомпозиция для представления объекта в виде системы. Для описания взаимодействия всех элементов системы используются объектно-ориентированный анализ и проектирование.

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

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

«Эволюция» -- это настольная игра, для компании от 2х до 4х человек, где каждый игрок развивает собственную популяцию живых существ, наделяя их разнообразными свойствами необходимыми для выживания. Свойства помогают животным в борьбе за пищевые ресурсы, запасы которых ограничены. Существа, которым не досталось пищи, погибают, а выжившие позволяют ввести в игру ещё больше животных и свойств. Победителем становится тот из соперников, чья популяция будет к концу игры самой развитой и многочисленной .

Животные и их свойства представлены в игре в виде карточек. Где с одной стороны изображен символ животного - ящерица, а с другой различные свойства, такие как: «Хищник», «Водоплавающее», «Симбиоз», «Норное» и т.д. Всего в базовой версии игры существует 19 различных свойств (см. Приложение 1). Каждая карта, лежащая на поле игрока символом животного вверх, является одним из его существ. Свойства подкладываются под животное, таким образом, что бы другим игрокам было видно какими свойствами оно обладает. На некоторых картах указано сразу два свойства: в таком случае игрок должен выбрать, каким из них он хочет наделить своё существо. Когда животное погибает от голода или становится съеденным другим животным со свойством «Хищник», оно вместе со всеми свойствами отправляется в сброс игрока.

Начало игры. Колода с картами перемешивается. Каждому участнику выдается по шесть карт. Партия длится несколько раундов, пока не закончатся карты в колоде. Каждый раунд состоит из четырех этапов:

? фаза развития;

? фаза определения кормовой базы;

? фаза питания;

? фаза вымирания и получения новых карт.

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

Фаза питания. Во время этого этапа игроки по очереди берут из кормовой базы одну фишку еды и используют на любое своё существо, которое ещё не накормлено. Для обычных животных необходима одна фишка еды красного цвета, чтобы оно считалось накормленными, но некоторые свойства увеличивают эту потребность. Также фишки еды можно получить, путем применения таких свойств, как «Хищник» или «Пиратство» в данном случае фишка дополнительной еды будет синего цвета. Накормленное животное не может получить новые фишки еды, кроме случая, когда на нем применяется свойство «Жирового запас», при действии данного свойства фишка еды красного цвета преобразуется в желтую фишку. Если все животные игрока накормлены и их «Жировой запас» заполнен, игрок больше не может брать фишки еды из кормовой базы или получать их в результате применения свойств. Однако если в кормовой базе остались фишки еды и у игрока еще есть ненакормленные животные или животные с незаполненным «Жировым запасом», он обязан брать фишки из кормовой базы. Когда все животные накормлены и их «Жировой запас» заполнен, либо закончилась кормовая база и игроки сыграли все свойства, которые хотели использовать в эту фазу хода - фаза питания завершается.

Рис. 1.1. Алгоритм игрового процесса.

Данная схема включает в себя следующие подпроцессы:

1. Инициализация. Содержит алгоритмы определения права первого хода и выдачи начального числа карт всем игрокам.

2. Фаза развития. Содержит алгоритм размещения карт на столе, в виде животных и их свойств.

3. Фаза определения кормовой базы. Содержит алгоритм определения количества фишек еды, которое будет доступно игрокам в «фазу питания».

4. Фаза питания. Содержит алгоритмы кормления и применения свойств животных.

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

6. Завершение игры. Данная схема содержит алгоритм подсчета очков и определения победителя.

Подробные схемы подпроцессов находятся в приложении Б. Алгоритмическое описание правил игры.

1.3 Спецификация требований

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

Бизнес требования:

? игра против компьютера;

? выбор количества игроков.

Функциональные требования:

Требования, предъявляемые к системе, с точки зрения правил игры:

? выдавать карты;

? хранить актуальную информацию о текущих картах на руках игроков и их животных со всеми свойствами, лежащими на игровом поле;

? рассчитывать очередность хода;

? определять и передавать право на первый ход;

? рассчитывать взаимодействие между различными свойствами;

? определять кормовую базу в расчете на количество игроков;

? помещать карты в сброс;

? хранить информацию о картах находящихся в сбросе игрока;

? считать итоговые очки и определять победителя;

Требования, предъявляемые к системе, с точки зрения игрока:

? начать новую игру;

? положить карту в виде животного;

? положить карту, как свойство;

? пропустить ход;

? взять фишку еды из кормовой базы;

? положить фишку еды на своё животное;

? активировать\ применить свойство;

? закончить игру.

1.4 Модель вариантов использования

1.4.1 Построение диаграммы прецедентов

Визуализация требований реализована с помощью use-case диаграммы (см. рисунок 1.2.).

Рис. 1.2. Диаграмма прецедентов.

1.4.2 Документирование прецедентов

Документирование прецедентов представлено ниже в таблицах (см . таблицы 1.1. - 1.15).

Таблица 1.1. Прецедент «Создать новую игру».

Таблица 1.2. Прецедент «Задать параметры».

Таблица 1.3.Прецедент «Сохранить игру».

Таблица 1.4.Прецедент «Продолжить игру».

Таблица 1.5.Прецедент «Закончить игру».

Таблица 1.6.Прецедент «Играть».

Таблица 1.7. Прецедент «Получить карты».

Таблица 1.8.Прецедент «Выиграть».

Таблица 1.9.Прецедент «Проиграть».

Таблица 1.10.Прецедент «Пропустить ход».

Таблица 1.11.Прецедент «Сделать ход».

Таблица 1.12.Прецедент «Положить карту в виде животного».

Таблица 1.13.Прецедент «Положить карту как свойство».

Таблица 1.14.Прецедент «Взять фишку еды».

Таблица 1.15.Прецедент «Применить свойство».

1.5 Обзор инструментов разработки

В качестве среды для разработки компьютерной игры «Эволюция» был выбран игровой движок Unity. Unity - это мультиплатформенный инструмент для разработки 2D/3D игр и интерактивного контента. На сегодняшний день доступна 5 версия движка, в которой реализованы все самые последние 3D и 2D технологии. Одной из таких технологий является UI System, которая содержит классы, значительно упрощающие работу с 2D элементами. . Данная технология наиболее подходит для создания игрового пространства и интерактивного интерфейса компьютерной игры «Эволюция». Базовый набор UI элементов и их назначение представлены в таблице 1.16.

Таблица 1.16. Базовый набор UI элементов в Unity.

Одной из главных особенностей игрового движка Unity является удобный и полностью настраиваемый интерфейс, который сочетает в себе редактор сцен, игровых объектов, скриптов, анимации, а также предоставляет возможность мгновенного запуска и отладки разрабатываемого приложения или игры . На рисунке 1.3. изображен скриншот окна редактора. Все ресурсы и объекты могут перемещаться при помощи Drag-and-Drop методов.

Рис. 1.3. Окно редактора Unity.

Ниже подробней описаны используемые вкладки окна редактора:

1. Scene View. В данном окне можно перемещаться по игровому миру, передвигать и вращать объекты сцены, а также изменять их масштаб.

2. Game View. Представляет собой изображение игрового мира, отрисованное из установленной камеры. Здесь можно посмотреть, как будет выглядеть игра для игрока. Также можно запустить и проверить игру.

3. Project Window. В данном окне можно работать со всеми ресурсами проекта: изображениями, шрифтами, скриптами, сохраненными объектами, сценами и т.д. Unity поддерживает огромное количество различных форматов мультимедии.

4. Hierarchy Window. Представляет собой иерархию игровых объектов расположенных на текущей сцене.

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

6. Toolbar. Содержит инструменты для трансформации игровых объектов в окне Scene View, Кнопки запуска и остановки приложения в окне Game View, выпадающее меню Layout которое отвечает за расположение окон в редакторе.

7. Console Window. Обеспечивает вывод в лог сообщений, предупреждений и ошибок.

Unity также обладает следующими преимуществами:

1. Открытость документации. Unity поставляется с полной документацией и примерами по каждой функции движка, к которой можно обратиться в любой момент.

2. Сообщество разработчиков. Unity обладает активным онлайн сообществом, готовым помочь новым пользователям. Также разработчики Unity Technology часто прислушиваются к пользователям и добавляют по их запросам новые функции в игровой движок. Кроме этого существует множество официальных и неофициальных видео-курсов помогающих разобраться с аспектами разработки игр на данном игровом движке .

3. Кроссплатформенность. Один и тот же код, написанный на движке Unity, с минимальными изменениями может быть перенесен на различные платформы (PC, Mac, Android, iOS, Web, игровые консоли). Это огромный плюс, который сокращает время на разработку игры в несколько раз.

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

В качестве инструмента для написания программного кода была выбрана среда Visual Studio 2015. В данной работе Visual Studio используется как лучшая альтернатива MonoDevelop, которая в игровом движке Unity представлена по умолчанию.

В качестве языка программирования был выбран высокоуровневый язык программирования C# .

1.6 Анализ аналогов

В ходе исследования предметной области был найден единственный на данный момент рабочий аналог компьютерной реализации настольной игры «Эволюция». Интерфейс данного аналога изображен на рисунке 1.4.

Рис. 1.4. Интерфейс пользователя игры-аналога.

Данный аналог обладает следующими преимуществами:

? доступен режим игры против 1го компьютера на 3х уровнях сложности. В данном варианте сложность проявляется в предоставлении «форы» компьютеру (компьютер отыгрывает один раунд без участия игрока, после этого присоединяется игрок);

? доступен режим по сети 1 против 1;

? доступен режим конструктора, где можно проверить взаимодействие различных свойств;

? понятный и интуитивный интерфейс пользователя, основанный на point-and-click;

? существует запись в журнал игрового процесса, всех ходов игрока и его соперника;

? возможность просмотреть код (массив содержащий параметры текущей игры: количество карт в колоде, очередность хода и список карт находящихся на руках у игроков);

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

Данный аналог обладает следующими недостатками:

? игра расположена в социальной сети «вконтакте» из-за чего отсутствует возможность играть без подключения к интернету;

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

Выделим основные критерии для сравнения аналога и разрабатываемой нами игры (см. таблица 1.17.):

1. Существует ли возможность запускать игру в оффлайн режиме против компьютера?

2. Присутствует ли возможность играть онлайн через интернет?

3. Правила игры соответствуют оригиналу игры?

4. Присутствует возможность выбора количества игроков?

5. Есть возможность изменить уровень сложности компьютера?

Таблица 1. 17. Сравнение критериев игры аналога и разрабатываемой игры.

По сложившимся результатам можно сделать вывод, что разрабатываемая игра будет улучшена в том плане, что она позволит играть без подключения к интернету. И будет присутствовать возможность выбора количества игроков, от 2 до 4х. Таким образом, данный анализ помогает выявить достоинства и недостатки игры аналога и оценить конкурентное преимущество разрабатываемой игры.

1.7 Выводы по главе

В результате анализа правил настольной игры «эволюция» был представлен алгоритм в виде блок схем, подробно описывающий этапы игрового процесса. Были разработаны функциональные требования, предъявляемые к системе с точки зрения правил игры. Построена диаграмма вариантов использования и описан основной и альтернативный порядок действий системы при инициализации прецедента игроком. Проведен краткий обзор возможностей и преимуществ игрового движка Unity. Рассмотрены плюсы и минусы найденного аналога и определены преимущества разрабатываемой игры.

2. Проектирование игры

2.1 Модель проектирования

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

алгоритм интерфейс файл пользователь

Таблица 2.1. Соответствие прецедентов и классов игры.

2.1.1 Архитектура игры

Визуализация игровой логики реализована с помощью диаграммы классов. Данная диаграмма состоит из двух частей: первая часть - это классы описывающие отображение игровых объектов, вторая часть классов описывает игровую логику. Данные классы связаны при помощи класса EvolutionGame отвечающего за игровой процесс и перехватывающий события с остальных классов системы. Диаграмма классов, представляющая архитектуру игры, показана на рисунках 2.1. - 2.3.

Рис. 2.1. Диаграмма классов. Часть 1.

Рис. 2.2. Диаграмма классов. Часть 2.

Рис. 2.3. Диаграмма классов. Часть 3.

2.2 Разработка графического интерфейса пользователя

2.2.1 Структура интерфейса

На основе данных полученных в результате анализа и проектирования была разработана структура графического интерфейса пользователя, которая содержит связи между основными экранами игры и модальными окнами, вызываемыми на этих экранах. Также данная диаграмма содержит наименования событий инициализирующих вызов этих окон. Структура интерфейса изображена на рисунке 2.4.

Рис. 2.4. Структура интерфейса.

2.2.2 Главное меню

Главное меню (см. рис. 2.5.) игры состоит из названия игры, фонового изображения и 3х кнопок: «Новая игра», «Продолжить игру» и «Выход». При нажатии на кнопку «Новая игра» открывается модальное окно настройки параметров игры (см. рис. 2.6.), которое содержит переключатели для выбора набора карт (базовый набор установлен по умолчанию и не доступен для выбора), выбор количества игроков, а также кнопку «Начать игру», при нажатии на которую загрузится игровое поле.

Рис. 2.5. Главное меню

Рис. 2.6. Окно задания параметров игры.

2.2.3 Экран игры

Экран игры состоит из 2х областей: фронтальной области и игрового поля. Фронтальная область (см. рис. 2.7.) содержит верхнее меню с кнопками: «Показать\скрыть игровой лог», «Сохранить игру», «Выйти в меню». Также в верхней части фронтальной области располагается окно с игровым логом, текстом уведомлений и информацией о текущей фазе в которой находится игра. Внизу фронтальной области располагается панель с картами, находящимися “на руках” у игрока. Данная панель может быть свернута и развернута по щелчку мыши. При двойном нажатии на любую карту животного оно масштабируется по центру экрана (см. рис. 2.8.).

Рис. 2.7. Фронтальная область.

Рис. 2.8. Подробный просмотр карты.

Игровой стол (см. рис. 2.9.) находится в 3D пространстве и содержит 2 области: игрока и соперника. Данные области служат для расположения карт животных и их свойств. Между данными областями находится кормовая база с фишками еды. Также на игровом столе располагаются кнопки выбора игроков, колода с указанием оставшегося количества карт, и кнопка «Сброс», при нажатии на которую открывается модальное окно содержащее карты животных, которые погибли в результате фазы вымирания.

Рис. 2.9. Экран игры. Игровой стол.

2.3 Реализация интерфейса в среде Unity

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

На основе спроектированного графического интерфейса в Unity было создано 2 сцены:

· «Menu» - представляет собой главное меню игры.

· «Game» - представляет собой игровое пространство, на котором непосредственно происходит весь игровой процесс.

Все сцены, так же как и любой другой ресурс сохраняются в папку Assets проекта и могут быть открыты в окне редактора. На рисунке 2.10. показаны сохраненные сцены проекта.

Рис. 2.10. Ресурсы проекта - игровые сцены.

Для захвата и отображения объектов в игровом пространстве используются камеры. Камера может быть установлена в двух режимах: ортографический и перспективный. При использовании ортографической камеры изображение объектов не уменьшается при увеличении дистанции. Данный режим используется для создания двухмерных и изометрических миров, во всех остальных случаях используется перспективная камера (см. рис. 2.11.).

Рис. 2.11. Настройки камеры в редакторе Unity.

Для создания игры было принято использовать систему UI игрового движка Unity. Все элементы UI располагаются на полотне (Canvas), которое определяет размещение 2D объектов в игровом пространстве. За это отвечает свойство Render Mode, которое содержит следующие значения:

Screen Space - Overlay. В данном режиме полотно масштабируется по размерам экрана и отрисовывается без связи со сценой или камерой (UI будет отрисован даже в том случае, когда на сцене нету камеры). В случае изменения размера окна, полотно будет растянуто под размеры экрана. Полотно будет рисоваться поверх всех остальных графических элементов.

Screen Space - Camera. В данном режиме полотно рисуется на плоскости перпендикулярной взгляду камеры, на некотором расстоянии от точки взгляда. Размер полотна не меняется с изменением расстояния, оно всегда масштабирется, чтобы заполнять разрез пирамиды видимости у камеры (camera frustrum view). Интерфейс будет заслоняться любыми 3D элементами, которые находятся перед плоскостью интерфейса.

World Space. В данном режиме полотно располагается в мировых координатах и является плоским 3D объектом.

2.3.1 Главное меню

На рисунке 2.12. показана сцена главного меню и иерархия объектов, расположенных на данной сцене. Полотно на котором располагаются UI элементы имеет свойство RenderMode с установленным значением Screen Space - Overlay. Такие элементы, как: ParamsWindow, ExitConfirm, ContinueGame - являются модальными окнами и по умолчанию находятся в неактивном состоянии.

Рис. 2.12. Сцена «Главное меню» и иерархия игровых объектов

MenuManager - пустой GameObject содержащий класс для управления меню.

Settings - пустой GameObject содержащий класс с настройками игры. Данный объект передается при загрузке сцены игры, чтобы иметь информацию о выбранных настройках.

2.3.2 Экран игры

На рисунке 2.13. показана сцена «Игровое поле» и иерархия объектов данной сцены. Элементы фронтальной области располагаются на полотне со свойством Render Mode равном Screen Space - Overlay, это означает, что отображение данных элементов не зависит от камеры. Игровое поле представляет собой полотно, расположенное в 3D пространстве и повернутое под углом 30 градусов относительно камеры. Для отображения данной сцены используется перспективная камера.

Рис. 2.13. Сцена «Игровое поле» и иерархия объектов сцены.

Общее представление сцены игры, то, как она выглядит для игрока показано на рисунке 2.14.

Рис. 2.14. Отладка сцены «Игровое поле».

2.4 Структура файла сохранения игры

Файл сохранения должен быть представлен в удобном для чтения программы формате и содержать информацию о всех текущих состояниях игры:

· текущие настройки игры;

· текущая фаза игры;

· текущее право хода;

· карты, находящиеся на руках у игроков;

· карты животных, находящиеся на столе у игроков;

· карты животных, находящиеся в сбросе у игроков;

· свойства и связи между животными;

· информация об использованных свойствах;

· информация о накормленных животных;

· количество фишек еды в кормовой базе;

· карты находящиеся в колоде.

Для описания данной информации наиболее подходящим является формат JSON. JSON (JavaScript Object Notation) - простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером . Примерное содержание файла изображено на рисунке 2.15.

Рис. 2.15. Структура файла сохранения игры.

2.5 Проектирование поведения компьютера

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

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

Подобные документы

Разработка компьютерной игры "Эволюция" с помощью игрового движка Unit. Сравнение критериев игры-аналога и разрабатываемой игры. Разработка графического интерфейса пользователя. Настройки камеры в редакторе Unity. Структура файла сохранения игры.

дипломная работа , добавлен 11.02.2017


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

курсовая работа , добавлен 09.11.2012


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

дипломная работа , добавлен 27.10.2017


История развития языка программирования Java. История тетриса - культовой компьютерной игры, изобретённой в СССР. Правила проведения игры, особенности начисления очков. Создание интерфейса программы, ее реализация в среде Java, кодирование, тестирование.

курсовая работа , добавлен 27.09.2013


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

методичка , добавлен 24.10.2012


Описание алгоритма хода ЭВМ в режиме "пользователь-компьютер" в игре "Морской бой". Описание совокупности классов, их полей и методов. Разработка интерфейса и руководства пользователя по проведению игры. Листинг программы, написанной на языке Java.

курсовая работа , добавлен 26.03.2014


Обоснование необходимости разработки программы для игры "Тетрис". Математическая и графическая части алгоритма. Выбор языка и среды программирования. Отладка текста программы, разработка интерфейса пользователя. Тестирование, руководство пользователя.

курсовая работа , добавлен 17.01.2011


Исследование общих правил игры в шашки, инструкции пользователя и программиста. Характеристика основных алгоритмов, исполняющих задачи класса Life Widget. Оценка ходов компьютера и человека. Построение дерева поиска лучшего хода исходя из оценки функций.

контрольная работа , добавлен 20.12.2012


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

курсовая работа , добавлен 03.12.2014


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