Войти
Unreal EngineФорумПрограммирование

Компиляция/организация немаленького проекта

#0
(Правка: 22:23) 20:56, 29 мар. 2020

начинаю разработку своей TBS мечты, вот встал вопрос:
комп у меня не новый и хотелось бы добиться приемлемого времени компиляции с учетом того, что у меня практически все будет в коде
т.е. любое геймплейное изменение при обычном подходе потребует перекомпиляции всего игрового модуля
делаю так, чтобы была возможность использовать этот же код на сервере, если он когда-нибудь будет

подумал, решил разделить проект на несколько модулей внутри папки Source,
собственно как в самом движке сделано, ну на вид оно выглядит так же, на самом деле хз

сделал три модуля:
Game  PrimaryGameModule кароче, весь визуал тут
Core  базовая логика работы игры, базовые классы для юнитов и т.п.
Content  всякая конкретика, поведения юнитов, скиллы и т.п.

ну сделал вроде работает, компиляция отдельных модулей через студию правда хз как делается, но через редактор можно скомпилить отдельно Content,
надеюсь он не производит полную компиляцию папки Source для этого, нужно проверить

и вот сегодня начал сомневаться в правильности такого подхода
может быть какие-то другие варианты есть, с частичной компиляцией только измененных файлов или что-то подобное
про прекомпилированные файлы что-то припоминаю из прошлого, но будут ли они работать с уе билдами хз

норм подход? как это делается у вас?

забыл добавить вариант с использованием "стороннего" кода
меня в принципе устраивает если Core и Content будут в отдельных проектах того же солюшена, но я не совсем понимаю как оно будет работать с UE
GenerateProjectFiles перетрет все дополнительные проекты наверно

через плагин тоже пробовал делать, но там какой-то косяк случился, я даже не помню какой уже


#1
(Правка: 20:23) 20:13, 30 мар. 2020

mitroxa
> забыл добавить вариант с использованием "стороннего" кода
> меня в принципе устраивает если Core и Content будут в отдельных проектах того
> же солюшена, но я не совсем понимаю как оно будет работать с UE
> GenerateProjectFiles перетрет все дополнительные проекты наверно
Ну делаешь сперва интерфейс \ абстрактный класс
Условно говоря его можно назвать Фреймворком 
Есть три основные сущности
А) Игра
Б) Внешний модуль
В) Модуль "Фремоворк" 
Выходит так
1) "Фреймворк" - Содержит в себе макеты стандартных поведенческих структур
Например он содержит в себе класс представляющий базовый класс всех игровых юнитов

public abstract class  Character  
{
  private int HP = 100;
  private int Power = 10;
    
  public virtual void Atack(Character other)
  {
  other.Defense(this);
  }
  
  public virtual void Defense(Character other)
  {
  HP-=other.Power;
  }
}
Этот класс должен содержать в себе стандартные методы и свойства, которые будут использоваться игровым движком в той или иной ситуации.

Далее отправляем наш "Фреймворк" в DLL
Саму DLL подключаем и к игровому движку (он будет дергать методы) и к внешнему модулю (Он будет выполнять роль реализации макетных классов)

Далее для того чтобы игра правильным образом формировала и воспринимала данные из внешнего модуля, необходимо сделать точку входа (Условно говоря метод инициализации внешнего модуля)

abstract Class Game 
{
abstract public void Ini()
{
}
public void Spawn(Character character)
{
SpawnEvent(this,new CharacterEvent(character));
} 
public event SpawnHandler SpawnEvent;
}

public SpawnHandler(object sender, CharacterEvent e)

public Class CharacterEvent : Eventarg
{
public readonly Character Character;
public CharacterEvent(Character character)
{
Character  = character;
}
}
Этот класс должен содержать в себе методы взаимодействия с игровым движком из внешнего модуля данных, а так же события для обработки на стороне игрового модуля.

Т.е. сам Фреймворк знает что вызывается и что передается на вход. Но при этом он не в теме так сказать деталей того что конкретно будет происходить ни на стороне движка, ни на стороне модуля данных.

В свою очередь в игровом модуле код при спавне нужно описать примерно так

SpawnEvent += SpawnToMap;
public SpawnToMap(object sender, CharacterEvent e)
{
Map.Add(e.Character);
}
Т.е. выходит так что игровой движок добавляет в структуру "Map" некоего персонажа (о котором в принципе ни чего не известно)
Далее уже из Map можно будет дергать его методы которые реализуются в модуле данных
#2
20:29, 30 мар. 2020

mitroxa
у епиков есть демо стратежки - кури его

#3
(Правка: 22:11) 22:02, 30 мар. 2020

Jeners
я это все понимаю, спасибо
у меня вопрос то насчет организации скорее, ты предлагаешь схему в которой DLL оформлены в виде независимых от UE проектов? или использовать модули UE с Build.cs файлом?

Jeners
> Саму DLL подключаем и к игровому движку
конкретно в коде через использование метода загрузки Dll в рантайме?
FPlatformProcess::GetDllHandle() вроде метод есть, хз он ли
или в виде упаковки всего это в модуль в котором будут файл билда? как сделано в ue4/source/ThirdParty?

кароче вопрос типа, можно сделать так чтобы в солюшене было N проектов
один проект для игры, созданный самим ue, в нём есть что-то вроде ThirdParty папки(это теоретически избавит от необходимости загружать их вручную, хз), в которой через build.cs подключаются собранные в других проектах dll.
в других проектах этого же солюшена находится shared код, возможно там же находится сервер в виде отдельного проекта
и чтобы все это как-то лояльно воспринималось редактором UE, потому что он чуть что сразу ругается, типа иди билди из исходников все, или любой класс добавляй через редактор, что вызывает перекомпиляцию всей этой петрушки

такая схема подразумевает что можно забыть про generate project files, который трет все по дефолту?

сорян если тупой вопрос, с++ не моя стихия еще

innuendo
> у епиков есть демо стратежки - кури его
помню что-то такое, давно вроде смотрел, а там многомодульность используется разве? эпики же сами не советуют использовать больше одного модуля кода, какие-то там проблемы могут начаться

#4
22:09, 30 мар. 2020

mitroxa
> помню что-то такое, давно вроде смотрел, а там многомодульность используется
> разве? эпики же сами не советуют использовать больше одного модуля кода,
> какие-то там проблемы могут начаться

зачем тебе модульность ? миддлваре не делаешь же
просто добавь свои файлы и перегенери проект

#5
22:35, 30 мар. 2020

innuendo
> зачем тебе модульность ?
да мне не нужна, мне нужно код разбить на части таким образом, чтобы это нормально воспринималось редактором
я хз как он потом это воспримет при финальной сборке игры
у эпиков сделано в движке нормально вроде, в файле модуля можно указать несколько билдов либы под разные платформы, видимо когда идет "запекание" игры, редактор чекает этот файл и кладет нужную dll
но я пробовал проект отдельный добавить в солюшен и он у меня терся
может быть сам накосячил где-то

мне больше интересно как в нормальном продакшене этот процесс устроен
вряд ли конечно через студию, какие-нибудь CMake нужно использовать наверно, мне такое не потянуть

#6
23:15, 30 мар. 2020

mitroxa
> я хз как он потом это воспримет при финальной сборке игры
> у эпиков сделано в движке нормально вроде, в файле модуля можно указать
> несколько билдов либы под разные платформы, видимо когда идет "запекание" игры,
> редактор чекает этот файл и кладет нужную dll
> но я пробовал проект отдельный добавить в солюшен и он у меня терся
> может быть сам накосячил где-то

ты шото загнался - там всё проще было

#7
0:09, 31 мар. 2020

innuendo
да, есть у меня такой косяк, вид прокрастинации

#8
9:14, 31 мар. 2020

Ну, раньше (в UNIX) были make... Но они не вписались в концепцию обезьянников для доморощенных кодеров.

#9
9:33, 31 мар. 2020

mitroxa
>

найди пример в анириле и не парь мозг

Unreal EngineФорумПрограммирование