Войти
ПрограммированиеФорумОбщее

Компонентная система игровых сущностей. (комментарии) (27 стр)

Страницы: 124 25 26 27 28 29 Следующая »
#390
17:49, 12 янв. 2013

3eR0.1ive
> Ты чего сказать-то хотел? Расстроился чтоли просто?
С чего бы мне расстраиваться? - пока вы в *опе я в топе ;)


#391
17:55, 12 янв. 2013

AlexCraft
> я в топе
Господин, топай мимо в свой мнимый топ, дрожащими от самосовершенства руками поддеживая своё чувство важности в кибермире.

#392
14:57, 22 мар. 2013

Снова назрел вопрос.
Не однократно в теме писалось про возможность присвоения любому аспекту чилда.
Вопрос, можно конкретный пример, для чего? Я так и не понял.
Допустим с трансформом все ясно - корень объекта, от него породнились все аспекты. А вот бывают ли такие ситуации, когда MeshAspect_1 выступает родителем MeshAspect_2 ? Грубо говоря. Или PhysicsModel_1 -> PhysicsModel_2 ? Чисто интересно, так как у себя я не нашел способ применения этого, или я как то не правильно думаю.

#393
15:05, 22 мар. 2013

И еще. Есть 5 ящиков с одинаковым мешем, рендер аспектом и материалом. Их отличие только в трасформе - один ребром повернут, другой на земле, третий в воздухе.
В основном дереве объектов, в качестве ноды выступает трансформ объекта, и уже в этой ветке - набор новых аспетков или ссылки на существующие.
Потом рендер проходит по этому дереву, по нодам, забирает нужные в данный момент объекты себе в граф.
Мне не нравиться что-то этот способ, что тут можно изменить? Или же я заблуждаюсь?
Мне предлагали вынести меш в ресурсы. Сделать граф ресурсов и менеджер их. И создавая компонент меша, биндить к нему геометрию. Мне это тоже не понравилось. Мало того, что усложниться прозрачность рендера, в памяти будут создаваться не ссылки на аспекты, а ненужные фантомы с одинаковыми параметрами.

#394
14:21, 24 мая 2013

Смотрел ету статью: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
Я так понял что тут пишет что обьекта как такого не существует.
Здесь обсуждали двойственные имена, например:
character.transform
character.geometry0
character.geometry1
character.material0
character.skeleton0
character.sound0
...
И все ети компоненты не обьединены в структуре или классе? Иначе зачем такие имена?
Тогда связь обьекта - ето имя компонента, и при рендере надо перебирать список компонента transform чтобы отрендерить некую сущность в правильной позиции?

#395
1:38, 25 мая 2013

Каждый компонент выполняет роль. Роль описывается интерфейсом. Одну и туже роль можно реализовывать по разному. Композицию объектов составляют либо в реал тайме либо компилет тайм. Камопннет-клиент запрашивает необходимые ему роли у компонента-сервера. Любой компонент может быть и клиентом и сервером. Но все же желательно чтобы зависимости были деревом а не графом. В идеале MVC - Подмножество компонентов определяет модель, подмножество отображение и подмножество связывает модель и отображение.

#396
5:28, 23 июня 2013

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

#397
14:15, 23 июня 2013

а что непонятного? : )

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

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

#398
14:24, 23 июня 2013

>можно сделать жирный объект, в котором будут все поля и методы, необходимые перечисленным подсистемам

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

В случае жирного объекта подсистемы ровно так же ничего не знают про другие части этого жирного объекта.

#399
14:31, 23 июня 2013

x
> В случае жирного объекта подсистемы ровно так же ничего не знают про другие
> части этого жирного объекта.
но при этом в кеш попадает много лишних данных, из-за чего упадет скорость обработки

#400
14:54, 23 июня 2013

x
> В случае жирного объекта подсистемы ровно так же ничего не знают
есть соблазн сделать жирный объект посредником между подсистемами : )
т.к. работать они должны хоть и независимо, но согласовано

#401
18:02, 23 июня 2013

Все равно не понятно. Ну вот конкретный пример: 2Д игра. Лабиринт - двумерный массив. На нем бегают враги, и главный герой. Как это сделать компонентно? При условии, что все движущиеся объекты должны знать о массиве, чтоб правильно двигаться. Враги должны знать о герое, чтоб знать куда им прокладывать путь в массиве. А герой должен знать о врагах, чтоб фиксировать соприкосновение с ними.

#402
18:35, 23 июня 2013

надо прикинуть подсистемы/сервисы: контроллер пешки (для игрока управляется через input, для мобов через AI), pathfinder и collision detection

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

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

#403
21:39, 23 июня 2013

Pushkoff
>но при этом в кеш попадает много лишних данных
Ну сама по себе агрегация не улучшает ситуацию никак. Только если составные части лежат в отдельных массивах где-то снаружи "жирного объекта".
Так что это не есть прямое следствие выделения пачки свойств в объект.

Sh.Tac.
Ну так соблазн не является характеристикой какого-либо архитектурного решения)

Я к тому что объяснение идеи какое-то неубедительное, потому непонятное. Но в #402 уже нагляднее.
Однако всё равно вопрос.

>персонажа как такового по сути нет, он представлен своими минимально необходимыми отображениями/аспектами в каждой из подсистем
Число жизней, текущее оружие, позиция и скорость, это всё где лежит?

#404
22:47, 23 июня 2013

x
> Число жизней, текущее оружие, позиция и скорость, это всё где лежит?
Где то точно лежит, суть компонентной системы в том, что нет единого объекта.
Каждая компонента может взаимодействовать с другими компонентами и подсистемами.
И это заранее определено в редакторе, там же все линкуется, и поставляется в игру в виде например файла First.lvl или Characters.хз

пс. на правду не претендую

Страницы: 124 25 26 27 28 29 Следующая »
ПрограммированиеФорумОбщее