Как стать автором
Обновить

Комментарии 10

Вы в курсе, что ваша игра вообще не находится по запросам retrowave и synthwave?


А так да, выглядит замечательно, и играется интересно. Удачи в продвижении.
Реквестирую игры, инспирированные стилями минимал-синт и дарквейв :)

Спасибо, буду иметь в виду про поиск по данным запросам!
А для писи не планируете издать? Выглядит весьма привлекательно, но вот не люблю я мобилкогеймерство. ничего не могу с собой, окаянным, поделать.
Пока не планирую, сначала посмотрю как пойдет на мобилках
Недавно слушал лекцию на Unity MeetUp в Москве, как раз по теме сериализации данных в Unity. Так вот, там рассказывали про ScriptableObject (далее SO). SO это что-то вроде Monobehaviour, только без всех callback'ов типа Start и Update и, что самое главное, оно может сохранять изменения, сделанные в игровой сессии после ее завершения, в отличие от Monobehaviour, который сбрасывает все поля после завершения игровой сессии на изначальные. Таким образом при помощи SO можно создать редактор уровней внутри самого Unity без xml.
Вообще SO был как раз разработан для таких решений, а использование Prefab'ов для хранения данных считают неким костылем.

P.S. Если будет желание создать редактор уровней для игрока (чтоб он сам смог создавать свои уровни), одним SO не обойдешься, так как состояние SO можно сохранять только в Ediotr'е.
Спасибо за информацию, но я не совсем понимаю каким образом хранить уровни не в префабах, используя ScriptableObject?
Сам уровень в SO хранить не выйдет, так как SO не имеет Transform, соответсвенно не может иметь «детей». Можно хранить в SO информацию об уровне, например двумерный массив int'ов, а потом генерировать уровень из этого массива. По сути SO выступает здесь вместо xml.
Остается вопрос, в чем же преимущество SO перед обычным xml? SO использует внутренние, бинарные (если не изменяет память) протоколы сериализации и десериализации, которые очень хорошо оптимизированы.
Но думается мне, что для таких несложных объектов, как уровни в вашей игре, это не играет большую роль. Поэтому я скорее делюсь еще одним способом, который активно продвигает Unity, а не советую вам что-то поменять.
Но все же один вопрос у меня остается, зачем вы создаете префабы? Почему бы не хранить в asset'ах просто xml файлы, а потом в рантайме генерировать уровни из них?
Идея ясна, спасибо за объяснение.
А для процессора явно проще на сцену добавить один сгенерированный префаб уровня, чем каждую клетку игрового поля по отдельности. Я только что замерил ради интереса время:
— на создание уровня из xml уходит в среднем 0.1 сек
— на добавление префаба уровня на сцену в рантайме 0.05 сек.

Отличная статья, спасибо! Насчёт дублирования интерфейса и других объектов если каждый уровень в отдельной сцене — я решил эту проблему скриптом LevelStarter, который хранил нужные для конкретного уровня настройки и заодно создавал интерфейс и проверял наличие нужных синглтонов (мне это пришло в разработке для возможности старта с любой сцены). Но это все было из-за лени создавать редактор.

Всегда пожалуйста :)
Интересное решение, но все равно, насколько я знаю, загрузка сцены более трудоемкая операция, чем смена префаба
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории