-
Похожие публикации
-
-
Автор: romka
В игровом сообществе Steam под последней новостью Daymare: 1994 Sandcastle игроки уже выражают недоумение ценообразованием игры.
Состоялся выход хоррора на выживание Daymare: 1994 Sandcastle. Новость вроде бы хорошая, но её омрачает один не маловажный момент — это стоимость игры. Цена оказалась слишком высокой для игроков большинства стран, в том числе России. У нас полная стоимость игры составляет 2699 р., и временная скидка в 10% не сильно скрашивает ситуацию, снижая цену до 2429 р.
Самая низкая цена в Китае — 13$, а с невероятным отрывом от всех стран на самый верх снизу взобралась Коста-Рика со своими 68$.
В игровом сообществе Steam под последней новостью Daymare: 1994 Sandcastle игроки уже выражают недоумение ценообразованием игры.
Оригинальная игра 2019 г. Daymare: 1998 на данный момент стоит немногим дороже цены с года релиза и до сих пор остаётся приемлемой, а именно 515 р.
Да, разработчики сменили издателя, но у того же издателя в этом году уже вышла игра и она имеет совсем другую цену.
Возможно издатель высоко оценил детище Invader Studios приквел Daymare 1998 и возлагает на Daymare: 1994 Sandcastle большие надежды, но непонятно с чего. Daymare 1998 до сих пор не снискала какой либо славы и на данный момент у игры в Steam всего две с половиной тысячи отзывов с общей оценкой “в основном положительно”. Может быть промо компания конкретно Daymare: 1994 Sandcastle заинтересовала огромное количество людей? Так и здесь не сходится, самым популярным видео с Daymare: 1994 Sandcastle является трейлер с канала IGN, у которого за два года набралось не особо внушительные 946 тысяч просмотров.
Ситуация складывается странная. Остаётся надеяться, что это очередная “ошибка” и в скором времени в стоимость Daymare: 1994 Sandcastle внесут необходимые корректировки.
P.S. Пока составлялся пост, разработчики услышали глас обречённых, вышли на контакт и уже разбираются в ценообразовании.
ДОПОЛНЕНИЕ: Цену снизили почти в два раза.
-
-
Сейчас популярно
-
-
Продвигаемые темы
-
-
Последние сообщения
-
Автор: aleks2007 · Опубликовано:
Мне не трудно и я знаю где находиться Secure Boot в BIOS, но к хейту EA все равно присоединюсь, просто что б боком такая защита встала. Им дай волю так они заставят starforce + denuvo + плагин какой ни будь отслеживающий трафик заставят ради игры поставить, или вообще специальной биос EA прошить. -
Автор: piton4 · Опубликовано:
Я убил тигру, и да, там был старик, который телепортнул меня в первый телепорт зимней локи(там, где нет снега) но я побегал и ничего не нашёл. Тогда вернулся к тигре, пошёл дальше, переплыл, убил демона, ну и как бы тупик. То есть, мне надо в зимнюю локу и копать там? -
Автор: \miroslav\ · Опубликовано:
ох, я уже и не помню, но по моему если ты полностью прошел зимнюю локацию и ту где тигр, то нужно поговорить со старичком и он предложить пройти дальше по сюжетки в начальную локацию, но которая уже вся горит и там сражаются разные монстры друг с другом. или отведет тебя к спуску в какую то пещеру. я реально не помню последовательность, но помню что именно старичок меня отправлял дальше по сюжету. -
Автор: Setekh · Опубликовано:
По ходу ссылка кривая, если так https://help.ea.com/ru/articles/technical-issues/secure-boot/ то заходит. Хотя я к онлайну палкой не прикасаюсь даже, так что пофиг. -
Автор: piton4 · Опубликовано:
@\miroslav\ хотел в личку написать, но почему-то не могу. Такой вопрос: куда там нужно идти после убийства демона в поместье Бай? Это там, куда ты на лодке после тигры отплываешь. Я не понимаю, что там дальше делать ( -
Автор: piton4 · Опубликовано:
Да, такая же фигня. Понапридумывают блин... -
Автор: DeeMan · Опубликовано:
Хотел глянуть на эту инструкцию, так у меня сайт не открывается. -
Автор: 0wn3df1x · Опубликовано:
Проблема в самой архитектуре движка Inkle, которая требует не просто перевода, а лингвистического реинжиниринга нарратива на уровне низкоуровневого кода, то есть перестройки логической системы, созданной для английской языковой модели, под другую парадигму.
Первое и главное, что нужно понимать: Inkle - это не классическое диалоговое дерево “выберите вариант А, получите ветку А”. Inkle ткёт повествование из мелких фрагментов текста, переменных, функций и логических условий. Переводчик видит не цельные, готовые к переводу предложения, а их составные части - по сути, сырье, из которого движок будет склеивать финальный текст на лету. Это больше похоже на работу с ассемблером для текста, чем с привычными строковыми ресурсами. Как программист на ассемблере должен знать архитектуру процессора, так и локализатор Inkle обязан понимать внутреннюю логику его нарративной виртуальной машины. К примеру, возьмём игру The Pale Beyond и её текстовый ФАЙЛИК на 33 мб. Там есть функция ShortSentenceDeadClickTest: "ShortSentenceDeadClickTest": [ [ "ev", "str", "^x", "/str", "/ev", { "temp=": "Xstring" }, "ev", "str", "^y ", "/str", "/ev", { "temp=": "Ystring" }, [ "^Loop ", "ev", { "CNT?": ".^" }, "out", "/ev", "^. String X ", "ev", { "VAR?": "Xstring" }, "out", "/ev", "^. String Y ", "ev", { "VAR?": "Ystring" }, "out", "/ev", "\n", // ... логика выбора ... "ev", { "VAR?": "Xstring" }, "str", "^x", "/str", "+", { "temp=": "Xstring", "re": true }, "/ev", // ... "ev", { "VAR?": "Ystring" }, "str", "^y ", "/str", "+", { "temp=": "Ystring", "re": true }, "/ev", ], ], ] Это квинтэссенция подхода Inkle. Там нет диалогов в привычном понимании. Это низкоуровневый программный код. Команды ev (evaluate), str (string), VAR? (get variable), out (output), temp= (assign to temporary variable), re= (reassign) - это инструкции для виртуальной машины движка. Этот код инициализирует две переменные и в цикле (CNT? - вероятно, счетчик цикла) конкатенирует (оператор +) к ним новые символы. Для английского языка, где слова редко меняются, это нормально. Для русского - это катастрофа. Можно представить ситуацию, где вместо "x" нужно подставлять слово, которое должно меняться в зависимости от контекста (например, числа итераций цикла), а этот контекст определяется где-то в совершенно другой части кода. Это черный ящик, который невозможно перевести, не декомпилировав в уме логику его работы. Повествование управляется состоянием сотен переменных, и переводчик видит лишь разрозненные атомы текста, не зная, в какую молекулу-предложение они соберутся. Так вот, раз уже я начал о конкатенации и связанном с ней грамматическом аде. Конкатенация (простое склеивание строк) является в Inkle основным инструментом повествования. И именно в ней кроется дьявол для флективных языков, порождающий каскадные грамматические зависимости. Гипотетический пример на английском: itemCount = 1, itemAdjective = "red", itemName = "apple" -> "You have 1 red apple." itemCount = 5, itemAdjective = "red", itemName = "apples" -> "You have 5 red apples." Всё просто. Сценарист готовит две формы существительного и одно прилагательное.
Тот же пример, но на русском: "У вас есть " + itemCount + " " + itemAdjective + " " + itemName + "." itemCount = 1, itemAdjective = "красное", itemName = "яблоко". Получаем: «У вас есть 1 красное яблоко». itemCount = 2, itemAdjective = "красных", itemName = "яблока". Получаем: «У вас есть 2 красных яблока». itemCount = 5, itemAdjective = "красных", itemName = "яблок". Получаем: «У вас есть 5 красных яблок**_**». Прилагательное “красный” и существительное “яблоко” меняют свои окончания в зависимости от числа itemCount. Причем правила для 1, 2-4 и 5+ разные. Движок этого не знает. Он просто подставит переменные. Локализатору нужно переписать всю эту строку в отдельную функцию с громоздкой логикой. А теперь представим, что таких переменных в игре тысячи, и они могут быть не только предметами, но и статусами, именами, локациями. Вот реальный пример из функции GetWeeklyTitleCardTextSubtitle: "GetWeeklyTitleCardTextSubtitle": [ // ... "ev", "str", "ev", { "VAR?": "TERRITORY_0_WEEKSHERE" }, "out", "/ev", "^ Week", "ev", { "VAR?": "TERRITORY_0_WEEKSHERE" }, 1, ">", "/ev", [ { "->": ".^.b", "c": true }, { "b": [ "^s", ... ] } ], "nop", "^ on the Temperance.", "/str", "/ev", "~ret", // ... ], Этот код генерирует фразу типа “1 Week on the Temperance”. Логика примитивна: если переменная TERRITORY_0_WEEKSHERE больше единицы, то с помощью условного перехода { "->": ".^.b", "c": true } (по сути, goto) добавляется строка ^s. Команда ~ret означает, что эта собранная строка возвращается как результат функции. Куда? Возможно, она будет подставлена в другую строку, создавая новый виток грамматического ада. Переводчик видит три изолированных куска: [число], Week, on the Temperance.
На русском это превращается в неразрешимую задачу: 1 неделя, 2 недели, 5 недель. Просто добавить окончание невозможно. Нужно полностью переписывать эту функцию на уровне кода. И так - везде. Каждая такая строка - это мина замедленного действия. Также Inkle обожает переиспользовать фразы. Одна и та же часть предложения может быть использована в десятках разных мест с разными подставляемыми существительными, прилагательными и глаголами. Пример с родом: "The " + objectName + " is broken." objectName = "Engine" (двигатель, мужской род) → Двигатель сломан. objectName = "Radio" (радио, средний род) → Радио сломано. objectName = "Door" (дверь, женский род) → Дверь сломана. Прилагательное “broken” в русском языке должно согласовываться с родом существительного. Переводчик видит строку " is broken" в отрыве от objectName. Он не знает, к чему она будет применяться. Единственный выход - создавать для каждого объекта метаданные (например, его род), а затем вместо простой строки " is broken" писать целую функцию, которая будет запрашивать род объекта и возвращать правильную форму прилагательного: “сломан”, “сломана” или “сломано”. Это уже не перевод, а программирование. Вот, например, функция listSurnamesWithCommas. "listSurnamesWithCommas": [ { "temp=": "if_empty" }, { "temp=": "list" }, "ev", { "VAR?": "list" }, "LIST_COUNT", "/ev", [ "du", "ev", 2, "==", "/ev", { "->": ".^.b", "c": true }, { "b": [ "pop", "\n", "ev", { "VAR?": "list" }, "LIST_MIN", { "f()": "CrewNameToSurname" }, "out", "/ev", "^ and ", "ev", { "VAR?": "list" }, { "VAR?": "list" }, "LIST_MIN", "-", { "f()": ".^.^.^" }, "out", "/ev", // ... ]} ], // ... ], Этот код берет список фамилий и красиво форматирует его в строку: "Smith, Jones and Williams". Он просто вставляет запятые и слово "and". А теперь представим, что нам нужно сказать не “Вот Смит и Джонс” (Именительный падеж), а “Я вижу Смита и Джонса” (Винительный падеж) или “Я говорю со Смитом и Джонсом” (Творительный падеж). Переводчик не может просто перевести "and" как "и". Ему нужно знать падеж, в котором будут стоять все эти фамилии, и создать отдельную функцию для каждого падежа.
Помимо этого, английский язык имеет строгий порядок слов (Subject-Verb-Object). Inkle-скрипты часто полагаются на это. В русском языке порядок слов гибкий и используется для расстановки смысловых акцентов. Попытка собрать русскую фразу из кусков в английском порядке приводит к уродливым, машинным конструкциям. Переводчик оказывается в ловушке: он не может изменить порядок сборки фразы, потому что он зашит в логику движка. Ему приходится либо жертвовать качеством языка, либо полностью переписывать логические блоки. Короче говоря, ад Inkle для локализации заключается в том, что: Движок собирает предложения из грамматических кубиков лего. Эти кубики в английском языке взаимозаменяемы, но в русском они намертво связаны правилами согласования. Каждый такой кубик - это потенциальная точка отказа для всей фразы. Переводчик видит отдельный кубик (слово или фразу), не зная, с какими другими кубиками он будет склеен. Это как переводить слово, не показывая предложения. Контекст определяется не соседним текстом, а состоянием десятков игровых переменных. Русский язык требует согласования слов по роду, числу и падежу. Inkle не предоставляет для этого встроенных инструментов. Вся эта сложнейшая грамматическая логика должна быть написана с нуля переводчиком, который, по сути, становится программистом. Каждый простой + (конкатенация) в оригинальном коде превращается в вызов сложной функции в локализованной версии. Логика сборки фраз диктует порядок слов, который естественен для английского, но часто звучит чужеродно и коряво на русском. Вот такие пироги. Вот такая красота:
-
Автор: SerGEAnt · Опубликовано:
Жалобы возникают к самому требованию заходить в BIOS и что-то там настраивать: судя по отзывам, многих современных игроков это приводит чуть ли не паническим атакам. Шутер Battlefield 2042, вышедший еще в 2021 году, подвергся потешному ревью-бомбингу со стороны пользователей Steam. Все из-за того, что Electronic Arts приняла решение запретить запуск игры на компьютерах, в BIOS которых не активирован режим безопасной загрузки (Secure Boot). Он отвечает за шифрование приложений на уровне системы и таким образом помогает работе античита. Эта опция является обязательной для установки актуальной Windows 11. EA попыталась подготовиться к нововведению и даже смастерила инструкцию по включению Secure Boot, но игроки все равно решили проявить ярость. Жалобы возникают к самому требованию заходить в BIOS и что-то там настраивать: судя по отзывам, многих современных игроков это приводит чуть ли не паническим атакам. Отметим, что у Battlefield 6 будут аналогичные требования. Если EA не придумает, как решить проблему, в день релиза будет жарко. -
-
-
Изменения статусов
-
Привет! ты разбираешься в компьютерном железе, сможешь помочь с советом по апгрейду старого компа?· 1 ответ
-
-
-
Здраствуйте! Извините, а можно попросить ссылку на место где можно взять перевод (патч или образ игры с переводом) El Shaddai: Ascension of the Metatron для ps3, пожалуйста? А то в теме к этой игре у меня не получилось найти работающие ссылки… Первая ведет в группу в которой удалены большинство постов, а пост с этой игрой ведет на сайт https://psnext.ru который сейчас не имеет отношения к видеоиграм.· 0 ответов
-
-
-
Лучшие авторы
-
1
-
2
-
3
-
4
-
5
-
