{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Технический",
    "_rss_description": "Свежие новости и обновления о Pax Dei, Valheim и Rust, а также увлекательные рассказы о моих приключениях и исследованиях в игровых мирах",
    "_rss_language": "ru",
    "_itunes_email": "luridan@luridan.com",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/luridan.com\/pictures\/userpic\/userpic-square@2x.jpg?1671024535",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/luridan.com\/tags\/tech\/",
    "feed_url": "https:\/\/luridan.com\/tags\/tech\/json\/",
    "icon": "https:\/\/luridan.com\/pictures\/userpic\/userpic@2x.jpg?1671024535",
    "authors": [
        {
            "name": "Луридан",
            "url": "https:\/\/luridan.com\/",
            "avatar": "https:\/\/luridan.com\/pictures\/userpic\/userpic@2x.jpg?1671024535"
        }
    ],
    "items": [
        {
            "id": "1384",
            "url": "https:\/\/luridan.com\/all\/major-change-resource-system\/",
            "title": "Pax Dei наконец признал простую вещь: ресурсы — это не только баланс, это память мира",
            "content_html": "<p>Mainframe переработала систему размещения ресурсов в Pax Dei. Теперь точки добычи не будут хаотично мигрировать после каждого патча — новый алгоритм сохраняет старые позиции, если баланс ресурса не изменился. В текущем обновлении удалось удержать на месте около 60 % точек. Разработчики также обещают публиковать точные цифры всех изменений в патчноутах — для студии, которую не раз критиковали за молчание, это заметный сдвиг.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/major-change-resource-system.jpg\" width=\"1920\" height=\"1080\" alt=\"\" \/>\n<\/div>\n<p>Знание территории в MMO — это валюта. Где растёт амберграсп, в каком овраге искать канонит, к какому карьеру проложить маршрут — всё это формирует у игрока ощущение, что мир реален и предсказуем. В Pax Dei эта валюта до сих пор обесценивалась с каждым обновлением: знакомые точки исчезали, маршруты ломались, и приходилось разведывать местность заново. Не потому что так задумано, а потому что так работал алгоритм.<\/p>\n<p>Mainframe наконец объяснила, почему так происходило, — и рассказала, как это меняется.<\/p>\n<h2>Как устроена генерация мира<\/h2>\n<p>Мир Pax Dei создаётся с помощью внутренних инструментов студии, интегрированных с Unreal Engine. Вручную делается многое: карта биомов, расположение PvE-локаций, формы горных хребтов. Все PvE-площадки — ручная работа. Но покрыть весь мир вручную нереально, поэтому детали — эрозию гор, расстановку отдельных деревьев в лесах — генерирует Houdini. Идея в том, чтобы компьютер брал на себя рутину, где ручной труд не даёт принципиального выигрыша в качестве. Для тех, кому интересны подробности, есть <a href=\"\/all\/pax-dei-world-generation\/\">отдельное видео<\/a> о том, как работает этот конвейер.<\/p>\n<p>Один из продуктов конвейера — так называемые «сокеты ресурсов». Это массив из миллионов точек по всему миру, и каждая точка описывает окружение вокруг себя: расстояние до воды и ближайшей дороги, биом, тип территории, находится ли точка в карьере, и так далее.<\/p>\n<p>Дальше в дело вступают правила. Для каждого ресурса прописаны условия: в каких биомах он появляется, при каких характеристиках точки, с какой плотностью. Алгоритм прогоняет правила по сокетам — и на выходе получается карта спавнов, которая уходит на серверы.<\/p>\n<h2>Почему ресурсы мигрировали<\/h2>\n<p>Проблема была в самом принципе размещения. Ресурсы назначались на точки последовательно — один за другим. И когда разработчики меняли количество какого-то одного ресурса, это сдвигало доступные слоты для всех, кто шёл в очереди следом. Даже мелкая балансная правка могла перетасовать полкарты.<\/p>\n<p>Механизмы для сохранения старых позиций существовали, но работали ненадёжно. В результате после каждого обновления игроки обнаруживали, что их привычные маршруты сломаны. А разработчики при этом далеко не всегда внятно сообщали, что именно изменилось в балансе ресурсов. Двойная проблема: мир менялся хаотично, и об этом ещё и молчали.<\/p>\n<h2>Что меняет новый алгоритм<\/h2>\n<p>Новая система переворачивает логику. Вместо того чтобы сразу раскидывать ресурсы по точкам, алгоритм сначала рассчитывает, сколько каждого ресурса нужно в каждом биоме. Потом проверяет точки из предыдущего обновления — и по возможности оставляет их на месте, если они по-прежнему удовлетворяют правилам распределения.<\/p>\n<p>Ключевое следствие: если количество ресурса не уменьшилось, система может сохранить все его старые точки в этой зоне — знакомые места останутся на месте. По словам разработчиков, обеспечить это и одновременно сохранить правильную плотность распределения было технически непросто, но результат их устраивает.<\/p>\n<p>В текущем обновлении удалось сохранить примерно 60 % точек. Цифра не стопроцентная, потому что часть данных, необходимых новой системе, просто не генерировалась в прежних версиях — восстановили что могли. В будущих патчах доля сохраняемых точек должна расти, с поправкой на масштаб балансных изменений.<\/p>\n<h2>Прозрачность: впервые по-настоящему<\/h2>\n<p>Второе важное изменение — не алгоритмическое, а коммуникационное. Новая система позволяет разработчикам точно сказать, сколько точек переместилось и как изменился баланс каждого конкретного ресурса. Эту информацию обещают включать в полные патчноуты. Если ресурс не упомянут — значит, количество его точек не изменилось.<\/p>\n<p>Для Mainframe, которую игроки не раз критиковали за туманные формулировки и объяснения постфактум, это заметный шаг. По сути, студия учится разговаривать с игроками как со взрослыми: не «мы подкрутили баланс, разбирайтесь сами», а «вот конкретные цифры, вот что сдвинулось, вот что осталось». Осторожный оптимизм здесь уместен, но фанфары — пока нет. Одно обещание прозрачности ещё не тенденция.<\/p>\n<h2>Замечание для тестовой ветки<\/h2>\n<p>Отдельно для игроков на PTS: свежее обновление тестовой ветки использует заново сгенерированные данные, которые возвращают многие точки к позициям из основной версии игры и исправляют несколько регрессий в количестве ресурсов. Поэтому разница с предыдущей сборкой PTS будет значительной. Указанные в <a href=\"https:\/\/discord.com\/channels\/1071081786962088018\/1486730770847629442\/1486730785238155425\">патчноутах<\/a> изменения ресурсов — это разница между текущей основной версией и новой сборкой PTS, а не между двумя версиями тестовой ветки.<\/p>\n<h2>А скептики правы?<\/h2>\n<p>В сообществе есть и <a href=\"https:\/\/t.me\/worlds_guide\/9466\">другой взгляд<\/a>: часть игроков считает, что стабильные точки — это путь к скуке. Если споты зафиксированы, фарм превращается в заученный маршрут. Бежишь с закрытыми глазами, кликаешь по знакомым узлам, повторяешь.<\/p>\n<p>В этом есть зерно — но важно различать два явления. Одно дело — продуманная динамика, когда мир живёт и меняется по понятным игровым правилам: конкуренция за споты, истощение жил, сезонность. Другое — хаотичная миграция из-за технического костыля, которая ломала маршруты не ради геймплея, а потому что алгоритм так устроен. Mainframe починила второе. Появится ли в Pax Dei первое — пока открытый вопрос.<\/p>\n<h2>Фундамент, но не дом<\/h2>\n<p>Стабильность ресурсных точек — это необходимый минимум для MMO, которая хочет ощущаться как место для жизни, а не как вечный прототип. Когда мир помнит сам себя от патча к патчу, игрокам проще в него вкладываться: строить маршруты, запоминать территорию, чувствовать, что их знание чего-то стоит.<\/p>\n<p>Но это именно фундамент. Дом на нём пока не построен. Сбор ресурсов в Pax Dei по-прежнему сводится к «подбежал — кликнул», и никакая стабильность точек сама по себе это не исправит. Чтобы фарм перестал быть рутиной, нужны механики, которые сделают его интересным — а не просто предсказуемым. Mainframe сделала шаг от хаоса к порядку. Следующий шаг — от порядка к глубине.<\/p>\n<p>См. также:<\/p>\n<ul>\n<li><a href=\"https:\/\/t.me\/playpaxdei\">Телеграм-канал Pax Dei<\/a><\/li>\n<\/ul>\n",
            "date_published": "2026-03-27T14:00:52+07:00",
            "date_modified": "2026-03-27T14:00:44+07:00",
            "tags": [
                "Pax Dei",
                "Игры",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/major-change-resource-system.jpg",
            "_date_published_rfc2822": "Fri, 27 Mar 2026 14:00:52 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "1384",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/major-change-resource-system.jpg",
                    "https:\/\/luridan.com\/pictures\/paxdei-title.jpg"
                ]
            }
        },
        {
            "id": "1340",
            "url": "https:\/\/luridan.com\/all\/pax-dei-world-generation\/",
            "title": "Как Pax Dei собирает свой мир из кусочков",
            "content_html": "<p>В докладе на Everything Procedural Conference ведущий теххудожник Pax Dei Ийту Мартола показывает, как маленькая команда из пяти человек собирает огромный MMO-мир не вручную, а через умный процедурный конвейер на Houdini и Unreal 5.4.<\/p>\n<p>Мир вдохновлён югом Франции и разбит на регионы, провинции по 10×10 км и ячейки по 2×2 км — каждая такая «долина» в терминах движка это отдельный уровень Unreal, который генерируется заново из набора карт и таблиц, когда разработчики нажимают кнопку в своём оркестраторе сборки Bro.<\/p>\n<p>С технической точки зрения долины Pax Dei начинаются с грубого скульпта рельефа (где горы, где низины и большие озёра), затем поверх него накладываются данные из QGIS-карты: расположение поселений, дорог, озёр, биомов и серверных зон. Высотное поле дорабатывается нейросетями и эрозией, а средний масштаб (камни, буераки, кочки) решается через систему biome tiles — библиотеку шестиугольных плиток с вручную расставленными объектами, которые адаптируются под местный рельеф. Для линий — дорог, берегов, стен — используется похожая система «линейных тайлов»: заранее собранные отрезки дороги\/берега деформируются вдоль настоящих контуров мира.<\/p>\n<p>Отдельный модуль отвечает за малые реки и ручьи (Streams): генератор берёт случайные точки на высоте, «пускает» из них воду по направлению естественного стока и сохраняет только те потоки, которые достаточно длинные и впадают в уже существующие водоёмы. Сейчас эта система полностью отключена — разработчики честно признаются, что она создаёт слишком много проблем, но видно, что в долгосрочной перспективе они хотят вернуть живую сеть ручьёв в мир.<\/p>\n<p>Интересных фактов в докладе много: все параметры мира живут в Google Sheets, мир можно пересобрать хоть целиком за ночь, а крупные точки интереса — города, руины, лагеря — это отдельные рукотворные уровни, которые «врезаются» в рельеф по отпечатку-маске. Переходы между провинциями реализованы как ворота в горах с загрузочным экраном, а внутри одной провинции игрок на самом деле незаметно прыгает между несколькими Unreal-серверами, чтобы выдерживать MMO-нагрузку.<\/p>\n<p>В конце Мартола честно рассказывает и о проблемах: world partition до недавних версий Unreal постоянно портил жизнь, генератор не видит содержимое ассетов уровней, а любая мелкая правка в начале пайплайна по эффекту бабочки может заметно перекроить финальный ландшафт. На этом фоне становится понятнее, почему даже «простой» баг вроде деревьев, прорастающих через постройки, на практике упирается не в один флаг, а во всю сложную цепочку модулей, масок, скаттера и повторной генерации мира — чинить это аккуратно в уже живой игре действительно непросто.<\/p>\n<p>Если хочется просто понять, как устроены долины Pax Dei под капотом, этого пересказа уже достаточно. А если интересно увидеть, как именно они из карты в QGIS, таблиц и пары нейросетей собирают тот самый знакомый ландшафт, то полный доклад даёт очень приятный закулисный тур по миру игры.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/Vlyt8lDx-Zk?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<p>См. также:<\/p>\n<ul>\n<li><a href=\"https:\/\/t.me\/playpaxdei\">Телеграм-канал Pax Dei<\/a><\/li>\n<li><a href=\"\/all\/tech-dei\/\">Технические аспекты игровых миров Pax Dei<\/a><\/li>\n<li><a href=\"\/all\/world-of-pax-dei\/\">Мир Pax Dei<\/a><\/li>\n<\/ul>\n",
            "date_published": "2025-11-13T14:11:40+07:00",
            "date_modified": "2025-11-13T14:11:35+07:00",
            "tags": [
                "Pax Dei",
                "Игры",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/remote\/youtube-Vlyt8lDx-Zk-cover.jpg",
            "_date_published_rfc2822": "Thu, 13 Nov 2025 14:11:40 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "1340",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/remote\/youtube-Vlyt8lDx-Zk-cover.jpg",
                    "https:\/\/luridan.com\/pictures\/paxdei-title.jpg"
                ]
            }
        },
        {
            "id": "1176",
            "url": "https:\/\/luridan.com\/all\/our-building-system\/",
            "title": "Как мы масштабируем строительство: миллионы элементов в Pax Dei",
            "content_html": "<p class=\"lead\">Разработчики Pax Dei делятся техническими деталями и сложностями, с которыми они столкнулись при создании продвинутой системы строительства в игре, раскрывая, как они обеспечивают масштабируемость, репликацию данных и реалистичную визуализацию миллионов строительных элементов в многопользовательской среде.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/our-building-system-1.jpg\" width=\"1920\" height=\"1080\" alt=\"\" \/>\n<\/div>\n<p>Разработчики Pax Dei постоянно поражаются прекрасным сооружениям, которые игроки построили с момента выпуска первой альфа-версии. Система строительства стала одной из самых увлекательных функций в игре на сегодняшний день. Поэтому они подумали, что будет интересно поделиться некоторыми инсайтами о технологии, лежащей в основе этой системы, которая, возможно, является одной из самых сложных в истории видеоигр.<\/p>\n<p>В настоящее время наиболее активные зоны домашних долин содержат примерно 400 000 строительных элементов. С общим количеством 24 домашних долин на мир, каждый мир включает в себя несколько миллионов элементов. Обычно игроки добавляют около 10 000 новых элементов в неделю в одной домашней долине.<\/p>\n<h2>Система репликации<\/h2>\n<p>В сетевых многопользовательских играх система репликации обеспечивает, чтобы все игроки имели единое и актуальное состояние игры. По сути, она принимает ввод данных от одного игрока и распределяет его другим игрокам.<\/p>\n<p>В настоящее время данные строительства для одной домашней долины составляют около 30 МБ. Это может показаться незначительным, но при 100 игроках общий объём данных, который должен обрабатывать сервер, клиенты и система репликации, достигает 3 ГБ.<\/p>\n<p>Этот огромный объём требует особого подхода на каждом этапе игрового конвейера. Поскольку система репликации Unreal Engine используется для геймплея, её нельзя применять для зданий. Поэтому основой репликации строительства является пользовательский сервер бэкенда под названием «Repli», который передаёт данные о строительстве из мировой базы данных клиентам и серверам.<\/p>\n<p>Когда игрок входит в систему, и клиент, и сервер подключаются к Repli, который сначала отправляет полное текущее состояние зоны. Как уже упоминалось, первоначальные данные составляют около 30 МБ в самых больших зонах. После этой начальной репликации клиент и сервер слушают новые события строительства от Repli. Они используют gRPC-стриминг в качестве канала связи для этих событий. Не вдаваясь в детали gRPC, достаточно сказать, что он обеспечивает эффективную коммуникацию и понимание между сервером, Repli и клиентами.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/our-building-system-2.jpg\" width=\"1920\" height=\"1080\" alt=\"\" \/>\n<\/div>\n<h2>Добавление строительного элемента: что происходит за кулисами<\/h2>\n<p>Добавление строительного элемента включает несколько этапов за кулисами, когда игрок использует свою киянку:<\/p>\n<ol start=\"1\">\n<li>Клиент отправляет запрос на строительство серверу Unreal.<\/li>\n<li>Сервер выполняет проверку прав, чтобы убедиться, что запрос на строительство допустим.<\/li>\n<li>Если одобрено, сервер пересылает запрос на строительство на бэкенд.<\/li>\n<li>Бэкенд проводит собственную проверку для одобрения или отклонения запроса на строительство.<\/li>\n<li>После одобрения строительный элемент добавляется в основную мировую базу данных.<\/li>\n<li>Событие строительства отправляется из базы данных на пользовательский сервер бэкенда Repli.<\/li>\n<li>Repli распределяет событие строительства как серверу, так и клиенту.<\/li>\n<li>Сервер и все клиенты в зоне (в данном случае домашняя долина) создают строительный элемент.<\/li>\n<li>Сервер выполняет проверку целостности, чтобы убедиться, что структура остаётся стабильной.<\/li>\n<li>Клиент также рассчитывает целостность для отображения в пользовательском интерфейсе.<\/li>\n<\/ol>\n<h2>Сделать здание видимым для всех<\/h2>\n<p>Сделать здания видимыми для всех игроков представляет дополнительные сложности помимо массовой репликации данных. После того как клиент получил все 400 000 элементов домашней долины (упомянутый ранее пакет в 30 МБ), эти элементы нужно отобразить на компьютере игрока — что является значительной задачей.<\/p>\n<p>Отрисовка 400 000 элементов последовательно непрактична. Поэтому необходимы специальные решения. Двумя ключевыми элементами являются инстанцированные статические меши (ISM) и менеджеры областей.<\/p>\n<p>ISM позволяют отрисовывать множество, даже тысячи, элементов за один вызов отрисовки, вместо того чтобы рендерить их по отдельности.<\/p>\n<p>Менеджеры областей — представленные в виде параллелепипедов — контролируют все объекты и строительные элементы в своих регионах. Они отвечают за создание и уничтожение строительных элементов и объектов, расчёты целостности и управляют ISM.<\/p>\n<p>Менеджеры областей анализируют все стандартные строительные элементы в своих зонах (исключая ремесленников и контейнеры), сортируя их по пространству. Затем они вставляют их в пользовательские инстанцированные статические меши, что позволяет эффективно их рендерить.<\/p>\n<p>Однако на этом задача не заканчивается. Помимо зданий, есть контейнеры, ремесленники и декоративные элементы для отображения, многие из которых имеют собственные игровые функции. Эти объекты являются стандартными актёрами Unreal, но в отличие от зданий, видимых издалека, они появляются только вокруг персонажа в пределах дистанции стриминга.<\/p>\n<p>Менеджеры областей также контролируют видимость этих объектов в зависимости от позиции персонажа и дистанции стриминга клиента. Они активируют или деактивируют видимость объектов соответственно.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/ZQG9MZJavwo?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">На видео красным цветом показаны менеджеры областей, которые деактивируют видимость объектов, а голубым — активные менеджеры. Фиолетовым отмечены те, которые находятся в процессе активации, а пурпурным — те, которые находятся в процессе деактивации.<\/div>\n<\/div>\n<p>Существует ещё один тип объектов, требующий особого подхода: источники света. Когда персонаж находится рядом с ними, свет обрабатывается через систему освещения Lumen Unreal — динамическую систему глобального освещения в Unreal Engine 5 — для улучшения погружения. На определённом расстоянии источники света переключаются на легковесные световые карты для повышения производительности. В некоторых долинах одновременно может быть видно более 20 000 источников света!<\/p>\n<p>Конечно, существуют и ограничения на стороне сервера. Один сервер Unreal Engine может поддерживать максимум 150—200 игроков. Если большее число игроков хочет быть в одной деревне, требуются дополнительные серверные инстансы. И здесь вновь на помощь приходят пользовательские системы. Их система репликации позволяет зданиям быть видимыми во всех серверных инстансах в реальном времени. Если игрок строит в одном серверном инстансе, все игроки в других инстансах видят изменение здания одновременно.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/our-building-system-3.jpg\" width=\"1920\" height=\"1104\" alt=\"\" \/>\n<\/div>\n<h2>Несколько завершающих слов<\/h2>\n<p>Создание всех этих строительных элементов вокруг игрока без заметных задержек — сложная задача, выполняемая в течение нескольких секунд или даже минут, распределённая по множеству кадров. Как упоминалось в предыдущем описании процесса, расчёт целостности чрезвычайно сложен. Сервера также стримят контент мира, поэтому расчёты целостности требуют тщательной настройки, чтобы все поддерживающие ландшафты были загружены заранее. Установка физических состояний для элементов должна выполняться без задержек, а последующие физические перекрытия и расчёты целостности выполняются итеративно.<\/p>\n<p>Это объясняет, почему при входе в игру игроки часто сначала видят ландшафт, затем здания и, наконец, объекты.<\/p>\n<p>Игроки строят с более высокой скоростью, чем изначально предполагалось. Вся система прошла множество этапов оптимизации, и планируются дальнейшие улучшения. Текущая система должна функционировать хорошо до примерно 500 000 элементов. После этого появятся новые задачи, которые необходимо решить. Хорошие новости: уже существуют планы по масштабированию системы до 1 000 000 элементов на зону — но это тема для другого раза.<\/p>\n",
            "date_published": "2024-09-28T11:17:19+07:00",
            "date_modified": "2024-09-28T11:17:14+07:00",
            "tags": [
                "Pax Dei",
                "Игры",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/our-building-system-1.jpg",
            "_date_published_rfc2822": "Sat, 28 Sep 2024 11:17:19 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "1176",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/our-building-system-1.jpg",
                    "https:\/\/luridan.com\/pictures\/our-building-system-2.jpg",
                    "https:\/\/luridan.com\/pictures\/remote\/youtube-ZQG9MZJavwo-cover.jpg",
                    "https:\/\/luridan.com\/pictures\/our-building-system-3.jpg",
                    "https:\/\/luridan.com\/pictures\/paxdei-title.jpg"
                ]
            }
        },
        {
            "id": "1134",
            "url": "https:\/\/luridan.com\/all\/the-dns-debacle\/",
            "title": "Истории из командного центра Pax Dei: Путаница с DNS",
            "content_html": "<p>Команда Pax Dei поделилась закулисными подробностями о том, как они справились с проблемами входа в игру из-за ошибки в DNS. Узнайте, как они вернули игроков в игру и победили технические трудности.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/the-dns-debacle.jpg\" width=\"1920\" height=\"804\" alt=\"\" \/>\n<\/div>\n<p>После нескольких дней без крупных проблем большинство команды почувствовали облегчение и начали наслаждаться началом новой недели. Однако технические проблемы тоже знают о понедельниках, и небольшая ошибка может создать огромные проблемы. Это наша третья история из командного центра, и мы называем её «Путаница с DNS» — да, название немного спойлерит, но, как сказали бы некоторые, «это всегда DNS».<\/p>\n<p>В 19:45 по московскому времени некоторые игроки начали сталкиваться с проблемами при входе в игру. Их внезапно выбросило из системы, и они не могли снова войти. Поскольку затронутые игроки были разбросаны по различным регионам, шардам и зонам, наши системы мониторинга зафиксировали лишь незначительное снижение активности пользователей и не подняли тревогу. Однако, следя за активным сообществом в нашем дискорде, один из членов команды Mainframe заметил тревожную тенденцию и быстро решил поднять тревогу и активировать командный центр.<\/p>\n<p>К 20:00 по московскому времени мы начали диагностику. Проблема была связана с логинами, и она затрагивала значительную (и растущую) часть нашей игровой базы. Хотя у нас всё ещё было много активных игроков, кривая активности застыла или начала падать — именно в тот момент, когда она должна была расти.<\/p>\n<p>Первоначальное расследование с помощью мониторинга, метрик, графиков и оповещений указывало на несколько возможных причин. Один из наших центральных сервисов, отвечающий за логины, испытывал повышенную нагрузку на процессор, и логи нашей основной системы аутентификации были заполнены ошибками. Кроме того, мы заметили проблемы с системой обработки прав (определяющей, кто владеет игрой и какого типа лицензия у него есть) и решили следить за этим, сосредоточив внимание на наиболее вероятных виновниках.<\/p>\n<p>К 20:20 по московскому времени мы решили перезапустить систему аутентификации, которая казалась источником проблемы. Оглядываясь назад, это было ошибкой. С уже существующими проблемами при логине и постоянными попытками игроков войти в систему, перезапуск усугубил проблему. Нам пришлось временно закрыть все запросы на аутентификацию, чтобы стабилизировать систему, а поскольку игре нужно регулярно обновлять токены аутентификации, это означало, что со временем все игроки не смогли продолжить игру.<\/p>\n<p>Когда наша система аутентификации восстановилась, мы решили снова разрешить все запросы к системе. Поскольку теперь все наши игроки пытались войти одновременно, проблема с системой прав, замеченная ранее, стала явно очевидной. Система была перегружена и полностью вышла из строя, что означало, что даже те пользователи, которые смогли подключиться, оказались без права на игру. В этот момент мы поняли, что нам нужно сражаться на двух фронтах одновременно. Проблема с системой прав не могла ждать, пока будет устранена коренная причина отключений. К счастью, мы были на грани решения этой проблемы.<\/p>\n<p>Так что же вызвало эту бомбардировку, спросите вы? К сожалению, это была самопроизвольная рана. Во время диагностики мы обнаружили, что некоторые DNS-имена не разрешаются правильно. Один из инженеров на вызове выявил проблему — отсутствующая запись DNS, а именно критическая запись делегирования NS. Другой инженер сразу понял, что произошло.<\/p>\n<p>Ранее в тот день в ходе очистки было удалено ненужное инфраструктурное оборудование, и эта важная запись была ошибочно удалена. Последние команды в очистке были выполнены около 19:40, и, как оказалось, стандартное время жизни (TTL) для многих DNS-записей составляет ровно 5 минут. После нескольких ручных шагов запись была восстановлена, и нам пришлось терпеливо ждать, пока DNS-кэши по всему миру обновятся.<\/p>\n<p>Коренная причина, однако, является лишь начальным моментом, и с дежурным персоналом в нашем командном центре, оценивающим ситуацию, и несколькими старшими инженерами, готовыми к действиям, нам всё ещё нужно было решить проблему с сервисом прав. Мы решили бороться с этой проблемой с двух сторон одновременно:<\/p>\n<ul>\n<li>Эскалация и поддержка. Мы связались и передали проблему по цепочке поддержки поставщика, отвечающего за наше хранилище прав. Они подтвердили, что система перегружена, и пообещали вскоре развернуть решение. Часы начали тикать в 20:40 по московскому времени.<\/li>\n<li>Путь исправления на лету. Мы изменили наш код системы прав, включив резервный метод, благоприятствующий нашим игрокам. Если у нас возникли проблемы с разрешением прав, но игрок ранее владел определённой лицензией, мы предположим, что он всё ещё владеет ею, и позволим ему пройти. У нас уже был аналогичный код, обрабатывающий случай ограничения скорости. Добавление случая с аналогичным результатом для неотзывчивого сервиса прав было простой задачей, и исправление на лету было рассмотрено, скомпилировано, собрано и развернуто в течение 10 минут.<\/li>\n<\/ul>\n<p>Теперь у нас было три участника в одной гонке: наше исправление, позволяющее игрокам войти в игру, пока сервис страдал, сам сервис прав, стабилизирующийся с уменьшением числа запросов и внедрением исправлений, и глобальное обновление DNS-кэшей, признающих восстановленную запись.<\/p>\n<p>К 21:35 по московскому времени ситуация значительно улучшилась. Наши игроки успешно входили в игру, система прав догоняла, распространение DNS подходило к завершению, и команда смогла обернуть сложную ситуацию в свою пользу.<\/p>\n<p>Путаница с DNS была разрешёна, и мы были готовы к следующему вызову на горизонте.<\/p>\n",
            "date_published": "2024-06-26T13:22:43+07:00",
            "date_modified": "2024-09-28T10:54:02+07:00",
            "tags": [
                "Pax Dei",
                "Игры",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/the-dns-debacle.jpg",
            "_date_published_rfc2822": "Wed, 26 Jun 2024 13:22:43 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "1134",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/the-dns-debacle.jpg",
                    "https:\/\/luridan.com\/pictures\/paxdei-title.jpg"
                ]
            }
        },
        {
            "id": "1133",
            "url": "https:\/\/luridan.com\/all\/stories-from-the-war-room-d-day\/",
            "title": "Истории из командного центра Pax Dei: День релиза",
            "content_html": "<p>Команда Pax Dei поделилась закулисными подробностями первого дня выхода игры в Ранний доступ. После первоначального спокойного старта начали появляться проблемы с большим количеством NPC и задержками. Разработчики перезапускали серверы и быстро внедряли исправления. Также возникли трудности с открытием рецептов и размещением участков, но команда активно работала над их решением. К концу дня ситуация стабилизировалась, и игра вернулась к нормальному состоянию.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/stories-from-the-war-room-d-day-3.jpg\" width=\"1920\" height=\"804\" alt=\"\" \/>\n<\/div>\n<p>Для нас день релиза начался относительно спокойно. Все серверы во всех трех географических зонах были запущены, подготовлены и ожидали наплыва игроков. В полдень по UTC начали заходить первые игроки, и все системы справлялись хорошо, без критических автоматических предупреждений в наших системах мониторинга.<\/p>\n<h2>И снова кролики<\/h2>\n<p>Через час мы начали замечать, что серверы в некоторых более населенных зонах начали увеличивать количество NPC, что сказывалось на производительности. В то же время начались сообщения в Discord о сильных задержках перемещения (rubberbanding) в некоторых зонах, что было ожидаемым следствием.<\/p>\n<p>Те, кто знаком с нашей <a href=\"\/all\/stories-from-the-war-room\/\">историей со второй альфы<\/a>, могут вспомнить, что неконтролируемая популяция кроликов однажды привела нас к коллапсу. В данном случае это были не конкретно кролики, а общее увеличение количества мобов, вызванное плотной и очень активной популяцией игроков, с которой наша система контроля не справлялась.<\/p>\n<p>Временным решением стало выборочное перезапускание серверов, находившихся на грани, что означало кратковременное отключение для игроков, подключенных к этим зонам. Но, по крайней мере, сервер временно возвращался к нормальному состоянию.<\/p>\n<p>К счастью, мы работали над исправлением этой проблемы в предыдущие дни, хотя не смогли полностью воспроизвести ее в лабораторных условиях. Мы решили ускорить внедрение исправления, которое затрагивало только серверы и не требовало патча от клиента. Построение и развертывание исправления на наши тестовые серверы заняло примерно 2 часа. Затем мы решили развернуть его выборочно на несколько худших зон, чтобы убедиться в его эффективности, прежде чем внедрять его повсеместно.<\/p>\n<p>Развертывание исправлений на всех серверах всегда рискованно, поэтому мы предпочли применить его к подмножеству серверов для безопасности. Кроме того, после развертывания исправления в зоне, необходимо было подождать как минимум час, чтобы убедиться в его эффективности. До этого момента мы продолжали вручную перезапускать зоны в критическом состоянии, что было допустимым временным решением.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/stories-from-the-war-room-d-day-1.jpg\" width=\"1920\" height=\"804\" alt=\"\" \/>\n<\/div>\n<h2>Задумавшиеся рецепты<\/h2>\n<p>Но при столь масштабном вторжении редко приходится сталкиваться только с одной проблемой. Из дискорда мы начали получать сообщения о проблемах с открытием рецептов, сопровождавшихся значительными задержками.<\/p>\n<p>На наших серверах мы уже знали об одном слабом звене в этой системе: сервере Redis, который использовался для передачи уведомлений о рецептах всем игрокам (а также различных других уведомлений, таких как состояние здоровья членов группы и т. д.).<\/p>\n<p>Этот сервер нельзя масштабировать просто добавлением нового оборудования, поэтому, если он достигал предела, нужно было решать проблему на более фундаментальном уровне.<\/p>\n<p>Мы могли временно смягчить проблему перезапуском связанных сервисов, но немедленно начали работу над более постоянным исправлением, которое требует тщательного тестирования перед развертыванием, так что с этой нестабильностью придется мириться еще один день.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/stories-from-the-war-room-d-day-2.jpg\" width=\"1920\" height=\"804\" alt=\"\" \/>\n<\/div>\n<h2>Невидимые постройки<\/h2>\n<p>Это отвлекло наше внимание, пока под поверхностью не зрела более серьезная проблема, частично скрытая в тумане войны. Примерно в 16:50 UTC начали поступать сообщения из дискорда, что у людей возникли проблемы с размещением участков, и некоторые не видели построенное, хотя ресурсы тратились. Первоначально это происходило в регионе США, но затем распространилось на регион ЕС, оставив регион ЮВА нетронутым.<\/p>\n<p>Эта битва заняла у нас больше всего времени и оказалась самой сложной для устранения. Исправление не удалось найти до 02:00 UTC (День релиза + 1).<\/p>\n<p>Виновником оказался связующий звено между нашей базой данных и сервисом, отвечающим за репликацию строительных элементов для всех игроков. Этот сервис имел предварительно настроенные квоты, которые были превышены, что привело к ограничению работы сервиса.<\/p>\n<p>Обычно это не проблема, так как мы можем динамически увеличивать квоты, но в этом случае, когда квота была увеличена и база данных возобновила связь с сервисом, ей пришлось восстановить очень большой объем накопившихся транзакций. Хотя она выполняла это добросовестно, просто не успевала, что приводило к длительным задержкам между созданием строительных блоков и их репликацией для клиентов.<\/p>\n<p>В какой-то момент задержка достигла целого часа. Для игроков это выглядело так, будто они не могут построить участок, но на самом деле они не видели завершения операции более часа. Это стало очевидным только с течением времени, но нам потребовалось некоторое время, чтобы выяснить причину. В режиме расследования мы решили позволить сервису работать в его темпе, чтобы не потерять состояние игроков, что заняло несколько часов.<\/p>\n<p>После выявления причины мы применили несколько простых исправлений в конфигурации и перезапустили связанные сервисы. Состояние строительства было почти мгновенно восстановлено, и все регионы вернулись в нормальное состояние.<\/p>\n<p>В это время мы почти забыли о нашей первоначальной тревоге: производительности серверов зон из-за популяции мобов, но были рады наблюдать, что после применения исправления к выбранным зонам, они оказались под контролем и работали значительно лучше, что было отличной новостью. Поэтому параллельно со всем вышеуказанным мы начали обновление всех серверов зон по всем регионам, что привело к кратковременному отключению игроков, но обеспечило более здоровый профиль ЦП для всех миров.<\/p>\n<p>Итак, в 03:00 UTC (День релиза + 1), после почти 24-часовой смены, все в Командном центре чувствовали усталость, но были довольны. Мы все еще слышали отдаленные раскаты, и знали, что битва не окончена, но, по крайней мере, мы установили плацдарм и были готовы двигаться дальше.<\/p>\n",
            "date_published": "2024-06-20T14:54:02+07:00",
            "date_modified": "2024-09-28T10:54:10+07:00",
            "tags": [
                "Pax Dei",
                "Игры",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/stories-from-the-war-room-d-day-3.jpg",
            "_date_published_rfc2822": "Thu, 20 Jun 2024 14:54:02 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "1133",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/stories-from-the-war-room-d-day-3.jpg",
                    "https:\/\/luridan.com\/pictures\/stories-from-the-war-room-d-day-1.jpg",
                    "https:\/\/luridan.com\/pictures\/stories-from-the-war-room-d-day-2.jpg",
                    "https:\/\/luridan.com\/pictures\/paxdei-title.jpg"
                ]
            }
        },
        {
            "id": "972",
            "url": "https:\/\/luridan.com\/all\/stories-from-the-war-room\/",
            "title": "Истории из командного центра Pax Dei",
            "content_html": "<p>Разработчики Pax Dei рассказали несколько закулисных историй о технической стороне работы игры. В тексте много технических терминов, но все равно было интересно почитать о том, как табуны кроликов положили сервер.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/stories-from-the-war-room.jpg\" width=\"1339\" height=\"752\" alt=\"\" \/>\n<\/div>\n<p>Вот мы и подошли к концу первых 24 часов нашего второго альфа-тестирования. Как и следовало ожидать, было усвоено много уроков, пришлось переступить через свою гордость, но мы также получили несколько приятных сюрпризов.<\/p>\n<p>Одна из главных целей этого альфа-теста — протестировать весь наш технологический стек под давлением и в возрастающих масштабах с реальными игроками, потому что никакое автоматизированное тестирование и симуляция не могут выявить различные критические события, которые могут произойти в разных частях нашего стека, и какой эффект домино они могут оказать на весь сервис.<\/p>\n<p>С точки зрения Liveops, весь альфа-тест похож на запуск огромной ракеты в космос с надеждой, что она достигнет орбиты и, желательно, вернется на Землю более или менее целой, готовой к новому полету. Все это оснащено всей возможной телеметрией, чтобы мы могли получать информацию о происходящем в режиме реального времени и устранять проблемы, желательно до того, как они приведут к катастрофическим сбоям.<\/p>\n<p>Наш стек довольно сложен и состоит из множества серверов, работающих со множеством сервисов в разных географических регионах. Для этого теста мы задействовали около 150 виртуальных серверов, распределенных между ЕС и США. Примерно две трети из них — это серверы Unreal, работающие с определенными зонами в конкретных мирах и автоматически запускающиеся при входе игроков в эти зоны. Остальные — это внутренние серверы, выступающие в качестве конечных точек API для различных игровых сервисов. К ним относятся инвентарь, аватар, группы, здания и аутентификация. За всеми этими сервисами стоят несколько больших баз данных, в которых хранятся все данные о клиентах, их персонажах и связанных с ними постоянных состояниях.<\/p>\n<p>Все эти серверы и системы, а также выбранные образцы клиентов генерируют телеметрию, которая собирается в платформе наблюдаемости под названием Datadog, а также в нашем аналитическом стеке, что позволяет нам в режиме реального времени визуализировать состояние всех компонентов, а также автоматически генерировать оповещения при возникновении определенных критических условий.<\/p>\n<p>Во время таких мероприятий, как сейчас, мы собираем команду Liveops, которая следит за Datadog, а также мониторит каналы социальных сетей, работая посменно круглые сутки. Эта команда состоит из наших самых опытных инженеров по надежности сайта, инженеров-программистов и комьюнити-менеджеров. Состав этой команды таков, что она должна быть способна устранять критические ситуации в реальной среде, находить приемлемое решение, тестировать и развертывать это решение, а затем контролировать, что оно действительно решило проблему, и все это при максимальном обновлении сообщества и обеспечении того, чтобы все, что делается, затрагивало наименьшее количество людей. Вся эта команда собирается в так называемом Командном центре, который представляет собой канал видеоконференции, где проблемы обсуждаются и решаются коллективно. Подумайте об этом как об управлении полетами Apollo (по крайней мере, именно с этим они любят себя сравнивать).<\/p>\n<p>Вот несколько историй из Командного центра.<\/p>\n<p>В это прекрасное утро вторника мы запустили наши двигатели в 11 по Гринвичу и сразу же увидели приток игроков во всех мирах и зонах. Все системы вели себя нормально. Во время такого наплыва игроков необходимо следить за серверами аутентификации и, соответственно, за различными зонами, которые запускаются по требованию, когда игроки подключаются к различным частям миров. Несмотря на то, что этот процесс может быть довольно быстрым, он все еще остается относительно органичным, поскольку игроки подключаются к игре случайным образом.<\/p>\n<p>Когда около 12:30 по Гринвичу мы достигли популяции примерно в 5 тысяч игроков, мы начали получать первые предупреждения. Сервер Redis начал опасно приближаться к 100% нагрузке процессора. Серверы Redis используются для кэширования и быстрого сохранения изменчивого состояния серверов Unreal в нескольких мирах в одном регионе AWS. Они очень эффективны и, как правило, не являются чем-то, что легко прогибается под нагрузкой, но вам все равно нужно иметь некоторое обоснованное первоначальное предположение о том, какая мощность процессора ему потребуется. Обычно мы можем сформировать обоснованные предположения, симулируя трафик на различных конечных точках, но в случае с сервером Redis мы не стали проводить такие тесты, а ограничились стресс-тестами с использованием внутренних игроков, а также специальных тестовых ботов. Эти тесты и близко не подходили к симуляции текущей нагрузки, и стало ясно, что необходимо переключиться на более производительную ноду. Обычно это можно сделать вживую и прозрачно, но в данном случае служба не была настроена на работу с легкодоступной репликой (так называемый режим Multi-AZ).<\/p>\n<p>Это означало, что его нужно было отключить, а затем перезапустить. Здесь мы подошли к неизвестной территории, поскольку было неясно, справятся ли все системы с таким сбоем и смогут ли они прозрачно подключиться к новому экземпляру Redis без упорядоченного отключения и перезапуска. Поскольку у нас не было особого выбора, так как сервер в конечном итоге должен был выйти из строя, мы решили обновить экземпляры Redis на более производительных узлах. Очень быстро стало очевидно, что правильное переподключение не происходит, и мы начали получать ошибки и аномальное поведение от различных частей стека, которые зависели от сервера Redis.<\/p>\n<p>Параллельно с этим мы следили за потреблением памяти несколькими серверами зоны Unreal, которое превышало норму, что приводило к низкой производительности и лагам у игроков, подключенных к этим узлам. Некоторые расследования, проведенные путем реального подключения к этим подозрительным узлам, выявили виновника.<\/p>\n<p class=\"loud\">Кролики. Кролики повсюду.<\/p>\n<p>Всегда кролики, не так ли? Правило распределения ресурсов, которое использовалось для контроля популяции кроликов, вело себя плохо в некоторых биомах, что приводило к увеличению количества кроликов. Теперь, несмотря на то, что кролик кажется невинным существом, на самом деле он считается полноценным существом в нашем подсчете НИП. Когда сервер полностью заполнен игроками, НИП необходимо держать под контролем, так как они конкурируют за ресурсы процессора сервера для таких задач, как обнаружение столкновений и поиск пути. Обновить распределение ресурсов, чтобы уничтожить этих кроликов, достаточно просто, но в данном случае это потребовало бы перезагрузки затронутых зон. Поскольку у нас не было четкого представления о том, какой узел может быть затронут кроличьим нашествием, и учитывая, что мы уже боролись с еще одним нарушением из-за перезапуска Redis, а также необходимость применять одни и те же изменения к разным регионам мира, было решено перевести всю игру в режим обслуживания, чтобы мы могли перезагрузить все должным образом.<\/p>\n<p>Режим технического обслуживания, по сути, закрывает доступ для всех игроков, поэтому он сразу же отключает сервис, позволяя нам перезагрузить мир и завершить некоторые изменения, которые мы хотели применить. Мы хотим избегать этого как можно чаще, потому что это на 100 % нарушает процесс игроков. Тем не менее, с этим связана и другая проблема: выход из режима технического обслуживания.<\/p>\n<p>Проблема в том, что переход в режим техобслуживания при наличии многих тысяч уже подключенных игроков означает, что, когда вскоре после этого вы захотите снова открыть сервис, тысячи игроков подключатся к нему почти в одно и то же мгновение. Это совсем не похоже на органический рост числа подключений в течение обычного дня, а скорее напоминает цунами одновременных подключений, происходящее в течение нескольких минут. Большая часть нашего стека имеет встроенную защиту от этого с точки зрения автоматического масштабирования и балансировки нагрузки, но все же есть некоторые узкие места, которые могут быстро стать проблемными в таких сценариях. Эти узкие места могут оказать эффект домино на другие системы, ожидающие подключения, и в конечном итоге могут выйти из строя, создавая идеальный шторм. Как правило, в конце концов все исправляется, хотя впечатления игрока от игры на этом этапе могут быть не самыми лучшими. В будущем мы планируем усовершенствовать режим обслуживания, включив в него дросселирование входящих соединений, что позволит нам плавно наращивать количество подключений, но пока что нам полезно видеть, какие сервисы становятся узкими местами, и это помогает нам определить, где мы могли бы использовать различные конфигурации, чтобы лучше справляться с такими скачками.<\/p>\n<p>Примерно через 20 минут простоя мы вернулись в седло, а количество игроков постоянно росло, так как к игре начали присоединяться не только жители ЕС, но и США. Примерно в 17:30 по Гринвичу мы достигли того, что, по нашим прогнозам, должно было стать пиком количества подключенных игроков за день.<\/p>\n<p>В этот момент мы начали наблюдать некоторую турбулентность в силе, и в данном случае она оказалась связана с перегрузкой базы данных. Казалось, что она затрагивает в основном один регион, но поскольку некоторые из наших запросов к БД работают с несколькими БД в нескольких регионах, эффект ощущался повсюду. Казалось, что наши БД правильно настроены и даже при такой высокой нагрузке не должны работать на 100 % процессора, но что-то заставляло БД останавливаться.<\/p>\n<p class=\"loud\">В конце концов, мы докопались до одного неавторизованного соединения с БД, которое зависало и держало критическую таблицу заблокированной, что приводило к блокировке любых запросов, использующих эту таблицу.<\/p>\n<p>Это снова имело эффект домино, так как запросы к бэкенду, инициирующие эти запросы, в конечном итоге завершались по таймеру, что приводило либо к повторным попыткам, либо к сбоям в определенных действиях игрока. Это был хороший пример того, как один-единственный ослабленный винтик оказывает влияние на весь стек и регионы. Как только мы сняли блокировку с этой таблицы, большинство сервисов начали плавно восстанавливаться, и мы быстро вернулись к прежним уровням игроков.<\/p>\n<p>В течение оставшейся части ночи у нас было несколько оповещений, с которыми нужно было разобраться, но, к счастью, все эти проблемы мы смогли устранить в прямом эфире, не нарушив работу всего сервиса и не разбудив больше людей.<\/p>\n<p>Уроки заключаются в том, что обычно, как только вам удается найти первопричину проблемы, лечение становится относительно очевидным, и вам может быть немного стыдно за то, что вы не заметили эту конкретную проблему перед запуском. Однако правда заключается в том, что тип возникающих проблем и сочетание нескольких различных систем, демонстрирующих различное поведение в условиях реального трафика игроков, трудно предсказать в целом, и часто бывает сложно определить истинную причину из-за взаимозависимости. В то же время, охота за проблемой приносит определенный азарт и большое удовлетворение, когда решение найдено.<\/p>\n<p>Именно поэтому мы проводим такие тесты, как Альфа, и очень благодарны сообществу, которое участвует в подобных мероприятиях, помогая обнаружить эти труднодоступные проблемы и создать более надежные системы для их решения в будущем. Мы еще раз хотим выразить искреннюю благодарность всему нашему сообществу за поддержку и страсть к Pax Dei.<\/p>\n",
            "date_published": "2024-05-18T18:59:50+07:00",
            "date_modified": "2024-09-28T10:54:19+07:00",
            "tags": [
                "Pax Dei",
                "Бета",
                "Игры",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/stories-from-the-war-room.jpg",
            "_date_published_rfc2822": "Sat, 18 May 2024 18:59:50 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "972",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/stories-from-the-war-room.jpg",
                    "https:\/\/luridan.com\/pictures\/paxdei-title.jpg"
                ]
            }
        },
        {
            "id": "991",
            "url": "https:\/\/luridan.com\/all\/tech-dei\/",
            "title": "Технические аспекты игровых миров Pax Dei",
            "content_html": "<p>Разработчики Pax Dei рассказали об устройстве серверной части игрового мира и ответили на вопросы сообщества.<\/p>\n<p>Если кратко:<\/p>\n<ul>\n<li>Будет существовать несколько серверов-шардов для разных регионов (США, Европа) вместимостью 7000 игроков.<\/li>\n<li>Каждый шард будет состоять из серверов, обслуживающих отдельную зону, а каждая зона будет иметь несколько инстансов, вмещающих до 150 игроков.<\/li>\n<li>Отдельных серверов для ПВЕ и ПВП не будет.<\/li>\n<li>Подземелья не будут разделяться на инстансы, чтобы чаще происходили стычки с другими игроками.<\/li>\n<li>Плановых еженедельных технических обслуживаний не будет.<\/li>\n<li>Переносить персонажей между серверами можно будет, а вот перенос зданий и целых кланов пока еще в разработке.<\/li>\n<li>К модам разработчики относятся хорошо, вот только поддержку пока еще не сделали.<\/li>\n<\/ul>\n<hr \/>\n<p>Как вы уже знаете, мир Pax Dei состоит из нескольких регионов (Галлия, Анатолия, Готия), разделенных на несколько провинций (Ансьен, Мерри, Керис). Провинция — это очень большая географическая область с несколькими долинами, перемежающимися большими горными хребтами. В отдельных провинциях, называемых хартлендами, есть несколько долин, которые называются домашними, и именно там вы можете построить свой дом. И, конечно же, у вас будут темные подземелья и пещеры, которые в основном находятся под поверхностью этих провинций.<\/p>\n<p>Но как эти географические особенности отображаются на реальных физических серверах и как они влияют на игру?<\/p>\n<h2>Миры и шарды<\/h2>\n<p>Перед созданием персонажа в Pax Dei первым делом вам нужно будет выбрать, где вы будете играть, а именно выбрать Шард. Несмотря на то, что мир Pax Dei географически огромен, он может вместить только определенное количество игроков. Поэтому будет несколько копий мира, каждая из которых идентична, но полностью независима от других с точки зрения реального населения. Каждая такая копия называется <i>шардом.<\/i><\/p>\n<p>По нашим оценкам, в начале игры максимальное количество игроков на одном шарде будет составлять около 7000 человек. Один шард работает полностью в рамках одного физического облачного хостинг-центра. Будут запускаться шарды в различных регионах доступности по всему миру, например, в Северной Америке и Европе.<\/p>\n<p>Таким образом, на выбор шарда будут влиять следующие факторы:<\/p>\n<ul>\n<li>Задержка до вашего основного игрового компьютера.<\/li>\n<li>Наличие свободных мест, так как некоторые шарды могут быть переполнены.<\/li>\n<li>Наличие друзей, уже играющих на шарде.<\/li>\n<\/ul>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tech-dei-1.png\" width=\"452\" height=\"1292\" alt=\"\" \/>\n<\/div>\n<h2>Зонные серверы<\/h2>\n<p>С вычислительной точки зрения шард представляет собой большую совокупность различных серверов и облачных сервисов, каждый из которых выполняет определенную функцию. Наиболее многочисленными из них являются так называемые зонные серверы. Это связано с тем, что моделирование целого мира является слишком тяжелым вычислительным процессом для одного аппаратного экземпляра, поэтому он делится на более мелкие вычислительные единицы, которые мы называем зонами. Сервер одной зоны — это выделенный Unreal Server, который занимается моделированием определенной части мира, например, одной домашней долины.<\/p>\n<p>В любой момент времени вы, как игрок, автоматически подключаетесь к серверу зоны. При перемещении через границу зоны ваше соединение автоматически переходит к серверу соседней зоны. Это и называется переходом между зонами. В большинстве случаев такие переходы должны быть плавными, за исключением нескольких важных моментов:<\/p>\n<ul>\n<li>Переходы между различными провинциями или в подземелья обычно требуют некоторого времени загрузки, поскольку клиент загружает совершенно новую карту.<\/li>\n<li>В настоящее время не существует видимости других игроков или NPC через границы зон.<\/li>\n<\/ul>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tech-dei-2.png\" width=\"1130\" height=\"1292\" alt=\"\" \/>\n<\/div>\n<h2>Экземпляры зон<\/h2>\n<p>Как уже говорилось выше, сервер зоны — это выделенный Unreal Server, который занимается моделированием небольшого участка мира. В конечном итоге зонный сервер также может быть перегружен большим количеством игроков. В настоящее время этот предел составляет около 150 игроков, но ожидается, что он изменится с улучшением аппаратного обеспечения и оптимизацией. Чтобы избежать необходимости закрывать зоны при достижении максимального количества игроков, например, в часы пик, вводится понятие экземпляра зоны или попросту <i>инстанса.<\/i> Механизм такой, что при превышении максимального количества игроков в зоне весь набор игроков распределяется в пределах данной границы зоны между двумя или более отдельными инстансами. Каждый экземпляр зоны фактически является отдельным сервером зоны для одной и той же зоны, но игроки в пределах данного инстанса не могут взаимодействовать с игроками в другом.<\/p>\n<p>Это разделение распространяется только на прямое взаимодействие игроков, а вот здания, помимо всего прочего, отображаются между инстансами нормально, то есть здания видны всем. Как только уровень населения зоны снижается, инстансы объединяются. В обычном режиме создание и объединение инстансов будет происходить очень редко, но на начальном этапе — часто.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tech-dei-3.png\" width=\"944\" height=\"1292\" alt=\"\" \/>\n<\/div>\n<h2>Бэкэнд<\/h2>\n<p>Помимо серверов зон, остальная часть бэкенда обеспечивает координацию между серверами зон, транзакционную игровую логику, связь и стабильность. Бывают ситуации, когда клиенты напрямую подключаются к этому бэкенду через защищенные API, например, для аутентификации. Однако в большинстве случаев именно зональные серверы связываются с бэкендом для работы с определенными сервисами, такими как инвентарь, управление ресурсами и так далее.<\/p>\n<p>Вся эта инфраструктура развертывается, координируется и масштабируется с помощью архитектуры Kubernetes, работающей поверх облачной инфраструктуры.<\/p>\n<h2>Вопросы<\/h2>\n<p><b>Объясните, пожалуйста, чем конкретно занимается бэкенд-инженер?<\/b><\/p>\n<p>Бэкенд-инженер — это человек, который работает над любыми сервисами, находящимися на сервере, а также над взаимодействием между серверами зон и серверной стороной.<\/p>\n<p>Как правило, бэкенд-инженеры определяют и реализуют API, используемые при взаимодействии между Unreal и бэкенд-сервисами. Они также определяют структуры данных и логику хранения для всех сохраняемых данных в главной базе данных.<\/p>\n<p>Наконец, они также занимаются развертыванием и мониторингом всей базовой инфраструктуры.<\/p>\n<p><b>Как происходит взаимодействие между backend и frontend?<\/b><\/p>\n<p>В основном это взаимодействие происходит через хорошо документированные API. API определяет все операции, которые разрешены для данного сервиса. Бэкенд также проверяет и обеспечивает правильность аутентификации клиента API и наличие у него разрешения на вызов данной функции. Ответ API обычно представляет собой данные или валидацию, которые клиенты используют для отображения игрокам через настраиваемый пользовательский интерфейс.<\/p>\n<p><b>Что является самой большой проблемой при работе над такой MMO, как Pax Dei?<\/b><\/p>\n<p>Самая большая сложность заключается в том, насколько сложен технологический стек. Весь технологический стек состоит из различных компонентов, некоторые из которых являются компонентами сторонних производителей (например, Unreal Engine или PostgresDB), а другие полностью разработаны собственными силами.<\/p>\n<p>Большинство из них не предназначены для использования в MMO. Функции этих компонентов варьируются от моделирования физики, рендеринга графики, поведения искусственного интеллекта до обеспечения целостности транзакций и высокой масштабируемости серверных операций.<\/p>\n<p>Они охватывают несколько языков программирования и должны быть созданы и развернуты в идеальной гармонии, чтобы функционировать всем вместе, как задумано. Наконец, тестирование MMO без реальных игроков затруднено, поэтому так важно раннее пользовательское тестирование.<\/p>\n<p><b>Будут ли существовать шарды для разных языков или все игроки смогут играть вместе?<\/b><\/p>\n<p>Мы хотим проследить за этим вопросом. Вначале мы не будем вводить специальных языковых ограничений, но, возможно, появятся шарды с явным языковым уклоном. Мы приложим все усилия, чтобы предоставить игрокам такие данные, чтобы помочь им принять взвешенное решение о том, к какому шарду присоединиться.<\/p>\n<p>Мы также не хотим заставлять вас играть в определенном регионе. Мы имеем в виду, что если вы — европейский игрок и хотите играть с друзьями из США, то вам должно быть позволено это делать (правда, при этом придется смириться с большей задержкой).<\/p>\n<p><b>Будет ли у нас несколько шардов, предназначенных для PvE, без какого-либо взаимодействия с PvP?<\/b><\/p>\n<p>Нет, в настоящее время планируется, что все шарды будут идентичны.<\/p>\n<p><b>Сколько игроков будет на одном шарде?<\/b><\/p>\n<p>Для начала мы планируем, что на одном шарде будет около 7000 игроков (в 3-4 провинциях хартлендов). По мере того как мы будем вводить в строй новые провинции, максимальное количество игроков на одном шарде будет расти соответственно.<\/p>\n<p><b>Как вы планируете избежать очередей в связи с ожидаемым высоким спросом на старте?<\/b><\/p>\n<p>По мере необходимости мы сможем запускать дополнительные шарды, чтобы принимать все больше и больше игроков, но механизм зонной инсталляции также поможет снизить первоначальную нагрузку на шард.<\/p>\n<p><b>Каковы ваши планы по минимизации задержек для игроков?<\/b><\/p>\n<p>Шарды будут доступны в различных географических регионах, так что новые игроки смогут найти тот, который находится в географической близости от них. Кроме того, боевая система и типичные для ММО взаимодействия таковы, что они более терпимы к задержкам по сравнению с шутерами от первого лица.<\/p>\n<p><b>Будет ли проводиться еженедельное техническое обслуживание? Будет ли оно отличаться в зависимости от региона с учетом часовых поясов?<\/b><\/p>\n<p>Мы спроектировали нашу систему таким образом, что она не должна нуждаться в обслуживании, за исключением крупных обновлений клиента и сервера, но на данный момент нам все же приходится делать некоторые простои, а иногда и полное стирание миров. Выбранные временные рамки, безусловно, будут направлены на то, чтобы минимизировать неудобства для игроков.<\/p>\n<p><b>Как вы будете управлять населением миров? Планируете ли вы разрешить перенос персонажей?<\/b><\/p>\n<p>Да, безусловно. Это необходимо и для качества жизни игроков, и для управления населением.<\/p>\n<p>Но давайте разделим этот вопрос на разные случаи: перенос персонажа из одного мира в другой довольно тривиален, поэтому мы, безусловно, разрешим его (в качестве дополнительной услуги или бесплатно, если целью является разгрузка населения того или иного мира).<\/p>\n<p>Перемещение участка и здания (зданий) на нем — гораздо более сложная задача. Мы не можем просто перенести здания, поскольку в новом мире может не оказаться свободного места, и мы не можем легко переместить здания в «аналогичное место», поскольку структура зданий зависит от местности, на которой они находятся. В идеале, у нас будет система, позволяющая сохранять структуру здания в виде чертежа или, по крайней мере, помещать все его компоненты в магический мешок (не спрашивайте, пожалуйста, о том, что за этим скрывается).<\/p>\n<p>Наконец, что касается переноса кланов, то в настоящее время мы рассматриваем такую возможность, но по ряду причин (приоритеты, рабочая сила, недоработанные функции) мы не можем утверждать, что это произойдет в ближайшее время. Более подробную информацию о трансферах и их доступности мы предоставим позже.<\/p>\n<p><b>Если я хочу поиграть с друзьями, как мы можем гарантировать, что мы будем в одном мире? Могу ли я присоединиться к ним, даже если их мир переполнен?<\/b><\/p>\n<p>Когда мир становится переполненным, он будет заблокирован для обеспечения качества обслуживания. Таким образом, наша задача — найти баланс между предотвращением переполненности и обеспечением возможности для друзей играть вместе.<\/p>\n<p>Главное здесь — грамотно подойти к выбору показателей, которые мы будем использовать, и к тому, как мы будем направлять людей к определенным мирам.<\/p>\n<p>В критических ситуациях мы хотели бы предоставлять возможность бесплатного перевода персонажей из населенных миров, поскольку это один из лучших способов уменьшить переполненность. Более подробную информацию мы предоставим позднее.<\/p>\n<p><b>Какова ваша позиция в отношении сторонних программ и модов?<\/b><\/p>\n<p>Мы открыты для сторонних программ и модов (при условии, что они не дают игрокам несправедливых преимуществ), поскольку признаем, что они часто могут улучшить пользовательский опыт и предоставить ценные функциональные возможности. Однако на данный момент мы, к сожалению, не располагаем необходимыми ресурсами для их полноценной поддержки. Мы искренне надеемся, что в обозримом будущем мы сможем обеспечить поддержку, которой вы заслуживаете. Будьте уверены, мы будем держать вас в курсе событий и сообщать дополнительную информацию по мере ее поступления.<\/p>\n<p><b>Будут ли в какой-то момент сняты ограничения на шарды и серверы зон?<\/b><\/p>\n<p>Ограничения, упомянутые выше, мы вводим в Альфе и должны быть увеличены позже, ближе к релизу.<\/p>\n<p>Каждый человек всегда сможет получить доступ к любой точке на карте — если сервер зоны будет переполнен, мы создадим другой. Мы работаем над алгоритмом, который постарается сделать так, чтобы вы всегда ходили в инстанс со своим кланом или группой, так что вы всегда должны встречать тех, кого ожидаете в инстансе зоны, в которой находитесь.<\/p>\n<p>Мы будем внимательно следить за тем, насколько хорошо работает эта система и каково реальное максимальное количество игроков, которое мы можем поддерживать в каждой зоне, поскольку это зависит от многих факторов и трудно предсказуемо. Мы также ожидаем, что из-за большого размера мира большинство зон не будут нуждаться в инстансах большую часть времени.<\/p>\n<p><b>Если я играю в группе, какова вероятность того, что нас разделят на серверы разных зон?<\/b><\/p>\n<p>Мы сделаем все возможное, чтобы убедиться, что если вы играете в группе, вы будете находиться в одном инстансе.<\/p>\n<p>Мы уже говорили о том, что провинции хартлендов делятся на домашние долины и дикие земли. Домашняя долина — это место, где вы можете получить участок и построить свой дом. Дикие земли — это территории между домашними долинами. Каждая домашняя долина — это зона.<\/p>\n<p>Мы постараемся сделать так, чтобы все члены одной гильдии гарантированно находились в одном и том же экземпляре зоны. Таким образом, когда вы строите деревню и играете в PvE-зоне хартленда, вы никогда не пересечете границы зон и будете находиться там вместе со всеми, с кем хотите играть.<\/p>\n<p><b>Будут ли подземелья инстансовыми и ограниченными?<\/b><\/p>\n<p>Во-первых, важно знать, что мы не будем создавать экземпляр подземелья для каждой группы, входящей в него.<\/p>\n<p>Поэтому, когда вы отправитесь в подземелье со своей группой, вы можете столкнуться с другими группами людей. Таким образом, впечатления от пребывания в подземелье должны быть довольно непредсказуемыми. Если вы видите новый зал или коридор, в котором еще не были, и в нем нет врагов, это может означать, что кто-то недавно убил их, и вам следует действовать осторожно, иначе вы рискуете оказаться посреди заспавнившихся новых врагов. И, как вы уже догадались, подземелье — это зона, а значит, на нее распространяется ограничение в 150 игроков на зону... что может быть очень много.<\/p>\n<p>В качестве примечания: хотя мы не можем комментировать частоту респаунов, мы можем сказать, что команда, работающая над ними, хочет сделать некоторые зоны жестоко трудными. Исследовать их в одиночку будет очень опасно, и даже в группе нужно быть очень, очень осторожным.<\/p>\n<p><b>А как насчет зданий, находящихся в стадии активного строительства?<\/b><\/p>\n<p>Они мгновенно появляются во всех инстансах. На практике увидеть, как дом строится сам, можно будет сравнительно редко, но это может случиться.<\/p>\n<p><b>А как насчет PvP-зон? Если есть ограничения, то что может помешать крупным кланам легко использовать их для контроля над зоной?<\/b><\/p>\n<p>Для предотвращения этого в PvP будут разработаны специальные правила ведения боя, как только будет реализован игровой процесс, включающий масштабные бои.<\/p>\n<p>Мы также надеемся, что у нас будет отдельный инстанс, предназначенный именно для PvP, и мы сможем запускать больше игроков в эти зоны. В игре должно быть несколько типов сценариев PvP, которые будут вести себя несколько по-разному — однако сейчас это еще в процессе разработки, и более подробную информацию мы предоставим позднее.<\/p>\n<p><b>Сможем ли мы со временем видеть и взаимодействовать с людьми, находящимися за границами зон?<\/b><\/p>\n<p>В настоящее время другие игроки или NPC не видны через границы зон — мы понимаем, что это звучит как большая проблема, но на самом деле вы практически никогда не столкнетесь с подобной ситуацией.<\/p>\n<p>Дизайн карты мира учитывает наличие зон, поэтому пересекать их границы вы будете крайне редко. Следует отметить, что 90 % границ зон проходят по таким элементам, как непроходимые горные вершины. Кроме того, зоны в целом достаточно велики: каждая провинция имеет площадь около 75-80 кв. км, и на нее приходится 7 зон. Таким образом, в зависимости от того, чем вы занимаетесь, вы можете играть часами и пересечь границу зоны максимум два раза в процессе исследования.<\/p>\n",
            "date_published": "2023-09-22T21:08:19+07:00",
            "date_modified": "2023-09-22T21:07:18+07:00",
            "tags": [
                "Pax Dei",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/tech-dei-1.png",
            "_date_published_rfc2822": "Fri, 22 Sep 2023 21:08:19 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "991",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/tech-dei-1.png",
                    "https:\/\/luridan.com\/pictures\/tech-dei-2.png",
                    "https:\/\/luridan.com\/pictures\/tech-dei-3.png",
                    "https:\/\/luridan.com\/pictures\/paxdei-title.jpg"
                ]
            }
        },
        {
            "id": "500",
            "url": "https:\/\/luridan.com\/all\/tera-631\/",
            "title": "Клиент игры для стресс-теста в Корее",
            "content_html": "<p>Скорее всего, что именно он и будет на ОБТ в Корее.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/down.jpg\" width=\"569\" height=\"133\" alt=\"\" \/>\n<\/div>\n<p>Напомню, что тестирование нагрузки на сервер будет проходить с 26 по 29 ноября, после которого издатели огласят дату ОБТ и, возможно, выхода TERA в Корее.<\/p>\n<p>Общий вес файлов составляет 22 Гб.<\/p>\n<p><b>Системные требования<\/b><br \/>\nПроцессор: Intel Core 2 Duo или лучше RAM: 2 Гб или более Видеокарта: GeForce 8800 и лучше (минимум GeForce 7600) DirectX: DirectX 9.0c или выше версия Жесткий диск: 40 Гб<\/p>\n",
            "date_published": "2010-11-23T18:13:26+07:00",
            "date_modified": "2023-02-20T22:24:59+07:00",
            "tags": [
                "Popori",
                "TERA",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/down.jpg",
            "_date_published_rfc2822": "Tue, 23 Nov 2010 18:13:26 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "500",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/down.jpg",
                    "https:\/\/luridan.com\/pictures\/popori.jpg",
                    "https:\/\/luridan.com\/pictures\/popori-logo.jpg"
                ]
            }
        },
        {
            "id": "253",
            "url": "https:\/\/luridan.com\/all\/tera-235\/",
            "title": "Клиент игры ЗБТ 3",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/down.jpg\" width=\"569\" height=\"133\" alt=\"\" \/>\n<\/div>\n<p><b>Системные требования<\/b><br \/>\nПроцессор: Intel Core 2 Duo или лучше RAM: 2 Гб или более Видеокарта: GeForce 8800 и лучше (минимум GeForce 7600) DirectX: DirectX 9.0c или выше версия Жесткий диск: 40 Гб<br \/>\nКак видим, требования снизили.<\/p>\n",
            "date_published": "2010-02-26T19:35:57+07:00",
            "date_modified": "2020-04-09T00:37:13+07:00",
            "tags": [
                "Popori",
                "TERA",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/down.jpg",
            "_date_published_rfc2822": "Fri, 26 Feb 2010 19:35:57 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "253",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/down.jpg",
                    "https:\/\/luridan.com\/pictures\/popori.jpg",
                    "https:\/\/luridan.com\/pictures\/popori-logo.jpg"
                ]
            }
        },
        {
            "id": "219",
            "url": "https:\/\/luridan.com\/all\/tera-200\/",
            "title": "В погоне за консольными ощущениями в TERA",
            "content_html": "<p>Интервью с представителями отдела 3D-моделирования Gweon Min и Seung-weon Gang.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-200-1.jpg\" width=\"539\" height=\"337\" alt=\"\" \/>\n<\/div>\n<p>Графика TERA, какую мы видели, поражает. Прозрачное небо с плавно бегущими по нему изящными облаками, реалистичная водная поверхность, завораживающий полет на Пегасе с богатыми эффектами достойный длинного рассказа. Однако настало время последнего интервью, на которое согласились представители Bluehole Studio. Его нам дали технический моделист Gweon Min и моделист эффектов Seung-weon Gang. Онлайновую игру нового поколения вам представят два сотрудника фирмы.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-200-2.jpg\" width=\"539\" height=\"404\" alt=\"\" \/>\n<\/div>\n<p><b>TIG: Несколько непонятно, чем занимаются технические моделисты<\/b><br \/>\nGweon Min: Это понятно. Отечественные компании не уделяют этой стороне бизнеса большого внимания. 3D-технологии, применяемые при изготовлении игр, обеспечивают простоту и быстроту создания форм и воплощения замыслов, но в тоже время требуют постоянного сопровождения. Также сами художники не могут и не владеют современными технологиями воплощения своих работ. Таким образом, многие компании приходят к выводу о необходимости иметь в своем штате технический персонал, выполняющий данную работу.<\/p>\n<p><b>TIG: Какова важность технического персонала для компаний?<\/b><br \/>\nGweon Min: В высококлассной игре происходит постоянное расширение контента относительно исходных работ, что требует постоянной совместной работы от всех служб компании. Художники и программисты, хоть и связаны, но понимают задачи по-разному, потому что думают разными категориями. Технический персонал должен создать требуемые инструкции и описания, а также оформить необходимые требования для сдачи-приемки работ, что позволяет компании нормально функционировать. Так, в наши обязанности входит: поддержка средств программирования, весь спектр технических проблем с игрой, создание Pixel Shaders, исследования в сторону улучшения качества игры и проверка результативности.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-200-3.jpg\" width=\"539\" height=\"337\" alt=\"\" \/>\n<\/div>\n<p><b>TIG: Опишите вкратце, чем занимается группа моделирования эффектов<\/b><br \/>\nSeung-weon Gang: Как следует из названия, наша группа занимается созданием графики умений персонажей и всех визуальных эффектов окружающего мира. Игроки обычно невольно ограничивают сферу деятельности, к которой имеет отношение наша группа. Например, столб пыли — это эффект, случайное скопление насекомых — это эффект.<\/p>\n<p><b>TIG: Какие ограничения накладывает среда разработки?<\/b><br \/>\nSeung-weon Gang: В существующих MMORPG окружение существенно ограничивает использование эффектов. В случае TERA сильной стороной является использование Unreal Engine 3, который располагает технологией Shaders, благодаря которой удается достичь невиданного ранее в MMORPG реализма. Например, многие игровые движки предоставляют возможность разнообразного отображения пламени, но только в TERA пламя и открытый огонь по-настоящему реалистичны. Так, для отображения огня применено несколько шейдеров, что делает отображение движений более реалистичным. Для разработчика эффектов Unreal Engine 3 предоставляет практически неограниченные возможности. Кроме того никогда еще не было таких возможностей для работы с движением материала. Эффекты в TERA могут легко сравниться с эффектами из консольных игр.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-200-4.jpg\" width=\"539\" height=\"305\" alt=\"\" \/>\n<\/div>\n<p><b>TIG: Как в разработке принимает участие технический персонал?<\/b><br \/>\nGweon Min: Несмотря на то, что группа художников практически полностью выполняет разработку, весь внешний вид игры зависит от нас. В самом начале работы над этим проектом Bluehole Studio специалисты нашего отдела представили общие схематические планы, поэтому у нас есть полное понимание стоящих задач. С нашим отделом связаны художественные отделы, отделы программистов, отдел дизайна и еще многие подразделения.<\/p>\n<p><b>TIG: Как происходит процесс составления нужной документации?<\/b><br \/>\nGweon Min: Во-первых, при выявлении какого-то выделяющегося элемента необходимо произвести его оценку художественным отделом на предмет его уместности, а затем провести испытание его технической реализации. В случае положительных результатов испытания решение и описание проблемы направляются непосредственно в отдел программирования, где после положительных результатов проверки на ресурсоемкость они внедряются непосредственно в программу. В случае успешности внедрения художественный отдел получает соответствующие инструкции, а также издается документ, содержащий необходимые нормы. В будущем обращения в техническую поддержку будут обрабатываться согласно этим рекомендаций.<\/p>\n<p><b>TIG: Какое содержание ваших инструкций?<\/b><br \/>\nGweon Min: Наши инструкции охватывают практически всю игру: правила использования Pixel Shaders, правила создания всех зон игрового мира, информация о регистрации на карте объектов типа деревьев, правила относительно особенностей персонажей и их кастомизации. То есть практически все области, связанные с производством игрового контента.<\/p>\n<p><b>TIG: Входят ли в вашу сферу ответственности погодные явления?<\/b><br \/>\nGweon Min: Поддержка производства консультациями и технической документацией на общих основаниях. Однако, это производство очень сложное и ресурсоемкое. Например, необходимо, чтобы при взгляде на небо у пользователя возникали сильнейшие ощущения. Технология шейдеров, входящая в Unreal Engine 3, предоставляет нам возможность фактически создать для этих целей отдельную подсистему. Теперь представьте, что с помощью нашего отдела на обычном оборудовании были получены эти потрясающие сцены проплывающих облаков, включая сказочного вида солнце — прекрасное, роскошное, впечатляющее небо.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-200-5.jpg\" width=\"539\" height=\"337\" alt=\"\" \/>\n<\/div>\n<p><b>TIG: Что наиболее важно при создании эффектов?<\/b><br \/>\nSeung-weon Gang: Для TERA важно, чтобы реалистичные эффекты соответствовали окружению. Например, в случае, если игрок хочет резать ножом монстра, то именно в эту сторону должен быть направлен и спецэффект. В системе Non-Target важной работой является сочетание способа целеуказания и ощущения от удара. После осуществления удара необходим эффект испачканной кровью земли. Также для натуральности эффекта требуется учитывать класс монстра, его атакующие возможности и другие ограничения. Также для игрового процесса важно увязывать реалистичность при одновременном выполнении анимации и эффектов. Для придания натуральности мы использовали возможности Unreal Engine 3, позволяющие менять отображение всех эффектов умений и движений согласно движениям персонажа, основываясь на заданных настройках эффектов. Таким образом, есть несколько базовых элементов, позволяющих при необходимости создавать как резкие, так и плавные эффекты.<\/p>\n<p><b>TIG: Магические умения как-то отличаются?<\/b><br \/>\nSeung-weon Gang: Для магических умений у нас есть много задумок. У Sorcerer скиллы имеют разные атрибуты (огонь, вода, свет, тьма и так далее), и все они должны выглядеть естественно. Для Elementalist у нас есть несколько концептов, которые основаны на изображении цветка. Для Priest, в отличие от других игр, будут созданы в «цифровой» (имеется в виду киберпанк) стилистике.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-200-6.jpg\" width=\"539\" height=\"305\" alt=\"\" \/>\n<\/div>\n<p><b>TIG: В чем отличие от эффектов существующих MMORPG?<\/b><br \/>\nSeung-weon Gang: Система Non-Target сказывается и на эффектах. В существующих MMORPG эффекты статичные, неизменяемые. В TERA эффекты зависят от условий применения для увеличения зрелищности. То есть действие в TERA более «живое» и естественное. Даже без Non-Target введение подобного способа создания эффектов — новое явление в MMORPG. Если сравнивать с обычными MMORPG, то игра в TERA принесет больше эмоций и впечатлений благодаря потрясающему визуальному исполнению.<\/p>\n<p><b>TIG: Чем достигается польза от технической группы?<\/b><br \/>\nGweon Min: При разработке игры постепенно сферы деятельности разделяются всё больше, и появляется необходимость в дроблении подразделений. Тем не менее, запросы пользователей очень высоки. Наше подразделение сильно вовлечено в оценку сложности разработанного контента, оценки технической сложности ставящихся задач, а также для определения взаимоотношений между подразделениями. Этим достигается улучшение условий для разработки игры.<\/p>\n<p><b>TIG: Как именно проявляется эта польза?<\/b><br \/>\nGweon Min: Наибольшая польза — повышение качества визуальной составляющей игры. Технический отдел Bluehole Studio прикладывает все возможные усилия на этом направлении для проекта TERA. Также наш отдел предлагает различные способы и методы снижения себестоимости работ художественных отделов.<\/p>\n<p><b>TIG: Что делается для достижения такого качества эффектов?<\/b><br \/>\nSeung-weon Gang: Очень сложный вопрос. Если говорить вообще об играх, то между эффектностью и зрелищностью MMORPG и консольных игр существует огромная пропасть. Тем не менее, вместе с вышесказанным, даже если вы создадите замечательные прототипы персонажей и задних планов, вам всё равно нужно соединить их хорошими эффектами. Эффекты в TERA — новая высота в графическом исполнении MMORPG. Более того я бы хотел, чтобы вопросов о сравнении эффектов в TERA и на консолях не возникало ввиду очевидности ответа.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-200-7.jpg\" width=\"539\" height=\"404\" alt=\"\" \/>\n<\/div>\n<p><b>TIG: Сложно работать в техническом отделе?<\/b><br \/>\nGweon Min: Не легко. Для начала необходимо понимание всего процесса создания 3D игры. Необходимо понимание основных художественных работ. Требуются знания языков программирования. Также требуется логическое мышление, понимание естественных образов, а также понимание и возможность полноценного общения со всеми подразделениями компании, чтобы обеспечивать хорошую связность структуры. Конечно, наша команда обладает всеми необходимыми качествами для выполнения возложенных на неё задач, но, к сожалению, случаются моменты, когда и они не срабатывают.<\/p>\n<p><b>TIG: Что вам требуется для создания эффектов?<\/b><br \/>\nSeung-weon Gang: Честно говоря, каждый должен для себя определить важность эффектов в TERA. На создание эффектов для игры многие люди в течение многих месяцев выдают массу оригинальных и свежих идей. С этой точки создание окружения и эффектов делают зрения атмосферы команды. Я не думаю, что в других командах используются подобные стимулирующие мероприятия. Необходимы базовые навыки в 3ds Max и Adobe Photoshop, однако существенно более важна обучаемость другим новым средствам разработки. В TERA более 80% операций осуществляется средствами, имеющими отношение к Unreal Engine 3, что требует понимания новых программ.<\/p>\n<p><b>TIG: Скажите нашим читателям что-то на прощание<\/b><br \/>\nОба: Мы прикладываем все наши усилия для создания наиболее качественной графики и самых оригинальных эффектов. Спасибо за ваше ожидание и горячее участие. Осталось ждать уже недолго.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-200-8.jpg\" width=\"539\" height=\"337\" alt=\"\" \/>\n<\/div>\n",
            "date_published": "2010-01-03T19:45:18+07:00",
            "date_modified": "2023-04-14T14:26:57+07:00",
            "tags": [
                "Popori",
                "TERA",
                "Интервью",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/tera-200-1.jpg",
            "_date_published_rfc2822": "Sun, 03 Jan 2010 19:45:18 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "219",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/tera-200-1.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-200-2.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-200-3.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-200-4.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-200-5.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-200-6.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-200-7.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-200-8.jpg",
                    "https:\/\/luridan.com\/pictures\/popori.jpg",
                    "https:\/\/luridan.com\/pictures\/popori-logo.jpg"
                ]
            }
        },
        {
            "id": "213",
            "url": "https:\/\/luridan.com\/all\/tera-194\/",
            "title": "Люди, создающие систему Non-Target в TERA",
            "content_html": "<p>Интервью с представителями отдела программирования Hyeon-cheol Kim и Seong-jung Ryu.<\/p>\n<p>Я знаю одну игру, которая обладала замечательным замыслом, персонажами, окружением, качеством эффектов, но все равно провалилась из-за качества программирования. Программирование не заметно для глаз пользователей, но является основой всех игр. Особенно это важно для онлайн-игр, которые имеют разнесенные клиент и сервер. Возникает вопрос о том, что делается для обеспечения комфорта пользователей.<\/p>\n<p>Перед ЗБТ 2 у нас возникло множество вопросов, которые мы хотели бы задать представителям отдела программирования игры. Сейчас программирование TERA вышло на оптимальный ритм, поэтому мы встретились с двумя представителями Bluehole.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-194-1.jpg\" width=\"539\" height=\"404\" alt=\"\" \/>\n<\/div>\n<p><b>Программирование сервера<\/b><br \/>\nHyeon-cheol Kim: Идею создания связки сервера и клиента легко проиллюстрировать, например, при помощи связки браузера (Internet Explorer) и веб-сервера (собственно, сайта). Так же и в MMORPG — к серверу может подключиться одновременно несколько тысяч клиентов, которые с участием сервера могут выполнять определенные действия. Например, если игрок начинает атаку монстра, клиент посылает на сервер запрос, после чего на нём происходят проверки и расчеты. После завершения расчетов на сервере, происходит обратная передача результатов на все находящиеся в окрестностях клиенты. После этого обмена информацией результаты отображаются на всех вовлеченных клиентах у пользователей.<\/p>\n<p><b>Программирование клиента<\/b><br \/>\nSeong-jung Ryu: В случае каких-то действий игрока клиент обязан отправить соответствующий запрос на сервер. Пользователи непосредственно общаются с программой, поэтому тут возникает серьезный вопрос о безопасности. Также должны передаваться сведения о предметах. Подобное разграничение на две части — клиент и сервер — выглядит логичным и обоснованным. Со стороны клиента особенно важна скорость, тогда как система безопасности должна быть в основном на сервере.<\/p>\n<p><b>Разные результаты действий персонажей<\/b><br \/>\nSeong-jung Ryu: Вообще система работает так: клиент передает серверу информацию, сервер её обрабатывает и высылает клиенту результат. Однако каким будет действие персонажа на экране пока сказать нельзя. Например, это особенно характерно для перемещения. Так, клиент просчитывает команду, поступившую от сервера, и выполняет её в зависимости от конкретных условий.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-194-2.jpg\" width=\"539\" height=\"311\" alt=\"\" \/>\n<\/div>\n<p><b>MMORPG и система Non-Target<\/b><br \/>\nSeong-jung Ryu: Возможность её реализации мы оценили в самом начале разработки. Однако, по мере ввода нового контента, как показал опыт, требуется всё более мощный фреймворк для обработки загрузки в ходе тестирования. Об уместности non-target в MMORPG лучше будет спросить у пользователей об удовольствии от возможности полного контроля над персонажем.<\/p>\n<p><b>Реализация действий в Non-Target<\/b><br \/>\nSeong-jung Ryu: В условиях nontаrget важным элементом является использование монстрами особенностей рельефа. Из-за того, что монстры постоянно перемещаются, пользователю приходится постоянно менять направление обзора и следить за расстоянием, что может приводить к излишней нервозности.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-194-3.jpg\" width=\"539\" height=\"298\" alt=\"\" \/>\n<\/div>\n<p><b>Unreal Engine 3 и MMORPG<\/b><br \/>\nSeong-jung Ryu: Unreal Engine 3 — оптимальный движок для разработки FPS (First-Person Shooter). Что важно, он также оптимальный для дополнений, подразумеваемых жанром MMORPG. Раньше при создании MMORPG нужно было практически вс` заново разрабатывать, и только потом воплощать бесшовный мир.<\/p>\n<p><b>Unreal Engine 3 и другие средства<\/b><br \/>\nHyeon-cheol Kim: Unreal Engine 3 предлагает ряд средств, которые обеспечивают подстройку под свои нужды ускоренными темпами. Помимо стандартных средств, мы используем собственные. Например, средства, требуемые для отдела планирования, разработаны внутри компании. Практически каждый элемент контента требует тех или иных дополнительных средств.<\/p>\n<p>Seong-jung Ryu: От использованных при разработке средств зависит качество пользовательской среды. Хорошая работа планировщиков создания боевого баланса, свойств, данных — обеспечивает получение высококачественного игрового окружения. В целом, важность применяемых средств очень высока.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-194-4.jpg\" width=\"539\" height=\"404\" alt=\"\" \/>\n<\/div>\n<p><b>Падение серверов<\/b><br \/>\nHyeon-cheol Kim: Вопросы со стабильностью сервера внесены в график. Сейчас поиск ошибок в коде стоит особенно остро. Ошибки в программе не означают, что её использование невозможно. Мы подвергаем весь наш код серьезным внутренним испытаниям, потому что это — залог того, что в результате получится стабильная программа. В случае падения сервера быстро ставится вопрос на оперативном совещании, что позволяет быстро находить решение.<\/p>\n<p>Seong-jung Ryu: Стабильность программы крайне важна, поэтому не менее важны внутренние тесты. Многократно повторяющиеся тесты позволяют нам предложить пользователям совершенно стабильную программу.<\/p>\n<p><b>Ошибки (баги), не влияющие на стабильность серверов<\/b><br \/>\nSeong-jung Ryu: Приведу пример: искусственный интеллект (AI) монстров содержит баг. В этом случае в базу данных команды разработки монстров были внесены неверные параметры. Для TERA команда программистов разработала специальные средства, помогающие искать и устранять баги на всех ступенях разработки. Кроме того, все подобные процессы тщательно контролируются службой контроля качества (ОКК, QA).<\/p>\n<p>Команда программистов в моменты выявления и обнаружения таких случаев работает над уменьшением числа пострадавших, добиваясь, чтобы их вообще не было. С другой стороны, самостоятельная диагностика проблем разработчиками на этапе производства невозможна. Поэтому после получения замечаний от других служб работа продолжается. Это очень важная проблема.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-194-5.jpg\" width=\"539\" height=\"404\" alt=\"\" \/>\n<\/div>\n<p><b>Введение прыжка<\/b><br \/>\nHyeon-cheol Kim: После анализа множества отчетов и обдумывания этой идеи, мы пришли с положительному мнению относительно введения прыжков. Возможность прыжков уже внедрена на одном из технических прототипов, сейчас мы находимся в процессе окончательного определения требуемых параметров. Пока мы не думали о балансе, так как имеются большие проблемы с дизайном.<\/p>\n<p><b>Базовые знания для программирования игр<\/b><br \/>\nHyeon-cheol Kim: Для создания компьютерных игр требуются люди, понимающие основы в области компьютерного программирования, а также основные требования, предъявляемые к программам. При этом вполне достаточно базового школьного курса и знаний, полученных самостоятельно. Сейчас становится важным уметь не только видеть всю картину, но также понимать вопросы, связанные с разработкой любого аспекта игры и решать возникающие вопросы. Для этого самообучение подходит наилучшим образом. В Bluehole есть все возможности для быстрого получения всех необходимых базовых знаний. Наличие базовых знаний — залог правильного направления при разработке.<\/p>\n<p>Seong-jung Ryu: При подготовке программистов крайне важно, чтобы они посещали современные библиотеки. По крайней мере, это важно для подготовки специалистов в области rendering. Но это лишь одна из областей знаний, которая быстро меняется. Также важным вопросом является умение создавать такие программы, которые будут впоследствии понятны.<\/p>\n<p><b>Программирование и ориентация на внешние рынки<\/b><br \/>\nHyeon-cheol Kim: Программист может мало что сделать для поддержки передачи контента, связанного с текстовыми данными. Передача данных между разными командами не должна вызывать неудобств. Это может быть представлено как создание кода без возможности исправлений.<\/p>\n<p>Однако представляется важным создание средств для возможности локализации контента. Проект TERA, прежде всего, нацелен на общемировую аудиторию, поэтому возможность корректной локализации контента крайне важна. В проекте содержатся инструменты, позволяющие легко локализировать контент, а также исключать различные нежелательные в разных регионах элементы.<\/p>\n<p><b>Планы на будущее<\/b><br \/>\nHyeon-cheol Kim: TERA — игра, которая будет раскрывать свой потенциал в течение нескольких лет, поэтому сейчас имеются некоторые ограничения. Я не хотел бы обсуждать эту тему сейчас.<\/p>\n<p><b>Соединение сервера и клиента<\/b><br \/>\nОба: Техническая сторона, конечно, нуждается в оптимизации. Например, слишком большое количество постоянных подключений на сервер или скорость работы (FPS) клиента. Однако, важно чтобы игра получилась интересной. Лучшая похвала для отдела программирования — это если пользователи будут узнавать о нас только из титров. В этом смысле для удобства пользователей все подразделения должны выдавать разработки наивысшего качества. Наш отдел не хочет заслонять от вас солнце.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/tera-194-6.jpg\" width=\"539\" height=\"315\" alt=\"\" \/>\n<\/div>\n",
            "date_published": "2009-12-27T23:21:25+07:00",
            "date_modified": "2023-06-09T16:54:36+07:00",
            "tags": [
                "Popori",
                "TERA",
                "Интервью",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/tera-194-1.jpg",
            "_date_published_rfc2822": "Sun, 27 Dec 2009 23:21:25 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "213",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/tera-194-1.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-194-2.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-194-3.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-194-4.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-194-5.jpg",
                    "https:\/\/luridan.com\/pictures\/tera-194-6.jpg",
                    "https:\/\/luridan.com\/pictures\/popori.jpg",
                    "https:\/\/luridan.com\/pictures\/popori-logo.jpg"
                ]
            }
        },
        {
            "id": "148",
            "url": "https:\/\/luridan.com\/all\/tera-116\/",
            "title": "Клиент игры ЗБТ 2",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/down.jpg\" width=\"569\" height=\"133\" alt=\"\" \/>\n<\/div>\n<p><b>Системные требования<\/b><br \/>\nПроцессор: Intel Pentium DualCore, AMD Athlon 64×2 или лучше RAM: 2 Гб или более Видеокарта: Geforce 9800 и лучше DIRECTX: DirectX 9.0c или выше версия Жесткий диск: 30 Гб<\/p>\n",
            "date_published": "2009-10-31T17:12:40+07:00",
            "date_modified": "2020-03-30T21:00:49+07:00",
            "tags": [
                "Popori",
                "TERA",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/down.jpg",
            "_date_published_rfc2822": "Sat, 31 Oct 2009 17:12:40 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "148",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/down.jpg",
                    "https:\/\/luridan.com\/pictures\/popori.jpg",
                    "https:\/\/luridan.com\/pictures\/popori-logo.jpg"
                ]
            }
        },
        {
            "id": "76",
            "url": "https:\/\/luridan.com\/all\/tera-33\/",
            "title": "Клиент игры",
            "content_html": "<p>На официальном сайте игры представлен клиент для загрузки.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/luridan.com\/pictures\/down.jpg\" width=\"569\" height=\"133\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Доступен только зарегистрированным пользователям.<\/div>\n<\/div>\n<p><b>Системные требования<\/b><br \/>\nПроцессор: Двухъядерный и более<br \/>\nRAM: 2 Гб или более<br \/>\nВидеокарта: Geforce 9800 и лучше<br \/>\nDIRECTX: DirectX 9.0c или выше версия<br \/>\nЖесткий диск: 30 Гб<\/p>\n<p>Представленные рекомендуемые системные требования актуальны только для ЗБТ, так как работа над оптимизацией клиента ещё не закончена.<\/p>\n<p>На странице загрузки клиента можно проверить свой компьютер удовлетворяет ли он рекомендованным системным требованиям. Так же там можно скачать Direct X 9.0C.<\/p>\n",
            "date_published": "2009-08-17T17:32:27+07:00",
            "date_modified": "2020-04-09T00:36:31+07:00",
            "tags": [
                "Popori",
                "TERA",
                "Технический"
            ],
            "image": "https:\/\/luridan.com\/pictures\/down.jpg",
            "_date_published_rfc2822": "Mon, 17 Aug 2009 17:32:27 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "76",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/luridan.com\/pictures\/down.jpg",
                    "https:\/\/luridan.com\/pictures\/popori.jpg",
                    "https:\/\/luridan.com\/pictures\/popori-logo.jpg"
                ]
            }
        }
    ],
    "_e2_version": 4098,
    "_e2_ua_string": "Aegea 11.1 (v4098e)"
}