Организация хранилаща игровых объектов

Привет всем геймдевелоперам Беларусии!!!
Я тут смотрю мало у нас обсуждений, я уже как почти пол года назад зарегился, а вот никак не мог написать что-нить на форуме.Я конечно понимаю, что все мы умеем посылать в гугл, или на gamedev.ru :), но почему бы не наращивать мощь нашего форума, для того что бы люди сюда хоть иногда заходили, не просто посмотреть что ничего нового не появилось, а с целью узнать что-то новое, давайте обсуждать темы.

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

Так вот сейчасная моя схема рендера(точнее это не схема это просто набросок того, что она должна из себя представлять):
[img_assist|nid=368|title=так как я себе его представляю|desc=|link=popup|align=left|width=100|height=120]
Но в ней ничего нет про то как же на самом деле будет происходить рендеринг геометрии, и тем более нет ничего из-того, что будет говорить о так называемой схеме расположения объектов. Что я под этим понимаю, это организация игровых объектов с учетом не только графики, но и физики, ии, звука и даже сети.

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

Так я себе представляю главное хранилище объектов, это только для скажем так модели состоящей из одного меша или из нескольких, но с условием, что она не может меняться. Т.е. всегда статична, как следует из названия :)
//forward declarationclass brSoundEntity;class brRenderEntity;

class brPhysicEntity;

class brStaticObject : public ibrObject{public:

virtual ~brStaticObject(){

}

private: brRenderEntity *renderEntity; brSoundEntity *soundEntity; brPhysicEntity *physicEntity;};

Каждая из этих энтитей наследуется от базово класса энтити, который прописывает общие каноны всем подсистемам двига. Далее все эти энетити это скажем вся необходимая информация, которая поступает в подсистемный обработчик связанный с данной игровой моделью. Скажем brRenderEntity будет содержать в себе мешь, материал, настройки состояний рендера, т.е. формирования батчей тоже идет только благодаря этой энтити цельного игрового объекта.

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

//forward declaration

class brAIEntity;

class brGameObject{private: std::vector<ibrObject*> objectes; brAIEntity *ai; mat4X4 gameOrientation;};

Да чуть не забыл во абстрактный класс с базовыми, пока скудными свойствамиclass ibrObject{public:

virtual ~ibrObject(){

}

inline BRvoid setOrientationMatrix(const mat4X4 &_mat){ orientation = _mat;

}

inline const mat4X4 &getOrientationMatrix() const{ return orientation; }protected: mat4X4 orientation;};

Да тут кстати встает еще один немаловажный вопрос как эти подсистемы будут между собой общаться. Меседжы, эвенты, функции обратного вызова? Не наю, надо думать, мот кто что посоветовать может буду рад, но пока не решил еще что будем использовать.

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

Высказывайтесь, советуйте, только просьба не надо превращать топик в фарс, я его написал, не столько для знаний, сколько для рекламы нашего сайта Smile Давайте просто обсуждать наболевшую тему, ведь форум именно для этого и предназначен. да?

P.S. Познее уберу последние строки дабы не смущать народ. А может и удалю тему. Надеюсь на вас сомемберы.

P.S.2 Респект создателям сайта, настойки для ввода текста на форуме действительно удобные, имхо может лучше даже чем на .ru :)

Последняя правка: пн, 29/08/2011 - 22:08
Submitted by BronX on

Комментарии

В самых лучших книгах написано то что мы итак уже знаем (с) Дж. Оруэлл

Модель сия очень абстрактна и несмотря на упрощенный вид очень наворочена. Даже я бы сказал черезчур наворочена. Мало игр имеют настолько закрученную модель в отношении составления объектов. Настороженность вызывает что данная модель зделана под все и ничего конкретно. ее сложно будет оптимизировать хотя в теории легко будет адаптировать.

И как в любой сложной объектной модели (в особенности на с++) один из самых важных вопросов: а как всю это фиговину превратить в нечто единое, синхронизированное и живое? Проще говоря: как сделать обмен данными между объектами, да еще и чтоб побыстрей было (игровой движок всетаки). Основная проблема: как изменить объект и уведомить об этом все другие объекты, которые его используют. Т.к. это игра то объекты, которые используют главный могут еще и какието свои данные в целях оптимизации хранить.

первое, что приходит в голову это куча глобальных или статических функций вида:

set_xxx_property(Manager &manager,Manager::Handle &handle,Object &object,Object::property new_property);

которые бы учитывали состояние объекта в рамках того что этим объектом пользуется. Вариант экономичный по отношению к памяти но некрасивый. Он плавно перерождается в идею хранить в объекте указатели на то что им пользуется и при изменении свойств через эти указатели уведомлять "пользователя", читай callback. сей вариант менее экономичен с точки зрения памяти да и не всегда оправдан но достаточно удобен.

И наконец Метод "влоб". Каждый раз узнавать характеристики объекта и подстраиватся при рендеринге, обсчете ИИ или механики.Не всегда снижает производительность да и метод весьма простой: поменял переменную, а рендерер на следующем проходе сам все сделает. Кстати этот метод неплохо подходит для модели, изображенной на схеме Smile

P.S. Фигню какуюто я написал Sad

Submitted by tormoz on
Превед tormoz. Если бы не знал этого человека было бы даже неловко так писать :)

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

Submitted by BronX on

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

Во первых сам ресурс, что он должен уметь, и какую иформацию хранить:
1) имя ресурса, оно должно быть уникально в рамках системы, можно использовать UUID можно Имя + путь файла, можно ХЭШ.
2) Должен содержать ссылку на Интерфейс работы с Движком взаимодействующим с данным ресурсом.
3) Должен содержать ссылку на Интерфейс работы с Загрузчиком ресурсов.
4) Должен содержать работу с прекэшингом ресурса если она необходима.

5) Должен содержать работу с Меритами ресурса (приоритет работы ресурса, содержания в кэше)

4й и 5й пункт, нужен для игр которые не могут целиком подниматься в память

Далее работа ресурса в движке:

Движек - непосредственно работает с интерфейсом ресурса, считает сколько времени данный ресурс используется и устанавливает мерит данному ресурсу, т.к. Ресурсы движка ограничены (тут я имею ввиду реальные ресурсы например Видеопамять) то необходимо каким то образом (по мериту) определять ресурсы которые сбрасываются в кэш(системную память), или удаляются полностью. Также может возникнуть необходимость перегрузить все ресурсы для переключения режима, эту логику можно выделить в отдельный класс, т.к. работа идет с базовым классом русурса.

Вот собственно и всё, если есть вопросы мы сможем их решить Smile тугезер.

Submitted by Relyer on
Пиривет Relyer. Рад что народ начал рассписываться :)

Короче ты наверное на правильно понял, что я имел ввиду. На самом деле менеджер ресурсов, имхо я пока не собираюсь делать, хотя на его счет есть много идей. Одна из них сделать для каждого ресурса отдельный пул, определенного размера,выделить его объем в начале игры и просто уже записыать, без постоянных перераспределений. Имхо тут возникает проблемка, в том плане, что текстуры могут быть разных размеров, тогда просто в этом пуле будет выделяться память не на саму текстуру, которая еще раз повоторюсь может быть разных размеров, а только на дескриптор текстуры + указатель на действительные данные, которые потом загружаеются из одного большого файла, т.е. предкомпилированных ресурсов. Имхо это будет очень быстро так как не надо грузить что-то ни по имени ни по индентификатору, а просто копируем образ этих компилированных ресурсов сразу в память, а потом просто будем их по смещению доставать. Но это не то что я хотел спросить.

Проблема у меня в другом, как правильно огранизовать общую систему хранения объектов, НЕ РЕСУРСОВ, а именно игровых объектов. Просто щас получается, что надо придумать эту схему хотя бы приблизительную, что бы можно было бы забыть об этом вопросе хотя на некоторое время и начать работать вплотную на остальными подсистемами. Вот?
Имхо игоровой объект это не ресурс, это что-то которое является управленцем на этими ресурасами. И то над чем подсистемы производят манипуляции... Надеюсь понятно. Честно говоря на этот вопрос мне не смогли ответить на gamedev.ru. Отчасти из-за того, что у меня не хватает опыта, отчасти имхо из-за того что это очень большой вопрос, что бы его можно было обсудить в рамках форума. А в отчачсти, по тому, что все его решают итеративым путем, постоянно улчшая, но имхо этот путь закончиться тем, что эту подсистему будет очень сложно понять и она будет пронизана всякими перекресными связями. Хотя я все чаще начинаю слышать такое мнение, что мол не надо пытаться сделать схему для того же рендера, ибо это просто не возможно, ведь каждый новый спецэффект приводит к тому что надо лезть в разные части подсистем менять что-то там без просу. Имхо это так, ведь игровой двиг, в частности рендер нужен как раз для быстродействия а внутри это очень сложно сделать, если не поступиться некоторыми дизайнерскими принципами. Заметьте я никоим образом не хочу сказать что невозможно сделать такой рендер, я просто хочу сказать что этим занимаются новички, которые начитались ООП и паттеронов проектирования (я один из них Smile ) и думают, что они все могут помочь решить. и в силу своей неопытности делают бред. Заниматься универсализацией того же рендера надо только тогда, когда это уже не первая твоя выпущенная игра, и ты начал замечать что-то ты делаешь плохо, ведь каждую новую игру приходиться писать почти заново.

Фу лано что-то я разошелся. Давайте критику......... Smile

Submitted by BronX on

Хех тут вариантов может быть много

Например всё хранить в дереве, причем дереве где каждый уровень ниже содержит какуюто абстракцию

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

но основная проблемы выплывает когда тебе надо объеденить несколько обьектов(звук рендер физика) и работать с ним как с цельным обьектом, это уже каждый вибирает для себя либо сложную ООП модель делать, либо писать всё на шаблонах, либо писать всё в геймспецифик хардкодом, много различных подходов Smile

Далее по поводу универсальности - понятное дело что универсальную модель легко превратить в специфичную, но не наоборот, проблема найти эту универсальную модель.

По поводу перфоманса - 90% процессорного времени в 15% кода, поэтому оптимизация - дело на этапе RELEASE_CANDIDATE, но это не значит что можно вообще не задумываться над перфомансом, в общем баланс, кто его правильно зафиксирует - тот добьется успеха Smile

Submitted by Relyer on

>>но основная проблемы выплывает когда тебе надо объеденить несколько обьектов(звук рендер физика) и работать с ним как с цельным обьектом, это уже каждый вибирает для себя либо сложную ООП модель делать, либо писать всё на шаблонах, либо писать всё в геймспецифик хардкодом, много различных подходов :-)


Так вот в этом то собственно и был вопрос, как лучше это сделать. Т.е. плюсы и минусы разных подходов, где могут быть подводные камни ну и так далее...

Submitted by BronX on
Короче понятно, либо тема слишком серьезная либо ... :)
Буду разбираться как всегда в гордом одиночестве изучаю творения кармака и других опенсорс творений.

Если к чему интересному приду обязательно отпишусь. Smile

Submitted by BronX on

GameDev.by