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

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

G>>какой "плюс" а том что вы ипользуете для в добавления в мир целый класс с названием CShell_Insert ( называете его "оболочка вставки" ) ? мне кажется можно просто заделать метод в классе мира для этого ? или я не прав ?

EG>Оболочка вставки (insertion shell) в заданный тип мира W, как правило, может содержать важную информацию о положениях и ограничениях самой вставки и создаётся одной сущностью для другой сущности, которая может использовать данную информацию для корректного создания других своих оболочек в том же мире, а самое главное, налаживает связь той сущности с миром, в котором ей создали оболочку вставки.

EG>Надеюсь не очень путанно написано =)

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

Разве нельзя было зделать метод Insert() в классе мира который конечно будет виртуальным ( ведь для каждого мира должна быть своя реализация ) и занимался бы как раз вставкой любого допустимого объекта в мир. я лично вижу несколько плюсов такого подхода: у вас нету еще одно лишнего класса с сомнительной потребностью, у вас есть возможность возвратить какуюто ошибку ( если вставка не удалась ), а так если CShell_Insert является классом и я хочу вставлять объекты одной строкой ( потому что простые действия должны иметь простой код ) то конструктор конечно ничего возвратить не сможет... разве что try-catch использовать.

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

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

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

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

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

G>работа мне ваша понравилась. я ничего плохого сказать немогу. просто опровергните мой вариант или покажите неопровиржимые достатки своего варианта

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

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

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

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

А>Статья очень понравилась.
А>Есть желание построить модель в UML.
А>Если возникнут вопросы можно к тебе обращаться?

Конечно!

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

EG>.......

круто.
спасибо.

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

Я вот не понимаю где во всей этой работе место такому ключевому понятию как scenegraph?
В чем все-таки смысл существования essence?

Мутно все как-то. Либо автор сам не понимает до конца свою идею, либо не может ее понятно объяснить. И то и другое очень плохо.
Использовать с/с++ в примерах тоже как-то не очень. Нужно что-то типа псевдо-языка, похожего наверное на Яву (ну или с#) а то все эти особенности с/с++ с его указателями, и т.д. только отвлекают.

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

А>Я вот не понимаю где во всей этой работе место такому ключевому понятию как scenegraph?

Essences существуют в Worlds в виде Shells. Вот и весь граф.

Если под Scene Graph понимается то, что нужно Render'у, то такой Scene Graph получается из подмножества общего графа Сущностей-Миров-Оболочек и прекрасно синхронизируется с клиентами заданной Camera shell (оболочки камеры, по сути это Observer).

А>В чем все-таки смысл существования essence?

Сущность может находится в разных мирах (воссоздавая оболочки под тот тип мира в котором она сейчас), может даже находится в разных мирах одновременно (в виде оболочек, например Меч висит на поясе у Героя и участвует в обработке физики (это для крутых игр =), но также виден и в его инвентаре), может быть Миром (и не одним), может быть Оболочкой или даже одновременно несколькими Оболочками (через интерфейсы). Но главная задача любой Сущности — это реализовывать себя (свою сущность, не только внешний вид, но и поведение = AI) в Мирах в виде Оболочек.

А>Мутно все как-то. Либо автор сам не понимает до конца свою идею, либо не может ее понятно объяснить. И то и другое очень плохо.

Да, чтобы понять эту абстракцию нужно попробовать въехать в это самостоятельно (в статье описаны далеко не все мелочи).
Кстати, это черновик и именно вторую часть (про Сущности-Миры-Оболочки и их кодирование) я хотел переписать.

А>Использовать с/с++ в примерах тоже как-то не очень. Нужно что-то типа псевдо-языка, похожего наверное на Яву (ну или с#) а то все эти особенности с/с++ с его указателями, и т.д. только отвлекают.

Спасибо за совет, с выводом согласен, но в любом случае кроме кода статьи стоит приложить исходный код (вариант реализации) на каком-либо общеиспользуемом языке программирования (и я склоняюсь к C++, но также рассматриваю вариант C#).

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

EG>Спасибо за совет, с выводом согласен, но в любом случае кроме кода статьи стоит приложить исходный код (вариант реализации) на каком-либо общеиспользуемом языке программирования (и я склоняюсь к C++, но также рассматриваю вариант C#).
Всетки лучше на C# (или вобще на nemerle [маниакальный смех]... вывод типов, pattrern-matching и вложенные функции рулят) ибо С++ будет отвлекать от сути всякими мелочами типа упаравления временем жизни и тп.

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

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

EG>>Спасибо за совет, с выводом согласен, но в любом случае кроме кода статьи стоит приложить исходный код (вариант реализации) на каком-либо общеиспользуемом языке программирования (и я склоняюсь к C++, но также рассматриваю вариант C#).
WH>Всетки лучше на C# (или вобще на nemerle [маниакальный смех]... вывод типов, pattrern-matching и вложенные функции рулят) ибо С++ будет отвлекать от сути всякими мелочами типа упаравления временем жизни и тп.

Ты это не забывайся
Тут игроделы C++ не хотят осваивать, а ты ...

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

EG>>Спасибо за совет, с выводом согласен, но в любом случае кроме кода статьи стоит приложить исходный код (вариант реализации) на каком-либо общеиспользуемом языке программирования (и я склоняюсь к C++, но также рассматриваю вариант C#).
WH>Всетки лучше на C# (или вобще на nemerle [маниакальный смех]... вывод типов, pattrern-matching и вложенные функции рулят) ибо С++ будет отвлекать от сути всякими мелочами типа упаравления временем жизни и тп.

Интересный момент заключается в том, что если в самой статье будет псевдокод, то он будет достаточно легко превращаться в программу на C#, а исходник тогда хотелось бы положить на С++ (хорошую реализацию, с правильным разруливанием времени жизни объектов).

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

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

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

EG>>>Спасибо за совет, с выводом согласен, но в любом случае кроме кода статьи стоит приложить исходный код (вариант реализации) на каком-либо общеиспользуемом языке программирования (и я склоняюсь к C++, но также рассматриваю вариант C#).
WH>>Всетки лучше на C# (или вобще на nemerle [маниакальный смех]... вывод типов, pattrern-matching и вложенные функции рулят) ибо С++ будет отвлекать от сути всякими мелочами типа упаравления временем жизни и тп.

FR>Ты это не забывайся
FR>Тут игроделы C++ не хотят осваивать, а ты ...
А действительно — зачем сейчас С++ для игр использовать (шареварных)? Сейчас есть куча аналогов, более удобных, чем С++ с нуля (без либ и готовых фреймвоков).

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

EG>Интересный момент заключается в том, что если в самой статье будет псевдокод, то он будет достаточно легко превращаться в программу на C#, а исходник тогда хотелось бы положить на С++ (хорошую реализацию, с правильным разруливанием времени жизни объектов).
Думаешь ГЦ не справится с разруливанием жизни объектов?

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

EG>>Интересный момент заключается в том, что если в самой статье будет псевдокод, то он будет достаточно легко превращаться в программу на C#, а исходник тогда хотелось бы положить на С++ (хорошую реализацию, с правильным разруливанием времени жизни объектов).

WH>Думаешь ГЦ не справится с разруливанием жизни объектов?

Да, думаю, справится (если использовать правильно). Просто плюсы ближе пока =)

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

Старые ссылки умерли, вот новые:

"Game Engine Programming Guide" (zip-версия, 85 Кб)
"Game Engine Programming Guide" (HTML-версия, 903 Кб)

новые похоже тоже умерли