В geenral в вашем коде вы можете использовать c # препроцессоры , чтобы компилировать код или условно комментировать некоторые глобальные определения.
Unity предлагает Версия и платформаспециальные препроцессоры
Начиная с Unity 2.6.0 и далее, вы можете компилировать код выборочно.Доступные параметры зависят от версии редактора, над которым вы работаете.Учитывая номер версии XYZ (например, 2.6.0), Unity предоставляет три глобальные директивы #define в следующих форматах: UNITY_X, UNITY_X_Y и UNITY_X_Y_Z.
и
Начиная с Unity 5.3.4, вы можете скомпилировать код выборочно на основе самой ранней версии Unity, необходимой для компиляции или выполнения заданной части кода.Учитывая тот же формат версии, что и выше (X.Y.Z), Unity предоставляет один глобальный #define в формате UNITY_X_Y_OR_NEWER, который можно использовать для этой цели.
Таким образом, вы можете точно контролировать, какойверсия кода должна использоваться для конкретной целевой платформы, версии Unity, версии .Net и т. д.
Вы можете заключить код, например, в
#if UNITY_2017_1_OR_NEWER
/* Code that only compiles under newer version */
#elif UNITY_5
/* Code that compiles for Unity 5.x.y */
#elif UNITY_4
/* Code that compiles for Unity 4.x.y */
#else
/* apparently some older stuff */
#endif
Затем вы можете упаковатьвсе это в одном *.unitypackage, и пользователь даже не заметит.Поскольку закомментированный материал удаляется во встроенном приложении, он не увеличивает размер сборки.
Однако структура развития - это другой вопрос.Я думаю, чтобы быть уверенным, что поддержка работает, вы не придете к единому проекту для каждой версии Unity и скопируете код для более старых версий в разделы препроцессора самой новой версии.
Чтобы сделать его максимально простым для меня, я бы, вероятно, использовал структуру папок, например
YourPlugIn
|-- General
|-- Unity4
|-- Unity5
|-- Unity2017
, и использовал ключевое слово partial, чтобы реализовать полное поведение, вместо этого включив иотключение отдельных блоков кода, например
General / MyBehaviour.cs
public partial class MyBehaviour : MonoBehaviour
{
// this is the script users should be dragging onto objects
}
Unity4 / MyBehaviour_4.cs
#if UNITY_4
// Extends the general MyBehaviour for Unity 4.x.y
public partial class MyBehaviour
{
public string InitialValue;
private void Start()
{
Debug.Log(InitialValue);
}
}
#endif
Unity5 / MyBehaviour_5.cs
#if UNITY_5
// Extends the general MyBehaviour for Unity 5.x.y
public partial class MyBehaviour
{
public int InitialValue;
private void Start()
{
Debug.Log(InitialValue.ToString());
}
}
#endif
Unity2017 / MyBehaviour_2017.cs
#if UNITY_2017
// Extends the general MyBehaviour for Unity 2017.x.y
public partial class MyBehaviour
{
public Vector3 InitialValue;
private void Start()
{
Debug.Log(InitialValue.ToString());
}
}
#endif
Но , тогда вы не можете использовать ни одно из, например, UNITY_X_Y_OR_NEWER определений, поскольку вы получите дубликаты;)
Конечно, есть много других проблемных зон, таких как, например, переименование ваших классов позже или в более новой версии, оборачивая их в интерфейсы и т. Д., Но я надеюсь, что я ясно изложил свою идею.
Я бы тоже рискнулTo утверждать, что этого должно быть достаточно, чтобы поддерживать только «последние» версии Unity и не делать плагин обратно совместимым вплоть до Unity 2.6 ... кто все равно будет использовать этот старый материал?
В настоящее время вHUB - последняя версия, предлагаемая для установки, - 2017.1.5f1, поэтому я утверждаю, что достаточно иметь обратную поддержку до этой версии, а не дальше.
К вопросу об управлении версиями:Github предлагает довольно полный .gitignore для Unity .Там вы можете видеть, что существует намного больше, чем папка Temp, которую следует игнорировать .. особенно Library.
В этот пост Я тожеописал быстрый и безопасный способ удаления всех сгенерированных файлов с помощью одной команды git.Лично мне нравится исключать все Library/*.asset файлы из игнорируемого (поэтому они контролируются версией), так как здесь хранятся некоторые вещи, такие как пользовательские макеты, текущая цель сборки и т. Д.