Comments 5
Раз хардкор начали почему не приводите пример зачем именно использовать скриптабл обжект? Если награда однотипная проще будет вручную завести кастомные кнопки.
Давайте пример где действительно оправдан скриптабл обжект: к примеру разные награды.
ScriptableObject — это просто способ хранения информации о миссии в Unity проекте. Конечно, можно хранить инфу о миссиях как в формате json, так и в XML, но зачем себе жизнь усложнять, если есть ScriptableObject (про кастомные кнопки не понял). Если у тебя будут разные награды, то ты просто делаешь отдельное поле, например, так:
//Конфиг для миссии:
public abstract class MissionConfig : ScriptableObject
{
[SerializeField] public string id;
[SerializeField] public MissionDifficulty difficulty;
[SerializeField] public string title;
[SerializeField] public Sprite icon;
[SerializeField] public RewardConfig reward; //Ссылка на награду
public abstract Mission CreateMission();
}
//Конфиг для награды:
public class RewardConfig : ScriptableObject
{
//Структура награды зависит от тз...
}
SO вам подтянет все зависимости которые вы в нем укажете - все иконки, конфиги и другие ресурсы, которые вы возможно в будущем захотите в этом конфиге описывать. Даже те, которые не нужны, например прошедшие миссии. Не страшно, если миссий 5-10. А если 50-100? Все это будет в памяти. Так что как минимум для самих СО конфигов стоит предусмотреть загрузку по требованию, хотя бы из ресурсов, а лучше из бандлов/аддрессаблов.
Из бест-практикс, советую использовать шаблон "сценарий" из обычных инумераторов.
Разбиваете сценарий на условия выполнения, следующий шаг выполнятся будет после выполнения этого условия.
Это позволит сделать асинхронную реактивную логику. На сценариях просто реализовать туториалы , макросы, логику ошибок, поведение UI, просто реализовать едитор для гд.
Реализация миссий в игре на Unity (Ч1)