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

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

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

Игры FPS (first-person shooter, шутер от первого лица) стали неотъемлемой частью видеоигровой индустрии ещё с момента появления в 1992 году популярнейшей Wolfenstein 3D. С тех пор жанр эволюционировал: улучшалась графика, увеличивались бюджеты на разработку, развивалась экосистема киберспорта. Но что насчёт их фундамента — механики стрельбы? Как проходило развитие на этом фронте? Почему в некоторых играх оружие кажется реальными, а в других похоже на игрушки?

Hitscan

В предыдущую эпоху многие игры для рендеринга 3D-сцен в 2D-изображения использовали технику под названием raycasting («бросание лучей»). Raycasting позволяет движку определять первый объект, с которым пересечётся луч. Но потом разработчики задались вопросом: «Что, если выпустить луч из ствола оружия, чтобы имитировать пулю?» Благодаря этой идее родился hitscan («сканирование попадания»).


Пример raycasting

В большинстве реализаций оружия с hitscan при выстреле игрока физический движок выполняет следующие операции:

• Определяет направление, в котором указывает оружие.
• Выпускает из ствола оружия луч на заданное расстояние.
• Использует raycasting для определения того, попал ли луч в объект.

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

Внимание: эта статья написана в 2019 году. С тех пор наш процесс найма изменился. Почитать об актуальной структуре собеседований всегда можно у нас на Гитхабе.

Наша команда разработки уже больше 4 лет растёт примерно на 20% в год. Мы постоянно ищем технических специалистов и совершенствуем наём. Перепробовали много подходов, чтобы сделать процесс эффективнее: от изменений порядка этапов отбора до больших конкурсов для аналитиков и программистов. За несколько лет активного подбора мы накопили большой опыт, и сегодня я хочу рассказать о том, как работает часть нашей HR-команды.

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

Как говорится, если тебе не стыдно за свой старый код, значит, ты не растешь как программист — и я согласна с таким мнением. Я начала программировать для развлечения более 40 лет назад, а 30 лет назад и профессионально, так что ошибок у меня набралось очень много. Будучи профессором информатики, я учу своих студентов извлекать уроки из ошибок — своих, моих, чужих. Думаю, пришло время рассказать о моих ошибках, чтобы не растерять скромность. Надеюсь, кому-то они окажутся полезны.

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

Что нужно сделать?

1. Подумать, почему и на что мы должны кликать?
2. Что должно произойти, когда мы кликнем?
3. Что должно произойти, если не кликнем?

Как ответил я на эти вопросы:

1. Мы должны кликать в любое место на экране.
2. При клике должен смениться объект.
3. При игнорировании — проигрыш.

О чем будет игра?

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

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

Можно ли всё это как-то ускорить?!

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

Этот способ называется SPLATTER TILE!

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

За последние два месяца я создал целых 9 новых действий игрока (такие забавные вещи как блокировка щитом, уворачивание в прыжке и оружие), 17 новых носимых предметов, 3 набора брони (пластинчатый, шёлковый и кожаный) и 6 видов причёсок. Также я завершил создавать всю автоматизацию и инструменты, поэтому всё уже используется в игре. В статье я расскажу, как этого добился!


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

Краткое описание

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

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

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

В первой части я рассуждал для чего прототипирование и в целом с чего начать
— Часть 1

В второй части немножко пробежались по ключевым классам
и архитектуре — Часть 2

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

Скриншоты про ракету в целом унылые, поэтому предлагаю посмотреть видео другого прототипа, который был собран за 2е недели вместе с графикой, и был заброшен в связи с тем что в жанре платформеры и так не протолкнуться. Это кстати одна из ключевых идей вокруг прототипа — собрать, посмотреть, не гавно ли это, нужно ли это? И честно забросить в корзину если вам ответы кажутся недостаточно убедительными. Но! Это не касается творческих проектов — иногда творчество бывает ради творчества ).

Итак видосик, смотреть надо на тексты расставленные по уровню, а не на геймплей ):

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

Необходимый функционал:

1. Любой класс может подписаться на любое событие (часто агрегаторы в юнити делают подписчиками конкретные Gameobject)
2. Должна быть исключена возможность двойной подписки конкретного экземпляра, на конкретное событие (в стандартных средствах за этим нужно следить самому)
3. Должен быть функционал как ручной отписки, так и автоматической, в случае удаления экземпляра/отключения монобеха (хочется подписаться и не париться что подписчик вдруг откинет копытца)
4. события должны уметь перекидывать данные/ссылки любой сложности (хочется в одну строку подписаться и получить весь комплект данных без заморочек)

Для тех кто пропустил первую часть — Часть 1
Следующая часть — Часть 3

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

Итак, начинаем собирать всё в кучу

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

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

Идея выглядит так

Часть 2
Часть 3

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

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

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

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

Привет! Перевели статью от Google с пошаговой инструкцией создания Instant Game в Google Play для игр на Unity.



Google анонсировал сервис Google Play Instant в марте 2018-го; с тех пор гейм-девелоперы могут создавать игры с мгновенным погружением. Существует несколько способов привлечения игроков в мгновенные игры: от кнопки TRY NOW («Попробуйте сейчас!») в Google Play до обычной ссылки, которую могут расшарить друг другу пользователи. Благодаря этому разработчики могут продемонстрировать свою игру и привлечь новых пользователей. В этой статье рассказывается о том, как создать билд готовой к выпуску мгновенной игры на Unity с нуля, а также преимущества мгновенных игр. Продолжение под катом.

В этой публикации я постараюсь вкратце рассказать о типе перечисления в C#, применении его в качестве флагов, а так же о том, как можно упростить их рисование в инспекторе Unity.

Всем привет! Давно ничего не писал, но сейчас захотелось рассказать про очень удобную штуку, о которой многие не знают. Это Event System в Unity. Многие, для задач в которых EventSystem очень удобен, используют обычный Raycast. Я расскажу про то, как пользоваться частью функционала EventSystem (его на самом деле очень много) и как этот инструмент позволяет быстро решать многие задачи связанные с обработкой событий интерфейсов и объектов. Как всегда с репозиторием с примерами. Если вам интересно — добро пожаловать под кат!

Вы задавались когда-нибудь вопросом, как в играх наподобие Super Meat Boy реализована функция реплея? Один из способов её реализации — выполнять ввод точно так же, как это делал игрок, что, в свою очередь, означает, что ввод нужно как-то хранить. Для этого и многого другого можно использовать шаблон Command.

Шаблон Command («Команда») также полезен для создания функций «Отменить» (Undo) и «Повторить» (Redo) в стратегической игре.

В этом туториале мы реализуем шаблон Command на языке C# и используем его для того, чтобы провести персонажа-бота по трёхмерному лабиринту. Из туториала вы узнаете:

• Основы шаблона Command.
• Как реализовать шаблон Command
• Как создавать очередь команд ввода и откладывать их выполнение.

Содержание

• Часть 0. Перечень GUI элементов, используемых в статьях
• Часть 1. Атрибуты
• Часть 2. Окна
• Часть 3. Редактор класса, наследника от MonoBehavior или ScriptableObject
• Часть 4. Редактор класса, кастомный редактор для сериализуемой переменной

Предисловие

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

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

Unity — игровой движок, с далеко не нулевым порогом вхождения (сравнивая с тем же Game Maker Studio), и в этой статье я расскажу с какими проблемами столкнулся начиная его изучение, и какие решения этих проблем нашел. Я буду описывать подобные моменты на примере своей 2d игры-головоломки для Android (которая, надеюсь, скоро выйдет в Play Market).