Вспомнить все

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

Со временем мы концентрируемся лишь на том, что нам необходимо в работе. Да, кто-то пытается учиться, заглядывать в смежные области, но черпает оттуда лишь то, что нужно в сейчас для основной занятости.

В этом нет ничего плохого, и это даже хорошо, так как мы все знания адаптируем под свои потребности в конкретный момент времени. Но я это все веду немного к другому - будучи indie, есть шанс вспомнить все, и куда более высокий шанс узнать много нового, так как во всем приходиться разбираться самому.

Главным стимулом к обучению становится лень - двигатель прогресса, а мы все существа ленивые и без стимула никак. Вместе с ленью нас стимулируют ограничения - нет большой команды, нам некуда делегировать задачи. Мы начинаем разбираться сами, копать матчасть, смотреть туториалы и адаптировать это под свои нужды.

Так, к примеру, много лет назад я зарекся, что буду скриптовать, так как мне это банально надоело. И я действительно не скриптовал до начала этого года, когда мы начали в свободное от основной работы время делать проект - мне пришлось лезть и разбираться в юнити, найти удобный для себя формат и работать в нем (с playmaker мне стало куда проще работать с Unity). Но это "разобраться" пошло дальше, и я сейчас с удовольствием берусь поскриптовать в своем основном проекте, хотя это и не входит в мои обязаности, а мне, как оказалось на самом деле, нравится скриптовать.

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

На днях мне пришлось разбираться с google analytics, который я видел впервые, так как мы запускали блог для Isles Of Umbra и нуждались в статистике, которую в tumblr посмотреть нельзя. Теперь полученные знания и понимание работы google analytics мне пригодятся и в основной работе, так как я никогда с ним не сталкивался (в основном работал с самописными тулзами для статистики, которые более выгодны для игровых проектов, чем сторонние).

Да, есть останавливающие факторы - в основном это нежелание разбираться и искать, а также время, которое тратится, так как это дополнительная нагрузка, даже если вы не один человек, а маленькая команда, кому-то придется делать RND всего, с чем вы не знакомы или никогда не работали.

Да, можно сказать, что так мы никогда не будем профессионалами в одном направлении, но будучи indie необходимо быть человеком-оркестром, и уметь все на удовлетворительном уровне (критерии умений и знаний ставим себе сами) лучше, чем уметь что-то одно, но при этом утонуть в попытках найти людей, которые будут уметь другое и готовы войти в вашу команду

Indie way #3 - Games Jamm's

Последних несколько месяцев не было совсем времени, чтобы писать в блог, да и не было о чем говорить. Но пост об участии в games jamm's и пользе от них созрел давно, и самое время в преддверии нового Ludum Dare поделиться своими мыслями.

Первый раз в игровом джеме я участвовал несколько лет назад, в гордом одиночестве, пытаясь сделать платформер. По итогу мне ничего так и не получилось, а я забил на эту идею на несколько лет.

Следующий раз, уже два года назад, мы собрались командой в три человека и участвовали в Ludum Dare, с игрой в стиле The Sting!. Это был командный зачет, у нас было 72 часа, за которые мы не сделали толком ничего, так как уперлись в проблему планирования времени.

В последнем Ludum Dare я участвовал лишь для того, чтобы проверить возможность концепции, и я ее удачно проверил, не выложив игру, но так родилась Isles Of Umbra, правда, тогда в совсем текстовом режиме, но это дало возможность поверить в свои силы и начать делать этот проект.

Последним джемом, в котором я участвовал, стал Games Jam: Kanobu, благодаря которому проект получил публичность. Мы приняли участие в двух этапах - игровой концепт и концепт арт. По итогу, хоть мы и ничего не выиграли, но собрали команду и сейчас делаем проект во всю, с желанием его закончить по IGF.

Джемы стали спортом для игровой индустрии, своеобразными забегами на выносливость, которых становится все больше. Иногда кажется, что скоро вся индустрия превратится из девелопмента в джем-батлы.

Но давайте теперь поговорим о том, что же нам дает джем:

• Proof of concept - да, большинство джемов имеют установленную тему, но никто не мешает придумать игру под нее, проверить ее на жюри и игроках, которые будут оценивать и по итогу уже сделать выводы. На эту проверку не уйдет много времени и вы сделаете необходимый минимум, так как сроки очень сжатые.
• Планирование времени - работая над игрой, похожей на The Sting!, нашим главным врагом было время. Мы слишком долго думали над тем, какую концепцию выбрать под тему, решили писать свой движок вместо того, чтобы взять готовое решение, плюс усталость, которая с каждым часом нас тормозила, так как мы жестко рашили. Но, выявив проблемы, с ними не сложно бороться - брать готовые технологии, в которых есть разбираешься, ставить временные рамки на каждую часть работы, если выходим за них - упрощать и урезать. Проверкой для меня станет новый Ludum Dare(25-28 апреля) где я буду с новой командой.
• Публичность - вы привлекаете к себе внимание, даже простые посты в блоге процесса разработки Ludum Dare могут вызвать бурное обсуждение в комментариях, а это уже хороший старт для дальнейшего развития проекта.
• Команда - благодаря Games Jam: Kanobu нам удалось собрать отличную команду. Не принимай мы там участия - мы бы еще долго искали художника и людей, готовых нам помогать, или даже просто ретвитить и шейрить сообщения о статусах разработки.
• Работа с ограничениями - бытует мнение, что ограничения - это плохо. Но на самом деле ограничения есть во всем, на протяжении всего девелопмента, и они стимулируют к лучшим решениям, чем безграничные ресурсы.

Еще один большой и важный плюс - джемы помогают выявить проблемы внутри команды, если вы участвуете не в одиночку, даже если вы, казалось бы, уже сработаны. Любой джем - это стресс, сжатые рамки, проблемы коммуникаций, которые вылазят наружу в первые часы и если их не решить, проект будет погублен. Выявляя эти проблемы в джеме, их можно исправить уже внутри сработанной команды. Для молодых и только созданных команд это хорошее испытание, чтобы сработаться либо увидеть, кто вам не подходит.

Indie way #2 - Ограничения

Продолжаю серию постов о indie-разработке, и сегодня речь пойдет о ограничениях и их пользе в разработке, и это касается не только indie-проектов. Следуя ограничениям, нам приходится изворачиваться и придумывать вещи куда интересней, чем если бы у нас были полностью развязаны руки.

Я уже не первый раз говорю об ограничениях, и в этом блоге тоже было несколько постов. Но я не устану это повторять, так как игровой дизайн - это problem solving, а при ограничениях чем, как не problem solving заниматься.

Но прежде чем мы начнем, посмотрите выступление Petri Purho, который рассказывает хорошо об ограничениях через призму отсутствия бюджета для игры, и почему это хорошо для разработки.

А теперь давайте поговорим про ограничения, которые разделим на три категории:

• Технология - я не зря первый пост из серии написал о технологиях, так как базируясь на их ограничениях, мы строим наш девелопмент. Я много раз слышал, что технология не должна тормозить дизайн, что наши программисты напишут технологию, на которой можно будет делать все и т.д. Но легко девелопить фичи там, где нет границ - делай что хочешь, даже особенно задумываться не надо. Другое дело, когда ты знаешь рамки, знаешь, что точно нельзя делать, и пытаешься придумать уже на этом дизайн, решив конкретные проблемы. 
• Деньги - имея ограниченный бюджет, мы зачастую получаем игру про капитана кругляша и его верных помощников квадратов. Да, деньги могут стать причиной закрытия проекта, но бюджет нам нужен для дополнительных сотрудников, возможно офиса, нанять художника, который сделает нам крутую картинку и т.д. Не имея возможности привлечь дополнительные ресурсы, используя ограниченный бюджет, мы концентрируемся на главном, том, что получается у нас лучше всего.
• Skills - да, много людей-пароходов, которые могут на достаточно уровне держать все части игры. Но так же много людей, которые пробуют, не умея рисовать, писать музыку или писать код. Используя для этого тулзы, которые не требуют знаний в программировании, бесплатные ассеты вместо графики (или покупая ее) и концентрируются на геймплее как главном, или технологии, или картинке - в зависимости от уровня скиллов. 

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

Indie way #1 - Технологии

Решил сделать серию небольших постов про indie development, которым я занимаюсь в свободное время. Точнее, уже много-много времени, и все никак не могу сдвинуться дальше кучи прототипов, которые попадают в стол. За это время набралось много всяких мыслей, которые не тянут на большой пост, а вот в блиц-формате пойдут хорошо. 

Так что, пожалуй, начнем с технологий, где я буду капитаном очевидность, и вообще говорить о понятных для многих вещах.

Я всегда завидовал людям, которые максимально универсальны, могут и код писать и рисовать и музыку делать, и дизайн придумывать. Даже если все это делается не на high level. При наличии таких умений разрабатывать indie-игру куда проще, чем обладать узкопрофильными знаниями.
Все таки, если нет возможности собрать команду, то indie для людей-пароходов.

Прототип платформера с ревайдом времени с использованием GameMaker 8.1

Свой первый прототип/игру я сделал в 12 лет, и тогда мне это казалось просто "ВАУ!!!!!!!1111, я смог это сделать", для этого я использовал Blitz Max, на который случайно набрел в интернете, начитался туториалов и сделал змейку с генерируемой графикой. (в основе лежал один из туториалов для Blitz Max, который я довольно сильно модифицировал).

Прототип одного из проектов с использованием самописного движка

Со времени первого прототипа я перепробовал множество технологий, попытался стать человеком-пароходом - я стал дизайнером, начал писать музыку, подтягиваю постоянно свои знания в написании кода. Я даже пытался научится рисовать, но с этим не срослось вообще, хотя в будущем буду пробовать еще.

Прототип UI проекта, который я делал вместе с mercai используя UDK

Ладно, вступление как-то затянулось, так что перейдем к технологиям. За последние годы я опробовал многое - Unity, UDK, Game Maker, Stencyl, Construct, вновь Blitz Max с желанием сделать модификацию на SCP, Twine, Phaser и т.д. Кстати, у Pixel Prospector есть хороший гайд по технологиям, используемым для разработки игр, и проектам, сделанных на них. Проекты, понятное дело, не показатель удобности технологии, но гайд интересный.

Я на всем пытался делать прототипы, чтобы понять для себя ограничения, о которых мы поговорим в одном из следующих постов, и пользу, а также понять, насколько и где удобно работать.

Попытка сделать красивый Volume light с использованием GameMaker 8.1

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

• Документация -  как по мне, самый важный элемент любой технологии. Она помогает понять, как с этим работать, какие есть подводные камни и насколько сильно придется танцевать с бубном. Чем меньше документации, тем сильнее мы полагаемся на сообщество.
• Сообщество -  помогает с примерами, дает ответы даже на самые часто задаваемые вопросы по сотому разу, помогает с pro tips и прочими интересными вещами, которые не так легко обнаружить. Самое слабенькое коммюнити сейчас у Phaser, но тут и понятно, каждый считает, что проще написать свой html5 framework, чем развивать уже существующие, там дикий запад. Самые хорошие, но это опять имхо, у Game Maker и Unity.
• Простота использования - больше в контексте порога вхождения, так как не всегда высокий порог вхождения означает, что можно сделать что-то очень крутое,  но чем он выше, тем меньше людей остается с этой технологией, отсюда и меньшее количество людей в сообществе.
• Поддержка со стороны разработчиков - когда нет ответа в документации или в сообществе, единственный путь - обратиться к создателям. Когда есть официальная поддержка (пускай платная, что даже лучше), работать с таким движком куда приятнее, так как выше вероятность получить ответ. Но часто ситуация обратная, когда ответ нельзя получить и от разработчиков, так как они такого не пробовали делать или по другой причине (недавно читал подобный тред в сообществе Construct, где народ обсуждал парсинг текста).

Не помню, что за прототип, но на Unity ;)

Получилось немного больше, чем заметки на полях, следующие посты будут короче и более точечные, по конкретным идеям или проблемам.