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

1.1 Описание целей и логики игры (аналог тз) (дата сдачи: 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.