Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина).
Re: Где почитать о проектировании игровых движков?
Здравствуйте, Flammable, Вы писали:
F>Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина).
Что по твоему структурщина? (Пример опенсорсного движка, если можно)
Хочешь ООПнутый движек,правда это скорее просто рендер, посмотри исходники OpenSceneGraph. Мне их подход ужасно не нравится.
Приятный чистый код в Irrlich.
Ogre — куча стращных нагромождений, тебе наверное не понравится
Re[2]: Где почитать о проектировании игровых движков?
Здравствуйте, Trrrrr, Вы писали:
T>Что по твоему структурщина? (Пример опенсорсного движка, если можно)
Нужно ООП и С++. Quake 3 написан на C. Doom 3 написан на C++, но на мой взгляд, там какая-то смесь структурщины и ООП. Не то.
T>Хочешь ООПнутый движек,правда это скорее просто рендер, посмотри исходники OpenSceneGraph. Мне их подход ужасно не нравится.
В чем именно, можешь пояснить?
Просто рендер — это легче, поскольку не нужна лишняя абстракция для связывания рендера со всякой физикой и игровой логикой. Но для начала и такое пойдет, всяко лучше, чем ничего.
Re: Где почитать о проектировании игровых движков?
Здравствуйте, Flammable, Вы писали:
F>Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина).
Я сейчас проектирую, опираясь на свой обширный опыт. Где почитать — не знаю, т.к. тема эта очень обширная и неопределённая, так же неясен уровень в данной теме у спрашивающего.
Интересует только графика, архитектура сценеграфа? Или есть желание написать свой анреал энджин (шутка)? Для какого рода игр и платформ нужен движок?
Такую книгу видел? Она хороша для начала.
Могу поотвечать на вопросы, если интересно.
Нужно разобрать угил.
Re[3]: Где почитать о проектировании игровых движков?
Здравствуйте, Flammable, Вы писали:
F>Просто рендер — это легче, поскольку не нужна лишняя абстракция для связывания рендера со всякой физикой и игровой логикой. Но для начала и такое пойдет, всяко лучше, чем ничего.
Графика и физика — это архитектурно совершенно разные и несвязанные между собой модули. Их стыковку нужно производить уровнем выше и возможно даже не на уровне движка, а на уровне игры. Т.к. физика зависит от игры, а практически один и тот же сценеграф можно использовать как на телефоне со 100 мегерцами и одним мегабайтом памяти, так и на XBox360.
Я даже графику разделяю на несколько модулей: сценеграф, платформ-зависимый рендерер сценеграфа и воршоп сценеграфа, который занимается кешированием/клонированием/обработкой и т.п. И это не касаясь отдельных либ для сериализации, загрузки и работы с текстурами, математики, файловых операций и всякого вспомогательного хлама.
Нужно разобрать угил.
Re[2]: Где почитать о проектировании игровых движков?
Здравствуйте, Nikе, Вы писали:
N>Я сейчас проектирую, опираясь на свой обширный опыт. Где почитать — не знаю, т.к. тема эта очень обширная и неопределённая, так же неясен уровень в данной теме у спрашивающего. N>Интересует только графика, архитектура сценеграфа?
N>Или есть желание написать свой анреал энджин (шутка)?
Та не, пишу ради практики.
N>Для какого рода игр и платформ нужен движок?
Для FPS, но хочется заранее проектировать так, чтобы ничто не мешало потом сделать на нем RTS. Кроссплатформенность — это сейчас модно, поэтому тоже надо заранее закладывать.
N>Такую книгу видел? Она хороша для начала.
Попадалась на глаза, но не читал. Спасибо.
N>Могу поотвечать на вопросы, если интересно.
Да, интересно. Например, как правильно выстроить архитектуру сущностей? Их нужно как-то разделить на рендерабельные (меши, партиклы, глобальные эффекты, элементы гуя) и нерендерабельные (звуки, скрипты). Где размещать код, который будет выполнять непосредственно рендеринг сущности? Внутри каждой сущности или в отдельном рендере, который умеет?
Re[4]: Где почитать о проектировании игровых движков?
Здравствуйте, Nikе, Вы писали:
N>Графика и физика — это архитектурно совершенно разные и несвязанные между собой модули. Их стыковку нужно производить уровнем выше и возможно даже не на уровне движка, а на уровне игры. Т.к. физика зависит от игры, а практически один и тот же сценеграф можно использовать как на телефоне со 100 мегерцами и одним мегабайтом памяти, так и на XBox360.
Согласен, так должно быть лучше.
N>Я даже графику разделяю на несколько модулей: сценеграф, платформ-зависимый рендерер сценеграфа и воршоп сценеграфа, который занимается кешированием/клонированием/обработкой и т.п. И это не касаясь отдельных либ для сериализации, загрузки и работы с текстурами, математики, файловых операций и всякого вспомогательного хлама.
Сценеграф (единственный?) у тебя является частью рендера?
Re[3]: Где почитать о проектировании игровых движков?
Здравствуйте, Flammable, Вы писали:
N>>Для какого рода игр и платформ нужен движок? F>Для FPS, но хочется заранее проектировать так, чтобы ничто не мешало потом сделать на нем RTS.
Вот, про это я и говорил, что физика и графика на уровне движка никак не связаны. Физика очень сильно зависит от игры. Если для FPS можно брать какой-нибудь PhysX, то для RTS скорее всего нужно писать самому, что-нибудь специализированное.
Игровой движок это очень расплывчатое понятие
F>Кроссплатформенность — это сейчас модно, поэтому тоже надо заранее закладывать.
Вот это зависит от определения движка. Допустим, сделать графику супер-универсальной — не проблема. А вот если ты делаешь удобный движок позволяющий клепать FPS — то тут уже нужно завязываться под какой-то класс устройств. Тот же самый UnrealEngine под iPad ты не запустишь, а вот OSG — запросто.
N>>Могу поотвечать на вопросы, если интересно. F>Да, интересно. Например, как правильно выстроить архитектуру сущностей?
Для меня это слишком общий вопрос. Это уровень конкретной игры.
F>Их нужно как-то разделить на рендерабельные (меши, партиклы, глобальные эффекты, элементы гуя) и нерендерабельные (звуки, скрипты). Где размещать код, который будет выполнять непосредственно рендеринг сущности? Внутри каждой сущности или в отдельном рендере, который умеет?
У меня всегда было так:
1. Уровень сценеграфа. Тут есть только логические примитивы: трансформации, графические пары (сетка|спрайт, материал — определяется платформой), камеры, рендер-таргеты, состояния, анимации и т.п. Говорят — есть каноничная подборка этих примитивов — надо посмотреть по существующим SG Библиотека сценеграфа не знает ничего про то где она будет использоваться. Она сама по себе платформонезависима. Однако, в целях оптимизации некоторые компоненты элементов графа подменяются платформозависимыми объектами перед отправкой на рендеринг. Очень минимальный пример:
class VertexBuffer
{
public:
virtual void* Lock() = 0;
virtual void SendToRender() = 0;
virtual AbsoluteVertexBuffer* IsAbsolute() = 0;
};
class AbsoluteVertexBuffer : public VertexBuffer
{
public:
std::vector<byte> m_Buffer;
...
};
class Mesh
{
VertexBufferPtr m_VertexBuffer;
}
class Appearance : public SGElement <-- элемент сценеграфа
{
MaterialPtr m_Material;
MeshPtr m_Mesh;
}
///////////////////////////////////
// OpenGL rendererclass GlVertexBuffer : public VertexBuffer
{
uint m_VBO;
...
}
На этапе разработки — сцены и все данные грузятся из xml, текстуры — из любых форматов и даже генерируются при старте, а затем конвертируются в нативный формат.
При создании дистрибутива продукта — данные в нативном формате сохраняются в бинари, которые упаковываются в дистрибутив. При достаточном упорстве можно сделать так, что бинарь будет затем грузиться единым куском в память, а затем в этом блоке индексы заменяешь на указатели, расставляешь таблицы виртуальных функций и получаешь готовую сцену. Это необходимо если скорость загрузки критична.
Я щитаю сценеграф хорошо сделанным, если дизайнер может создать в Максе достаточно сложную анимированную сцену (в том числе с переключающимися камерами), экспортнуть её в локальный формат и увидеть в плеере на движке тоже самое, что и в Максе.
2. Вспомогательный уровень. Сцены нужно:
— Грузить.
— Клонировать. Это сравнительно сложно, т.к. в целях оптимизации требуется делать тонкую настройку.
— Кешировать. Текстуры, шейдеры, геометрию и т.п.
— Рендерить. Классы умеющие правильно скармливать сценеграф рендереру я не отношу к самому сценеграфу, т.к. алгоритм зависит от специфики продукта. Нужно делать сортировки по прозрачности, материалам и т.п. и отсекать невидимые подсцены. Сюда, например, относятся порталы (FPS), привязка к 2Д (для стратегий) или 3Д сеткам (полёты всякие) и т.п.
— Партиклы, когда их нужно много — плохо укладываются в сценеграф, поэтому для них делаются специализированные классы, допустим на стратегиях.
— Системы управления анимациями и состояниями. Я рядом со сценеграфом какого-то объекта иногда храню именованные блоки модификаторов, которые можно к этому сценеграфу применить. Примерно так:
Итого, очень многие поведения можно вытащить в данные, посылая только сигналы для их активации. Загрузка сцены происходит с участием разных фабрик, поэтому в сцену можно абстрактно провести что угодно.
3. Сущности уровня продукта.
Они генерируют сценеграфы и манипулируют ими. Или не генерируют, а встраиваются в какой-то большой — опираясь на теги расставленные в графе. Это может быть класс Body, Landscape, Button. Нет смысла делать отдельные механизмы рендеринга для UI, его можно рендерить, через стандартные механизмы. Просто выставляется камера с ортогональным проецированием и всё. Сюда же помещаю продукто-специфичные графические элементы. Например — генерируемый ландшафт, это класс, который динамически создаёт свой сценеграф.
4. Дальше — то, что из этих сущностей уровня продукта формирует сам продукт.
F>Где размещать код, который будет выполнять непосредственно рендеринг сущности? Внутри каждой сущности или в отдельном рендере, который умеет?
Не совсем понял вопрос.
1. Я делаю небольшие библиотеки которые умеют рендерить сценеграф (используя DX, GL, GLES, софтверные рендереры). Примерно так:
2. На уровне программы: как правило формируется сценеграф целиком, который отправляется на рендеринг из одной точки. Однако, на уровне программы — очень часто присутствует некий кустомный умный нод, который умеет отправлять на рендеринг нужные (видимые) подсцены в правильном порядке. Граф не обязан быть внутренне единым целым, но он так выглядит для рендерера:
Связку между графикой, ИИ, физикой и всякой ерундой типа звуков осуществляет слой игрового уровня. Задача движка — предоставить ему удобные и абстрактные инструменты.
Нужно разобрать угил.
Re[5]: Где почитать о проектировании игровых движков?
Здравствуйте, Flammable, Вы писали:
N>>Я даже графику разделяю на несколько модулей: сценеграф, платформ-зависимый рендерер сценеграфа и воршоп сценеграфа, который занимается кешированием/клонированием/обработкой и т.п. И это не касаясь отдельных либ для сериализации, загрузки и работы с текстурами, математики, файловых операций и всякого вспомогательного хлама. F>Сценеграф (единственный?) у тебя является частью рендера?
Рендер — одна из вспомогательных библиотек, умеющая работать со сценеграфом. Аналогично — сериализация.
Нужно разобрать угил.
Re: Где почитать о проектировании игровых движков?
Здравствуйте, Flammable, Вы писали:
F>Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина).
Здравствуйте, Flammable, Вы писали: F>Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина).
исходники всех версий дума и квака открыты. халф-лайфа тоже можно найти при желании.
Re[2]: Где почитать о проектировании игровых движков?
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Flammable, Вы писали: F>>Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина). __>исходники всех версий дума и квака открыты. халф-лайфа тоже можно найти при желании.
Дизайн движка дума объектно-ориентированный только в некоторых местах. Не то.
Квака вообще на C написана.
Re[3]: Где почитать о проектировании игровых движков?
Здравствуйте, Flammable, Вы писали: __>>исходники всех версий дума и квака открыты. халф-лайфа тоже можно найти при желании. F>Дизайн движка дума объектно-ориентированный только в некоторых местах. Не то. F>Квака вообще на C написана.
особенно дум пример прекрасно написанного ООП кода на C
только товарищ Кармак вместо обьявления класса в файлике обьявлял интерфейс из ф-ий, а this передавался явно
типа