Гейм-дизайн: Реальные тестовые задания
Про что эта статья?
Сборник различных заданий из тестовых, которые я давал. Это не одно большое тестовое, а именно компиляция из разных старых тестовых заданий. Приводится для ознакомления.
Вакансии были самые разные, от junior до senior. Основные направления: игровой UI/UX, баланс, дизайн уровней.
Тестовые не оплачиваются, результаты по умолчанию могут использовать все желающие (я бы рекомендовал выкладывать под CC0 сделанное, чтобы получить больше фидбэка от других геймдизайнеров).
Сложность проставил по шкале Junior — Middle — Senior приблизительно.
Сами тестовые задания
UX (перенос из web на мобилки)
Уровень: middle+
   |
https://vk.com/app2708130_4926764 сама игра, она на FLASH так что в декабре превратится в тыкву.
Описание механики
Есть крафт по рецептам. В каждом рецепте от 1 до 5 компонентов (от 1 до N штук каждого).
Если все компоненты есть, то крафт бесплатен. Крафт мгновенный.
В обычных рецептах можно заменять любые недостающие компоненты золотом, общая сумма пишется внизу.
В “редких” рецептах нельзя заменять компоненты золотом, только собирать. Самый частый пример такого: вложенные рецепты (собери железо из угля и руды — простой, потом из железа собери шестеренки — редкий, потом из шестеренок собери робота — редкий). Нужна возможность перейти к сбору nested-компонента в этом случае, если такой рецепт есть.
Фильтр: все, нет компонентов, есть частично, есть всё чтобы собрать.
Фильтр2: категория собираемого (лотки, корабли и т.п.)
Некоторые рецепты можно собрать не более N раз (например, может быть только 2 статуи венеры, третью уже собрать нельзя, рецепт не показывается). Сколько ещё можно собрать нужно показывать.
При наведении везде есть подсказки с параметрами и описанием.
Примерное число рецептов: 500.
Что нужно сделать
Адаптировать интерфейс для работы на телефоне (тачскрин). Размер телефона: iphone5 (т.е. небольшой телефон).
Сохранить нужно механику крафта, но можно полностью изменить визуал.
Не требуется финальное качество арта (это работа художника), но нужна схема расположения всех элементов (мокап), список возможных состояний каждого элемента (например, для кнопки disabled “недоступна” , active “можно нажать”, hover “навели на кнопку”) с описанием как их различить (например, «меняем цвет рамки»/»меняем цвет подложки на красный»/»делаем иконку черно-белой»).
Не обязательно располагать всё на одном экране.
Описать чем вы руководствовались при изменении интерфейса.
Что оценивается
Удобство (элементы достаточно крупные, их видно, прослеживается логика), соответствие оригинальной механике (все оригинальные механики сохранены), логичность интерфейса (понятно что там делать и как это работает).
UX (управление с геймпада)
Уровень: junior
Что нужно сделать
- Найти и изучить требования full controller support. Схема управления должна полностью соответствовать этим требованиям.
- Взять 3 любые игры на выбор где нет поддержки геймпада (одну любую на мобильной платформе, одну пошаговую на любой платформе, одну с управлением только мышью без клавиатуры на любой платформе). Описать для них схему управления с внешнего (НЕ виртуальный джойстик на экране) геймпада, список подсказок (где их разместить, как они должны переключаться). Описать как минимальными средствами адаптировать игру чтобы она соответствовала требованиям.
- Описать чем вы руководствовались когда выбирали такое управление.
Геймпады xbox one, ps4, другие по желанию.
Что оценивается
Выполнение требований (FCS), логичность и удобство управления.
UX (управление, мобильная платформа)
Уровень: junior/middle
Что нужно сделать
У вас есть юнит, которого нужно перемещать в пошаговом режиме (поле клетчатое или из хексов на выбор). Механики игры придумайте сами или возьмите их из любого подходящего под описание тайтла.
- Опишите как можно больше способов перемещения юнита.
- Опишите как можно больше возможных состояний клеток/хексов и юнита.
- Составьте список возможных действий пользователя (передумал, мисс-тап, переместил и т.п.)
Что оценивается
- Способность мыслить как игрок, составлять список возможных действий
- Полнота и качество обратной связи, позволяющие игроку принять решение
Теория вероятности (база)
Уровень: junior
Что нужно сделать
Два игрока кидают кубики. Один кидает D20, второй 3D6. У кого больше тот и победил.
Хочется увидеть 3 цифры в %: победа D20, победа 3D6, ничья (выпало равное число). Число испытаний ~бесконечное (очень большое). Т.е. условно 70% победит д20, 29% 3д6, 1% ничья. Или 50% д20, 50% 3д6, ничья невозможна (0%). — приложить решение также нужно (а не просто цифры).
Что оценивается
Правильный ответ или нет, адекватный способ решения или нет.
Нарративный дизайн (диалоги и последствия)
Уровень: middle+, но делать можно и джунам, просто оценивать надо будет отдельно.
Что нужно сделать
Вам нужно сделать игру с выборами и последствиями.
- описать как это будет выглядеть в игре
- описать какие виды взаимодействий, диалогов и типы выборов вам нужны (если их несколько), как вообще будут работать выборы.
- описать небольшую ситуацию, которая покажет необходимые механики
- описать варианты упрощения и усложнения механики выборов с точки зрения бюджета (перевод, озвучка, анимации и т.п.), с точки зрения полезности (наличие диалогов должно как минимум не делать хуже), с точки зрения скорости и сложности добавления контента.
- по возможности добавить референсы на описанное (“моделируется ситуация из такого-то фильма”, “интерфейс как в такой-то игре”, …)
Не обязательно делать полноценный сценарий и прописывать все реплики, задача скорее — ТЗ на инструментарий для вас, как дизайнера + нужно показать что вы знакомы с существующими решениям в других играх/медиа.
Что оценивается
- По описанию понятно как это реализовать
- Есть примеры на все описанные механики
- Есть описание с точки зрения влияния на игрока, понимание нарративным дизайнером того, каких целей он хочет добиться
От Джула (про системность)
Уровень: junior+
Что надо сделать
Составьте шаблон для описания игры (универсальный).
Что будет оцениваться
Насколько удобно по этому шаблону описывать игры, есть ли польза от такого описания, можно ли описать любую игру по такому шаблону или только узкий жанр?
Левелдизайн (сборка блокаута)
Уровень: junior+
Что надо сделать
 |
Собрать whitebox (этапы: blockout = общие формы, потом whitebox = добавление средней детализации и цвета, потом финализация и добавление мелочей — подробнее у Кадикова почитать можно) локации по референсному изображению. Нужно сделать это как можно проще, использовать примитивы и заливки цветом, например. Не тратить время на ненужные для понимания сути локации объекты, потратить основное время на важные элементы.
Можно задать вопросы о локации, самой игре и арт-стиле (или указать самостоятельно, например что это экшн от 3 лица, шутер от первого лица в реалистичной стилистике или RTS с cartoon-стилизацией).
Что будет оцениваться
Объемы. Правильно ли они переданы в целом или сделано что-то совсем не то (например вместо склонов локация стала плоской).
Цвет. Удалось ли передать важную информацию о цветовом решении локации, достаточно ли информации для арт-отдела, чтобы приступить к финализации локации?
На что обратили внимание (оставили в вайтбокс-версии), а что выкинули. Осмысленное это упрощение или при упрощении были потеряны важные детали. Возможно дизайнер захочет добавить мелкие элементы очень важные для локации и объяснит зачем они добавлены на этапе вайтбокса.
Играбельность. Учтены ли особенности жанра игры, есть ли лэндмарки, нормально ли локация выглядит при использовании игровой камеры (а не рендера с красивого ракурса).
В целом задание про оценку того как мыслит левелдизайнер при создании локации и может ли сделать whitebox, не закапываясь в излишнюю детализацию, но передать всё нужное для дальнейшей работы.
UX (игровая камера для перемещения в игре от 3 лица)
Уровень: middle, но умеющий пользоваться гуглом джун легко осилит, просто делать будет долго
Что надо сделать
Вам нужно спроектировать камеру в игре для консолей или PC (можно и то и то, не мобильная игра) в пошаговой игре от 3 лица (т.е. камера не динамичная и не синематографичная). Камера может быть не привязана к персонажу (давать возможность осмотреть локацию или выбрать точку перемещения).
Можно опустить камеры для хайлайтов (красивого показа смерти, например) и выстрелов. Только перемещение. Максимум указать кратко.
- Напишите какие параметры камеры вы хотели бы уметь менять и как (FOV, углы, расположение, …). Относительно чего вы (как дизайнер) хотели бы настраивать параметры камеры (например настраивать высоту от земли или дистанцию до персонажа). Приведите примеры (референс) параметров камеры (например, “угол обзора хочется как в XCOM 2, вот скриншот”).
- Напишите какие параметры камеры может менять игрок (например, перемещать камеру, вращать её, менять расстояние или угол обзора). Объясните свой выбор приведя примеры использования.
- Опишите как должна вести себя камера при выборе персонажа, при свободном исследовании локации и т.п. (если это важно для игры). Какие проблемы вы решаете (например, “хочу чтобы камера не проваливалась под землю никогда, выглядит плохо” или “хочу чтобы персонажа всегда было видно”)
- Дополнительные вопросы: расскажите чем отличается удаление камеры от персонажа (dolly), изменение угла обзора (zoom) и смена высоты (этажа). Опишите преимущества и недостатки этих способов управления камерой (на примерах).
- Дополнительные вопросы: Опишите как камера должна вести себя если натыкается на препятствие (стену, дерево), если есть изменение высоты ландшафта, если есть многоэтажность.
Что будет оцениваться
Удобно ли играть с такой камерой.
Понятно ли техническим специалистам (программистам) как реализовать камеру для дизайнера (настройки камеры) и для игрока (поведение камеры в игре).
Учтены ли сложные случаи использования камеры.
Есть ли референсы (дизайнер ознакомился с существующими реализациями, а не просто изобретает велосипед).
Плюсом будет осмысленный анализ того что сделано (“не делаем смену угла обзора потому-то или делаем зум только сменой угла обзора потому-то”).
Оцениваться будет прежде всего как описание фичи для программистов, а не как описание для игроков.
Excel (знание инструмента)
Уровень: junior с базовым знанием excel, там есть небольшой подвох в исходных данных, а формул 1-2 базовых нужны.
Что надо сделать
Вася, Петя и черт лысый пошли по кабакам. Расплачивались и записывали кто сколько потратил, кто сколько выпил, иногда возвращали сразу деньги.
Нужно посчитать кто кому сколько должен остался.
https://docs.google.com/spreadsheets/d/1BeZhYMNZ_6hzIhqnGFLF5aD2b4A_uS1byKDi03L8XGk/edit?usp=sharing
Нужно скопировать исходную табличку, переделать/доделать и прислать ссылку на новую табличку где всё правильно считается.
Надо посчитать кто кому сколько должен.
Надо чтобы можно было позже добавить ещё участников (допустим 15 человек) и не переделывать все формулы глобально.
Итог должен быть числом сколько этот человек должен (-15000) либо сколько ему должны (+25000)
Нераспределенные суммы (чаевые, или не помнят например) раскидываются на всех.
Что будет оцениваться
Всё считается нормально, использованы адекватные инструменты (а не скрипт на лиспе в амазонсервисе — задача всё же про excel), результат отдан в том виде в котором просили.
Дополнительно оцениваются вопросы, которые задавались в процессе или комментарии к исходным данным.
Как получить обратную связь?
Если вы решите сделать какие-то из этих заданий, можете прислать мне на почту (roman.ilyin@gmail.com), или комментарием к этой статье у меня в блоге ( https://romanilyin.com/gamedesign-tests/ ). Результат, я по возможности прокомментирую и что-то посоветую. Не обещаю что это будет быстро, но постараюсь ответить всем.
Список тестовых будет со временем пополняться.
Свежие комментарии