От хакатона до собственной студии разработки игр. Часть 2 / Microsoft corporate blog / Habr
Делимся продолжением истории из жизни инди-разработчиков из IzHard. Сегодня команда расскажет про события, которые с ними происходили после победы в международном конкурсе, а также про ошибки, которые они совершали в процессе развития.Цикл статей «GameDev с нуля»
1. От хакатона до собственной студии разработки игр: часть 1, часть 2.
2. Unity3D и векторная графика.
3. Как общаться с игроком без слов.
4. Как выйти из хаоса и начать работать.
Всем привет
Продолжаем цикл статей «GameDev с нуля» глазами команды IzHard. В первой части мы рассказали, как попали в игровую индустрию и победили в конкурсе Imagine Cup. Во второй части расскажем о том, как пошли наши дела по возвращению домой, как расширилась наша команда, какие задачи мы поставили перед собой, что дают поездки на игровые конференции, почему получилось, что игру делаем так долго, и как резюме, наши ошибки, которые мы наделали будучи неопытными, и советы о том, как не стоит поступать.
Возвращение домой и приятные новости
Итак, после того как мы вернулись в Питер и сделали себе перерыв длиной в месяц, нам предстояло решить главную задачу — доделать игру и выпустить её.
Уже в начале осени у нас появился заинтересованный издатель — компания Nekki. Они предложили нам неплохие условия, на которых мы полностью брали на себя разработку продукта, а все вопросы маркетинга и продвижения оставались им. Это был отличный вариант — не отвлекаться от разработки и спокойно делать игру. Мы заключили устную договоренность с Nekki о сотрудничестве и принялись за дело.
Пополнение команды
Нам очень хотелось сделать игру с необычным сюжетом. Вся команда фанатела от игры Journey и мечтала сделать что-то похожее — с глубоким философским сюжетом и «молчаливым» геймплеем. Мы взяли в команду нарративного дизайнера, который также занимался ещё и маркетингом в нашей команде.
Также мы поняли для себя, что понадобится программист с хорошим знанием Unity, поскольку очень много времени уходило на исследование движка и его возможностей. Предложений было много, но мы медлили с ответом. У многих ребят был хороший опыт в разработке, но нам хотелось найти человека, который был бы так же одержим игрой, как и мы.
В итоге, случайно наткнувшись на статью на Хабре, мы нашли человека, который в одиночку делает свою игру и разделяет наше видение дизайна: минимализм вплоть до цвета, необычный геймплей и отсутствие привычных для игрока элементов интерфейса. Удивительным было то, что концепт игры, описываемой в статье, оказался близок к изначальной идее OVIVO. И, недолго думая, мы связались с автором, а после предложили переехать в Санкт-Петербург и вместе делать наши игры.
Так команда из трёх превратилось в пять: программист, графический дизайнер, художник, нарративный дизайнер и геймдизайнер. Этим составом мы и решили сделать игру мечты.
Ошибка #1. Не стоит делать первой игрой игру мечты, если у вас нет опыта. Хочется сделать идеально, но без опыта очень трудно добиться желаемого результата. Из-за этого процесс разработки сильно затягивается и есть риск, что потеряется интерес к делу.
Начало разработки и генерация идей
Начать разработку мы решили с написания концепции всей игры и детального описания дизайн-документа. За шаблон документации взяли небезызвестную «Курочку Рябу».
Первые наброски для игры:
Концепт написали сразу, а диздок наполнялся по ходу разработки. В основном этим описанием занимались геймдизайнер и нарративщик, а в брейншторминге участвовала вся команда. С этого началась первая проблема — каждый хотел что-то придумать и добавить это в игру. В итоге на обсуждения уходило слишком много времени.
Мы решили как-то ограничить нашу фантазию и придумали, так сказать, трех «китов», на которых основывается игра и направляет генерацию идей в нужном направлении. Три правила, которыми мы руководствуемся и сейчас (для нас это стало некой мантрой):
1. В игре только два цвета: чёрный и белый.
2. Полное отсутствие какого-либо текста.
Это очень сильно помогло отсеять лишние идеи и повернуть мысли в нужном направлении. Так мы избавились от лишних механик, проблем с локализацией и четко определились с визуальным стилем игры.
Ошибка #2. Дизайн документ в виде текстового документа — абсолютно ненужная для небольшой команды вещь. Читать его никто не хочет, а процесс заполнения занимает много времени. Диздок — необходимый инструмент, но он должен быть удобен для прочтения и навигации, и очень важно содержать в нем чёткую структуру проекта. Для нас хорошей альтернативой стал способ ведения документации с помощью менеджера задач.
Организация работы
Когда концепт был написан и команде было дано общее видение игры, мы приступили к разработке. Изначально все роли были чётко распределены и, казалось, что каждый сам знает, что делать. Однако вскоре выяснилось, что некоторые задачи делаются излишне долго, команде не очевидна их приоритетность, а многие задачи приходится переделывать из-за несогласованности. К тому же Unity регулярно выпускала патчи, и команде нужно было быть постоянно в курсе обновлений.
В конце концов, мы пришли к тому, что диздок представляет собой набор задач в таск менеджере. И каждую неделю вместе выбираем какие задачи наиболее приоритетны и выкладываем их в другую доску, чтобы не путать со всем пулом задач. На их решение определяем дедлайны (обычно неделю), и если не укладываемся, то переносим нерешенные задачи на следующую неделю. Если задача слишком сложная или занимает много времени на решение, то забиваем на её.
Ошибка #3. К сожалению, в нашей команде не все смогли приучить себя к дедлайнам. А для некоторых корпоративные методы просто «неинтересные», чтобы их соблюдать.
Конференции
Была ещё одна большая польза от мероприятий — мы всегда шоукейсили игру и получали ценный фидбек непосредственно от игрока. Сначала мы скептически относились к шоукейсам, мол, время отнимает и нет особого в них смысла. Но когда тесты показали, что в игре полно пробелов, мы кардинально поменяли свое мнение.
Очень полезный навык, который мы выработали на шоукейсах — это молчать пока тестируют вашу игру. Без подсказок игрок проходит игру, как если бы получил её дома, и тем самым демонстрирует в каких моментах у него возникают проблемы. Ещё ценнее, когда игрок высказывает все свои мысли. Так мы поняли, что в игре большой уровень сложности, а многие элементы непонятны и требуют доработки. Поэтому мы решили упростить многие моменты, сделали более гладкую кривую сложности и добавили туториал (о том, сколько раз мы переделывали туториал, можно отдельную статью написать).
Ошибка #4. Не стоит злоупотреблять частыми выездами на конференции, поскольку это очень отвлекает от процесса разработки и отнимает немало времени на подготовку. Однако, не стоит разрабатывать игру в полной изоляции и бояться показать её на публике. Плейтесты очень важны практически на всех этапах создания игры — они дают возможность выбрать верный курс разработки. В идеале нужно научиться балансировать так, чтобы основные ресурсы тратились именно на разработку, но и не забывать о тестировании и общении с коллегами.
Долгая разработка и отказ от издательства
Изначально, после Imagine cup, мы договорились, что игра для нас станет обучающим проектом. Поэтому первое время мы изучали возможности Unity и по мере продвижения разработки придумывали улучшения для нашей игры. Кстати, вот так выглядел первый уровень игры во время Imagine Cup.
Мы несколько раз переписывали функциональную часть проекта, поскольку старые механизмы не соответствовали новым требованиям геймплея. Аналогично с графикой — использование растра слишком «грузило» проект. В нашем случае это было очень критично, поскольку вся игра была чёрно-белая. К тому же графика — это интерактивный элемент. Персонаж взаимодействует с каждым углом платформы, и нужно найти баланс в точности отрисовки графики и построения физических свойств.
В конце концов мы нашли способ — использовать в Unity векторную графику (об этом будет отдельная статья). Проект стал весить мегабайты вместо гигабайт, и это позволило без проблем создавать билды для мобильных платформ.
Сейчас первый уровень игры выглядит вот так.
Однако перелопачивание проекта и частые конференции привели к постоянным срывам сроков. Мы не успевали завершить свои задачи в том виде, в каком хотелось, и часто приходилось делать «заглушки» в игре. Для продвижения издателю были нужны видео-ролики, промо материалы, работа с сайтом и так далее. Времени на разработку приходилось уделять меньше, а жертвовать качеством игры очень не хотелось. В итоге мы решили отложить вопрос с издательством Nekki и сосредоточиться на разработке.
Ошибка #5. Качественное планирование и знание всех этапов разработки (от генерации идей до продвижения) на начальных этапах поможет сэкономить время в будущем.
Эпилог
За прошедшие два года мы многому научились, и, несмотря на множество ошибок и затянувшуюся разработку, мы всё равно получаем кайф от нашей работы. Нам очень нравится то, что мы делаем, и мы советуем всем, кто смотрит в сторону геймдева — пробовать.
Надеемся, что статья была вам полезна и с радостью ответим на ваши вопросы. Всем спасибо!
От хакатона до собственной студии разработки игр. Часть 1 / Microsoft corporate blog / Habr
Представляем новый цикл статей, посвященный разработке игр. В нём маленькая студия из Санкт-Петербурга расскажет о том, с чего началась их любовь к геймдеву, как они создали первую игру и стали победителями международного конкурса. Приглашаем вас под кат в увлекательную историю инди-разработчиков от первого лица.Цикл статей «GameDev с нуля»
1. От хакатона до собственной студии разработки игр: часть 1, часть 2.
2. Unity3D и векторная графика.
3. Как общаться с игроком без слов.
4. Как выйти из хаоса и начать работать.
Давайте знакомиться
Привет! Мы команда IzHard – маленькая студия разработки игр из Санкт-Петербурга. Мы работаем над двумя проектами OVIVO и coloristique. Любовь к геймдеву началась с простого участия в хакатоне от Microsoft более двух лет назад. С тех пор мы прошли длинный путь. Начинали с того, что не знали о разработке совершенно ничего, потом пришли на хакатон, сделали прототип игры OVIVO, с которой стали победителями в международном конкурсе Imagine Cup в 2015 году, получили грант и основали собственную студию по разработке игр.
За всё это время у нас накопилось немало опыта, которым мы хотим с вами поделиться. Первая статья из цикла будет полезна для тех, кто собирается участвовать в предстоящем Imagine Cup 2017. Расскажем, что, такое Imagine Cup, какие действия привели нас к победе и дадим несколько советов. В следующей статье мы расскажем уже о своей работе в студии: чем она отличается от разработки игры для конкурса, какие возникают проблемы у инди-разработчиков и как их решать.
Что же такое Imagine Cup
Это международный конкурс от Microsoft, направленный на развитие интереса к информационным технологиям среди молодёжи. Он проходит каждый год и принять участие в нём могут студенты, аспиранты и школьники старше 16 лет. Imagine Cup проводится в несколько этапов: в начале национальный этап – в каждой стране выбирают одного победителя, потом происходит онлайн отбор – выбирают лучшие проекты среди национальных призёров, и, наконец, финал, который проводится в Сиэтле, США, в штаб квартире Microsoft.
До 2017 года все проекты делились на три категории: инновации, социальные проекты, игры. С текущего же года все проекты проходят под одной категорией – инновации.
Суть конкурса – это презентация какой-нибудь крутой технологичной идеи. Команде предстоит разработать прототип, придумать бизнес-план и выступить с презентацией своего проекта перед судьями.
Оценивают по нескольким критериям: насколько ваш продукт эффективно использует новые технологии, в чём новизна проекта, будет ли он успешен на рынке и насколько идея актуальна. В итоге команде, занявшей первое место, Microsoft выделит денежный грант 100 000 долларов на развитие проекта.
Как это было в 2015 году
Наша команда впервые познакомилась на хакатоне в ноябре 2014 года. Это был наш первый хакатон, в котором мы и разработали прототип игры OVIVO. Радость победы была настолько воодушевляющей, что мы решили доработать проект, хотя бы до стадии маленького демо. В этот же период проходил набор участников на Imagine Cup, и мы, недолго думая, решили попробовать свои силы и принять участие.
Для того, чтобы попасть на национальный этап, необходимо было пройти региональный в Санкт-Петербурге. Во время подготовки мы думали, как сделать свою презентацию особенной, и решили сделать её в виде приложения на Unity. Поскольку игра была на этом же движке, то процесс геймплея не приходилось прерывать на показ слайдов. Эта задумка очень помогла нам заработать баллы на последующих этапах.
На национальном этапе мы тоже сделали презентацию на Unity, но более проработанную: сократили текст и сделали его более выразительным, пофиксили многие баги, да и просто уже меньше волновались, так как презентация была полностью отработана.
Подготовка к финалу стала серьёзным испытанием, поскольку в этот год мы заканчивали университет и команде приходилось тесно совмещать подготовку к конкурсу и дипломную работу. Поэтому мы выкладывались настолько, насколько позволяло свободное от учёбы время:
- Показывали проект каждую неделю сотрудникам Microsoft, журналистам, другим командам.
- Проигрывали различные ситуации, когда презентация могла пойти не по сценарию, учились правильно отвечать на провокационные вопросы.
- Зазубривали текст, поскольку английский у нас был не на высоте.
- Много работали над самим билдом игры. Сделали интересную фичу: игроки сами могли нарисовать фигуру фломастером, сфотографировать её и добавить в игру. Многим судьям она очень понравилась.
Это интервью до начала подготовки.
В итоге мы кардинально поменяли презентацию. Изначально в ней очень не хватало живости и вау-эффектов, а многие ключевые моменты мы просто упустили. Вместе с менторами из московского офиса Microsoft, Анастасией Макеенок и Дмитрием Сошниковым, мы придумали, например, трюк с разряженной батареей, который очень приятно удивил как жюри, так и публику (4:01).
Все эти старания не прошли даром – наша команда заняла первое место в категории Игры и мы получили грант от Microsoft на 50 000 долларов. Мы были безумно рады и почувствовали сильное облегчение, что всё это наконец закончилось.
Однако, как победителям, нам предстояло ещё побороться с другими призерами своих категорий за кубок Imagine Cup – победитель среди победителей, и для этого нужно было выступить перед многотысячной публикой с более короткой версией презентации. В жюри пригласили известных людей: Алекс Кипман – главный проектировщик контроллера Kinect, Йенс Бергенстен – ведущий разработчик Minecraft и Томас Миддлдитч – актёр сериала «Кремниевая долина».
Кубок мы не взяли, но всё равно очень счастливые, хотя и уставшие, в скором времени вернулись домой. И следующем нашим шагом стало создание студии, о котором расскажем в следующей части материала.
Советы для новичков
Imagine cup – это супер конкурс, который дает возможность испытать свою идею и самого себя. Для нас это было самым незабываемым приключением, которое поменяло нашу жизнь. Нам бы очень хотелось всем тем, кто ещё задумывается участвовать или нет, однозначно ответить — участвуйте! Регистрация сейчас открыта. Но нужно не забывать, что конкурс будет отнимать у вас очень много времени и сил. Мы бы хотели поделиться некоторыми советами и подсказками, которым следовали сами, надеемся, что они будут для вас полезны.
- В команду на конкурс старайтесь выбирать в первую очередь заинтересованных людей, даже если у них мало опыта. Больше шансов, что проект не бросят на полпути.
- Если в команде никто не знает английский, у вас меньше шансов попасть в финал, даже если вы прошли национальный отбор. К сожалению, это один важных критериев, несмотря на крутизну вашей идеи.
- Не бойтесь экспериментировать со своей презентацией. Старайтесь не следовать строгому шаблону.
- Не бойтесь перфомансов на выступлении, но и не слишком увлекайтесь.
- Делайте презентацию весёлой. Смех поможет вам расслабиться и не нервничать, а жюри отдохнуть от сухих фактов.
- Спокойно относитесь к вопросам типа: «А что, лучше нельзя было придумать?».
- Такого рода вопросы, просто используются, чтобы посмотреть на вашу реакцию.
- Уделяйте больше времени реализации вашей идеи. Она сама по себе может стать отличной презентацией.
- Залог отличной презентации – репетиция, репетиция, репетиция.
- Посмотрите выступление Brainy Studio – победителей в 2014 году. Это отличный пример.
- Дополнительно можно почитать их блог «Советы бывалых», многим из них мы следовали при подготовке.
Надеемся, что эта статья была для вас полезной и интересной.
GameDev как хобби / Habr
Работая в программистом в области никак не связанной с играми я вдруг решил написать мобильную игру. Не зная ни инструментов, ни технологий и специфики разработки. Какой она получилась? Какие выводы я для себя сделал и может ли геймдев быть хобби – всё под катом.Краткая предыстория
Некоторое время назад у меня возникла идея: «А не написать ли компьютерную игру?» Думаю, что такая мысль приходит почти к любому программисту. Все мы, когда только начинаем изучать профессию, грезим созданием новых World Of Warcraft’ов, Counter Strike’ов или, как минимум, «Веселых ферм». Но потом школьно-студенческие годы заканчиваются и мы начинаем писать то, за что платят.
Первую и единственную свою игру я написал на Delphi лет десять назад, когда только изучал программирование. Это был убогий клон вертикальных слайдеров-стрелялок, который дико глючил и тормозил. Я понял, что для разработки чего-то путного нужно не только желание, но и немалые знания в области работы с графикой, и что при разработке «интересное программирование» займет десять процентов времени, а остальное уйдет на решение совсем не романтических технических проблем. Поэтому идею написания игр я забросил еще до ВУЗа и на сегодняшний день уже пять лет счастливо работаю в области интеграции корпоративных систем.
Однако, пару месяцев назад мне захотелось написать что-нибудь «для души». К тому же стремительно развитие мобильных приложений вызывает ощущение, что рядом происходит что-то очень интересное, но без меня. «Не порядок!» — решил я и кинулся копать в сторону разработки мобильных игрушек.
И вот тут начинается самое интересное…
Во-первых, очень радует обилие различных готовых движков. Причем бесплатных и простых в освоении.
Во-вторых, куча маркетов и сайтов с приложениями, где можно честно делиться своими трудами.
В-третьих – множество статей, уроков, туториалов и т.д. и т.п. Одних статей на Хабре вполне хватает, чтобы получить представление о технологиях и инструментах.
Так что решение было однозначным – делать!
А что делать?
Первые четыре-пять идей-прототипов были безжалостно выкинуты или отложены до лучших времен.
Причины самые разные: некоторые были слишком сложными в разработке, некоторые оказывались плохими клонами существующих продуктов, некоторые банально требовали большого объема работы по созданию контента.
Тогда я сел и решил сформулировать требования к будущей игре.
- Она должна обладать ярким и приятным интерфейсом. Времена плохо прорисованных flash игр давно прошли, если когда-то вообще наступали.
- Игра должна обладать простым геймплеем. Это было продиктовано ограниченностью ресурсов – писать что-то серьезное не было ни сил, ни времени. К тому же корреляция между сложностью игры и ее популярностью весьма сомнительна. Привет злым птичкам!
- Управление должно быть максимально простым. Это мой личный взгляд на мобильные игры. Терпеть не могу те, где нужно тыкать пальцами по десятку маленьких экранных кнопок, либо крутить телефон как руль. Просто личные предпочтения.
В итоге остановился на следующей концепции: Мяч прыгает по платформам. Задача – «допрыгать» до финиша и не упасть. Управление – одним пальцем. Коснулся, потянул, отпустил. Никаких кнопок или других элементов управления, кроме меню.
В качестве движка был выбран Unity3d. Во-первых, по нему много информации, во-вторых, с 3d я дружу гораздо лучше, чем с 2d. Сделать простенькие модельки и собрать из них уровни показалось куда проще, чем пытаться нарисовать «кривыми» руками красивые спрайты.
Итак, цель ясна, поехали!
Первые проблемы
Первое, чего не хватало – контент. Даже самая проста игра – это не только функции и классы, но и модели, текстуры, звуки. Программисты редко бывают художниками. Музыкантами – еще реже. А и тем, и другим, и третьим – почти никогда.
Контент нужно было либо искать на стоках, либо заказывать у специалистов, либо делать самому. Платные стоки и индивидуальный заказ отпали сразу – речь шла не о коммерческом приложении, и вкладывать в него деньги не было смысла. На бесплатных стоках найти что-то путное не получалось – процесс поиска напоминал копание в большой урне, куда выбросили все, что было под рукой.
Остался последний вариант – делать все самому. В итоге от чего-то пришлось отказаться, как, например, от фоновой музыки. Зато я получил массу удовольствия от изучения 3d инструментов. Самым крутым оказался 3d Studio Max. Жаль, что время его тестового использования ограничено одним месяцем. Если вдруг займусь этой областью профессионально – обязательно куплю. А так вполне выручает бесплатный Blender.
Со звуками тоже оказалось не сложно – несколько коротких звуковых эффектов на падение мяча, «сбор» звездочек и завершение уровня были сделаны с помощью бесплатного Audacity. Можно было сделать и больше и лучше, но тут проблема не в инструменте, а в навыках.
Второй проблемой стала архитектура приложения. Описать классы и их назначение – это не беда, а вот склеить их как-то с Unity, который я на момент начала разработки открыл в первый раз – гораздо сложнее. Как собрать весь этот зоопарк в кучу, когда возможности инструмента узнаешь по ходу разработки? Переписать все с начала и по-человечески хотелось через каждые несколько часов разработки. Постоянно узнавал что-то новое и старое решение казалось идиотским.
Очень быстро пришло осознание того, что если гнаться за качеством кода, то игра не будет сделана никогда. В итоге продумывались только те моменты, которые реально влияли на разработку и использовались во многих местах – десяток префабов с подвешенными на них скриптами-контроллерами. Остальное – хардкод и анархия.
Кажется, что я использовал все антипаттерны, которые только есть – хардкод, копипастинг и т.д. Ни в коем случае не призываю так делать, но не могу не обратить внимание на то, что это позволило сократить время разработки раза в три. На выходе – работающая игра и отвратительный код, который никто никогда не увидит.
Еще одной бедой игр, о которой я никогда не задумывался оказался баланс. Даже в моей мини-игре сложность уровней должна была постепенно возрастать. Причем не только размер, а именно сложность. Пропорционально должны были возрастать начисляемые за прохождение очки.
Первый вариант игры оказался мега-хардкорным, хотя я его проходил без проблем и думал, что все в порядке. Но «альфа-тестирование» с помощью близких людей показало, что игра непроходима если не ты сам ее писал.
Пришлось многое упрощать, оптимизировать, добавлять «страховочные» элементы, не позволяющие провалить уровень в одном прыжке от финиша.
После изменений «поплыли» коэффициенты очков. Т.к. они рассчитываются с учетом времени прохождения, то за первые уровни начислялось больше, чем за последние.
Чтобы выправить баланс пришлось пройти игру десятки раз. И все равно создать линейное возрастание сложности не удалось.
И напоследок массу эмоций доставило создание иконки. Все уперлось в неумение рисовать и незнание того, какими они вообще должны быть. В итоге получилось чудо переполненное фотошопными «артефактами». Не самый лучший вариант, но на большее не хватила сил. Просто не ожидал, что это окажется нетривиальной задачей.
Доработка напильником
После того, как были сделаны первые шаги и запущен первый уровень, я составил список того, что нужно добавить в игру перед тем, как ее выпускать. Список получился длинным.
Первые же пункты показали, что если делать всё, то игра выйдет месяца через три-четыре. Учитывая, что все делалось на энтузиазме – не вариант. Я прекрасно понимал, что чем дольше будет длиться разработка, чем больше будет возникать «затыков», тем меньше шансов, что я вообще что-то сделаю. Разработка должна была пройти быстро, на одном запале. Фактически – в один спринт, если бы речь шла о скраме.
В итоге было решено игру ужать.
От чего отказался:
- Фоновая музыка. Найти хорошую и бесплатную не удалось, писать свою не умею, покупать чужую – не вариант. А воровать – не хорошо и аморально.
- Количество уровней сократилось с 25 до 15.
- Вместо многослойного задника с эффектом перспективы были вставлены абстрактные облачка.
- Не реализована интеграция с социальными сетями. Очень хотелось сделать страницу в facebook и хотя бы кнопку Like в самом приложении, но не хватило времени.
- Глобальный рейтинг. Планировал показывать не только достижения самого игрока, но и лучшие среди все и лучшие среди его друзей в facebook. Аналогично, времени не хватило.
- Реклама в приложении. Хотелось чуть-чуть компенсировать себе деньгами потраченное время. Но возникли проблемы с admob, и встал вопрос – либо ничего не заработать, либо сильно затянуть выпуск. Решил, что уж лучше выпустить совсем бесплатно, а себя наградить полученным опытом.
Это только те пункты, которые были записаны и о которых я реально жалею. Общее количество нереализованных «хотелок» не перечесть.
Итоги
- Игра выпущена и опубликована в Google Play.
- Продолжительность разработки от идеи до релиза – чуть больше 2-х месяцев.
- Время потраченное на разработку – около 60 часов. Очень примерно, т.к. бОльшая часть времени ушла на изучение неизвестных ранее технологий. А еще на тестирование и выравнивание баланса.
- Денежная стоимость разработки – 25 долларов за аккаунт разработчика в Google Play.
Win!
Выводы
Для себя я сделал несколько выводов, которыми с радостью поделюсь.
- Современная разработка мобильных мини-игр – это больше работа художника, чем программиста. Для программной реализации достаточно самых базовых представления о разработке. Конечно, если делается большой и качественный продукт с коммерческой целью – все совсем по-другому. Но написать казуальную стрелялку-бродилку-леталку-прыгалку сейчас не представляет никакой проблемы. Было бы желание.
- Идеал недостижим. Если стремиться вложить в свою первую игру все, что хочется, то она никогда не будет сделана. Лучше сделать что-то простое и приятное, чем ничего.
- Не нужно бояться нарушить правила разработки. «Грязный» код – это, конечно, плохо. Но пользователь его никогда не увидит. И вы тоже, если не собираетесь развивать вашу игру. А делать что-то в первый раз и надеяться на развитие – это наивно. Код небольшой игры легко держать в голове и вполне можно пренебречь его чистотой, если это ускорит выход.
- Лучшая мотивация – скорый релиз. Если он переносится на неопределенный срок из-за каких-то проблем, то желание что-то делать тает на глазах. Поэтому все «тормозящие» проблемы нужно решать как можно быстрее. Идеальный инструмент для самомотивации – лист бумаги на который выписано все, что нужно сделать для релиза. Если что-то оказывается слишком сложным и необязательным – оно вычеркивается и больше к нему не следует возвращаться.
- Первая игра должна быть такой, в какую самому хотелось бы сыграть. Вряд ли она «выстрелит» и взорвет рейтинги магазинов приложений. Но ее будет приятно разрабатывать и ею захочется поделиться с окружающими. А для хобби это самое главное.
И последние, совсем личные впечатления.
Делать игру – это интересно. Иногда даже более интересно, чем играть в нее. В отличии от работы в команде над крупным проектом это дает маленькую радость личной победы. Выпуск продукта на работе – это норма, там все понятно, в этом не ничего необычного. А вот такие мини-игры позволяют пережить ту радость, которую мы испытывали при запуске наших первых программ. Когда вокруг ворох неизвестных технологий, все новое, непонятное, а тут: О-па! Оно заработало!
Впечатления от разработки остались самые приятные. Так что — Play game!
Буду рад, если кто-нибудь поделится своим опытом «непрофессиональной» разработки игр.
Как научиться делать игры: полезные ресурсы / Habr
Когда я начинал строить свою карьеру в игровой индустрии шесть лет назад, то часто задавался вопросами по геймдеву. Начиная от поиска общего понимания того, как разрабатываются и оперируются онлайн-игры, до частных вопросов типа того, как лучше рекламировать конкретную игру. Тогда было мало структурированной информации по созданию и продвижению игр, новичку разобраться и найти ответы было исключительно сложно. Практически единственным источником информации был собственный опыт и консультации более опытных коллег. Сейчас ситуация кардинально изменилась. Информации по игровой индустрии настолько много, что рискуешь в ней просто утонуть. Для того, чтобы упростить процесс получения нужных мне знаний, я структурировал и делал себе пометки по всем источникам информации о геймдеве. Далее в статье предлагаю всю эту информацию в удобной форме для общего пользования.Специализированные интернет-ресурсы всегда были одним из самых простых способов получения информации. Если не нашел нужную статью, то всегда можно спросить на форуме или в комментариях к постам на близкую тему. И даже есть шанс получить ответ!
Под спойлером вы найдете таблицу, в которой я перечислил самые популярные российские ресурсы по геймдеву с краткими личными пометками по каждому.Список геймдев-ресурсов
| Ресурсы про геймдев | Пометки |
|---|---|
| habrahabr.ru | Сама эта статья опубликована на Хабре J На Хабре и его «младших братьях» можно найти статьи как по разработке/оперированию игр, так и по индустрии в целом. |
| gamesisart.ru | Мой любимый геймдев-ресурс. Статей меньше, чем на других порталах, но берет качеством, а не количеством. Ряд статей оттуда мне очень помогли в работе. |
| vc.ru/paper/category/games | Колонка рынка игр на ЦП появилась недавно относительно других ресурсов, но быстро стала модной. Мне она удобна тем, что есть приложение для iOS, через него и читаю. |
| dtf.ru | Еще несколько лет назад был ключевым интернет-ресурсом получения знаний по геймдеву. Прекрасный сайт, жаль, что сейчас его забросили. |
| www.gamedev.ru | Мастодонт среди ресурсов по геймдеву. Старый, но не бесполезный. |
| gcup.ru | Тоже один из древнейших и крупнейших порталов по игрострою с уклоном в программирование. |
| galyonkin.com | Подкасты Сергея Галенкина. Самые популярные подкасты по игровой индустрии. |
| igdc.ru | Конкурсы молодых разработчиков игр и сильно живой форум для общения. |
| progamedev.net | Блог Александра Штаченко про геймдев. Регулярно обновляется, материалы интересные. |
| aushestov.ru | Качественный блог про геймдизайн от Анатолия Шестова. |
| www.progamer.ru/dev | Есть хорошие статьи по геймдеву. |
| gameinstitute.ru | Сайт с упором на публикацию уроков по разработке игр. Давно не обновляется, но есть много интересных старых статей. |
| make-games.ru | Портал с сильным уклоном в программирование и разные конструкторы игр. |
| flashgamedev.ru | Странненькое место. Не сижу там. |
| www.ant-karlov.ru | Авторский блог разработчика Flash игр. |
| mmozg.net | Место обсуждения MMO. |
| narratorika.com | Для игровых сценаристов. |
| romanilyin.com/category/storytelling | @Grisper «тут ещё немного есть по нарративному дизайну» |
| dogames.ru | Не полезный ресурс. |
| www.gamedis.ru | Блог про геймдизайн. Новые посты изредка. |
| www.uraldev.ru | Спасибо за ссылку на ресурс Msviblov Интересный ресурс Уральских разработчиков игр. Жаль давно не обновляется |
| torick.ru | Спасибо за ссылку на ресурс Msviblov Необычный блог с текстовым описанием различных подкастов по геймдеву |
| upd. от 16.04 gamesjam.org | Ресурс, где публикуется информация обо всех интересных мероприятиях в геймдеве. И просто площадка для общения с единомышленниками. |
| upd. от 16.04 empathybox.me/ru | Коллективный блог про теорию геймдизайна и культуру разработки игр |
| upd. от 16.04 core-rpg.net | Cайт о разработке компьютерных RPG |
| upd. от 16.04 gamedevblogs.ru | Просто много блогов инди-разработчиков. Что-то типа жж для игровых девелоперов. |
| upd. от 16.04 fasterthanthere.blogspot.ru | «Описание создания видеоигр и разные мысли вокруг да около…» в блоговом формате. |
| upd. от 16.04 tiendil.org | Блог «про разработку ПО, геймдев и прочие радости жизни». |
| upd. от 16.04 gopractice.ru | Блог про аналитику и маркетинг мобильных приложений |
| upd. от 16.04 warnworld.com | Авторский ресурс геймдизайнера Ильи Туменко «о разработке игр: гейм-дизайн, мобильные рынки, игровая индустрия и всякое такое». |
| upd. от 16.04 leaden.ru/language/ru | Блог о геймдизайне Ярослава Кравцова — соавтора Message Quest. В копилке у Ярослава, помимо этой игры, — работа над Skyforge, «Аллодами Онлайн» и Armored Warfare. |
| upd. от 16.04 Манжеты Гейм-дизайнера | Слоган сайта: «Как не умереть от ужаса в первый и все последующие рабочие дни на позиции гейм-дизайнера». |
| Ресурсы про геймдев с акцентом на мобильных разработках | Пометки |
| indiedev.name | Хороший информационный ресурс для тех, кто занимается продвижением мобильных игр. Одна база издателей и сайтов для продвижения мобилок чего стоит. |
| app2top.ru | Отличный ресурс про мобильные разработки. |
| apptractor.ru | Еще один классный ресурс про мобильные разработки. |
| apps4all.ru | И тоже про мобильные разработки, и тоже шикарный. |
Так повелось, что площадкой для тусовки людей из игровой индустрии стал именно Facebook. Во Вконтакте и в LinkedIn тоже есть gamedev-сообщества, но они менее «тусовочны». Поэтому здесь приведу ссылки именно на группы в FB.Русскоязычные группы Facebook по геймдеву
Русскоязычной геймдев-литературы немного – всего пара книг по маркетингу в играх от русских авторов и несколько переводов самых известных иностранных книг по геймдизайну. Стоит отметить, что англоязычной литературы очень много и большинство людей из геймдева читает ее в оригинале. Мы сегодня говорим только о русскоязычных ресурсах, поэтому под спойлером представляю вашему вниманию книги на русском языке.Книги по геймдеву
| Наименование книги | Автор книги | Ссылка на книгу |
|---|---|---|
| Первая русская книга по геймдеву: «Маркетинг игр» | Сергей Галенкин | galyonkin.com/book |
| Вторая русская книга по геймдеву: «Качай деньги! Маркетинг мобильных игр и приложений» | Анар Бабаев, Николай Евдокимов, Михаил Боде, Юрий Барбашов | adtoapp.com/book/mobile-app-marketing |
| The Art of Game Design: A book of lenses | Jesse Schell | Перевод тут и тут |
| Level Up! The Guide to Great Video Game Design | Scott Rojers | Перевод тут |
| Designing Virtual Worlds | Richard Bartle | Перевод делается на Хабре |
| upd. от 14.10 Проектирование и архитектура игр | Э. Роллингз, Д. Моррис | Перевод тут |
Еще одним способом обрести новые знания, а самое главное новые знакомства в игровой индустрии, является участие в профильных мероприятиях: конференции, выставки, конкурсы. К самым известным относятся DevGAMM, White Nights, раньше еще КРИ была. Но это только вершина айсберга. Существует множество других профильных мероприятий, постоянно появляются новые. Чтобы за всеми ними уследит и понять, на какие именно вам будет полезно сходить, я подготовил список каталогов таких мероприятий.Календари мероприятий по геймдеву
| Ресурс | Пометки |
|---|---|
| gcup.ru/news/meroprijatija/1-0-4 | На gcup организаторы мероприятий сами публикуют анонсы. Можно откопать интересные мероприятия, о которых в других местах и не услышишь. |
| app2top.ru/category/conferences/calendar_news | Современный и удобный каталог конференций. |
| apptractor.ru/events | Календарь мероприятий для мобильных разработчиков. |
| apps4all.ru/event | И тоже хороший календарь. |
Описанное выше является по сути самообразованием. А есть еще и комплексное профессиональное образование в сфере геймдизайна и менеджмента игровых интернет проектов. На текущий момент в Москве есть три учебных заведения, которые предоставляют такие услуги: RealTime School, Scream School и Высшая школа бизнес-информатики Национального исследовательского университета Высшая школа экономики (ВШБИ). Традиционно под спойлером мои пометки про образование в этих местах.Образовательные программы по геймдеву
| Учебное заведение | Пометки |
|---|---|
| RealTime School | Хорошие короткие интенсивы на выходных по геймдизайну. Проходят примерно раз в квартал. |
| Scream School | Самые долгие и самые дорогие из всех курсы геймдизайна. Насколько они хороши сам не знаю, отзывов лично от знакомых не слышал. |
| ВШБИ | Лучшая на мой взгляд комплексная программа подготовки кадров для игровой индустрии. Плотно общался с выпускниками, все очень довольны и либо трудоустроились в игровые компании, либо свои проекты запускают. |
На этом заканчиваю обзор полезных ресурсов о том, как научиться делать игры. Если есть что дополнить в мои списки, то пишите в комментариях – я с удовольствием добавлю в статью с пометкой upd и ссылкой на автора материала.
Upd от patch2.
unitywiki.com/page-27-download-free-3d-models
unitywiki.com/page-28-download-free-textures
telias.free.fr
Подборочка сайтов с музыкой для игры (Purchase stock audio. You can purchase royalty-free stock audio from the following sites:
arteriamusic.com
audiojungle.net
beatsuite.com
firstcom.com
ibaudio.com
instantroyaltyfreemusic.com
istockaudio.com
magnatune.com
partnersinrhyme.com
revostock.com
sounddogs.com
soundeffects.com
soundrangers.com
soundsnap.com
stockmusic.net
tallarico.com
8bitcollective.com
ccmixter.org
flashkit.com
freesound.org
hartwigmedia.com
incompetech.com
musopen.com
newgrounds.com
openmusicarchive.org
openmusic.linuxtag.org
indiegamemusic.com
Маркет для 3D Models
Лицензированный контент:
turbosquid.com/ 3D Модели и текстуры, пожалуй самый
большой ресурс.
opengameart.org 3D Models, Textures, Sound Fx,
3dexport.com Buy 3D Models, Sell 3D Models, Low-Poly 3D Models, 3D
Print Models
www.the3dstudio.com 3D Models, Текстуры, 3D Уроки
www.daz3d.com
www.cgtrader.com
В основном для ознакомления, «Пиратские ресурсы»:
www.designconnected.com 3D Models
archive3d.net
www.3dmodelfree.com
www.3dm3.com
tf3dm.com
www.sweethome3d.com
www.freebie3d.com
artist-3d.com
www.exchange3d.com
3dgarage.ru
www.wirecase.com 3D Models, Textures, Interior and Exterior
animium.com Free 3D Models and 3D Tutorials
www.dmi-3d.net DMI Car 3D Models
www.onnovanbraam.com
www.carbodydesign.com
www.syncronia.com Architecture 3d models and instruments for design
architecture.
www.gandoza.com 3D Models, 3D Modeling, Textures and Rendering on
Gandoza
archibaseplanet.com Home Design, Free 3D models, High Quality Textures,
Online Interior Design.
3dmagicmodels.com 3D Model Services
Asset Store for Unity3d
www.unityprefabs.com
unity3d-asset.ru
Текстуры
www.gametextures.com
Программы помогающие при разработке
www.filterforge.com — Плагин для фотошопа для генерации
текстур. Процедурные текстуры.
www.allegorithmic.com Программы
для работы с текстурами: диффуза, бампа, карт АО и т.д
www.codeandweb.com/texturepacker — Упаковывает текстуры в атлас
www.world-machine.com —
Процедурный генератор ландшафтов World Machine
www.quadsoftware.com —
Grоme Editor — Простое создание больших ландшафтов
Текстуры, Модели Анимации — Порталы
3dsky.org Models Textures
mocap.cs.cmu.edu Mocap Free Animation
mocapdata.com/index.cgi?category_id=19053
sites.google.com/a/cgspeed.com/cgspeed/motion…
accad.osu.edu/researchmain/research/motion_cap…
gfx-motion-capture.blogspot.co.uk
charactergenerator.autodesk.com — Генератор персонажей. Спасибо Тариэл Фарниев
Фриварные инструменты для разработчиков:
www.blender.org — Blender3D, Unity понимает его формат
«нативно», экспортировать не обязательно
www.gimp.org — GIMP, бесплатный растровый редактор; на аналог Photoshop не тянет, удобство использования — вечный повод для холиваров, но есть ряд интересных функций специально для создания цикличных (бесшовных) текстур, например. С помощью плагина позволяет генерировать Normal Map из любого изображения.
www.inkscape.org —
Inkscape, бесплатный векторный редактор. Blender позволяет импортировать его
SVG-файлы в виде Curves.
www.makehuman.org —
бесплатный генератор человеческих фигур с ригом.
ngplant.sourceforge.net — NGplant, конструктор для
растительности. Полигональность и визуальная привлекательность получившегося
изображения зависит главным образом от прямизны рук. Не SpeedTree, конечно
(рига нет), но весьма неплохо для статики.
3dlowpolymodels.com
tf3dm.com
www.models-resource.com
gamemodels.ru
Для 2D разработчиков! Иконки, спрайты и многое
другое.
60+ полезных сайтов для дизайнера.
www.adme.ru/tvorchestvo-dizajn/60-poleznyh-instrumentov-i-resursov-dlya-dizajnerov-873510
Звуки
diforb.com/ru
Полезный Ютюб канал, переводит оффицальные
видеоуроки по юнити на русский язык
www.youtube.com/channel/UCtpgnWrMynRl869Snx52n6w
Список книг по GameDev gcup.ru/forum/8-41920-1, книга по шейдерам в юнити > на англu3d.at.ua/load/free_to_use/kenny_lammers_unity_shaders_and_effects_cookbook_format_pdf/37-1-0-2754, на русском вроде только бумажный вариант) никто ксерокопию не сделает)) в документах этой группы есть книги по GameDev и Unity ссылка
Upd от Kallist Msviblov GreatRash andreysmind
Upd от Наташа Свиридова
www.youtube.com/channel/UCnz7plM_g7zctL2N7-u3W_Q (Русскоязычный канал Unity, где проводят вебинары и выкладывают интересные выступления по Unity с русскоязычных конференций)
Upd от afiskon
Как попасть в геймдев и стать востребованным специалистом. Часть 1
Каждый профессионал, работающий в топовой игровой компании, был когда-то новичком и тоже искал работу, иногда не без трудностей. Считается, что начинающему специалисту очень сложно получить место в солидной студии из-за небольшого опыта, а также высокой конкуренции со стороны матерых профи геймдева. Так ли это на самом деле? Михаил Шеметун, один из креативных директоров студии Plarium, поделился мыслями по этому поводу, рассказал о своем опыте и дал несколько полезных советов молодым специалистам.Миша, расскажи немного о себе. С чего начался твой путь в игровой индустрии?
До Plarium я четыре года управлял дизайнерской студией и десять лет занимался рекламой. В 2010 году, после очередной волны кризиса и нестабильности в стране, понял, что руководить студией в том виде, в каком она существовала на тот момент, бесперспективно. К тому времени я уже около двух лет занимался игростроем как хобби и решил, что если найду работу, связанную с геймдевом, в своем городе, то останусь, если нет — уеду в Москву. Там мне предлагали хорошую должность за неплохие деньги. С такими мыслями я вышел на Plarium, получил тестовое задание, справился с ним и начал работать 2D-художником. В нашей компании я начал совершенствовать свои навыки: учился, наблюдал и анализировал организацию процессов. Учитывая мой управленческий опыт, через семь месяцев мне доверили руководить частью одного из наших проектов, а спустя несколько лет и проектов я занял место креативного директора.
Теперь перейдем непосредственно к нашей теме. Какие специальности сейчас востребованы в игровых студиях?
Начнем с того, что профессий очень много. Это аниматоры, текстурщики, иконщики, концептеры, технические художники. Многие, насмотревшись работ на ArtStation, хотят быть концептерами, не пройдя при этом предварительной подготовки. Если вы умеете рисовать, то это еще не значит, что вы концепт-художник: в этой области нужно быть еще и дизайнером. Человек, который не работал несколько лет в индустрии цифровой графики, вряд ли отличит иллюстрацию от хорошего концепт-арта. Это интересная работа, но не для всех: в ней очень много рутины и специфических технических требований.
Вы должны быть готовы к тому, что не всегда будете рисовать то, что хотите, например, красивый парусник при свете луны. Вам, возможно, придется изображать коричневый стол в комнате или простого крестьянина. Можно сказать, что концепт-арт — отдельное подразделение, где не столь важно уметь рисовать, как показывать и объяснять. Ваши идеи должны быть предельно ясны моделлерам и другим специалистам, которые будут их реализовывать. Если вы создаете персонажа в костюме со всевозможными ремешками, вы должны объяснить, для чего и почему они были использованы.
И все же, что ты можешь посоветовать ребятам, которые мечтают работать в сфере концепт-арта?
Я рекомендую в начале пути позиционировать себя как 2D-художника или иллюстратора. Хороший 2D-художник должен отлично понимать текстуры, свет, грамотно работать в Adobe Photoshop с масками, цветокоррекцией, ориентироваться в стилях и умело использовать стилизацию. Могу сказать, что всегда не хватает иконщиков. Отрисовка иконок — очень хорошая практика по рендеру текстур, материалов, пониманию формы, света и цвета. Также можно попробовать себя в текстурировании 3D-моделей. Начните с малого: рисуйте иконки, интерфейсы, подложки, не пренебрегайте этим этапом. Читайте теорию и историю концепт-дизайна шестидесятых годов: полезно изучать творчество того периода, где не было графических программ, а все создавалось исключительно руками.
А если человек интересуется анимацией и 3D-моделированием?
Чтобы быть аниматором, мало уметь работать с Maya и знать основные принципы риггинга. Нужно чувствовать динамику, скорость, инерцию, изучать классику анимации для реалистичной передачи движений. Хорошей анимации веришь. Если вашей анимации не верят, значит, она не годится. Анализируйте проекты лучших анимационных студий, например, Pixar и Disney, используйте их работы в качестве референсов и стремитесь к такому же высокому уровню.
Что касается 3D-художников, то они должны разбираться в скульптинге, лепке, умело пользоваться программами, в которых собирается та или иная модель. В этой сфере очень помогают знания инженерного дела, архитектуры, сопромата, понимание чертежей, моделей и механизмов, а также конструкторские навыки. Смотрите профильные форумы, анализируйте работы на ArtStation и постарайтесь сделать так же или лучше. Прежде всего нужно упорно учиться и совершенствовать себя, не важно, студент вы или уже работаете.
Как компания поощряет развитие своих сотрудников?
Если человек хорошо проявил себя в своей области, то ему всегда дадут возможность попробовать что-нибудь еще, но тогда он должен включить режим новичка и активно впитывать информацию, чтобы стать лучшим. Объединяя опыт и знания из нескольких областей, вы можете вырасти и стать очень востребованным специалистом. Сейчас мы стремимся к тому, чтобы создавать специализации. У нас есть визуализаторы, моделлеры персонажей и техники, текстурщики и так далее — все они работают полный день над своими задачами и становятся лучшими в своей сфере.
Каким должен быть потенциальный кандидат, который стремится получить работу в студии?
Часто бывает, что люди на собеседовании не могут ответить на вопросы о том, кем они хотят быть, что делать, чем могут быть полезными студии. Человек должен четко позиционировать себя. Если кандидат говорит, что он может делать все: рисовать персонажей, иконки, моделить технику, анимировать, значит, у такого человека, скорее всего, нет ярко выраженной сильной стороны. Каждый наш работник в чем-то очень силен, у кого-то таких качеств несколько, а у кого-то только одно, но оно есть. Например, вы можете создавать превосходных персонажей, разбираться в анатомии, но вам ничего не мешает рисовать и архитектуру.
Какие качества необходимы новичку, чтобы быстрее развиваться?
Прежде всего желание работать: под этим я понимаю развитие себя в выбранной области. Стремление устроиться в крутую студию и нежелание что-либо делать для этого обречены на провал. Если же вы с утра до вечера рисуете, моделите, занимаетесь самообразованием и стремитесь стать лучшим, то велика вероятность, что вас заметят и пригласят на работу. К примеру, вы увидели картинку, вдохновились — идите рисуйте. Если же вы вместо этого садитесь пить кофе и играть в любимую игру, то ничего не получится. Работать нужно изо дня в день. Чем больше вы занимаетесь, тем качественнее выполняете свою работу.
Более того, нужно понимать, что вы из себя представляете как специалист. Составьте о себе мнение не со слов родственников и друзей, которые всегда говорят, что вы лучший. Самооценка должна быть объективной — не завышенной и не заниженной. Так вышло, что современный мир внушает каждому человеку, что он неимоверно талантлив. Нам постоянно говорят об этом родители, твердят реклама и телевидение. Люди впитывают эту информацию и могут переоценивать свои возможности. К нам часто обращаются соискатели со слабыми знаниями и верой, что они все умеют. Однако просмотр портфолио все расставляет по своим местам, и мы видим реальный уровень навыков кандидата.
Еще очень важно определить свою цель: осознавать, куда идешь, какие качества в себе развиваешь. Работать в большой студии — это не цель. Целью может быть создание крутого концепт-арта персонажей за определенное количество часов, рисование персонажей или окружения для конкретного AAA-проекта, стремление к уровню любимого художника.
Какими навыками должен обладать начинающий специалист?
Конечно, необходимы базовые художественные знания. Их наличие — огромный плюс. Чтобы быть хорошим художником по персонажам, мало уметь работать в Adobe Photoshop. Лучше вернуться назад к страшным скучным учебникам по анатомии, цвету, композиции, порисовать примитивы. Как бы не хотелось, но перепрыгнуть это нельзя. В будущем, когда начнете позиционировать себя как профессионала, вы провалитесь, ведь чем выше ваш уровень, тем тоньше лед, по которому вы ступаете.
В начале еще можно позволить себе много ошибок, так как от вас другого и не ждут, но чем дальше вы идете, тем выше риски, и если вы не знаете элементарных вещей, например, по поводу акцентов в композиции, отделения цветом одного от другого, то потерпите неудачу. База важна, потому что формирует чувство вкуса, понимание баланса, вы изящнее выполняете свою работу и становитесь человеком, который может что угодно сделать красивым. Если вы художник, то у вас есть особенное восприятие: вы можете интересно расположить даже три обычных шарика на столе или три стула в комнате.
Также следует понимать, какие навыки вы развиваете и для чего, а программы должны быть лишь инструментами для претворения в жизнь ваших замыслов. Новичок должен обладать базовыми знаниями, мы не будем рассказывать, как делать ретопологию, настраивать материалы или выстраивать перспективу. В студии вас направят, помогут развить навыки и структурировать полученные знания, но не будут учить с нуля.
Стоит ли начинать карьеру в игровой индустрии после 25-27 лет?
Я бы не рекомендовал кардинально менять сферу своей деятельности. Объясню свою позицию: человек развивается циклично, и некоторые качества, которые сильны в молодости, с возрастом сменяются другими. Молодые быстро осваивают новые знания, легко принимают критику, могут переключаться с одной задачи на другую. Чем больше жизненного опыта накапливается у человека, тем критичнее он относится к другим людям и меньше заглядывает в себя.
Если же вы решили стать, например, 2D-художником, то рисуйте, чтобы руки горели, и только через несколько лет у вас появится шанс стать профессионалом. Такой переворот легко сделать в двадцать лет, а вот в двадцать семь, когда есть семья, дети и различные обязательства, сложно. Конечно, если вы готовы все бросить и вести образ жизни студента, рисовать с утра до ночи и упорно работать, то тогда это возможно. Может быть, вам придется несколько лет поработать с разовыми заказами, обрести уважение среди фрилансеров, после чего у вас появится перспектива получить постоянную работу.
Это только первая часть большого интервью. Во второй части Михаил расскажет, как выигрышно оформить портфолио и резюме, а также даст практические советы по выполнению тестового задания.
Game Development: начало пути / Habr
Многие думают — хочу делать игры! Вроде и идей у меня куча (правда скорее всего никак не оформленных), и в других играх я все недочёты вижу с первого взгляда и мысли свои излагать могу связно и последовательно, но… Чего-то не хватает! Что именно делать, если хочешь попробовать себя на ниве игростроя? Пути вроде всего два: делать игры в составе какого-нибудь профессионального коллектива или делать игры самому. Но даже беглый обзор в моём регионе (Санкт-Петербург) показал, что такой позиции, как «Junior Game Designer», в принципе не существует. И даже не джуниор позиции очень редки.Видимо, это закрытая кухня, в которую со стороны попасть трудно. Отсюда возникает другое решение — идти в контору, производящую игры самостоятельно на любую открытую позицию, естественно при наличии соответствующей квалификации). Но и тут есть нюанс, личный опыт мне подсказывает, что будучи рядовым разработчиком, шансы поучаствовать в написании GDD (да в принципе и любого другого ТЗ) или хотя бы в формировании начальных требований к нему, очень незначительны. Времени на это просто не будет, а на общих собраниях, с участием всех отделов, если таковые вообще будут, можно почерпнуть только очень, как это ни странно, общие концепции.
Для того, чтобы полностью делать игру самому, нужно чтобы сложилось слишком много звёзд, рассматривать этот вариант я сейчас не буду, скажу только, что это не мой путь (на данный момент).
Так что же тогда делать? Сейчас я попробую сформулировать несколько тезисов, которые, как мне кажется, должны помочь людям, считающими себя начинающими геймдизайнерами, хотя бы начать двигаться хоть куда-нибудь).
1) Писать, писать и ещё раз писать.
Записывать все идеи, которые приходят в голову. Идеи могут перерасти в полноценный GDD, а наброски – в рассказы, а они, в свою очередь, опять-таки в сюжет для игры. И даже если нет, то лишний раз поупражняться в писательстве не повредит. Ведь в более-менее крупных проектах требуется полноценный сценарий, диалоги главных персонажей, описание миссий, и даже банальные реплики второстепенных персонажей. Всё это пишет(ну уж читает-то точно) в том числе и гейм-дизайнер.
2) Определись с платформой и жанрами.
Тут, возможно, многие скажут, что главное идея, а где реализовывать — это вопрос второстепенный. Но гейм-дизайнер, как мне кажется, должен не только определять общую концепцию игры, прорабатывать различные механики, определять стилистику игрового мира, но и сносно владеть техническими вопросами: возможности движка, объёмы трафика, вопросы связанные с приобретением игровой валюты и т. д. Мне кажется, что спектр вопросов, связанных с технической реализацией игр настолько широк, что только их изучением можно заниматься годами, поэтому условно выделю такие направления:
a) Игры для ПК
b) Игровые консоли
c) Браузерные игры
d) Игры для мобильных устройств
e) Настольные игры
Чтобы не утонуть в разнообразии сложных движков, вначале, как мне кажется, стоит ориентироваться на игры для браузеров, ну и конечно настолки. В последних на практике можно даже тестировать баланс и смотреть как работает та или иная механика.
Жанр же, мне кажется, не так важно какой выбрать, просто надо понимать, что браться за написание своего первого GDD, взяв за основу идею игры в стиле РПГ или стратегии, можно столкнуться с таким количеством подводных (и не очень) камней, что пропадёт всякая охота этим заниматься. Лучше попробовать с более простых жанров, например, скроллшутер или тауэр дифенс.
3) Следи за новостями.
Быть в курсе последних событий в мире игр, хотя бы, в той нише, которую вы выбрали для себя. Какие игры вышли, какие технологии при их создании и сопровождении используются. Почему та или иная игра провалилась или, наоборот, попала в топ Google Play. Неплохо так же иметь и своё мнение на этот счёт)
4) Играй в игры.
Самому постоянно играть в новые (и особенно) в старые игры. Даже если они вам кажутся неудачными, всегда старайтесь проходить игры до конца – так можно будет увидеть какие-то нестандартные приёмы и ходы от разработчиков и лучше понять, что будет интересно потенциальному пользователю вашей будущей игры, а что не очень. Особенно это касается старых игр, например для NES или SMD, когда скромные возможности приставок заставляли производителей игр больше думать над сюжетом и геймплеем.
5) Доведи дело до конца.
Очень важно важно (как минимум, для себя) довести до конца хотя бы один GDD. Дать ему «вылежаться» с неделю, просмотреть ещё раз «незамыленым» взглядом, возможно внести коррективы. Дать почитать друзьям, выложить на профильных сайтах/форумах и получить хоть какую-нибудь обратную связь. Но открывая своё «творение» миру, надо быть готовым к критике(зачастую, далеко не конструктивной), а может и вообще к полному игнорированию своих идей и текстов. Это тоже может существенно снизить энтузиазм, или и вовсе заставить прекратить дальнейшие попытки заниматься писательством. Ну значит не очень то и хотелось.
6) Собери портфолио.
В результате выполнения вышеперечисленных пунктов, в конце концов у нас может получиться с десяток законченных GDD, возможно даже с написанными на чём-то прототипами игр и другой сопутствующий литературный материал. Собранное вместе в резюме это может послужить портфолио (хоть и без реального опыта работы), которое уже можно будет попробовать показать потенциальному работодателю.
Я понимаю, что у геймдевелоперской конторы наверняка куча своих наработок, на претворение в жизнь которых попросту не хватает ресурсов, но, возможно, им покажутся интересными не столько сами идеи, сколько подход к их осуществлению.
Интересно, что думает сообщество по поводу такой возможности попасть в геймдев. Может кто-то прошёл этот путь и является сейчас гейм-дизайнером. А может всё тут написанное полная ерунда и совершенно нереализуемо в нашей вселенной?
Инструкция начинающего разработчика игр / Habr
В данной инструкции я попытался осветить основные моменты разработки игр. Инструкция будет полезна для людей, собирающихся заняться разработкой игр в роли лидера (главного разработчика и организатора).Хочу отметить, что игры бывают разные – большие и маленькие, сложные и лёгкие, и поэтому для каждой игры эта инструкция верна в какой-то своей определённой степени. Охватить всё не удалось, но передать общие моменты, думаю, получилось.
И так Вы решили сделать свою игру, о чём Вам нужно подумать…
Думаем – нужно ли это тебе
Перед тем, как за что-то взяться, необходимо всё обдумать. А перед тем, как заняться разработкой игр, необходимо обдумать всё очень хорошо. Очень часто начинающие разработчики, достигнув определённых успехов в чём-то (сделал мод для игры, небольшой фан-сайт и пр.), начинают грезить созданием своей игры. Это происходит из-за того, что они имеют слабое представление о процессе разработки игр.
Я перечислю основные ошибки в их представлении:
- Нет романтики. Многие начинающие разработчики, наигравшись вдоволь в игры, приходят к мысли, что создавать игры также интересно, как и играть, только чуть-чуть сложнее. Это очень частая ошибка. Чем больше и сложнее игра тем, скучнее и безынтереснее процесс её разработки. Романтики совершенно нет.
- Трудно и даже невозможно. Многие после нескольких (или даже одного) успешного проекта наполняются уверенностью, что написать игровой проект им по силам. На самом деле, игры – это одно из самых сложных направлений разработки. И чем «серьёзнее» игра, тем проект сложнее. В процессе создания игры разработчик может столкнуться с нерешаемыми проблемами, которые убивают на корню энтузиазм даже у самых упёртых.
- Отвращение к играм. Со временем у каждого матёрого разработчика игр развивается отвращение к играм. Сначала просто они становится менее интересными. Затем начинаешь замечать, что они вовсе не интересны, а интересно только, как они работают. Чем дальше, тем хуже.
- Конкуренция и качество продукта. Играми занимаются многие студии и независимые разработчики. Существует своеобразный «уровень вхождения» в этот бизнес. Сейчас нельзя сделать успешную игру, нарисованную акварелью (да, такие игры встречались в начале 2000-х). Она просто не выдержит конкуренции. Соответственно, абы что не сделаешь. Тут скрывается важный психологический момент – начинающий разработчик вынужден делать хороший продукт, иначе он будет испытывать постоянное чувство страха неуспешности своего продукта.
- Время и ресурсы. И самая распространенная ошибка – это то, что ресурсов (время, деньги, знания) им хватит. Чтобы понять объём работ, читайте следующие пункты.
Концепция и ТЗ
Когда-то давно я написал довольно неплохую статью о концепции проекта. За последние пару лет мои взгляды слегка поменялись, но суть осталась та же.
- Что же такое концепция? Концепция игрового проекта — это документ, описывающий цели, задачи, основные особенности проекта, исследование рынка и целевой аудитории, условия его выполнения. Также, так как проект игровой, обязательно описание игровой механики, игровых понятий, примерный сценарий и концепт-арт. Если Вы ещё рассчитываете делать проект не в одиночку (что весьма вероятно), то понадобится ещё техническое задание (ТЗ) – документ, содержащий описание необходимых работ, сроки и условия.
- Зачем нужна концепция? Очень хороший вопрос. Зачем заниматься какой-то «писаниной», когда нужно собирать команду и писать код?
В первую очередь концепция нужна, чтобы самому получить полноценное представление о конечном результате и оценить объём работ. Без чёткой и продуманной концепции у Вас в итоге получится, соответственно, противоречивая и непродуманная игра. Без концепции существует большая вероятность возникновения ошибок организации игровой механики или ошибок реализации.
Во вторую очередь концепция нужна для того, что бы другие поняли то, что Вы хотите сделать. Все члены команды должны работать над одним общим проектом. Об этом общем проекте члены команды узнают из документа концепции проекта. Это нужно, чтобы не было расхождений в представлениях о конечном результате. Если Вы решили создать игру и для этого собираете команду, то первые вопросы от будущих членов команды будут: «А что предстоит мне сделать? Что в итоге мы должны получить?». Вы должны будете им предоставить концепцию проекта и ТЗ. Без концепции и ТЗ Вы не привлечёте ни одного нормального специалиста. - Объёмы. Весьма интересен вопрос объёма концепции. Тут необходимо отталкиваться от сложности игры и её разработки. Если у Вас простая игра, Вы работаете один и Вы способны удержать идею игры в своей голове, то можно вообще не писать концепцию. Если удержать в памяти все моменты нельзя, то необходимо перенести их на бумагу (или другой носитель). Если Вы будете работать в команде или использовать помощь других людей (инвесторы, художники и прочие), то Вам просто необходима развёрнутая концепция и ТЗ для каждого человека. Критерий один – понятность. Нужно чтобы любой человек, ознакомившись с концепцией и ТЗ, представил конечный результат, так же как и Вы.
Обратите внимание на то, что, если Вы понимаете свою концепцию, то это не значит, что её поймут другие. Написание концепции выполняет роль «лакмусовой бумажки». Если Вы не можете написать понятную концепцию (примерно, 5 страниц для небольшой игры, несколько десятков страниц для большой), то вряд ли Вы закончите в итоге проект. - Детальность. В концепции должны быть ответы на все вопросы. После прочтения концепции должно сформироваться полное представление о проекте. Специалисты первым делом смотрят на концепцию, если концепция окажется для них не полной и непонятной, то они не будут с Вами работать.
Отдельно стоит упомянуть концепт-арт. Он должен быть, хотя бы в простейшем виде. Он является доказательством решения проблемы с контентом, содержимым игры (смотрите следующий раздел). - Русский язык. Для многих это серьёзная проблема. Если документ концепции содержит множество грамматических, орфографических и синтаксических ошибок, то ни один специалист не воспримет его всерьёз. Помните: незнание русского языка очень вредит бизнесу.
- Время. Желательно в сразу в ТЗ указать сроки выполнения работ. Проблема в том, как оценить это время, если никогда подобным не занимался. Точно ответа на этот вопрос Вы никогда не получите, всё придёт с опытом. Я только дам один совет: учитывайте не только время разработки, но и время на исправление ошибок (примерно 50% от времени на разработку).
Контент
Я специально выделил этот раздел, так как он является решающим в процессе разработки игр. Под контентом понимается всё содержимое игры, с которым взаимодействует пользователь. Это графика (растровая, векторная, 3D), музыкальное и звуковое сопровождение, видеоряд, сценарий и текст. Также сюда следует добавить медиаматериалы, используемые для продвижения игры (реклама, банеры и прочие).
В английском языке есть такое понятие как «artist» обозначающие сразу художников, музыкантов, режиссёров, писателей и прочих творцов. К сожалению, в русском языке нет нормального аналога этого слова, поэтому я дальше буду использовать понятие «создатель контента».
Разберём основные моменты этого раздела.
- Сложность. Это самая главная проблема в вопросе контента. Оказывается, в большинстве случаев подготовка контента является самой сложной задачей, сложнее написания программного кода, сложнее тестирования и отладки, и сложнее реализации игры. Естественно, если игра маленькая, то это не так заметно, а если большая, то на долю создателя контента выпадает до 80% работы по проекту.
- Объёмы. Часто из-за того, что разработчики никогда не выполняли задачи создателей контента, им очень сложно оценить объёмы. Кажется, что там такого ¬– пара десятков картинок и 3-4 звука. Но если посчитать, то получается 40 крупноразмерных изображений, 400 мелких изображений, два десятка звуков (я привел пример среднестатистической BMMORPG). Хорошо, что это всё можно подсчитать при подготовке концепции.
- Качество. Во-первых, надо понимать, что игроки работают непосредственно с контентом. Во-вторых, надо помнить, что существует огромное количество игр-конкурентов с хорошим контентом. Можно сделать вывод: игра с плохим контентом будет не конкурентоспособна, т.е. контент в игре должен быть высокого качества.
- Время. Вполне логично, что на подготовку больших объёмов качественного контента уходит очень много времени. Времени уходит больше, чем на все остальные направления вместе взятые (маленькие игры не в счёт). Учитывайте это, когда будете планировать и рассчитывать сроки.
- Стоимость контента. Хороший контент стоит «хороших» денег. Очень «хороших» денег, которых у начинающих разработчиков игр обычно нет. Многие разработчики питают иллюзорную надежду найти «бесплатного» создателя контента (или дешёвого). Найти можно, но он либо будет создавать низкопробный контент, либо создаст для Вас немного контента, а затем переметнётся к тем, кто будет ему платить. Короче говоря, «бесплатного» создателя хорошего контента Вы никогда не найдёте. Именно по этой причине нет хороших «OpenSource» игр.
- Воровство. Из-за существования проблемы дорогого контента, иногда появляются разработчики игр, которые его воруют. Мол, что такого?.. возьму-ка я из этой игры десяток картинок, а фоновые изображения найду на DA, а в качестве фоновой музыки поставлю пару любимых песенок Rammstein. Проблема в том, что авторское право контента достаточно легко подтвердить. У «жертвы» воровства есть либо исходные файлы контента, либо документ о передаче контента от его создателя. Для воров контента очень велик шанс нарваться на статью 146 УК РФ.
- Единый стиль. Ещё один важный момент, о котором часто забывают. Что бы игра смотрелась цельной и продуманной, ей нужно иметь единый стиль. Создатели контента не роботы, поэтому делают работы в своём индивидуальном стиле. Отсюда можно сделать вывод: желательно чтобы содержимое игры создавало как можно меньше человек.
- Дилемма. После прочтения описанных выше моментов можно построить следующую цепочку: Конкурентоспособная игра требует использование качественного контента. Качественный контент может сделать только профессиональный создатель контента. Профессиональный создатель контента стоит недёшево. Решений данной проблемы всего лишь три:
- Не делать игру, то есть отказаться от направления разработки игр.
- Найти инвестора. Но тут сразу нас поджидает проблема концепт-арта. Кто будет подготавливать концепт-арт, если нет денег на художника? А без концепт-арта никто не будет инвестировать в Вас.
- Решать проблему собственными силами. То есть кто-то из членов команды должен быть создателем контента и должен получать зарплату, даже если все остальные сосут палец.
Программирование
Как ни странно, создание программного кода для игр не является самой сложной задачей, но в тоже время и не является простой.
- Команда. В отличие от создателей контента программистов для своей команды найти легко. Это объясняется тем, что при определённом уровне подготовки написание программного кода игры не такая уж сложная задача. Можно найти «бесплатных» программистов, готовых работать ради интереса. А за плату и «имя» (упоминание, как разработчика игры) можно найти программиста, который будет писать хороший годный код. Но… сейчас не начало 2000-х и программисты поумнели. Первым делом адекватный программист попросит разработчика продемонстрировать концепцию и ТЗ. Затем спросит про создание контента или финансирование, которое пойдёт на его создание. Специалисты прекрасно понимают, что незачем вкладывать силы в изначально провальный проект. Если у Вас нет концепции и не решен вопрос с контентом, то нормального программиста Вы не найдёте.
- Сначала делаем большое, потом маленькое. Достаточно простой совет, но ему чаще всего не следуют. Игровой проект в большинстве случаев сложен и имеет множество зависимостей. Все это сложно просчитать на уровне составления концепции, частенько приходиться что-то менять в планах. Поэтому, чтобы не выполнять двойную работу, сначала необходимо сделать общую работающую конструкцию (прототип), а затем углубляться в детали.
- Что сначала контент или код? Прочитав раздел про контент, Вы уже, наверное, поняли, что современные игры основаны на контенте, а не на программировании. Отсюда дилемма – код подгонять под контент или контент подгонять под код. Оба подхода имеют место в современном процессе разработки. Если подгонять код под контент, то нагрузка падает на программиста, время разработки увеличивается. Это дешёвый способ. Если контент подгонять под код, то нагрузка с программиста спадает, и при учёте, что контент подготавливают наёмные работники, время разработки сокращается. Это дорогой способ, так как нагрузка падает на наёмных создателей контента. Заранее оцените ситуацию и придерживайтесь одного из подходов.
- Нерешаемые ошибки. Это даже не проблема, а предубеждение. Разработка игры весьма сложный процесс. Бывает, что разработчик сталкивается с нерешаемыми проблемами (либо решаемыми крайне тяжело) и ему приходиться пересматривать чуть ли не весь проект. Психологически это очень трудно. Многие, даже самые упёртые разработчики, попав в такой «тупик», теряют энтузиазм и закрывают проект. Предубеждение в том, что все считают, что с ними такого не случиться. Совет один: будьте психологически готовы пересмотреть весь проект и выполнить работу заново.
- Журналы. Совет лично от меня. Ведите три журнала:
- Журнал выполненной работы по проекту для отслеживания динамики разработки;
- Журнал идей по проекту, чтобы не забыть их и, если возможно, включить в концепцию;
- Журнал найденных багов и ошибок, которые необходимо исправить в будущем.
- Время. При определении времени, которое планируется на написание кода, часто делают одну ошибку – не учитывают затраты времени на исправление багов и отладку кода.
- Авторство программного кода. Определённый «маразм» наблюдается, у некоторых программистов. Они считают, что обладают абсолютными правами на код, который ими написан, что даже после релиза игры они могут предъявить права на «часть кода» игры. Что бы защитить это «священное» право они могут пойти на всякие низости (программные бомбы, бакдоры, отказ от передачи исходных кодов и прочие). Мой совет прост – остерегайтесь таких неадекватных программистов. Программный код не контент. Доказать его авторство очень сложно. Поэтому нормальный программист сначала договаривается, что он получит за код; затем его пишет; потом передаёт разработчику и получает вознаграждение; после чего уже ни на что не претендует. Также должно быть организовано и в команде.
Тестирование
О тестировании начинающие разработчики обычно не задумываются, а зря, так как на него тратиться немногим меньше времени, чем на написание программной части. В этом разделе есть два важных момента:
- Тестирование сторонними людьми. В процессе разработки тестирование проводиться в основном своими средствами. Со временем глаза привыкают к имеющимся игровым моментам, вырабатываются умение работать в данной системе, короче, ошибки становятся менее заметными. Поэтому устраивайте периодические тесты продукта сторонними людьми, которые никогда не видели ваш продукт. Следите за их реакцией на различные игровые моменты, как они воспринимают меню игры и, вообще, расспросите их общее впечатление. Поверьте мне, один такой тест даст Вам очень большой объём полезной информации. Проводите их чаще, прислушивайтесь к обратной связи, и Вы получите на выходе хорошую игру.
- Женщины. Когда-то я написал неплохую статью про женщин и игры. Смысл в том, что женщины видят всё по другому. Поэтому, желательно, чтобы в тесте игры участвовала хотя бы одна женщина (девушка), даже если игра не рассчитана на женскую аудиторию. Их обратная связь будет невероятно полезна.
Организационные моменты
- Команда. Как Вы могли догадаться, созданием таких проектов, как игры, лучше заниматься командой. Это обосновано тем, что создание контента совершенно другой вид деятельности отличный от программирования и организации проекта и одному заниматься такими разными видами деятельности сложно. Минимальная команда – это два человека, создатель контента и разработчик. Чтобы не было непонимания, уточню – наёмный работник, по-моему, тоже в какой-то мере член команды.
Конечно, можно заниматься разработкой и в одиночку. Есть такие «сумасшедшие», которые и пишут код, и рисуют графику, и сочиняют музыку, но это их проблемы.
Собрать команду при наличии финансирования легко – форумы программистов и создателей контента, биржи фрилансеров Вам в помощь. При отсутствии финансирования можно найти только программиста, а вот нормального создателя контента не найдёте – здесь надо надеяться либо на себя, либо на удачу. - Юридическое оформление. Здесь всё просто. Хотите иметь с игры деньги и обезопасить себя от рейдерского захвата (когда кто-то внаглую ворует вашу игру), то вам нужно юридическое оформление на уровне индивидуального предпринимателя. Если Вы ещё собираетесь распределять проект по долям, то нужно оформление на уровне ООО. Поэтому если при поиске членов команды Вы обещаете долю в проекте, то не удивляйтесь, что Вас будут просить предъявить реквизиты вашей организации.
- Контакты. Никогда не пренебрегайте знакомствами. Знакомьтесь с другими разработчиками, общайтесь и обменивайтесь контактами. В будущем, возможно, знакомство с ними принесёт Вам пользу.
- Реклама. Так как игр на рынке много, то чтобы пользователи выбрали именно вашу игру, нужно привлечь к себе внимание. Делается это при помощи рекламы на различных ресурсах. Логично, что реклама эта требует: во-первых денег, а во-вторых, рекламный контент (банеры, видеоролики, статьи). Возможны и другие способы ¬– связи, спам, рекламные акции и прочие, но они не всегда эффективны.
Без рекламы игра, точно также как и без контента, является провальным проектом. Обратите на это внимание. Но тут ситуация может достаточно легко исправлена инвестированием и сторонней помощью. - Инвестирование. Понятное дело, что с деньгами игру делать гораздо легче, но без развёрнутой концепции (с концепт-артом), команды и рабочего прототипа никто не будет финансировать ваш проект. То есть на начальных этапах на финансирование не надейтесь. А вот на последних этапах разработки ситуация может в корне поменяться – могут появиться инвесторы и Вам всё равно будут нужны деньги для организации рекламной компании.
Чтобы найти инвесторов, собирайте контакты. - Сторонняя помощь. Вместо инвесторов можно найти стороннюю помощь (реклама за рекламу, помощь в распространении за процент и прочие). Тут надо ориентироваться по ситуации. Чтобы найти стороннюю помощь, так же собирайте контакты.
Послесловие
Инструкция получилась большой, материала много. Крайне советую прочесть её начинающим разработчикам игр, так как, возможно, она поможет им избежать ошибок в будущем.
UPD: Статья получилась успешной, даже очень. Но в комментариях прослеживаются замечания по поводу отсуствия романтики и отвращения к играм. Поэтому я прокомментирую эти моменты.
Многие опускают тот факт, что статья для начинающих разработчиков игр, претендующих на роль лидера (первый абзац статьи). Не буду отрицать, что со временем, когда приобретаешь опыт разработки игр и жизнь складывается удачно, возвращается романтика и отвращение спадает. Но в самом начале, когда начинаешь с нуля, после того как столкнёшься с первыми серьёзными проблемами, эта романтика и любовь к играм исчезает ко всем чертям. Разработка игр — это не прогулка по ковровой дорожке в розывых очках, а блуждание в лабиринте Минотавра, где много тупиков.
Я не собираюсь своей статьёй вселять в начинающих разработчиков уверенность. Они должны знать, что путь разработчика игр сложен, что они могут встретить нерешаемые проблемы, что их нерализованный проект будет для них символом поражения.