Здравствуйте, zelenprog

Желательно разложить всё по полочкам

Как понимаю три пункта работы приложения:
* Инициализация
* Работа
* Завершение

—

Задача первого пункта

Подготовить к работе все ресурсы.

Вот от них кажись и надо плясать. Какие виды ресурсов для работы нужны? (model_3d, music_background, etc)

—

Для каждого Делаем класс: ресурс такой-то

Для формирования этого ресурса есть параметры

можно сложить эти параметры в структуру (обычно без методов): params_init_ast (или что там)
* Каждому набору параметров формирования своя структура.

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

—

Создание объекта с параметрами формирования в некоторых случаях удобно поручить отдельному классу.

—

Если вдруг окажется, что класс ресурса нуждается в общении с другими классами (назовём "вычислители"), то есть от них зависит
То почему бы не добавить этих "вычислителей" как поля для структуры params_
Да капитан, параметр ясен перец может быть классом.

struct params_car_holder (text name, float size, agent orange)

// метод-аксесор
params_car_holder::get_age() { return this.orange.calc(this.size) }

—

Что по файлам? Хорошо ли отделить по разным классам: А логику загрузки данных от Б набор ресурсов для хранения и обработки?
Когда загрузчики более не нужны — некоторые можно выгрузить из оперативки. Хотя во втором пункте бывает нужно что-то подгружать)

—

Система
  Ресурсы
  Обработчики

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

Здравствуйте, zelenprog

Желательно разложить всё по полочкам

Как понимаю три пункта работы приложения:
* Инициализация
* Работа
* Завершение

—

Задача первого пункта

Подготовить к работе все ресурсы.

Вот от них кажись и надо плясать. Какие виды ресурсов для работы нужны? (model_3d, music_background, etc)

—

Для каждого Делаем класс: ресурс такой-то

Для формирования этого ресурса есть параметры

можно сложить эти параметры в структуру (обычно без методов): params_init_ast (или что там)
* Каждому набору параметров формирования своя структура.

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

—

Создание объекта с параметрами формирования в некоторых случаях удобно поручить отдельному классу.

—

Если вдруг окажется, что класс ресурса нуждается в общении с другими классами (назовём "вычислители"), то есть от них зависит
То почему бы не добавить этих "вычислителей" как поля для структуры params_
Да капитан, параметр ясен перец может быть классом.

struct params_car_holder (text name, float size, agent orange)

// метод-аксесор
params_car_holder::get_age() { return this.orange.calc(this.size) }

—

Что по файлам? Хорошо ли отделить по разным классам: А логику загрузки данных от Б набор ресурсов для хранения и обработки?
Когда загрузчики более не нужны — некоторые можно выгрузить из оперативки. Хотя во втором пункте бывает нужно что-то подгружать)

—

Система
  Ресурсы
  Обработчики

В таком раскладе обработчиков можно динамически подменять налету.
Типо когда в игре по сети теряется соединение и происходит переход в автономный режим.
Сорян, пример надуманный, я ещё не работал в гейм деве.