Новая неделя - новый рассказ о том, как я учусь делать игры в Вышке (aka НИУ ВШЭ). Предыдущая часть здесь.
Excel, SQL, XML
На этот раз неделя началась с практического занятия по игровой логике с Константином Сахновым. Он рассказал нам (ну или напомнил) про базовые функции Excel: логические, математические, статистические и текстовые, а также ссылки и массивы. Потом мы послушали про конфиги в играх - наборы данных, где хранится всякая геймдизная инфа: настройки контента, поведение игровых объектов, уровни и левел-дизайн, макросы и так далее. А ещё коротко разобрали SQL-скрипты - язык запросов к базам данных, которые поддерживают архитектуру структурированного хранения информации - и посмотрели на XML и JSON.
Но это всё теория - вскоре нам предстояло разобраться с этим на практике. Всё остальное занятие мы занимались калькулятором рецептов крафта. Сделать нужно было вот что:
1. Создать в Excel страницу с предметами и материалами для крафта.
2. Создать в Excel страницу для расчётов.
3. Сделать ячейку Recipe fullname - она будет использовать название предмета, который получится в результате крафта, чтобы создать полное название рецепта.
4. Сделать ячейку Outcome product name - она позволяет выбрать предмет, который получится в результате крафта.
5. Сделать ячейки: product quantity (количество крафтовых предметов, которое будет создано в результате), time in minutes (время крафта в минутах) и rarity (редкость рецепта).
6. Сделать ячейки ингредиентов.
7. Преобразовать созданные рецепты в код XML - так, чтобы в итоге код со всеми строками с рецептами выгрузился в конфигурационный файл.
Зачем всё это, думаю, понятно - чтобы оптимизировать, автоматизировать, упростить и ускорить конструирование рецептов. Разумеется, можно составлять их и вручную, но в этом способе два недостатка: риск ошибок и трудности при внесении правок, если рецептов очень много.
Работает - не трожь, не влезай - убьёт
На следующем занятии мы занимались административным и проектным менеджментом, не поверите, снова с Константином Сахновым. От проектного управления, о котором мы много говорили в прошлом году, мы перешли к административному - и вот что про него узнали.
Административное управление - это комплекс мер по поддержанию работы компании, которое зиждется (вот это слово я вспомнила!) на таких принципах:
1) Работает - не трожь!
2) Не делай руками
3) Бюрократия с человеческим лицом.
А руководителей, которые занимаются только административкой (не по КоАП РФ, а управлением), называют функциональными. Чем они занимаются:
1) Операционка (согласование решений, контроль задач и процессов, подписание документов).
2) Кадры (найм и увольнение сотрудников, обучение их, решение проблем и мотивация).
3) Финансы (планирование доходов и расходов, управление финансами, ресурсы на проекты).
4) Стратегия (регламенты, долгосрочное планирование, ключевые решения, управление рисками, развитие бизнеса).
Разделить задачи функционального руководителя можно на вот такие категории.
Мне больше всего нравятся вот эти два пункта - так бы всегда и работала:):)
Ещё мы немножко поговорили про идеальный регламент в административном управлении.
Он:
1. Понятный и однозначный.
2. Короткий (потому что никто не любит их читать).
3. Содержит ситуацию, действие и последствия.
4. Не допускает исключений.
Например, такой.
Новые регламенты делают не от того, что больше нечем заняться и “чтобы были”, а на основе прецедента, к которому выработали решение.
А теперь быстренько про структуры управления (ну вдруг вам когда-нибудь предстоит возглавить корпорацию). Виды структур такие:
1. Линейная: всё выстроено вокруг одного руководителя с прямым подчинением только ему. Оптимально для 2-10 сотрудников, но структура негибкая, она не масштабируется - зато быстро принимаются решения.
2. Иерархическая: с вертикальным подчинением в виде пирамиды. Оптимально для 10-50 сотрудников, в ней просто делегировать, это быстрая структура для штатных ситуаций, но так себе для форс-мажоров и стратегических решений.
3. Проектная: деление компании, как нетрудно догадаться, на проекты. Оптимально для 50-100 сотрудников, тут высокая самостоятельность проектов, но делегировать и внедрять новое сложно.
4. Функциональная: деление по видам деятельности. Оптимально для 30-100 сотрудников, что для неё характерно - высокая взаимозаменяемость.
5. Матричная: двойное подчинение исполнителей. Оптимально для 100-300 сотрудников, структура надёжная, позволяет динамично перестраивать процессы.
6. Дивизионная: деление на бизнес-юниты с большой автономностью, но общей инфраструктурой. Оптимально для 500 и больше сотрудников, это надёжная структура, в которую можно интегрировать даже новые компании.
Бумажные прототипы и правильные плейтесты
Также на этой неделе у нас прошло уже второе занятие по прототипированию со Степаном Кулешовым, на котором мы узнали про виды прототипов. Классифицировать их можно по многим критериям, я выделю самые полезные (на мой взгляд) с точки зрения практики.
Прототипы бывают:
1. Функциональные: проверяют опыт игрока от взаимодействия с объектом. В них можно обойтись без особого художественного дизайна и не использовать технологии проекта. Это, к примеру, прототип фичи или срез геймплея/игровых циклов.
2. Технические: проверяют работоспособность неизвестной технологии и/или функциональность новой платформы.
3. Дизайнерские: проверяют ощущения пользователя от восприятия объекта. Можно собрать не из финальных ассетов, такой прототип может быть не интерактивным - в виде картинки или видео. Так можно проверять атмосферу, саунд-дизайн, музыку, арт-стиль, эффекты, UI.
Ещё мы чуть-чуть поговорили про бумажное прототипирование. Оно очень симпатичное (по моему мнению, “ну, во-первых, это красиво”) и почти универсальное.
С его помощью можно дёшево посмотреть на дизайн, интерфейсы, уровни игры, обособленные фичи, пошаговые проекты и настолки. И всё это - без сложных инструментов, навыков программирования и с лёгким тестированием! К тому же, это весело (пусть и довольно муторно, если хочется, чтобы получилось качественно). Люблю эту тему - у меня к бумаге особое отношение, в конце концов, занимаюсь бумажной игрой!:)
На той же лекции мы от прототипирования плавно перешли к плейтестам (тоже своего рода прототип). Систематизирую советы, которые мы получили:
1. Заранее определиться, что проверяем.
2. Подготовиться к плейтесту: начиная от рабочего билда и заканчивая поиском шкафа, куда пришедшие игроки смогут повесить куртки.
3. Подобрать разношёрстную аудиторию: лояльных игроков, целевую и нецелевую аудиторию.
4. Собрать фидбэк: садиться рядом с игроками и записывать (ну только так, чтобы они не напрягались:)), просить игроков вести заметки, записывать аудио и видео процесса, раздавать анкеты и опросники.
Идеальное тестовое задание и типы вопросов на интервью
И ещё у нас было занятие по карьерному консультированию с Сергеем Волковым. Мы поговорили про то, как искать и строить команду (но на примере большой или средней компании, не в инди-сегменте). Поэтому коротко, что нужно сделать:
1. Определить потребность в сотруднике, составить описание вакансии.
2. Подготовить тестовое задание. Оно должно проверять необходимые скиллы и не ограничиваться жёстким сроком выполнения. Идеальное тестовое занимает 1-2 часа, много времени не должно требоваться и для его проверки. Результат не должен идти в работу компании - в противном случае тестовое нужно оплачивать.
3. Сформулировать вопросы для HR и определить критерии для отсева кандидатов на этом этапе. Например, несовпадение по зарплате, софт-скиллам и несоответствие заявленного опыта требованиям вакансии.
4. Провести собеседование в несколько этапов: c HR, с нанимающим менеджером и компетентным спецом в необходимой области, с продюсером проекта и HRD.
На интервью можно задавать вопросы разных типов. Например, исследовательские, чтобы выяснить детали: “а почему вы так решили?”. Или проективные - они сформулированы вроде как о других людях или персонажах, но, отвечая на них, кандидат будет проецировать свой опыт на других. Например, “что, на ваш взгляд, может побудить человека уволиться?” или “как вы думаете, почему люди играют в игры?”. Наконец, можно задавать ситуационные вопросы - они же кейсы, то есть приводить пример практической ситуации и смотреть, как бы поступил в таком случае кандидат.
И напоследок - хороший интервьюер должен уметь отделять факты от гипотез (в данном контексте - домыслов). Человек часто менял работу - это факт, а вот вывод о том, что он не склонен к стабильности - лишь гипотеза. И наоборот, то, что человек проработал на одном месте пять лет - это факт, а вот решение, что он стабильный и надёжный сотрудник - лишь гипотеза.
И на этом на сегодня закончим! В этот раз получилось посерьёзнее, чем в прошлый:) Но, в конце концов, не всё же тусить - иногда можно и поучиться, для разнообразия:):)
P. S. Читать Student Simulator также можно в VK, твиттере и телеге.
P. P. S. На случай, если кого-то заинтересуют технические подробности про курс, на котором я учусь - традиционно оставляю ссылку на программу “Менеджмент игровых проектов”.