Создание игрового движка. Хождение по граблям и кругам при создании игры с нуля
Это пятая статья из цикла материалов для начинающих разработчиков игр: Игровой движок - написать самому или взять готовый?
Одна из самых распространённых ошибок начинающих разработчиков - это желание во что бы то ни стало написать свой собственный игровой движок и уже на нём сделать игру. Не редкость, когда оба этих дела пытаются проводить параллельно, в итоге, естественно, успешно проваливая оба.
Почему не стоит писать свой игровой движок
В первую очередь необходимо ответить себе на один простой вопрос - что именно вы хотите сделать, игру или движок ? Если движок, то забудьте про игру и занимайтесь только им. Если игру - возьмите готовый движок или конструктор и делайте игру, не отвлекаясь на разработку её программной части.Создание полноценного игрового движка требует специальных знаний, понимания того, как работают игры, огромного количества свободного времени и желания писать исходный код. И уж поверьте - это отнюдь не весёлое занятие, как это может показаться. Даже в бесплатные готовые решения, доступные для использования, вложены тысячи человеко-часов программирования, не говоря уж о коммерческих движках, в которые помимо времени ещё были вложены и серьёзные финансы. Изобретать велосипед, когда вокруг каждый второй ездит на автомобиле - занятие неблагодарное и совершенно излишнее.
Помимо бесплатных систем разработки игр, многие коммерческие игровые движки, полностью готовые к немедленному началу использования в игровых проектах, предлагают сразу несколько очень привлекательных схем лицензирования : полностью бесплатную (Unity 3D в бывшей Indie-редакции), смешанную схему с выплатой Royalties (Unreal Development Kit ) - 99 $ взнос за лицензию и выплаты 25 % прибыли после первых заработанных 5000 $, либо же доступную стоимость полновесной коммерческой лицензии (Unity Pro за 1500 $).
Кроме того, никто не может запретить использовать бесплатную редакцию любого движка до определённой стадии готовности игры, чтобы потом с ощутимым и главное - наглядным результатом своих трудов начать поиски стороннего финансирования для перевода проекта на коммерческую лицензию.
Для 95 % игровых проектов любого жанра и направленности возможно найти адекватное их потребностям готовое решение. Времена, когда игровые движки были диковинкой для отечественного рынка разработки игр и стоили больших денег, прошли - а вместе с ними закончились аргументы в пользу написания собственного игрового движка.
Более того, желание непременно написать всё самостоятельно вкупе с иллюзией того, что такое решение будет лучшим продуктом, чем уже существующие аналоги, может сыграть очень злую шутку с начинающими разработчиками, когда и так весьма ограниченные ресурсы вкладываются в совершенно не нужную задачу (личный опыт), в итоге приводя к преждевременной смерти проекта.
Подводим итог : написанием собственного игрового движка могут заниматься те, кто чётко представляет, что именно и зачем ему это нужно, видит адекватные преимущества такого подхода и способен за вменяемые сроки претворить свой план в жизнь. Всем остальным следует поискать готовое решение, благо оных в последнее время появилось достаточно - взять хотя бы те же Unity 3D и UDK.
Эта статья является первой в целом цикле материалов для тех, кто хочет стать создателем игр. Если вы молоды, амбициозны и полны идей, а руки чешутся сделать "убийцу GTA" или "MMORPG типа WoW, но круче", то вы нашли то, что искали - руководство новичка по созданию игр . Моя цель - дать читателю общее представление о том, как же всё-таки выглядит процесс создания игр и развеять те иллюзии, которые могли сложиться на этот счёт, чтобы в последствии вы смогли избежать ошибок, совершаемых многими. Как и в любом деле, половина успеха - это правильная подготовка, поэтому чем полнее вы с самого начала будете представлять себе всю картину - тем большего успеха сможете добиться.
На данный момент цикл статей включает в себя следующие материалы, который со временем будет дополняться:
1. Создание игр для начинающих
Начинающий Разработчик Игр - В Простонародии "Чайник"
Итак, после очередного вечера за вы подумали - а чем я хуже?.. Подумали и решили, что вот он, шанс на всеобщее признание - пора создавать игры своей мечты! Кажется, что в этом нет ничего сложного, но вы заблуждаетесь... серьёзно заблуждаетесь. С этого, пожалуй, мы и начнём.На самом деле, даже если не касаться вопроса сложности разработки любой игры (а мы его обязательно коснёмся чуть ниже), то все плюсы и положительные стороны "игроделания" с лихвой уравновешиваются негативными сторонами, с которыми так или иначе сталкиваются все разработчики, особенно начинающие.
Так уж сложилось, что самый первый этап является и самым привлекательным - это момент рождения идеи, её поверхностной проработки, мгновения творчества. В такие моменты можно часами нарезать круги по комнате, представляя, каким классным всё должно получиться и какого признания можно добиться, если воплотить новую идею в жизнь. Восхищение своим творческим гением может переполнить сосуд, и в таком случае оно потребует выхода - чаще всего незрелая идея выплёскивается на одном из тематических форумов, в теме с заголовком вида "Собираю команду для разработки игры, нужны все". Где успешно высмеивается более опытными товарищами по цеху, и, стоит признать, порой весьма справедливо.
Создание Игр - Развлечение?
К сожалению, это далеко не так. Даже если не касаться профессиональной работы в индустрии производства игр, то и любительский проект - это не развлечение в прямом смысле этого слова. Конечно, процесс работы над воплощением своих идей приносит определённое удовлетворение и удобен как средство самореализации, но... Как уже было сказано, самым приятным является момент рождения идеи и её проработка, но затем неизбежно наступают "трудовые будни"
с их повторяющимися действиями, нудной кропотливой работой и тем, чем заниматься ну совсем не хочется (а так как создание игр - достаточно разноплановая работа, то такие вещи наверняка будут, особенно если вы работаете в одиночку). В итоге в таком болоте тонет мотивация, а вместе с ней - и желание заниматься своим проектом.Будьте готовы к тому, что даже относительно небольшой игровой проект может отнять у вас не один месяц времени на его завершение. Подумайте - достаточно ли у вас мотивации, чтобы продолжать работать над воплощением своей идеи даже после того, как начальный азарт угаснет?.. Наверное, не ошибусь, если скажу, что доля проектов, не доведённых до конца и брошенных на разных этапах разработки, стремится к 99%... Вы ведь не хотите пополнить это число своей идеей, правда?
Типовой Портрет Начинающего Разработчика
Да простят меня те, кто узнает себя в этом описании - призываю не обижаться, а продолжить чтение. Сейчас мы попробуем нарисовать типовой портрет начинающего разработчика игр, чтобы лучше понять, с чем нам предстоит иметь дело. Итак, начинающий "игродел" - это чаще всего учащийся школы в возрасте 12-18 лет, внезапно загоревшийся идеей создания игр. Идея приходит спонтанно либо после какого-то толчка к вдохновению, вроде нового фильма или популярной игры. Как правило, сам он ничего не умеет в силу возраста, недостатка опыта и иных причин, поэтому хочет выступать в качестве "руководителя " и/или "сценариста ", "автора идей ". Соответственно, так как самостоятельно с такими навыками сделать ничего хотя бы отдалённое напоминающего игру, нельзя, то нужна "команда", которую данный генератор гениальных идей пытается собрать на одном из тематических форумов.При ближайшем рассмотрении идея оказывается клоном чего-то популярного и известного, "но лучше". Так как представления о том, чего же, собственно, хочется, и как организовать продуктивную работу, нет, то в команду приглашаются все либо почти все. В итоге такая "команда" складывается из случайных людей, которые в течение недели-двух создают видимость бурного обсуждения "проЭкта", иногда даже что-то пытаются сделать (вроде 3D-модели из набора примитивов), но примерно через это же время былой энтузиазм сходит на "нет", у членов команды появляются неотложные дела/сессия/уроки/бабушка заболела и вся затея благополучно рассыпается как карточный домик. Знакомая картина?..
Разработка Игр - Профессия или Хобби?
Разработка игр для многих является просто хобби (т.е. увлечением), но некоторые люди связывают с индустрией разработки игр свою карьеру и становятся профессиональными разработчиками. Естественно, что вопрос о том, есть ли разница между любителем и профессионалом, не стоит - она есть и весьма существенна. В то же время некоторые любители имеют куда более высокий уровень, чем отдельные "профессионалы", так что сам факт принадлежности к одной из этих двух групп не является определяющим. Тем не менее, некоторый отпечаток он всё же накладывает.Любитель , как правило, имеет иной источник дохода (в случае, если он уже достаточно взрослый человек), поэтому над ним не висит вопрос коммерческой успешности своего проекта. Аналогично для тех, кто учится в школе/ПТУ/ВУЗе - они могут работать над игрой в своё удовольствие, бросить в любой момент, реализовывать любые идеи и вообще испытывают гораздо больше свободы в своих действиях. С другой стороны, они не могут посвятить изучению инструментов и получению новых навыков достаточно времени, поэтому в постоянно меняющемся мире игр всегда серьёзно отстают технологически и качественно.
Профессионал - он и в Африке профессионал. Он делает свою работу и получает за это деньги. Как правило, работать приходится над чужими идеями, и благо, если они кажутся интересными - но иногда всё равно приходится работать над тем, что тебе не нравится. Так как уровень мастерства является определяющим в профессиональной деятельности, то такому человеку приходится идти в ногу со временем - осваивать новые технологии, программы, приёмы, техники и т.д. Он может позволить себе посещать семинары, курсы повышения квалификации, тратить достаточно времени на книги и видеоуроки - словом, пребывать в постоянной гонке за право считаться специалистом своего дела.
Есть и третий вариант - это независимые разработчики (инди) . На мой взгляд, это самый привлекательный путь для тех, кто обладает достаточным талантом и способностями для того, чтобы заниматься разработкой игр "от и до" самостоятельно либо в небольшом коллективе. Налицо плюсы такого подхода - можно работать над воплощением своих идей и в то же время зарабатывать на этом.
Вобрав в себя плюсы профессионального и хобби-подхода, инди-разработка не избавлена от ложек дёгтя в бочке мёда.
- Во-первых, чтобы быть успешным инди-разработчиком, необходимо всё же регулярно заниматься повышением своих способностей и улучшением навыков, посвящая достаточно времени самообразованию - двух выходных дней в неделю, которые можно посвятить себя делу, скорее всего будет недостаточно.
- Во-вторых, вам придётся самостоятельно заниматься многими специфическими вещами, которые в крупной компании выполняли бы отдельные специалисты, а в любительском проекте можно было бы обойтись и без них. В-третьих, так как мастера-на-все-руки, которые одинаково хорошо могут справиться со всеми аспектами разработки игры (графика-дизайн-музыка-программная часть) во всём мире, наверное, считанное количество, то часть работы нужно будет передавать на исполнение фрилансерам либо искать единомышленников, готовых работать вместе с вами.
- Ну и в-третьих - делая ставку на свой проект, вы вкладываете в него время, деньги (хотя первоначально можно обойтись без значительных вложений) и ожидаете получить какую-то отдачу. И тут всё зависит от вас - на что наработаете, то и заработаете. Проект может быть как удачным, так и неудачным.
Цена Идеи для Игры
Часто приходится сталкиваться с ситуацией, когда на форуме о разработке игр появляется тема, в которой автор представляет свой проект, но избегает всяких деталей, ограничиваясь лишь самой общей информацией. В ответ на просьбы дать подробности автор утверждает, что не сделает этого, т.к. идеи уникальны и могут быть украдены. Бесспорно, некоторые идеи могут быть очень удачными, и их вполне разумно держать в секрете, но...Не падайте в обморок, но идея сама по себе не имеет никакой цены. Ноль. Даже самая гениальная идея ничего не стоит. Идей великое множество, и некоторые из них весьма и весьма удачны. Тем не менее, идея не обладает практическим значением до тех пор, пока она не реализована в виде чего-то менее абстрактного.
Задумайтесь: когда в последний раз вы видели действительно оригинальную идею? "Аватар"? Нет - если разложить идею до уровня концепции, то всё просто: земляне из будущего добывают ресурсы на чужой планете, игнорируя интересы местного населения. Один из землян проникается сочувствием к аборигенам, становится частью их народа и возглавляет борьбу против захватчиков. Просто, не правда ли? Crysis? Классический шутер про элитного спецназовца с супер-способностями, которые ему даёт костюм, и пришельцами из космоса. World of Warcraft? Игра, действие которой происходит в богатой на события и предысторию вселенной, с высокой ролью сюжетной составляющей, разносторонними сложными взаимодействиями игроков и мощной экономической системой.
Во всех этих идеях самое ценное то, КАК они были реализованы. Даже самая простая идея, будучи воплощённой в жизнь на высоком, качественном уровне, с глубокой проработкой, может "выстрелить" и стать хитовой игрой/фильмом.
Таким образом мы приходим к выводу, что для начинающего разработчика вопрос "как" гораздо важнее вопроса "что". Очевидно, что идея создания MMORPG нового поколения (так называемый next-gen) абсолютно бесполезна для большинства разработчиков, так как в силу объективных причин они просто не могут реализовать её в каком бы то ни было виде.
Английский Язык для Разработчика Игр
Отдельного упоминания заслуживает вопрос изучения английского языка. Очевиден тот факт, что игровая индустрия в подавляющем большинстве своём использует английский язык как язык международного общения. Конечно, есть национальные рынки и их разработчики, которые говорят на своём языке (например, Россия и Япония), некоторые из них могут быть весьма крупными и даже огромными (Китай) - но это не отменяет того факта, что инструменты разработки, учебные материалы и документация почти всегда использует английский язык.Я убеждён в том, что знание английского языка - это критический фактор , который оказывает огромное влияние на тот путь, который предстоит пройти, чтобы стать разработчиком игр. Даже с чисто практической точки зрения способность читать и понимать английские тексты - огромный козырь в борьбе за место под солнцем. Если вы откроете вакансии русских компаний-разработчиков, то в 90 % из них найдетё такой пункт, как "технический английский на уровне чтения и понимания".
Возьмём конкретный пример - 3D-графика. Текстовые и видеоуроки по 3D-графике на русском языке в большинстве своём сделаны любителями для любителей, лишь немногие из них учат чему-то, что можно назвать средним уровнем, и крайне малая часть - это действительно профессиональные и актуальные вещи. Иными словами, всё это - капля в море знаний.
Спрашивается - зачем довольствоваться каплей, если можно выпить море? Знание и понимание английского - это ваш ключ к огромному массиву полезной и актуальной информации, сам факт доступа к которой даст вам десять очков форы. Компании Digital Tutors и Gnomon Workshop имеют в своём активе тысячи часов обучающего видео по всем областям применения популярных 3D-пакетов, таких как Maya или 3DS Max. Англоязычные сайты кишат статьями о геймдеве, а на форумах могут подсказать решение сложных проблем - просто потому, что количество людей ТАМ несоизмеримо выше с количеством людей ЗДЕСЬ. Берите лучшее из двух миров!
Что делать? Учить языки - оно того стоит, даже если через год вы забросите геймдев. Как? Не спать на уроках в школе, записаться на курсы, использовать самоучители - путей много, было бы желание. Особое внимание стоит уделить лексике - вам совсем необязательно уметь говорить на этом языке, главное - уметь читать и понимать прочитанное. Уже после этого можно будет начать развивать навык восприятия английской речи на слух - и в этом могут помочь видеоуроки по 3D-графике, если вы художник, или аудиоуроки по английскому языку. Ещё раз повторюсь - по ту сторону языкового барьера огромный мир, полный информации. Не иметь к нему ключей - всё равно что учиться по черновику, когда рядом есть библиотека.
Пост о воплощении мечты и о создании игры с нуля. И о граблях разной величины.
0. Дано
Когда-то, во времена не столь от нас отдаленные, когда интернет в Уфе был ещё с помегабайтной оплатой, я занимался созданием и разработкой локальных «фришных» серверов Lineage и WoW. Но вот появились безлимитные тарифы, а локальные сервисы начали терять свою актуальность и я ушёл в вебразработку.
В некотором роде, как хобби я даже сохранил своё отношение в Геймдеву, правда, с другой стороны – разработка ботов и всего такого.
Шли года, а мысль написать что-нибудь свое, с преферансом и поэтессами не переставала меня терзать. В какой-то момент я понял, что либо сейчас, либо уже никогда.
1. Идея и Прототип
С чего начинается разработка? C прототипа. А прототип - с идеи. Для первого проекта стоит создать что-то небольшое и простое. Питая любовь к головоломкам и пошаговым стратегиям, я увлекся мыслью, что нужно сделать какую-нибудь пошаговую головоломку. Поразмыслив, вспомнил одну интересную игру времён Спектрума (стоит отметить, что автор не так стар, как может показаться) идея которой была прекрасна в своей простоте. Игрок ходит на 1 клетку, обходя препятствия, а враги его преследуют и ходят на 2 клетки, но препятствия не обходят.
Если взять ситуацию “A,” то мы можем спокойно ходить вверх и вниз, а монстр просто будет упираться в стену. В ситуации “B” монстр находится в загончике, а мы можем спокойно ходить справа, сверху и снизу от него. Поскольку игра у нас детерминированная, то существуют два типа монстров, которые отличаются по цветам и алгоритму поиска пути. Это для того чтобы не было неопределённости куда пойдёт монстр, когда он стоит наискосок. Красный всегда сначала сокращает расстояние до нуля по оси X ситуация “C”, в ней монстр зайдёт в загончик и упрётся в стенку. Фиолетовый же по оси Y ситуация “D”, в ней монстр пойдёт вниз, а потом уже направо и съедает главного героя.
Тут ещё мог бы быть большой абзац про выбор «движка» для написания игры. Но, пожалуй, можно обойтись и парой слов; перед тем как попробовать Unity3D, я поковырялся в нативном Obj-C, Corona SDK, UE, Cocos2d и ещё пару 2D Фреймворках, название которых, так глубоко в стеке памяти, что уже и не откопать.
В итоге, выбор пал на Unity3D, он мне показался оптимальным и я неспешно начал писать. Через месяц появилось вот такое приложение для iPad.
В нём мы играли за мужичка в красном и убегали от мужичков в синем, параллельно собирали сердца – читай звезды. В тот момент мы ещё использовали кубы как стены, но затем для экономии пространства на экране заменили их.
Хотелось бы отметить, что до этого момента, я никогда не писал на C#, но писал на JS, поэтому прототип был написан UnityScript (это такой диалект JS в рамках Unity3D). И это были первые большие грабли, послужившие нам уроком. Пришлось переписывать всё на C# и это заняло пару месяцев.
2. Команда
Как верно то, что я писал на десятке языков, так верно и то, что я не в состоянии нарисовать даже прямую линию. Поэтому после создания прототипа я начал искать художника\3Dшника, для этого я зашёл на сайт по фрилансу и посмотрел первых три сотни человек, с десятком - списался. Найти человека, за долю в довольно рискованном проекте, задача не из легких. Но она разрешилась, и в проекте появился талантливый художник Рамиль; итак – нас стало двое.
Параллельно я искал инвестора. Дело не в отсутствии денег, чтобы купить плагины или устройства для теста, а в том, чтобы создать обязательства, которые помогут не забить (не сложить с себя полномочия) при определенных обстоятельствах. И такой инвестор нашелся, в виде друга, решившего вложить свои кровные, в эту сомнительную, как ему казалось, затею. Итак, нас стало трое. Отмечу, что к моменту запуска, бюджет игры составил всего около 100.000р., при этом, в эту сумму входит покупка нескольких Android устройств для тестирования, плагинов и озвучки.
3. Расширение базовой концепции игры
С самого начала предполагалось, что невзирая на то, что игра будет максимально простой, необходимо будет привнести несколько новых идей в базовую концепцию. Так у нас появились односторонние телепорты (позже станет ботинком), ловушки и одноразовые грибы съедающие тех кто к ним подойдёт.
Концепт Арт
Основной фишкой игры мы планировали сделать то, что персонаж может вернуться во времени, на несколько ходов назад. Т.е. не отмену хода, а возможность переместиться 1 раз за уровень на клетку, где персонаж был 3 хода назад. Это давало огромное количество вариантов хода, но на первых же тестах выяснилось, что обычные игроки не в состоянии пройти такие уровни. Слишком сложно. Может стоить таки сделать Brainiac Edition?
Также мы много экспериментировали с размером уровней, в итоге остановились на том что весь уровень должен вмещаться на экран, даже на устройствах с небольшим экраном. Так у нас получились уровни 5х8 клеток. Но при этом у нас есть pinch zoom, для большепальцых или уровней 6х10. Кроме сокращения размера уровней, отключения возврата во времени, для упрощения была ещё добавлена отмена хода, до 5 раз за попытку.
4. 2D vs 3D
В какой-то момент наши тестовые билды выглядели так:
Ужас ужас
Приходило осознание того, что мы не в состоянии сделать картинку, которую мы хотели бы видеть в 3D с нормальным fps. Тестовая сцена для сравнения производительность 2D и 3D показывала не утешительные результаты.
Скриншоты из сцены
В итоге на iphone4, слева(3D) было всего 20 кадров в секунду, а справа(2D), стабильные 60. При этом, справа, качество картинки, как вы видите, на порядок лучше. Сейчас конечно если ориентироваться на минимальную производительность уровня iphone5+ и делать специально несколько квадратную графику, кошерные шейдеры + lightmapping + lightp robes, можно и для 3D сделать отличную графику
В итоге было принято решение всё переделывать на 2D. Но тут мы совершили ошибку, которую уже потом было не исправить. 2D анимация может быть 2 типов, первый это последовательность кадров, второй это наложение и смещение спрайтов.
Наглядное сравнение
Поскольку у нас были 3D модели, мы выбрали первый вариант. В итоге это выльется в большой вес приложения, даже с учётом огромного кол-ва оптимизаций мы не сможем уложиться в 50 мегабайт.
5. Форс-мажоры - это возможность
Не знаю можно ли назвать рождение ребёнка и переезды форс-мажорами, но именно эти события исключили нашего художника из работы над проектом, на несколько месяцев. Эти же обстоятельства сослужили службу и мне. В целях самообучения и познания тонкостей магазинов, я сделал другое небольшое приложение – обычную угадайку фильмов.
Для тех кто не понял о чём речь
На этом приложении я смог протестировать интеграцию с соц. сетями, несколько рекламных сетей, внутреннею аналитику и покупки внутри приложения.
6. Техническая часть
Думаю, настало время поднять градус гиковости. Значимую часть времени разработки заняло создание генератора уровней. Генератор писался на питоне, потому как он был мне духовно близок и numpy позволял быстро оперировать матрицами.
Сам генератор на выходе создавал txt файл(который парсился Юнити для создания сцены) и серию картинок, показывающих пошаговое прохождение уровня.
Сейчас я могу сказать, что писание внешнего генератора на другом языке, это - плохая идея. Главным образом, тем, что игровая логика начинает прописываться в двух разных местах. А это - риск рассинхрона. Особенно, если учесть, что внутри игры, есть такие понятия, как анимация и время её исполнения. И в генераторе, и в игре каждая клетка сама следила за тем, что в ней происходит: кто вошёл, кто вышел, кто умер и т.д. Но клетки, вида телепорт или мухобойка (атакует близлежащие клетки), связывали несколько клеток между собой. И если в генераторе это не вызывало проблем, то в игре повторить то же было сложнее т.к. анимации персонажей из разных клеток должны были засинхронизироваться между собой.
Огромный кусок времени заняла интеграция нативных библиотек. Cкажу прямо: если можно купить готовую реализацию того, что вам нужно, смело покупайте. При этом желательно всё брать у одного продавца, потому как в Unity3D в манифесте (Андроид), есть такая штука как mainactivity и это место где разные плагины могут конфликтовать. Потом для iOS, скорее всего, у вас будут плагины, которые занимаются различным постпроцессингом, это тоже место для конфликтов. В целом нативные либы, это место где вы легко можете получить очень трудно выявляемые ошибки. Поэтому, почти всё, что связанно с нативным кодом, мы покупали у Prime31.
Полный список плагинов и несколько слов о каждом
7. Статистика
В релизе около 400кб, написанного мной кода. Ещё 150кб - это генератор и некоторые смежные скрипты.
В самой игре, на данный момент, 3 главы по 16 отобранных уровней. Также есть режим Испытаний, где ещё около 700 уровней, динамически распределённых по сложности.
В среднем уровень без звёзд можно пройти за 25 ходов. Самые сложные уровни со звёздами около 55.
8. Монетизация и продвижение
Пока нет каких то точных цифр, но у нас как и у сайлонов есть план.
На примере угадайки фильмов мы поняли, что на рекламе можно заработать, только если у вас от 300к+ пользователей. Поскольку проект у нас, как ни крути нишевой, думаю это не вариант. Но при этом делать платное приложение для Андроида - самоубийство. В итоге была выбрана стандартная нынче модель: показ рекламы и продажа монет. С любой покупкой монет идёт в комплекте полное отключение рекламы. Монеты даются при прохождении уровней и за них можно узнать идеальное прохождение уровня.
Что должны учитывать будущие разработчики игр? С какого языка начать обучение? К чему стремиться? На кого равняться? И что необходимо сделать в первую очередь?
Большинство любителей рок-музыки рано или поздно берут в руки гитару. Фанаты спорта страстно мечтают о выходе на футбольное поле, баскетбольную площадку или теннисный корт. Ну а те, кто совершил сотни угонов в GTA, провел десятки часов в компьютерных клубах за Counter-Strike или достиг немалых успехов в MMORPG, наверняка задумываются о карьере разработчика игр.
Проблема в том, что данному направлению обучают в считанных учебных заведениях. Посему большинство разработчиков игр – самоучки, некогда сами составившие учебную программу. Но какие нюансы они учитывали? С чего начинали и к чему стремились? Какой язык учили в первую очередь? На эти и другие актуальные вопросы мы и постарались ответить.
К чему стремиться?
Перед походом в магазин вы составляете список покупок (хотя бы в голове). Перед поездкой в другой конец города – прокладываете маршрут. Ну а перед тем, как обучаться разработке игр, целесообразно задаться вопросом: чем именно вы хотите заниматься? Создавать мобильные приложения или браузерные игры? Трудиться в крупной компании или маленькой? Профессионально заниматься разработкой игр или посвящать этому свободное от работы время? И если первое, то что интересует вас больше: создание интерфейса, отшлифовка геймплея или написание скриптов?
Правильная постановка цели поможет сэкономить уйму времени и сил. Кроме того, позволит достичь конечного пункта кратчайшим путем. Без риска сойти с дороги или угодить в болото.
Какой язык учить?
Кроме того, от цели зависит и ответ на животрепещущий вопрос: с какого языка программирования стоит начинать?
Так, будущим разработчикам игр вроде Minecraft и мобильных приложений под Android стоит обратить пристальное внимание на Java. Для начала советуем пройти интенсив , тем более, что это бесплатно. Тем, кто заглядывается в сторону iOS – на Objective-C. Для браузерных игр порой хватает знания Ruby-On-Rails. Для совсем маленьких и простых временами достаточно HTML. В производстве Flash-игр используется ActionScript, а для написания скриптов любой сложности вам понадобится JavaScript или, возможно, не столь распространенная Lua. Для создания же небольших консольных игр требуется знание C#.
Что до наиболее крупнобюджетных игр (так называемого класса AAA), то большинство из них оснащены своим или заимствованным у коллег "движком". Нередко, впрочем, весь "движок" или его большая часть написана на C++. Именно этот язык использовался при создании множества известных "игрушек" – от Doom 3 и Call Of Duty до FIFA и The Sims. В то время как классика вроде Quake была написана на C.
Впрочем, в освоении C++ есть и загвоздка – чрезмерная сложность. Недаром ведь говорят, что браться за C++, не зная других языков, – все равно, что начинать изучение математики с линейных уравнений.
Достаточно ли одного языка?
Одна из прелестей программирования – возможность постоянного саморазвития. В разработке же игр (особенно крупных) самосовершенствование, в том числе изучение как можно большего количества языков, – не прихоть, а жизненная необходимость. Так, опытные разработчики, трудящиеся на благо гигантов игровой индустрии, нередко сталкиваются с необходимостью поочередно писать на 7-8 языках. При этом, помимо вышеуказанных языков, им приходится изучать, к примеру, Python либо и вовсе SQL (как вы понимаете, для создания баз данных).
Поэтому, если вы решили связать судьбу с производством крупных игр, будьте готовы стать "полиглотом". Кроме того, чем больше языков вы освоите, тем более интересные и разнообразные задачи перед вами поставят. Ну и, конечно, шансы на получение работы мечты заметно возрастут.
С ЧЕГО НАЧАТЬ?
Перед тем, как совершить кругосветное путешествие, нужно научиться ходить. Ну а перед серьезным игровым проектом необходимо попробовать силы в чем-то менее значимом.
Практически все опытные разработчики вне зависимости от регалий и таланта начинали с небольших приложений: настольных игр, вариаций известных "игрушек", простеньких "флэшек". Тогда они не думали о крупных выставках вроде E3, а накапливали бесценный опыт. Почему бы не последовать их примеру? При этом не обязательно писать архисложный код. Для дебюта достаточно использования специальных программ для создания игр (к примеру, Game Maker). Ведь даже благодаря несложному инструментарию вы значительно облегчите себе жизнь. Во-первых, в миниатюре поймете логику и структуру практически любого игрового приложения. Во-вторых, набьете шишки, которые заживут во время перехода к серьезным проектам. Наконец, в-третьих, обогатите портфолио. Ведь даже простая "игрушка" требует массу времени, терпения и творчества для выдумки концепции, написании кода и устранения багов. Кроме того, показывает, что с производством игр вы знакомы не только в сухой теории.
Что брать за ориентир?
Тот, кто мечтает стать писателем, прочитает сотни книг перед тем, как напишет хотя бы одно слово. Мастера игры на фортепиано на зубок знают лучшие произведения Штрауса, Шопена и Бетховена. Известные же художники перед крупными выставками наизусть заучивали историю искусств.
В разработке игр действует тот же принцип. Вы не сможете развиваться в вакууме. Поэтому играйте, вдохновляйтесь мастерами и, как губка, впитываете лучшее. При этом старайтесь смотреть на приложения не глазами "геймера", а взором разработчика. Иными словами: транспонируйте игру. Задумайтесь, почему в данный момент времени "бот" побежал налево, а не назад? Из-за каких факторов меняется сила и точность удара в спортивном симуляторе? Как создать "эффект усталости" при долгом беге персонажа? Как сделать так, чтобы во время дождя игрок слышал звук капель, а не свиной визг? В общем, проникайте в суть. Постарайтесь воссоздать в голове алгоритмы, с которыми сталкиваетесь во время игры. Поверьте, подобный конструктивный подход поможет вам в будущей нелегкой, но чертовски увлекательной карьере разработчика игр.
В последнее время я занят тем, что пишу игровой движок на C++. Я пользуюсь им для создания небольшой мобильной игры Hop Out . Вот ролик, записанный с моего iPhone 6. (Можете включить звук!)
Your browser does not support HTML5 video.
Hop Out - та игра, в которую мне хочется играть самому: ретро-аркада с мультяшной 3D-графикой. Цель игры - перекрасить каждую из платформ, как в Q*Bert.
С чего бы кому-то хотеть написать игровой движок? Возможных причин много:
- Вы - ремесленник. Вам нравится строить системы с нуля и видеть, как они оживают.
- Вы хотите узнать больше о разработке игр. Я в игровой индустрии 14 лет и всё ещё пытаюсь в ней разобраться. Я даже не был уверен, что смогу написать движок с чистого листа, ведь это так сильно отличается от повседневных рабочих обязанностей программиста в большой студии. Я хотел проверить.
- Вам нравится ощущение контроля. Организовать код именно так, как вам хочется, и всегда знать, где что находится - это приносит удовольствие.
- Вас вдохновляют классические игровые движки, такие как AGI (1984), id Tech 1 (1993), Build (1995), и гиганты индустрии вроде Unity и Unreal.
- Вы верите, что мы, индустрия игр, должны сбросить покров таинственности с процесса разработки движков. Мы пока не очень-то освоили искусство разработки игр - куда там! Чем тщательнее мы рассмотрим этот процесс, тем выше наши шансы усовершенствовать его.
Игровые платформы в 2017-ом - мобильные, консоли и ПК - очень мощные и во многом похожи друг на друга. Разработка игрового движка перестала быть борьбой со слабым и редким железом, как это было в прошлом. По-моему, теперь это скорее борьба со сложностью вашего собственного произведения . Запросто можно сотворить монстра! Вот почему все советы в этой статье вращаются вокруг того, как сохранить код управляемым. Я объединил их в три группы:
- Осознайте, что сериализация - обширная тема.
Эти советы применимы к любому игровому движку. Я не собираюсь рассказывать, как написать шейдер, что такое октодерево или как добавить физику. Я полагаю, вы и так в курсе, что должны это знать - и во многом эти темы зависят от типа игры, которую вы хотите сделать. Вместо этого я сознательно выбрал темы, которые не освещаются широко - темы, которые я нахожу наиболее интересными, когда пытаюсь развеять завесу тайны над чем-либо.
Используйте итеративный подход
Мой первый совет - не задерживаясь заставьте что-нибудь (что угодно!) работать, затем повторите.
По возможности, начните с образца приложения, которое инициализирует устройство и рисует что-нибудь на экране. В данном случае я скачал SDL , открыл Xcode-iOS/Test/TestiPhoneOS.xcodeproj , затем запустил на своём iPhone пример testgles2 .
Вуаля! У меня появился замечательный вращающийся кубик, использующий OpenGL ES 2.0.
Моим следующим шагом было скачивание сделанной кем-то 3D-модели Марио. Я быстро написал черновой загрузчик OBJ-файлов - этот формат не так уж сложен - и подправил пример, чтобы он отрисовывал Марио вместо кубика. Ещё я интегрировал SDL_Image , чтобы загружать текстуры.
Затем я реализовал управление двумя стиками, чтобы перемещать Марио. (Поначалу я рассматривал идею создания dual-stick шутера. Впрочем, не с Марио).
Следующим делом я хотел познакомиться со скелетной анимацией, так что открыл Blender , создал модель щупальца и привязал к нему скелет из двух костей, которые колебались туда-сюда.
К тому моменту я отказался от формата OBJ и написал скрипт на Python для экспорта собственных JSON-файлов из Blender. Эти JSON-файлы описывали заскиненный меш, скелет и данные анимации. Я загружал эти файлы в игру с помощью библиотеки C++ JSON .
Как только всё заработало, я вернулся в Blender и создал более проработанного персонажа (Это был первый сделанный и зариганный мной трёхмерный человек. Я им весьма гордился.)
В течение следующих нескольких месяцев я сделал такие шаги:
- Начал выделять функции работы с векторами и матрицами в собственную библиотеку трёхмерной математики.
- Заменил.xcodeproj на проект CMake
- Заставил движок запускаться и на Windows, и на iOS, потому что мне нравится работать в Visual Studio.
- Начал перемещать код в отдельные библиотеки "engine" и "game". Со временем, я разделил их на ещё более мелкие библиотеки.
- Написал отдельное приложение, чтобы конвертировать мои JSON-файлы в бинарные данные, которые игра может загружать напрямую.
- В какой-то момент убрал все библиотеки SDL из iOS-сборки. (Cборка для Windows всё ещё использует SDL.)
Ключевой момент в следующем: я не планировал архитектуру движка до того как начал программировать . Это был осознанный выбор. Вместо этого я всего лишь писал максимально простой код, реализующий следующую часть функционала, затем смотрел на него, чтобы увидеть, какая архитектура возникла естественным образом. Под "архитектурой движка" я понимаю набор модулей, которые составляют игровой движок, зависимости между этими модулями и API для взаимодействия с каждым модулем.
Может показаться, что при таком подходе много времени теряется впустую, ведь вы всегда пишете плохой код, который потом требуется переписывать начисто. Но большая часть изменений представляет собой перемещение кода из одного.cpp -файла в другой, извлечение определений функций в.h -файлы или другие не менее простые действия. Определить, где что должно лежать - сложная задача, и решить её проще, когда код уже существует.
Готов поспорить, что больше времени тратится при противоположном подходе: пытаться заранее продумать архитектуру, которая будет делать всё, что вам понадобится. Две моих любимых статьи про опасности чрезмерной инженерии - The Vicious Circle of Generalization Томаша Дабровски и Don’t Let Architecture Astronauts Scare You Джоэла Спольски.
Я не говорю, что вы не должны решать проблемы на бумаге до того, как столкнётесь с ними в коде. Я также не утверждаю, что вам не следует заранее решить, какой функционал вам нужен. Например, я знал с самого начала, что хочу, чтобы движок загружал все ресурсы в фоновом потоке. Просто я не пытался спроектировать или реализовать этот функционал до тех пор, пока мой движок не начал загружать хоть какие-то ресурсы.
Итеративный подход дал мне куда более элегантную архитектуру, чем я мог бы вообразить, глядя на чистый лист бумаги. iOS-сборка моего движка сегодня на 100% состоит из оригинального кода, включая собственную математическую библиотеку, шаблоны контейнеров, систему рефлексии/сериализации, фреймворк рендеринга, физику и аудио микшер. У меня были причины писать каждый из этих модулей самостоятельно, но для вас это может быть необязательным. Вместо этого есть множество отличных библиотек с открытым исходным кодом и разрешительной лицензией, которые могут оказаться подходящими вашему движку. GLM , Bullet Physics и STB headers - лишь некоторые из интересных примеров.
Дважды подумайте, прежде чем слишком обобщать
Как программисты, мы стремимся избегать дублирования кода, и нам нравится, когда код следует единому стилю. Тем не менее, я думаю, что полезно не давать этим инстинктам управлять всеми решениями.
Время от времени нарушайте принцип DRY
Приведу пример: мой движок содержит несколько шаблонных классов умных указателей, близких по духу к std::shared_ptr . Каждый из них помогает избежать утечек памяти, выступая обёрткой вокруг сырого указателя.
- Owned<> для динамически выделяемых объектов, имеющих единственного владельца.
- Reference<> использует подсчёт ссылок чтобы позволить объекту иметь несколько владельцев.
- audio::AppOwned<> используется кодом за пределами аудио микшера. Это позволяет игровым системам владеть объектами, которые аудио микшер использует, такими как голос, который в данный момент воспроизводится.
- audio::AudioHandle<> использует систему подсчёта ссылок, внутреннюю для аудио микшера.
Может показаться, что некоторые из этих классов дублируют функциональность других, нарушая принцип DRY . В самом деле, в начале разработки я пытался повторно использовать существующий класс Reference<> как можно больше. Однако, я выяснил, что время жизни аудио-объекта подчиняется особым правилам: если объект закончил воспроизведение фрагмента, и игра не владеет указателем на этот объект, его можно сразу же поместить в очередь на удаление. Если игра захватила указатель, тогда аудио-объект не должен быть удалён. А если игра захватила указатель, но владелец указателя уничтожен до того, как воспроизведение закончилось, оно должно быть отменено. Вместо того чтобы усложнять Reference<> , я решил, что будет практичнее ввести отдельные классы шаблонов.
95% времени повторное использование существующего кода - верный путь. Но если оно начинает вас сковывать или вы обнаруживаете, что усложняете что-то, однажды бывшее простым, спросите себя: не должна ли эта часть кодовой базы в действительности быть разделена надвое.
Использовать разные соглашения о вызове - это нормально
Одна из вещей, которая мне не нравится в Java - то, что она заставляет вас определять каждую функцию внутри класса. По-моему, это бессмысленно. Это может придать вашему коду более единообразный вид, но также поощряет переусложнение и не поддерживает итеративный подход, описанный мной ранее.
В моём C++ движке некоторые функции принадлежат классами, а некоторые - нет. Например, каждый противник в игре - это класс, и бо́льшая часть поведения противника реализована в этом классе, как и следовало ожидать. С другой стороны, в моём движке выполняются вызовом sphereCast() , функции в пространстве имён physics . sphereCast() не принадлежит какому-либо классу - это просто часть модуля physics . У меня есть система сборки, которая управляет зависимостями между модулями, что сохраняет код достаточно (для меня) хорошо организованным. Заворачивание этой функции в произвольный класс никоим образом не улучшит организацию кода.
Как минимум, постарайтесь представить, насколько сложными будут ваши требования. Если вы делаете маленькую игру вроде Flappy Bird, с несколькими ассетами, вам скорее всего не придётся много думать о сериализации. Вероятно, вы можете загружать текстуры напрямую из PNG и этого будет достаточно. Если вам нужен компактный бинарный формат с обратной совместимостью, но вы не хотите разрабатывать свой - взгляните на сторонние библиотеки, такие как Cereal или Boost.Serialization . Не думаю, что Google Protocol Buffers идеально подходят для сериализации игровых ресурсов, но они всё равно стоят изучения.
Написание игрового движка - даже маленького - большое предприятие. Я мог бы сказать намного больше, но, если честно, самый полезный совет, который я могу придумать для статьи такой длины: работайте итеративно, слегка сопротивляйтесь тяге к обобщению кода, и помните, что сериализация - обширная тема, так что понадобится выбрать подходящую стратегию. Мой опыт показывает, что каждый из этих пунктов может стать камнем преткновения, если его игнорировать.
Я люблю сравнивать наблюдения по этой теме, так что мне очень интересно услышать мнение других разработчиков. Если вы писали движок, привел ли ваш опыт к тем же выводам? А если не писали или ещё только собираетесь, ваши мысли мне тоже интересны. Что вы считаете хорошим ресурсом для обучения? Какие аспекты ещё кажутся вам загадочными? Не стесняйтесь оставлять комментарии ниже или свяжитесь со мной
