Я прошёл эту игру. Нет, не так. Наконец-то я прошёл эту игру! И она отвратительная. У меня есть вопросы. Несколько.
Вопрос 1.
Зачем было менять классическое управление с point-to-click на адаптированный для консолей выкидышь трёхмерных игр? И если так уж хотелось именно 3D, почему не взяли механику от Тени судьбы/Shadow of Destiny/Shadow of Memories. Она была хорошей для начала 2000-х. Вместо этого Кейт управляется с фиксированной камеры. Камера, конечно, следует за ней при движении, но существует места, где это совершенно никак не помогает Кейт перемещаться. Поэтому она застревает, например, в какой-нибудь бочке на рынке или скамейке на корабле.
Непродуманная смена локаций вызывает только разражение: бежим направо, добежали до лестницы, переключились на новую локацию. Всё ещё наклоняете левый стик направо? Зря, вы вернулись на предыдущую локацию, но поняли это слишком поздно. И, будьте добры, подождите минуту, пока локация загрузиться (квест должен быть сложным!).
Поэтому игра тормозит. Все эти камеры, движение рывками и долгое ожидание смены локаций заставили меня и поскучать и побеситься.
Вопрос 2.
Кто это переводил? Перевод и субтитры сделаны в лучших традициях кустарного перевода аниме.
Вопрос 3.
Почему геймплей ужасен?
Первое, что сразу раздражает, — прокрутка рюкзака. Рюкзам сделан в виде списка, а новые предметы помещаются в конец. Чем больше предметов соберёте, тем дольше вам его крутить. Ну почему нельзя было класть новые предметы в начало этого списка?
Второе, что погрузит в тоску, — геймплей построен по принципу: спроси и иди проверь что нового появилось на открытых локациях. Кстати, сами квесты-то не очень сложные, поэтому, быстро поняв, как мне сделать печать, чтобы выбраться из деревни, я долго пытался заставить кузнеца поговорить со мной об этом. Вот инструкция, как пройти этот уровень (если ваш кузнец также не сговорчив, как и мой): обязательно найдите бородача на рынке, чтобы получить у него бланк, положите бланкв машину для печати, чтобы при следующей беседе кузнец спросил у вас, не нужно ли вам чего. И я бы простил такой геймплей, если бы игра, ****, не томрозила.
Кстати, из-за управления я долго не мог понять, как включить ледорубы. Издалека мне было совсем не видно, что над кнопкой есть стеклянный предохранитель, которое нужно было сначала отодвинуть. Узнал я это, кстати, из прохождения на ютубе. Вообще, ближе к концу игры я всё чаще лазил за подсказками ради того, чтобы понять, где искать какую-нибудь мелочь. Как, например, шестерёнку для колеса обозрения. Сколько раз я бегал через комнату с инструментами в парке развлечений, но ни разу не замечал коробки, где и лежала эта чёртова шестерёнка.
Так что
Если вы поклоник 1 и 2 частей, то не покупайте и не играйте в 3. Хотя, лучше вообще не покупайте 3-ю часть: концовка ужасная, а сюжет в целом слабый и вымученный. Главные злодеи есть, чтобы были. Юколы бесполезны и на протяжении всей игры орут: «Помоги, Кейт Уока». А в заключительной части они всё равно вас кинут.
P.S. СПОЙЛЕР: в игре Оскар оживает. И есть кусок игры, где нам дают за него поиграем. Только движения у этого автоматона такие же, как и у Кейт. На этом всё.
Троллинг и хейтерство
…тролли выбирают в качестве потенциальных жертв представителей тех сообществ и групп, которые в культуре воспринимаются как незащищенные. Поэтому если вы видите троллинг в отношении женщин, подростков или инокультурных, инонациональных групп, то вы можете сразу фиксировать, что в этой культуре существует хорошо развитый сексизм, другие хорошо развитые типы дискриминации.
Закон Амдала иллюстрирует ограничение роста производительности вычислительной системы с увеличением количества вычислителей:
Закон Густавсона — Барсиса — оценка максимально достижимого ускорения выполнения параллельной программы, в зависимости от количества одновременно выполняемых потоков вычислений («процессоров») и доли последовательных расчётов:
Прежде чем начать
Стоит ли задача усилий?
Оптимизирован ли код?
Используется ли эффективный алгоритм?
Какие части задачи наиболее интенсинвы в вычислительном отношении?
Декомпозиция бывает: по заданиям, по данным, по потокам данных.
Декомпозиция по заданиям делится на task parallelism (линейная процедура) и divide and conquer (рекурсивная процедура).
Декомпозиция по данным делится на геометрическую декомпозиция (линейная процедура) и рекурсивные данные (рекурсивная процедура).
Декомпозиция по потокам данных делится на конвейерную обработку (регулярный) и координацию на основе событий (нерегулярная).
Буду честен, всегда испытывал сложности с выражением мыслей. И тем более с правильным их изложением на бумаге без ошибок. Поэтому часто под моими статьями для студентов можно увидеть такую табличку:
Материал дополняется, поэтому любые комментарии и исправления приветствуются.
Сообщите об опечатке, выделив ошибку в тексте и нажав на Ctrl + Enter.
Я люблю текст и красивое оформление. В университете я долго готовился к презентациям и докладам, а после прочтения книги «Живая типографика» увлекался типографикой (правда, недолго). Так, к примеру, выглядела моя презентация для сдачи бакалаврской работы (включите отображение комментариев к слайдам, чтобы понять о чём речь):
Про инфостиль, редакторскую работу и вот это всё
Книга «Пиши, сокращай» — это прекрасный учебник для тех, кто хочет перестать писать многословно и запутывать собеседника непонятными словами. Для студентов это возможность писать хорошие статьи и отчёты, а для коллег — описание задач. Авторы книги быстрее убедят вас на странице о своей книге. Рекомендую всем, кому важно о чём и как они пишут.
Книга Главреда
Как создавать сильный текст в информационном стиле. Второе издание.
Java Swing устарел. Не настолько, чтобы стать ненужным, и не так, чтобы с ним было бы невозможно написать хороший интерфейс. Но он устарел достаточно, чтобы программирование интерфейсов стало рутинным и утомительным процессом. Таблицы используются часто, даже очень. Для создания кастомной модели реализуется интерфейс javax.swing.table.TableModel или (чаще) наследуются от javax.swing.table.AbstractTableModel. Но каша из столбцов, констант, индексов и наименований столбцов превращает поддержку модели в ад. Самой ненавистной мною частью является хранение наименований и типов классов в отдельных переменных. Такое можно увидеть и в официальной документации:
class MyTableModel extends AbstractTableModel {
private String[] columnNames = ...//same as before...
private Object[][] data = ...//same as before...
...
}
Из-за этого в других частях кода я часто вижу использование неименованных индексов столбцов и сравнение их по имени. Вот вам совет: используйте перечисления для работы с колонками таблицы:
public enum IntegerFormatColumns {
/**
* Значение, как оно есть.
*/
SIMPLE {
@Override
public Object getValue(Integer i) {
return i;
}
// переопределяем тип возвращаемого значения
@Override
public Class<?> getColumnClass() {
return Integer.class;
}
},
/**
* Шестнадцатиричное представление числа.
*/
HEX {
@Override
public Object getValue(Integer i) {
return Integer.toHexString(i);
}
},
/**
* Двоичное представление числа.
*/
BINARY {
@Override
public Object getValue(Integer i) {
return Integer.toBinaryString(i);
}
}
;
/**
* Метод, который извлекает показываемое значение из исходных данных
* @param i исходные данные
* @return отображаемый в таблице результат
*/
public abstract Object getValue(Integer i);
/**
* Метод извлечения названия столбца таблицы.
*
* Для примера название извлекается из именования элемента перечисления.
*
* @return название столбца таблицы.
*/
public String getColumnName() {
return name();
}
/**
* Метод извлечения класса отображаемого результата.
*
* По умолчанию, это класс {@link String}.
*
* @return класс отображаемого результата
*/
public Class<?> getColumnClass() {
return String.class;
}
}
Используем этот класс в модели:
public static class IntegerFormatModel extends AbstractTableModel {
private final List<Integer> values = new ArrayList<>();
@Override
public int getRowCount() {
return values.size();
}
@Override
public int getColumnCount() {
return IntegerFormatColumns.values().length;
}
@Override
public String getColumnName(int column) {
return IntegerFormatColumns.values()[column].getColumnName();
}
@Override
public Class<?> getColumnClass(int columnIndex) {
return IntegerFormatColumns.values()[columnIndex].getColumnClass();
}
@Override
public Object getValueAt(int rowIndex, int columnIndex) {
return IntegerFormatColumns.values()[columnIndex].getValue(values.get(rowIndex));
}
}
Бесплатно вы получите возможность добавлять/изменять/удалять столбцы без вмешательства в саму модель и простой способ получения индекса столбца:
Каждый, кто начинает обрабатывать цифровые изображения, видел или работал с этой фотографией:
Оригинальное изображение в формате TIFF
Девушку на фотографии зовут Лена Сёдерберг, а вот перевод статьи с историей её появления в научных статьях:
Изображение Лены (Lena или Lenna) — одно из наиболее часто используемых в алгоритмах сжатия стандартных тестовых изображений. Сайт comp.compression FAQ сообщает следующее:
Для любопытных: «Лена» или «Ленна» — оцифрованный разворот Плейбоя ноября 1972 года. (Ленна — имя, использованное в Плейбое, Лена с одной «н» — шведское имя.) Лена Сёдерберг (Lena Soderberg) по последним сведеньях живёт в её родной Швеции, счастлива замужем, имеет 3-х детей и работу в региональной алкогольной монополии. В 1988 её впервые опрашивали несколько шведских изданий, связанных с компьютерными технологиями, и её приятно повеселило, что случилось с её фотографией. Тогда она впервые узнала об использовании фотографии в сфере компьютерных технологий.
Почитайте чудесную статью в Newsletter от мая 2001 за авторством Джейми Хатчинсон на IEEE Professional Communication Society, если хотите знать больше. Вот небольшая выдержка:
Александр Савчук рассказывает, что был июнь или июль 1973, когда он, будучи ассистентом профессора электроинженерии в институте обработки сигналов и изображений (USC SIPI), спешно искал в лаборатории хорошее изображение для сканирования в статью своего коллеги на конференцию. Они просмотрели их набор стандартных тестовых изображений, но хотелось чего-нибудь отпечатанного на глянцевой бумаге журнала, чтобы быть уверенными в хорошем динамическом диапазоне выходного изображения; и им нужно было лицо. Именно тогда, кто-то зашёл с последним выпуском Плейбоя.
Инженеры оторвали верхнюю треть разворота, чтобы она могла поместиться вокруг барабана их сканера широкоформатных изображений, подсоединённого к установке из аналогово-цифровых преобразователей (по одному на красный, зелёный и синий каналы) и миникомпьютера Hewlett Packard 2100. Сканер имел фиксированное разрешение в 100 линий на дюйм, и, поскольку инженеры хотели получить изображение размером 512 на 512 точек, они ограничили сканирование в 5.12 дюймов, чего хватило для оцифровки разворота вплоть до плеч модели.
На протяжении многих лет шли дискуссии об использовании этого изображения. Часть экспертов предлагали запретить использование этого изображения из-за его происхождения. Помимо этого Плейбой угрожал судебными разбирательствами за несанкционированное использование изображения. Почитайте об этом в редакторской статье журнала SPIE инженеров оптики или в записке бывшего главного редактора в соглашении об обработке изображений IEEE. Согласно Wired Magazine, Плейбой прекратил преследование за нарушения прав использования этого изображения, но по-прежнему остаётся их владельцем.
Ещё один любопытный факт о выпуске с Леной (Мисс Ноябрь 1972) — это самый продаваемый выпуск за всю историю Плейбоя (продано 7 161 561 копий).
А в мае 1997 года Лена присутствовала на юбилейной конференции IS&T (50 лет) и вот как это прошло.