В ООП — недавно. Пока плохо умею применять на практике. Создаю игровой двиг.
За графику взял Ogre, звук — audiere, коллизии — Opcode.

Если смешать все в кучу -- выходит класс Game entity.

slass GameEntity {
Polyform myPolyform // графический побъект
soundEntity mySoundEntity // звуковой побъект
collisionEntity myCollisionEntity // collision побъект
}

В движке все построено на менеджерах -- для каждого составляющего — свой (SceneManager,CollisionManager...).

Я создал еще и GameManager, который создает и держит список всех GameEntity.
Но, блин, как-то все это не красиво -- один менеджер вызывает другие, на которые ему при создании переданы поинтеры.
Может вы бы как-то по другому все организовали ? И что бы это дало ?
Спасибо

Abstract Factory из GOF-patterns может окажется полезной ?

PS извини, смысл глубоко не уловил вопроса. Так, первое что пришло в голову

Здравствуйте, Troglodit, Вы писали:

T>В ООП — недавно. Пока плохо умею применять на практике. Создаю игровой двиг.
T>За графику взял Ogre, звук — audiere, коллизии — Opcode.

T>Если смешать все в кучу -- выходит класс Game entity.
...
А ты попробуй не смешивать. Забудь про "дизайн" и "проектирование" — если нет опыта ни в том ни в другом. Начни с простого. Попиши код — простой и незамысловатый, в процедурном стиле, потом отойди на пару метров — и станет понятно, что надо обОбщить, и что во что выделить.

Здравствуйте, flax, Вы писали:

F> Abstract Factory из GOF-patterns может окажется полезной ?

А что это ? Можно по подробней, пожалуйста ?

Здравствуйте, Troglodit, Вы писали:

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

T>А что это ? Можно по подробней, пожалуйста ?
http://rsdn.ru/Forum/?mid=583152

Автор: nap2k
Дата: 25.03.04

Как раз вчера читал Скота Майерса — 35 правил .... или что-то в этом роде.
Правило 31. Про мульти-методы. Посмотри, может пригодится.

Здравствуйте, Аноним, Вы писали:

А>Как раз вчера читал Скота Майерса — 35 правил .... или что-то в этом роде.
А>Правило 31. Про мульти-методы. Посмотри, может пригодится.

Ну если на то пошло, можешь посмотреть реализацию мультиметодов из Александрески "Modern C++ design"

PS сейчас насоветуем

F>Ну если на то пошло, можешь посмотреть реализацию мультиметодов из Александрески "Modern C++ design"

F>PS сейчас насоветуем

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

А можно как-то объяснить, как мне поступить ?

Здравствуйте, Аноним, Вы писали:

А>Как раз вчера читал Скота Майерса — 35 правил .... или что-то в этом роде.
А>Правило 31. Про мульти-методы. Посмотри, может пригодится.

Искал на гугле такого автора, но не нашел...
Можна сцылку плиз...

Здравствуйте, Troglodit, Вы писали:

T>Здравствуйте, Аноним, Вы писали:

А>>Как раз вчера читал Скота Майерса — 35 правил .... или что-то в этом роде.
А>>Правило 31. Про мульти-методы. Посмотри, может пригодится.

T>Искал на гугле такого автора, но не нашел...
T>Можна сцылку плиз...

Да, ошибочка вышла.
Вот как правильно:

Скотт Мейерс
Наиболее эффективное использование C++. 35 новых рекомендаций по улучшению ваших программ и проектов.
http://anatolix.naumen.ru/cppbooks.htm

Здравствуйте, Troglodit, Вы писали:

T>slass GameEntity {
T>Polyform myPolyform // графический побъект
T>soundEntity mySoundEntity // звуковой побъект
T>collisionEntity myCollisionEntity // collision побъект
T>}

Тоже вариант. Здесь надо понять что тебе даёт такая организация игрового обьекта. Все ли обьекты у тебя могут быть отрисованы, озвучены и имеют физические свойства? Что даёт тебе агрегация в противовес наследованию. Почему абстрактный игровой обьект (если в твоём контексте он абстрактный) содержит конкретные реализации элементов других подсистем (рендеренга,...)? НО! Это тоже вариант и он имеет право на жизнь, только надо понимать в чём _для_тебя_ плюс такого варианта.

T>В движке все построено на менеджерах -- для каждого составляющего — свой (SceneManager,CollisionManager...).
T>Я создал еще и GameManager, который создает и держит список всех GameEntity.
T>Но, блин, как-то все это не красиво -- один менеджер вызывает другие, на которые ему при создании переданы поинтеры.

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

T> Может вы бы как-то по другому все организовали ? И что бы это дало ?

Неправильный вопрос. ИМХО, вопрос должен звучать так: я хочу то-то и то-то, как мне этого добиться?

В то время как космические корабли бороздят просторы народного театра, а Уокер — Техасский Рейнджер борется с мировым терроризмом, многоуважаемый Troglodit wrote следующее:


T>В ООП — недавно. Пока плохо умею применять на практике. Создаю игровой двиг.

T> Может вы бы как-то по другому все организовали ? И что бы это дало ?
T>Спасибо

Я бы опускал уровень абстракции сверху-вниз, пока не дошёл бы до частей которые можно заключаться в классы..
Скажем, куча манагеров неплохая идея, но я бы применил глобальный менеджер-цикл, который принимал бы данные от инпута и АИ, проверял на соответствие с логикой, тестировал бы коллижны функцией-мембер карты на которой происходит действо, и наконец отдавал бы полигоны рендереру.