Описание целей и логики игры (аналог ТЗ) (дата сдачи: 17.09)

Этапы выполнения курсового проекта

Результатом выполнения данного пункта является подробное описание того, что должно получиться на выходе курсового проекта. Необходимо в свободной форме описать что будет представлять из себя игра, и что можно будет делать в этой игре. Рекомендуется расписать все требования по пунктам. Рекомендуемый объем: не менее одной страницы А4.

Пример _очень_краткого_описания_:

Игра будет представлять из себя двухмерный шутер, где главной целью игрока будет добраться до конца уровня собирая бонусы и избегая врагов. Игра будет написана с использованием Vulkan API и будет работать как на Windows, так и на Linux.

1. Наличие не менее 4х разных уровней

2. Возможность сохранения результатов игры (таблица рекордов)

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

4. Количество типов противников не менее 4

5. Количество типов собираемых бонусов не менее 2

6. Меню настроек

7. Выбор уровня сложности

8. Наличие ИИ у противников

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

1.2 Чтение информации о паттернах проектирования (дата сдачи: 01.10)

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

1.3 Описание модулей игры (дата сдачи: 01.10)

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

Например, типичная игра содержит следующие модули: главное окно; event-handler; input-handler; объекты игры; журнал событий; модуль настроек; модуль логики; модуль отрисовки; модуль данных и т.д. Этот набор модулей не обязательный и каждый вправе создавать свой собственный набор. Модули будут общаться между собой через так называемые интерфейсы, о которых будет сказано в 4ом пункте. Лучше стараться сделать большое количество модулей, которые не имеют перекрестных связей. Примером перекрестных связей может быть указатель внутри класса одного модуля на класс из другого модуля, по которому дергается этот класс. Такой код называется «Код прибитый гвоздями» и его очень тяжело тестировать и вносить изменения. В идеале, модуль можно выдрать из проекта и вставить в другой проект и он будет работать – именно к такой архитектуре модулей следует стремиться. Внутри каждого модуля описать классы, которые планируется реализовывать в этом модуле и их методы. Чем больше будет продумано на этом этапе, тем легче будет идти разработка. Описание модулей и классов лучше делать используя UML.

1.4 Описание интерфейсов модулей (дата сдачи: 15.10)

После того как список модулей был выбран нужно определить интерфейсы этих модулей – как они будут взаимодействовать между собой. Интерфейсы это обычные абстрактные классы (в терминологии C++), которые начинаются с заглавной буквы “I”, например: IGame, ILogic, IJournal, IEvenHandler и т.д. От этих интерфейсов наследуется реальный класс, который имплементирует все виртуальные функции интерфейса. Проектирование интерфейсов – очень важная и ответственная задача. Как правило, интерфейсы проектируется один раз и на очень долгое время, а реальные объекты за интерфейсами могут меняться. Например пусть у нас есть интерфейс IJournal, в котором есть метод save( );, который где-то сохраняет журнал. За интерфейсом мы понятия не имеем какой на самом деле стоит журнал, это может быть FileJournal, NetJournal, DBJournal и вообще, что угодно. Главное чтобы класс, который наследуется от интерфейса определил у себя функцию save() иначе, интерфейс не будет работать.

1.5 Выбор паттернов проектирование и наложение на архитектуру (дата сдачи: 29.10)

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

1.6 Написание тестов на интерфейсы и модули (дата сдачи: 12.11)

Начинать написание тестов следует с интерфейсов. Создается класс-пустышка (в терминологии фреймворка тестирования google: Mock - объект), который пытается описать как должен вести себя реальный класс. Этот класс-пустышка наследуется от интерфейса и пытается имитировать работу всех его методов, чтобы это было похоже на то, как будто за интерфейсом находится реальный объект. Такое поведение сделать достаточно просто, т.к. пользователь интерфейса не видит всего что должно происходить в реальном объекте и может контролировать только ограниченный набор данных, которые предоставляет интерфейс. Например, вызвав метод интерфейса, который называется int getSceneObjectsCount(), тот, кто вызвал этот интерфейс, ожидает что этот метод вернет какое-то положительное число или бросит исключение, если сцена отсутствует.

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

После того как созданы все Mock-объекты, Необходимо написать тесты на все методы в интерфейсах. Эти тесты в начале будут не работать, т.к. реальные объекты еще не созданы и по мерее наполнение классов реальным кодом, количество пройденных тестов будет увеличиваться.

Если для написания игры будет использоваться язык C++, рекомендуется использовать тестирующий фрейворк от google: googletest

1.7 Наполнение модулей игры и демонстрация результатов (дата сдачи: 10.12)

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

1.8 Пояснительная записка (дата сдачи: 24.12)

Пункты:

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

2. Описание правил игры

3. Описание структуры программы

3.1 Модули игры

3.2 Интерфейсы игры

4. Диаграммы классов

5. Использованные паттерны проектирования

6. Руководство пользователя

Заключение

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

Приложение

Объем пояснительной записки не менее 15 страниц, не включая титульный лист. Диаграммы классов необходимо сделать используя UML. Для автоматической генерации UML рекомендуется использовать Doxygen.