Показаны сообщения с ярлыком pbroblems. Показать все сообщения
Показаны сообщения с ярлыком pbroblems. Показать все сообщения

воскресенье, 19 января 2014 г.

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 ;)
Получилось немного больше, чем заметки на полях, следующие посты будут короче и более точечные, по конкретным идеям или проблемам.   

воскресенье, 20 октября 2013 г.

В заложниках ситуаций

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

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

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

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

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

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

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

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

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

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

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

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

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

четверг, 18 июля 2013 г.

проблема "говорить"

В этом коротком видео всего за 3 минуты Марк Риттенберг объясняет основную проблему менеджмента в RU/CIS, которая состоит в отсутствии умения налаживать коммуникации. Я думаю, что эта проблема свойственна не только нашему региону, но и EU/USA, возможно, в меньшей форме.

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

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

  • мы не знаем что-то, но умолчим и будем долго биться головой об стену, пока не докопаемся до правильного решения задачи.
  • о косяках и проблемах, так как пытаемся их решить сами, даже если косячим не мы.
  • о сроках реализации, когда что-то пошло не так. Очень редко говорят, что "задача А пошла не так, по причине Б, это займет еще 3 дня", это говорят уже в момент, когда задача А должна быть готова.
Основная проблема тут в страхе, и с этим страхом нужно бороться внутри команды. Команда должна понимать, что если любой человек из нее скажет, что он не знает, как реализовывать эту задачу, то ему не ответят "ахахаха, днище иди учи", а объяснят, как ее делать, или на какие примеры посмотреть для ее реализации.

Тут очень хорошо помогает система, когда все таски по фиче изначально не имеют конкретного исполнителя. Это позволяет человеку из команды самому решить, где он может выложиться на все 100 процентов и сделать задачу во время.

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

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

Нужно говорить, говорить и еще раз говорить. Это тяжело. Особенно же тяжело научить себя тому, что если возникла проблема, то нужно пойти и сказать о ней, а не сделать вид, что проще самому сделать, чем узнать, откуда она возникла.

Нужно помнить, что в конце страдает не тот, кто мало работал, а тот, кто молчал и много работал.

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

среда, 17 июля 2013 г.

3 мысли из лекции Никиты Буянова

Думаю, что не я один не подозревал, что существует компания AbsolutSoft, которая сделала и продолжает работу над Contract Wars. По ссылке можно найти первую часть выступления
Никиты Буянова, арт-директора в выше упомянутой компании, который рассказывает нам о выпуске проектов для midcore аудитории.

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

Мысль 1: Финансирование
Если у вас нет имени, то деньги вам не даст никто. Все молодые команды начинают без денег, и лишь немногим получается найти профильного инвестора. Зачастую находится не профильный, после чего на выходе слишком много палок в колесах из-за желания побыстрее вернуть вложенное.

Любой инвестор хочет понимать - куда, а главное в кого он вкладывает деньги. В первую очередь деньги вкладываются в команду/людей, которые могут довести проект до конца, потом в сам проект.

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

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

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

Мысль 2: Не знание технологии
Сейчас много всего лежит прям перед нами - Unity, UDK, Game Maker, бери и используй. Порог вхождения в индустрию максимально низкий, но любая готовая технология не гарантирует нам успеха или 100 процентного завершения проекта.

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

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

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

Технология легко может похоронить ваш проект.

Мысль 3: выход за рамки ТЗ
Все в команде знают как сделать лучше, и это хорошо. Но у этой медали есть и вторая сторона, когда желание сделать лучше превращает фичу A в фичу В, потому что все пытались сделать лучше, а сделали совсем другое, а проекту без фичи А не жить никак.

Этим светлым стремлением мы сами же себе удлиняем срок разработки, так как к работе над фичей A придется вернутся и сделать как было запланировано, а получившаяся фича В может и не войти в билд вовсе.

Это же касается итераций - всегда должен быть предел, после которого фича апрувится или же выкидывается, и делается новая на ее место. Если такого предела в виде количества итераций не будет установлено в самом начале проекта - будем иметь смещенные сроки на непонятное значение, стремящееся к бесконечности.

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

А еще сходите и почитайте пост о времени у Сергея Климов в блоге.

среда, 22 мая 2013 г.

Во всем виноваты бюджеты

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

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

Но перед тем как продолжить читать дальше, послушайте отличный доклад от Petri Purho "Why Being Poor and Having No Budget is Good For Making Game". Его я привожу часто в пример, когда начинаются разговоры за бюджеты. Он банальный, в нем нет ничего нового, но он дает понять, что игры можно делать и без бюджетов.
Но вернемся же к нашим проблемам, которые возникают внутри команды, и которые куда страшнее любого бюджета, так как они разваливают нашу команду и проект изнутри. На самом деле таковых проблем очень много, но я остановлюсь на тех, которые чаще всего встречаются.