Телеграм канал 'Game Development'

Game Development


4'536 подписчиков
0 просмотров на пост

🎮 Управление производством в Game Dev
⚡️ Менеджмент IT проектов
🧩 Настройка процессов для технических и творческих команд

💎 А так же крутые кейсы, интересные статьи, обучающий материал, ивенты

Обратная связь и фидбек @gameprod_bot

Детальная рекламная статистика будет доступна после прохождения простой процедуры регистрации


Что это дает?
  • Детальная аналитика 186'632 каналов
  • Доступ к 67'644'136 рекламных постов
  • Поиск по 256'849'986 постам
  • Отдача с каждой купленной рекламы
  • Графики динамики изменения показателей канала
  • Где и как размещался канал
  • Детальная статистика по подпискам и отпискам
Telemetr.me

Telemetr.me Подписаться

Аналитика телеграм-каналов - обновления инструмента, новости рынка.

Найдено 54 поста

Недоушедшие сотрудники: почему это опасно для коллектива
https://hr-portal.ru/article/nedoushedshie-sotrudniki-pochemu-eto-opasno-dlya-kollektiva

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

12. Сохраняйте идеи на другой проект

В какой-то момент вам пришла в голову гениальная идея, от которой у всех отвалится челюсть, но для её реализации нужно переделать всю игру? Отложите её на другой проект! Это же не последняя игра в вашей жизни, правильно? Приберегите идею для следующего проекта, но сначала – закончите этот!

13. Убирайте лишнее

Ой-ой, вы выбиваетесь из графика. Вы полны блестящих идей, но Марс колонизируют прежде, чем вам удастся реализовать хотя бы половину из них. Бедный, бедный вы… Но постойте!

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

14. Если все-таки бросаете, уменьшайте размах, а не увеличивайте

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

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

Так что уменьшайте размах еще, еще и еще – пока не обнаружите, что осталось даже слишком мало для вашего уровня. Например, вместо того, чтобы от задумки космической стратегии перейти к космической 3D-стратегии, попробуйте сделать качественную игру с одним элементом космического симулятора. Не исключено, что и эта задача будет сложнее, чем вам казалось поначалу (но при этом и гораздо интереснее)!

15. Последние 10 процентов

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

Если вас это смущает, не отчаивайтесь. Да, последние 10 процентов бывают мучительными, но именно в это время ощущаешь отдачу от проекта. Именно в этот период, если вы правильно распределили свое время, начинает складываться «общая картинка». А превращение потока хаотичных идей и контента в стройную и красивую игру – удивительное чувство.
Всё дело в деталях.

И наконец… Релиз!
Еще один плюс в том, чтобы иметь готовые общие проекты, – ваши партнеры знают, на что вы способны, поэтому им комфортнее с вами работать. Очень трудно убедить опытных людей работать с вами на одной только идее, особенно если учесть, насколько небольшой процент этих идей будет реализован (и как сложно оценить значимость некоторых идей до их непосредственного воплощения). Хорошие партнеры хотят видеть ваши готовые проекты. Так что доделывайте их!

Как вариант, найдите бесплатную графику и музыку онлайн – по крайней мере в качестве заглушек (у нас на Independent Gaming Source проходил конкурс, в рамках которого было создано много бесплатного графического контента и музыки). Если нужно, используйте ASCII. Мне как художнику гораздо интереснее участвовать в проекте, который уже почти готов, и осталось только сделать графику. А если вам нужен программист… Попробуйте научиться кодить – если я смог, то и у вас получится – или воспользуйтесь специализированным ПО для разработки игр (см. п.3).

7. Рутина — это нормально. Включите ее в план

Большая часть разработки игры – это скука и рутина. Это не игра, а работа, поэтому смело душите любого, кто решит сострить на тему «ты целыми днями в игры гоняешь». В какой-то момент вы внезапно осознаете, что есть куча вещей, о которых вы не думали во время планирования своего проекта и разработки логотипа, – штуки вроде меню, переходов, сохранения и загрузки. «Блин! Я считал, что буду создавать крутые игровые вселенные, экспериментировать с игровыми механиками! Я не думал, что застряну на несколько месяцев, пытаясь сделать хоть сколько-нибудь приличное меню!». А еще есть вещи, которые увлекательны в малых дозах, – например анимация персонажей, – но становятся невыносимыми, когда понимаешь, что тебе нужно анимировать около сотни юнитов.

Пройдя через это пару раз, вы поймете, как важно соизмерять объем работ, чтобы не торчать в этом болоте слишком долго («слишком долго» – это вплоть до того момента, когда вы бросите проект). А еще вы поймете, как важна для игры вся эта скучная ерунда! Например, хорошая заставка чудесным образом улучшает презентабельность игры.

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

Когда мы с Алеком работали над Aquaria, срок подачи заявок на Independent Games Festival заставил нас принимать жесткие решения о направлении нашего движения и реалистичнее оценить наш график. Если бы над нами не висел этот дедлайн – не знаю, завершили бы мы проект или нет! Участвовать в конкурсах и соревнованиях очень полезно – там строгие дедлайны, и вознаграждение (признание, награды, иногда деньги) тоже ощутимое. А еще это отличный способ познакомиться с единомышленниками.

9. Избегайте пробуксовки

Застряли? Делайте что-то другое. Работайте над следующим уровнем, новым врагом – чем угодно. Это полезно не только с точки зрения мотивации – так вы сможете лучше понять, как в конечном итоге будет выглядеть ваша игра. Ведь если вы пишете книгу, вы же не придумываете по одному предложению, переделывая до безупречности каждую фразу, прежде чем написать следующую. Делайте общие наброски.

10. Следите за своим физическим и психическим здоровьем

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

Я обнаружил, что есть 3 типа игр, которые меня интересуют: игры, которые я хочу делать; игры, которые я хотел бы сделать; игры, которые у меня хорошо получается делать.
Игры, которые я хочу делать, – игры, в которых сам процесс разработки кажется мне увлекательным. Это может быть механика, с которой круто поэкспериментировать, или персонаж, которого мне очень хочется анимировать.
Игры, которые я хотел бы сделать, – это игры, в которых для меня важнее результат, а не процесс. Это может быть ничем не ограниченный концепт («Ух ты, смесь GTA с Final Fantasy, а еще со Starcraft и…») или просто симпатичная идея, реализация которой не принесет мне особого удовольствия.
Игры, которые у меня хорошо получается делать, – это близкие мне по духу игры, в создании которых у меня есть опыт. Это может быть определенный жанр, к которому вы тяготеете, хорошо понимая его законы и ритм.
По-моему, самые многообещающие идеи (или по крайней мере те, которые с большей вероятностью будут закончены) попадают во все 3 категории и соответствуют условию «у меня есть время и ресурсы для того, чтобы сделать это».

2. Начните, наконец, работать над игрой

Записать идеи – не значит начать работу над игрой. Написать дизайн-документ – не значит начать работу. И собрать команду – не значит начать работу. И даже работать над графикой или музыкой – не значит начать работу. Очень легко спутать понятия «готовиться работать над игрой» и «начать работать над игрой». Просто запомните: игра – это такая штука, в которую играют, и если вы не сделали ничего, во что можно поиграть, это не игра!
Черт возьми, даже делать игровой движок не всегда значит работать над игрой. Что подводит нас к следующему пункту:

3. Не заморачивайтесь с движком без необходимости

В разработке собственного движка есть «за» и «против». Спросите себя, так ли это необходимо. Действительно ли то, что вы делаете, невозможно реализовать с помощью уже существующих разработок? Не собираетесь ли вы изобретать велосипед? Конечно, можно написать собственный движок и сделать его, по вашему мнению, идеальным. Но если честно – сколько раз вы переходили от написания движка непосредственно к созданию игры? Может быть, вы чаще создаете не игры, а движки?

Я создал оригинальную версию Spelunky в Game Maker и именно благодаря этому готовому проекту смог поработать над версией для Xbox 360. Не нужно думать, что софт для создания игр и упрощенные инструменты – это непрофессионально. Самое главное – это игра.

4. Создайте прототип

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

5. Убедитесь, что основные механики интересны

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

6. Выбирайте хороших партнеров (или работайте в одиночку сколько сможете)

Создавать с партнером компьютерные игры – как строить отношения. Мы привыкли думать, что главное здесь – умение: «О, круто, я программист, а тот парень – художник, поехали!». Но нужно учитывать еще и характер человека, его опыт, ритм работы и ваши с ним общие интересы. Как в романтических отношениях – вы же не хотите, чтобы кто-то из вас отдавал меньше, чем получает. Испытайте друг друга на более мелких проектах, ведь когда важный для команды человек внезапно уходит через несколько месяцев или лет разработки – это очень тяжело.
Как закончить игру
Автор Derek Yu (оригинал статьи доступен по ссылке)

Заканчивая работу над собственной игрой, я много размышлял о завершении проектов вообще. Я заметил, что есть множество разработчиков, которые не могут довести дело до конца. Если честно, за мной тоже тянется шлейф так и не завершенных игр, думаю, как и за каждым из нас. Не всем проектам суждено «выстрелить» – по разным причинам. Но если вы стали замечать, что постоянно бросаете игровые проекты с хорошим потенциалом, стоит остановиться и задуматься, почему так происходит.

1. Выбирайте идеи с хорошим потенциалом
2. Начните, наконец, работать над игрой
3. Не заморачивайтесь с движком без необходимости
4. Создайте прототип
5. Убедитесь, что основные механики интересны
6. Выбирайте хороших партнеров (или работайте в одиночку сколько сможете)
7. Рутина — это нормально. Включите ее в план
8. Используйте конкурсы, соревнования и другие события в качестве дедлайнов
9. Избегайте пробуксовки
10. Следите за своим физическим и психическим здоровьем
11. Не заморачивайся на качестве кода
12. Сохраняйте идеи на другой проект
13. Убирайте лишнее
14. Если все-таки бросаете, уменьшайте размах, а не увеличивайте
15. 90 процентов работы – в последних 10 процентах работы

Всё дело в деталях.
Web-страница:
Finishing a Game
As I work towards completing my own game, I've been thinking a lot about finishing projects in general. I've noticed that there are a lot of talented developers out there that have trouble finishing...
И вдруг опять внезапно, пятница. Подливая масло в огонь 😈 хочу поделится небольшим историческим фактом про историю возникновения Open Space офисов от кандидата исторических наук Александра Байрамова. Информация спокойно гуглится, в достоверности можно не сомневаться.

Идею рабочих мест в виде open space связывают с именем светлейшего князя Потёмкина, поскольку как раз в его имении проводились подобные эксперименты. Это происходило в 1786 г. в местечке Кричев, в Могилёвской губернии.

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

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

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

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

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

Правда, впоследствии подобный паноптикум всё-таки применили в устройстве офисов, что не отменяет характеристику, которую Маркс дал этому проекту: «вершина буржуазной глупости».
Требования к игровому функционалу
https://telegra.ph/Trebovaniya-k-igrovomu-funkcionalu-07-09

Сара Сантиллан, Lead Designer в Boomzap Entertainment, рассказывает о требованиях к созданию игрового функционала. Что понадобится, а что – нет в этом творческом процессе?

Если вы делаете игры, принадлежите ли вы к индустрии программного обеспечения?
Краткий ответ – нет.
Web-страница:
Требования к игровому функционалу
Развлекательная функция игр – вещь абстрактная. И чтобы создавать игровые миры, в которые пользователю захочется погружаться с головой снова и снова, придется очень многое продумать. Сара Сантиллан, Lead Designer в Boomzap Entertainment, рассказывает о требованиях к созданию игрового функционала. Что понадобится, а что – нет в этом творческом процессе? Быстрый вопрос: если вы делаете игры, принадлежите ли вы к индустрии программного обеспечения? Краткий ответ – нет. Более развернутый – отчасти да, но в целом…
Актуально: Опыт удаленной фасилитации собраний и проведения ретроспектив.

Спикер: Роман Малашнёв, ЦФТ

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

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

https://www.youtube.com/watch?v=WwQZPenAsgk&feature=youtu.be
Web-страница:
2 Роман Малашнёв – Опыт удаленной фасилитации собраний и проведения ретроспектив
Спикер: Роман Малашнёв, ЦФТ

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

Я расскажу про опыт удаленной фасилитации групповых обсуждений, таких как ретроспективы, совещания. Мы разберем подготовку и основные этапы проведения ретроспективы/совещания, а также рассмотрим инструменты, которые можно использовать для повышения эффективности онлайн-встреч.
Календарь событий игровой индустрии
: 3608 | на пост: 1070 | ER: 29.7%
Публикации Упоминания Аналитика
CGC | LIVE
22 -26 сентябрь 2020 г.
онлайн

Cutting-edge Games Conference приглашает разработчиков видео игр и геймеров стать частью захватывающего мира новых технологий, познакомиться с возможностями их реализации в играх, вдохновиться идеями и опытом коллег, совершив виртуальную прогулку по выставочной зоне и конференц-залам в течение пяти дней мероприятия!


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

Почему нужно посетить CGC | LIVE?

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

Спикеры
Вашему вниманию будут предложены интереснейшие и познавательные презентации от спикеров мирового класса. В сочетании с горячими дискуссионными панелями и личными встречами, эти выступления изменят ваше мнение о будущем игр и о грядущих стремительных изменениях в индустрии. Будьте среди первых, кто получит эти знания и извлечет выгоду из технологий, меняющих игровой мир каждую минуту! Более 100 спикеров осветят важнейшие темы в рамках 10 треков, которые нельзя пропустить:

Гейм дизайн
Киберспорт
Мобильные игры
Блокчейн игры
Игры на ПК и консоли
Виртуальная и дополненная реальность
Инди игры
Гипер-кэжуал игры
Привлечение инвестиций
Маркетинг и монетизация
И это еще не все…
CGC Showcase представит инновационные и экспериментальные игры, создаваемые инди-разработчиками. А эксклюзивные призы и конкурсы от компаний-участников не оставят никого равнодушным.


Хотите узнать как продвигать свой игровой стартап, найти инвесторов, создать собственную игру и узнать, на какие тенденции следует обратить внимание в ближайшем будущем? Желаете получить практический опыт, узнать, о чем будут говорить спикеры, и какой инди-проект получит желанный приз?
Спешите купить билет и присоединяйтесь к пятидневному празднику геймдева CGC | LIVE!

Контактное лицо:

Мария Яковлева: mary@cgc.one

CGC в социальных сетях:
Facebook Facebook (мероприятие) Telegram Twitter Instagram LinkedIn


Полезные ссылки:
Стать спикером
Стать медиа партнером
Заявка на участие в CGC Showcase
Стать спонсором

О мероприятии: https://cgc.one/
Web-страница:
CGC
CGC. 393 likes · 12 talking about this. CGC (AKA Crypto Games Conference) is the world’s first business event for gaming professionals harnessing the power of blockchain, VR, AR. The past three...
Однозначно, иногда нагрузку на команды нужно снижать. Хотя бы для того чтобы стало возможным оглянутся назад, провести ретроспективу, подвести итоги и наметить новые цели. Но если низкая или нулевая нагрузка сохранится длительное время, это плохо влияет на настрой команд и чревато падением общей производительности и раскачкой на старте. В подобные моменты я бы рекомендовал ставить задачи по поиску вариантов оптимизации и улучшению продукта.

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

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

📡 Обратная связь / Фидбек @gameprod_bot
Game Dev Conference 2020
https://gdconf.com/

В этом году конференция GDC проходит в онлайн формате 4-5-6 августа. Но уже сейчас доступны несколько интересных докладов:
- Mastering Kombat: Designing Mortal Kombat 11's Empowering Tutorial Mode
- Until You Fall: Building Satisfying VR Combat on a Budget
- Machine Learning Summit: Successfully Use Deep Reinforcement Learning in Testing and NPC Development
- Clash of Clans: Bigger, Better, Battle Pass
- Machine Learning for Optimal Matchmaking
- Matchmaking for Engagement: Lessons from Halo 5
- From Assassin's Creed to The Dark Eye: The Importance of Themes

Ссылка на общий плейлист
Изображение
Позднее разработчики добавили множество функций – видеозапись, фильтры, таймлайны и даже создали очки для видеосъёмки. Нет ничего плохого в том, что продукты становятся более сложными. Выпуск продукта по принципу SLC не означает, что он в будущем не будет эволюционировать.

Применяя данный принцип, вы получаете лучшие результаты и более благоприятные условия для дальнейших шагов. Если не получилось – ничего страшного. Значит, эксперимент не удался. Ни MVP, ни SLC не застрахованы от провала, ибо всё это эксперимент. Однако если эксперимент с SLC удался, то ваш продукт уже имеет экономическую ценность, и у вас есть множество доступных вариантов его развития, ни один из которых не является срочным. Работайте над версией v2.0, и, поскольку ваш продукт уже имеет ценность, у вас будет больше времени подумать над тем, как должна выглядеть следующая версия. Можно даже провести опрос среди имеющихся пользователей на тему того, что точно следует включить в версию v2.0, вместо того, чтобы нанимать армию альфа-тестеров, интересующихся лишь тем, когда вы «пофиксите баги».

Или же вы решите не разрабатывать новую версию. Не каждый продукт должен становиться сложным. Не каждый продукт требует выпуска обновлений со значительными изменениями раз в полгода. Некоторые вещи могут оставаться простыми, привлекательными и полноценными. Спросите своих пользователей. Они согласятся.
Существует множество способов, чтобы сделать продукт привлекательным. «Минимальность» и «жизнеспособность» явно не входят в их список. Популярный в настоящее время подход к созданию привлекательного продукта кроется в его дизайне: необходимо сочетать удачный опыт взаимодействия (UX) с удобным пользовательским интерфейсом (UI). Но есть и другие способы. Культура компании-разработчика и ее отношение к пользователям может сделать продукт привлекательным. Например, блоги компании Buffer с её поразительной прозрачностью, MeetEdgar, действительно помогающая предпринимателям, а также HubSpot, чей блог с самого начала был, как минимум, так же полезен клиентам, как и сама платформа HubSpot. Другой способ заключается в глубоком понимании образа мышления и стиля работы клиентов. В качестве примера можно привести Heroku, которая порвала с традиционной маркетинговой моделью и вместо описания выгод использования разместила на своей домашней странице образцы параметров командной строки, таким образом наладив прямую связь со своей продвинутой целевой аудиторией.

Для MVP есть правильная альтернатива – SLC, вот составляющие: Simple, Lovable и Complete – Простота, Привлекательность и Полноценность. Мы в WP Engine произносим это как «слик» (англ. slick, созвучно аббревиатуре SLC – прим. перев.). Например: «Какова «сликовая» версия вашей идеи?»

Помимо всего вышесказанного, у принципа SLC есть ещё одно преимущество, которое вы ощущаете в ходе разработки следующей версии своего продукта.

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

Говоря о циклах разработки продукта, часто используют мем, точно отображающий принцип SLC (хотя сам этот термин там и не использован). Взгляните на диаграмму: «Виды транспорта» от команды разработчиков Spotify.

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

Подробнее рассмотрев один из примеров, о которых мы упоминали, Snapchat, можно увидеть, что его разработчики действовали по принципу SLC подобно метафоре с видами транспорта. В первой версии продукта был создан экран, прикасаясь к которому в любой точке, можно было сделать фото и отправить его кому-либо, указав, через сколько секунд после получения изображение исчезнет с устройства получателя. Никаких видео, фильтров, социальных сетей, комментариев и никакого пространства для хранения данных – всё просто. Однако продукт привлекательный и полноценный, судя по тому, как он массово распространялся среди пользователей. Решающей в плане привлекательности была идея не хранить фотографии, однако многие предполагали, что простота интерфейса сыграла не меньшую роль. Успеху способствовал сам факт того, что продукт был простым до невозможности (при этом разработчики не жертвовали его полнотой и привлекательностью).
MVP это не лучший метод. Он довольно эгоистичен и оскорбителен для пользователей. Мы не будем выпускать MVP для WP Engine.

Причины появления концепции MVP до сих пор актуальны:

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

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

3. Если проект себя не проявил, его можно закрыть, а если в нём просматривается потенциал – проинвестировать.

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

Проблема в том, что пользователи ненавидят MVP. Великий Рид Хоффман (Reid Hoffman) призывает запускать стартапы на рынок «достаточно рано, чтобы вам было неловко за первый релиз продукта». Однако никто не захочет пользоваться продуктом, в котором не уверены сами его создатели. Пользователям нужны отличные продукты, готовые к применению прямо сейчас.

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

К счастью, существует лучший способ создать и опробовать новые продукты. Чтобы это понять, следует отдать должное вышеперечисленным полезным атрибутам MVP, при этом уделяя как можно больше внимания клиентскому опыту.

Чтобы продукт был небольшим и быстро попал к пользователям, он должен быть простым. Пользователи каждый день соглашаются использовать те или иные простые продукты. Они простят отсутствие у продукта всех необходимых функций, если продукт не был заявлен как нечто большее. Например, все спокойно отнеслись к тому, что ранние версии Google Docs могли выполнять лишь 3% функций Microsoft Word, поскольку Google Docs блестяще обеспечивал то, для чего изначально был предназначен – простоту в использовании и совместную работу в режиме реального времени.

Продукт был простым, но полноценным. Это значительно отличается от классической концепции MVP, которая по определению не является полноценной (и поэтому смущает разработчиков). «Простота» – это хорошо, а вот «неполноценность» – плохо. Предполагается, что клиент искренне хочет использовать продукт «как есть». И не потому, что это «версия 0.1» чего-то сложного, а потому, что это «версия 1.0» чего-то простого.

В том, что продукт может быть одновременно простым и полноценным, нет никакого противоречия. В качестве примеров можно привести ранние версии WhatsApp, Snapchat, Stripe, Twilio, Twitter и Slack. Некоторые из них затем были расширены и усложнились (Snapchat, Stripe, Slack), в то время как другие остались верными принципу быть проще (Twitter, WhatsApp). Авиакомпания Virgin Air начиналась всего с одного маршрута – короткого, но полноценного.

Наконец, немаловажно то, что продукт должен быть привлекательным. Необходимо, чтобы люди хотели им пользоваться. Привлекательные продукты с меньшим набором функций более успешны на рынке, нежели продукты со множеством функций, но нелюбимые пользователями. В качестве примеров можно привести малофункциональные, всенародно любимые и крайне успешные ранние версии программ, упомянутых в предыдущем абзаце. Успешность продукта в ходе эволюции зависит от его привлекательности, а не функционала.
Интересное мнение Джейсона Коэн (CTO стартапа WP Engine) относительно MVP. Он считает, что пора пересматривать подходы в работе с пользователями, призывает отказаться от MVP.

Альтернативой предлагает SLC – продукт, который не требует постоянной доработки. Чем SLC лучше MVP читайте в переводе публикации Джейсона.

Подписчикам однозначно стоит ознакомиться со статьей. Как всегда истина где-то рядом.

Уже лет десять разработчики поют старую песню про MVP (Minimum Viable Product, минимально жизнеспособный продукт), не пересматривая свой взгляд на правильность того или иного способа накопить больше знаний о потребностях пользователей и при этом угодить им.
Изображение
1. UI. Убедитесь, что интерфейс поддерживает вашу фичу. Заранее делайте макеты основных окон.
2. Пользовательский поток. Прежде чем отдавать новую фичу в разработку, убедитесь, что в ней учтены и продуманы все окна и их сочетания в пользовательском потоке. Что за поток? Читайте здесь: Mobile UI and Game Design: Screens vs. Flows.
3. Пограничные случаи. Продумайте все основные пограничные случаи. Что это такое? Пограничные случаи – это игровые ситуации, которые находятся за рамками нормального потока геймплея, но их тоже нужно прорабатывать. Проверьте, что в пограничных случаях нет подводных камней.
4. Влияние на систему. Подумайте, как новая фича повлияет на баланс и экономику вашей игры. Как она отразится на других системах в вашей игре. А в разных частях интерфейса? Убедитесь, что нигде не будет противоречий.
5. Влияние на проект. Как новая фича повлияет на геймплей, проектные параметры и монетизацию? Если вы сходу добавите новую PvE-фичу в PvP-игру, это может привести к КАТАСТРОФЕ. Как это отразится на ожидаемой и фактической монетизации? (Подробнее здесь: Monetization-based Game Design: ARPDAU Contribution) Подумайте над этим!

Но всё же, бывают случаи, когда лучше использовать итеративный подход вместо планирования. Например, в экспериментах с новыми типами геймплея, если именно это является основной задачей и главным риском. Кроме того, смысл не в СВЕРХпланировании. Рассматривать перечисленные выше вопросы проектирования стоит настолько, насколько это необходимо для каждой конкретной фичи, типа игры, ваших целей и т.д. Именно ваш отдельно взятый случай будет определять ваше Максимально Жизнеспособное Планирование. Стандартного решения всех проблем не существует.

В зависимости от ситуации, более тщательного планирования, как правило, требуют такие типы игр:

• Более сложные – комплексные, многосистемные, с большим количеством взаимосвязей; здесь необходимо понимать, как новая фича повлияет на всё остальное в игре.
• Больше UI – тоже более сложные, но в плане большого количества окон;
• Мультисистемные — чем хардкорнее ваша игра, тем больше в ней систем.

В завершение:

• Надеюсь, эта публикация поможет кому-то из вас увеличить шансы на успех вашего продукта за счет планирования.
• Нужно понимать, когда ситуативно использовать планирование, а когда — итерацию.
• Используйте вышеупомянутые приемы для уменьшения итераций на продакшене; основная часть планирования должна выполняться на первых этапах разработки игры, когда стоимость изменений еще сравнительно небольшая.
Мобильный гейм-дизайн: итерация vs. планирование и опасности MVP. Перевод, автор Joseph Kim

Всем гейм-дизайнерам, которые не занимаются планированием, я хотел бы сказать:
«Остановитесь! Вы опасны. Вы изматываете разработчиков. Вы напрасно тратите драгоценное время и ресурсы, которые можно было бы легко сэкономить, уделяя достаточно внимания планированию. Проектирование на скорую руку оборачивается задержками в общей разработке. Спешка втиснуть новые полусырые фичи аукнется вам в виде незапланированных расходов. Работайте нормально!»

Как же делается качественное планирование?
Как правило, мобильный гейм-дизайн делится на две базовые школы принципов разработки:

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

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

На мой взгляд, стало слишком много людей, которые чересчур увлеклись методом итерации. Эти люди возвели MVP (англ. minimum viable product — минимально жизнеспособный продукт) в статус культа и сделали метод MVP универсальным костылем и дешевой отговоркой для того, чтобы не особо тщательно продумывать все фичи. Сторонники MVP-подхода часто приводят аргументы вроде:

• “Мы просто можем проитерировать это потом”
• “О монетизации подумаем позже, а пока нужно сделать интересно”

К сожалению, нетехнические разработчики не понимают, что игровой код не резиновый. Это вам не пластмассовые блоки LEGO собирать. Игра – не пластилин, ее нельзя сильно перекроить без существенных последствий. Всё потому, что код (особенно игровой код с изрядным количество хардкода) относительно негибкий.

На этот счёт у меня довольно радикальная точка зрения: я считаю, что многие гейм-дизайнеры, которые используют метод итерации в мобильных free-to-play играх, просто опасны тем, что могут загубить своей ленью целые команды разработки.

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

Закон Кима:
Разрабатывай Минимально Жизнеспособный Продукт с Максимально Жизнеспособным Планированием

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

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

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

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

Как же делается качественное планирование?

На самом деле, всё сводится к таким основным задачам:
Web-страница:
Mobile Game Design: Iteration vs. Planning, MVP = Dangerous!
The following blog post, unless otherwise noted, was written by a member of Gamasutra's community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company. Mobile game design typically follows two primary schools of design philosophy: Iteration
Важно чтобы каждый из используемых коммуникационных процессов дополнял и усиливал все используемые. Менеджеры часто действуют интуитивно, иногда на автомате, но если разобрать по полочкам, библиотека процессов на более менее-крупном проекте будет весомой.

📡 обратная связь / фидбек @gameprod_bot
Зарегистрироваться в Slack и создать каналы, не является налаженной коммуникацией.

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

По разным оценкам, менеджеры, тратят от 70% до 90% времени на организацию и поддержание коммуникаций в командах.

Для меня коммуникации проекта это:
- Процессы планирования работы
- Сбор обратной связи от команды и бизнеса
- Создание и рассылка всевозможных отчетов
- Организация совместного доступа к проектной информации
- Контроль качества исполнения работ
- Мониторинг своевременного выполнения работ
- Организация и проведение собраний
- Проведение презентаций и демонстраций
Видео/гифка, 5 сек, Script Text Google+ Photo.mp4
Формирование команд. Аутсорсинг. Часть 2.

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

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

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

- Тестируй команды. У тебя в запасе должны быть задания, выполнив которые ты сможешь проверить уровень мастерства команды. У тебя должен быть эталонный результат, сверив с которым ты сможешь ориентироваться и принимать решения.
- Если по каким-то причинам ты не можешь удостовериться и подтвердить для себя уровень квалификации аутсорсеров, привлекай стороннего подрядчика. Это нормальная практика, но заявить об этом стоит в начале знакомства с командами.
- Если замечаешь серийные факапы, не стесняйся просить замену косячника в команде, включая менеджера.
- Контролируй. Договоритесь о коротких итерациях по результату которых ты сможешь фиксировать соответствие продукта твоим ожиданиям. Не отпускай ребят в большое плавание без контроля потому что формально задача может быть поставлена и выполнена верно, но результат нужен совершенно другой. Мелкие правки дешевле крупных переделок.
- Составляй NDA с аутсорсером таким образом, чтобы в нем были перечислены все участники проекта которые могут нести ответственность за разглашение. Этот момент важен. Аутсорсеры часто нарушают NDA и демонстрируют результаты труда при личных беседах с потенциальными заказчиками. Не нужно недооценивать этот риск. никогда не знаешь кто из конкурентов будет на презентации у твоих партнеров.
- Результат интеллектуального труда по документам должен переходить к твоей студии. Вместе с тем тебе стоит удостовериться, что внутри компании верно оформлены юридические документы между сотрудниками и компанией о передаче интеллектуальной собственности. Это важно. История знает случаи когда успешные проекты получали судебные иски за использование "чужого" труда в своих коммерческих целях.
- Хорошая аутсорс команда будет стараться перетянуть на свою сторону продуктовые знания проекта, чтобы тебе А) было дорого Б) страшно В) неразумно Г) невозможно сменить подрядчика. Поэтому тебе адски необходима хорошая документация. Закладывай время на ее создание в смету. Контролируй ее написание и редактирование в соответствии с внедряемыми изменениями.
- Передача кода и прочих исходников. Забирай всё, вплоть до рабочих драфтов, эскизов. Абсолютно всё. Никогда не знаешь что будет завтра. Может они закроются.
- Организуй гарантированное хранение полученной информации на своей стороне. Гарантированное это значит с резервными копиями. Узнай каковы условия хранения данных на стороне исполнителя. Удаляют ли они данные по завершении проекта или по твоему запросу.

📡 обратная связь / фидбек @gameprod_bot

Найдено 54 поста