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

[Движок]<->[Драйвер+Медиатор]<->[Игровая логика]
###|##########|###############|
###|--------------> [Утилиты]<--------------------|

Движок, игровая логика, и утилиты будут находиться в DLL.
Драйвер+Медиатор будет находиться в одной EXE, где и будет собственно вся инициализация, цикл приложения и т.д.
Движок - граф, сетевой, и т.д. движок.
Игровая логика - всё что связано непосредственно с логикой игры.
Собственно какие проблемы:
1) Общаться через медиатор - жрёт много ресурсов - думаю наилучшее решение: напрямую односторонние вызовы движка из игровой логики.
2) Утилиты, тут я вообще в ауте. Всё что там есть, вроде нужно всем, с другой стороны - создавать три копии одного фреймворка, как-то не есть гуд.
3) Может вообще запихнуть всё в одну EXE?
С уважением.
Добавлено @ 09:54
Ещё одно решение, на котором я сейчас остановился:
Запихал утилиты в главный EXE и передаю фабрику обьектов обоим модулям.

Это сообщение отредактировал(а) chipset - 4.4.2005, 09:50

chipset
Ты не мог бы немного поподробнее, а то как-то все сумбурно и непонятно...

Цитата(arilou @ 4.4.2005, 01:15)

Ты не мог бы немного поподробнее, а то как-то все сумбурно и непонятно... smile

Есть игра
Игра состоит из следующих блоков(как предполагается):
1) Игровой движок - это: загрузка 3D моделей, работа с 3D графикой, 2D графикой, сетевые функции, звук, управление (джойстик) и т.д.
2) Логика игры - это сам сюжет, правила игры, кондиции, карты, и т.д...
3) Драйвер игры - это EXE файл который запускается пользователем. Он инициализирует все модули, самого себя, и служит границей между двумя модулями [№1,№2], эдаким переправочным пунктом.
Также, в этом EXE находятся всевозможные утилиты, наподобие: сериализационных, XML-тулзов, скриптов, парсинг и т.д...
...
Есть два момента ради которых я создал эту тему:
1) Мне не нравится то что драйвер игры служит переправочным модулем, мне кажется это сокращает производительность.
2) Дело в том что утилиты содержащиеся в драйвере будут, скорее всего нужны всем трём модулям.
...
Для второго пункта я придумал временное решение, основанное на четвертой динамической библиотекой, которая будет инкапсулировать утилиты.
Мне не хочется плодить DLL вот только...

Все понятно, а чем тебе не нравится DLL? Ведь она выполняется в адресном пространстве процесса? Ведь затрат на вызов не будет.

По-моему, 1 и 3 - это код, все верно. А вот 2 - это уже контент, так сказать. Ведь сюжет, правила, и т.д. можно описать с помощью данных (например, XML). Поэтому в п.1 у тебя должны быть средства, которые п.2 будут загружать, парсить, и давать возможность взаимодействовать между собой и игроком.

Цитата(chipset @ 4.4.2005, 11:26)

Дело в том что утилиты содержащиеся в драйвере будут, скорее всего нужны всем трём модулям

Цитата(chipset @ 4.4.2005, 11:26)

Для второго пункта я придумал временное решение, основанное на четвертой динамической библиотекой

Именно это решение и напрашивается само собой.

============

Вообще, я бы выделил такие части:
1. Движок контента - отрисовка графики, воспроизведение звука. Он не зависит от всего остального и предоставляет унифицированный интерфейс к своим ф-циям. Сюда же идет поддержка сцен и сети. При желании, сеть можно выделить в отдельный "движок".

2. Движок игры - поддержка скриптов, персонажей, айтемов, триггеров, событий. Сюда идет подсистема, которая позволяет загружать и сохранаять данную информацию.

3. Набор утилит, которые пользуются интерфейсами из 1 и 2, и дают возможность редактировать контент, поддерживаемый этими подсистемами.

4. Некий runtime, которому дается начальная позиция, по которой он инициализирует игровой мир.

Все это в сумме называется "игровой движок". Сама игра - это, на мой взгляд, контент, порожденный при помощи п.1, 2 и 3, "запускаемый на выполнение" п.4.

Цитата(arilou @ 4.4.2005, 01:47)

Все понятно, а чем тебе не нравится DLL? Ведь она выполняется в адресном пространстве процесса? Ведь затрат на вызов не будет.

tnx, так и сделаю

Цитата(arilou @ 4.4.2005, 01:47)

Вообще, я бы выделил такие части:

Сейчас так все и нарисовано, кроме библиотеки утилит

Цитата(arilou @ 4.4.2005, 01:47)

А вот 2 - это уже контент, так сказать. Ведь сюжет, правила, и т.д. можно описать с помощью данных (например, XML).

Да, конечно..

В качестве примера посмотри Unreal Engine 2 Runtime.

Цитата(arilou @ 4.4.2005, 02:12)

В качестве примера посмотри Unreal Engine 2 Runtime.

Глянул Ну на этом принципе работает и HalfLife, взять хотя-бы кол-во модов к нему..
Да и не хотим мы игру в DLL засовывать
Изначально ведь и задумывается как: правила, загрузчик и обработчик карт.

Это сообщение отредактировал(а) chipset - 4.4.2005, 12:35

Цитата(chipset @ 4.4.2005, 12:34)

Да и не хотим мы игру в DLL засовывать

Поясни плих немного этот момент - как это, игру - и в DLL?
---
800-ое сообщение!!!

Это сообщение отредактировал(а) chipset - 4.4.2005, 15:24

Цитата(arilou @ 4.4.2005, 05:17)

Поясни плих немного этот момент - как это, игру - и в DLL?

Под этим я подразумеваю засовывание всего составляющего игры: NPC, карты, диалоги, названия,и т.д., в DLL.


Это сообщение отредактировал(а) chipset - 4.4.2005, 15:24

Цитата(chipset @ 4.4.2005, 15:24)

Под этим я подразумеваю засовывание

Тогда согласен на все 100%. Кстати, с .NET'ом отпадает необходимость в интерграции в движик какого-либо скриптового языка.

Цитата(arilou @ 4.4.2005, 05:27)

Кстати, с .NET'ом отпадает необходимость в интерграции в движик какого-либо скриптового языка.

Это в таком смысле, что C# настолько простой язык, что сам сойдет в роли скрипт-языка? Я что-то не сильно понял

Это сообщение отредактировал(а) chipset - 4.4.2005, 15:30

Цитата(chipset @ 4.4.2005, 15:30)

Я что-то не сильно понял

.NET framework дает возможность в рантайме загружать любые сборки и выполнять оттуда код. Это позволяет использовать любой .NET-совместимый язык как "скриптовой".

Для запуска скриптов можно использовать AppDomain'ы. Это нужно для того, чтобы иметь возможность выгрузить скрипт, изменить, перекомпилить, и запустить заново. Причем компилирование скрипта можно сделать с помощью самого движка, благо что .NET дает соотв. классы для динмамической кодогенерации.

Получаешь выигрыш в производительности, потому что выполняется native код, а не интерпретируется.

Вот.

arilou, ещё одно преимущество в сторону .NET для игровых разработок
Хотя это уже в малость другую тему