Архитектура движка игры.

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

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

Вопрос вот в чем - как лучше реализовать это деление? Каждый отдельный - dll или lib (лучше lib, обращение к дижку будет только из самого движка), в нем глобальный класс движка с соответствующими подклассами и функциями? И каким образом лучше всего обработать передачу данных между движками?

Как-то не хватает мозгов охватить все глобально. Не подскажете? :)

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

А потом понять, что все было криво и переписывать с нуля.

Вот наброски. Чистовой уже вариант, но все еще не доделанный из чернового.
Много недоделанного. Пока бери что есть. Авось почерпнешь что то полезное.
Когда допишу статью про управление, может и доделаю.

Глобальная структура:

Наброски основных частей:

Пример работы главного цикла падения шарика на наклонную плоскость:

Пробуй, смотри. Если есть идеи - высказывай. Может тогда и доделаю это раньше.
Просто знай, что есть два метода: инкапсулированный и быстрый. Истина где то между ними.

Огого! 0_о

Спасибо большое :)

Namynnuz
http://www.terathon.com/c4engine/architecture.php
А вообще, архитектура такая штука, что либо её сам придумываешь (1) -> реализовываешь(2) -> используешь(3) -> переделываешь архитектуру(3) -> goto (2)... либо берёшь готовое и ждёшь обновлений. по моему брать готовую архитектуру и реализовывать не есть хорошо, разве что только посмотреть, подумать и сделать свою...

the_siv
> http://www.terathon.com/c4engine/architecture.php
Вот-вот, а я как раз искал эту картинку.

Благодрю тебя, the_siv. Ты сэкономил мне несколько тысяч нервных клеток. И да, ты прав. Пока что ничего действенней "посмотрел и придумал свое" не существует:)

Amber
Скажите пожалуйста, а где получаются такие красивые диаграммы?

Lost
Visio попробуй.

Lost
> Скажите пожалуйста, а где получаются такие красивые диаграммы?
спроси у кошмареца, он знает

> Скажите пожалуйста, а где получаются такие красивые диаграммы?
Красивые?! Как для человека далекого от разработки по - возможно...

> Visio попробуй.
Или Rational Rose

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

Я реально не понимаю ценность етих картинок... разве что для осознания что вообще в движке может бъть, но не более. Примерно стрелочки с связями между модулями - ето курам на смех. Часть подсистем тоже.
Т.е. отталкиватся надо от требований к движку, а не от такой диаграмъ, которая делалась неведомо кем, неведомо для чего.
Вот к примеру - есть какие-то требования к игре - DX9 рендер, стриминг, статичность мира, нет рандом генератора, локации маленькие но стримящиеся одна в другую, мир 2.5D (т.е. плоский), солнце не двигается, много поинт лайтов, физика, онлайн, сплит-скрин, етц. Платформа PC (low end) + Mac.
Отсюда уже можно делать въводъ про сам тек и про движок - бейкать лайтинг, писать forward рендер для low-end-а, думать что будет со сцен графом + сплит скрин.
Потом разложить по подсистемам - файловая система для паков, шрифтъ, UI, организация сценъ (для физики и рендера), скрипт и нужен ли вообще, рендер поверх той сценъ. Потом подумать про експорт арта и про то, как несколько человек будут его делать, тестить и заливать в билд, несколько человек (евентуально) будут писать скрипт, все ето дело будет паковать билд процесс и т.д.
И потом уже доходим до всяких ТextureManager, которъе в общем случае даже не нужнъ.
Т.е. я понимаю, что ето любительский проект - я просто дал пример о чем хорошо подумать, а не смотреть на какие-то диаграммъ сомнительной ценности.

Z
+1