Я тут смотрю мало у нас обсуждений, я уже как почти пол года назад зарегился, а вот никак не мог написать что-нить на форуме.Я конечно понимаю, что все мы умеем посылать в гугл, или на 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 будет содержать в себе мешь, материал, настройки состояний рендера, т.е. формирования батчей тоже идет только благодаря этой энтити цельного игрового объекта.
) Ведь смысл управлять ии, колесом машины Хотя это мое имхо.//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;};Да тут кстати встает еще один немаловажный вопрос как эти подсистемы будут между собой общаться. Меседжы, эвенты, функции обратного вызова? Не наю, надо думать, мот кто что посоветовать может буду рад, но пока не решил еще что будем использовать.
Высказывайтесь, советуйте, только просьба не надо превращать топик в фарс, я его написал, не столько для знаний, сколько для рекламы нашего сайта Давайте просто обсуждать наболевшую тему, ведь форум именно для этого и предназначен. да?
P.S.2 Респект создателям сайта, настойки для ввода текста на форуме действительно удобные, имхо может лучше даже чем на .ru :)
В самых лучших книгах написано то что мы итак уже знаем (с) Дж. Оруэлл
Модель сия очень абстрактна и несмотря на упрощенный вид очень наворочена. Даже я бы сказал черезчур наворочена. Мало игр имеют настолько закрученную модель в отношении составления объектов. Настороженность вызывает что данная модель зделана под все и ничего конкретно. ее сложно будет оптимизировать хотя в теории легко будет адаптировать.
И как в любой сложной объектной модели (в особенности на с++) один из самых важных вопросов: а как всю это фиговину превратить в нечто единое, синхронизированное и живое? Проще говоря: как сделать обмен данными между объектами, да еще и чтоб побыстрей было (игровой движок всетаки). Основная проблема: как изменить объект и уведомить об этом все другие объекты, которые его используют. Т.к. это игра то объекты, которые используют главный могут еще и какието свои данные в целях оптимизации хранить.первое, что приходит в голову это куча глобальных или статических функций вида:
set_xxx_property(Manager &manager,Manager::Handle &handle,Object &object,Object::property new_property); которые бы учитывали состояние объекта в рамках того что этим объектом пользуется. Вариант экономичный по отношению к памяти но некрасивый. Он плавно перерождается в идею хранить в объекте указатели на то что им пользуется и при изменении свойств через эти указатели уведомлять "пользователя", читай callback. сей вариант менее экономичен с точки зрения памяти да и не всегда оправдан но достаточно удобен.И наконец Метод "влоб". Каждый раз узнавать характеристики объекта и подстраиватся при рендеринге, обсчете ИИ или механики.Не всегда снижает производительность да и метод весьма простой: поменял переменную, а рендерер на следующем проходе сам все сделает. Кстати этот метод неплохо подходит для модели, изображенной на схеме
P.S. Фигню какуюто я написал