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

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

F>Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина).

Что по твоему структурщина? (Пример опенсорсного движка, если можно)

Хочешь ООПнутый движек,правда это скорее просто рендер, посмотри исходники OpenSceneGraph. Мне их подход ужасно не нравится.

Приятный чистый код в Irrlich.
Ogre — куча стращных нагромождений, тебе наверное не понравится

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

T>Что по твоему структурщина? (Пример опенсорсного движка, если можно)
Нужно ООП и С++. Quake 3 написан на C. Doom 3 написан на C++, но на мой взгляд, там какая-то смесь структурщины и ООП. Не то.

T>Хочешь ООПнутый движек,правда это скорее просто рендер, посмотри исходники OpenSceneGraph. Мне их подход ужасно не нравится.
В чем именно, можешь пояснить?

Просто рендер — это легче, поскольку не нужна лишняя абстракция для связывания рендера со всякой физикой и игровой логикой. Но для начала и такое пойдет, всяко лучше, чем ничего.

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

F>Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина).

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

Такую книгу видел? Она хороша для начала.
Могу поотвечать на вопросы, если интересно.

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

F>Просто рендер — это легче, поскольку не нужна лишняя абстракция для связывания рендера со всякой физикой и игровой логикой. Но для начала и такое пойдет, всяко лучше, чем ничего.

Графика и физика — это архитектурно совершенно разные и несвязанные между собой модули. Их стыковку нужно производить уровнем выше и возможно даже не на уровне движка, а на уровне игры. Т.к. физика зависит от игры, а практически один и тот же сценеграф можно использовать как на телефоне со 100 мегерцами и одним мегабайтом памяти, так и на XBox360.
Я даже графику разделяю на несколько модулей: сценеграф, платформ-зависимый рендерер сценеграфа и воршоп сценеграфа, который занимается кешированием/клонированием/обработкой и т.п. И это не касаясь отдельных либ для сериализации, загрузки и работы с текстурами, математики, файловых операций и всякого вспомогательного хлама.

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

N>Я сейчас проектирую, опираясь на свой обширный опыт. Где почитать — не знаю, т.к. тема эта очень обширная и неопределённая, так же неясен уровень в данной теме у спрашивающего.
N>Интересует только графика, архитектура сценеграфа?

N>Или есть желание написать свой анреал энджин (шутка)?
Та не, пишу ради практики.

N>Для какого рода игр и платформ нужен движок?
Для FPS, но хочется заранее проектировать так, чтобы ничто не мешало потом сделать на нем RTS. Кроссплатформенность — это сейчас модно, поэтому тоже надо заранее закладывать.

N>Такую книгу видел? Она хороша для начала.
Попадалась на глаза, но не читал. Спасибо.

N>Могу поотвечать на вопросы, если интересно.
Да, интересно. Например, как правильно выстроить архитектуру сущностей? Их нужно как-то разделить на рендерабельные (меши, партиклы, глобальные эффекты, элементы гуя) и нерендерабельные (звуки, скрипты). Где размещать код, который будет выполнять непосредственно рендеринг сущности? Внутри каждой сущности или в отдельном рендере, который умеет?

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

N>Графика и физика — это архитектурно совершенно разные и несвязанные между собой модули. Их стыковку нужно производить уровнем выше и возможно даже не на уровне движка, а на уровне игры. Т.к. физика зависит от игры, а практически один и тот же сценеграф можно использовать как на телефоне со 100 мегерцами и одним мегабайтом памяти, так и на XBox360.
Согласен, так должно быть лучше.

N>Я даже графику разделяю на несколько модулей: сценеграф, платформ-зависимый рендерер сценеграфа и воршоп сценеграфа, который занимается кешированием/клонированием/обработкой и т.п. И это не касаясь отдельных либ для сериализации, загрузки и работы с текстурами, математики, файловых операций и всякого вспомогательного хлама.
Сценеграф (единственный?) у тебя является частью рендера?

Здравствуйте, 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 renderer
class GlVertexBuffer : public VertexBuffer
{
  uint m_VBO;
  ...
}

На этапе разработки — сцены и все данные грузятся из xml, текстуры — из любых форматов и даже генерируются при старте, а затем конвертируются в нативный формат.
При создании дистрибутива продукта — данные в нативном формате сохраняются в бинари, которые упаковываются в дистрибутив. При достаточном упорстве можно сделать так, что бинарь будет затем грузиться единым куском в память, а затем в этом блоке индексы заменяешь на указатели, расставляешь таблицы виртуальных функций и получаешь готовую сцену. Это необходимо если скорость загрузки критична.
Я щитаю сценеграф хорошо сделанным, если дизайнер может создать в Максе достаточно сложную анимированную сцену (в том числе с переключающимися камерами), экспортнуть её в локальный формат и увидеть в плеере на движке тоже самое, что и в Максе.
2. Вспомогательный уровень. Сцены нужно:
— Грузить.
— Клонировать. Это сравнительно сложно, т.к. в целях оптимизации требуется делать тонкую настройку.
— Кешировать. Текстуры, шейдеры, геометрию и т.п.
— Рендерить. Классы умеющие правильно скармливать сценеграф рендереру я не отношу к самому сценеграфу, т.к. алгоритм зависит от специфики продукта. Нужно делать сортировки по прозрачности, материалам и т.п. и отсекать невидимые подсцены. Сюда, например, относятся порталы (FPS), привязка к 2Д (для стратегий) или 3Д сеткам (полёты всякие) и т.п.
— Партиклы, когда их нужно много — плохо укладываются в сценеграф, поэтому для них делаются специализированные классы, допустим на стратегиях.
— Системы управления анимациями и состояниями. Я рядом со сценеграфом какого-то объекта иногда храню именованные блоки модификаторов, которые можно к этому сценеграфу применить. Примерно так:

<Scene>
  <Transform Name="Tree" ...
      <Animation Name="WindAnimation" Enabled="0" ...
  </Transform>
  <Configuration Name="EnableWind">
    <Modify Element="WindAnimation" Enable="1"/>
    <Call Function="EnableSound:TreeWind"/>
  </Configuration>

Итого, очень многие поведения можно вытащить в данные, посылая только сигналы для их активации. Загрузка сцены происходит с участием разных фабрик, поэтому в сцену можно абстрактно провести что угодно.
3. Сущности уровня продукта.
Они генерируют сценеграфы и манипулируют ими. Или не генерируют, а встраиваются в какой-то большой — опираясь на теги расставленные в графе. Это может быть класс Body, Landscape, Button. Нет смысла делать отдельные механизмы рендеринга для UI, его можно рендерить, через стандартные механизмы. Просто выставляется камера с ортогональным проецированием и всё. Сюда же помещаю продукто-специфичные графические элементы. Например — генерируемый ландшафт, это класс, который динамически создаёт свой сценеграф.
4. Дальше — то, что из этих сущностей уровня продукта формирует сам продукт.

F>Где размещать код, который будет выполнять непосредственно рендеринг сущности? Внутри каждой сущности или в отдельном рендере, который умеет?
Не совсем понял вопрос.
1. Я делаю небольшие библиотеки которые умеют рендерить сценеграф (используя DX, GL, GLES, софтверные рендереры). Примерно так:

class Renderer
{
public:
  virtual VertexBufferPtr CreateVertexBuffer( size_t size ) = 0;
  virtual TexturePtr CreateTexture() = 0;
  virtual void Apply( Material& ) = 0;
  virtual void Draw( Geo& ) = 0;
}
class DXRenderer : public Renderer
{
   ...
}

2. На уровне программы: как правило формируется сценеграф целиком, который отправляется на рендеринг из одной точки. Однако, на уровне программы — очень часто присутствует некий кустомный умный нод, который умеет отправлять на рендеринг нужные (видимые) подсцены в правильном порядке. Граф не обязан быть внутренне единым целым, но он так выглядит для рендерера:

class SpatialLocator2D
{
public:
  void SetupLandscape( const Landscape& );
  void RegisterSmallObject( ElementPtr subSceneRoot, Rect area );

  void ProcessVisibleScene( SceneProcessor& proc )
  {
    m_Landscape.ProcessVisibleScene( proc );
    LocateAndProcessAllVisibleObjects( proc );
  }
};

SceneDrawer drawer( renderer, frustum );
m_World.ProcessVisibleScene( drawer )
m_Gui.Process( drawer );
drawer.Finish();

Связку между графикой, ИИ, физикой и всякой ерундой типа звуков осуществляет слой игрового уровня. Задача движка — предоставить ему удобные и абстрактные инструменты.

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

N>>Я даже графику разделяю на несколько модулей: сценеграф, платформ-зависимый рендерер сценеграфа и воршоп сценеграфа, который занимается кешированием/клонированием/обработкой и т.п. И это не касаясь отдельных либ для сериализации, загрузки и работы с текстурами, математики, файловых операций и всякого вспомогательного хлама.
F>Сценеграф (единственный?) у тебя является частью рендера?

Рендер — одна из вспомогательных библиотек, умеющая работать со сценеграфом. Аналогично — сериализация.

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

F>Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина).

Гибкая и масштабируемая архитектура для компьютерных игр, часть первая

Здравствуйте, Flammable, Вы писали:
F>Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина).
исходники всех версий дума и квака открыты. халф-лайфа тоже можно найти при желании.

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

__>Здравствуйте, Flammable, Вы писали:
F>>Сабж. С примерами в виде исходников, насколько я понял, все очень плохо (интересует красивый и прозрачный объектно-ориентированный дизайн, а не всякая структурщина).
__>исходники всех версий дума и квака открыты. халф-лайфа тоже можно найти при желании.
Дизайн движка дума объектно-ориентированный только в некоторых местах. Не то.
Квака вообще на C написана.

Здравствуйте, Flammable, Вы писали:
__>>исходники всех версий дума и квака открыты. халф-лайфа тоже можно найти при желании.
F>Дизайн движка дума объектно-ориентированный только в некоторых местах. Не то.
F>Квака вообще на C написана.
особенно дум пример прекрасно написанного ООП кода на C
только товарищ Кармак вместо обьявления класса в файлике обьявлял интерфейс из ф-ий, а this передавался явно
типа

map.h

struct Map{}
void initMap(Map *);
void doSomethingWithMap(Map *)