Очередные вопросы от меня по игровой логике и скриптингу
1. Что будет работать быстрее?
1.1 Массив перебираемый в цикле. 1.2. Листаемый свитч с вбитыми вариантами искуемого. 2. Как правильно организовать возврат из текущей сцены в предыдущую без потери игрового процесса в сцене? (расположение и количество объектов на сцене, их параметры, и так далее.) 2.1 Нужно писать загрузку\сохранение уровня, или же как-то можно заморозить и запомнить всё в сцене возможностями юнити, и просто когда надо вернуться в нужную сцену и продолжить игру с текущего места? 2.2. Если это возможно только с загрузкой\сохранением (что по моему мнению медленно), то не проще ли отказаться от сцен, и делать всю игру в одной сцене просто перенося игрока по разным координатам подальше, имитируя переход в другую сцену? |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
1. Свитч, потому что он в итоге преобразуется в что-то типа словаря.
2. Надо делать сохранения (записывать например состояние сцены в файл json или xml или другой формат), а при загрузке сцены восстанавливать состояние из сохраненного файла. Возможности заморозить нет. Если ты можешь себе позволить делать все в одной сцене, то почему бы и нет? Но разве сохранения в итоге не потребуются далее? Если например игра для телефонов, то часто телефон будет уводить приложение в фон и если не сохранить прогресс, то можно его потерять... |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
Плюс больше шансов где-то пролюбиться, ведь при рестарте игры надо будет всё не только грузить, но ещё и за собой вычистить, тут можно ошибиться и наловить багов. А сцены это вариант для ленивых, чтобы не париться (ну или если есть реальные причины так не делать). |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
с условиями выкакана, там под 2к строк. Я думал это сделать временным решением, и перевести всё на массивы с циклами позже, но теперь я уже так не думаю. Засомневался. У меня там прям рекурсия (свитчи в свитчах в свитчах в свитчах). Цитата:
Когда нужно часто менять сцену, чуть ли не каждые пол минуты, то постоянная загрузка может в конец выбесить игрока, нужно другое решение. Возможно стоит вторую сцену реализовать внутри первой через слои, например тормозим все объекты в первом слое, и отрубаем им рендер и коллайдеры, и соответственно обратное делаем со второй сценой. Всё будет происходить в тех же координатах игровых, даже не надо куда-то в отдельные координаты переносить импровизированную сцену. |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
Думаю тут можно делать тоже самое, только камеру переключи. |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
Переключаем часть свитча, рендерится другая часть (считай другой слой), вот тебе и другой уровень. Я это по большей части для меню использовал. А так я чисто загрузку и сохранение реализовывал, локация создавалась нужная по месту, выкорячивалась из массивов. У меня даже модели в массивах лежали. --- В своём проекте в юнити есть идея просто сцену боя рисовать под локацией открытого мира снизу. Этак пунктов на 50 ниже. Она один хрен каждый раз под бой генерируется, все её объекты всё равно исчезают после боя. А открытый мир сверху тупо на паузу ставим (она кстати давно уже реализована). Так-как в этой игре не предусмотрено смотреть камерой вверх, то открытому миру сверху даже рендер отключать не надо, как максимум источники света. Ну а камеру не надо переключать, просто перенести в нужные координаты. Но возможно лучше и переключать на другую, хз, тут подумать надо. |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
|
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Вложений: 1
Цитата:
10 лет блитц не видел, уже впадлу вспоминать чё там к чему. Помню, что реализовал через свитч, при чём вторая часть его за рендер ворлдом. Видео работы в архиве поста. Вот прям из своего проекта код теме: Добавил: вот смотрю я код, а там функция ВорлдКлир. По ходу не исключал из рендера, а загружал и удалял объекты. |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
Если GameObject'у сделать SetActive(false) то он выключается из иерархии. Перестаёт рендериться, привязанные к нему скрипты перестают работать (возобновляются после SetActive(true)). Можно сделать в корне сцены родительские объекты, к которым будут крепиться те, что относятся к соответствующей части игры (меню, мир, битва), это и будут "слои". Чтобы не загружать заново ассеты, можно загрузить один раз и держать их образцы для клонирования. Про вычищение я имел в виду, что если у тебя, например, битва завершилась, и ты вернулся в мир, то тебе надо уничтожить всех монстров, которые были в битве и т.д., чтобы в следующей их там не было. При этом основные объекты (игровое поле, например) можно оставить. Про это я и имел в виду, что "надо париться", если просто грузить сцену, то там само всё обнуляется в начальное состояние (вариант для ленивых и нубов). |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
На счет выпила объектов на поле боя, это легко. Делаем глобальный статический скрипт, вешаем в него переменную отвечающую за зачистку. В каждом объекте зашиваем условие с проверкой значения этой переменной, в результат условия пишем дестрой зыс, всё. При завершении боя меняем эту переменную, и все объекты самовыпиливаются. |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
Вообще такое можно сделать 2 способами: Через эвенты. 1. Создаёшь UnityEvent battleOver и вызываешь его battleOver.Invoke() в момент, когда битва завершена. 2. Каждому объекту, который имеет отношение к, в OnEnable делаешь подписку (лайк, колокольчик) на этот эвент: PHP код:
Вариант с эвентами хорош тем, что можно создать эвенты на все ключевые события, а потом объекты "подписывать" на них по мере надобности. Второй способ через списки: Иметь список всех однотипных объектов и при надобности перебирать их все. public static List<Monster> allMonsters = new List<Monster>(); // Глобальный список PHP код:
PHP код:
Если тебе надо удалить всех монстров (или что-то с ними сделать) то перебираешь список: PHP код:
Способ со списками более простой, но я бы советовал раздуплить как работают эвенты, полезная штука. |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
|
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
Цитата:
В твоём коде они только в функции LoadMap, остальное на If'ах. По поводу мира: Отдельную сцену боя логично, сразу загружать и держать где-то в стороне в одном пространстве. Обычно так и делают. На сколько большая карта предполагается? Потому что если у тебя вид сверху, всё относительно «мелкое», много повторяющихся элементов? Я бы так и поступил, разместил всё в одной сцене. Pax предложил отличную идею слоёв (как я сам не догадался). По моим наблюдениями, в подобных играх (если я тебя правильно понимаю) далеко не всё содержимое мира сохраняют. Crystal, не забывай пожалуйста прятать свои простыни кода под спойлер :( P. S. В общем тут уже написали всё то что я хотел написать вчера, но почему-то забил. |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
У меня максимум объектов 50 могло бы так ожидать смерти читая переменную в отдельном статике. Цитата:
https://forum.boolean.name/showpost....45&postcount=4 на самом деле в моём случае вообще не надо ничего, кроме перемещения камеры на этаж с нужным уровнем. Генерируем поле нужного размера, расставляем монстров и игрока, телепортируем камеру в нужные координаты. После боя возвращаем камеру обратно, а поле с игроком и монстрами удаляем. Нужно только источники света на локации выше выключить. Цитата:
что просто в других координатах бой рисуется в той же сцене. Цитата:
Цитата:
Цитата:
только что в посте проверил, и работает! Вчера форум мне в посте проявлял тег, не читая его. |
Ответ: Очередные вопросы от меня по игровой логике и скриптингу
Цитата:
Осуществимо было при использовании FastExt или AShadow. |
Часовой пояс GMT +4, время: 00:19. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot