Про "готовые" движки

Так случилось, что в последнее время вопрос "готовых" движков довольно часто поднимался, поэтому хотелось бы "развеять несколько мифов".
.
Наиболее сильно внушаемый миф упрощённо звучит примерно так "не делайте движок, сосредоточьтесь на игре". В реальности же, чаще всего, вместо "тратим силы на собственный тех" получаем "боремся с чужим техом". Использование ^готового движка^ НЕ сокращает время разработки и НЕ сокращает количество необходимых ресурсов по программированию. Просто сравните кредитсы игр на "своём" и "чужом" движке -- количество программистов и там и там примерно одинаково (я конечно же говорю про более-менее успешные коммерческие игры -- т.е. не бесплатные инди-поделки или говноигры "по лицензии").
.
Что действительно позволяет "готовый движок" -- сразу начать клепать арт и видеть как что-то бегает по экрану. Это обычно магически действует на манагеров/директоров. Обратная сторона медали -- возможность наваять _гору_ контента задолго до того, как придёт понимание что и как нужно делать. Я самолично наблюдал, как было сделано несколько _сотен_ анимаций (настоящих персонажных анимаций, не спрайтиков), которые потом ВСЕ пришлось чуть ли не сделать заново.
.
"Готовый" движок на самом деле может быть полезен -- но только тем, чья квалификация такова, что они сами могут без проблем написать всё то же самое (и, неудивительно, что они таки пишут). Вот такой вот парадокс. Подавляюшее большинство по настоящему успешных игр сделано на "доморощенной" технологии и это не случайность, а скорее закономерность. (И не нужно приводить примеры Bioshock, Mass Effect -- "готовый" UE был настолько сильно модифицирован, что называть его UE можно с очень большой натяжкой).
.
Итого. Писать нужно игру, не движок. Но бороться при этом лучше со своим техом, а не с чужим -- выходит лучше (по статистике). Таких вещей как "готовый движок" и "полная документация" не существует в природе; это банальная истина, но шмаркетологи часто хотят внушить обратное (а манагеры/разработчики хотят верить).
.
P.S. Разумеется, в случае с middleware всё по другому. Если это правильный middleware конечно, т.е. с документацией, примерами, исходниками, возможностью контролировать память и т.п.
Submitted by BLK Dragon on

Комментарии

По своему опыту вижу это так - сначала всегда попробуй то, что сделали до тебя.
Максимально разберись с тем, что в готовых продуктах тебя не устраивает.
Выбери (выдели) то отличающие от всех, что потом будешь продавать, показывать от чего твои игроки не отведут глаз и именно это доведи до совершенства.
Пример Ил-2 Штурмовик (серия).
1. До него были симуляторы полетов - да, были 2 мировой тоже да (качаем смотрим).
2. В готовых до этого продуктах хромала достоверность и физ модель поведения планеров в бою (т. е. отсутствовал реализм).

3. Соответственно продаем - реализм, историческую достоверность воздушного боя времен 2 Мировой.

По 3 пунктам видим что необходим свой 3d/физ/звук движок.

Submitted by Necro on

ПОлностью согласен. Для того, чтобы овладеть "готовым" инструментарием нужно потратить немало времени и не факт, что в итоге это будет оправдано.

Submitted by Aleks_T on
По своему опыту вижу это так - сначала всегда попробуй то, что сделали до тебя. Ну понятно, что не нужно пытаться всё делать самому ради того чтобы сделать всё самому.
Submitted by BLK Dragon on
Quote:
BLK Dragon писал(а):
1. Наиболее сильно внушаемый миф упрощённо звучит примерно так "не делайте движок, сосредоточьтесь на игре". . . . 2.Итого. Писать нужно игру, не движок.
Мне одному кажется, что в этих двух высказываниях кроется противоречие? Или я чего-то не догоняю? Какой-то странный стиль изложения - прочитал несколько раз и так и не понял - так стОит все-таки использовать готовый движок или нет?
Submitted by DekaSoft on
Мне одному кажется, что в этих двух высказываниях кроется противоречие? Или я чего-то не догоняю? Какой-то странный стиль изложения - прочитал несколько раз и так и не понял - так стОит все-таки использовать готовый движок или нет? Нету противоречия. Движок должен расти вместе с игрой, т.е. нового функционала должно добавляться ровно столько, чтобы поддержать развитие игры (или игр если несколько на движке делается). Не нужно писать движок ради писания движка. Это так, наблюдение из жизни. Ответ на вопрос "стоит ли использовать движок" зависит от множества факторов -- какой проект делать, какой командой, какие сроки, какой движок.
Submitted by BLK Dragon on

to BLK Dragon: Спасибо за четкое внятное разъяснение ситуации среди движков Smile

Submitted by rkamo on

по этому поводу в своё время ходил перл - что бы ты не начинал делать на UE, всегда получается Gears Of War Biggrin

Submitted by Relyer on
по этому поводу в своё время ходил перл - что бы ты не начинал делать на UE, всегда получается Gears Of War Это звучит так: "что с унрылом не делай -- получается унрил турнамент, только ##" -- практически слово в слово как я это слышал от манагера когда-то :) Справедливости ради, на УЕ много разных проектов сделали. Стоило ли их делать именно на УЕ -- вопрос отдельный.
Submitted by BLK Dragon on
Извечная тема велосипедостроения и доводки конечного изделия напильником.

Как всегда проблема поиска золотой середины... )

Submitted by Victor on
Виктор к сожалению проблема движков, подходов и техник будет всегда. Например что я сейчас вижу - действительно старые движки (DirectX 9.0c) проигрывают в производительности решениям DirectX11/10. Потому как там большая часть операций ускоряется аппаратно и делается это очень быстро и без нагрузки на процессор. Тоже касается физики. Если бы к примеру Quake3 переписать на DirectX 11 - было бы 1000+ FPS. Появляются и новые подходы к текстурированию делая модельки все красивее и красивее.
Submitted by Necro on
Например что я сейчас вижу - действительно старые движки (DirectX 9.0c) проигрывают в производительности решениям DirectX11/10. C этим как раз просто -- нету особого смысла использовать DX10/DX11, ибо на PS3/X360 всё равно SM3.0 с нюансами; и ситуация в ближайшие лет 5 не изменится (даже если Wii2 будет и будет круче текущего поколения). На хандхелдах и подавно. // зачем не нужно ориентироваться на пейси, надеюсь, обяснять не нужно А модельки красивыми делают, как правило, артисты, а не новые подходы к текстурированию.
Submitted by BLK Dragon on

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

Submitted by Necro on
При новом подходе идет переход от понятия текстуры к понятию материал Так а что тут "нового"? Лет 5 (а то и 10) нормальные люди (в готовых движках и подавно) оперуют понятием "material/effect/surface" -- т.е. совокупностью vertex-prog + fragment-shader + parameters(всякие разные, в том числе и текстуры). Я последний раз "текстурами" мыслил как раз где-то в 2003 году когда на PowerTV ваял игрульки.
Submitted by BLK Dragon on

В свое время также появился Nextgen в свете приставок нового поколения с нормал мапами, спекулами и прочими шейдерами. Хотя для пк тогда это уже давно было нормой.

Submitted by Aleks_T on
В свое время также появился Nextgen в свете приставок нового поколения с нормал мапами, спекулами и прочими шейдерами. Хотя для пк тогда это уже давно было нормой. Normal-map'ы и бампы, если придираться, придумали задолго до шейдеров. В SoulCaliburIII на пс2 на некоторых уровнях можно наблюдать нечто до боли похожее на нормал-мап :) В любом случае к движкам это то это каким боком?..
Submitted by BLK Dragon on

Я это к тому, что фактически у готовых движков нет чего-то действительно особенного, что делало бы их выбор критичным.

Submitted by Aleks_T on
Я это к тому, что фактически у готовых движков нет чего-то действительно особенного, что делало бы их выбор критичным. Да ну прямо таки; например, инструментарий -- вполне себе причина выбирать "готовый" движок. Делать уровни в UnreadEd и возюкаться с каким-нить Ogre3D -- две большие разницы :) А скорость производства контента -- очень даже критичный параметр.
Submitted by BLK Dragon on

Хых, так то оно так, вот только надо еще потратить время на глубокое знакомство с тем же UnreadEd)

Submitted by Aleks_T on
Хых, так то оно так, вот только надо еще потратить время на глубокое знакомство с тем же UnreadEd) Достаточно посмотреть пару часов видео-туторов про UDK чтобы оценить удобство инструментария. Я как бы не рекламирую УЕ, просто смотрел на всякое разное когда делал свои тулзы. С тем же Унити, опять же хватило нескольких часов, чтобы осознать насколько он бесполезен в качестве level-editor. Так что всё достаточно шустро выясняется.
Submitted by BLK Dragon on
Quote:
Necro писал(а):
При новом подходе идет переход от понятия текстуры к понятию материал.
Гдето это уже было, ааа Dx8, 7 итд, действительно новый подход. :-)

По поводу материалов на данный момент - материал это тупо установка нужного шейдера, я не понимаю зачем они вообще нужны как абстракция програминга. Как логическая абстракция вполне. Анимированые текстуры отдельно стоят, рендер в текстуру тоже. тусовать вместе глупо - мешать боб с горохом, както так Smile

Я категорично утверждаю, что от DX нужно только установка текстур, шейдера и вершинного буфера, а и стейтблоков - идеальное апи, остальное всё мусор.

Submitted by Relyer on

2Relyer

Ещё и тебе повторю -- к теме движков это всё мало относится. Тот же УЕ стОит столько, сколько стоит, не за то как он там треугольники рисует.

Submitted by BLK Dragon on
Quote:
BLK Dragon писал(а):
Ещё и тебе повторю
А помоему очень даже относится, пост то про то что, по сути движки сравнивать по рендору тупо, я написал что реально грубо говоря 4 функции используется от граф апи к граф апи. А вот склепать нормальный тулсет и продумать архитектуру - это проблема. Ты видно прочетал его через строчку или как я хз :-D
Submitted by Relyer on

GameDev.by