Блог компании Social Quantum
Разработка игр
Комментарии 48
0
Если бы ты был программером, а не дизайнером, то тебе было интересно писать именно движок.
0
Писал свой велосипед для fintank.ru. Написание своих движков — вопрос всегда чисто политический вида «прикалывает ли нас полный суверенитет достаточно сильно».
+3
Те 41% своих движков лишь показывают, что unreal и unity не покрывают всех потребностей.
Может нужно что-то более низкоуровневое и гибкое?
+1
все кому нужен ниже порог входа и меньше затрат времени ради свистоперделок, уже выбрали unreal, unity, cocos итд итп
+3
Или показывают, что проект начался ещё до того, как Unity вообще появился.
0
Unity появился больше 10 лет назад. Большинству проектов столько времени и близко не нужно.
0
Ну а все же — яркий пример использования популярного движка это PUBG. Там они сами криворукие или движок все же не такой хороший, как позиционируется? Игра из топа Steam и онлайна в 3кк человек очень резко скатывается, буквально за полгода в 1кк. Неужели даже изрядно подзаработав нельзя было пригласить экспертов из команды разработки движка? Мне кажется они так делали, просто ничего исправить не вышло… Хотя кто знает.
+1

Да да, и bluehole (pubg) даже судиться пытались, что абсурд. Но все же — анрил хорош и универсален или только если ты его разработчик? :)

+1
Я смотрел пару разборов, почему PUBG тормозит.
У меня сложилось впечатление, что там не движок виноват, а полное отсутствие настройки.
Вот один из моментов youtu.be/oup3dSeGAhM?t=303
0
Они даже защиту от спидхака не включили, хотя она ещё до PUBG была прямо в движке. Всего-то нужно включить защиту и поменять пару цифр для настройки, я в своей игре это сделал за 5 минут. Что уж говорить про остальное…
+1
Там они сами криворукие или движок все же не такой хороший, как позиционируется?

Не в том дело криворукие или нет, что бы сделать что то качественно нужно ВРЕМЯ а бизнесу нужно здесь и сейчас и потому ставят жесткие временные рамки, так как сотрудники на зарплате, нужно платить оренду и т.д. деньги на все это идут а прибыли нету, вот и приходится жертвовать качеством чтобы быстрее сделать итоговый продукт, это сама по себе порочная система и вряд ли из этого есть выход.

Неужели даже изрядно подзаработав нельзя было пригласить экспертов из команды разработки движка?

Не думаю что таких высокоценных экспертов кому либо делегируют посторонним компаниям.
+1
Учитывая тенденцию на монетизацию всего и вся у разработчиков PUBG — я думаю, что они просто жадные и руководствуются тем, что если играют и в кривое, то зачем нанимать людей, которые могут починить одно, но при этом сломать другое.
Думаю там очень много работы для целой команды профессионалов.
0
Я полностью поддерживаю тему разработки своих движков. Плюсы таковы вы делаете то что надо.
+2
Видать вы их не писали.
Проблемы

1 Баги.
Не просто баги, а Куча постоянно появляющихся багов. Движок живой и постоянно допиливается, откуда эти животинки постоянно лезут.
А у тебя нет комунити из 100к юзеров которые за день выловят 99% проблемных мест.

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

3 Новые фичи движка
Даже обычный вывод текста — это жуть на сколько сложно, если тебе надо сделать не абы как, а с хорошей производительностью.
Что уж говорить о прикрутке физики, аи, скелетов и т.д.

4 Кроссплатформенность
На каждую платформу надо найти спеца, обучить движку, потратить кучу времени на согласование с уже наработанным.
И каждая новая платформа обязательно выставит такие требования которые ну никак не хотят работать с требованиями от тех платформ что уже работают.

5 Сотрудники
Невозможно нанять людей уже знающих твою платформу, поэтому надо учить, а нет ни нормальной доки, ни комунити где сотрудник может поискать ответы.
Поэтому надо отвлекать остальных сотрудников, причем первый месяц вообще постоянно.
Любой грамотный программер понимает, что знания по этому домострою (в отличии от известных движков) ему нигде не пригодятся, и поэтому потребует весьма высокой оплаты.
А не грамотные просто не разберутся в коде.

Короче в 99% случаев, свой движок, это дорого, долго и бесперспективно.
0
Может одному и сложно делать, но не забывай что это дешевле компании по бюджету, но дороже по времени, за то прокачка опыта и следующий продукт будет качественее если будут учитывать прошлые ошибки.

Сейчас много фреймворков для графики упрощающие создание движка, там по сути все за тебя написано.
0
отбросить чужой игровой движек, что бы возится чужим графическим движком…
как-то это не кошерно
+1
Все графические фреймворки простые, единственное надо делать под себя, к примеру в штате больше разработчиков знают Lua с C++, следовательно для удешевления разработки будут к движку прикреплять интерпретатор Lua (LuaJIT в частности). Это касается всего процесса разработки игры и параллельно движка.

Тебе не придется изучать на другом движке методы и скриптовый язык, если ты можешь написать свои методы на своем любимом языке.
image
0
Вы не учли один важный плюс — можно вытрясти бОльший бюджет из инвестора и успешно его освоить.
+1
Ох, насколько же движки больная тема. Смотришь на Unreal и не знаешь, что с ним делать. С одной стороны, куча инструментов, сообщество, готовое решение 80% всех возможных задач. С другой стороны, тесная интеграция с Physx, трудности с использованием сторонних библиотек и невозможность встраивания в ПО без переписывания самого движка.
+1
после id tech 4 ничего в опен сорс не отдали, инструментария для моддинга игр не выпустили, кроме как для Rage.
+1
И это очень печально. Когда-то Тим Виллитс рассказывал, как получил работу в id во многом благодаря ориентированности Кармака на открытость и вовлечению, поощрению компанией создания контента со стороны. Уже тогда можно было заметить, что сам Виллитс не очень-то разделяет взгляды бывшего патрона, но сейчас это стало очевидно всем.

Удивительно, конечно, как изменились времена. Десять лет назад id спокойно выпускала Quake 4 SDK с примерами SP- и MP-модов, карт, model и texture reference'ами, а теперь стараются всё максимально огородить, запретить и непущать. Какой и кому от этого прок? Сами же лишают себя кучи годного и при этом бесплатного контента.
0
В сложившихся условиях любой движок — это трата времени. Это только кажется, что мы делаем только то, что надо. На самом деле в процессе прототипирования игры хочется попробовать разные варианты, в случае готового движка — это как раз-два, а в случае своего — это месяцы работы на мусорную корзину. Я серьезно. Я делал игры без движка. И делал свой движок. Это печаль. Статья длинная, а вывод один — если у вас нет кучи денег, чтобы не жалко было потратить их впустую, даже не стоит начинать. Ну а если вы индивидуальный разработчик… Думаю и тут ответ очевиден. Хоть Unity и Unreal — не очень, но выбора особого нет. К тому же кто мешает потратить свою творческую энергию на крутые плагины для Unity?
0
Удваиваю. Есть еще понятие как стоимость владения. Т.е нужно в стоимость вкладывать не только время разработки движка, но и стоимость его доработки, фиксов и т.п на все время существования проектов, основанных на этом движке. Т.е посыл статьи — «пишите отдельный движок под каждый проект, максимально подходящий для этого проекта, причем на максимально удобном языке для всех, кто будет его саппортить», а это означает 100500 движков внутри одной конторы и на каждый нужно содержать команду, которая знает как оно работает внутри. Это просто не работает. По этой причине все больше и больше контор отказывается от своих велосипедов (потому что дорого) и переходит на unreal / unity.

Скажем, в соседнем офисе сидят люди, которые делают движок. Каждый, кто пытался исправить баг в универсальном движке, то есть написать в багтрекер Unity или Epic, знает, что лучше даже не начинать. А если разработчики сидят в соседнем офисе, то вы можете к ним обратиться и решить вопрос за 15 минут.

Опять же — чтобы были разработчики по соседству — их нужно постоянно оплачивать, а фиксы для движка одной игры, выпущенной 3 года назад могут иметь нулевой приоритет перед всеми новыми играми, выпущенными на чем-то другом.
По поводу фиксирования багов в больших движках. Не знаю, как в unreal, но юнитекам отправляю баги регулярно и они их чинят, пусть и с задержкой в 2-6 месяцев. Да, чем дальше (после прихода нового CEO), тем становится хуже первая линия саппорта по регистрации тикетов. Просто начинаешь прямо требовать, чтобы убрали эту обезьяну и передали тикет квалифицированному специалисту — помогает. В форме фидбека есть встроенный фильтр «swear words», приходится довольно долго подбирать синонимы :)
+2
Законспектировал статью:
Разработка своего движка оправдана, если

1. Особые возможности игры тяжело реализуются на существующих движках, но легко пишутся с нуля (пример с Майнкрафтом)

2. Движка нет (сюда включаем случай, когда он недоступен по финансовым причинам)
+1
1) Вероятность минимальна
2) Не в наше время. Бесплатных движков море.
+1
автор же в статье описал — платформа для телевизора )
или для дешевых телефонов (правда, как продавать такие игры — разве что по соглашению с вендором, который хочет оснастить свои черно-белые телефончики новым монохромным хитом)
0
В любом случае, для таких платформ можно взять готовый код, сделав лишь специфические платформенные функции.
0
Главную то причину не указали. Если вы делаете игру в прицелом на 8-9 значную прибыль в долларах, то стоимость лицензирования становится абсурдно велика и намного дешевле нанять армию сеньоров и написать свой.
+3
Когда игры на новом движке появятся, тогда и оценим труды. С нетерпением ждём.
+1
В своем движке я столкнулся с интересной проблемой: UI компоненты делались по мере надобности, а не методом «реализовать все возможные контролы с всеми возможными вариантами использования». В итоге код каждого контрола переписывался много раз, кое-где оброс костылями, а всякие Progress Bar вообще не вошли в библиотеку и каждый раз реализуются по-разному. И, как водится, без юнит тестов.
Уже отлично видно, что это огромная самовыкопанная яма и выбраться из нее можно только если таки сделать шаг назад и таки сделать отдельно библиотеку базовых компонентов и тесты для них. Может даже попробовать имитировать частично UI стек готовых решений, а-ля wxWidgets или QT.

Может кто-то встречал гайдлайны «базовые UI компоненты и какими свойствами они должны обладать»? Или может имеет опыт и желание заняться чем-то таким? :)
0
Я сейчас как раз этим занимаюсь, пока выходит, что достаточно всего одного типа с вложенными дочерними компонентами, с возможностью скролла и переопределяемым поведением при нажатии. Скроллбар в таком случае — просто список с 1 элементом, который перемещается в границах родительского. Кроме скроллбара, таким образом легко получаются контейнеры для элементов, горизонтально и вертикально скроллящиеся одномерные и двумерные списки, кнопки, просто спрайты. По UX и API ориентируюсь на Android, чтобы сделать похожим на другие платформы — нужно просто текстурку поменять.
+1
А чем не устраивают готовые nuklear, ImGUI?
Есть еще основы типа github.com/randrew/layout
Можно очень красивые интерфейсы сделать на этих штуках. А всякие красивости на шейдерах.
wxWidgets можно сразу выкинуть, на маке отрисовка текста через CTLineDraw и тормозит.
QT можно, если размер не важен, но если сами будите пересобирать — можно больше времени потратить.
0
Готовые не устраивают тем, что есть уже свое рабочее решение, на нем написано сколько-то игр и впиливать вместо него что-то совершенно чужое, на другом языке смысла нет.
Но смысл есть выбрать какую-то готовую GUI библиотеку за эталон и привести свое решение к аналогичной архитектуре, вплоть до совпадающих методов. Банально, можно будет и чужие редакторы подключить, и просто на чужом опыте многие подводные камни пройти.
Я о том и говорю, что в случае собственных UI фреймворков, разработчики часто реализуют лишь то, что надо их проектам, а условия иногда меняются и мы получаем игры, где в поле ввода нельзя вставить текст из буфера, списки без быстрого поиска, тексты без поддержки стилей и т.д.
0
Очень интересно послушать сколько своих движков написали программисты этой компании, и сколько проектов они выпустили на них. Судя по статье у вас большой опыт в этом деле.
+2
Как я уже говорил, мы делали браузер, который занимает 2.5 мегабайт памяти, там есть JavaScript-движок, который проходит все тесты.

Вот про это следующую статью, будьте добры.
+1
Ох, прекрасно помню я этот доклад. А еще помню девочек на Вашем стенде, которые на мой ответ «Unity разработчик» ответили «Фу, Юнити, он же такой забагованный, а вот у нас свой движок!.»

Так вот, если у Вас есть ресурсы на свой движок — прекрасно. А для подавляющего большинства, в том числе и себя, я не вижу смысла заниматься этим. X-Ray с 1998 по 2011 GSC так и не довели до ума.
А конференция была отличная, уважение Александру Хруцкому и команде.
0
И правильно!
Зачем в него писать баги, а потом их долго вылавливать??!
-1
Девочек мы все любим не за их мнение о движках… ;-)

Про X-Ray стоит послушать самих создателей X-Ray, которые теперь в 4A. По их же словам, под новые требования, например стриминг, проще написать новый, чем править старый. А судя по последнему Метро, в движках они что-то понимают.
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.