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

Нашел идеальную фразу, для проверки шрифта. Тут все 33 буквы.

"Эй, жлоб! Где Туз? Прячь юных съёмщиц в шкаф"

Не благодарите.

Про плохую практику возвращать null из методов. Разберем на примере.

Если метод, например, имеет такую сигнатуру:

QuestData GetQuestData(string questId)

Вы, когда его вызываете совершенно не рассчитываете получить null. Но бывает, что метод при этом может вам его вернуть не показав ошибки или не упав. Не зная этого вы растиражируете это значение по коду и упадете неизвестно где. И от этой рандомной точки нужно будет вернуться к этому методу в обратном направлении затратив время на поиск ошибки. Это потеря времени просто, чтобы узнать, что например, ошибка в данных и такого questId не существует.

Плохая реализация выглядит так:

QuestData GetQuestData(string questId)
{
 if (_quests.TryGetValue(questId, out QuestData data))
return data;

return null;
}

Если у вас один такой метод или малый проект, то это особо может и не страшно (но точно неудобно). Те кто не обращают на такие мелочи внимание, далее как правило накручивают еще больше подобных методов и неустойчивость кода растет очень быстро.

Это плохо в первую очередь потому, что ошибка происходит, но делает это втихую — не сообщая ничего. Во-вторых заставляет вызывающий код делать проверки вида if (questData != null) везде где этот метод вызывается, а это повсеместный мусор. И, конечно, замедляет разработку.

Реализация чуть лучше:

QuestData GetQuestData(string questId)
{
 if (_quests.TryGetValue(questId, out QuestData data))
return data;

throw new Exception("Quest id '{questId}' not found.")
}

Тут мы уже узнаем, что у нас ошибка в данных. Внешние проверки результата уже не нужны — это хорошо. Но это все еще плохо потому, что в реальности ошибка скорее всего должна быть известна, но не ломать игру.

Хорошая реализация:

bool TryGetQuestData(string questId, out QuestData data)
{
 return _quests.TryGetValue(questId, out data);
}

Почему хорошо:
- Понятность, вам не придется ловить null непонятно где. Внешний код уже по сигнатуре метода знает, что данных может не быть, значит обработает это корректно (например, отправит ошибку в аналитику, выведет лог и не будет ломаться на попытке запустить этот квест в игре).

- Вы не тратите время и мысленно не "спотыкаетесь" когда пишите код, при работе с подобными методами. Это дает скорость в работе. Вам не надо заходить в методы и проверять их реализацию. Такая фобия может развиться, стоит вам найти 3-4 метода в проекте, которые почему-то неявно возвращают null.

- Например, у вас из 1000 есть целых 10 не валидных questId, которые вы передаете в метод. В варианте с возвращением null или throw new Exception — вам надо будет 10 раз запустить игру, чтобы их найти. В варианте, где вы очевидно обрабатываете отсутствие данных и, например, выводите лог, то вы узнаете все 10 неверных questId за один запуск. Это снова экономия времени.

- Делает код чище и проще. Меньше лишних проверок, меньше строк и снова буст к простоте проекта и скорости разработки.

#техничка@cat_and_code
Поддержите автора лайком или отправьте пост другу
Предложить тему для поста

Комментарий в рабочем легаси коде, который ОЧЕНЬ предостерегает

Достаточно активный срач содержательная дискуссия была под постом про TryGet. Мне понравилось. Я в ней поделился советом, у которого образовались и противники и согласные.

И я тут подумал, может у тебя лично, дорогой подписчик, тоже есть какой-то свой совет, который ты считаешь важным? Или какой-то приём/подход, который ты хотел бы проверить на прочность? Может быть тебе интересно узнать, на сколько он спорный и что об этом думают другие?

Предлагаю такую штуку — желающие поделиться могут написать мне в ЛС, изложить свой совет/рекомендацию удобным способом, я оформлю вашу мысль, подготовлю пост и опубликую на канале. Вам возможность понаблюдать со стороны, не вступая в дискуссию лично (или наоборот с указанием авторства вопроса). Желающим критиковать, шутить и троллить — широкое поле для деятельности, велком. Остальным польза в виде разных мнений на вопрос.

Новости из страны инди разработки. Singletone понемногу преображается.

Сейчас этап создания основных механик, но совсем без контента очень сложно принимать решения по развитию визуала. Добавился URP, чтобы художник мог играться с эффектами и начать формировать наш стиль. Тестовая модель нпс тоже показала, что высоко полигональные персонажи нам не пойдут. Мы не собираемся все выводить под стиль PS1, но тем не менее от реализма мы будем далеко, а к конструктивизму и авангарду 20 века — близко.

Пока, то что на видео это еще даже не попытка в визуал, а первые черновые этапы. Модель — это Петр с Mixamo и диалог написанный по инициативе Copilot (все-таки нейронки что-то знают).

В общем у кого тоже проекты на ранних этапах, как у вас идет? Не пасуйте перед количеством работы? Я видел на других каналах иногда делаются посты, типа "скриншот прогресса". Чтобы в комменты все желающие могли накидать прогресс по своему проекту за последнее время и подбодриться (или погрустить вместе, тут как повезет). Есть у нас тут что-то делающие и желающие делиться прогрессом? Думаю может тоже сделаем такую рубрику.
#девлог@cat_and_code

Давно не было чего-то из рубрики #техничка@cat_and_code

Недавно я вспомнил об очень простой штуке, которая иногда бывает просто незаменима в отладке. Все же пользуются Debug.Log(...) + красный и желтый вариант. А вот про Debug.Break() часто почему-то не в курсе.

Строчка ставит Unity на паузу в момент вызова. Категорический полезна, когда вы пытаетесь найти капризный кейс в нужный кадр. При брейкпоинте в IDE можно посмотреть значения переменных в коде, а тут значения в компонентах и обстановку на сцене.

Пример использования:
Тестирую систему динамического респауна персонажа. Нельзя заранее назначить безопасную точку респауна, она все время обновляется и вычисляется. Обстановка в уровне может меняться, в данном случае корабль качается на волнах. Поверхность может быть ниже или выше изначальной желательной точки. Есть алгоритм, который все это рассчитывает и вычисляет новую позицию. Вызов Debug.Break() в момент спауна позволяет визуально оценить работу алгоритма и эту самую позицию. Посмотреть куда по факту он переместил персонажа и на сколько ошибся.

#девлог@cat_and_code