ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!
|
| » Тру ООП (мышление объектами) | страница 1 |
|
|
|
|
Канал Игры Мечты: «Тру ООП (мышление объектами)» |
|
|
|
Shirson
 1605 EGP
     
Рейтинг канала: 7(626)
Репутация: 219
Сообщения: 16511
Откуда: 79°W 44°N
Зарегистрирован: 29.01.2002
  |
|
Коллеги, тут у меня возник некоторый вопрос.
Хочется познать сие Дао в полной мере и представить себе, как что-то делать в тру-ООП стиле, без оговорок.
Без каких-либо привязок к языку программирования (это ключевой момент).
Например, возьмём всем известный и понятный образец для реализации - Элиту.
Как будет организована её объектаная модель?
Как осуществлять покупку и продажу товаров, например?
Как организовать бой на лазерах?
Как будет работать ЕCM?
Каждая часть оригинала интересует, но в ракурсе тру-ООП.
(Напомню - вопрос по концепции ООП, и совершенно не по конкретному языку. Никаких упоминаний существующих языков)
Кто поделится идеями?
_________________
У меня бисера не доxеpа. |
|
|
|
бухой джедай
182 EGP
Рейтинг канала: 2(19)
Репутация: 70
Сообщения: 7906 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
 |
|
ну блин сразу скажу я в элиту много не играл так что частности могу путать плюс ниже сказаное лично мое ИМХО оно может не сростатся с мнениями других ....
1. Объектная модель
1) исходим из того что у нас первично ...
относительно Элиты я могу предполагать что первично у меня 2 вещи ...
а)сектор космоса
б)объект в космосе
А) Сектор в космосе имеет свои характеристики , если Секторов мб несколько типов (предположим : солнечная система,планета ,неведомая херня)
то для родительского класса (сектор космоса ) определяются общие для всех характеристики ,а для дочерних (солнечная система, планета ,неведомая херня) те характеристики которые их отличают друг от друга (например у солнечной системы это характеристики звезды , у планеты это допустим особености строения, у неведомой херни еще что то ) , соответсвенно и для классов прописываются те методы которые необходимы для их непосредственного использования , например для солнечной системы мб пригодится расчет освещенности в зависимости от расстояния до солнца , что мб избыточным для случая блуждающей планеты .Если методы необходимы для функционирования и тех и тех объектов то желательно их прописывать в родительском классе
добавлено спустя 59 минут:
2. Как осуществлять покупку и продажу товаров, например?
исходим из того что у нас реализована структура Объектов по которой мы наследуем
1)класс "Станция" с характеристикой "Трюм" (являет из себя список объектов класса "Товар"),характеристикой "Счет"(натуральное число) и методом "ДайСписокТоваров".
2)класс "Товар" с характеристиками "Цена" (натуральное число),"Объем" (натуральное число),"Владелец" (какой либо идентефикатор) и методом "Продать"
3)класс "1 Физическое Рыло" с характеристикой "Счет" (натуральное число) и Индификационный Код (какой либо идентефикатор)
добавлено спустя 12 минут:
маханизм прост метод "ДайСписокТоваров" обращается к характеристике Станция->Трюм и получает список того что в этой станции есть каждый пункт списка это Объект класса "Товар"
и возможно юзать метод Товар->Продать получаюший идентефикаторы Владельца, Покупателя по индефикаторам подгружающего соответсвенно Объекты класса "1 Физическое Рыло" и переводя с 1 Физическое Рыло->Cчет "Покупателя" на 1 Физическое Рыло->Cчет "Владельца" средства и меняя Товар->Владелец на ИНН покупателя
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист...
Последний раз редактировалось: бухой джедай (22:38 23-11-2013), всего редактировалось 5 раз(а) |
|
|
|
Minx
 987 EGP
   
Рейтинг канала: 6(329)
Репутация: 135
Сообщения: 10533
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
ООП представляет собой прежде всего объектную декомпозицию, которая в первую очередь является элементом архитектуры приложения.
Чтобы не писать много всего, обращу внимание на две важные вещи.
Во-первых, не бывает правильных декомпозиций (и ООП в том числе). Есть декомпозиции со своими свойствами. И все зависит того, какое будущее будет у задачи.
Особенность в том, что как только мы вводим в проект новую сущность, то мы моментально её получаем как независимый элемент (можем использовать отдельно и независимо, что плюс), но в то же время, мы ограничиваем гибкость наших решений в будущем (любая сущность это делает).
Например джедай ввел сущность "сектор космоса". С одной стороны, удобно пользователю показывать разные сектора как отельные элементы, привязывать к ним ID, организовывать поиск и прочее. Но с другой стороны, бесшовный космос с этой сущностью будет кошмаром и гемороем.
Т.е. если мы создаем класс "сектор космоса", то мы автоматически подписываемся под теми ограничениями, которые он накладывает, и в будущем нам придется с этим жить.
Во-вторых, создаваемые ООП-сущности должны быть независимыми и выпиливаемыми.
Это означает, что любую из них вы должны в состоянии выделить, обнести забором (т.е. интерфейсом), и положить на полочку.
Что ещё раз в свою очередь означает: эта сущность должна быть на этой полочке полностью протестирована, в идеале 100% (1) и использована при необходимости ещё раз (2).
---
Если мы берем Элиту как готовую игру за образец, т.е. повторить то, что уже есть, то ООП-решения принципиально отличаются от того случая, когда мы разрабатываем что-то тогда, когда ничего не понятно из того, что будет на выходе.
Кроме того, сила ООП также заключается в повторном использовании наработок. Поэтому важно создать такие сущности, которые мы могли бы потом быстро использовать и адаптировать в будущем.
---
Если говорить о тру-ООП, то для тру- достаточно соблюсти правила ООП (все элементы есть объекты, все объекты созданы от классов, все классы в иерархии наследования).
Далее - все решения уже имеют свои достоинства и недостатки. Какие-то будут тяжелы в усвоении, какие-то быстро написаны, какие-то труднотестируемы, какие-то не выживут при первом чихе заказчика и т.д.. Поэтому можно порассуждать о каких-либо конкретных ООП-примерах, но все они будут разные и среди них не будет правильных.
---
Поэтому, на основании вышесказанного.
| бухой джедай : |
|
исходим из того что у нас первично
|
Первично не имеет никакого значения. Выбирается то, что железобетонно. То, что изменится с малой вероятностью в будущем.
В Элите сектор может быть просто нарисован по координатам объекта пользователю, а таким же макаром название сектора прикручено к названию объекта.
Т.е. сектор совсем необязательно делать отдельным классом. Это может быть просто функция (x,y,z) как номер сектора, рассчитываемая на объекте каким-либо образом.
| бухой джедай : |
Сектор в космосе имеет свои характеристики , если Секторов мб несколько типов (предположим : солнечная система,планета ,неведомая херня)
то для родительского класса (сектор космоса ) определяются общие для всех характеристики ,а для дочерних (солнечная система, планета ,неведомая херня) те характеристики которые их отличают друг от друга (например у солнечной системы это характеристики звезды , у планеты это допустим особености строения, у неведомой херни еще что то ) , соответсвенно и для классов прописываются те методы которые необходимы для их непосредственного использования , например для солнечной системы мб пригодится расчет освещенности в зависимости от расстояния до солнца , что мб избыточным для случая блуждающей планеты .Если методы необходимы для функционирования и тех и тех объектов то желательно их прописывать в родительском классе
|
При декомпозиции важно не разбирать конкретные объекты (солнце, планета, бла-бла-бла), а выделять конкретные свойства и характеристики, и по ним уже проводить декомпозицию.
Поэтому в иерархии более предпочтетнльны классы "Светящийся", "Круглый", "Блуждающий" и т.п.. Потому что в следующий раз появится комета, и начнется перепиливание всей иерархии, что череповато.
| бухой джедай : |
|
исходим из того что у нас реализована структура Объектов по которой мы наследуем
|
Исходим из того, какие задачи мы выполняем. И из них строятся интерфейсы классов объектов. Т.е. кто кому что должен, какие задачи решает и какие обязательства на себя берет.
Изначально может стоять задача выдачи кому-то списка товаров (например пользователю при просмотре что можно купить). Если такая задача есть, то только тогда запускается все остальное. И в этом ключе надо уже понимать, например что вдруг список для нелегала и список для налоговой будут несколько отличаться.
В качестве другого ракурса. При существующей схеме уже будет затруднительно организовывать бартер. Кроме того, если вдруг на станции окажется несколько торговых точек, то интерфейс придется переделывать. В связи с этим надо сразу себе задавать вопросы - а нада ли нам вот эта или вот эта гибкость, и во что обернутся такие-то архитектурные решения?
---
В ООП-проектировании крайне важна разработка не только сверху вниз, но и снизу вверх. Тот же список товаров может быть задействован не только для станции, но и для пилота (чтобы торговать друг с другом на станции или в открытом космосе например), или для контейнера (в космосе, только с ним торговать не получится).
| Shirson : |
|
Как организовать бой на лазерах?
|
В качестве ни к чему не обязывающего примера в вакууме.
В системе существует множество объектов. Ими рулит диспетчер (периодически их обрабатывает).
Объекты могут быть рисовабельны (если да, то скармливаются движку рендеринга), AI-обладающи (запускается специальный метод думания), попадабельны (можно попасть лазером), потенциально-человеком-управляемы (корабль, ракета-оператор) и т.д..
Когда кто-то нажимает гашетку, то проверяется, что обладатель стреляющ. Если да, то создается событие выстрела и отдается диспетчеру, а тот на своем конвеере его обрабатывает, создавая объекты-спецэффекты, выравнимания очередь попадания (чтобы не было два убийства одного объекта от одновременного выстрела), дергая другую логику (а может человек уже умер? тогда отключить рисовалку и передать на геймовер; а вот тебе, объект, только что сделали дамаг в 100 попугаев - признавайся, что с тобой произошло?). Диспетчер может обрабатывать разные события (парковка в станцию, врезание в планету). Новые объекты могут быть быстро добавлены (если добавляется космическая птица-говорун, то достаточно ответить на вопросы базовых интерфейсов - он стреляющ?, попдаем?, рисуем?, AI-управляем? и т.д..; каждый интерфейс потребует реализации соответствующих методов, и после этого говорун будет жить с остальным миром).
_________________
μηδείς αγεωμέτρητος εισίτω
Последний раз редактировалось: Minx (11:34 24-11-2013), всего редактировалось 2 раз(а) |
|
|
|
бухой джедай
182 EGP
Рейтинг канала: 2(19)
Репутация: 70
Сообщения: 7906 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
|
|
| Minx : |
|
Первично не имеет никакого значения. Выбирается то, что железобетонно. То, что изменится с малой вероятностью в будущем.
|
насколько оно железобетонно зависит от того правильно ли мы выбрали и сформулировали объект от которого будем толкаться , и вопрос об его изменении в будующем зависит от того-же
| Minx : |
|
Поэтому в иерархии более предпочтетнльны классы "Светящийся", "Круглый", "Блуждающий" и т.п.. Потому что в следующий раз появится комета, и начнется перепиливание всей иерархии, что череповато.
|
очень сильно зависит от задачь ... во многих прикладных как раз таки этот подход будет не совсем верным ...
добавлено спустя 5 минут:
к тому же если подходить из моей логики любая нестандарная локация от сектора в космосе это лишь доп дочерний класс реализованный под какие-то нестандартные условия , а конкретно звезда , планета , комета и прочее внутри сектора с их поведением будет прямо либо опосредованно наследоваться от "объект в космосе" ... да и там если и будут промежуточные классы типа ("Светящийся", "Круглый", "Блуждающий") они будут отнюдь не первыми в очереди наследования ...
добавлено спустя 7 минут:
| Minx : |
|
В качестве другого ракурса. При существующей схеме уже будет затруднительно организовывать бартер. Кроме того, если вдруг на станции окажется несколько торговых точек, то интерфейс придется переделывать. В связи с этим надо сразу себе задавать вопросы - а нада ли нам вот эта или вот эта гибкость, и во что обернутся такие-то архитектурные решения?
|
Orly ? честно просто как 2 пальца ( что обмен партия на партию что обмен по соотношению стоимости потребуют лишь дописать методы в класс "Товар") а проблема с множеством точек продажи это проблема с непостановкой этого в тз как необходимости мб я чтото забыл или переигрался потом в иксы но в элите не было множества продавцов на станциях
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист...
Последний раз редактировалось: бухой джедай (10:16 24-11-2013), всего редактировалось 3 раз(а) |
|
|
|
Minx
987 EGP
Рейтинг канала: 6(329)
Репутация: 135
Сообщения: 10533
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| бухой джедай : |
|
правильно ли мы выбрали
|
"правильно" ли выбрали - это демагогия. нет правильных решений
Железобетонность - наши личное субъективное предсказание. Правильность - это неведомая херня, которую каждый трактует как попало.
Иерархии классов не толкаются от каких-либо сущностей - они необязательно древовидны.
| бухой джедай : |
|
во многих прикладных
|
Во многих прикладных применение ООП-подхода будет в корне противопоказанным. Не то что о каких-то принципах.
Читайте внимательно - ключевое слово "предпочтительны". А от вашей способности выбрать функцию предпочтительности зависит будущее проекта.
| бухой джедай : |
|
не первыми в очереди наследования
|
Нет очереди наследования. Есть набор свойств, из которых собираются новые сущности. Сущность "звезда" более конкретна, чем "святящийся", и не описывает того, чего мы от этой сущности хотим. Потому звезды менее железобетонны, чем светящийся объекты.
| бухой джедай : |
|
в элите не было множества продавцов на станциях
|
Речь идет о гибкости архитектурных решений, о понимании свойств того, что будет на выходе. В этом заключается искусство разработки.
А не о игре в конкретные игры.
_________________
μηδείς αγεωμέτρητος εισίτω
Последний раз редактировалось: Minx (11:29 24-11-2013), всего редактировалось 2 раз(а) |
|
|
|
Guest
2075 EGP
       
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
Тащемта, Минкс всё расписал...
| Minx : |
|
Во-первых, не бывает правильных декомпозиций (и ООП в том числе).
|
Ну почему же, вон у Зачесы была правильная декомпозиция... До кварков включительно...
| бухой джедай : |
|
2)класс "Товар" с характеристиками "Цена" (натуральное число),"Объем" (натуральное число),"Владелец" (какой либо идентефикатор) и методом "Продать"
|
Не должно быть у него метода "Продать", т.к. оный зависит от контекста. Инкапсуляция жеж. "товар" тут = "груз". Он может лежать в трюме, может обладать свойствами, но действовать он по-хорошему может только в отношении себя без конкретной ситуации. Например, он может протухнуть независимо от того, где и как он находится, т.к. для этого нужен всего лишь системный таймер и свойство "время оставшейся жизни".
Это у его надмозга (станции, трюма) может быть метод продатьТоварНаглойРыжейМорде(товар Item, морда Person, bool Бесплатно). Он же может и цену за товар отличной от базовой показать...
| Minx : |
|
Особенность в том, что как только мы вводим в проект новую сущность, то мы моментально её получаем как независимый элемент (можем использовать отдельно и независимо, что плюс), но в то же время, мы ограничиваем гибкость наших решений в будущем (любая сущность это делает).
|
Ну, всегда можно написать расширение сущности, дорисовав к новой (или даже старой) реализацию ещё какого-нибудь интерфейса...
_________________
Трещит земля как пустой орех
Как щепка трещит броня |
|
|
|
бухой джедай
182 EGP
Рейтинг канала: 2(19)
Репутация: 70
Сообщения: 7906 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
|
|
| Minx : |
|
Речь идет о гибкости архитектурных решений, о понимании свойств того, что будет на выходе. В этом заключается искусство разработки.
|
ну и какую гибкость решений мы можем изобретать если мы например вместо следования той же относительно понятной логике\классификации с конкретными отличительными чертами и особенностями поведения мы начинаем придумывать собственный велосипед который хрен его знает как начнет с ней конфликтовать хотя-бы потому-что например у сущности "Светяшийся" в контексте например какого нибудь куска космоса слишком много вероятных наследников с совершенно разными свойствами , а если оставить велосипеды велосипедистам а понятие излучает ли сущность или не излучает вынести как раз таки в свойство конкретного объекта , мы решаем вагон проблем с удобством написания ... ( не надо мне утверждать что так не делают потому что так не делают... так не делали длительное время по множеству причин кроме пресловутой гибкости архитектурных решений ... и не факт что это было верным просто в тот момент это было одним из оптимальных не только с точки зрения ООП но и сточки зрения имеющихся технологий и ресурсов )
добавлено спустя 10 минут:
| Guest : |
Не должно быть у него метода "Продать", т.к. оный зависит от контекста. Инкапсуляция жеж. "товар" тут = "груз". Он может лежать в трюме, может обладать свойствами, но действовать он по-хорошему может только в отношении себя без конкретной ситуации. Например, он может протухнуть независимо от того, где и как он находится, т.к. для этого нужен всего лишь системный таймер и свойство "время оставшейся жизни".
Это у его надмозга (станции, трюма) может быть метод продатьТоварНаглойРыжейМорде(товар Item, морда Person, bool Бесплатно). Он же может и цену за товар отличной от базовой показать...
|
в чемто согласен в чемто нет ...
станция в данном случае если уж подходить с точки зрения максимальной гибкости суть простым языком контейнер в котором мб и склад и прилавок и цех и хрен с багром и перевешивать конкретный функционал склада,прилавка,цеха, хрена с багром на станку сие есть неправильно
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист...
Последний раз редактировалось: бухой джедай (12:06 24-11-2013), всего редактировалось 1 раз |
|
|
|
Minx
987 EGP
Рейтинг канала: 6(329)
Репутация: 135
Сообщения: 10533
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Guest : |
|
Ну, всегда можно написать расширение сущности, дорисовав к новой (или даже старой) реализацию ещё какого-нибудь интерфейса...
|
Дописать можно. Но тут два основных эффекта:
- "sea of classes", в котором можно утонуть;
- если уже реализованные сущности понадобились в другом месте, то придется тянуть их через все интерфейсы или выполнять дублирование; в первом случае швейцарский нож, во втором проблемы синхронизации.
Ещё каждую сущность сопровождать надо.
добавлено спустя 10 минут:
| бухой джедай : |
|
а понятие излучает ли сущность или не излучает вынести как раз таки в свойство конкретного объекта
|
Тогда уж выполняй агрегирование и для звезды. И тут-то проблемы звезды будут светить более ярко, нежели проблемы светящихся объектов.
Если возможно агрегирование по сравнению с наследованием, то оно (агрегирование) более предпочтительно, так как это более слабая связь. Наследование же имеет смысл только тогда, когда работает полиморфизм. Наследование как попало усложняет иерархию и навигацию в проекте.
Таким образом, логика примерно такова. Если у нас в проекте нужным является полиморфное действие "обработать светящийся объект", то тогда создается сущность, его выполняющая (светящийся), и те классы, которые обладают этим, от него наследуются. Таким образом на группе сущностей можно выполнить полиморфное действие (т.е. на соответствующем уровне абстракции). Например перебрать все объекты в системе, узнать кто из них светится, и кто светится, выполнить действие с свечением.
Если надобности такого действия нет, то никаких наследований не рекомендуется. (но понятно, что случаи разные бывают)
_________________
μηδείς αγεωμέτρητος εισίτω
Последний раз редактировалось: Minx (12:25 24-11-2013), всего редактировалось 4 раз(а) |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
| Minx : |
|
- "sea of classes", в котором можно утонуть;
|
Есть такое, очень неприятно, если не знаешь полную структуру. А если приходит новый человек - то он таки не знает.
_________________
Трещит земля как пустой орех
Как щепка трещит броня |
|
|
|
Minx
987 EGP
Рейтинг канала: 6(329)
Репутация: 135
Сообщения: 10533
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Guest : |
|
Есть такое, очень неприятно, если не знаешь полную структуру.
|
Проблему значительно, но частично, решают над-ООП-способы. Это структурирование сверху (группы классов как или библиотека), когда предоставляется некий фасад. А также снизу, это паттерны и структуры данных, когда создается набор отверток и задействуется много где.
А в общем же случае въехать в проект или погрузиться в контекст это не только проблема ООП. Например в том числе документация, организация в команде и пр..
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
ООП давно не труЪ 
хоть тут и просили без языковой конкретики, но она накладывает своё, и где-то сделана просто отвратно
откуда растут длинные запутанные параллельные иерархии объектов aka гадкая древовидная хуйня (авторская орфография сохранена)
сама идея хранить нечто по указателю, и не знать что именно ты хранишь, ущербна по сути, и никакими виртуальными методами это не восполнить
сейчас лучше смотреть в сторону компонентно-ориентированных систем, по приведённой ссылке раз, Unity3D два
но декомпозицию объектов надо уметь проводить, да, прям как в ООП 
добавлено спустя 4 минуты:
З.Ы. ага, про паттерны, это набор костылей к ООП, чтобы хоть как-то передвигаться можно было (фух, кажись высказался)
З.З.Ы. и напоследок немного конструктива с оттенком имхо, на практике обычно используются три разновидности элементов/объектов, это данные, контейнеры и т.н. менеджеры
вопрос парадигм это смещение акцентов где именно происходит обработка данных, в ООП обработка находится в самих данных, менеджеры (сами рекурсивно являясь объектами) просто дёргают подчинённые объекты за ниточки/методы, в процедурном подходе менеджеры уникальны (существуют в одном экземпляре) и вырождаются в функции, которые суть обработчики данных, это разные полюса тксказать
_________________
This is what you get ...
(c) Radiohead
Последний раз редактировалось: Sh.Tac. (18:40 24-11-2013), всего редактировалось 2 раз(а) |
|
|
|
Minx
987 EGP
Рейтинг канала: 6(329)
Репутация: 135
Сообщения: 10533
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
Sh.Tac., прочитай внимательно что написал топикстартер. Вопрос в грамотном применении ООП, а не в холиварах.
Функциональную декомпозицию тоже надо уметь делать. И прострелить себе ногу можно точно также, как и в объектах.
Людей, которые не освоили паттерны, могу только пожалеть. Это совершенно отдельное направление, к основным парадигмам относящееся косвенно.
_________________
μηδείς αγεωμέτρητος εισίτω
Последний раз редактировалось: Minx (19:02 24-11-2013), всего редактировалось 1 раз |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
ООП это холиварная красная тряпка, можно посмотреть на примере других форумов
| Minx : |
|
Вопрос в грамотном применении ООП
|
так уже сам же и ответил, что не бывает правильных декомпозиций, следовательно нельзя грамотно применить, можно тока долго рассуждать о красоте теории 
в качестве стартового отсчёта рекомендую использовать декомпозицию моделируемого мира 1:1 как он есть, потом по ходу смотреть почему это неудобно
добавлено спустя 10 минут:
З.Ы. вот ещё вспомнил, если речь про игры, то там обычно есть две ортогональные сущности, локация и игрок, всё остальное так или иначе привязывается к ним (за исключением служебных сервисов, логгера, скажем, или системы кланов), и вся игра по сути строится на пересечении этих двух основ
добавлено спустя 24 минуты:
З.З.Ы. и ещё, всё же есть некоторые характеристики позволяющие отличить годную декомпозицию от негодной, это связность и сцепление классов, в идеале сильное сцепление и слабая связность
добавлено спустя 27 минут:
| Minx : |
|
Людей, которые не освоили паттерны, могу только пожалеть
|
на эту подколку могу тока боян про езду на велосипеде: 1 не умеешь и не едешь, 2 не умеешь и едешь, 3 умеешь и едешь, 4 умеешь и не едешь
_________________
This is what you get ...
(c) Radiohead
Последний раз редактировалось: Sh.Tac. (20:25 24-11-2013), всего редактировалось 3 раз(а) |
|
|
|
Minx
987 EGP
Рейтинг канала: 6(329)
Репутация: 135
Сообщения: 10533
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Sh.Tac. : |
|
следовательно нельзя грамотно применить
|
Нельзя применить идеально на все случаи жизни. Но можно более грамотно применить, и менее грамотно. Если твое решение выжило в схватке со временем, то это факт в пользу грамотности. И наобормот.
| Sh.Tac. : |
|
рекомендую использовать декомпозицию моделируемого мира 1:1 как он есть
|
Что под этим имеется ввиду?
| Sh.Tac. : |
|
боян про езду на велосипеде
|
5 умеешь и ездишь тогда, когда это востребовано.
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Minx : |
|
Что под этим имеется ввиду?
|
доводилось видеть такое, например есть корабель, и есть чувак, в реальном мире чувак сидит в корабле, следовательно корабель содержит чувака (это 1:1)
на практике это предельно неудобно, поэтому более важными являются отношения принадлежности, и как я уже говорил, весь хабар (включая заводы и корабли) тупо вешается на игрока
вот, добрался до стартовых вопросов, они все сложные, это целые подсистемы и нужно дофига всего чтобы заработало, я попробовал начать перечислять и у меня стал получаться охрененный список, и это ещё по-верхам, всегда легко что-то упустить, без чего не будет работать
З.Ы. единственное, что могу отметить, что все сущности должны быть достаточно абстрактными, как то Item (это просто структура с айдишкой), Inventory (это просто контейнер айтемов), и можно перекладывать айтемы из контейнера в контейнер, а также создавать айтемы при помощи Factory, и возможно удалять, например перекладывая в трешовый контейнер и удаляя его
на основе этой базовой функциональности можно дальше делать корабли, магазины, лутать поверженных противников и т.д.
уже конкретные шмотки это просто ресурсы в терминах системы, геймдизайнер может их легко добавлять и менять по сто раз на дню, и про всякие различия в их поведении знает только конкретная игровая логика (скрипт)
З.З.Ы. тут история в целом такая же как с геймдизайном, есть некоторые механизмы на уровне системы которым пофиг чем оперировать, и есть уже потом конкретное наполнение, т.е. код игры типа Элита и код игры <впишите-здесь-любую-игру> по сути ничем не отличается
_________________
This is what you get ...
(c) Radiohead
Последний раз редактировалось: Sh.Tac. (23:30 24-11-2013), всего редактировалось 3 раз(а) |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
Проситите, не все прочитал.
Объект
Трансформация (позиция + поворот)
абстрактный метод Update(dt)
----
Физический объект : Объект
Масса
Геометрия для просчета коллизий
+применить силу
и т.п.
----
Видимый объект : Объект
Геометрия[кол-во LOD'ов]
Материал (шейдеры/текстуры/параметры всякие)
----
Менеджеры физики / Менеджер сцены / Рендерер -- надо описывать?
--------
Слой игры
ОбъектИгры : ФизическийОбъект, ВидимыйОбъект
----
АбстрактныйОбъектСТрюмом : ОбъектИгры
объем
объекты в трюме
абстрактный метод положить в трюм
абстрактный метод вытащить из трюма
----
Станция : АбстрактныйОбъектСТрюмом
цены на товары
пристыкованые корабли
раса
----
Выстрел : ОбъектИгры
хозяин_выстрела
----
Игрок
текущий_корабль
собственность
деньги
...
----
Как-то так. Что-то надо описать еще?
| Shirson : |
|
Как будет работать ЕCM?
|
Что такое ЕСМ?
_________________
MOV topka, C++
Последний раз редактировалось: Jurec (14:48 25-11-2013), всего редактировалось 1 раз |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
Electronic Counter Measures вестимо, чисто игровой прибабах (с оговоркой на фкозмозе разумеется)
всё прочитать невозможно, и вообще я склоняюсь, что программасту проще кодом, нежели на пальцах объяснять, всё короче выйдет
З.Ы. я тут тока до поста бухого джедая добрался, могу отметить, что товар как сущность неуместная единица, что такое товар? правильно, всё что угодно, в т.ч. корабли и станции, поэтому нужно просто дать возможность вешать ценник на любой объект, вот и выйдет товар
_________________
This is what you get ...
(c) Radiohead
Последний раз редактировалось: Sh.Tac. (15:06 25-11-2013), всего редактировалось 1 раз |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
| Sh.Tac. : |
|
Electronic Counter Measures вестимо, чисто игровой прибабах (с оговоркой на фкозмозе разумеется)
|
Тогда он висит как подсистема у корабля.
Подсистема может быть активирована.
Вот у ECM по активации идет запрос у менеджера физ объектов - найти объекты в радиусе R от позиции корабля, где активирована система.
Найти среди объектов ракеты и вызвать им детонацию.
Все просто
_________________
MOV topka, C++ |
|
|
|
бухой джедай
182 EGP
Рейтинг канала: 2(19)
Репутация: 70
Сообщения: 7906 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
|
|
| Sh.Tac. : |
|
З.Ы. я тут тока до поста бухого джедая добрался, могу отметить, что товар как сущность неуместная единица, что такое товар? правильно, всё что угодно, в т.ч. корабли и станции, поэтому нужно просто дать возможность вешать ценник на любой объект, вот и выйдет товар
|
товар мб просто объектом с идентификатором чего угодно , идентификатором Владельца этого чего угодно и ценой.
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист... |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
Народ, че ж вы такое сложное решение придумываете?
_________________
MOV topka, C++ |
|
|
|
|
|
|
|
|
Канал Игры Мечты: «Тру ООП (мышление объектами)» |
|
|
|
