|
|
|
|
Канал Игры Мечты: «Тру ООП (мышление объектами)» |
|
|
|
Minx
 978 EGP
       
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
  |
|
Решение будет сложным когда доберемся до acquirer'ов и merchant'ов, а также к схемам двухфазных и трехфазных платежей. Что будет просто необходимо в распределенных системах.
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
Guest
 2075 EGP
        
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
 |
|
| Jurec : |
|
Менеджеры физики / Менеджер сцены / Рендерер -- надо описывать?
|
Было бы неплохо. Я вот до сих пор путаюсь, какими вещами может/должен заниматься, например, менеджер физики (кроме очевидного содержания коллекции всех физических элементов сцены, чтобы к ним можно было обращаться), а какими - собственно физический объект?
А вообще декомпозиция должна производиться до неделимых величин, о чём уже писали. Не нужно плодить детальки сущностей без необходимости. Будет гибче, но будет сложнее запомнить и удержать в "оперативной памяти" мозга полную картину.
Если светящиеся объекты - это сущность, способная существовать автономно, тогда можно и класс забабахать, если нет - хватит интерфейса, а если это просто фонарик, который может существовать у всех объектов, но по умолчанию выключен - возможно проще будет его включить в класс игрового объекта и не выдёргивать в отдельную сущность... Всё от контекста зависит. То бишь от конкретной игры. ООП ради ООП (ЪООП) тут не нужен...
В играх, в отличие от "рабочих" приложений редко когда производится перекапывание архитектуры в процессе эксплуатации. Хотя с тенденцией последнего времени "длительного тестирования", т.е. разработки в процессе эксплуатации (характерные примеры - MineCraft, Kerbal Space Program, Don't Starve, Gnomoria... Да тот же Dwarf Fortress) такой вариант возможен.
_________________
Трещит земля как пустой орех
Как щепка трещит броня |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
| Minx : |
Решение будет сложным когда доберемся до acquirer'ов и merchant'ов, а также к схемам двухфазных и трехфазных платежей. Что будет просто необходимо в распределенных системах.
|
А нафига это нужно?
добавлено спустя 1 минуту:
| Guest : |
|
А вообще декомпозиция должна производиться до неделимых величин, о чём уже писали.
|
До кварков? 
добавлено спустя 15 минут:
Менеджер физики делает update физики. Он знает все физические объекты. Перед update он устанавливает их состояния. После update - отправляет подписчикам события типа "объект А столкнулся с B". или в сенсор C попали объекты - вот они.
Объекты физики - к ним можно применить силы какие-то. Например, можно сделать взрыв таким образом:
менеджер_физики->дай_объекты_в_радиусе_R_от_объекта_BOMB
каждому физ объекту применить силу от центра взрыва
Корабль может подписаться на столкновения с своим физ. объектом. И обрабатывать их по всякому.
Менеджер сцены должен иметь граф сцены, чтобы трансформации передавать. Типа это корабль, к нему прикреплены турели и т.п.
В общем его задача ответить на вопрос- что видит камера X.
Чтоб помочь ему в этом вопросе может существовать occlusion engine, как мы делали в Splinter Cell, например - иерархический Z-buffer. Он поможет не только отсечь по пирамиде видимости, но и объекты, которые закрыты другими объектами.
Такими запросами можно получить список объектов, которые надо передать в рендерер, в том числе и для рендеринга карт теней.
Ну рендерер - зависит от реализации. Он сортирует объекты по материалу(читай - шейдеру) и вперед. Там много всего может быть, все очень зависит от задачи.
Сорри, времени нет, пишу brain dump
_________________
MOV topka, C++
Последний раз редактировалось: Jurec (19:12 25-11-2013), всего редактировалось 2 раз(а) |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Jurec : |
|
сложное решение придумываете?
|
оно достаточно универсально, магазины может настраивать как геймдизайнер, так и программист игромеха, генерируя прайслисты на лету, имитируя некую экономическую активность, потом это легко расширяется на бартер, достаточно вместо ид магазина использовать ид игрока
понятное дело, что в многопользовательской игре рынок-аукцион будут посложнее, но можно их строить поверх уже этой реализованной механики, как раз выйдет то самое пресловутое повторное использование кода
а вообще согласен, оверинжиниринг тоже плохо, просто топик стартер слишком кратко и общо поставил вопросы, тут по каждому можно не меньше месяца работать фуллтайм
и ещё мы сильно отклонились от изначально раскрасявого ООП, сейчас уже тут фактически всё скатилось к архитектуре игрового движка
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
Я отвечал на конкретные вопросы:
| Shirson : |
Как будет организована её объектаная модель?
Как осуществлять покупку и продажу товаров, например?
Как организовать бой на лазерах?
Как будет работать ЕCM?
Каждая часть оригинала интересует, но в ракурсе тру-ООП.
|
Без движка ответить на это нереально.
| Sh.Tac. : |
оно достаточно универсально, магазины может настраивать как геймдизайнер, так и программист игромеха, генерируя прайслисты на лету, имитируя некую экономическую активность, потом это легко расширяется на бартер, достаточно вместо ид магазина использовать ид игрока
|
Насколько я понял - речи о сложном рынке даже не было. Задачи в принципе по этому поводу нет, можете обрисовать рамки обсуждения?
добавлено спустя 5 минут:
Чем гибче решение, тем меньше от него толку. Сделать мега гибко архитектуру все равно нереально, не стоит даже пробовать.
_________________
MOV topka, C++
Последний раз редактировалось: Jurec (19:59 25-11-2013), всего редактировалось 2 раз(а) |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Jurec : |
|
А нафига это нужно?
|
Например когда информация о товаре/игроке/сделке/принадлежности находится на разных серверах.
Игрок A находится на сервере X, и хочет купить у игрока B вещь. Игрок B находится на сервере Y.
Проблема в том, что система распределенная, и заключается (проблема) в построении атомарной транзакции. В двухфазной схеме это реализуется где-то так:
1. A инициирует запрос на сделку.
2. X отсылает запрос о возможности проведения сделки на сервер Y. (первая фаза)
3. Y отвечает согласием или формирует отказ (товар уже купили, игрока такого нет, нет денег и пр.).
4. X получает согласие. Снимает деньги со счета A.
5. X формирует запрос на проведение сделки. (вторая фаза).
6. Y принимает запрос и выполняет сделку на своей стороне.
7. Y отвечает о результате операции, X принимает и закрывает транзакцию.
И даже при таких схемах есть тонкости и не все так просто.
Если же пишется Элита как игрушка для сингл- на полчаса пострелять, то проблема атомарности транзакции легко решается внутри монолитного приложения. При этом многие этой проблемы даже не замечают и не подозревают о её существовании (;
| Jurec : |
|
можете обрисовать рамки обсуждения?
|
Топикстартера нет, потому и рамок нет (;
_________________
μηδείς αγεωμέτρητος εισίτω
Последний раз редактировалось: Minx (21:57 25-11-2013), всего редактировалось 2 раз(а) |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Jurec : |
|
речи о сложном рынке даже не было. Задачи в принципе по этому поводу нет
|
а там вроде простая задача, сделать чтобы в разных системах на разных станциях был разный ассортимент товаров по разной цене
с удовольствием послушаю как ещё можно сделать
мы так делали потому-что у нас уже была система обектов (та самая Item-Inventory-Factory), которая позволяла задёшево добавлять новые категории объектов, в данном случае добавили сущность, обозвали её Price, сказали такие-то такие-то поля есть, кодеген и вперёд. Тупо набив их в инвентари по многа штук мы и получили те самые развесистые прайслисты
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Shirson
1605 EGP
 
Рейтинг канала: 7(626)
Репутация: 219
Сообщения: 16511
Откуда: 79°W 44°N
Зарегистрирован: 29.01.2002
|
|
| Minx : |
| Jurec : |
|
А нафига это нужно?
|
Например когда информация о товаре/игроке/сделке/принадлежности находится на разных серверах.
|
На каких еще серверах?
образец для реализации - Элита.
Как будет организована её объектаная модель?
Как осуществлять покупку и продажу товаров, например?
Как организовать бой на лазерах?
Как будет работать ЕCM?
Каждая часть оригинала интересует, но в ракурсе тру-ООП.
| Цитата: |
|
Топикстартера нет, потому и рамок нет
|
Рамки заданы сразу, однозначно и наглядно так, что дальше уж некуда.
_________________
У меня бисера не доxеpа. |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Shirson : |
|
На каких еще серверах?
|
На любых распределенных. Как в E: D (;
Проблема ярко проявляется на серверах, а в монолитном приложении её практически нет. Но может быть.
Например мы написали код сделки:
1. Взять денег у игрока X.
2. Переименовать принадлежность товара от Y к X.
3. Начислить денег игроку Y.
Если между 1 и 2 из системы исчезает игрок X, то товар пропадает в никуда. Если между 2 и 3 пропадает из системы игрок Y, то деньги уходят в никуда.
---
И вообще, это был ответ Jurec'у о том, что сложностей может быть намного больше, чем написано в этой ветке.
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
Shirson
1605 EGP
Рейтинг канала: 7(626)
Репутация: 219
Сообщения: 16511
Откуда: 79°W 44°N
Зарегистрирован: 29.01.2002
|
|
| Minx : |
| Shirson : |
|
На каких еще серверах?
|
На любых распределенных.
|
В Элите нет распределённых серверов. В ней вообще никаких серверов нет.
В  E: D. Топик об Элите.
| Цитата: |
|
Проблема ярко проявляется на серверах...
|
Это уже полный оффтопик.
_________________
У меня бисера не доxеpа. |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
Это чем это вам E: D не Elite? 
добавлено спустя 14 минут:
| Jurec : |
Менеджер физики делает update физики. Он знает все физические объекты. Перед update он устанавливает их состояния. После update - отправляет подписчикам события типа "объект А столкнулся с B". или в сенсор C попали объекты - вот они.
Объекты физики - к ним можно применить силы какие-то.
|
Детектирование столкновения должно производиться менеджером или объектами? То есть непосредственно вектор силы поменять на объекте - метод или свойство объекта (направление туда), а столкновение (направление оттуда) - это событие объекта или событие менеджера?
Вроде логично объекта, правда появляются дубликаты - при столкновении объектов А, В и С генерятся столкновения АВ ВА ВС СВ СА АС...
_________________
Трещит земля как пустой орех
Как щепка трещит броня
Последний раз редактировалось: Guest (03:40 26-11-2013), всего редактировалось 3 раз(а) |
|
|
|
Shirson
1605 EGP
Рейтинг канала: 7(626)
Репутация: 219
Сообщения: 16511
Откуда: 79°W 44°N
Зарегистрирован: 29.01.2002
|
|
| Guest : |
|
Это чем это вам E: D не Elite?
|
Вот этим
E: D
_________________
У меня бисера не доxеpа. |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
Shirson, дай фидбек по моим ответам, плиз. Я вроде по делу написал. Это то что нужно?
| Guest : |
|
Детектирование столкновения должно производиться менеджером или объектами?
|
Детект и солв делает менеджер. (broad phase, narrow phase). Сам себе объект ничего не меняет, он - просто "хранилище".
[offtop]
| Minx : |
Например когда информация о товаре/игроке/сделке/принадлежности находится на разных серверах.
|
Это решается не на этом уровне, а на уровне БД, которая поддерживает это дело из коробки.
[/offtop]
_________________
MOV topka, C++ |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Jurec : |
|
Сам себе объект ничего не меняет, он - просто "хранилище"
|
что-то как-то не по ООП-шному ни разу, думаю может сменить название топика
Это компонентная система, кажный объект имеет своё собственное представление в различных подсистемах, при этом логически объект один и тот же везде. И второй уже озвученный момент, объект сам как правило ничего не делает, ибо ему слишком много про всех надо знать будет, менеджеры его пинают вдоль и поперёк
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
| Sh.Tac. : |
|
что-то как-то не по ООП-шному ни разу, думаю может сменить название топика
|
Я о том как работают реальные продукты. О практике, то бишь. А че не по ООПшному? А как бы ты сделал по ООПшному?
Весь канал ИМ- это место где живут одни теоретики, которым только дай пообсуждать как бы было в идеале. Дайте практику, плиз. Автор топика четко дал задачи, а вы ушли в жесточайший оффтоп с рассуждениями без смысла.
Ребят, прошу примеров, по типу того как привел я.
_________________
MOV topka, C++
Последний раз редактировалось: Jurec (14:11 26-11-2013), всего редактировалось 1 раз |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Jurec : |
|
А че не по ООПшному?
|
лан, почти сдаюс
есть один момент, а именно само взаимодействие менеджеров между собой, оно у тебя не описано
там бывают встречаются такие неприятности вроде подписки и проч. "прелести"
добавлено спустя 12 минут:
З.Ы.
| Цитата: |
|
Ребят, прошу примеров, по типу того как привел я
|
можно, но получатся такие же куцые, например
| Цитата: |
Выстрел : ОбъектИгры
хозяин_выстрела
|
вопрос, где параметры и тип урона, в пульке или в оружке?
где вообще модель повреждений, не знаю, хотя бы лайфбар?
_________________
This is what you get ...
(c) Radiohead
Последний раз редактировалось: Sh.Tac. (14:39 26-11-2013), всего редактировалось 1 раз |
|
|
|
Olorin
70 EGP
Рейтинг канала: 1(6)
Репутация: 12
Сообщения: 97
Откуда: Хьёрвард
Зарегистрирован: 27.02.2006
|
|
Какая-то сферическая декомпозиция в вакууме уже пошла.
ООП в приложении к задаче всегда ограничивается тремя вещами:
1. ТЗ (диктует предметную область и набор сценариев, в рамках которых определяются задачи к реализации)
2. Здравым смыслом (балансом запаса гибкости и сложности поддержки архитектуры)
3. Прогрессом готовности реализации (рефакторинг/создание новых сущностей выполняется только тогда, когда это мотивировано задачей)
На этапе проектирования декомпозиция практически никогда до атомарных сущностей не доходит. Иначе можно проектируя сетевой чатик надекомпозироваться до субатомных частиц. Это относится и к сценариям.
Поэтому, имхо, взять и разложить нечто с потолка по ООП-принципам не получится.
Что сделать можно:
- определить предметную область (какие объекты в ней есть, с какими характеристиками, в каких отношениях между собой)
- определить сценарии взаимодействия пользователя и объектов этой предметной области
- определить качественные требования к форме представления
- провести проектирование абстрактной высокоуровневой архитектуры (на уровне модулей, блоков функциональности, зависимостей между ними) и публичных интерфейсов (прямо моделирующих предметную область), с учетом
вышеперечисленного
Но это будет не реализация, а спецификация.
Дальше нужно еще сформулировать задачи для реализации отношений и сценариев, способы проверки всех требований. Причем обычно это делается уже параллельно с реализацией, в процессе которой по мере выполнения задач идет дальнейшая декомпозиция.
| Minx : |
Например мы написали код сделки:
1. Взять денег у игрока X.
2. Переименовать принадлежность товара от Y к X.
3. Начислить денег игроку Y.
Если между 1 и 2 из системы исчезает игрок X, то товар пропадает в никуда. Если между 2 и 3 пропадает из системы игрок Y, то деньги уходят в никуда.
|
1. Взять денег у игрока X. (если пропадёт позже - товар ему уже не нужен, эквивалентно пропаданию после завершения сценария)
2. Взять товар у игрока Y.
4. Прописать принадлежность товара игроку X.
5. Начислить деньги игроку Y. (если пропал - деньги ему уже не нужны, эквивалентно пропаданию после завершения сценария)
_________________
Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший |
|
|
|
Olorin
70 EGP
Рейтинг канала: 1(6)
Репутация: 12
Сообщения: 97
Откуда: Хьёрвард
Зарегистрирован: 27.02.2006
|
|
| Shirson : |
образец для реализации - Элита.
Как будет организована её объектаная модель?
Как осуществлять покупку и продажу товаров, например?
Как организовать бой на лазерах?
Как будет работать ЕCM?
Каждая часть оригинала интересует, но в ракурсе тру-ООП.
|
Грубо говоря - как угодно.
Программирование вообще не формальная дисциплина, а инженерная.
Это как ткнуть пальцем в картинку с домиком и поставить вопросы вида: из каких материалов, сколько надо экскаваторов, сколько будет несущих стен?
В процессе проектирования ТЗ дополняется техническими требованиями ко внутренним характеристикам реализации, от которых архитектор пляшет как умеет с использованием тех средств и материалов, которые доступны. Внешний вид задается отделкой, как в рекламе: овощи пластмассовые, а меренги из строительной пены. Внутреннее устройство (а интересует ведь оно, я правильно понял?) может быть любым.
_________________
Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
| Sh.Tac. : |
вопрос, где параметры и тип урона, в пульке или в оружке?
где вообще модель повреждений, не знаю, хотя бы лайфбар?
|
Не пойму суть вопроса - ты имеешь ввиду что этого нельзя сделать в моей модели? Или имеешь ввиду что в моей модели детализации недостаточно?
Могу описать, нада? 
Если первое - обоснуй, а если второе, то соглашусь со следующим оратором:
| Olorin : |
|
На этапе проектирования декомпозиция практически никогда до атомарных сущностей не доходит. Иначе можно проектируя сетевой чатик надекомпозироваться до субатомных частиц.
|
| Olorin : |
|
Грубо говоря - как угодно.
|
Я так понимаю автор просил пример. Очень сомневаюсь что это был вопрос - "существует ли единственно верный тру метод?"
_________________
MOV topka, C++ |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Olorin : |
1. Взять денег у игрока X. (если пропадёт позже - товар ему уже не нужен, эквивалентно пропаданию после завершения сценария)
2. Взять товар у игрока Y.
4. Прописать принадлежность товара игроку X.
5. Начислить деньги игроку Y. (если пропал - деньги ему уже не нужны, эквивалентно пропаданию после завершения сценария)
|
Если это учтено и сценарии продуманы. Т.е. проблема замечена и решена на уровне протокола.
Если же это не учтено, то может обернутся не в пропадание игрока/товара, а например в попытку записи в удаленный из кучи объект со всеми вытекающими.
| Jurec : |
|
Это решается не на этом уровне, а на уровне БД, которая поддерживает это дело из коробки.
|
БД это скорее инструмент, который может обеспечить атомарность/транзакционность. Но не всякая БД имеет транзакции, а атомарность в монолите можно хоть через std::atomic обеспечить.
В той же Элите на подобные грабли можно наступить во многих местах. Например диспетчер прописывает в очередь для обработки события во время боя. Во время его происходят следующие события. Первая серия: выстрел (A), попадание в контейнер и его уничтожение (B). Вторая серия: захват контейнера (C), помещение контейнера в трюм (D). Представим, что события выстроились как A C B D. Если ситуация заранее не продумана, т.е. A-B и C-D не синхронизированы, то получаем undefined behavior, в смысле, как программа реализована, такой привет и будет. Может пронесет, может в трюм попадет пустой контейнер, а может контейнер delete, и потом к нему обращение по указателю и краш приложения.
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
|
|
|
|
|
Канал Игры Мечты: «Тру ООП (мышление объектами)» |
|
|
