Шутер как конструктор. Собери и опубликуй свою игру на Unity из готового шаблона

1.3 Открываем проект в Unity

Запустите Unity Hub. На вкладке Projects нажмите Add → Add project from disk.

Укажите распакованную папку проекта и нажмите Open. Проект появится в списке — кликните по нему, чтобы открыть в редакторе. Первый запуск может занять время: Unity импортирует ресурсы и собирает зависимости.

Рис. 1.2. Добавление проекта в Unity Hub: Add → Add project from disk.

Когда проект откроется, в окне Project появится папка Assets/Project_Shooter, а в папке Scenes — три сцены: MainMenu, Level_1, EndScene. Откройте MainMenu и нажмите Play, чтобы убедиться, что игра запускается.

Рис. 1.3. Проект открыт в редакторе Unity: окна Scene, Game, Hierarchy, Project.

1.4 Собираем браузерный билд (WebGL)

Откройте File → Build Profiles (в более ранних версиях Unity — Build Settings). В списке платформ выберите Web (WebGL) и нажмите Switch Platform. Если платформа недоступна — согласитесь на установку модуля Web Build Support и подождите.

Рис. 1.4. Окно Build Profiles: выбрана платформа Web (WebGL), кнопка Switch Platform.

Убедитесь, что в списке сцен сборки (Scene List) присутствуют MainMenu, Level_1 и EndScene, причём MainMenu стоит первой. Нажмите Build, укажите папку и назовите её, например, DeepGalacticShooterBuild. Дождитесь окончания сборки.

Рис. 1.5. Выбор папки сборки DeepGalacticShooterBuild и список сцен.

После сборки соберите содержимое папки DeepGalacticShooterBuild в один .zip-архив — именно архив мы загрузим на Яндекс.Игры.

Совет: подробно про настройки сборки под WebGL (Player Settings, шаблон, сжатие) — в Главе 5. Для быстрого старта достаточно переключить платформу на WebGL и нажать Build: значения по умолчанию вполне рабочие.

1.5 Заливаем билд в консоль Яндекс.Игр

Перейдите на yandex.ru/dev/games, войдите под аккаунтом Яндекса и откройте консоль разработчика. При первом входе пройдите быструю бесплатную регистрацию разработчика.

Рис. 1.6. Консоль разработчика Яндекс.Игр: кнопка «Добавить приложение».

Нажмите «Добавить приложение», придумайте название (например, DeepGalacticShooter) и сохраните черновик. Игра появится во вкладке «Приложения» со статусом Draft (черновик).

Откройте черновик, найдите раздел «Исходники» и загрузите ваш .zip-архив со сборкой. Ниже, в поле «Поддерживаемые платформы», выберите «все десктопные браузеры». Сохраните черновик.

Рис. 1.7. Раздел «Исходники»: загрузка архива сборки и выбор поддерживаемых платформ.

1.6 Получаем ссылку и отправляем другу

Когда архив пройдёт автоматическую проверку, в черновике появится ссылка на игру (вида yandex.ru/games/app/...). Это рабочая ссылка на вашу публикацию.

Скопируйте её и отправьте другу — он откроет игру прямо в браузере, без установки чего-либо. Управление: бег — стрелки, стрельба — клавишей Z.

Рис. 1.8. Готовая ссылка на игру и запуск в браузере на Яндекс.Играх.

Готово! Вы собрали игру и опубликовали её. Если уложились в 15 минут — поздравляю: вы только что прошли путь, на который у многих уходят недели.

Теория: жизненный цикл игры — от идеи до игроков

Вы только что собрали и опубликовали игру за пятнадцать минут — и, честно говоря, это маленькое чудо. Но за этими пятнадцатью минутами прячется большой и красивый процесс, который проходит каждая игра на свете, от инди-однодневки до многомиллионного блокбастера. Давайте посмотрим на него целиком, с высоты птичьего полёта, — чтобы вы понимали не только что нажимали, но и где в общей картине находились. Хорошая новость: вы уже прошли весь этот путь от начала до конца. Осталось только разложить его по полочкам, внести изменения чтобы сделать игру "оригинальной" и начать на ней зарабатывать :)

Пять этапов: идея → прототип → продакшн → билд → публикация (и потом — поддержка)

Любая игра рождается из идеи. Иногда это одна фраза: «космический шутер, где ты отстреливаешься от волн врагов и собираешь кристаллы». Идея — это ещё не игра, это направление, обещание самому себе. На этом этапе важно не утонуть в мечтах о «лучшей игре всех времён», а сформулировать суть в паре предложений: какой жанр, что делает игрок, что приносит удовольствие. Наш DeepGalacticShooter — это как раз такое обещание, обретшее форму.

Дальше идёт прототип — самая честная стадия. Здесь вы проверяете, весело ли вообще играть, ещё до красивой графики и музыки. Прототип может быть уродливым: кубик стреляет по кубикам — но если в этот момент уже интересно, идея жива. Если нет — лучше узнать это сейчас, на кубиках, а не через полгода полировки.

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

Когда игра готова (или хотя бы готова показаться людям), наступает сборка, она же билд — превращение проекта в работающее приложение. И финальный аккорд — публикация: вы выкладываете игру туда, где её найдут игроки. В нашем случае — на Яндекс.Игры, в браузер.

А после публикации история не заканчивается — начинается поддержка и обновления: вы читаете отзывы, чините баги, докручиваете баланс, добавляете контент. Игра — это не камень, который высекли и забыли, а скорее сад, за которым ухаживают.

Разбираем каждую стадию подробнее: что она даёт

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

Идея и концепт. Сначала идея живёт в голове, а потом её записывают. Документ, в котором сформулирована суть игры, называют концептом (или однострочным «pitch»): жанр, целевая аудитория, ключевая эмоция, главная механика, чем игра отличается от соседей по полке. Для инди это не толстый «дизайн-документ на 200 страниц», а скорее одна-две страницы, которые можно показать другу и спросить: «понятно, во что тут играют?». Что даёт стадия: фокус. Когда суть записана, легче отвечать «нет» всему, что в эту суть не вписывается.

Препродакшн (preproduction). Это этап «разведки боем»: вы ещё не строите всю игру, а проверяете рискованные места. Заработает ли управление? Весело ли стрелять? Потянет ли выбранная графика браузер? Здесь делают черновые наброски, маленькие технические пробы (их называют spike — «укол», быстрый эксперимент ради одного вопроса) и собирают первые прототипы. Что даёт стадия: снимает страх неизвестности. К концу препродакшна вы знаете, что игра в принципе осуществима силами вашей команды.

Прототип и вертикальный срез. Прототип отвечает на вопрос «весело ли?». А когда веселье подтвердилось, делают вертикальный срез (vertical slice) — маленький, но полностью готовый кусочек игры: один уровень, доведённый до финального качества, с графикой, звуком, интерфейсом и балансом. Это как пробная порция в ресторане: по ней судят обо всём блюде. Наш Level_1 в шаблоне очень близок по духу к вертикальному срезу — это один уровень, который выглядит и играется «по-настоящему», хотя вся игра ещё не достроена.

Продакшн. Когда срез доказал, что «вот так это и должно ощущаться», начинается тиражирование: по образцу первого уровня делают остальные, добавляют врагов, оружие, боссов, наполняют игру контентом. Это самая долгая и самая «рабочая» стадия — много рутины, мало откровений. Что даёт стадия: объём. Из одного убедительного кусочка вырастает целая игра.

Альфа, бета и плейтест. Альфа — момент, когда в игре есть всё основное содержимое («feature complete»), но оно ещё сырое и в багах. Бета — когда новые фичи больше не добавляют, а только шлифуют и чинят. Между ними и вокруг них непрерывно идёт плейтест — наблюдение за тем, как в игру играют другие люди. Что даёт стадия: правду. Только живой игрок покажет, что «очевидная» кнопка неочевидна, а «честный» враг кажется нечестным.

Релиз. Игра выходит к широкой аудитории. Для инди это часто не громкий «запуск ракеты», а тихая загрузка билда в магазин или на платформу — ровно то, что вы сделали в этой главе.

Пост-релиз и live-ops. После выхода игру поддерживают: патчи, баланс, новый контент, реакция на отзывы. Если игра живёт долго и постоянно обновляется, такую поддержку называют live-ops (live operations — «эксплуатация вживую»). Что даёт стадия: жизнь после рождения. Многие любимые игры стали любимыми не на релизе, а спустя десятки обновлений.

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

Итеративность: круг, а не прямая

Может показаться, что стадии идут строго по очереди: закончил одну — перешёл к следующей. На деле геймдев почти всегда итеративен — он движется кругами. Вы делаете маленькую версию, показываете её, узнаёте что-то новое и возвращаетесь назад, чтобы переделать. Прототип может отправить вас обратно к идее («а давай враги не летят, а ползут»). Плейтест посреди продакшна может заставить переписать управление. Это не провал и не хаос — это нормальный пульс разработки.

Сердце каждой итерации — плейтест. И здесь есть тонкость, которую новички узнают на собственных шишках: смотреть, как человек играет, важнее, чем спрашивать его мнение. Игрок может вежливо сказать «всё классно», но если вы видели, как он трижды промахнулся мимо кнопки старта или не понял, куда идти, — вы узнали в десять раз больше, чем из любых слов. Поэтому правило простое: дайте человеку поиграть, молчите, не подсказывайте и наблюдайте. А выводы делайте по действиям, а не по комплиментам.

Скоуп и коварный «feature creep»

Есть слово, от которого у опытных разработчиков слегка дёргается глаз, — скоуп (scope), то есть объём задуманного: сколько уровней, врагов, механик, режимов вы собираетесь сделать. Скоуп — это размер вашего обещания самому себе. И главная беда новичка не в том, что он мало задумал, а в том, что он задумал слишком много.

У этой беды есть имя — feature creep («расползание фич»): когда в проект потихоньку, по одной невинной идее за раз, добавляются всё новые возможности. «А давай ещё прокачку. И крафт. И мультиплеер. И сюжет с диалогами». Каждая идея по отдельности хороша, но вместе они топят проект: игра, которую можно было выпустить через месяц, не выходит и через год, потому что список «ещё бы добавить» растёт быстрее, чем вы успеваете его закрывать. Кладбище незаконченных инди-игр на 90% состоит именно из жертв feature creep, а не из плохих идей.

Лекарство — дисциплина скоупа. Запишите список фич, разделите его на «обязательно для выхода» и «потом, если будет время», и охраняйте первый список как сокровище. Хорошая привычка — спрашивать о каждой новой идее: «без этого игру нельзя выпустить?». Если можно — значит, это «потом».

Прикиньте сами: один аккуратный уровень, три типа врагов и одно оружие — это игра, которую реально доделать и выпустить. «Открытый космос с сотней планет, экономикой и кооперативом» — это мечта, которая, скорее всего, никогда не доедет до игроков. Маленький законченный шутер бьёт большой ненаписанный по всем статьям.

Прототип и MVP: почему «выпускай рано, выпускай часто»

Здесь важно познакомиться с двумя понятиями, которые сэкономят вам месяцы. Прототип — это проверка идеи на «весело / не весело». А MVP (minimum viable product, «минимально жизнеспособный продукт») — это самая маленькая версия игры, которую уже не стыдно показать игрокам: в ней есть начало, середина и конец, она работает и в неё можно играть, пусть и без излишеств.

Главная мысль звучит почти как девиз: «выпускай рано, выпускай часто» (release early, release often). Смысл прост и слегка контринтуитивен. Начинающий разработчик хочет «доделать всё до идеала, а потом показать». Опытный — наоборот, стремится показать как можно раньше, пусть и сыроватое. Почему? Потому что пока игра лежит у вас на диске, вы гадаете, что понравится людям. А как только она попадает к живым игрокам, гадание сменяется фактами. Маленькая игра в руках игроков ценнее, чем шедевр в воображении.

В этой главе вы фактически сделали именно это: взяли готовый MVP и сразу выпустили его. Вы не ждали, пока освоите весь Unity, — вы получили живую ссылку уже сегодня. Это и есть правильный геймдев-рефлекс.

MVP и вертикальный срез: два разных «маленьких»

Выше мы уже познакомились с MVP. Теперь стоит развести два похожих, но разных понятия, которые легко спутать.

MVP — это самая маленькая игра вширь: в ней есть всё необходимое от старта до финала, но всё — по минимуму. Один уровень, один враг, базовый интерфейс, экран победы. Игру можно пройти от начала до конца — и этого достаточно, чтобы выпустить и собрать обратную связь. MVP отвечает на вопрос: «можно ли в это играть как в законченную игру?».

Вертикальный срез — это маленькая игра вглубь: один кусочек, доведённый до финального качества по всем «слоям» сразу (отсюда «вертикальный» — он прорезает все этажи: графику, звук, геймплей, полировку). Срез отвечает на вопрос: «а так это будет выглядеть и ощущаться в готовой игре?».

Грубо говоря, MVP показывает форму всей игры в дешёвом исполнении, а срез показывает качество одного куска. Наш шаблон удачно совмещает оба: цепочка MainMenu → Level_1 → EndScene — это полноценный MVP (есть начало, игра и финал), а сам Level_1 тянет на вертикальный срез — он играбелен и оформлен «по-настоящему».

Почему публиковаться рано — это про петли обратной связи

За девизом «выпускай рано» стоит не лень и не спешка, а холодный расчёт. Пока игра лежит у вас на диске, вы крутитесь внутри одного контура: придумал → сделал → сам же оценил. Беда в том, что вы — худший в мире судья собственной игры: вы знаете все правила наизусть, помните, где какая кнопка, и давно перестали замечать то, что новичка ставит в тупик. Ваш внутренний контур врёт.

Публикация замыкает второй контур — с живыми игроками. И этот контур говорит правду. Чем раньше вы его замкнёте, тем раньше начнёте принимать решения на фактах, а не на догадках. Это и называют петлёй обратной связи: выпустил версию → понаблюдал за реакцией → поправил → выпустил снова. Чем короче петля и чем чаще она прокручивается, тем быстрее игра становится хорошей. Разработчик, который выпустил десять сыроватых версий и десять раз послушал игроков, обгонит того, кто полгода в одиночку «полировал шедевр», — просто потому, что у первого было десять уроков от реальности, а у второго ни одного.

Есть и приятный побочный эффект, чисто человеческий: ранний релиз даёт энергию. Незаконченный проект давит чувством «ещё столько всего надо». А игра, которая уже живёт по ссылке и которой кто-то поиграл, наоборот заряжает: хочется сделать следующую версию лучше. Мотивация — топливо инди-разработки, и публикация заправляет бак.

Где в этом цикле находимся мы — и почему начали с конца

Теперь самое интересное: где во всём этом большом круге стоите вы прямо сейчас? Формально — в самом начале пути: впереди и разбор проекта, и изменение уровней, и написание механик, весь продакшн. Но на карте цикла вы только что сделали странную вещь — шагнули сразу в финал. Вы собрали билд и опубликовали игру раньше, чем что-либо в ней изменили.

Это сделано намеренно, и вот зачем. Обычно публикация — пугающая финальная стена, к которой новичок подходит измотанным, после месяцев работы, с мыслью «а вдруг не получится залить». Мы убрали эту стену в самом начале: теперь вы знаете, что путь до игроков проходим, потому что прошли его своими руками. Дальше, когда мы будем менять врагов и рисовать уровни, у вас за спиной уже будет рабочая публикация и понятная процедура «как выложить». Это меняет всё: вы не «учитесь ради далёкого результата», а улучшаете то, что уже живёт в интернете.

Так что наша книга устроена как одна большая итерация цикла. Глава 1 — это релиз «как есть» (чужой MVP, выпущенный без изменений). Главы 2–5 — это возвращение в продакшн: разбор, переделка под себя, проектирование и новая сборка. А Глава 6 — пост-релиз и развитие: лидерборды, сохранения, достижения. Мы прокрутили петлю обратной связи один раз прямо на первой странице — чтобы дальше крутить её осознанно.

Что такое билд и зачем игру «собирают»

Пока вы работаете в Unity, проект существует как груда исходных файлов: сцены, скрипты на C#, текстуры, модели, настройки. Запускать это умеет только сам редактор. Чтобы игру смог запустить обычный человек без Unity, проект нужно собрать — то есть превратить в самостоятельное приложение. Этот процесс и его результат называют билдом (от англ. build — «собирать»).

Во время сборки Unity компилирует ваш код, упаковывает все ресурсы, оптимизирует их под выбранную платформу и складывает в папку, которую уже можно запустить или залить на сервер. По сути билд — это перевод вашего проекта с «языка разработчика» на «язык игрока». Именно папку DeepGalacticShooterBuild вы только что и получили.

Платформы, WebGL и сила первой обратной связи

Платформа публикации — это то, где живёт ваша игра: Windows, Android, iOS, PlayStation, Steam или браузер. Под каждую платформу собирается свой билд, со своими правилами и заморочками. И вот почему мы выбрали браузерную сборку (WebGL): это самый короткий путь от вас до игроков. Не нужно ничего устанавливать, не нужно проходить недели модерации в магазинах приложений, не нужен отдельный компьютер с нужной системой. Игрок просто открывает ссылку — и играет. Одна ссылка, которую можно отправить кому угодно в мессенджере, — это и есть магия WebGL.

И тут включается, пожалуй, самое ценное во всём цикле — обратная связь от первых игроков. Когда друг напишет «слушай, а враги слишком быстрые» или «классно, но кнопка не нажимается на телефоне», вы получите то, чего не даст никакая теория: взгляд со стороны. Первые игроки покажут, где игре весело, а где скучно или непонятно, — и именно их реакция направит ваш продакшн в нужную сторону. Поэтому мы и начали книгу с публикации: чтобы у вас как можно раньше появилась живая игра, которую можно показать, и живые люди, которые на неё ответят.

1.7 Что дальше

Давайте честно проговорим, что произошло — это важно для понимания всей книги.

Мы прошли весь конвейер целиком: проект → Unity → билд → консоль → ссылка. Пока на «готовом» проекте и без подробностей — но вы своими руками довели игру до публикации и убедились, что «выложить игру в интернет» проще, чем кажется. Теперь это для вас не страшный финал, а понятная процедура.

Дальше мы пройдём тот же путь осознанно и детально, превращая чужой шаблон в свою игру:

во второй главе установим Unity и подключим шаблон шутера;

в третьей разберём проект изнутри и начнём менять его под себя — уровни, врагов, предметы;

в четвёртой научимся думать как гейм-дизайнер и спроектируем свою игру на бумаге;

в пятой соберём собственную WebGL-версию и обновим ею тот же черновик, что вы создали сегодня;

в шестой добавим лидерборды, облачные сохранения, достижения и займёмся развитием игры.

Черновик, который вы только что завели, никуда не денется — в Главе 5 мы зальём в него уже изменённую вами сборку. Быстрый старт превратится в полноценный проект.

Выводы

В этой главе мы перевернули привычный порядок и начали с результата: вы скачали проект, собрали браузерную версию в Unity и опубликовали её на Яндекс.Играх, получив рабочую ссылку. Весь путь — от файлов проекта до игры, доступной другу по ссылке, — занял считаные минуты.

Это и есть главная идея книги: не «учиться годами ради далёкого результата», а быстро получить работающую игру и наращивать на неё своё. Теперь, когда вы уже видели финал, вернёмся к началу пути и соберём эту игру вдумчиво — со своим стилем, уровнями и механиками.

Закрепление главыЧто вы освоили

Эта глава была про самое смелое — провести чужой готовый проект DeepGalacticShooter до публикации по ссылке. Оглянитесь: вы уже умеете делать то, на что у многих уходят недели.

1. Скачивать и разворачивать готовый проект Unity с Яндекс.Диска и добавлять его в Unity Hub через Add → Add project from disk.

2. Открывать проект и проверять его на работоспособность: находить папку Assets/Project_Shooter, открывать сцену MainMenu и запускать игру кнопкой Play.