«
»

Эволюция геймобжекта

August 29, 2007, 9:05 am

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

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

Но мое глубокое ИМХО – лучший gameobject – это отсутствие gameobject вообще. В игре не так много сущностей, которые обладают полностью единым интерфейсом. И слишком много сущностей, которые обладают совсем разным интерфейсом.

Category: c++, life  |  Comment (RSS)  |  Trackback
  • look4awhile

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

  • alll
  • http://plakhov.livejournal.com Finder

    GameObject неявным привидением присутствует в тулсете. Не в качестве одного класса, конечно, но он есть.

  • http://aruslan.livejournal.com/ aruslan

    Tangling of concerns, обычно.
    Как антитеза к Separation of concerns.

  • http://aruslan.livejournal.com/ aruslan

    Строго говоря, tangling of concerns – это приём проектирования. Просто когда его применяют “от незнания” – получается ошибка.
    На выходе – сильно сцепленные (tightly coupled) и слабосвязные (low cohesive) компоненты.

  • Yuri

    Альясинг?

  • Dront

    немного IMHO:
    В игре есть много интерфейсов, и есть много классов объектов, причем у каждого объекта – некоторый subset из этих интерфейсов.
    То бишь, иерархии классов в виде наследования – мало подходят для игр вообще. Агрегировать надо. Типа, есть объекты, которые умеют рендериться, коллидиться, отбрасывать тени, имеют хитпойнты и AI. Если пытаться сделать его наследником от IRenderable, IShadowCaster и т.п. – получится жуткое месиво из всякого. А вот собрать его из экземпляров class AnimatedMonsterRenderer, class ScriptedAI и т.п. – вполне можно.

    При этом “базовый” GameObject все равно может быть полезным – но немного для другого… всякие там rtti, serialization и прочее подобное.
    Общая суть идеи – плох не GameObject, плоха иерархия.

  • dDIMA

    > AnimatedMonsterRenderer
    Еще хуже. Animated или нет – это вообще мелкая визуальная фенечка, которая требуется преимущественно только для рендеринга. Ну а вставлять слово Monster мне вообще не хочется.
    Простой пример: анимированный персонаж и скайбокс имеют очень похожие интерфейсы.

  • Pingback: The Daily DIP Count » Blog Archive » The God Object()

  • http://www.codygain.com neteraser

    GameObject –
    совсем непонятно.

    не платят теперь за GameObject никакого бабла!
    платят за его отсутствие (за излечение от него).

    у вас все еще платят за GameObject?
    падонаки уже на пути – к вам! :)

    замечу,
    dDIMA отписал не очень убедительно
    (если не считать самого бренда “dDIMA Evolution”)

    только таким худеньким напалмом
    будет довольно трудно вынудить уволить лида.
    понимаешь, дядя Дима? :)

    вот и пример:
    >> not convinced in the rightness of the thou shalt have no single GameObject
    уважаемый коллега не понимает. потому что он не догадался,
    что на лечении от GameObject можно сделать денег :)

    или думаете нельзя? что думаете?

  • http://www.codygain.com neteraser

    добавлю,
    во всех этих вопросах хорошо/плохо в программировании –
    мне очень сложно найти с людьми общий интерфейс и ценности.
    у меня нет ценностей, но есть интерес.

    у меня есть всего 3-4 человека,
    с которыми можно что-то измерять понятиями хорошо/плохо.

    со всеми остальными –
    измеряю только в бабле выгодно/невыгодно (прямо или косвенно)

    GameObject – и плохо, и едва ли выгодно.
    спорить, собственно, тут нет о чем.

    спорить вот так просто о чем-либо вообще нет причины :)
    люди либо будут соглашаться с вами, либо говорить полную ерунду.

    не припомню, чтобы когда-либо было иначе! (мог забыть, конечно…)

  • dDIMA

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

  • http://simsmen.livejournal.com/ simsmen

    2 dDIMA, я действительно в обсуждении получил ту дополнительную информацию, которой мне не хватало. Вот не получался у меня GameObject и всё. Не нужен:) Был в большой задумчивости:) Теперь стал более уверен в своей правоте, снесу, то что пытался под него вымучить:)

  • http://www.eye-gem.net EyeGem

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

    dDIMA:
    Почему “универсальный и абстрактный GameObject” должен быть гиганским или монстром?

    Если он нужен такой универсальный и такой абстрактный, то разве не логично, что вся specific-часть вне него будет, разве не? Это приведёт к QueryInterface-подходу, что хорошо в нужных местах и в правильно реализованном виде.

    А “логические игровые сущности” и “физические (геометрические объекты)” совмещать действительно не нужно.
    Логика (как физика World, так и сенсорика/моторика объектов) должна управлять телами, а не быть с ними единой.

    Могу вот, например, ссылку дать на статью мою, где тема затрагивается: http://www.eye-gem.net/gepg.zip

  • http://www.eye-gem.net EyeGem

    Сорри, пытаясь написать ссылку по-памяти, забыл субпуть.
    Лучше просто зайти на заглавную: http://www.eye-gem.net/