Анализ предметной области - Porosenok-Petr/THE-SHAKE-GAME GitHub Wiki

1. ВВЕДЕНИЕ

Многие из нас помнят игру детства на кнопочном телефоне - «Змейка». Суть данной игры заключается в том, чтобы направлять змею по полю и кормить ее яблоками, пока она в это время растет в размерах. Задачей было не врезаться в стены или в саму змею, пока она, разрастаясь в размерах, передвигается по полю. Наша команда разработчиков «Ядовитый синтаксис» решили создать ремастер данной игры с пересмотром графики и геймплея под современный лад, сохраняя классический стиль оригинальной игры. Разработка данной игры нацелена на закрепление теоретических знаний на практическом опыте и выполнение задания от преподавателя.

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

Задачи:

Собрать команду разработчиков для создания данной игры
Распределить обязанности разработки для каждого члена команды
Написать техническое задание
Проанализировать предметную область
Спроектировать архитектуру ИС
Создать геймдизайн
Разработать игру в Unity
Провести тестирование
Защитить проект

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

2. АНАЛИЗ ТРЕБОВАНИЙ

2.1. Анализ существующих решений В ходе предпроектного анализа были рассмотрены референсные реализации классической игры «Змейка», представленные как в консольной версии (Nokia 3310), так и в современных веб- и мобильных имплементациях (Google Snake, Slither.io и др.).

Выявленные особенности: • Архитектура: Большинство решений использует событийно-ориентированный подход с циклом обновления состояния (game loop) и двойной буферизацией для отрисовки. • Алгоритмы: Перемещение змейки реализовано на основе связанных списков или кольцевых буферов, что обеспечивает константную сложность O(1) при добавлении новой головы и удалении хвоста. • Недостатки: В устаревших реализациях наблюдается жесткая привязка к частоте кадров (FPS), что приводит к неравномерной скорости движения. Современные аналоги зачастую перегружены графическими эффектами, что снижает их ценность как дидактического материала для изучения чистой логики.

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

Управление: Обработка дискретных команд пользователя (клавиши-стрелки или WASD) для изменения направления движения змейки на 90 градусов относительно текущего вектора.
Механика движения: Автоматическое перемещение сегментов змейки с заданной дискретностью (по пикселям или ячейкам сетки).
Генерация объектов: Случайная генерация объекта питания («яблока») в свободной ячейке игрового поля.
Обработка коллизий: • Поглощение объекта питания (увеличение длины змейки, инкремент счета, генерация нового объекта). • Проверка столкновения головы с границами поля (стенами) или собственным телом (условия завершения игры).
Подсчет очков: Визуализация текущего количества очков (длины змейки).
Сохранение состояния: Фиксация рекордного результата (high-score) в энергонезависимой памяти.

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

Производительность: Частота обновления игрового состояния (тиков) должна быть стабильной и не зависеть от колебаний аппаратной производительности (достигается путем привязки к таймеру, а не к FPS).
Эргономика (UX): Время отклика на нажатие клавиши не должно превышать 100 мс. Интерфейс должен быть минималистичным, исключающим когнитивную перегрузку пользователя.
Переносимость: Кроссплатформенность (для веб-версий) или независимость от разрешения экрана (адаптивная верстка игрового поля).
Модульность: Архитектура приложения должна разделять логику игры (ядро), ввод данных (контроллер) и рендеринг (представление) для упрощения дальнейшего расширения функционала.

2.4. Моделирование данных Информационная модель системы описывается следующими сущностями и структурами данных:

• Игровое поле (Grid): Двумерный массив (матрица) размерностью N x M. Каждая ячейка может находиться в одном из состояний: EMPTY, SNAKE_BODY, FOOD. • Змейка (Snake):  Структура данных типа «очередь» (Queue) или дек. Элементы содержат координаты сегментов (x, y).  Направление движения (Direction): перечисление (enum) со значениями {UP, DOWN, LEFT, RIGHT}. • Игровой цикл (Game State):  Состояние игры  Текущий счет  Рекорд 2.5. Ограничения и допущенния. Проектирование системы осуществляется с учетом следующих ограничений и допущений:

Допущения: • Игровое поле имеет прямоугольную форму и замкнутые границы (стены). • Еда не может генерироваться на теле змейки (гарантируется алгоритмом поиска пустой ячейки). • Ввод пользователя корректен (не рассматриваются варианты одновременного нажатия двух противоположных клавиш, управление линейно).
Ограничения: • Отсутствие многопользовательского режима (проект ограничен одиночным прохождением). • Отсутствие процедурной генерации уровней (размер поля статичен). • Проект не предполагает использования сложных физических движков, полагаясь на математическую модель дискретной логики.

2.6. Риски При разработке системы, функционирующей в дискретном пространстве состояний и включающей модули ввода, логики и визуализации, следует учитывать ряд факторов, способных оказать критическое влияние на устойчивость работы приложения либо привести к некорректному поведению игровых объектов. В данной работе выделены следующие категории потенциальных рисков. Во-первых, существуют логические риски, связанные с обработкой пользовательского ввода. Поскольку изменение направления движения змейки осуществляется дискретно, существует вероятность возникновения коллизии, при которой игрок инициирует разворот на 180 градусов относительно текущего вектора движения. В случае отсутствия валидации ввода данное действие приводит к мгновенному столкновению головы с собственным телом, что является невалидным игровым состоянием, противоречащим классическим правилам. Митигация данного риска реализуется на уровне контроллера путем фильтрации команд, противоположных текущему направлению. Во-вторых, в процессе генерации объектов питания на двумерной матрице поля возникает риск вычислительной неэффективности, граничащий с отказом системы. При высокой степени заполнения поля сегментами змейки алгоритм случайного выбора координат может совершать неограниченное количество итераций в поисках свободной ячейки. Теоретически, при заполнении N-1 ячеек из N, вероятность нахождения свободной ячейки методом случайной выборки стремится к нулю, что создает угрозу бесконечного цикла. Для предотвращения данной ситуации вводится детерминированный подсчет свободных ячеек либо ограничение числа попыток с последующей фиксацией состояния «победа» (заполнение поля). В-третьих, необходимо учитывать технические риски, связанные с визуализацией (рендерингом). В системах, где частота обновления логики привязана к частоте кадров, наблюдается нестабильность скорости перемещения змейки на различных устройствах. Кроме того, отсутствие синхронизации между обновлением состояния модели и отрисовкой может привести к артефактам изображения (разрыву кадра). Данный риск сглаживается применением паттерна фиксированного временного шага (fixed timestep), при котором состояние игры обновляется с постоянной частотой, независимой от частоты кадра. Наконец, в контексте программной реализации присутствуют риски, связанные с внешними зависимостями. При использовании основы или графических библиотек существует вероятность несовместимости версий, что может привести к ошибкам компиляции или выполнения. Данный риск минимизируется путем строгой спецификации версий в конфигурационных файлах проекта и применения изолированных сред разработки (виртуальных окружений), что обеспечивает воспроизводимость сборки.