В официальной рекламе Google обнаружили русские матерные слова

В конце прошлого месяца корпорация Google выпустила ролик с названием «See yourself at Google», который приоткрывает нюансы работы в компании. Ролик предназначен для желающих начать карьеру в одной из крупнейших технологических корпораций мира.

Ролик был опубликован во многих местах — кроме YouTube, ссылки на него размещались в ряде социальных ресурсов Google. Спустя несколько дней один из сотрудников компании Jfrog обратил внимание на то, что строки кода, отображаемые на мониторе ПК в ролике содержат матерные слова.
Так, в 33 строке обнаружились слова «govno jopa barebuh suka» в 33 строке и «pidar gopa» на 36 строке.

Изначально пользователи Сети решили, что код написан сотрудниками Google, но затем оказалось, что видео, о котором идет речь, взято со стокового сайта Shutterstock. На нем обычно размещают видео на продажу. Лицензия на ролик в максимальном качестве обошлась корпорации в 179 долларов США.

Несколько позже был найден и автор видео. Им оказалась питерская видеокомпания Treedo, которая создала ролик на продажу в 2017 году. По словам ее директора, никто и не думал, что видео будет использовано Google, плюс руководство компании не подозревало о том, что в видео есть матерные слова.

«Мы в шоке. Факт, мы писали всякую ересь, но не могли предположить, что актёр будет писать такое. Мы даже не отсматривали код», — заявил Александр Игнатьев, арт-директор Treedeo.

Let's block ads! (Why?)

Кирилл Толкачёв и Максим Гореликов про Spring Boot на jug.msk.ru

На встрече московского сообщества Java-разработчиков jug.msk.ru, состоявшейся 28 июня 2019 года традиционно в офисе компании КРОК, Кирилл Толкачёв и Максим Гореликов представили свой доклад о Spring Boot: какие задачи можно решить с помощью него, какие сложности могут при этом возникнуть и как с ними бороться.

О докладчиках

Кирилл и Максим до недавнего времени работали в Альфа-Лаборатории, теперь представляют ЦИАН. Оба участвуют в различных конференциях в качестве докладчиков. Кирилл в четвёртый раз выступает на jug.msk.ru. В предыдущие разы дважды делал доклады с Александром Тарасовым (раз и два) и один раз вместе с Барухом Садогурским.

Ссылки на учётные записи Кирилла: Twitter, GitHub, Speaker Deck и Habr; Александра: Twitter, GitHub и Speaker Deck.

Доклады Кирилла за время, прошедшее с его прошлых выступлений на jug.msk.ru:

Доклады Максима:

• «Дизайн реактивной системы на Spring 5/Reactor» (Joker 2017: презентация, видео)
• «Эволюция синхронной системы со Spring 5/Project Reactor» (JUG.EKB-2018: видео)

Совместные доклады Кирилла и Максима:

О докладе

Андрей Когунь предваряет встречу анонсами предстоящих конференций (TechTrain 2019, Joker 2019) и представляет докладчиков.

В первой части были рассмотрены критерии выбора инструментов для написания сервисов, сказано об изменении восприятия Spring Boot Java-разработчиками, выполнен обзор структуры и содержимого типичного Spring Boot-приложения. Упомянуто про проблемы с различными версиями API сервисов и объяснены причины возможного появления собственных стартеров.

Во второй части поговорили об «умных» библиотеках, о тестировании, про различные возникающие на практике проблемы и возможные пути их решения, про другие фреймворки-альтернативы по отношению к Spring Boot. В конце подведены итоги и даны общие советы.

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

Презентация доклада, видео скоро появится (см. ссылки ниже).

Ссылки по jug.msk.ru:

• TimePad — анонсы встреч и регистрация на них, подписка на оповещение по почте о встречах
• YouTube — видео докладов
• Speaker Deck — презентации докладов
• VK — анонсы встреч, фотоотчёты, ссылки на материалы прошедших встреч
• Twitter: учётная запись (анонсы встреч, фотоотчётов, видео) и хэштег (твиты с комментариями о встречах)
• Хабр — обзоры встреч, найти все обзоры можно по тегу

Let's block ads! (Why?)

Несколько простых, но полезных советов по работе с геттерами в Vuex

Vuex предоставляет удобные инструменты для работы с данными, но некоторые разработчики используют их не всегда по назначению, либо создают избыточные конструкции там, где можно было написать более понятно и ёмко, такое также случается, когда разработчик только знакомится с данными инструментами. В данной статье будут приведены некоторые рекомендации по организации геттеров (Getters), которые вы сможете применить в работе.

Геттеры являются частью хранилища Vuex, вычисляемыми свойствами, если точнее. Они позволяют получать например отфильтрованные по какому-либо параметру данные. Но некоторые разработчики понимают название этого инструмента буквально и начинают использовать это, как замену получения данных напрямую из state. Отсюда вытекает первая ошибка использования геттеров.

Использование геттеров для простого получения данных из хранилища

Давайте разберем простой пример кода:

state: {
  films: [
    { id: 1, name: 'Джеймс Бонд' },
    { id: 2, name: 'Гарри Поттер' },
    { id: 3, name: 'Автострада 60' },
  ],
},
getters: {
  films: state => state.films,
},

Такое использование геттеров встречается достаточно часто и это плохо. Для доступа к состоянию в вашем компоненте достаточно сделать вычисляемое значение в computed, например:

computed: {
  films() {
    return this.$store.state.films;
  },
},

Либо еще более удобный вариант с использованием mapState:

computed: {
  ...mapState(['films']),
},

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

ИМХО: многие миксуют использовние mapState и создание вычисляемых значений, возвращающих состояние. Для создания единообразного кода используйте mapState и остальные инструменты даже для одного значения, так как ваш код станет более единообразным и в него можно будет вносить изменения гораздо быстрее и добнее, к примеру если придется вывести еще одно знанчение.

Создавать геттер для единственного случая использования фильтра

Предположим, что вам нужно получить фильм про Джеймса Бонда, для какого-то специфического случае, возможно вам захочется сделать так:

getters: {
  bondFilm: (state) => {
    const [film = {}] = state.films
      .filter(f => f.name === 'Джеймс Бонд');
    return film;
  },
},

Не нужно так поступать, лучше снова обратиться к mapState и сделать следующим образом:

computed: {
  ...mapState({
    bondFilm: (state) => {
    const [film = {}] = state.films
      .filter(f => f.name === 'Джеймс Бонд');
    return film;
  },
  }),
},

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

Создавать геттеры с параметрами

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

getters: {
  filmById: (state) => (id) => {
    const [film = {}] = state.films
      .filter(f => f.id === id);
    return film;
  },
},

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

getters: {
  filmsById: state => state.films
    .reduce((result, film) => ({
      ...result,
      [film.id]: film,
    }), {}),
},

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

Подведем небольшой итог

• Не используйте геттеры для простого получения данных, не нужно усложнять свой код обертками для простых операций
• Не создавайте геттреры для специфических фильтров, которые будет необходимы только однажды, основная идея геттеров — это получение производных состояний, но не нужно переносить логику компонента в логику хранилища
• Параметризированные геттеры теряют своё основное свойство — кэшируемость, подумайте несколько раз, прежде чем пользоваться ими таким способом
• Пользуйтесь всеми преимуществами mapState, помните, что большую часть специфических задач для компонента можно выполнить с его помощью
• Используйте mapGetters, об этом было сказано косвенно, но единообразие лучше, чем его отсутствие

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

Let's block ads! (Why?)

Статическое распределение памяти в микроконтроллерах

Холмс: Любезнейший, не подскажите где мы находимся?
Пастух: Вы находитесь на воздушном шаре!!!
Холмс: Вы должно быть программист.
Пастух: Да, но как вы догадались?
Холмс: Только программист мог дать столь точный и
при этом столь бесполезный ответ.

… отрывок из известного анекдота

Если Вы когда нибудь программировали под микроконтроллер, неважно, с помощью Arduino IDE или напрямую работали с компилятором для AVR, ARM, или ESP, Вы наверняка видели отчеты о завершении сборки вроде

Sketch uses 1,090 bytes (3%) of program storage space. Maximum is 30,720 bytes.
Global variables use 21 bytes (1%) of dynamic memory, leaving 2,027 bytes for local variables. Maximum is 2,048 bytes.

Или

text data bss dec hex filename
52136 1148 12076 65360 ff50 MyProject

Такие отчеты действительно являются абсолютно точными… Вот только неполными, а потому не такими уж полезными. Проблема в том, что тут учитываются только те данные, которые были распределены статически. А вот все что выделяется через new или malloc в статистику не попадает. Как результат гораздо сложнее отследить моменты когда вдруг перестает хватать памяти и прошивка начинает работать неверно. А ведь памяти в микроконтроллерах обычно не очень много, и за этим параметром стОит тщательно следить.

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

Статья рассчитана на новичков (хотя совсем уж базовые вещи рассказывать не буду – ожидаю, что читатель проштудировал хоть какую нибудь книгу по C++). Поехали.

Статическое распределение переменных

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

• статически распределенная память – сюда пападает все о чем знает компилятор на этапе сборки проекта: глобальные переменные и объекты, статические переменные в функциях и объектах
• куча (heap) – большая область памяти, из которой система (аллокатор памяти) нарезает кусочки кому сколько нужно. Функции вроде malloc и оператор new берут память как раз отсюда
• стек – место где процессор сохраняет регистры и адреса возвратов из функций, но также на стеке размещаются локальные переменные в функциях.

Давайте исследуем это на практике. Чтобы не парится с компилятором и системой сборки я воспользуюсь Arduino IDE под целевую платформу Arduino Nano.

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

Global variables use 21 bytes (1%) of dynamic memory, leaving 2,027 bytes for local variables. Maximum is 2,048 bytes.

Судя по сообщению свободной памяти у нас просто завались. Но давайте посмотрим на код

int * buf;
void setup()
{
  buf = new int[3000];
}
void loop() {}

Прошивка пытается выделить памяти больше чем есть в самом микроконтроллере. Разумеется, такой код работать не будет. Но, на мой взгляд. самая большая проблема тут в том, что код компилируется успешно, а компилятор вовремя не надавал по рукам и не предупредил, что память может закончится. И хорошо если есть внятный обработчик ошибки. А если нет?

Конечно, Вы сейчас скажете, мол сам себе злобный Буратино! Тебе отчет говорит, что есть всего 2кб, а ты пытаешься выделить 3000 элементов по 2 байта каждый. Но давайте подумаем как бы это выглядело в реальном проекте. Скорее всего часть была бы уже занята какими нибудь переменными, некоторым образом бы использовался стек, сколько-то памяти было бы уже распределено динамически. И тут вдруг наступает какое нибудь редкое событие, которое потребует еще кусочек памяти и… ой все, приехали.

Что я имею в виду под статическим распределением и чего вообще хочу добиться? Я ничего не имею против динамического выделения памяти. Но мне не очень понятно зачем использовать динамическое выделение для объектов, буферов, и массивов заранее известного размера. Почему бы просто не объявить это как глобальную переменную?

Я пока временно уменьшил размер массива до более вменяемого размера.

int buf[300];
 
void setup()
{
  buf[0] = 1; //Avoid optimizing this array
}
 
void loop()
{
}

Теперь компилятор и линковщик заранее знают про некий массив размером в 300*2=600 байт, который должен быть размещен в оперативной памяти. Более того, линковщик может выделить этому массиву фиксированный адрес, который при желании можно посмотреть утилитой objdump (если, конечно, найдете куда Arduino IDE кладет бинарь)

cd C:\Users\GrafAlex\AppData\Local\Temp\arduino_build_55567
"C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avr-objdump.exe" -x -D -S -s StaticMem.ino.elf
…
00800100 l O .bss 00000258 buf
…

Тут 0x00800100 это адрес, который линковщик присвоил нашему буферу, 0x258 это его размер (600 байт)

Попробуем теперь вернуть неадекватный размер в 3000 элементов и посмотреть что получится. Мы закономерно получаем «фе» от системы сборки

Sketch uses 456 bytes (1%) of program storage space. Maximum is 30,720 bytes.
Global variables use 6,009 bytes (293%) of dynamic memory, leaving -3,961 bytes for local variables. Maximum is 2,048 bytes.
...
Not enough memory; see http://www.arduino.cc/en/Guide/Troubleshooting#size for tips on reducing your footprint.

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

Сейчас придут знатоки хороших практик кодирования и скажут, что глобальные переменные это зло. Предлагаю полемику на этот счет оставить за кадром, а кого глобальные переменные смущают, то я могу предложить несколько альтернатив. В сущности, все нижеописанные подходы служат одной и той же цели – подсказать компилятору, что определенный объект можно распределить в памяти еще на этапе компиляции/линковки, дать ему заранее известный адрес и место в оперативной памяти. Как бонус получаем еще отсутствие фрагментации памяти, а также у нас нет оверхеда на динамическую аллокацию (во всяком случае для таких объектов).

Статическая глобальная переменная

Можно объявить наш массив/объект/переменную используя слово static. Это ограничит область видимости переменной – к ней можно будет доступиться только из этого cpp файла.

static int buf[300];
 
void setup()
{
  buf[0] = 1; //Avoid optimizing this array
}

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

extern int buf[300];

void foo()
{
    buf[0]++;
}

Линковщик выругается, что не может найти переменную buf

C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/main.cpp:47: undefined reference to `buf'

Если же в обоих файлах переменную buf объявить как static, то у каждого cpp файла эта переменная будет своя!

static int buf[300];

void foo()
{
    buf[0]++;
}

Вывод objdump в этом случае будет выглядеть так

0080036a l     O .bss   00000258 _ZL3buf.lto_priv.12
00800112 l     O .bss   00000258 _ZL3buf.lto_priv.13

Безымянный namespace

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

namespace
{
int buf[300];
}

Статические члены классов

Статические члены классов также распределяются на этапе компиляции.

class A
{
    static int buf[300];
public:
    int * getBuf()
    {
        return buf;
    }
};

int A::buf[300];
 
void setup() {}

void loop()
{
    A a;
    a.getBuf()[0] += 1;
}

Несмотря на то, что экземпляров класса A может быть много (для примера я создаю по экземпляру каждый раз, когда попадаю в функцию loop()), буфер объявлен как статический член класса. А это значит, что он будет существовать в единственном экземпляре и распределен в памяти еще на этапе линковки.

00800100 l O .bss 00000258 A::buf


Статические переменные в функциях

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

int getCounter()
{
    static int counter = 0;
    return ++counter;
}

void setup() 
{
    Serial.begin(9600);
}

void loop()
{
    Serial.println(getCounter());
}

Переменная counter распределена статически. Она не будет создаваться каждый раз при вызове функции getCounter(), а будет иметь фиксированный адрес в памяти

00800116 l     O .bss        00000002 getCounter()::counter

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

Тем не менее с этим способом связано несколько нюансов. Например статическое распределение массивов будет работать как нужно

int * getBuf()
{
  static int buf[300];
  return buf;
}

Стандарт языка C++ гласит, что переменная buf будет инициализирована при первом вызове getBuf(), ну а поскольку для инициализации тут ничего делать не нужно, то этот массив просто будет выделен где нибудь в секции .bss (область памяти, которая заполняется нулями на старте прошивки)

int * getBuf()
{
  static int buf[300] = {1, 2, 3};
  return buf;
}

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

class Buf
{
public:
  int buf[300];
 
  Buf(int v)
  {
        buf[1] = v;
  }
};
 
int * getBuf()
{
  static Buf buf(1234);
  return buf.buf;
}

В таком варианте у нас появляется нетривиальный конструктор, который что-то делает при первом вызове функции getBuf(). Для платформы AVR (ATMega) компилятор сгенерирует специальный флажок, который будет регулировать нужно ли запускать конструктор или он уже был запущен до этого. Это нужно иметь в виду, т.к. под этот флажок расходуется немножко оперативной памяти, а также будет неявная проверка флажка при каждом вызове getBuf(), что может сказаться на производительности.

А вот на платформе ARM (например, STM32) получается весьма неожиданная штуковина. Как только появляется нетривиальный конструктор прошивка сразу вырастает примерно на 60кб и уже может не поместиться в микроконтроллер. Это связано с тем, что компилятор под платформу ARM более строго следует стандарту С++ и реализует потокобезопасную инициализацию статических переменных (на случай если несколько потоков вдруг одновременно зайдут в функцию getBuf()).

Более того, этот код также проверяет, а не вызывается ли эта функция рекурсивно во время инициализации нашей переменной? И хотя по стандарту это undefined behavior, реализация имени g++ кидает исключение recursive_init_error. А раз есть исключение, то есть и код, который эти исключения обслуживает. По меркам больших процессоров там не очень много (те самые 60кб), но вот для микроконтроллера это очень дофига.

Решение – добавить ключик компилятора -fno-threadsafe-statics, он как раз и предназначен для того, чтобы отключить всю эту лабуду если у нас нет многопоточности и мы уверенны, что этот код будет вызываться строго из одного потока.

Синглтон

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

class Singleton
{
    int buf[300];

public:
    static Singleton & getInstance()
    {
        static Singleton instance;
        return instance;
    }
    
    int * getBuf()
    {
        return buf;    
    }
};

void setup() 
{
    Serial.begin(9600);
    Singleton::getInstance().getBuf()[42] = 10;
}

void loop()
{
    Serial.println(Singleton::getInstance().getBuf()[42]);
}

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

00800116 l O .bss 00000258 Singleton::getInstance()::instance

Обратите внимание, что сам массив buf объявлен как обычный член данных класса. Статическим является экземпляр instance, который внутри содержит наш массив. К сожалению objdump описывает данные внутри объекта не очень детально. Если бы внутри класса Singleton помимо buf были бы и другие поля, objdump все равно бы их слепил вместе и показывал одной строкой.

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

Заключение

Оперативной памяти в небольших микроконтроллерах, как правило, не очень много. Если вам повезло и вы работаете с ARM (STM32, nRF, NXP) или ESP8266 то у Вас в распоряжении до нескольких десятков килобайт (в зависимости от «толстости» микроконтроллера). Если у Вас AVR (в составе Arduino или сам по себе), то это всего 1-4кб. Если же вам не повезло и у вас архитектура MCS51, то у вам доступно всего пара сотен байт.

И хотя стандартная библиотека позволяет использовать функции динамического выделения памяти (new, malloc), и эти функции используются во множестве библиотек (например которые входят в состав STM Cube, или доступны в мире Arduino), как мне кажется, динамическое выделение памяти в микроконтроллерах создает больше проблем чем приносит пользы.

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

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

Не стОит этот способ использовать для короткоживущих объектов, возможно размещение на стеке подойдет куда лучше. Также этот способ не подойдет, если для создания объектов нужна некоторая информация не доступная на этапе компиляции.

Всем спасибо кто дочитал эту статью до конца. Я буду рад конструктивной критике. Мне также будет интересно обсудить нюансы в комментариях.

Let's block ads! (Why?)

Настольная ролевая тактика

Доброго дня.
Сегодня речь пойдёт о настольно-ролевой системе собственной разработки, на создание которой вдохновили как консольные восточные игры, так и знакомство с западными настольно-ролевыми гигантами. Последние вблизи оказались не такими уж сказочными, как хотелось — громоздкие в плане правил, с несколько стерильными героями и предметами, перенасыщенные бухгалтерией.
Так почему бы не написать что-то своё? Со Знаками Зодиака и Эйдолонами. Примерно так оно всё и завертелось. Около пяти-шести лет ушло на то, чтобы из нескольких разрозненных страниц идея развилась в 256-страничную книгу.

«Монстробой» — ролевая игра, посвящённая сказочно-фантастическим тактическим сражениям. Здесь герои черпают новые боевые знания из своего оружия, монстры обладают собственным «искусственным интеллектом», а вместо получения опыта используется система достижений.

Но, обо всём по порядку. Общий взгляд на ролевые игры, как на явление, сформировался у меня где-то в 90-х, после прочтения преотличной обзорной статьи в одном из томов «Энциклопедии компьютерных игр». Статья эта так и называлась «О ролевых играх», в ней описывалась как специфика настольно-ролевого опыта, так и многочисленные примеры компьютерных ролёвок, перенявших атмосферу и колорит у настольных вселенных. Отдельно подчёркивалось то обстоятельство, что ролевые настольные игры — это не про состязание «кто победил» и не про «воспитание» мастером игры нерадивых участников, а про совместное творчество и занимательное времяпрепровождение для всех.

Мастер игры: Стоя на мостике снижающегося «Пшесо» солнечный эльф Сигмар всматривался в приближающийся туман. Да, где-то здесь должны были водится те редкие виды монстров, которые понадобятся в эксперименте. Он сунул ладонь в управляющую жемчужину корабля, чтобы скорректировать курс, и ракушкообразная посудина послушно отклонилась в сторону, обходя острый пик скалы. Наконец, среди тумана появился просвет и «Пшесо» устремился туда. Ракушкообразный корабль присел на небольшой каменистый уступ, огни силовых линий на его корпусе частично погасли, переходя в режим ожидания. Через пару минут нижняя часть раковины щёлкнула и выдвинулась вниз. Из чрева корабля на каменный уступ вышли вышли эльф, девушка-гриб и гоблин… Хотя, нет, пусть будут просто эльф и гоблин. Итак, дамы и господа, вы находитесь в Темнице Туманов!

Интриганка: Стоп, стоп! А что с девушкой-грибом?

Мастер игры: Пока с этих двух персонажей начнём, а там видно будет.

Знаток правил: Так и скажи, что забыл прописать ей параметры.

Мастер игры: * язвительно * Может я просто решил, что она слишком хороша, чтобы давать её вам?

Где-то в нулевых годах я делал различные небольшие настолки, чтобы было во что поиграть с друзьями, параллельно окунулся в дивный мир консольных эксклюзивов (незабываемая первая PlayStation), нашёл в городе клуб карточной Magic: The Gathering (в ту пору как раз вышла колоритная Камигава, понемногу отходил на покой мощнейший блок Мирродин, а карточки ещё не начали печатать на русском) и… наконец-то приобщился к настольно-ролевым играм тоже, найдя игровую компанию и практикующего мастера.

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

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

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

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

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

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

Мир игры

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

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

Свою иррацио герой воспринимает в виде особенной гаммы чувств, обретая знание о некоторых игромеханических параметрах. Например, о том, что у него есть некоторое количество здоровья. Основную массу прочих параметров герой ощущает как некие очевидные закономерности, которые достаточно трудно выразить словами. Есть и такие параметры, о наличии которых герой вовсе не догадывается: например, характеристики (Ловкость, Тело, Разум и Интуиция). Игроку все показатели и термины конечно же известны, но главный принцип, которым он руководствуется в своих решениях следующий: персонаж не является копией игрока, это настоящая живая личность, с собственными мотивами и представлениями об окружающем мире.

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

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

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

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

Сюжетные узлы

В системе «Монстробой» гибкий сеттинг, состоящий из общего описания мира и некоторых его отдельных участков, так называемых Узлов, не связанных между собой заранее какой-то общей картой. В книге приведены такие Узлы, как сказочный город водопадов (Утада), посёлок драконьих наездников (Заскан), восстановленные руины древнего города посреди пустыни (Новый Асгард), таинственный замок в лесу (Маторика) и так далее.

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

Исследователь: * нетерпеливо * Ну так что там дальше-то? Прилетели, и?

Мастер игры: Собственно разбирайте персонажей. Кто эльф, кто гоблин?

Интриганка: Я бы взяла гриба, но ты её не дал!

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

Тактик: Ага, боёвочка! Что у нас умеет гоблин?

Мастер игры: Гоблин умеет метать бомбы. И гранаты. Если ты гранатовое дерево найдёшь.

Тактик. О, беру его.

Исследователь: * обводя глазами партию* Я тогда эльф, если никто не против.

Интриганка: Да пожалуйста.

Мастер игры: Хорошо. Кстати, у него прелюбопытнейшая предыстория.

Биография и Характеристики

Биография — это несколько слов/фраз о сути персонажа. Например: «эльф», «ведьма», «заводной дракончик», «огненный маг с протезом вместо руки», «друид из Ветвистого леса», «купец, подозрительного вида», «королевский гонец», «орк-кузнец, проклятый», «ученик некроманта», «высокомерная девушка-паладин», «тень чужестранец со своим неживым псом» и так далее.
Этот параметр содержит все важные сведения о самом герое, его состоянии, указывает на возможные вектора развития героя.

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

Ловкость (гибкость огня)
Тело (твёрдость земли)
Разум (любознательность воздуха)
Интуиция (таинственность воды)

Каждый герой имеет представление о своей Биографии, но совершенно не подозревает о том, что на успешность его действий влияют Характеристики (от величины Характеристики не зависят ни внешность героя, ни его сила, ни масса, ни ум).

Например: у героя Биография «профессор техномагии», а его Разум равен "-2". Низкое значение Разума не делает героя глупым. Он хорошо разбирается в техномагических приборах и теориях, а также всём том, что может быть отнесено в эту область знания. Разум "-2" означает лишь то, что в делах требующих Разум, но с его стезёй, техномагией, вообще никак не связанных, он будет неудачлив.

Жизнь персонажа подчиняется вере в себя и личным амбициям. Он не может сравнить свои достижения с чьими-то ещё по абсолютной шкале, в оценке своих качеств он достаточно субъективен. Одних не останавливают неудачи, в то время как другие обманывают сами себя, зарывая истинный талант в землю.
В этом незнании кроется особенная прелесть: уверенность в чём-либо действительно превращает мыслимое в явное — совершая различные поступки герой тем самым зарабатывает Биографию. Каждая конкретная Биография, в свою очередь, повышает успешность тех действий персонажа, которые с ней связаны.

Например: если герой «друид», то чаще всего он сможет уже на этом основании бесшумно идти по лесу. А если мастер и решит назначить проверку по Ловкости для бесшумного передвижения, то её сложность для «друида» будет не высокой.

Мастер игры: Продолжаем. Едва отойдя от корабля Сигмар и Отто наткнулись на группу металлических големов, чей вид напоминал ожившие доспехи. Вокруг каждого из этих странных созданий клубился туман, проникая сквозь щели в металле. Один из големов тащил за собой сопротивляющуюся копну тёмных волос, другой вцепился в странное пышное создание с румяными, словно поджаренными боками. Прочие доспехи, увидев приближающихся эльфа и гоблина, бросились на них…

Тактик: Я полагаю, с целью расцеловать?

Мастер игры: Хуже. Кинь кубик… Хотя, пока не будем перегружать бросками. Первым будет ходить эльф, потом гоблин.

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

Кадр сражения из прототипа на Flash.

Сражения

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

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

В начале хода герой обычно получает около 3-х Очков действий и 1 Боевое действие. Очки действия тратятся в основном на перемещение, выполнение вспомогательных задач (вроде использования предметов или смены экипировки) и выступают в роли дополнительного ресурса (усиливая проводимую атаку). Боевые действия расходуются на различные атакующие приёмы, либо активацию мощных способностей.

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

Мастер игры: Раскидав в стороны враждебно настроенные доспехи вы освобождаете их добычу. Это девушка с чрезвычайно длинными, чуть шевелящимися волосами, которые почти полностью скрывают её фигуру. Вместе с ней, вас с любопытством оглядывает другое спасённое существо — слегка левитирующий над землёй ком, чего-то похожего на румяную сдобу, он и пахнет как свежевыпеченный хлеб. Присмотревшись к лежащим доспехам Отто заметил, что потоки тумана покидают их.

Тактик: Хм, что бы это могло значить? Надо поразмыслить.

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

Интриганка: Так-так. Что тут у нас? Дамочка в беде и пышка на ножках?

Тактик: * покатившись со смеху * Ну ты даёшь!

Исследователь: Какой пассаж!

Мастер игры: * наставительно * Вобще-то, эта ведьма тут ни разу не дамочка в беде, как ты выразилась. Она вполне способна за себя постоять. Кстати, кроме этой парочки вы можете брать металлических големов.

Ведьма Труанн — одна из предустановленных персонажей

Архетипы героев

У каждого героя есть некий боевой архетип. Всего их четыре: «Маг», «Ловкач», «Боец» и «Медиум». Названия архетипов условны и сами герои о них не знают (например, архетип «Маг» не означает, что герой обязательно является каким-нибудь заклинателем по Биографии).

Как уже было сказано ранее, первооснова каждого существа обладает некоторой прочностью: запасом Очков здоровья. Но кроме обычного здоровья у героев есть ещё и Душевное: чем оно выше, тем герой более сосредоточен при выполнении различных магических либо энергетических действий. Если герой теряет все Очки здоровья, то падает без сознания или даже умирает. Если же он теряет всё Душевное здоровье, то резко идёт на убыль его боевая эффективности: персонаж не может использовать приёмы и особые Таинства Знаков, ему остаётся лишь простая атака оружием или без него.

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

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

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

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

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

Помощница: А сколько было големов?

Мастер игры: В каком смысле?

Помощница: Ну, сколько персонажей в итоге будет в группе?

Знаток правил: Вероятно столько, сколько мы выберем.

Мастер игры: Естественно. Собственно, големы введены специально, как дополнительный выбор и как возможность расширить количество участников, если на игру пришло бы большее количество человек.

Интриганка: Занятно.

Тактик: Но это же клоны. Быть клоном — плохо.

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

Таинства

Герои «Монстробоя» умеют несколько раз в день пользоваться разнообразными мистическими дисциплинами, Таинствами. Их ровно 12, каждому из них покровительствует свой Знак Зодиака. На старте игры каждый персонаж владеет Таинствами двух Знаков — своего родного и второстепенного.

Каждое Таинство можно применить двумя разными способами: театральным и тактическим. Первый способ применяется только во время повествовательной части игры. Второй способ используется в тактическом сражении или же неким образом с ним связан (позволяет создать боевой предмет или зачаровать оружие).

Например: Таинство Мимикрия (Знак покровитель: Рак) позволяет владельцу копировать наблюдаемые им магические, энергетические или мистические эффекты за трату 1 использования. Можно метнуть встречный сгусток огня в злого дракона, поднять мертвеца в ответ на аналогичное действие некроманта и так далее. За трату дополнительного использования можно отменить эффект вместо его копирования. Во время тактического сражения Мимикрия позволяет герою дублировать чужие атаки или приёмы.

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

Интриганка: Отлично, я буду металлическим големом!

Мастер игры: Я думал ты ведьму возьмёшь.

Помощница: Ведьмочку я возьму. У неё книжка заклинаний есть?

Интриганка: Я гриба взять хотела. О, можно на моём големе будет набит барельеф в виде мухомора?

Исследователь: Похоже будет не скучно.

Мастер игры: Прямо радуете меня. Да, книжка есть. Да, можно барельеф. *глядя на Знатока правил* Кого берёшь — хлебобулочного элементаля или металлического голема?

Знаток правил: Так это хлебобулочный элементаль был? Беру вот прям не глядя.

Мастер игры: Тебе понравится, он ещё и целитель.

Знаток правил: Служитель Великой небесной хлебопекарни?

Мастер игры: Почти.

Интриганка. О, он будет печь нам лечильные булочки!

Тактик: Или летальные.

Исследователь: Всё от начинки зависит.

Помощница: Булочки — это хорошо!

Мастер игры: Давайте лучше познакомим героев. Расскажите друг другу о себе.

Кубики

«Монстробой» использует 3 вида кубиков: четырёхгранник (D4), шестигранник (D6) и двадцатигранник (D20). У каждого из них своя роль в игромеханике: четырёхгранник и двадцатигранник используются в тактике, шестигранник чаще всего регулирует повествование.

D4, оружейная атака

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

Например: герой атакует врага Палашом. Параметры урона этого оружия: 2/3/4/4. На кубике выпал 1, значит враг получит 2 повреждения.

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

Например: Волшебная палочка (-/0/1/1) зачарована на "+1" огненное повреждения к атаке. Если на кубике выпадет 1, то атака этого оружия промахнётся. Если выпадет 2, то Волшебная палочка попадает, нанося врагу 0 физических повреждений и 1 огненное. Если выпадет 3 или 4, то враг получит 1 физическое и 1 огненное повреждение.

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

Например: Чернильная шпага бьет врагов тьмой, а не физикой. Её параметры: И/4/6/8. Владелец шпаги сейчас имеет Интуицию равную 5. Если на кубике атаки выпадет 1, то шпага нанесёт 5 повреждений тьмой.

D6, проверки

Во время повествования некоторые действия героев требуют успешной проверки по одной из Характеристик (Ловкость, Тело, Разум, Интуиция). Мастер устанавливает сложность проверки, а игрок бросает кубик, складывая с требуемой Характеристикой.

Например: ведьма хочет понять смысл древних символов, которые покрывают стены катакомб. Мастер назначает проверку по Разуму со сложностью 6. Разум ведьмы равен 2, на кубике выпало 3. В сумме вышло 5, что ниже требуемой сложности, поэтому смысл символов разгадать не удалось.

D20, интеллект монстров

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

Например: идёт бой, ход получает вражеский Гоблин. Мастер бросает кубик, выпало 19. В параметрах Гоблина указано, что если выпало значение от 15 до 20 то ему положено наложить Ауру Отравления на цель в радиусе 1. Мастер пододвигает Гоблина к одному из героев, после чего накладывает на того Ауру Отравления.

В понятие игромеханической модели монстра входят следующие параметры:

Идентификационные — ранг (от 1 до 5), Знак (один из 12), тип (нежить, животное, гоблин и так далее).
Основные — это Очки здоровья и Скорость (иногда есть Очки маны).
Действия — перечень атак и приёмов, привязанных к интервалам 20-гранника.
Опциональные — физическая и магические защиты, иммунитеты, прочие особенности и ограничения.

Игроки таким же способом управляют призванными монстрами и Эйдолонами (особыми существами, в которых герои могут перевоплощаться с помощью Таинств Знака Скорпион).

Например: на несколько ходов паладин 2-го уровня превратился в Левиафана, Зодчего Глубин (Эйдолон водной стихии). Каждый ход игрок кидает кубик, выясняя предписанное действие, сейчас выпало 2. Число из диапазона от 1 до 9 предписывает Левиафану нанести цели в радиусе 1 повреждения Водой равные 2 + уровень героя. Таким образом Эйдолон нанесёт врагу 4 водных повреждения.

Интриганка: Ну что ты стоишь, преврати его в жабу!

Помощница: А я умею? Мастер, мастер?

Мастер игры: Я думаю твоя специализация к этому располагает, но ты пока начинающая, поэтому не владеешь конкретно этим заклинанием.

Интриганка: Ну и ладно, всёравно — угрожай, блефуй, запугивай!

Помощница: Давайте просто отпустим эту тень с миром, она же нам пока ничего не сделала.

Интриганка: Какая-то ты не очень злая ведьма.

Помощница: А почему ведьма должна быть злая? Она ведь не старая.

Знаток правил: И вот тут я, наконец, всё понял про ведьм.

Интриганка: Ты тогда просигнализируй, как постареешь. Я хоть спрятаться успею.

Помощница: Поздно, я тебя запомнила!

Титулы и Вехи

В бою персонажи могут открыть Титулы — различные простые достижения. Можно обладать многими Титулами, но лишь один из них активен в течение игрового дня и даёт герою свой специфический бонус. Те герои, которым доступно Выступление (Таинство Знака Водолей) могут во время сражения напевать известный им Титул, делясь его эффектом со всеми союзниками. Кроме того есть секретные (уникальные) Титулы, которые можно открыть лишь однажды, после чего они становятся недоступны для прочих героев.

Пример Титула:

«Спаситель», секретный Титул
Условия получения: вы пережили состояние достаточно близкое к смерти, но не умерли, а кроме того есть кто-то, кто-то вас любит.
Преимущества Титула: «тот, кого вы держите за руку не может умереть» (черта биографии).

Но одними Титулами «Монстробой» не ограничивается. Он развивает эти идеи и идёт дальше, вовсе отказываясь от использования игрового опыта (Exp) в пользу глобальных игровых достижений — Вех. Герой начинает с первым уровнем Вехи и может 9 раз открыть те Вехи, что предусмотрены планом развития (прокачиваясь таким образом с первого уровня до максимального, 10-го).

Примеры Вех:

«Миссия» — герой выполнил важное задание, полученное от игрового субъекта

«Вкус боя» — герой одержал победу в 3-х сражениях

«Эхо отражений» — герой находился в состоянии Транса

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

План может быть достаточно простым и узконаправленным, например, «Миссия (9)», то есть герой будет получать уровни только за выполнение важных сюжетных заданий и для получения максимального уровня Вехи ему просто нужно открыть «Миссию» 9 раз подряд — то есть выполнить 9 разных поручений, взятых у персонажей игрового мира. Также план может быть очень разнообразным и максимально свободным, когда предложено сразу много Вех, каждую из которых можно открыть более чем один раз.

Открытки персонажей

Конечно, в «Монстробое» можно создать героя с нуля, прочитав посвящённую этому главу. Однако, я решил предлагать начинающим не лишь конструктор «собери сам», а готовых уникальных героев. Каждый из них относится к отдельному классу и имеет намётки характера. Это важно, потому что хотелось бы подчеркнуть тот момент, что герой не является копией игрока. Подобное сложно прочувствовать, когда ты ещё лишь приходишь в хобби и тебе дают конструктор героя — велик соблазн собирать болванку попроще, без особой истории, и так же поступать в дальнейшем. Это не проблема в играх компьютерных, но за столом может ею стать.

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

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

Импровизация

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

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

Миниатюрки

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

Лично мне в тактических ролёвках, играемых за столом, хотелось бы видеть какие-то стандартизированные не слишком ярко-выраженные миниатюры. Нечто такое универсальное в стиле кубизма-минимализма, особенно это касается противников/монстриков. Обычно же играющие используют те миниатюрки, что оказались под руками, собранные из разных источников, наборов и игр.

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

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

Это я всё к тому, какие фигурки стал бы класть в коробку со своей игрой, если бы такая коробка выпускалась:

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

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

Очень желательно видеть какую-то нумерацию на модельках из одной группы. Это могут быть циферки, точечки, полосочки, буквы, символы. На животе фигурки, на спине или сверху. Это было бы очень удобно, чтобы отслеживать количество оставшегося у врага здоровья. То есть, когда герой ткнул вон ту фигурку слева от него из группки скелетов, то мы сразу видим, что это какой-нибудь «скелет номер 3» получил по шапке, а не кто-то другой. Опять же, очень помогает мастеру отслеживать — кем из противников он уже походил, а кем ещё нет.

Когда на столе выставлено столько всего — пойди разберись, кто есть кто.

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

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

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

Вот таких симпатичных милах откопал на просторах интернета.

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

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

Тессерфакт

В принципе игромеханику «Монстробоя» можно адаптировать для компьютерной реализации. Хотя это не так уж просто, как кажется. Просто мне всегда нравилась Final Fantasy Tactics, хотелось бы чего-то в подобном стиле, а боёвка «Монстробоя» довольно близка по духу. Как бы то ни было, компьютерная тактика — это пока просто одна из идей, отложенных в долгий ящик. Был только маленький флэш прототип с одной сценой и вот этот вот ролик, показывающий направление мысли.

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

А это видео более позднее. Собирал в Unity одну из гипотетических локаций. Тут уже больше похоже на стиль FFT.

Итог

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

Всё мои ролевые книжки и сопутствующие материалы можно найти на сайте: https://twistedterra.github.io/

На том и закончу рассказ. Хороших вам выходных.

Let's block ads! (Why?)

Как настроить HTTPS — поможет SSL Configuration Generator

Рассказываем об инструменте для конфигурации SSL, который разработали в Mozilla.

Под катом — о его возможностях и других утилитах для настройки сайтов.

Фото — Lai Man Nung — Unsplash

Зачем нужен генератор

Прежде чем перейти к рассказу о возможностях инструмента, поговорим о его назначении. При работе с HTTPS шифрование применяется в четырех случаях: во время обмена ключами, в SSL-сертификатах, при пересылке сообщений и составлении хеш-суммы (дайджеста).

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

Например, шифронабор ECDHE-ECDSA-CHACHA20-POLY1305 означает, что обмен ключами происходит по протоколу Диффи — Хеллмана на эллиптических кривых (ECDHE). При этом используются эфемерные ключи (одноразовые) для установки только одного соединения. Центр сертификации подписал сертификат при помощи алгоритма ECDSA (Elliptic Curve Digital Signature Algorithm), а для шифрования сообщений применяется поточный алгоритм ChaCha20. За их целостность отвечает POLY1305, вычисляющий 16-байтный аутентификатор.

Полный список всех доступных комбинаций алгоритмов можно найти на wiki-страничке Mozilla.

Для настройки криптографических методов, используемых сервером, в сети есть специальные инструменты. Такую функциональность имеет SSL Configuration Generator, разработанный в Mozilla.

Что он собой представляет

В Mozilla предлагают три рекомендуемые конфигурации для серверов, использующих TLS:

• Современная — для работы с клиентами, использующими TLS 1.3 без обратной совместимости.
• Промежуточная — рекомендуемая конфигурация для большинства серверов.
• Устаревшая — доступ к сервису осуществляется с помощью старых клиентов или библиотек, таких как IE8, Java 6 или OpenSSL 0.9.8.

Например, в первом случае генератор использует алгоритм шифрования AES128/256, алгоритм хеширования SHA256/384 и режим работы симметричных блочных шифров GCM. Вот пример шифронабора: TLS_AES_256_GCM_SHA384.

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

С учетом этих требований SSL Configuration Generator строит конфигурационный файл (OpenSSL). При построении можно выбрать необходимое серверное программное обеспечение: Apache, HAProxy, MySQL, nginx, PostgreSQL и еще пять других. Вот пример современной конфигурации для Apache:

# generated 2019-07-04, https://ssl-config.mozilla.org/#server=apache&server-version=2.4.39&config=modern
# requires mod_ssl, mod_socache_shmcb, mod_rewrite, and mod_headers
<VirtualHost *:80>
    RewriteEngine On
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile      /path/to/signed_cert_and_intermediate_certs
    SSLCertificateKeyFile   /path/to/private_key

    # enable HTTP/2, if available
    Protocols h2 http/1.1

    # HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
    Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

# modern configuration, tweak to your needs
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

Генерируемые конфигурации можно использовать в своем проекте, нужно лишь отредактировать пути сертификата и секретного ключа и загрузить настройки. Однако, как говорит один из резидентов Hacker News, важно обратить внимание на версию сервера, чтобы получить правильные результаты. В частности, вывод для nginx 1.0 и nginx 1.4 значительно отличается. Также есть мнение, что в некоторых случаях придется вручную подправить часть сгенерированных шифронаборов, чтобы сохранить обратную совместимость и получить высокую оценку в бенчмарках для сканирования сайтов.

Какие еще утилиты помогут с защитой сайтов

В портфолио Mozilla есть несколько утилит, которые помогут проверить надежность ресурса после конфигурирования SSL.

Первая — это Mozilla Observatory. Изначально компания разрабатывала инструмент для проверки защищенности своих собственных доменов. Теперь он доступен всем вместе с исходным кодом. Observatory сканирует сайты на самые популярные уязвимости, среди них: потенциально опасные cookies, XSS-уязвимости и редиректы. После сканирования системы выдает набор рекомендаций для повышения безопасности интернет-ресурса.

Фото — sebastiaan stam — Unsplash

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

^{Наши публикации из блогов и социальных сетей:}

^{Как защитить виртуальный сервер в интернете
Зачем нужен мониторинг?
Получение OV и EV сертификата — что нужно знать?}

^{Mobile-first индексация с первого июля — как проверить свой сайт?
F.A.Q. по частному облаку от 1cloud}

^{Как оценить производительность СХД на Linux: бенчмаркинг с помощью открытых инструментов
Есть мнение: технология DANE для браузеров провалилась}

Let's block ads! (Why?)

Власти выделяют средства на создание российского конкурента «Википедии»

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

Идея о создании отечественного аналога «Википедии» появилась не сейчас, а несколько лет назад. В 2016 году занимавший на тот момент должность директора Российской национальной библиотеки Александр Вислый заявил, что именно этот ресурс станет электронным аналогом Большой российской энциклопедии. Одновременно он позиционировался как «конкурент „Википедии“».
Кроме того, в 2016 году председатель российского правительства Дмитрий Медведев утвердил рабочую группу, которая должна была реализовать этот проект. В группу вошел 21 человек, включая первого заместителя главы аппарата правительства Сергея Приходько и замминистра связи и массовых коммуникаций Алексея Волина.

В документе, который был разработан и представлен Минкомсвязи в этом месяце, говорится о правилах выделения государством средств из федерального бюджета для реализации проекта. Действие положений законопроекта будет распространяться на все «правоотношения, возникшие с 1 января 2019 года».

В соответствии с новым законопроектом, средства на создание российского «конкурента „Википедии“» должны соответствовать лимитам, которые выделяются государством Роспечати. Ну а конечным получателем этих средств станет издательство «Большая Российская энциклопедия».

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

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

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

Созданием бумажной версии БРЭ занимается научное издательство «Большая российская энциклопедия», которое было образовано в 1925 г. и до 1991 г. именовалось «Большая советская энциклопедия». В настоящее время в издательстве работает около 200 человек (в советские времена штат достигал 600 человек).

Let's block ads! (Why?)

Отозван законопроект об обязательной предустановке российских приложений

Автор законопроекта об обязательной предустановке российских приложений отозвал свой документ. Если бы законопроект приняли, то в России запретили бы продажу смартфонов и компьютеров без предустановленного отечественного ПО. Соответствующие уведомления размещены в карточках законопроектов на сайте Госдумы.

3 июля в Госдуму был внесен пакет из трех законопроектов: поправки в закон «О защите прав потребителей», Кодекс об административных правонарушениях (КоАП) и в закон «О защите конкуренции». Документ устанавливал запрет на продажу в РФ гаджетов, включая смартфоны, компьютеры, телевизоры с функцией Smart TV, которые не соответствую требованиям об установленном на них программном обеспечении.
Кроме всего прочего, обязательные для предустановки программы должны были быть закреплены в специально созданном реестре. Порядок ведения этого реестра и его оператора должно было определить правительство.

За продажу устройств, которые не соответствовали бы требованиям законодательства продавцам грозили штрафы. Для частных лиц от 100 тыс. до 500 тыс. рублей, для компаний от 500 тыс. до 1 млн рублей.

В поправках внесенных депутатами в закон «О защите конкуренции» вводилось понятие «значимых хозяйственных объектов», которые владеют «экосистемами» программ. Такие компании при помощи программного обеспечения контролируют около 35% рынка, получают выручку преимущественно от российских пользователей, а их программы используются сразу в нескольких отраслях экономики. Согласно поправкам он должны обрабатывать данные исключительно на территории РФ, обеспечивая к данным недискриминационный доступ. Доля иностранного участия в их капитале не должна превышать 20%.

Аналогичный проект предлагало и Минкомсвязи. В документе упоминалась необходимость обязательной установки приложений, которые созданы российскими разработчиками, на смартфоны и другие устройства, поставляемые в РФ. В качестве такого ПО упоминались карты от «Яндекса», приложения отечественных социальных сетей, антивирус от «Лаборатории Касперского». Конкретный же перечень оборудования, на которое должны быть установлены приложения, а также перечень типов софта, который подлежит обязательной установке, тоже должно определять правительство.

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

Представитель Минкомсвязи отказался сообщить, будет ли опубликован собственный законопроект ведомства о предустановке отечественных приложений. Законопроекты, которые были внесены Жигаревым в Госдуму, в министерство не поступали, а о причинах их отзыва из Госдумы ничего неизвестно.

Let's block ads! (Why?)

Новости недели: «Яндекс» и западные спецслужбы, ФАС борется с онлайн-казино, Минтранс регулирует работу BlaBlaCar

В новом дайджесте читайте:

• «Яндекс» подвергался атакам западных спецслужб;
• Google планирует за деньги раздавать интернет с воздушных шаров;
• Минтранс занялся регуляций деятельности BlaBlaCar и других транспортников;
• НАСА планирует отправить ровер на Титан;
• Дональд Трамп отменяет санкции против Huawei;
• ФАС серьезно возьмется за онлайн-казино;
• Corel и Parallels проданы за $1 млрд.

«Яндекс» и западные спецслужбы

Компания «Яндекс» заявила о том, что в конце 2018 года подверглась атакам злоумышленников. Эта атака заключалась в попытках киберпреступников внедрить в инфраструктуру компании редкий тип зловреда. При условии успешного введения его в сеть оператор malware может следить за учетными записями пользователей сервисов компании.

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

Google будет раздавать интернет с воздушных шаров в Кении

В течение ближайших нескольких недель компания Google совместно с одним из крупнейших интернет-провайдеров Кении собираются запустить интернет по воздуху. Речь идет о проекте Project Loon, который постепенно реализуется корпорацией.

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

Если проект Google хорошо себя покажет в Кении, то его протестируют и другие компании, которые упомянуты выше. «Если результаты будут положительными, мы будем заинтересованы в проекте», — сообщил представитель Orange Middle East and Africa.

Минтранс будет регулировать работу онлайн-агрегаторов совместных поездок на автомобилях

Министерство транспорта России планирует заняться регулированием онлайн-агрегаторов. Крупнейшим сервисом такого рода является BlaBlaCar. Проект накладывает ряд ограничений на возможности тех пользователей, которые предлагают транспортные услуги.

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

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

НАСА отправляет ровер на Титан, правда, не сегодня и не завтра

Агенство НАСА заявило о намерении отправить на Титан летающий ровер Dragonfly. Это устройство, по плану, отправится на планетоид в 2026 году. Опуститься в атмосферу объекта оно должно в 2034 году. Аппарат представляет собой октокоптер — это дрон с четырьмя двойными винтами. Такого рода коптеры еще ни разу не высаживались за пределами Земли.

«Аппарат будет летать в десятки мест на Титане в поисках химических элементов и процессов, распространенных как на Титане, так и на Земле. Титан является аналогом Земли на самой ранней стадии ее развития и может дать подсказку о том, как могла появиться жизнь на нашей планете», — заявляет NASA в своем пресс-релизе.

США отменяет санкции против Huawei

Президент США Дональд Трамп заявил о том, что почти все санкции против китайской компании Huawei отменяются. Переговоры по этому вопросу были проведены на саммите большой двадцатки в Японии.

Насколько можно понять, поводом для снятия санкций с Huawei, очевидно, послужили успешные переговоры между представителями стран относительно планируемого США повышения пошлин на импортируемые товары из Китая. Ранее Дональд Трамп изъявлял недовольство торговым дисбалансом между двумя странами. В результате же проведенных переговоров он заявил: “Теперь мы не планируем в ближайшее время повышать тарифы в отношении Китая. Мы рассчитываем на сотрудничество с Китаем. Похоже, они открыты для общения и готовы начать тратить деньги".

ФАС будет бороться с незаконной рекламой онлайн-казино

Федеральная антимонопольная служба (ФАС) России собирается получить право блокировки сайтов с незаконной рекламой онлайн-казино с помощью Роскомнадзора.

«Проблема с онлайн-казино действительно большая. Реклама казино у нас запрещена в интернете. И, в принципе, в поисковиках и на новостных сайтах она не появляется. Такая реклама в большей степени характерна для сайтов с пиратским контентом, но не всегда эти сайты расположены в наших доменных зонах, поэтому не всегда возможно закрыть доступ к такому сайту. Мы эту проблему знаем и пытаемся решить», — рассказала информагентству ТАСС Татьяна Никитина, начальник управления контроля рекламы и недобросовестной конкуренции ФАС.

Corel и Parallels продали за $1 млрд

Компании, о которых говорится в заголовке, были куплены инвестиционной группой KKR из США. О том, что KKR планирует приобрести Corel стало известно еще в мае 2019 года — правда, тогда четкого сигнала от покупателя не было, так что информация ходила лишь в виде слухов. Сейчас итоговая сумма сделки не раскрывается, но источники, близкие как к продавцу, так и к покупателю, заявляют, что объем сделки составляет не менее $1 млрд.

В KRR заявили, что планируют и дальше продолжать политику Corel — покупать перспективные компании и использовать их активы. На данный момент неизвестно, какие продукты Corel будут продолжать развивать, а какие останутся в прежнем виде или будут закрыты.

Let's block ads! (Why?)

User Inyerface — как не надо мучать пользователя

Студия Bagaar собрала худшие элементы сайтов в одной онлайн-форме и предложила ее заполнить. Сможете пройти это испытание?
Ссылка на онлайн-форму.

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

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

Конечно, в интернете нет настолько плохих сайтов, но есть те, которые «подбираются очень близко к User Inyerface, и в этом заключается истинный ужас», — считают в The Verge.

На самом деле, по ссылке лучше заходить с планшета или смартфона — намучайтесь больше куда и как нажать в каком месте странички, чтобы дальше пошло дело!

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

Кстати, самое большое время можно потратить… на заполнение первой формы. Ибо там столько напихано и всплывает сразу через некоторое время.

Когда галочка не для «галочки»:

А тут пользователь просто озадачен:

Выбор страны просто прелесть:

Как и даты рождения:

Доживем и переживем:

Отдельная тема тут — проверка на то, что Вы человек.

Попробуйте тут просто пересмотреть ВСЕ виды вопросов, которые Вам задают и варианты ответов. Это очень забавно и действительно мозг начинает что-то подозревать:

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

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

Например, счетчик в меню помощи добавляет одного пользователя при каждом нажатии Help в форме:

Let's block ads! (Why?)