Короче, всем привет опять. Илья @meenauh Осташко на проводе. Будем за андерхуд, манжеты и гейм-дизайн тереть. Вываливайте всё, что накипело.

Если кто запамятовал или отсутствовал, я уже проводил андерхуд: gdunderhood.ru/meenauh/. Это были лекции в одностороннем порядке. Исправим.

Помню в конце прошлой моей недели кто-то сказал «заходи ещё». Захожу.

Где же новые авторы и куда пропали 2 недели? Я тоже не знаю. Все решили релизить что-то в марте повально и заняты.

А, ну на минуточку. Давайте расскажу про сам андерхуд и как это всё устроено.

Есть такой @vedmich. Он следит за трендами и именно он собрал всех вместе под знаменем gdcuffs.com. Андерхуд — тоже его идея.

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

Я же занимаюсь обновлением gdunderhood.ru и поиском новых авторов (Ник тоже этим занимается). Потому пишите, если хотите недельку.

В этом году мы обещали, что будем приглашать иностранных авторов. И начали приглашать. И ещё есть на подходе немного позже.

Только одно «но». Что-то активности от читателей и общения я особо не наблюдал :) Это же отличный способ сравнить подходы к гейм-дизайну.

Читатели, расскажите, почему такая низкая активность на иностранцах? Чего не хватает? Скучно/неинтересно/бесполезно? Кого пригласить?

Читатели, расскажите, почему такая низкая активность на иностранцах? Чего не хватает? Скучно/неинтересно/бесполезно? Кого пригласить?

Давайте ещё покидаем интересные форматы для андерхуда. Возможно, не просто пригласить кого-то, а мероприятие провести интересное.

У нас, например, уже был гейм-дизайнерский джем с @YarKravtsov: gdunderhood.ru/YarKravtsov/

И симулятор создания игры мечты от @luayan: gdunderhood.ru/luayan/

Сложное я тестировал на бумаге. Один гд сварганил небольшую настолку из бумажек и маркеров наподобие goo.gl/EDb7cH (но типа D&D).

@gdunderhood Проще дискутировать с ведущими, рассказывающими истории из своей практики. На "спросите у меня что-нибудь" думать нужно.

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

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

Я на основе этой игры потом писал концепт. По сути Dungelot + King of Thieves. Ты должен искать в космосе «оффлайн»-станции и рейдить.

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

Утро доброе. Про андерхуд поговорили. Больше историй из опыт — по ним проще общаться, чем думать над вопросами. И интерактивчику. Ок.

Давайте поговорим о другом, более глобальном начинании @vedmich — Манжеты Гейм-дизайнера. Во-первых, никогда не пишите Манжеты Гейм-дизайна.

Вы же прекрасно знаете, что ГД обычно применяют к людям, а не к сфере в целом. «У меня 2 джун гд», «ищу себе крутого гд в команду».

Вряд ли услышав вопрос «Как у тебя с гд в проекте?» вы подумаете про гейм-дизайн, а не про наличие гейм-дизайнера на проекте.

Так вот, твиттеряне, за что вы любите и ненавидите @GDcuffs? Чего не хватает? Чего слишком много? Что хочется видеть прямо завтра, например?

Я понимаю, что все в спешке побежали смотреть, что же это за gdcuffs.com такой :) Каких вам материалов/форматов вам не хватает?

Суть вот такая: chakerhamdi.wordpress.com/2013/03/24/sig…
В статье напишу «зачем» и постараюсь описать с какой стороны к этому подойти.

@gdunderhood @GDcuffs аналитики мало! :D Всего 4 статьи!

@gdunderhood про ui/ux что нибудь не общее запилите

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

@gdunderhood по левел-дизайну. И не общее типа "локация должна рассказывать историю", а конкретно. Как делать уровни для, допустим,сокобана

Так. У нас тут в стране праздник! Дорогие девушки-гд и не только! Поздравляю от всей гейм-дизайнерской души с праздником!

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

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

Господа читающие! Есть ли среди нас фриланс-гейм-дизайнеры? Расскажите, каково это и какие задачи вы обычно выполняете.

Придумал. У меня есть любимая презентация от Саши Штаченко: goo.gl/e6DBze. Там за многие пункты ответственен гд. Давайте разберём.

Ну, пойдёмте: Game Design Document
take.ms/coxWY

Тут два ключевых момента — сеттинг и кор-геймплей. Даже нет. Кор-геймплей.

По своему опыту могу сказать, что первые прототипы должны служить proof of concept именно основной механики.

Да, возможно сеттинг является продающим, но играть они буду в кор-геймплей. Его-то и нужно итеративно полировать до блевания радугой.

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

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

Двинем дальше: User Experience Flow
take.ms/LRt2O

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

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

Кор-геймплей с щепоткой меты сформирует ваш первичный (Primary) цикл, в котором игрок будет проводить каждый свой день.

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

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

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

Например, во время 15-минутной сессии у вас есть прогресс, но вы умираете.

Можно начать сначала бесплатно. А можно за хард реснуться на месте с 25% хп. За 3х харды можно реснуться на месте с 100% хп.

Вовлечение в сессию и ценность потраченного времени монетизирует игрока. Точка монетизации в основном цикле.

Это спонтанная монетизация, основанная на импульсе. Вообще роляет. Даже в мете всё тоже может быть основано на ней же.

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

Игрок ставит себе цели в игре. Краткосрочные и долгосрочные. К каждой цели его может вести заготовленный для него цикл.

Далее: UI Wireframes
take.ms/eXasF

Моё любимое. Тут нужно уже много разнообразных знаний и кругозора игрового. Чтобы все ваши циклы обернуть в удобные интерфейсы.

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

На этом этапе важно ПРИКИНУТЬ объём интерфейсов. Все экраны, куда игрок может попасть и как его не запутать, чтобы его метациклы работали.

Я лично делают UI Flow Chart (карту интерфейсов) абстрактно с названиями экранов, определяя, сколько максимум экранов надо на какую фичу.

Боёвкой, например, нужно заниматься отдельно. Там флоу экранов нет, но там есть понятный чистый HUD и хороший UX, которые определят многое.

По процессам, которые участвуют в обеспечении хорошим UX и подготовку wireframes, наверное, статью напишу в @GDcuffs.

Когда гейм-дизайнер говорит «В прошлый раз много писал, в этот раз будет меньше», не верьте.

Дальше вообще сок: AERM
take.ms/a4ocK1

Благодаря Саше узнал о такой штуке и теперь считаю, что для f2p-проектов это вообще must have point в препродакшне.

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

Берётся путь юзера: привлечение→вовлечение→возврат→монетизация. И прописываются фичи в 3 разрезах: Кор, Мета, Социальность.

Можно позволить себе оставить какие-то ячейки пустые. Конечно! А можно ещё самому донатить в проект, так как он чёт не зарабатывает.

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

Social Description Document
take.ms/840Mu

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

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

Разрабатывать игру в вакууме никто не мешает. Но разгружать вагоны тоже весело. Или в макдональдсе всегда лишние руки не помешают.

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

Ваша задача — обеспечить социализацию в игре, притом удобным и ненавязчивым образом. Чтобы рассказать другу ХОТЕЛОСЬ самому игроку.

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

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

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

Ибо я встречал личностей, которые заявляли, что не обязательно понимать игру, чтобы продвигать её. ¯\_(ツ)_/¯

Ну, и напоследок не ответственность ГД, но всё же: take.ms/baEUa

Первый майлстоун — MVP. Там вы полируете ваш кор-геймплей. Сфокусируйтесь и не распыляйтесь. Вы сами должны быть довольны результатом.

Второй — пре-альфа. Пройдёт прилично времени после первого этапа и вы соберёте базовые циклы и сможете поиграть в основные механики.

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

И, наконец, игра "готова", юзеры насобирали вам 1.5 тысячи багов, вместо одного меча у вас теперь 17 — вы готовы к Бете. Пути назад нет.

Вот вы уже работаете с аудиторией, никого не вайпаете (не факт!), и ведёте себя так, будто релиз. Только в случае факапа есть козырь — БЕТА.

@gdunderhood для пункта "монетизация" Адам Телфер выкатил отличный гайд, по которому он читал лекцию на GDC'17
adamtelfer.files.wordpress.com/2017/03/gdc201…

Тредов получилось много. Читайте, радуйтесь жизни, а завтра поговорим о чём-нибудь ещё.

Например, как тач-полоска на новых макбуках спасёт инди-сцену российского геймдева.

@gdunderhood зависит от заказчика, были и мелкие задачи, но были и с погружением полным. Но вообще сложно делать ГД без погружения мелкого.

Всем приветы в этом сегодняшнем чате. Я передумал говорить с вами о том, о сём, потому буду говорить об этом.

Давайте поговорим о насущном (для меня). Вот у меня игра — аркадные шутеропокатушки на сборных танках. Весело, быстро, занимательно.

Игрок такой собирает себе сам танк из 7 корпусов и 11 пушек, идёт пиу-пиу, прыгает, летает, переворачивается, всё взрывается, красиво.

Была расходка в игре. Имбовала. Я вот взял и убрал её как сущность. Сделал вместо этого абилки.

Да абилки-то непросыте, а кас-то-ми-зи-ру-е-мы-е. Корпуса недостаточно различаются, говорите? Вот вам роли теперь.

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

Вроде как неплохое подспорьте, но не всё так просто. Модули-то крафтятся! Детальки выбил, купил, модуль собрал, вставил, катайся.

И тут самое интересное. У модуля есть одна из 132 генерирумых характеристик. Шанс выпадения тоже у них разный. И тут начинается гринд.

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

@gdunderhood ну тут такое, если в самих пострелушках все оч скилбэйсд (кс, квейк), то тогда сложновато. А если же решают статы, то тогда ок

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

@gdunderhood а в с такой точки зрения уже тяжеловато, так что осторожно своё имхо скажу просто: pic.twitter.com/oFFE59Y3bT

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

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

Как вообще фичи появляются в проектах. На всех моих проектах всё было по-разному. Распространюсь о самом актуальном.

Откуда приходит фича? Откуда угодно — гд, пм, маркетолог, км, художник, программист. У всех бывают дельные идеи и я их выслушиваю.

Если идея звучит как шлак — не спеши её отмести. Возможно, её можно переделать. Но главный вопрос — зачем.

Ведь у проекта есть цели, которые надо выполнять. Старайтесь не распыляться и отбирать только ценное для выполнения целей.

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

Вот, допустим, цели поставлены и следующий рабочий этап разбит на майлстоуны и состоит из 4 крупных фичей.

Беру я фичу наивысшего приоритета и начинаю думать. Первое, что делаю — мокапы (если это не чисто механическая фича), точнее прикидка.

Прикидываю, что может быть в интерфейсе. Это помогает сформировать видение фичи с точки зрения игрока и разбить её на много user stories.

Разбиваю док на подпункты, для каждой завожу user story и сажусь прописывать, подкрепляя всё мокапами. Док потихоньку формируется.

Дальше я кое-что не делаю, но собираюсь делать — интерактивные прототипы (если фича полностью новая и не в 2 кнопки) в Adobe Xd.

На них можно убрать кучу рисков по UX и даже придумать более элегантные решения. Либо понять, что надо всё переделать :D

Более расширенный функционал для интерфейсов, конечно в Adobe Illustrator, но мне очень нравится простота и красота Adobe Xd.

Док написан, мокапы готовы, интерактивные прототипы сделаны. Давайте расскажу, как у меня док устроен.

Раньше я пытался уложить всё в общую логику (Общая инфа → Механика (что не видно юзеру) → Взаимодействие (что видно юзеру) → Тексты.

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

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

Теперь я пляшу от экранов. Но начинаю с общей инфы — одно предложение для описания US (user story). Чтобы понять, о чём док.

Дальше пишу «Причины» — откуда задача взялась и почему это важно. Дальше «Что ожидаем» — пишу, какие результаты мы ожидаем после внедрения.

Таким образом, все, кто читает док получает базовое представление зачем и что делается. И начинает доверять задаче больше. И делать охотнее.

Дальше я описываю, собственно, функционал. Пляшу теперь от экранов. Мокап, описание элементов, функционал элементов, кейсы разные.

Если задача без экранов — просто описываю логику/формулы, даю ссылки на таблицы, калькуляторы и так далее.

После описания функционала идёт список текстов и список ассетов. Если уже запланировано развитие задачи — ссылка на следующий док.

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

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

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

После того, как док переписан после комментов QA, приходит очередь программистов.

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

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

Готовьте доки так, чтобы всё разжевывалось. Если не получилось — убеждайте голосом. А с чем-то действительно вы согласитесь.

Во время подготовки фичи всегда пользуйтесь принципом «5 зачем»: en.wikipedia.org/wiki/5_Whys. Разбирайте проблемы до корня.

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

Большинство рисков вы убрали на этапе интерактивного прототипа и через 3 итерации вычитки. Так что критов быть не должно.

Единственное, что стоит делать — собирать прототип в движке. Это должно быть первым этапом разработки крупной фичи. Если нужно.

Дальше только аналитикам осталось прочитать доки и подготовить список логов для статистики. Ну, или вам, товарищ гд, если аналитиков нет.

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

Если так, то ставить чек. Если нет, то зовёт меня и мы решаем — переписывать док или переписывать код ;)

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

Ну, собственно, и всё. Дальше таски на КМ по подготовке новостей и описаний. Вы им тоже всё рассказываете и помогаете подгтовиться.

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

В середине треда у половины города вышибло интернет, так что сорри, если вы успели отвалиться :) Возвращайтесь дочитывать.

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

А ещё я поломал статистику андерхуда тем, что ворвался во второй раз. Буду всю неделю чинить. Так что авторы впредь будут только уники.

Либо старые, но с новыми твиттер-аккаунтами :)

Поправка: там не «5 зачем», а «5 почему». Так как именно поиск источника проблемы. Для новых фичей я предлагаю именно «5 зачем» :)

Ладно. Спасибо, что приняли ещё раз, ребятки. Пойду начинать чинить статистику. Здоровья там и хорошего настроения!