Comments 24
Используйте пространства имен на C# и разбивайте свой код на ассемблеры на ранних этапах. Это обеспечивает более чистое разделение архитектуры и сокращает время компиляции в долгосрочной перспективе.А можно в числах? А то везде про это пишут, но я в своих проектах не вижу прям большой разницы при использовании Assembly Definitions.
Напишите в Unity плэймод-тесты игры и тесты интеграцииВот про это бы поподробнее.
Начните разработку игру с последней бета-версией UnityОчень спорный совет.
Не полагайтесь на PlayerPrefs. Сериализуйте вашу игровой конфиг со всеми настройками в простой текстовый формат.А что не так с PlayerPrefs?
Если вы не знаменитость с >10К фанатов, то спам об игре в Твиттере будет бесполезен. Хэштег #gamedev движется со скоростью несколько сообщений в секунду — скорее всего никого не будет волновать ни ваша игра, ни то, что вы недавно сделали#screenshotsaturday для некоторых весьма хорошо работает.
А что не так с PlayerPrefs?
Размер? Удобство редактирования?
А можно в числах? А то везде про это пишут, но я в своих проектах не вижу прям большой разницы при использовании Assembly Definitions.
Зависит от того насколько качественно разбили. Юнитеки пишут (емнип), что вы либо используете асмдефы по всему проекту, либо не используете вообще. В любом случае, важно понимать, что если вы меняете код в сборке, которую используют все остальные — пересобираться будут все, а не только она.
разбивайте свой код на ассемблеры
Assembly в .Net переводится как сборка.
Попробуйте делать меньше ООП. Держите все в изоляции, имейте меньше состояний. Обменивайтесь данными, а не объектами с состояниями и иерархиями.
Странный совет. Я бы наоборот, сказал, что делая игру — делайте больше ООП, потому что объектно-ориентированное моделирование (ECS или нет — это уже детали) обычно на игры ложится прекрасно.
Но важно помнить, что абстракции ООП не бесплатны, и вот тут-то как раз речь идёт о том, о чем в статье: не надо плодить тучи временных объектов, тут мигом можно убить и память и производительность (когда GC офигеет) разом.
Возможно имелся в виду component-based design. ООП в чистом виде можно использовать толко на уровне подсистем. Как не надо делать: класс типа Car с методами update/move/shoot (конечно же перегружаемыми для каждого под-класса). Смерть для производительности и потом очень сложно такое выкорчевать.
А как надо?
Entity Component System, полагаю. Например, в таком стиле https://habr.com/ru/post/343778/
Думаю, что тут про принцип "composition over inheritance"
Мне кажется, имеется в виду событийная система. Она не отрицает ООП, а по сути — является даже её более идеальным представителем, но самое главное — позволяет избавится от знания объектов о том, какие ещё объекты есть в коде. Учитывая, что в юнити зависимостей порождается ещё больше чем в любом другом коде(из за перелинковок со сценой и контроллерами, например), без системы сообщений у меня любой рефакторинг вызывал боль, поскольку приходилось менять поведение по цепочке в целой куче объектов.
ООП это самое большое зло для игр на Unity.
Там другая парадигма.
Совсем.
И чем быстрее забудете это аббревиатуру — тем быстрее сможете что-то сделать)))
Там другая парадигма.
Совсем.
И чем быстрее забудете это аббревиатуру — тем быстрее сможете что-то сделать)))
Согласен с большинством советов, но некоторые моменты спорные:
Автор предалагает хардкодить какие-то значения, которые можно задать в эдиторе? Или выность в какие-то отдельные файлы настроек? А ссылки как — через GetComponent<>? )
Если проект для мобил — сдается мне, что 2D будет все таки профитнее. Хотя лучше проверить и убедиться.
Попробуй Rider — он еще великолепнее. )
Постарайтесь определить как можно больше в коде, а не полагаться на Unity Editor или предварительную сериализацию. Когда вам понадобится что-то рефакторить, наличие множества вещей, соединенных в единые YAML-файлы, добавит вам проблем. Используйте редактор, чтобы быстро найти хороший набор значений в рантайме, затем впишите его в код и удалите [SerializeField].
Автор предалагает хардкодить какие-то значения, которые можно задать в эдиторе? Или выность в какие-то отдельные файлы настроек? А ссылки как — через GetComponent<>? )
Избегайте 2D физики Unity даже для 2D-игр. Постройте ее с 3D, и вы получите многопотоковый Nvidia Physx вместо менее производительного Box2D.
Если проект для мобил — сдается мне, что 2D будет все таки профитнее. Хотя лучше проверить и убедиться.
Используйте редактор кода, который показывает ссылки на классы, переменные и методы. Например, Visual Studio Code — он великолепен.
Попробуй Rider — он еще великолепнее. )
ну кстати для своего проекта в целом хороший прогресс (я про выводы), хотя некоторые конечно очень спорные )
Мне показалось противоречивым:
К тому моменту как займёшься именованием, покупкой доменов, настройкой аккаунтов и т.п, внезапно что-то запланированное тобой уже может быть занято, см. предыдущий пункт.
- Хорошо подумайте над финальным названием игры. Переименование позже может превратиться в полный кошмар.
- Назовите ваш проект кодовым именем. Не начинайте с именования, покупки доменов, настройки аккаунтов, покупки приложения Steam и т.д. Это можно сделать намного позже.
К тому моменту как займёшься именованием, покупкой доменов, настройкой аккаунтов и т.п, внезапно что-то запланированное тобой уже может быть занято, см. предыдущий пункт.
Я думал что с юнити игры делать проще, но сейчас вижу, что даже для 2д гонок нашлась целая куча проблем.
Неплохой набор моментов о которых стоит задуматься :)
Некоторые оч спорные это да, кажется некоторые хорошо ложатся на одиночную разработку и не подходят для студии :)
такие как этот:
А этот вообще оч хорош:
Хотелось бы узнать у автора какая боль ему встретилась что он такое предлагает:
Я например тут полностью несогласен. Тут сильно лучше встроить какой нить MVVM фреймворк, если нету своего, и никогда не не делать код зависимым от UI. Только UI зависимый от кода.
Некоторые оч спорные это да, кажется некоторые хорошо ложатся на одиночную разработку и не подходят для студии :)
такие как этот:
Постарайтесь определить как можно больше в коде, а не полагаться на Unity Editor или предварительную сериализацию. Когда вам понадобится что-то рефакторить, наличие множества вещей, соединенных в единые YAML-файлы, добавит вам проблем. Используйте редактор, чтобы быстро найти хороший набор значений в рантайме, затем впишите его в код и удалите [SerializeField].
А этот вообще оч хорош:
Подумайте о моддинге на ранней стадии. Разложите начальную архитектуру проекта так, чтобы вы могли построить ядро игры в виде мода или набора модов. Игровой контент должен быть «мягкой» архитектурой, он должен легко модифицироваться.
Хотелось бы узнать у автора какая боль ему встретилась что он такое предлагает:
Никогда не подключайте кнопки пользовательского интерфейса к редактору Unity Editor. Вместо этого используйте onClick.AddListener из кода.
Я например тут полностью несогласен. Тут сильно лучше встроить какой нить MVVM фреймворк, если нету своего, и никогда не не делать код зависимым от UI. Только UI зависимый от кода.
Имеется в виду не делать вызов методов через инспектор кнопки (там же можно перетянуть ссылку на монобех в специальное поле на кнопке, и указать какой метод вызвать и с какими параметрами). Вот так лучше не делать, как минимум потому, что потом программистам сложно отследить откуда идут вызовы, да и вообще зависимости строить сильно сложнее.
Я понимаю :)
И именно про это и сказал. MVVM как раз за то чтобы именно так и делать (настраивать вызов в инспекторе) и не иметь зависимости кода от UI. Только контролируемо.
Стандартный инспектор юнити не дает никакого контроля и да лучше его не использовать.
У на для этого свой компонент который делает это верно (с нашей точки зрения :))
он дает вызывать только методы которые явно в коде отмечены аттрибутом [Callable]
Программисты явно выдают методы для вызова из UI и код не зависит от того есть там кнопка в том UI или нет и вообще где она и сколько их. И может то вообще не кнопка а чекбокс который вызывает метод на включении… то уже дело UI.
И именно про это и сказал. MVVM как раз за то чтобы именно так и делать (настраивать вызов в инспекторе) и не иметь зависимости кода от UI. Только контролируемо.
Стандартный инспектор юнити не дает никакого контроля и да лучше его не использовать.
У на для этого свой компонент который делает это верно (с нашей точки зрения :))
он дает вызывать только методы которые явно в коде отмечены аттрибутом [Callable]
Программисты явно выдают методы для вызова из UI и код не зависит от того есть там кнопка в том UI или нет и вообще где она и сколько их. И может то вообще не кнопка а чекбокс который вызывает метод на включении… то уже дело UI.
ясно. Ну да, возможно. Мы больше придерживаемся MVC и вью подписывается на ивенты кнопки, а снаружи у нее торчат уже свои ивенты, на которые подписывается контроллер. В рамках этого чтобы задействовать инспектор пришлось бы делать контроллер монобехом, ну и снова — теряли бы возможность отследить связи
Sign up to leave a comment.
Вещи, которые я бы хотел знать до начала разработки собственной игры