Elite Games - Свобода среди звезд!
.
  » Тру ООП (мышление объектами) | страница 1
Конференция предназначена для общения пилотов. Для удобства она разделена на каналы, каждый из которых посвящен определенной игре. Пожалуйста, открывайте темы только в соответствующих каналах и после того, как убедитесь, что данный вопрос не обсуждался ранее.

Поиск | Правила конференции | Фотоальбом | Регистрация | Список пилотов | Профиль | Войти и проверить личные сообщения | Вход

   Страница 1 из 3
На страницу: 1, 2, 3  След. | Все страницы
Поиск в этой теме:
Канал Игры Мечты: «Тру ООП (мышление объектами)»
Shirson
 1604 EGP


Модератор
Рейтинг канала: 7(626)
Репутация: 217
Сообщения: 16511
Откуда: 79°W 44°N
Зарегистрирован: 29.01.2002
Коллеги, тут у меня возник некоторый вопрос.
Хочется познать сие Дао в полной мере и представить себе, как что-то делать в тру-ООП стиле, без оговорок.
Без каких-либо привязок к языку программирования (это ключевой момент).

Например, возьмём всем известный и понятный образец для реализации - Элиту.
Как будет организована её объектаная модель?
Как осуществлять покупку и продажу товаров, например?
Как организовать бой на лазерах?
Как будет работать ЕCM?
Каждая часть оригинала интересует, но в ракурсе тру-ООП.

(Напомню - вопрос по концепции ООП, и совершенно не по конкретному языку. Никаких упоминаний существующих языков)
Кто поделится идеями?
_________________
У меня бисера не доxеpа.
    Добавлено: 20:45 23-11-2013   
бухой джедай
 151 EGP


Рейтинг канала: 2(19)
Репутация: 67
Сообщения: 7879 Предупреждений: 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 раз(а)
    Добавлено: 22:38 23-11-2013   
Minx
 907 EGP


Модератор
Рейтинг канала: 6(320)
Репутация: 140
Сообщения: 10416
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
ООП представляет собой прежде всего объектную декомпозицию, которая в первую очередь является элементом архитектуры приложения.

Чтобы не писать много всего, обращу внимание на две важные вещи.

Во-первых, не бывает правильных декомпозиций (и ООП в том числе). Есть декомпозиции со своими свойствами. И все зависит того, какое будущее будет у задачи.

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

Например джедай ввел сущность "сектор космоса". С одной стороны, удобно пользователю показывать разные сектора как отельные элементы, привязывать к ним ID, организовывать поиск и прочее. Но с другой стороны, бесшовный космос с этой сущностью будет кошмаром и гемороем.

Т.е. если мы создаем класс "сектор космоса", то мы автоматически подписываемся под теми ограничениями, которые он накладывает, и в будущем нам придется с этим жить.

Во-вторых, создаваемые ООП-сущности должны быть независимыми и выпиливаемыми.
Это означает, что любую из них вы должны в состоянии выделить, обнести забором (т.е. интерфейсом), и положить на полочку.
Что ещё раз в свою очередь означает: эта сущность должна быть на этой полочке полностью протестирована, в идеале 100% (1) и использована при необходимости ещё раз (2).

---

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

Кроме того, сила ООП также заключается в повторном использовании наработок. Поэтому важно создать такие сущности, которые мы могли бы потом быстро использовать и адаптировать в будущем.

---

Если говорить о тру-ООП, то для тру- достаточно соблюсти правила ООП (все элементы есть объекты, все объекты созданы от классов, все классы в иерархии наследования).

Далее - все решения уже имеют свои достоинства и недостатки. Какие-то будут тяжелы в усвоении, какие-то быстро написаны, какие-то труднотестируемы, какие-то не выживут при первом чихе заказчика и т.д.. Поэтому можно порассуждать о каких-либо конкретных ООП-примерах, но все они будут разные и среди них не будет правильных.

---

Поэтому, на основании вышесказанного.

бухой джедай :
исходим из того что у нас первично

Первично не имеет никакого значения. Выбирается то, что железобетонно. То, что изменится с малой вероятностью в будущем.

В Элите сектор может быть просто нарисован по координатам объекта пользователю, а таким же макаром название сектора прикручено к названию объекта.
Т.е. сектор совсем необязательно делать отдельным классом. Это может быть просто функция (x,y,z) как номер сектора, рассчитываемая на объекте каким-либо образом.

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

При декомпозиции важно не разбирать конкретные объекты (солнце, планета, бла-бла-бла), а выделять конкретные свойства и характеристики, и по ним уже проводить декомпозицию.

Поэтому в иерархии более предпочтетнльны классы "Светящийся", "Круглый", "Блуждающий" и т.п.. Потому что в следующий раз появится комета, и начнется перепиливание всей иерархии, что череповато.

бухой джедай :
исходим из того что у нас реализована структура Объектов по которой мы наследуем

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

Изначально может стоять задача выдачи кому-то списка товаров (например пользователю при просмотре что можно купить). Если такая задача есть, то только тогда запускается все остальное. И в этом ключе надо уже понимать, например что вдруг список для нелегала и список для налоговой будут несколько отличаться.

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

---

В ООП-проектировании крайне важна разработка не только сверху вниз, но и снизу вверх. Тот же список товаров может быть задействован не только для станции, но и для пилота (чтобы торговать друг с другом на станции или в открытом космосе например), или для контейнера (в космосе, только с ним торговать не получится).

Shirson :
Как организовать бой на лазерах?


В качестве ни к чему не обязывающего примера в вакууме.

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

Когда кто-то нажимает гашетку, то проверяется, что обладатель стреляющ. Если да, то создается событие выстрела и отдается диспетчеру, а тот на своем конвеере его обрабатывает, создавая объекты-спецэффекты, выравнимания очередь попадания (чтобы не было два убийства одного объекта от одновременного выстрела), дергая другую логику (а может человек уже умер? тогда отключить рисовалку и передать на геймовер; а вот тебе, объект, только что сделали дамаг в 100 попугаев - признавайся, что с тобой произошло?). Диспетчер может обрабатывать разные события (парковка в станцию, врезание в планету). Новые объекты могут быть быстро добавлены (если добавляется космическая птица-говорун, то достаточно ответить на вопросы базовых интерфейсов - он стреляющ?, попдаем?, рисуем?, AI-управляем? и т.д..; каждый интерфейс потребует реализации соответствующих методов, и после этого говорун будет жить с остальным миром).
_________________
μηδείς αγεωμέτρητος εισίτω

Последний раз редактировалось: Minx (11:34 24-11-2013), всего редактировалось 2 раз(а)
    Добавлено: 04:26 24-11-2013   
бухой джедай
 151 EGP


Рейтинг канала: 2(19)
Репутация: 67
Сообщения: 7879 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
Minx :
Первично не имеет никакого значения. Выбирается то, что железобетонно. То, что изменится с малой вероятностью в будущем.


насколько оно железобетонно зависит от того правильно ли мы выбрали и сформулировали объект от которого будем толкаться , и вопрос об его изменении в будующем зависит от того-же



Minx :
Поэтому в иерархии более предпочтетнльны классы "Светящийся", "Круглый", "Блуждающий" и т.п.. Потому что в следующий раз появится комета, и начнется перепиливание всей иерархии, что череповато.



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

добавлено спустя 5 минут:
к тому же если подходить из моей логики любая нестандарная локация от сектора в космосе это лишь доп дочерний класс реализованный под какие-то нестандартные условия , а конкретно звезда , планета , комета и прочее внутри сектора с их поведением будет прямо либо опосредованно наследоваться от "объект в космосе" ... да и там если и будут промежуточные классы типа ("Светящийся", "Круглый", "Блуждающий") они будут отнюдь не первыми в очереди наследования ...

добавлено спустя 7 минут:
Minx :
В качестве другого ракурса. При существующей схеме уже будет затруднительно организовывать бартер. Кроме того, если вдруг на станции окажется несколько торговых точек, то интерфейс придется переделывать. В связи с этим надо сразу себе задавать вопросы - а нада ли нам вот эта или вот эта гибкость, и во что обернутся такие-то архитектурные решения?

Orly ? честно просто как 2 пальца ( что обмен партия на партию что обмен по соотношению стоимости потребуют лишь дописать методы в класс "Товар") а проблема с множеством точек продажи это проблема с непостановкой этого в тз как необходимости мб я чтото забыл или переигрался потом в иксы но в элите не было множества продавцов на станциях
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист...

Последний раз редактировалось: бухой джедай (10:16 24-11-2013), всего редактировалось 3 раз(а)
    Добавлено: 10:16 24-11-2013   
Minx
 907 EGP


Модератор
Рейтинг канала: 6(320)
Репутация: 140
Сообщения: 10416
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
бухой джедай :
правильно ли мы выбрали

"правильно" ли выбрали - это демагогия. нет правильных решений

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

Иерархии классов не толкаются от каких-либо сущностей - они необязательно древовидны.

бухой джедай :
во многих прикладных

Во многих прикладных применение ООП-подхода будет в корне противопоказанным. Не то что о каких-то принципах.

Читайте внимательно - ключевое слово "предпочтительны". А от вашей способности выбрать функцию предпочтительности зависит будущее проекта.

бухой джедай :
не первыми в очереди наследования

Нет очереди наследования. Есть набор свойств, из которых собираются новые сущности. Сущность "звезда" более конкретна, чем "святящийся", и не описывает того, чего мы от этой сущности хотим. Потому звезды менее железобетонны, чем светящийся объекты.

бухой джедай :
в элите не было множества продавцов на станциях

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

А не о игре в конкретные игры.
_________________
μηδείς αγεωμέτρητος εισίτω

Последний раз редактировалось: Minx (11:29 24-11-2013), всего редактировалось 2 раз(а)
    Добавлено: 11:27 24-11-2013   
Guest
 2075 EGP


Модератор
Рейтинг канала: 5(167)
Репутация: 378
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
Тащемта, Минкс всё расписал...
Minx :
Во-первых, не бывает правильных декомпозиций (и ООП в том числе).

Ну почему же, вон у Зачесы была правильная декомпозиция... До кварков включительно...
бухой джедай :
2)класс "Товар" с характеристиками "Цена" (натуральное число),"Объем" (натуральное число),"Владелец" (какой либо идентефикатор) и методом "Продать"

Не должно быть у него метода "Продать", т.к. оный зависит от контекста. Инкапсуляция жеж. "товар" тут = "груз". Он может лежать в трюме, может обладать свойствами, но действовать он по-хорошему может только в отношении себя без конкретной ситуации. Например, он может протухнуть независимо от того, где и как он находится, т.к. для этого нужен всего лишь системный таймер и свойство "время оставшейся жизни".
Это у его надмозга (станции, трюма) может быть метод продатьТоварНаглойРыжейМорде(товар Item, морда Person, bool Бесплатно). Он же может и цену за товар отличной от базовой показать...
Minx :
Особенность в том, что как только мы вводим в проект новую сущность, то мы моментально её получаем как независимый элемент (можем использовать отдельно и независимо, что плюс), но в то же время, мы ограничиваем гибкость наших решений в будущем (любая сущность это делает).

Ну, всегда можно написать расширение сущности, дорисовав к новой (или даже старой) реализацию ещё какого-нибудь интерфейса...
_________________
Трещит земля как пустой орех
Как щепка трещит броня
    Добавлено: 11:52 24-11-2013   
бухой джедай
 151 EGP


Рейтинг канала: 2(19)
Репутация: 67
Сообщения: 7879 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
Minx :
Речь идет о гибкости архитектурных решений, о понимании свойств того, что будет на выходе. В этом заключается искусство разработки.


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

добавлено спустя 10 минут:
Guest :
Не должно быть у него метода "Продать", т.к. оный зависит от контекста. Инкапсуляция жеж. "товар" тут = "груз". Он может лежать в трюме, может обладать свойствами, но действовать он по-хорошему может только в отношении себя без конкретной ситуации. Например, он может протухнуть независимо от того, где и как он находится, т.к. для этого нужен всего лишь системный таймер и свойство "время оставшейся жизни".

Это у его надмозга (станции, трюма) может быть метод продатьТоварНаглойРыжейМорде(товар Item, морда Person, bool Бесплатно). Он же может и цену за товар отличной от базовой показать...


в чемто согласен в чемто нет ...

станция в данном случае если уж подходить с точки зрения максимальной гибкости суть простым языком контейнер в котором мб и склад и прилавок и цех и хрен с багром и перевешивать конкретный функционал склада,прилавка,цеха, хрена с багром на станку сие есть неправильно
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист...

Последний раз редактировалось: бухой джедай (12:06 24-11-2013), всего редактировалось 1 раз
    Добавлено: 12:06 24-11-2013   
Minx
 907 EGP


Модератор
Рейтинг канала: 6(320)
Репутация: 140
Сообщения: 10416
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Guest :
Ну, всегда можно написать расширение сущности, дорисовав к новой (или даже старой) реализацию ещё какого-нибудь интерфейса...

Дописать можно. Но тут два основных эффекта:
- "sea of classes", в котором можно утонуть;
- если уже реализованные сущности понадобились в другом месте, то придется тянуть их через все интерфейсы или выполнять дублирование; в первом случае швейцарский нож, во втором проблемы синхронизации.

Ещё каждую сущность сопровождать надо.

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

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

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

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

Если надобности такого действия нет, то никаких наследований не рекомендуется. (но понятно, что случаи разные бывают)
_________________
μηδείς αγεωμέτρητος εισίτω

Последний раз редактировалось: Minx (12:25 24-11-2013), всего редактировалось 4 раз(а)
    Добавлено: 12:22 24-11-2013   
Guest
 2075 EGP


Модератор
Рейтинг канала: 5(167)
Репутация: 378
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
Minx :
- "sea of classes", в котором можно утонуть;

Есть такое, очень неприятно, если не знаешь полную структуру. А если приходит новый человек - то он таки не знает.
_________________
Трещит земля как пустой орех
Как щепка трещит броня
    Добавлено: 12:36 24-11-2013   
Minx
 907 EGP


Модератор
Рейтинг канала: 6(320)
Репутация: 140
Сообщения: 10416
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Guest :
Есть такое, очень неприятно, если не знаешь полную структуру.

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

А в общем же случае въехать в проект или погрузиться в контекст это не только проблема ООП. Например в том числе документация, организация в команде и пр..
_________________
μηδείς αγεωμέτρητος εισίτω
    Добавлено: 13:11 24-11-2013   
Sh.Tac.
 150 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 раз(а)
    Добавлено: 16:52 24-11-2013   
Minx
 907 EGP


Модератор
Рейтинг канала: 6(320)
Репутация: 140
Сообщения: 10416
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Sh.Tac., прочитай внимательно что написал топикстартер. Вопрос в грамотном применении ООП, а не в холиварах.

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

Людей, которые не освоили паттерны, могу только пожалеть. Это совершенно отдельное направление, к основным парадигмам относящееся косвенно.
_________________
μηδείς αγεωμέτρητος εισίτω

Последний раз редактировалось: Minx (19:02 24-11-2013), всего редактировалось 1 раз
    Добавлено: 19:02 24-11-2013   
Sh.Tac.
 150 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 раз(а)
    Добавлено: 20:25 24-11-2013   
Minx
 907 EGP


Модератор
Рейтинг канала: 6(320)
Репутация: 140
Сообщения: 10416
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Sh.Tac. :
следовательно нельзя грамотно применить

Нельзя применить идеально на все случаи жизни. Но можно более грамотно применить, и менее грамотно. Если твое решение выжило в схватке со временем, то это факт в пользу грамотности. И наобормот.

Sh.Tac. :
рекомендую использовать декомпозицию моделируемого мира 1:1 как он есть

Что под этим имеется ввиду?

Sh.Tac. :
боян про езду на велосипеде

5 умеешь и ездишь тогда, когда это востребовано.
_________________
μηδείς αγεωμέτρητος εισίτω
    Добавлено: 20:38 24-11-2013   
Sh.Tac.
 150 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 раз(а)
    Добавлено: 20:43 24-11-2013   
Jurec
 445 EGP


Ведущий раздела
Рейтинг канала: 4(76)
Репутация: 106
Сообщения: 1440
Откуда: Seattle
Зарегистрирован: 25.02.2006
Проситите, не все прочитал.

Объект
Трансформация (позиция + поворот)

абстрактный метод Update(dt)
----
Физический объект : Объект
Масса
Геометрия для просчета коллизий

+применить силу
и т.п.
----

Видимый объект : Объект
Геометрия[кол-во LOD'ов]
Материал (шейдеры/текстуры/параметры всякие)
----


Менеджеры физики / Менеджер сцены / Рендерер -- надо описывать?

--------
Слой игры

ОбъектИгры : ФизическийОбъект, ВидимыйОбъект
----

АбстрактныйОбъектСТрюмом : ОбъектИгры
объем
объекты в трюме

абстрактный метод положить в трюм
абстрактный метод вытащить из трюма
----

Станция : АбстрактныйОбъектСТрюмом
цены на товары
пристыкованые корабли
раса
----

Выстрел : ОбъектИгры
хозяин_выстрела
----


Игрок
текущий_корабль
собственность
деньги
...
----

Как-то так. Что-то надо описать еще?

Shirson :
Как будет работать ЕCM?

Что такое ЕСМ?
_________________
MOV topka, C++

Последний раз редактировалось: Jurec (14:48 25-11-2013), всего редактировалось 1 раз
    Добавлено: 14:48 25-11-2013   
Sh.Tac.
 150 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 раз
    Добавлено: 15:02 25-11-2013   
Jurec
 445 EGP


Ведущий раздела
Рейтинг канала: 4(76)
Репутация: 106
Сообщения: 1440
Откуда: Seattle
Зарегистрирован: 25.02.2006
Sh.Tac. :
Electronic Counter Measures вестимо, чисто игровой прибабах (с оговоркой на фкозмозе разумеется)


Тогда он висит как подсистема у корабля.

Подсистема может быть активирована.

Вот у ECM по активации идет запрос у менеджера физ объектов - найти объекты в радиусе R от позиции корабля, где активирована система.

Найти среди объектов ракеты и вызвать им детонацию.

Все просто
_________________
MOV topka, C++
    Добавлено: 15:32 25-11-2013   
бухой джедай
 151 EGP


Рейтинг канала: 2(19)
Репутация: 67
Сообщения: 7879 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
Sh.Tac. :
З.Ы. я тут тока до поста бухого джедая добрался, могу отметить, что товар как сущность неуместная единица, что такое товар? правильно, всё что угодно, в т.ч. корабли и станции, поэтому нужно просто дать возможность вешать ценник на любой объект, вот и выйдет товар


товар мб просто объектом с идентификатором чего угодно , идентификатором Владельца этого чего угодно и ценой.
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист...
    Добавлено: 17:01 25-11-2013   
Jurec
 445 EGP


Ведущий раздела
Рейтинг канала: 4(76)
Репутация: 106
Сообщения: 1440
Откуда: Seattle
Зарегистрирован: 25.02.2006
Народ, че ж вы такое сложное решение придумываете?
_________________
MOV topka, C++
    Добавлено: 18:11 25-11-2013   
Канал Игры Мечты: «Тру ООП (мышление объектами)»
На страницу: 1, 2, 3  След. | Все страницы
  
Показать: 
Предыдущая тема | Следующая тема |
К списку каналов | Наверх страницы
Цитата не в тему: Я буду... когда точно, не знаю, но меня легко узнать по группе крови... (решил встретиться WolF)

  » Тру ООП (мышление объектами) | страница 1
Каналы: Новости | Elite | Elite: Dangerous | Freelancer | Star Citizen | X-Tension/X-BTF | X2: The Threat | X3: Reunion | X3: Terran Conflict | X Rebirth | X4: Foundations | EVE Online | Orbiter | Kerbal Space Program | Evochron | VoidExpanse | Космические Миры | Онлайновые игры | Другие игры | Цифровая дистрибуция | play.elite-games.ru | ЗВ 2: Гражданская война | Творчество | Железо | Игра Мечты | Сайт
   Дизайн Elite Games V5 beta.18