Полтора года я занимаюсь разработкой игр, а последние несколько месяцев посвятил созданию своего первого полностью самостоятельного проекта. У меня не было подобного опыта, так как ранее я участвовал в создании игр на должности Unity‑разработчика, и объём моих задач был ограничен. А теперь мне необходимо всё делать самостоятельно. Хоть я и делаю игру для мобильных устройств и веба, но чётко ощущаю, что её разработка затянулась.
В связи с этим я начал часто задумываться над причинами моего столь медленного темпа и смог сформировать несколько советов, основанных на моём опыте. Какие‑то из них могут показаться вам очевидными и лежащими на поверхности, но я считаю, что всё же такие вещи лучше «проговаривать вслух». Сразу хочу отметить, что всё написанное ниже, в бОльшей степени, будет полезно только начинающим соло‑разработчикам или молодым командам из двух‑трёх человек.
Не пренебрегайте документацией
Вообще, я уже давно ввёл для себя в привычку вести заметки на телефоне и записывать туда абсолютно всё: от банального списка дел или продуктов до своих идей для игр. Это освобождает голову от назойливых мыслей и позволяет сконцентрироваться на важных в данный момент вещах, а уже после вернуться к записанному.
Поэтому, неважно насколько у вас большой проект, не поленитесь написать дизайн‑документ. Даже если вы хотите «слепить на коленке» за неделю игру под какой‑нибудь тренд. Уделите немного времени, чтобы тезисно набросать главные фичи — в дальнейшем это значительно упростит вам разработку.
Предположим, мы хотим сделать игру «Покатай шары», упрощённый клон популярной Going Balls, небольшой «диздок» можно написать где угодно: в том же Rider или VSCode, хоть на листе бумаги.
Теперь, когда основные моменты записаны (см. скриншот выше), мы можем оценить и сформировать приблизительную структуру проекта и начать задаваться вопросами:
Будем ли мы делать альтернативный вариант управления, например, джойстиком или гироскопом? Как мы будем определять проигрыш — падением шара ниже определённых координат в пространстве или будем использовать коллайдеры под платформами? Для чего нам собирать монеты? Может, за собранные монеты игрок будет открывать следующие уровни? По какой системе игроку будут начисляться очки за пройденный уровень? Какие цвета мы будем использовать? Будем ли мы создавать тематические уровни?
Написав подобный документ, вы сможете чётче представить игру у себя в голове и увидеть как потенциально проблемные места, так и места для роста. Да и впоследствии вы сможете дополнять свои записи или помечать выполненные сегменты, благодаря чему, отслеживать прогресс станет намного удобнее.
Плотно работайте с референсами
Изучайте как можно больше успешных игр не только в жанре вашей игры, но и смежных. Заимствовать удачные решения — это абсолютно нормально.
Самое главное — не просто копировать вслепую, а постараться декомпозировать тот или иной элемент и понять, почему это решение кажется вам хорошим, какие именно механизмы привлекают и удерживают пользователей и вас самих.
Чем больше вы соберёте референсов и чем плотнее вы с ними поработаете, тем качественнее получите результат на выходе. Вы сами удивитесь тому, как быстро новые идеи начнут приходить вам в голову. В этот момент важно обратиться к предыдущему пункту и начать всё записывать.
Важно отметить, что оба описанных пункта следует применять на этапе «пре‑продакшена», до того как вы начали активную разработку. Хорошо проделанная работа на этом этапе сэкономит вам недели, а может и месяцы разработки.
Не бойтесь отказываться от некоторых идей
Отказываться от каких‑либо идей в процессе разработки — это нормально. В конце концов, в релизную версию игры должны попасть только те вещи, в которых вы точно уверены. Важно не зацикливаться на какой‑то одной идее и экспериментировать, желательно, на самых ранних этапах и как можно больше.
Я потерял около месяца из‑за того, что зациклился на определённом визуальном стиле, который мне никак не давался. Я не мог собрать все элементы воедино и постоянно что‑то перерисовывал. Пока внезапно, не без помощи моей жены (но об этом в следующем пункте), не решил максимально отдалиться от изначального стиля и начать экспериментировать.
В итоге, за следующие 3 дня я отрисовал 90% всей необходимой мне графики, и конечный результат мне нравится гораздо больше.
Возвращаясь к нашей вымышленной игре «Покатай шары» из первого пункта, предположим, вы решили отказаться от лидерборда и системы подсчёта очков. Это может быть обосновано по‑разному: вы не хотите тратить лишнее время, не придумали как реализовать фичу или просто не уверены, нужна ли эта механика в игре.
Смело вырезаем эту фичу, всё равно ничего хорошего из этого не выйдет. Если что‑то в процессе разработки игры вас фрустрирует — либо полностью откажитесь от этой идеи, либо постарайтесь посмотреть на неё под другим углом.
Начинайте как можно раньше показывать свою игру
Когда ты работаешь над чем‑то в одиночку, особенно долго, то постепенно начинаешь терять связь с реальностью. Не всегда понятно, насколько хороша реализованная тобой идея. Интересно ли это другим людям? Понятно ли?
Если вы работаете в команде, хотя бы из двух‑трёх человек, ситуация становится немного лучше, но тем не менее любое решение требует взгляда со стороны. В больших компаниях эту функцию выполняют плей‑тесты, в нашем же случае на это попросту нет ресурсов.
В такой ситуации лучшее решение — это обратиться к комьюнити. В ру‑сегменте существует огромное количество ресурсов (форумов, групп и каналов), где можно разместить свой проект и получить качественный фидбэк, в том числе и от профессионалов.
Исходя из своего опыта, могу заверить вас, что комьюнити игровых разработчиков очень тёплое и отзывчивое. Честно говоря, за некоторые вопросы, задаваемые на разных форумах и в группах, мне даже немного стыдно — настолько, по моему мнению, они были глупыми. Но при этом я всегда получал на них ответ и ни разу не сталкивался с высокомерным осуждением.
Помимо фидбэка от вовлечённого в игры комьюнити, обязательно показывайте своё творение близким. Особенно если они ничего не понимают в играх. Так вы сможете увидеть реакцию обычного пользователя, для которого и создаются игры, и извлечь из этого пользу.
Например, моя жена помогла мне нащупать визуальный стиль игры. Я рассказал ей о сути проекта, какие эмоции он должен вызывать, после чего спросил, как она себе это представляет. Справедливости ради, стоит упомянуть, что она уже несколько лет работает UX/UI‑дизайнером. Да‑да, знаю, я использовал чит‑код. Но не спешите обесценивать опыт своих друзей и близких — даже если они никак не вовлечены в геймдев, они всё ещё смогут вас удивить отличными идеями.
Тем не менее, важно помнить одну единственную вещь — все ключевые решения в проекте должны принимать ТОЛЬКО ВЫ. Мнения людей могут быть противоречивы, профессиональные разработчики могут давать кардинально противоположные советы. Ваша задача — научиться грамотно работать с этим фидбэком.
Не бойтесь просить помощи
Вы не обязаны взваливать на себя кучу обязанностей и абсолютно всё делать самому. Не обязательно писать свой движок под игру, когда существует множество открытых и бесплатных решений. Не обязательно мучиться в Photoshop, Illustrator или Blender, если вы не художник — воспользуйтесь готовыми ассетами.
Используйте готовые решения для создания механик — большое количество программистов выкладывают свои наработки в открытый доступ. Главное — всегда уточняйте условия использования тех или иных вещей.
Возвращаясь к предыдущему пункту, не бойтесь просить совета у других разработчиков. В конце концов, мы все делаем одно большое дело.
Подводя итоги, хотелось бы сказать, что если бы я сам придерживался этих советов, то не потратил бы кучу времени на переделку основных механик, не потерял бы месяц разработки из‑за моей зацикленности на одном визуальном стиле. Быстрее бы пришёл к удачным решениям в своём проекте, если бы начал раньше показывать его другим людям.
Надеюсь, этот материал поможет другим разработчикам создавать игры эффективнее и не совершать моих ошибок.
Недавно я завёл личный блог про игры и разработку, поэтому обращусь к последнему пункту своей статьи и попрошу подписаться на него, если этот материал вам понравился. Так же попрошу вас оставить фидбэк о статье и поделиться своим «бэст практис» в комментариях.
Комментарии (7)
feelamee
14.07.2024 13:52+1похоже забыли один из самых важных советов для создания успешной игры - занимайтесь маркетингом.
Кажется я прочел об этом в книге "кровь, пот, пиксели". Там есть хорошее описание процесса создания инди игры stardew valley.
Fabrichkin Автор
14.07.2024 13:52Согласен, маркетинг - это очень важно. Но в этой статье я хотел больше уделить внимания проблемам организации и хода разработки.
P.S. Эрик Барон - легенда! От части его история и вдохновила меня на изменения в жизни. Да и книга топ, свой блог назвал с отсылкой именно на неё))
iRusher
14.07.2024 13:52+2Я начал изучать Godot с нуля, до этого только были не оконченные курсы по Python, начинал всё как просто по прикалываться, а потом с интузиазмом и интересом занялся вплотную, так и не заметил как пролетело 5 месяцев. И сейчас я осознаю некоторые вещи, которые стоило сделать сразу, а не когда уже 4к строк кода и десятки скриптов написано для игры. Я делаю экшин РПГ и поделюсь своими наблюдениями:
1) Делать документацию, для работы со своими механиками. Когда разработана механика, например скилов, тоесть у вас есть экшин бар, скил лист откуда учится скил, меню где выбираешь активные скилы, у меня полное добавление скила в игру задействует 4-5 скриптов, и честно говоря когда на меня снисходит озарение, и я решаю добавить новый, мне приходится вспоминать как что и где мне нужно делать чтобы везде это работало как надо, и на это уходит время и энергия.
2) Не тратьте запланированное время на отдых, для своего проекта. Я тоже делаю всё в одиночку, и я горю этим делом, обычно я придерживаюсь тактики заниматься этим в свободное от работы время, а на выходных отдыхать. Так сложилось что у меня работа основная 4-5 часов в день занимает и я так работал 2.5 месяца, и всё было супер продуктивно и отлично вообще, но потом мне захотелось ещё и на выходных заниматься проектом, я поработал так 1 месяц, и в итоге словил выгорание, и где то весь следующий месяц я очень мало им занимался, прежде чем снова вернуться в этот режим. Теперь на выходных я даже при желании заняться проектом, отдыхаю.
3) Не торопитесь заниматься наполнением пока не готовы механики и другие аспекты игры типо левел дизайна. Дело в том что я делаю 2Д игру, но использую 3Д рендеры моделей в блендере для нарезки на спрайты в изометрии, и первый раз я сначала накупил моделек и начал рендерить для анимации несколько врагов и персонажей, потом я увидел что стоковые тени в движке не подходят, тогда я понял что надо запекать тень при рендере в блендер, и мне пришлось перерендерить десяток анимаций для разных моделей и это рутинное дело, у меня был тестовый уровень где я добавлял врагов и тестировал механики, было представление как будет выглядеть графика и левел дизайн, но я им пока не занимался, а когда занялся понял что то представление которое у меня было не реализуемо в одиночку, и мне снова пришлось перерендерить кучу моделек, до чуть меньшего качества чтобы качество моделей врагов и персонажей не выбивалось на общем фоне левел дизайна, и честное слово нет ничего унылее этого дела, лучше сделать пару элементов и оставить остальное до момента когда уже будет более менее вырисовываться общая концепция игры.
4) Не используйте нейросети для того чтобы написать вам код для игры или механики, но используйте для того чтобы разобраться в том как это сделать, по началу пока не привык к синтаксису я просил ChatGPT для того чтобы он мне написал например код для механики движения, ещё для каких то вещей, потом когда я привык постепенно в течении месяца, начал замечать косяки в его коде, и все меньше к нему обращался, так как некоторые вещи которые он делает, громоздкие и не учитывают уже созданную тобой инфраструктуру, лучше написать их самому , а непонятные моменты у него уточнить как это работает. В результате вы будете самостоятельно разбираться в движке, начнёте все чаще обращаться к документации, создавать классы, и будете понимать как работает ваша игра и как ее усовершенствовать или обслуживать. Ищите примеры создания требующихся механик на Ютубе.
Ну и позволю себе немного не согласиться с некоторыми вещами, о которых написал автор. Показывать родным, друзьям, близким хорошо, моя жена тоже добавила свежий взгляд по дизайну, но уже когда что то действительно уже есть, хотя бы процентов 20% игры, потому что на моем опыте показав что у тебя ходят квадратики по непонятному полю из пикселей и стреляют картинкой, может вызывать фидбек от которого у тебя мотивация убавится, но когда показываешь уже нечто что действительно похоже на игру, восторг и похвала даёт большой заряд, заниматься этим ещё больше.
Также не соглашусь с тем, что стоит рассказывать о своей игре как можно раньше, от части по причине того что написано выше и также потому что если вы делаете игру сам, или вдвоем-троем, совершенно не факт что если ваша идея наберёт обороты и популярность, какая нибудь инди команда на десяток чел по больше и по опытнее, не возьмутся сделать нечто похожее, и сделают это раньше вас намного. Лично я собираюсь показывать свою игру сообществу, и собственно делать демки, страницу в стиме, уже когда будет хотя бы половина игры готова. Возможно я не прав, но я твердо в этом убежден. Набрать вишлисты всегда можно успеть, в конце концов рекламу у блогера взять например, а корректировать свое виденье проекта не вижу смысла, я изначально занимаюсь творчеством и хочется делать что тебе в первую очередь нравится для души, а комьюнити не видя общей картины может просто не понять задумку. И для таких целей, большие компании используют контрольные группы, а не публичные соц сети.
Fabrichkin Автор
14.07.2024 13:52Во-первых, желаю Вам довести свой проект до релиза и много продаж!
Во-вторых, не вижу ничего страшного если кто-то подхватит мою идею, все равно тебе в голову они не залезут и не украдут твоё виденье)) Даже если их вариант реализации окажется лучше, это повод понять, что именно ты сделал неправильно.
И последнее, в статье я говорю об опыте разработки мобильной игры, где цикл разработки короче, от идеи до реализации проходит меньше времени. В итоге, игра быстро переходит из состояния "квадратиков" до "чего-то похожего на игру". Но в случае разработки более масштабного - я соглашусь с вашими тезисами))
VitalyZaborov
Я занимаюсь разработкой игр 20 лет, а последние несколько недель посвятил поиску издетеля для своего очередного проекта ;) И мне таки есть чем дополнить ваши, тоже очень дельные, советы.
Не пытайтесь откусить больше, чем сможете проглотить.
Ещё на самом раннем этапе, ещё когда вы только придумываете игру, учитывайте какие средства (время, скиллы, деньги) у вас есть и что вы можете сделать этими средствами.
Если вы не можете нарисовать / анимировать весь контент - сначала идите в ассет стор и думайте что более-менее достойное можно сделать из его содержимого.
Если вы не программист - тоже идите в стор или ищите примеры уже сделанных механик и выберите те, в которых сможете разобраться и адаптировать под себя.
Даже если ваш бюджет $0 - всё равно идите в стор и смотрите бесплатные ассеты. На них тоже можно дотащить игру до MVP и дальше искать издателя или единомышленников.
Трезво оценивайте свои трудозатраты. Исходите из того, что из MVP, сделанного за выходные, полноценная игра получится никак не меньше чем за 3-4 месяца.
Планируйте и следуйте плану.
Определитесь хотя бы какие фичи вы делаете на этой неделе и какие - на следующей. Занимайтесь своим проектом постоянно. Хотя бы понемногу, но каждый день. Иначе очень легко забросить, особенно если совмещаете с основной работой.
Даже если вы освободили под проект выходные - занимайтесь им по вечерам и на буднях тоже, иначе ваши эстимейты на дни превратятся в эстимейты на недели.
Fail fast & fail cheap
Если работа над игрой не идёт, сроки постоянно съезжают или вам буквально в тягость заниматься игрой - не бойтесь её бросить. Оглянитесь назад, поймите что сделали не так, составьте план на новый проект и потратьте 1-2 недели на R&D. Там посмотрите ещё раз, стоит ли забрасывать. Если вы осознали, что выбрали не ту технологию, то чем раньше вы её смените - тем лучше.
Вот если вы за собой заметили, что уже 2-3 раза меняете проект или движок - это повод задуматься что в целом идёт не так.
Fabrichkin Автор
Отличные советы) Думаю, о таких, казалось бы, очевидных вещах - нужно говорить как можно чаще. Особенно людям с таким большим опытом как у вас)