Технологии игровых движков
 

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

Какие концепции реализации движков Вам по душе больше, чем другие?

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

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

Ответ: Технологии игровых движков
 

По мне так движок (3Д) должен:
1. Рендерить сцену
2. Играть звук/музыку
3. Читать ввод.
4. Быть дружелюбным к взаимодействию с движками другого функционала (напр. физики)

Остальное делает программист игры. ИМХО.

Ответ: Технологии игровых движков
 

Но есть движки, у которых рисование и апдейт врознь - в различных методах.
А есть, например, что все в одном цикле. И нужно прописывать вручную рисвание и апдейт.
Какому отдашь предпочтение?

Ответ: Технологии игровых движков
 

если уж пихать звук, то заодно и физику

Ответ: Технологии игровых движков
 

Всегда был сторонником такого подхода:
-логика
-рендер
-обработка рендера

При этом в логике, как правило, сперва идёт считывание ввода, затем обработка ввода, затем (на основании изменённых вводом данных) - обработка не зависящих напрямую от ввода параметров (ИИ например)

Но всегда у меня получается своего рода "мостик" между вводом и воздействием на игру... И как правило этот "мостик" можно перекидывать между разными объектами, т.е. объектом действий игрока могут быть разные игровые объекты - камера, робот #1, робот #2, джип и т.п.

Ответ: Технологии игровых движков
 

Ой...сколько людей, столько и мнений :)
Как по мне, движок — это очень абстрактное понятие. Каких их только не бывает: графический, звуковой, сетевой, физический, игровой.
Сферу деятельности каждого устанавливает программист, который, как обычно, не зная меры, награждает всего и сразу.
Лазая по категориям абстракции можно конечно сделать логические выводы типа: графический движок — это то, что рисует, предварительно создав окно.
Но вот только так ли это на деле? :-D

Вот для меня например, игровой движок — это то, что организует взаимодействие объектов, выстраивая их в иерархию, фильтруя их и так далее. Игровой движок - это так же связующее звено между всеми компонентами игры. В таком случае графический движок должен быть просто приемником данных, которые нужно показать. В случае с ОГРом же, видно что он берет на себя функционал по части менеджмента сцены, ресурсов, плагинов, работы с памятью и так далее, т.е. его понесло в игровые степи.

Хотя наличие этого функционала понятно: определение видимых объектов, облегчение управления объектами и так далее. Без них движок был бы уже менее эффективным, а программисту, бедолаге, пришлось бы все это реализовывать самому. И ведь не факт, что он бы оптимально использовал возможности ОГРа.

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

Сама же игра, опять-таки, понятие растяжимое. В каждом конкретном случае структура будет разная, но есть блоки, которые присутствуют всегда: это, как уже было сказано ранее, обновление мира, сбор пользовательского ввода, отрисовка видимых объектов, ИИ, звук, физика, сеть, что там еще? :)

В общем пытаться все идеально обрисовать "из далека" — как по мне, очень сложно. Лучше все таки действовать методом проб - эффективнее будет :)

Ответ: Технологии игровых движков
 

Для меня графический движок - функция, которая выводит на экран изображение того, что творится в игре. Больше ничего не добавляю, лучше по кусочкам:
чтение ввода с клавиатуры, сенсора и т.п. и обработка нажатий
шаг программы (передвижение юнитов, действия AI и прочее)
вывод изображения на экран
и снова)

Ответ: Технологии игровых движков
 

некропостить так некропостить !! ;)
Я лично отдаю предпочтение тем движкам у которых это разбито на 2 фукционала !! А собственно ядро двига разбито на манагеры !! ИнпутМанагер, СценеМнагер, ПартиклМанагер ГУИМанагер и т.д. !! У каждого свой апдейт и рендер, а возможно что то одно !! Например в ИнпутМанагера (менеджера ввода) рендера никакого естественно нет !!
Я считаю это очень удобно, вот !! :)

Ответ: Технологии игровых движков
 

MVC иногда плачет при виде этих слов

Ответ: Технологии игровых движков
 

ужас какой-то в теме, брррр:crazy:

…давайте посмотрим правде в глаза - Вы начинаете делать универсальные игровые движки, когда у Вас закончились идеи для создания игр.
Richard Fine, Enginuity, Part I

Ответ: Технологии игровых движков
 

Непоняв, чего ??

Ответ: Технологии игровых движков
 

та так, как говорится highly professional scums

Ответ: Технологии игровых движков
 

Игр движек, та хрень - которая удовлетворят ваши потребности при разработке игры

Ответ: Технологии игровых движков
 

Просвети чтоб MVC повеселело.

Ответ: Технологии игровых движков
 

MVC это Model–view–controller, софтварная архитектура (http://en.wikipedia.org/wiki/Model–view–controller)

при обилии разных интересных модулей народ начинает путаться что есть что в этой архитектуре, и получается что в одном уровне абстракции это модель, в другом контролёр и тд, иногда вообще "объект - золотые руки" который делает всё что надо и не надо

к примеру сцена является отображением модели игрового мира, хотя для рендера сцена сама является моделью, а рендер это отображение сцены и тд