что делает движок в играх
Подумайте дважды, прежде чем использовать игровые движки
Холивар о том, нужно ли использовать для создания игр движки, начался сразу после появления первых игровых движков. Этот пост на reddit не является идеальным примером разумных контраргументов против постоянного использования движков, но я считаю, что непреодолимое желание их применения немного отдаёт фанатизмом.
Давайте рассуждать разумно
Я считаю, что не существует готового ответа на вопрос, стоит ли разработчику применять движок. Мудрый разработчик перед выбором технологии оценивает все возможные варианты.
Уровень навыков
Достаточно ли у вас навыков, чтобы эффективно использовать выбранный вариант? Если у вас нулевой опыт в программировании, то придётся многому научиться, прежде чем вы будете готовы создавать игру из набора разрозненных библиотек.
Если у вас нет ни технических навыков, ни интереса к их изучению, то вариантов и в самом деле нет — придётся работать с движком (или убедить кого-нибудь заняться технической частью за вас; удачи вам в этом!).
Есть промежуточное состояние между полным отсутствием навыков и профессиональным уровнем. В основном он находится в стране скриптовых языков: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D и т.д. Все они для тех, кто желает получить определённый уровень технических знаний, чтобы быстро достичь результатов.
Если вы опытный/профессиональный программист, способный уверенно освоить стороннее ПО, то можете воспользоваться этим навыком и решить, насколько минималистичным/максималистичным будет ваш подход (будет ли это исключительно минимальный SDL или же полностью оборудованный Unreal Engine).
Цели разработки
Каковы ваши цели в этом проекте? Технологии должны по максимуму упрощать их достижение:
Интерес
Если вы больше работаете (или планируете работать) с разработчиками, чем в одиночку, то вам нужно оценить, насколько другие люди заинтересованы в технологии. Если вы работаете со старым движком/фреймворком, который все ненавидят, то вам сложно будет найти для своего проекта мотивированных разработчиков.
Подумайте также над тем, как с технологией будут взаимодействовать художники и дизайнеры. Хотите ли вы создавать инструменты, чтобы догнать по функциональности Unreal? Они неизбежно будут сравнивать возможности движка и собственные. Я слышал, что даже у AAA-студий есть проблема с художниками, требующими наличия функций Unreal, которые пока не реализованы в текущем форке Unreal студии.
Если вы работаете в одиночку, то нужно поддерживать в себе сильную увлечённость проектами. Если вы ненавидите технологию, с которой работаете, то скорее всего забросите работу. Если вы бросите, то все ваши усилия пойдут прахом (за исключением бесценного опыта).
Что они дают вам на самом деле?
У Джонатана Блоу есть удивительно мудрое видео о том, что же на самом деле дают игровые движки. Они решают за вас «простые» проблемы, но потом встают на пути, когда пытаетесь решить сложную проблему, из которых и состоят увлекательные игры.
Да, конечно, вы получаете великолепный редактор, инструменты профессионального уровня и движок, который подошёл тысячам разработчиков, но вы расплачиваетесь за него множеством других аспектов:
Что нужно для вашего проекта?
Технологиями должен управлять ваш проект, если только это не технологическое демо. Если вы создаёте игру, то нужно работать только с теми технологиями, которые оказывают влияние на игру — только с самым необходимым для передачи вашего видения. Если движок предоставляет вам самый быстрый путь для выпуска вашей игры, то это хороший выбор. Но так будет не всегда!
Существуют успешные игры, которым бы послужил плохую службу любой из доступных движков:
Будущее вашей (и нашей) индустрии
При использовании любой технологии стоит задуматься о замыкании. У Джоэла Сполски есть серия статей о бизнес-стратегии разработки ПО, в которой он размышляет о замыкании на продукте. Если вкратце, то его мысль заключается в том, что компании заинтересованы удерживать вас, чтобы вы использовали их продукт, потому что если вы не используете продукт, то они не зарабатывают денег. Мастерами в захвате целых отраслей стали Apple, Microsoft, Adobe и Autodesk, они создают ощущение, что кроме их ПО нет никаких других альтернатив.
Замыкание влияет даже на хобби/соло-разработчиков. У меня есть друг, который постоянно борется с Unity (рушащие совместимость обновления, система прототипирования, навмеш, плохая поддержка 2D. ). Он хочет уйти от Unity, но сильно замкнут на этот движок, потому что большая часть его кода (и данных) полагается на Unity API.
Почему движки покупают?
Unreal и Unity управляются требованиями рынка. Их клиенты AAA-уровня при помощи многомиллионых контрактов определяют курс дальнейшего развития движков. Если вы работаете над игрой, структура которой не совпадает с целями этих AAA-игроков, то разработчики движков не будут так же преданно служить вам. Например, двухмерным, процедурным, экспериментальным, воксельным играм и играм с большими объёмами данных почти всегда приходится искать что-то своё.
Чем ярче кажутся функции, тем больше руководство компаний (которое чаще всего не является технарями) стремится использовать движки. Такие возможности, как Blueprints движка Unreal, очень нравятся художникам и дизайнерам, но создают множество проблем программистам. (Это свойственно любым скриптовым языкам; если позволить не изучавшим программирование людям программировать, то результат будет плохим, аналогично тому, как плоха графика, рисуемая программистами).
Действительно ли новые функции упрощают завершение создания вашей игры? На самом ли деле они повышают ценность конечного продукта?
Боритесь с централизацией
Каждый раз, когда одна из студий переходит с собственного движка на Unreal или Unity, компании Epic и Unity набирают в игровой индустрии ещё бОльшую мощь. Поначалу такая централизация может казаться выгодной (у них ведь над движком работают 500 инженеров, отлично!), но через пару десятилетий это станет реальной проблемой. На ум приходит Google: эта компания захватила обширную часть функций, которые люди используют в Интернете, и это стоило им потери большой доли приватности.
Даже на уровне хобби отказ от исследований в пользу Unreal или Unity вредит будущим поколениям движков. Это может повредить даже самому Unreal: если все будут использовать Unreal, то Epic не сможет больше нанять никого для создания нового поколения движка, потому что никто не будет знать, как пишутся игровые движки!
Будущее может быть за открытыми исходниками
Если мы, как индустрия, хотим расти, создавая всё более качественные продукты, то нам нужно больше, а не меньше делиться технологиями.
Я думаю, что индустрия движется в этом направлении, хоть и чрезвычайно медленно. В особенности это свойственно игровым студиям AAA-уровня, которые всё ещё скрывают код своих движков, чтобы получить (воображаемое?) конкурентное преимущество.
Качество ПО
Джонатан Блоу и Кейси Муратори — ярые критики современных практик написания ПО. Их точка зрения заключается в том, что мы создаём надстройки над слоями абстракций так долго, что получаются огромные хрупкие слои ненужного хлама, и это не позволяет нам писать более качественные продукты.
Возможно их философия ближе к идеализму, чем к прагматизму (что обычно приводит к откладыванию сроков выпуска игр), но если она близка вам, то не стоит её игнорировать.
Важны ли вам скорость, качество и элегантность ваших технологий? Многих людей вполне устраивает отрицательный ответ, но некоторые хотят создавать программы более «чистым» способом.
Каковы альтернативы?
Вместо использования движка вы просто пишете игру.
Новички часто думают, что для создания игры им нужен движок. С большой долей вероятности им стоит отбросить такую точку зрения. Начинающие будут впустую тратить время на реализацию бесполезных функций движка, вместо того, чтобы дать игре решить самой, что ей абсолютно необходимо. Только игра должна управлять тем, что нужно от движка (разумеется, в качестве контрпримера можно привести Unity, как образец подхода «движок в первую очередь»; в поддержку такой концепции у Unreal Engine 4 есть Paragon, Fortnite и Unreal Tournament, не говоря уже о десятках лет опыта выпуска бесконечного количества игр в предыдущих версиях движков).
Использование библиотек
Начинать «с нуля» имеет смысл только если вы имеете навык и планируете создать инновацию в конкретном компоненте (или имеете ограничения). Во всех остальных случаях существует множество библиотек для интеграции. Это особенно хорошо, когда вы знаете, что, например, стандартная система физики полностью подходит для требований вашего проекта (особо важно это потому, что для реализации собственной физики нужен большой объём знаний в этой области).
Вот несколько библиотек, которые могут заполнить пробел между работой «с нуля» и использованием полностью готового движка:
Большой плюс в использовании библиотек заключается в том, что он даёт вам наибольшую среди всех вариантов гибкость. Если вы пишете весь код в одном движке, то для его портирования придётся приложить огромные усилия. Если вы пишете игру как коллекцию библиотек, то обладаете большой мобильностью и можете заменять целые подсистемы. Если библиотека не отвечает вашим требованиям, то можно попробовать другую или даже написать собственную замену.
Кроме того, и Unreal, и Unity поддерживают импорт динамически подключаемых библиотек. Это значит, что можно начать работать с библиотеками, а затем перейти на Unreal без необходимости переписывать весь базовый код геймплея, потому что он находится в библиотеке. Чтобы код оказался достаточно гибким для таких огромных изменений, требуется серьёзная продуманность, но я думаю, что для среднего или долговременного проекта оно того стоит.
В заключение
Я представил несколько точек зрения, под которыми можно рассматривать технологии при их выборе. Потратьте пару недель на подробное исследование, и это может сэкономить вам в дальнейшем несколько месяцев работы по портированию или даже годы неудобств.
В конце концов, ваша основная задача — закончить проект. Вам следует приложить максимальные усилия к поиску кратчайшего пути к решению этой задачи. Он может оказаться для вас довольно неожиданным!
Что такое игровой движок?
Содержание
Содержание
Если вы регулярно читаете статьи о компьютерных играх, то обязательно сталкивались со словами «игровой движок». И вы знаете, что он может быть быстрым, тормозным, продуманным, неудачным, привычным и так далее. А что это за «движок», который скрывается под красивой оберткой текстур и скриптов компьютерной игры? Это же не двигатель автомобиля. Тогда что? Программный код? Комплекс приложений для программистов и игроков? Разберемся немного подробнее.
Понятие «игрового движка»
Термин «игровой движок» является прямой копией английского «Game Engine». Фактически это объединенный в единое целое комплекс прикладных программ, с помощью которых обеспечивается графическая визуализация, звуковое сопровождение, перемещение внутриигровых персонажей, их действия в соответствии со скриптами, а также игра в сети, встроенные графические сцены, соблюдение физических эффектов и законов и многое другое.
Есть ли польза от использования готового игрового движка? Несомненно. Разработчик получает готовый качественный инструмент с большим количеством библиотек. В результате ему не надо писать большую часть базового программного кода и можно сосредоточиться на реализации своих идей, графики, игровой механики и сюжета, не тратя время на написание кода с нуля.
В результате ряд компаний занялся разработкой именно игровых движков, а разработчики игр стали покупать на них лицензии, как это получилось с Unreal Engine или id Tech 3. Стоимость лицензии может составлять от нескольких тысяч до миллионов долларов. Но при этом надо отметить, что для некоммерческого использования многие игровые движки, например, популярные Unity и Unreal Engine 4 доступны бесплатно. Остановимся на этих движках немного подробнее.
Особенности популярных игровых движков Unity и Unreal Engine 4
Движки Unity и Unreal Engine 4 являются самыми популярными в среде разработчиков из-за их удобства, детальной проработки и большого количества дополнительных библиотек, что позволяет настраивать и реализовывать практически любые идеи, приходящие в голову дизайнерам и игроделам.
Unreal Engine 4
Этот движок смело можно назвать легендой. Его разработка началась в 1998 году и с тех пор он постоянно модернизируется, дополняется и совершенствуется. Современный Unreal Engine 4 — это движок, на котором пишут игры для любых платформ и операционных систем, начиная от ОС Windows и заканчивая всеми современными консолями — Playstation 4, Xbox One, а также мобильными платформами, в том числе и iOS.
Unity
Unity — одна из популярных платформ для разработчиков игровых приложений. Можно услышать, что этот движок называют самым молодым. Но тут надо отметить, что он появился в 2005 году и с тех пор успешно развивается.
Большой плюс Unity — простота его освоения. Минус — графика в играх, созданных на основе этого движка. Она выглядит проще и не настолько реалистична, как у Unreal Engine. Тем не менее, около половины всех мобильных игр, по заверениям разработчиков, написаны именно на этом движке.
Как создаются игры с помощью игровых движков
Для разработчика игровых приложений движки представляют собой программную среду, в которой он ведет разработку проекта. Ее использование позволяет не заниматься такими рутинными вещами, как описание работы с графикой, звуком и физической моделью. Но это не значит, что программировать не придется ничего. Разработчику все равно потребуется писать скрипты для внутриигровых действий. На Unity, например, потребуется работа с C#, да и на Unreal Engine знание языков программирования не помешает.
Необходимо отметить, что важной особенностью Unreal Engine является технология Blueprints, позволяющая описывать игровую логику и события с помощью графических схем, без использования языков программирования. Это, конечно, приведет к тому, что созданная игра будет занимать больше места и требовать более быстрой платформы, но зато процесс разработки значительно упрощается.
Использование игровых движков позволяет избавиться от написания кода для очень многих рутинных моментов, так как, кроме самих движков, для них существует огромное количество библиотек и расширений. С их помощью первые простейшие игры на Unity можно создать уже через несколько часов изучения платформы. Специально для начинающих в Unity существует масса проектов вроде Creator Kit и Microgame, предлагающих большое количество исходных материалов для написания простых приложений в 2D и 3D. На Unreal Engine также есть множество библиотек и уроков, позволяющих быстро освоить программную среду и начать писать простые игровые приложения.
Все игровые движки позволяют добавлять и рисовать уровни, их элементы и персонажей, прописывать события, которые происходят в зависимости от действий главного героя. При этом разработчик не тратит время на написание сотен строчек кода, а занимается только реализацией своих непосредственных идей.
Так что же такое игровой движок для игрока и разработчика?
Получается, что игровой движок с точки зрения разработчика является программной платформой, на которой ведется разработка приложения. Кстати, это совсем не обязательно игра. Unity, например, активно используют в работе над приложениями с дополненной реальностью. А это уже не только игры, но и путеводители, справочники, энциклопедии и многое другое.
А с точки зрения игрока или пользователя написанного приложения, игровой движок — это основа игры, на которую разработчиком наложен сюжет, уровни, графика и музыка. Разница между этими двумя определениями небольшая, но она все-таки есть.
«Начинайте с идеи игры, а не движка». Разработчик игровых движков — о том, что это и как устроено
Василий разрабатывает игровые движки с 16 лет, с того момента, как дома появился первый ZX Spectrum, — и не представляет, чем еще мог бы заниматься в жизни. Айтишник выпускал мобильные и веб-игры, создавая их в одиночку, а также написал несколько движков (вот один из них). В рамках спецпроекта Onliner и BGaming мы узнали у разработчика этой компании, как устроен игровой движок и что он собой представляет.
Как выглядит движок
— Простым языком: движок игры — что это такое?
— Изначально у тебя есть язык программирования, в котором ты можешь сделать все что угодно. Но примерно ко второй игре становится ясно, что многие вещи повторяются из игры в игру, и чтобы не писать их повторно, ты объединяешь их в некий набор библиотек и инструментов, который и принято называть движком. Хороший движок избавляет от необходимости делать то, что уже сделано раньше, но в то же время оставляет тебе свободу действий. Продвинутый и удобный движок — это не просто набор библиотек, понятный только программистам. Это инструмент, в котором можно увидеть и отредактировать игру. То есть это, если сильно утрировать, как Photoshop или Word, только для игр. Такого пути при разработке движка я всегда придерживался.
Обычно в движке есть окно, в котором ты видишь то же, что и игрок, когда запускает твою игру. С тем лишь отличием, что ты можешь выделить любой объект и изменить его свойства, переставить в другое место. Есть окно, в котором показана иерархия игровых объектов в виде дерева или списка. По большому счету эти два окна позволяют тебе собрать игру как из кирпичей.
Иногда эти кирпичи, то есть объекты игрового мира, нужно настроить, придать им свою логику и свойства. Выглядит это так: создаешь свой новый тип игрового объекта, который наследует свойства одного из стандартных объектов, и дописываешь ему свою логику — то, как объект ведет себя в игре при взаимодействии с другими объектами. Нажимаешь кнопку запуска — и смотришь результат.
— По такому принципу можно любую игру сделать?
— Визуально вся игра сводится к тому, что каждый объект перед каждым кадром обновляет свою позицию. У него есть координаты — X и Y. Если к X прибавить 1, объект сдвинется на один пиксель. А если на каждом кадре прибавлять к X по единице, то объект будет непрерывно двигаться вправо. Вот и все: когда в 16 лет я узнал, как вывести произвольную букву в произвольную точку экрана, мне хватило, чтобы уйти в это с головой. Я составлял человечков из букв, которые бегали по лестницам, собирали монеты и так далее.
Но есть более продвинутый способ двигать объекты по экрану — это когда мы работаем не с X и Y объекта напрямую, а с его скоростями по оси X и Y. Назовем их speedX и speedY, значения которых попросту прибавляются к X и Y каждый кадр. Теперь, однажды установив speedY значение, равное 1, мы заставим объект двигаться вниз со скоростью 1 пиксель за кадр. А если мы начнем каждый кадр увеличивать speedY на 1, то объект будет двигаться вниз с ускорением — получится действие гравитации. Нам останется проверить наличие препятствия под объектом и установить speedY в 0, чтобы объект не проваливался сквозь пол. А можно при касании пола speedY умножить на минус один (изменить скорость на противоположную), и тогда объект «отскочит» и полетит вверх.
Другая, обычная для игры задача — определить момент, когда два объекта друг друга коснулись. В упрощенном виде касание — это когда расстояние между центрами двух объектов стало меньше, чем размер этих объектов. Пересеклись — соответственно, есть касание: наносим урон, добавляем на экран взрывы. Во многих движках это реализовано, и тебе остается написать, что именно произойдет при столкновении.
Универсальность — не всегда хорошо
— Почему нет движков, которые подошли бы под любой игровой жанр?
— Идей очень много, и они всегда выходят за пределы того, на что рассчитывал разработчик движка. Вообще, универсальный движок сводится к простоте: чем меньше функционала, тем он универсальнее. А когда пытаешься все охватить, то универсальность, наоборот, страдает.
— Бывает так, что движок заточен под определенный жанр? Например, для стратегии подойдет, а для гонок — вообще нет.
— Одни заточены, другие нет. Это зависит от количества реализованного в них функционала. Например, есть движок для текстовых адвенчур. Понятно, что там можешь сделать только текстовую адвенчуру. Но вообще, возможности движка ограничены только фантазией разработчика, который его использует: если горишь этим и хочешь что-то сделать, то даже в простейшем движке реализуешь интересные вещи.
В целом при разработке самое главное — не ставить глобальные задачи, пытаясь все охватить. И не пытаться в новой для тебя задаче с ходу сделать что-то фундаментальное и долгоживущее. Нужно подходить экспериментально: двинулся куда-то, понял, что есть проблема, — попробуй другой путь. Если видишь, что идея рабочая — можешь проработать ее детальнее. Свой игровой редактор я создал не с первой попытки. Было множество версий на разных языках, были и тупиковые версии, которые я бросал через две недели после начала разработки, так как понимал, что подход нежизнеспособный.
Кстати, важный момент в любой разработке — скорость итерации, то есть насколько быстро ты увидишь внесенные тобой изменения в действии. Бывают проекты, в которых на компиляцию и запуск игры уходит минута и больше, а бывают такие, где хватает 1—2 секунд. И простая математика: ты сразу становишься в 15—30 раз эффективнее. Даже не в том смысле, что сделаешь в 30 раз больше работы, а в том, что получишь в 30 раз меньше стресса и при этом будешь полон сил двигаться дальше.
— От чего зависит популярность движка? Например, CryEngine, несмотря на технологичность, почти нигде не использовался, а Unreal Engine много где встречается.
— Движков тысячи, есть удобные и не очень. У человека есть какое свойство: когда ты смотришь на что-то новое с большим количеством кнопок — оно тебе всегда не нравится. Допустим, работаешь год в 3ds Max, потом переходишь на Blender — кажется, что это полная муть и его инопланетяне придумали. Только дня через три начинаешь понимать, что к чему. То есть привыкание, инертность играют большую роль. Допустим, появился новый движок — он может быть объективно удобным и хорошим. Но кто захочет уйти от чего-то привычного и понятного? А когда речь идет о крупной компании, все в разы сложнее, тем более если на кону большие деньги.
— Почему многие студии делают собственные движки? Не проще ли лицензировать существующий?
— Я лицензированием движков не занимался, но по себе могу сказать, что свое всегда ближе, и ты меньше тратишь времени на доработку и исправление чужих «косяков». Цепляешься за какой-то недочет в стороннем движке — и либо тебе приходится от чего-то отказываться, либо тратить большое количество времени на поиск обходного пути.
Года три назад при переходе с Flash на HTML я около месяца просидел на Unity в качестве эксперимента. На мой вкус, там слишком много рутинных вещей, игровые объекты избыточно раздроблены на подкомпоненты, и 90% твоего кода занимают связи между этими подкомпонентами. Другие вещи, которые я считаю важными, реализованы не идеальным образом. Возможно, тут сыграла роль та самая человеческая инертность.
— Ты разрабатываешь только движок или игрой тоже занимаешься?
— Разрабатывать движок, отгородившись от игры, вредно. Если сам с ним не работаешь как пользователь, то понятия не имеешь, куда двигаться дальше. Только непосредственно при разработке игровой сцены ты заметишь, что чего-то не хватает или какая-то процедура занимает больше сил, чем могла бы. Как только я натыкаюсь на рутину или баг — сразу добавляю какую-то кнопку, галочку, пару дней проверяю, как оно работает в «боевых условиях», и если все в порядке, включаю ее для всех.
Если делать движок отдельно от игры, то ты не сможешь до конца понять, что именно нужно разработчику, и то, что ты сделаешь, не будет таким удобным и полезным, каким могло бы быть.
Принципы оптимизации
— Как выглядит оптимизация под разные платформы, железо?
— Устройств много, и в первую очередь нужно думать о самых слабых девайсах. Наиболее простой способ оптимизации выглядит так. Допустим, у тебя есть набор анимаций, частиц. Их можно сделать в десять раз меньше по количеству. На маленьком экране разницу даже не заметишь, а нагрузка на железо серьезно уменьшится.
Однако больше всего производительность страдает от отрисованной на экране площади за один кадр. Когда картинка состоит из нескольких слоев, каждый слой в ней отъедает значительную часть ресурсов, даже если она неподвижная. Неподвижные объекты из разных слоев нужно склеивать в один везде, где это возможно, и не отправлять на отрисовку то, что находится за пределами экрана. Например, изображение для фона в играх часто имеет размер намного больше, чем сам игровой экран, видимый пользователю. Если такое изображение отрисовывать как есть, то области за пределами экрана будут нагружать видеокарту. Значит, нужно вычислить область в пределах экрана и отрисовать только ее. В нашем движке для этого есть специальный объект, который обрезает у себя «лишние» части.
Даже если у тебя игра уже работает максимально быстро и дополнительная оптимизация не дает видимого глазу эффекта, есть батарея телефона, которая будет греться и быстро садиться, если не подойти к вопросу оптимизации с душой или хотя бы с серьезными намерениями.
— Разработчик игры должен быть технарем?
— Человек, отвечающий за программирование, — да. Для художника это не обязательно, но когда он имеет опыт разработки игр собственными руками — это очень сильно помогает и экономит время. Он может заранее организовать слои максимально близко к тому виду, в каком они будут организованы в игре. Не потратит время на то, что будет в любом случае вырезано и реализовано программно.
Даже в отрыве от арта и кода игра — это сложная инженерная система, в которой пересекается множество идей и механик. Если ты не видишь все эти пересечения наперед, всплывает множество неожиданных переделок, которые дорого обходятся.
«Самое сложное — не начать разработку, а закончить ее»
— По каким признакам можно понять, хороший в игре движок или нет?
— Если движок хороший, то его присутствие в игре не заметно. Бывает, вижу какую-нибудь известную игру, а спустя годы узнаю, что ее сделали в GameMaker.
В 3D-играх возможны некоторые особенности в освещении и цветообработке. Но в случае с 2D все обычно сводится к отрисовке картинки такой, какая она есть, и движок не оставляет своих признаков. У меня была игра Iron Impact: она сделана в 2D с динамическим освещением, то есть каждый спрайт был не плоским, а имел карту высот и нормалей. И если бы на этом моем движке мне показали другую игру, я бы его узнал.
— Что посоветуешь разработчикам игровых движков?
— Начинайте с игры и ее идеи, а не движка. Нельзя сделать движок, а потом думать, какую игру на нем разработать. Только в процессе создания игры будет понятно, в какую сторону двигаться по расширению движка, как его адаптировать и оптимизировать.
Главный совет — не делайте чего-то глобального. Даже если уверены в своих силах, лучше сделать что-то простое, тогда будет шанс закончить дело и выпустить игру. Самое сложное — не начать разработку, а закончить ее. Ведь как все идет: за второй день разработки ты удвоишь объем сделанной работы, и это очень много. А день разработки после трех месяцев работы — это лишь один процент от уже проделанного. Чувство прогресса замедляется, и радость от разработки улетучивается.
BGaming — быстрорастущий игровой провайдер с белорусскими корнями, предлагающий качественные продукты для онлайн-казино по всему миру.
Игрок и его выбор — главная ценность компании, поэтому мы постоянно изучаем и анализируем потребности и предпочтения аудитории, чтобы создавать яркие и запоминающиеся продукты. Студия разрабатывает онлайн-игры на стыке gambling и gaming, в которых идеально сбалансированы визуальные эффекты и математика. Это возможно благодаря команде экспертов с безграничной энергией и более чем 20-летним опытом в индустрии.
Спецпроект подготовлен при поддержке ООО «Меркелеон девелопмент», УНП 193084780.
Читайте также:
Наш канал в Telegram. Присоединяйтесь!
Есть о чем рассказать? Пишите в наш телеграм-бот. Это анонимно и быстро