Этот обзор посвящен проекту космического шутера, созданному начинающим разработчиком Unity на C#. Цель обзора – показать типичные ошибки начинающих и предложить пути их решения. Проект представляет собой космический шутер с базовой игровой механикой: управление кораблём, стрельба и сбор ресурсов.
Обзор игры
Игра, несмотря на простоту, типична для начинающих разработчиков. Игрок управляет кораблём, уничтожает врагов с простейшим ИИ, собирает ресурсы и взаимодействует с торговыми станциями (функционал покупки кораблей не реализован). Варп-перемещения между системами также отсутствуют. Игровая механика неудобна и неинтересна.
Анализ кода: Класс Player
Класс Player хранит состояние игрока, включая боезапас турели и другого оружия. Структура кода неудачна: поля, такие как timerOn, timerCoolDown, timerStep, следует вынести в отдельный класс Timer.
Описание ресурсов игрока занимает 83-93 строки – избыточно для нескольких полей. Отсутствует проверка на отрицательные значения. Вместо игнорирования, лучше использовать исключения или обрезку до 0. Многочисленные однотипные поля лучше заменить на тип uint (при отсутствии поддержки инспектора в Unity – создать сериализуемый класс).
Метод Awake создаёт корабль на основе строки, определяющей его тип. Отсутствует фабричный метод; создание корабля лучше вынести в статический метод класса Player. Боезапас описан отдельно для турели и другого оружия, несмотря на наличие отдельных классов для оружия – это дублирование кода.
Анализ кода: Класс Trader
В классе Trader наблюдается аналогичное дублирование кода при описании цены боеприпасов. Использование массива слайдеров неудобно и подвержено ошибкам. Некорректное использование слайдеров требует пересчёта значений, а магические числа увеличивают вероятность ошибок. Необходимо унифицировать терминологию (quantities и shells). Логику трейдера следует отделить от пользовательского интерфейса.
Использование файла FType избыточно и усложняет зависимости. Проверку наличия компонентов (Player) лучше проводить с помощью исключений. Рекомендуется использовать SerializeField для явного объявления типов и ручного назначения зависимостей, или контейнеры для автоматизации.
Анализ кода: Оружие и архитектура
Реализация оружия содержит ряд проблем: боезапас каждого оружия описывается отдельно в классах Player и Trader. Виртуальные методы Awake в классах оружия часто бесполезны. Дублирование кода в методах атаки – необходимо использовать абстрактные методы. Названия методов (Update) следует унифицировать.
Рекомендуется использовать шаблон проектирования «открыт/закрыт» для добавления новых видов оружия без изменения существующего кода. Стиль кода достаточно аккуратный, что важно для поддержания хорошей архитектуры, особенно на начальном этапе обучения. Использование делегатов и событий повысит эффективность кода.
Код написан аккуратно, учитывая опыт разработчика (2-3 месяца обучения). Некоторые проблемы связаны с недостаточным пониманием ООП и организации кода. Проект демонстрирует потенциал, и при наличии наставника разработчик быстро улучшит навыки. Проект подходит для позиции джуниор-разработчика.