Приветствую вас, дорогие любители кодинга и виртуальных приключений! На связи снова неугомонный разработчик, который, как и всегда, с нетерпением жаждет поделиться своими мыслями.
Сегодня я снова погрузился в таинственный мир хранения данных во время игровых сессий. Пусть у нас и нет открытых миров, но данные всё равно нужно
собирать и хранить, даже если временно. Так что, потянувшись к Game Mode, я решил подключить ещё один объект.
Вы, возможно, задаётесь вопросом: зачем же так много объектов? Неужели я не
устаю твердить о них в каждой статье? Что это вообще такое? Если
отбросить сложные определения программистов и инженеров, то объект — это
как маленький жёсткий диск, который хранит данные. Чтобы передать их,
нужно взять этот «диск» с собой или отправить другу. Сам по себе объект —
это легковесный компонент, созданный с помощью Construct Object.
Он, как настоящий супергерой, обладает всеми необходимыми функциями:
функции, макросы, делегаты и переменные. Но в отличие от актора, который
может позировать на сцене, объект живёт только в памяти и существует до
тех пор, пока жив тот, к кому он привязан. Сам по себе объект, увы, не
может существовать — как бездомный кот, который мечтает о доме, но пока
просто бродит по дворам.
И вот тут возникает закономерный вопрос: почему же я так часто упоминаю объект и Game Mode? На самом деле, каждый модуль — будь то инвентарь, квестовая система или параметры NPC — можно представить в виде объекта. А Game Mode станет его заботливым родителем. Конечно, можно использовать Game Instance в качестве родителя, но это зависит от задачи, как от того, какой пирог печь: с вишней или с капустой. Game Mode перезагружается на каждом уровне, а Game Instance живёт, пока работает игра — как ваш любимый кот, который всегда рядом, даже когда вы его не зовёте.
Теперь представим, что квестовая система, диалоговая система, инвентарь и
характеристики NPC — это, образно говоря, модули. Так же, как
архитектура охватывает код и разработку, в игровой сфере можно
использовать те же принципы, только для других вещей. Когда вы
представляете каждый модуль объектом, работа с данными становится
гораздо проще. Возьмём классическую ситуацию со здоровьем персонажа. У
нас есть переменная здоровья, и мы хотим её изменить, например, подняв
уровень или восполнив здоровье. Обычно нам нужно извлечь это значение из
персонажа, обновить его и вернуть обратно. Технически это создаёт
несколько ссылок на персонажа через делегаты или интерфейсы, а ведь это
только здоровье! А если таких ситуаций тысячи? Получается, что мы
запутались в паучьем клубке, где путь до основания знают только две
инстанции: Бог и движок. И поверьте, молитвы тут помогут только тем, кто
искренне верит.
Теперь представьте, что переменная здоровья лежит в объекте, а объект — в Game Mode. Теперь, чтобы персонаж попил из колодца и восстановил здоровье, вам не нужно искать персонажа — достаточно просто вытащить объект из Game Mode (доступ к которому у движка есть из самых глубин ада) и обновить здоровье. И о чудо! Параметр здоровья обновляется и у персонажа, так как в обоих местах присутствует один и тот же объект. И никто не мешает вам создать матрёшку, чтобы не передавать десять разных объектов — можно сделать один главный объект и в него складывать частные. Конечно, можно
поэкспериментировать с наследованием, но с объектами это даётся с
трудом, как попытка заставить кота выполнять команды.
А что, если обновление нужно в реальном времени? Не проблема! Поместите
делегат в объект и вызывайте его именно там, где это необходимо. Этот
делегат будет привязан только к этому объекту и будет срабатывать в
нужный момент в любой части игры. А вот актор так не умеет: его один
делегат может «обзванивать» все места, где повешена привязка. Это бывает
полезно, например, когда нужно обновить полоску здоровья у персонажа и
вывести это значение в момент, когда вы поднимаете уровень.
Так что объект — это очень интересная штука, которая, к сожалению, ещё не
так широко обсуждается, даже на знаменитом форуме. Но при этом он может
значительно облегчить и упростить разработку, а главное — построить
логику вашей работы так, что вместо запутанных связей у вас будет вполне
себе структурированный набор данных.
Так что, друзья, не забывайте о наших маленьких, но мощных объектах!
#BlueprintDev #VisualScripting #UE5 #UnrealEngine #IndieGameDev
#GameplayProgrammer #TechnicalDesigner #GameLogic #AI #UI
#AnimationBlueprints #Prototyping #Git