В предыдущей статье в частности, я раскритиковал неумелое использование технологии MVC при создании игр.
Нет, я не являюсь заядлым критиком чего-либо, просто мне не нравится, когда какой-то подход или технология используется тогда, когда в этом нет необходимости.
В этой статье я расскажу вам один пример, когда данная технология просто необходима.
Но обратите внимание - для реализации вам не нужен какой-либо фреймворк, если вы еще не верите в свои силы - я научу вас создавать элегантные решения с минимумом усилий и тогда, когда вам это нужно :) Связь «Когда вам нужен MVC, как сделать привязку визуальных элементов управления с помощью метода (UNITY, C#, Game Development)» Вы можете меня послушать, но если хотите прочитать, пожалуйста, дайте мне подсказку.
Первое условие: у вас в игре есть как минимум две сцены: главное меню и сама игра.
Второе условие: вы не хотите дублировать какую-либо часть вашего GUI (графического пользовательского интерфейса) в своих сценах.
Вероятно, вы хотите, чтобы выбор настроек, возможность локализации (изменения языка), управление сохранениями, возможно, какие-то диалоги были доступны из любой из этих двух сцен.
Третье условие: вы хотите разгрузить сцены от ненужной логики.
Возможно, в главном меню у вас будет кат-сцена или сложный скриптовый диалог, но в игровой сцене все это не нужно.
При необходимости вы можете просто вернуться в главное меню.
В чем здесь проблема? По умолчанию при смене сцены удаляется всё, что там было.
Но можно использовать юнит-метод DontDestroyOnLoad (его можно найти в документации или на моем канале), но думаю об этом знают все, кто читает более сложные темы и идем дальше.
Но вы не хотите (по третьему условию) переносить всю сцену внутрь второго; наоборот, вы хотите передать только то, что необходимо.
Но это значит, что в новой сцене никто не знает об артефактах из предыдущей сцены (с этим еще можно жить), а оставшиеся артефакты не знают, кто заменит им тот функционал, который был в предыдущей сцене.
Например, в главном меню настройки вызывались с помощью какой-то «эпической» кнопки, а в игровой сцене — с помощью «простой» кнопки меню паузы.
Или если то, какую фоновую музыку играть сейчас в главном меню, решил сценарий диалога, то в игровой сцене будут решать другие объекты геймплея.
Но они должны найти друг друга.
А чем больше сцен, тем нелинейнее становится.
MVC как таковой, реализованный без привязки, на уровне поддержки фреймворка, полностью устарел и может быть только теорией.
Если вы попытаетесь реализовать MVC по Фаулеру (у него есть пример для языка Java), вы не будете смотреть на это без слез.
Он привел это как теоретический пример, а не как руководство к действию.
Известные фреймворки с привязкой — WPF и ASP.NET (их качество — отдельный разговор, но оно существует).
Но так ли сложно реализовать эту привязку самостоятельно? Но это необходимо в Unity. Оказывается, это относительно просто.
Проще, чем вручную реализовать MVC для 3 классов.
Для этого мы возьмем UnityEvent
Теги: #Разработка игр #C++ #unity #OOP #event #binding #MVC[System.Serializable] public class BindingEvent {
-
Worm Flame Создан Для Кибершпионажа
19 Oct, 24 -
Вам Нужен Еще Один Курс Git?
19 Oct, 24 -
Мальчик И Морская Звезда
19 Oct, 24 -
Пицца Ала-Полу-Под Присмотром
19 Oct, 24 -
(Архив) Matreshka.js V0.1
19 Oct, 24
