Создать игру, которая цепляет и удерживает игроков — задача не из лёгких. Но что отличает шедевры от проходных проектов? Это не хук, не сюжет, не геймплейный цикл и даже не графика. Есть пять фундаментальных принципов, которые есть в каждой великой игре и которых не хватает неудачным. Я разберу эти принципы, используя примеры из AAA-игры Resident Evil 2 Remake и инди-проекта Thronefall, чтобы показать, как они работают на практике. Эти идеи помогут разработчикам, особенно инди, создавать игры, которые игроки захотят проходить до конца.

1. Напряжение: вызов, который держит в тонусе

Игрок должен чувствовать сопротивление — что-то, что заставляет его напрячься. Это может быть таймер, сложные враги, ограниченные ресурсы или даже механика движения. Без вызова игра становится пресной.

• В Resident Evil 2 напряжение создают ограниченные патроны, необходимость возвращаться назад и агрессивные враги, которые наступают на пятки. Каждый шаг — это риск.

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

Задайтесь вопросом: против чего борется игрок? Это может быть головоломка, таймер или даже нехватка ресурсов. Убедитесь, что в вашей игре есть вызов, который держит игрока в тонусе.

2. Влияние игрока: контроль имеет значение

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

Примеры:

• В Resident Evil 2 вы сами решаете, по какому коридору пойти, каких зомби атаковать, а каких обойти из-за нехватки патронов. Ваш выбор влияет на выживание.

• В Thronefall игрок решает, когда и где улучшать башни, размещать юниты или брать перки. Это напрямую определяет, выиграете вы ночь или проиграете.

Спросите себя: чувствует ли игрок контроль? Убедитесь, что каждое действие — прыжок, удар или выбор — имеет вес и последствия. Избегайте скриптов, где результат предрешён.

3. Понятность: что делать, ясно без слов

Хорошая игра сразу даёт понять, что нужно делать. Цели, инструменты и обратная связь должны быть очевидными. Понятность не значит простота — даже сложные игры могут быть интуитивными благодаря хорошему дизайну.

Примеры:

• В Resident Evil 2 понятность достигается через интерфейс, HUD и структуру уровней. Визуальные сигналы (например, походка персонажа) показывают, насколько вы ранены.

• В Thronefall всегда ясно, сколько стоят улучшения, откуда идут враги и где стоят юниты. Карта и интерфейс не заставляют гадать.

Задайте себе вопрос: поймёт ли новичок, что делать? Убедитесь, что обучение, интерфейс и визуальные подсказки делают игру доступной без лишних объяснений. Проверьте понятность на друзьях, знакомых или бета-тестерах.

4. Прогресс: ощущение развития

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

Примеры:

• В Resident Evil 2 прогресс — это открытие новых зон, оружия и ранее закрытых дверей. Сюжет меняет карту, добавляя или убирая препятствия.

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

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

5. Награда: удовлетворение от действий

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

Примеры:

• В Resident Evil 2 награды — это нахождение печатной машинки для сохранения, победа над боссом, открытие новой комнаты или получение патронов после решения головоломки.

• В Thronefall награда — это поток золота в конце ночи, который растёт с улучшением экономики. Это мотивирует улучшать башни и здания.

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

Применение на практике

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

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

Александр Антипин, студия Metabula Games.

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

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

ЧТО ТАКОЕ OCP

Что такое OCP - Программные сущности (классы, модули, функции и т.п.) должны быть открыты для расширения, но закрыты для изменения.

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

Реализация принципа Open/Closed в Unity

Прежде чем рассмотреть, реализацию принципа в Юнити, предлагаю посмотреть на то, как этот принцип нарушается. Часто разработчики нарушают принцип Open/Closed, добавляя новый функционал непосредственно в существующие классы. Например, рассмотрим сценарий игры, где игрок должен управлять своим кораблем. Изначально логика управления реализована следующим образом:

Теперь представьте ситуацию, когда нам нужно добавить некоторый дополнительный функционал, который должен работать по другому принципу. Например стрельбу.

Мы бы написали что-то вроде этого, и после добавили бы переменную Weapons в класс Player и вызвали бы в методе Update метод стрелять.

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

СОЗДАНИЕ ЕДИНОГО КЛАССА ДЛЯ ВСЕХ СУЩНОСТЕЙ

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

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

На смену переменной типа Movement, пришла переменная с типом IBehaviour. IBehaviour – это интерфейс который имеет всего лишь один метод OnUpdate(). Теперь наше общение с нашим классом поведенческого типа стала универсальным, так как теперь мы принимаем в качестве переменной не конкретный поведенческий класс, а интерфейс. Такой подход хорош для того что бы начать собирать наш класс контейнер. Однако, нужно помнить, что поведенческих классов может быть огромное количество и для каждого пришлось бы реализовывать свою переменную. Выгладило бы, это примерно вот так:

Но мы с тобой не дураки, и понимаем.. Что нам нужно реализовать массив типа List который будет содержать в себе все поведенческие типы которые нужны для работы той или иной сущности. Модифицируем наш класс Actor под наши задачи, а задача у нас простая. Реализовать контейнер поведений которые обрабатываются все в одном месте.

Теперь давайте посмотрим, на реализацию классов EnemyMovement и PlayerMovement.

Отлично, и теперь по такому же принципу мы можем изменить наш класс Weapons.

Итог

За счет того, что мы сделали методы OnEnable и OnDisable, у нас с вами появилась гибкость.

• В методе OnEnable - мы спокойно получаем доступ к нашему Actor и добавляем себя в массив.

• В методе OnDisable- мы спокойно получаем доступ к нашему Actor и убираем себя в массив.

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

Теги: #unitydev #gamedev #разработкаигр #unitycommunity #игрынасоздание #создайигру #учисьделатьигры #геймдев #индиразработчики #programming #design #graphics #gameart #unitylearning #beginnerswelcome #unitygames #unityengine #vkgamedev #русскоязычныеразработчики

#OpenClosedPrinciple #SOLID #SoftwareDesign #ProgrammingConcepts #Encapsulation #Extensibility #CodeMaintenance #Refactoring #OOP #CleanCode