Всем привет!

Я создатель канала Flutter For Dev и в данном посте я хотел бы помочь тем людям, которые часто задают вопросы подобного типа: «Привет, я новичок в Flutter, что посоветуете почитать?», «А какие курсы по Flutter лучше пройти и какие из них бесплатные?». На все эти вопросы я постараюсь ответить максимально подробным списком информации.

Спросили Алексея Петрова pifagor_mc, Head of QA Сбермаркета, про интервью QA-инженеров и записали ответы. А ещё для подготовки прикрепили ссылки, которые он советовал — ищите их в конце статьи.

В тексте говорим только про собеседования:

• какое резюме прочитают внимательно, какое — закроют через пару секунд,
• о чём спросят на интервью вас и о чём стоит спросить работодателя,
• какие soft skills прокачивать QA-инженеру
• и как обсуждать зарплату на интервью.

Про метрики качества продукта, смерть QA — смотрите в записи вебинара на Ютубе.

Доброго времени суток, друзья!

Представляю вашему вниманию полное визуальное руководство-шпаргалку по всем свойствам CSS-модулей Flexbox и Grid.

Основные источники: A Complete Guide to Flexbox, A Complete Guide to Grid.

В конце статьи вас ждет небольшой туториал по созданию тренажера по Flexbox.

Без дальнейших предисловий.

Доброго дня!Немного об авторе: меня зовут Мария, младший гейм дизайнер. Это вторая статья из цикла по применению теории гейм дизайна в жизни.

Ссылка на первую статью: «Гейм дизайн в жизнь. Пример разбора механики игры»

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

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

Доброго дня!

Немного об авторе: меня зовут Мария, начинающий гейм дизайнер. С этой статьи начинаем цикл статей по применению теории гейм дизайна в жизни. В этой статье попытаемся разобрать механику игры на примере Northgard от студии Shiro Games (находящуюся на стадии раннего доступа на момент написания статьи – прим.автора). Игра была анонсирована в Стиме 22 февраля 2017 года и представляет собой стратегию, с пошаговым завоеванием земель.

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

В этой статье я тезисно перечислю наиболее интересные для меня выводы и чеклисты, которые я нашёл в книге Рафа Костера «Theory of Fun for Game Design».

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

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

От переводчика:
Представляю вашему вниманию статью авторства Andy Gainey, в прошлом независимого разработчика игровых инструментов, ныне сотрудника Paradox Development Studio. На мой взгляд, автор играючи создал один из лучших процедурных генераторов планет с открытым исходным кодом.

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

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

Бонусом в конце — несколько ссылок по теме.

Боевые системы наших игр Rimelands: Hammer of Thor и Trulon: The Shadow Engine были высоко оценены игроками. Несмотря на то, что это два сильно отличающихся взгляда на систему боя в RPG, они имеют много общего в дизайне механик и иллюстрируют мою личную философию дизайна. В обоих играх используются пошаговые бои, но Trulon они основаны на колоде карт, а в Rimelands — на наборе кубиков. В первой вы управляете целой партией персонажей, во второй — только одним героем. У этих игр есть сходства и различия не только в боях, но в данной статье я расскажу только о базовых боевых механиках.

Доброго дня!

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

Ссылки:

1. Первая статья: «Гейм дизайн в жизнь. Пример разбора механики игры»
2. Вторая статья: «Геймдизайн в жизнь. Экономика игры (Часть I)»

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

Коротко о выявленных проблемах игры:

1. Мало контента
2. Профицит валюты/ нет колодца трат
3. Паки валют – колебания стоимости одной единицы игровой валюты

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

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

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

Скриншот из Queen's Wish. Учтите, что я использую игровой арт, который мне нравится. Это необходимо, потому что потом придётся смотреть на него годами, и я не хочу сойти с ума.

Неделю назад я опубликовал в блоге пост «Почему все мои игры выглядят так отстойно» (оригинал). Он оказался ужасно популярным, его прочитало множество людей. Некоторые поддерживали меня. Другие потратили драгоценное время своей жизни на то, чтобы сообщить мне, что я ужасный тупица.

Спасибо всем! Когда пытаешься привлечь внимание к инди-игре, то плохой славы не бывает.

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

Я получил много вопросов. Хороших вопросов. Почему я не могу позволить себе арт-директора? Сколько стоит графика? Почему бы не сделать то или это? Поэтому я решил написать ещё один пост. Я хочу ответить на хорошие вопросы.

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

Видите ли, я самый большой жмот на рынке инди-игр.

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

Я уже 25 лет зарабатываю на жизнь написанием инди-игр. У нас с женой есть небольшой семейный бизнес. Мы создаём низкобюджетные ролевые игры в ретро-стиле с отличным сюжетом, дизайном и геймплеем.

Но все они выглядят как куча навоза.

Первая моя игра, выпущенная в январе 1995 года, тоже выглядела ужасно. Она достигла финансового успеха (очевидно, среди слепых людей), благодаря чему мне удалось профинансировать много других ужасно выглядящих игр и создать себе солидную репутацию.

Благодаря этой репутации мы провели на Kickstarter успешную кампанию по сбору средств на Queen's Wish: The Conqueror — потрясающую RPG, которая тоже будет выглядеть чудовищно. Мы надеемся, что она станет фундаментом для дальнейшего создания ужасно выглядящих игр.

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

Самое главное заключается в том, что я хочу защитить право инди-разработчиков быть странными. Если у инди-разработчика появится безумная, творческая идея, и он испугается её реализовать, но подумает: «Это можно и сделать; по крайней мере, я не настолько сумасшедший, как Джефф Вогель», то я буду считать свою миссию выполненной.

Итак, если вам интересно, почему мы пишем игры, которые выглядят и ВСЕГДА будут выглядеть как куча навоза, то продолжайте чтение.

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

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

В целом существует два основных типа сетевых архитектур: peer-to-peer и клиент-серверная. В архитектуре peer-to-peer (p2p) данные передаются между любыми парами подключенных игроков, а в клиент-серверной архитектуре данные передаются только между игроками и сервером.

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

Добрый день, уважаемые коллеги!

Меня зовут Александр, я разработчик HTML5 игр.

В одной из компаний, куда я отправлял свое резюме, мне предложили выполнить тестовое задание. Я согласился и, спустя 1 день, отправил в качестве результата разработанную по ТЗ HTML5 игру.



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

Данная статья даст представление об объеме работ, достаточном для успешного выполнения среднестатистического тестового задания на позицию HTML5 разработчика. Материал также может быть интересен всем, кто хочет познакомиться с фреймворком Phaser. А если вы уже работаете с Phaser и пишете на JS — посмотрите, как разработать проект на TypeScript.

Итак, под катом много кода на TypeScript!

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

Вообще, что такое ретро-игра? Скорее всего, первое, что придет на ум большинству — это модный нынче пиксель-арт. Если это 2D, то нарисуйте множество пиксельных спрайтов, сделайте слегка угловатые движения персонажей — и готово. Если это 3D, то… Ну, наверно, нужно понизить разрешение текстур, реализовать движение игрока в стиле «бульдозер», как это было в первом Doom, стрелочками вперед-назад-влево-вправо, добавить слегка мультяшных персонажей и… Я уж не знаю, как еще сделать современный клон старого Doom или Quake. Но в этом ли, в действительности, заключается дух старых игр? Уверяю вас, нет.

Когда проигрываешь в мультиплеере, проще всего обвинить баланс — рандом, пушка имба и далее по списку. Но где эта грань между тем, когда не хватило собственного скилла и когда у игры есть реальные проблемы?

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

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

1. Слишком сильный намного хуже слишком слабого

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

Причина заключается в том, что игроки стремятся к тому, что самое сильное, и используют только это. Например, в Awesomenauts есть 34 персонажа. Если трое из них будут слишком слабыми, то большинство игроков не будет ими играть, и у них на выбор останется 31 персонаж. То есть у них по-прежнему большой выбор и присутствует разнообразие. С другой стороны, если бы три персонажа были слишком сильными, то игроки играли бы только этими персонажами и не обращали внимания на остальных. Это бы сделало игру очень однообразной и она бы быстро наскучила.

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

Три года назад ведущий геймдизайнер ArenaNet Дженнифер Шойрле завела в Твиттере очень интересный тред на тему «отличных игровых механик, скрытых от глаз игрока с целью достижения определенного эмоционального эффекта, реакции или поведения», где любой геймдизайнер мог поделиться своими внутриигровыми «фишками».

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

• В Hellblade предупреждение перед игрой было тщательно продумано, чтобы заставить игроков поверить, будто в игре срабатывает система permadeath в случае, если игрок умирает слишком часто, хотя на самом деле ее там нет.
• Pacman может огибать углы более резко, чем это делают призраки, тем самым наделяя игрока небольшим преимуществом.
• Во многих шутерах последние очки здоровья стоят больше всей остальной шкалы, чтобы усилить чувство «выживания на грани». С той же целью в System Shock последняя пуля нанесет урон в 4 раза более сильный, чем остальные.
• И, напротив, Shadow of Mordor слегка увеличивает здоровье некоторых врагов, чтобы бои длились дольше.
• В Bioshock и Devil May Cry, находясь за спиной игрока, противники замедляют свою атаку.
• В Xcom, если промахнуться много раз подряд, игрок получит скрытый бонус для последующих выстрелов. Кроме того, если игроки остаются пассивными слишком долго, враги усиливают свою агрессивность.
• Похоже, что в Heartstone есть pity timers ― таймеры жалости. Многие другие игры позорно использовали их в более ранние годы.
• В Resident Evil 4 после слишком большого количества смертей заспавнится меньше врагов, чтобы дать игроку больше шансов пройти трудный для него эпизод.
• В любой гоночной игре реализован адаптивный ИИ, чтобы сделать соревнование более жестким.

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

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