Большое количество уровней в арканоиде

@GrigorGri · Регистрация: 16.09.2015

Студворк — интернет-сервис помощи студентам

Делаю арканоид, в игре планирую иметь 50+ различных уровней. Для удобства хочу создать отдельное приложение - редактор. Вопрос, как обычно реализовывается загрузка уровней в таком случае? Пока мне открылся только вариант создания текстового документа наподобие
000001200230
420000132310
123543468999;
и так для каждого уровня, загружая при его открытии префабы через скрипт.

@lentinant · 17.09.2015, 15:16

Я делал редактор уровней для своей игры, с помощью специального типа данных. Каждый объект на уровне описывался структуртой в виде "трансформ (положение, поворот, масштаб), тип объекта (блок это, бонус, декорация и т.д.), дополнительные параметры". В общий же тип данных записывался массив таких структур, соответственно количеству объектов на уровне. После чего успешно записывался в файл одним из многих методов (я использовал бинарную сериализацию). Воспроизведение уровней, даже в игре, можно сделать точно таким же образом - десериализируете файл, получаете ваш массив объектов, и, исходя из него, создаете объекты вашего уровня.

@jetyb · 18.09.2015, 08:07

Тут два варианта:
1. Сделать каждый уровень отдельной сценой и подгружать методами Application.LoadScene... Не совсем универсально, но удобно и для данного примера подойдет.
2. Каждый "уровень" представить группой префабов, префабы паковать как AssetBundle в отдельные файлы. Затем в процессе игры подгружать их и инстантиировать.

@8Observer8 · 19.09.2015, 01:19

Пока мне открылся только вариант создания текстового документа наподобие

Я так делаю, как вы написали. Тектовый файл формирую в редакторе Tiled Map Edit. Может вам подойдёт: https://www.cyberforum.ru/post8079151.html

@Darky · 22.09.2015, 15:56

Тут два варианта:
1. Сделать каждый уровень отдельной сценой и подгружать методами Application.LoadScene... Не совсем универсально, но удобно и для данного примера подойдет.
2. Каждый "уровень" представить группой префабов, префабы паковать как AssetBundle в отдельные файлы. Затем в процессе игры подгружать их и инстантиировать.

Вы ошибаетесь, здесь гораздо больше вариантов. То, что вы предлагаете, является худшей практикой, и делать так категорически нельзя. Я говорю это не чтобы подколоть или задеть как-то, просто я делал так же раньше, и наблюдал объемные утечки памяти в пустоту.
Если 50 уровней арканоида будут загружаться через App.LoadScene, ну кто угодно устанет ждать. А если новые уровни появятся? Всех их заносить в билд? А как удобно среди них ориентироваться в иерархии - слов нет! Короче, не вариант.

"Хватит болтать", скажете вы, и будете правы. Я тут не нотации пришел читать, а предлагать решение. То, что у меня есть - это ScriptableObject, универсальный объект для хранения данных. Его не нужно держать на сцене, на него можно делать прямые ссылки и обращаться к тому, что в нем хранится. А храниться может все подряд - префабы, вектора, данные любого типа (см. скриншот).

Вот вам код

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
using UnityEngine;
using System.Collections.Generic;
#if UNITY_EDITOR
using UnityEditor;
 
#endif
 
using System.Collections;
 
public class CreateConfigAsset : MonoBehaviour {
 
    public List <ConfigAsset> assetList;
 
    #if UNITY_EDITOR
    [ContextMenu("CreateAsset")]
    public void CreateAsset()
    {
        foreach (var item in assetList) {
            if (item.className != ""  && item.assetName != "") {
                var so = ScriptableObject.CreateInstance (item.className);
                AssetDatabase.CreateAsset (so, "Assets/Prefabs/" + item.assetName + ".asset");
            }
        }
    }
    #endif
 
}
[System.Serializable]
public class ConfigAsset{
    public string assetName;
    public string className;
}

Всю эту бандуру надо навешать на префаб, указать скрипт, из которого вы хотите сделать ScriptableObject, нажать шестереночку -> "Create asset", и - вуаля! - экземпляр готов. Если вам что-то не ясно, почитайте подробнее. Я обещаю, такого удобного инструмента для работы со структурами данных в Unity вы более не сыщете

@jetyb · 22.09.2015, 19:33

Darky
Преимущество первого метода - его простота, особенно для новичка. Не надо паковать общего в папку Resources, не надо отмечать все объекты, которые входят в "сцену", работать опять же проще. Сцена также автоматически подцепляет Lightmapping и OcclusionCulling, в варианте же с бандлами же придется на них писать свой костыль (в случае с OcclusionCulling - вообще непонятно как). Для игры из множества отдельных несвязанных уровней (случай ТС) это вполне годный вариант.

Сообщение от Darky

Вы ошибаетесь, здесь гораздо больше вариантов. То, что вы предлагаете, является худшей практикой, и делать так категорически нельзя. Я говорю это не чтобы подколоть или задеть как-то, просто я делал так же раньше, и наблюдал объемные утечки памяти в пустоту.
Если 50 уровней арканоида будут загружаться через App.LoadScene, ну кто угодно устанет ждать. А если новые уровни появятся? Всех их заносить в билд? А как удобно среди них ориентироваться в иерархии - слов нет!

Есть отдельная папка, в которой удобно хранятся все 33 (333) сцены. Если иерархия не нравится, сцены можно сгруппировать по подпапкам (все равно файлов получится меньше чем в случае с бандлами). Билдится все не в вручную, а скриптом, который сам подбирает все сцены.
Утечек памяти без причины тут не замечал.
Что там еще? Размер загружаемого билда\необходимость ребилдить проект после каждого изменения сцены?
Есть гибридный вариант - загружать сцены из AssetBundle.

Сообщение от Darky

То, что у меня есть - это ScriptableObject, универсальный объект для хранения данных. Его не нужно держать на сцене, на него можно делать прямые ссылки и обращаться к тому, что в нем хранится.

Прямые ссылки означают полную загрузку ScriptableObject со всеми данными в память. Если он у вас висит в памяти постоянно, то значит и все его данные (то есть 100 текстур и 200 мешей из 30 сцен) будут висеть в памяти. Когда нужны только данные от одной сцены.
Подход работать будет, но памяти будет жрать сверх меры.

Если же паковать ScriptableObject в бандлы - то получится по сути предложенный мною 2 вариант.
Можно паковать ScriptableObject, можно паковать префаб со ссылкой на ScriptableObject.
Сам так делаю.

@Darky · 22.09.2015, 20:13

Сообщение от jetyb

Преимущество первого метода - его простота, особенно для новичка. Не надо паковать общего в папку Resources, не надо отмечать все объекты, которые входят в "сцену", работать опять же проще. Сцена также автоматически подцепляет Lightmapping и OcclusionCulling, в варианте же с бандлами же придется на них писать свой костыль (в случае с OcclusionCulling - вообще непонятно как). Для игры из множества отдельных несвязанных уровней (случай ТС) это вполне годный вариант.
Если 50 уровней арканоида будут загружаться через App.LoadScene, ну кто угодно устанет ждать. А если новые уровни появятся? Всех их заносить в билд? А как удобно среди них ориентироваться в иерархии - слов нет!
Есть отдельная папка, в которой удобно хранятся все 33 (333) сцены. Если иерархия не нравится, сцены можно сгруппировать по подпапкам (все равно файлов получится меньше чем в случае с бандлами). Билдится все не в вручную, а скриптом, который сам подбирает все сцены.
Утечек памяти без причины тут не замечал.
Что там еще? Размер загружаемого билда\необходимость ребилдить проект после каждого изменения сцены?
Есть гибридный вариант - загружать сцены из AssetBundle.

Ладно, здесь с вами спорить трудно, вы убедительный. И я погорячился насчет "категорически нельзя", признаю.

Сообщение от jetyb

Прямые ссылки означают полную загрузку ScriptableObject со всеми данными в память. Если он у вас висит в памяти постоянно, то значит и все его данные (то есть 100 текстур и 200 мешей из 30 сцен) будут висеть в памяти. Когда нужны только данные от одной сцены.
Подход работать будет, но памяти будет жрать сверх меры.

Здесь, однако, не до конца уверен. Ребята, которые аутсорсят для нас, используют SO для всех своих проектов, и проблем с производительностью у них не было никогда.

Сообщение от jetyb

Если же паковать ScriptableObject в бандлы - то получится по сути предложенный мною 2 вариант.
Можно паковать ScriptableObject, можно паковать префаб со ссылкой на ScriptableObject.

Да, но я скорее решил просто рассказать про SO, про него знает весьма небольшой процент разработчиков.

Новые блоги и статьи Все статьи Все блоги /
Запрет удаления строк ТЧ документа при определенном условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .
Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.	Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .	Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .	Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .

@GrigorGri 0 / 0 / 0 Регистрация: 16.09.2015 Сообщений: 1

	Большое количество уровней в арканоиде 16.09.2015, 20:40. Показов 3126. Ответов 6 Метки нет (Все метки) Делаю арканоид, в игре планирую иметь 50+ различных уровней. Для удобства хочу создать отдельное приложение - редактор. Вопрос, как обычно реализовывается загрузка уровней в таком случае? Пока мне открылся только вариант создания текстового документа наподобие 000001200230 420000132310 123543468999; и так для каждого уровня, загружая при его открытии префабы через скрипт. 0

@lentinant 103 / 90 / 19 Регистрация: 15.04.2015 Сообщений: 353
	17.09.2015, 15:16
	Я делал редактор уровней для своей игры, с помощью специального типа данных. Каждый объект на уровне описывался структуртой в виде "трансформ (положение, поворот, масштаб), тип объекта (блок это, бонус, декорация и т.д.), дополнительные параметры". В общий же тип данных записывался массив таких структур, соответственно количеству объектов на уровне. После чего успешно записывался в файл одним из многих методов (я использовал бинарную сериализацию). Воспроизведение уровней, даже в игре, можно сделать точно таким же образом - десериализируете файл, получаете ваш массив объектов, и, исходя из него, создаете объекты вашего уровня. 0

@jetyb 298 / 260 / 108 Регистрация: 26.10.2012 Сообщений: 810
	18.09.2015, 08:07
	Тут два варианта: 1. Сделать каждый уровень отдельной сценой и подгружать методами Application.LoadScene... Не совсем универсально, но удобно и для данного примера подойдет. 2. Каждый "уровень" представить группой префабов, префабы паковать как AssetBundle в отдельные файлы. Затем в процессе игры подгружать их и инстантиировать. 0

Опции темы