[Перевод] Вещи, которые я бы хотел знать до начала разработки собственной игры

Последние два года я в свободное от основной работы время разрабатывал личный проект — игру, которую выпустил в Steam пару месяцев назад. На протяжении всего процесса я делал много ошибок, и вел записи для своего «прошлого я». Этот список может не относиться ни к вашей игре в частности, ни к вашему движку или языку (я использовал Unity и C#). Но я верю, что кому-то эти советы могут помочь. Поехали.

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

• Сделать сложную и отполированную игру, которую можно выпустить и даже иметь небольшой шанс на успех, будет в 100 раз сложнее, чем вы можете представить. Я не преувеличиваю.
• Используйте правильную шкалу единиц с самого начала, особенно если у вас есть физика в игре. В Unity, 1 единица = 1 метр. Неправильный масштаб сделает вашу физику странной.
• Спрайты должны быть сделаны и импортированы с согласованным размером, DPI, PPU.
• Убедитесь, что спрайты — это POT. Либо упакуйте их в атласы.
• Включите кранч сжатие на всех спрайтах, где можете (POT + кранч может легко превратить 1,3 Мб в 20 Кб)
• Создайте UI из компонентов, которые можно реюзать.
• Последовательно назовите UI-компоненты, чтобы их было легко найти.
• Сделайте гайд по стилю игры на ранних этапах.
• Используйте пространства имен на C# и разбивайте свой код на ассемблеры на ранних этапах. Это обеспечивает более чистое разделение архитектуры и сокращает время компиляции в долгосрочной перспективе.
• Никогда не используйте magic strings или string constants. Если вы печатаете строки в сериализованных полях Unity Editor, которые позже будут где-то использоваться для идентификатора — остановитесь. Используйте перечисления.
• Выделите большие непрерывные сеансы на свою игру. 2 цельных часа гораздо продуктивнее, чем 4 раза по 30 минут.
• Дизайн не должен быть частью прототипа. Не пытайтесь сделать его красивым, вам все равно придется его выбросить.
• Не тратьте время на создание арта (если, конечно, это не ваша основная цель). Если вы знаете, что он все равно будет выглядеть дерьмово, как бы вы ни старались, то сосредоточьтесь на том, что вы умеете лучше. Позже вы научитесь арту, или найдете коллегу в команду, кто сделает это за вас.
• Избегайте public static в C#.
• Попробуйте делать меньше ООП. Держите все в изоляции, имейте меньше состояний. Обменивайтесь данными, а не объектами с состояниями и иерархиями.
• Избегайте больших классов и методов любой ценой. Разделите обязанности, и cделайте это на ранних этапах. 300 строк, скорее всего, слишком много для класса, 30 строк, безусловно, слишком много для одного метода.
• Организуйте арт также, как вы организовываете код. Он должен быть четко и логически разделен, иметь пространство имен и правила по неймингу.
• Не просто копируйте и слегка модифицируйте код из других ваших игр — создайте общую библиотеку вещей, которые могут быть использованы позже.
• Если вы используете ScriptableObjects, они могут быть легко сериализованы в JSON. Это полезно для включения моддинга.
• Подумайте о моддинге на ранней стадии. Разложите начальную архитектуру проекта так, чтобы вы могли построить ядро игры в виде мода или набора модов. Игровой контент должен быть «мягкой» архитектурой, он должен легко модифицироваться.
• Если вы планируете сделать онлайн-мультиплеер — внедряйте его с 1—го дня. В зависимости от типа игры и вашего кода, добавление мультиплеера поверх готового проекта будет варьироваться от сверхтяжелого до почти невозможного.
• Не давайте ранние незавершенные версии игры стримерам и инфлюенсерам. Иначе эти геймплейные видео еще долго будут вас преследовать.
• Растите сообщество в Discord и Reddit.
• Сделайте сборки для всех ОС (Win, Linux, Mac).
• Прекратите тестировать игру после каждого изменения или давать сборки с ошибками вашему сообществу. Напишите в Unity плэймод-тесты игры и тесты интеграции: они могут играть в вашу игру на 100-кратной скорости и находить ошибки.
• Назовите свои GameObjects также, как вы называете свои классы MonoBehaviour. Или сделайте последовательные названия, чтобы было проще их искать. Да, вы можете использовать поиск, но хорошо названная иерархия игровых объектов намного лучше.
• Постройте надежную систему UI заранее, а затем используйте ее для построения всей игры. Сделать гибкий пользовательский интерфейс очень сложно.
• Никогда не подключайте кнопки пользовательского интерфейса к редактору Unity Editor. Вместо этого используйте onClick.AddListener из кода.
• Постарайтесь определить как можно больше в коде, а не полагаться на Unity Editor или предварительную сериализацию. Когда вам понадобится что-то рефакторить, наличие множества вещей, соединенных в единые YAML-файлы, добавит вам проблем. Используйте редактор, чтобы быстро найти хороший набор значений в рантайме, затем впишите его в код и удалите [SerializeField].
• Не используйте публичные переменные. Если вам нужно выставить частную переменную в Unity Editor, используйте [SerializeField].
• Будьте последовательны в именования и организации кода.
• Не срезайте углы и не идите на компромиссы по самым важным и сложным частям игры — основной механике, процедурной генерации, управлению и т.д. Вы пожалеете об этом позже. Под «срезанием углов» я имею в виду неаккуратное обращение с кодом, многократное копирование-вставка некоторых вещей, написание длинного метода с большим количеством if заявлений и т.д. Все это будет очень мешать при рефакторинге.
• Хорошо подумайте над финальным названием игры. Переименование позже может превратиться в полный кошмар.
• Назовите ваш проект кодовым именем. Не начинайте с именования, покупки доменов, настройки аккаунтов, покупки приложения Steam и т.д. Это можно сделать намного позже.
• При выполнении процедурной генерации, визуализируйте каждый шаг процесса, чтобы понять и проверить его. Если вы будете делать предположения, то ошибки все испортят. А отладка без визуализации станет кошмаром.
• Установить шрифты TextMeshPro по умолчанию.
• Не используйте iTween. Используйте LeanTween или другое производительное решение.
• Избегайте 2D физики Unity даже для 2D-игр. Постройте ее с 3D, и вы получите многопотоковый Nvidia Physx вместо менее производительного Box2D.
• Используйте Debug.Break() для перехвата странных состояний и их анализа. Очень хорошо работает в сочетании с тестами.
• Делайте сборки как можно быстрее. Инвестируйте время, чтобы понять, где у сборок узкие места — сэкономите больше в долгосрочной перспективе. Например, вам не нужно компилировать 32К шейдерных варианта на каждой сборке. Используйте предварительно загруженные шейдеры, чтобы получить значительное ускорение (Edit > Project Settings > Graphics > Shader Loading).
• Сделайте все элементы пользовательского интерфейса префабами.
• Избегайте LayoutGroup и всего, что вызывает восстановление Canvas, особенно в методе Update, и особенно если вы планируете перенести игру на консоли.
• Начните разработку игру с последней бета-версией Unity. К тому времени, как вы закончите, эта бета-версия будет стабильной и устаревшей.
• Ассеты из Asset Store следует называть Liabilities. Чем меньше вы используете, тем меньше у вас будет проблем.
• Используйте Unity Crash Reporting. Вам не придется просить людей присылать логи. Спросите их ОС, видеокарту, и найдите отчеты о сбоях с логами в онлайн панели управления.
• Повышайте версию приложения каждый раз, когда делаете сборку. Это должно быть сделано автоматически. Очень полезно в сочетании с Unity Crash Reporting — вы будете знать, если новые сборки получат старые проблемы. А когда что-то приходит со старой версии, вы будете знать, что это не платные пользователи, а пират со старой копией игры.
• Очаровательный динамический UI не стоит того. Сделайте пользовательский интерфейс простым и удобным. Никогда не используйте диагональные компоновки, если не хотите пройти через мир боли.
• Если вы строите игру, в которой ИИ будет использовать вход на основе PID-контроллера (виртуальный джойстик), сначала разберитесь с обработкой и управлением — и только потом начните работать с ИИ. Иначе придется переписывать его каждый раз.
• Используйте редактор кода, который показывает ссылки на классы, переменные и методы. Например, Visual Studio Code — он великолепен.
• Множество примеров кода, которые можно найти в интернете, абсолютно ужасны. Его можно переписать, чтобы он был намного короче и/или более производительным. Например, Steamworks.NET.
• Непринятые исключения внутри корутинов Unity приводят к крашам, которые невозможно отладить. Все, что работает в корутине, должно быть абсолютно пуленепробиваемым. Разделите корутины на подметоды, обработайте там исключения.
• Постройте систему управления корутиной. Вы должны знать, какие корутины работают в настоящее время, как долго, и т.д.
• Сделайте фотомод на ранней стадии. После этого вы легко будете делать красивые скриншоты и материалы для трейлеров.
• Постройте себе консоль разработчика. Пробовать что-либо быстро и без необходимости строить UI — это фантастика. А игроки смогут использовать консоль для модификации/читов и т.д.
• Не полагайтесь на PlayerPrefs. Сериализуйте вашу игровой конфиг со всеми настройками в простой текстовый формат.
• Никогда не тестируйте более 1 изменения за раз.
• Не вставайте в 4 утра, чтобы поработать над игрой. Не кранчите, отдыхайте и делайте физические упражнения. Хорошо питайтесь (максимизируйте потребление белка, избегайте углеводов и жиров — это худшее). Не убивайте себя, чтобы сделать игру.
• Если вы не знаменитость с >10К фанатов, то спам об игре в Твиттере будет бесполезен. Хэштег #gamedev движется со скоростью несколько сообщений в секунду — скорее всего никого не будет волновать ни ваша игра, ни то, что вы недавно сделали. Лучше займитесь разработкой.