prototype

Introducing time dilation, CCP Veritas


Замедление времени

Часто говорится, что война против лагов не может быть выиграна, поскольку наши игроки всегда могут привести еще один корабль. Это, по существу, верно, и принятие этой истины важно для работы, которую мы выполняем в команде Gridlock (”затор”). В дополнение к работам по оптимизации, выполняемых нами, мы также боремся с проблемами деградации, чтобы, в случае перегруженности сервера, она обрабатывалась разумным способом. Именно об этом сегодняшний блог. Но, чтобы понять, куда мы движемся, нужно знать, где мы сейчас. В настоящее время, при перегруженности сервера нет никакого явного механизма для обработки такой ситуации. Те же самые механизмы, которые обеспечивают нормальное функционирование, продолжают двигаться собственным ходом. В результате возникает интересное поведение, но мне нужно определить некоторые термины, прежде чем я углублюсь в обсуждение.

Об tasklet’ах, планировщиках, и уступке

Серверы EVE Online, в целом, существуют, чтобы выполнять набор задач – будь это ответ на поступающий от клиента пакет, задача, поддерживающая состояние модулей или, в общем, почти всё. Их называют tasklet’ами, по причинам, о которых вам сегодня знать не потребуется. Так как мы имеем дело с компьютером, только один tasklet может выполнятся в любой момент времени, и должна существовать такая часть программного обеспечения, которая бы решала, какой именно tasklet это должен быть. Эта часть называется планировщиком.

Планировщики бывают совершенно разнообразные. Тот, который управляет tasklet’ами EVE Online довольно прост – это циклический, совместно-многозадачный планировщик. Цикличность означает, что каждому tasklet’у дадут возможность выполнится прежде, чем любому tasklet’y дадут две возможности. Нет никакого установления приоритетов, или специальной обработки - это очень справедливо в том смысле, что каждый получает в свою очередь. Совместная многозадачность означает, что никакой tasklet не будет прерван извне во время его исполнения. Tasklet будет выполняться вплоть до того, как завершиться, либо до вызова специальной функции, которая сигнализирует планировщику, что tasklet желает передать возможность выполниться всем остальным. Это называется уступкой.

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



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

Другой распространённой причиной, по которой tasklet уступает, является ожидание некоторого ввода от другой машины, например базы данных. Нет никакого смысла сидеть и постоянно спрашивать "оно уже вернулось?" снова и снова и снова - мы можем позволить другим tasklet’ам делать свою работу, пока мы ждём. (Да, технари, это – состояние приостановки, до сигнала о завершении операции ввода/вывода, но остальным это знать не интересно).

Да, чувак, к чему это ты клонишь ?

Извините, мне нравиться писать о компьютерных вещицах. Клоню к объяснению поведения tasklet’ов при большой нагрузке. Если сервер перегружен, то может пройти пять или более секунд, до получения возможности что-либо сделать, после того как ты уступил. Результатом всего этого является то, что задачи, которые либо очень благовоспитанны, или имеют многочисленные требования по взаимодействию, могут, в конечном итоге, завершаться адски длительно, поскольку они проводят большую часть своего времени в ожидании очереди на выполнение. Уничтожение корабля является великолепным примером - требуется множество запросов к базе данных, поэтому tasklet уступает очень часто, в результате чего событие растягивается на несколько минут, прежде чем, наконец, завершится. Схожим образом, модули также могут очень замедлиться в обработке, так как tasklet, который управляет ими, уступает после 100 миллисекунд выполнения.

Я рассказываю вам всё это для того, чтобы мотивировать следующее заявления:

Сервер EVE Online [под нагрузкой] должен деградировать таким образом, чтобы очередь tasklet’ов, ожидающих исполнения, была минимальной – в идеале нулевой.

Именно на это и нацеливается Замедление Времени.

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

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

Регулировка нагрузки выглядит гораздо более привлекательным предложением на данный момент, теперь, когда мы разобрались с кучей легких оптимизации. Были выдвинуты несколько различных предложений о том, что можно было бы сделать. Одно, которое предлагалось большинством в первую очередь – это переход к более низкому разрешению, нежели один раз в секунду, в Destiny, нашей системе моделирования физики, при возникновении перегрузки. Это помогло бы снизить нагрузку выполнения моделирования, но, как оказалось, она составляет только 5-10% от нагрузки, поэтому много мы бы не выиграли.

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

К счастью, у нас есть средство, чтобы регулировать нагрузку, которая даёт нам преимущества, оставляя нетронутым дизайн: сделать время бегущим медленнее. Подавляющее большинство нагрузки в больших схватках привязаны ко времени - модули, физика, перелёты, отварпы, все эти вещи случаются в течение некоторого периода времени, так что замедление времени пропорционально снизит вызываемые ими нагрузки. Таким образом, идея состоит в замедлении внутриигрового времени настолько, чтобы поддерживать очень небольшую очередь ожидания tasklet’ов, а затем, при снижении нагрузки, ускорении времени вплоть до нормального, по мере того, как мы справляемся с нагрузкой. Это будет выполняться на лету, и очень маленькими шажками; нет никаких причин, по которым мы не можем работать на 98% времени, если мы просто немного перегружены.


Хорошо конечно, но как вы себе это представляет во время большого боя?

Вот как я себе это представляю в время большого сражения (к примеру, 1600 или около того). Когда атакующий флот приварпывает, сервер становится сильно перегружен – варп и другие подготовительное задачи, к примеру, выпуск дронов, довольно дороги – и игровое время чрезвычайно замедляется, до 5% реального времени. Как только эти задачи выполняются, у сервера возникает достаточный резерв для безопасного сокращения коэффициента замедления до 30% нормального времени, и к схватке присоединяются должным образом. К этому моменту, у нас 1600 активно противоборствующих пилотов, с быстрым и справедливым подтверждением запросов, но просто используется в 3 раза больше времени, чем обычно. Игроки во флотах могут заметить это, потому что замедлилась анимация элементов управления кораблём, и взрывы в космосе происходят как будто в замедленной съёмке. По мере того, как всё больше кораблей уничтожаются/улепётывают, нагрузка, вызываемая сражением, снижается, и, по достижении около 1200 участников, оценивая-предугадывая, мы вернёмся к 60% нормального времени. Может быть в этот момент один из командиров понимает, что проигрывает, и приказывает отступать. Отварп также дорог, поэтому часы замедляются, скажем, до 10%, пока флот сматывается. С завершением битвы, и уходом проигравших, нагрузка на сервер становится малой, и он возвращается к 100% времени.

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


Время управлять ожиданиями !

Замедление времени не решает всех вопросов. Некоторые нагрузки не привязаны к продолжительному времени, поэтому у нас не будет возможности обрабатывать бои бесконечного размера. Сегодня мы находимся в точке, в которой это будет охватывать все, что мы видим на регулярной основе. Я думаю, однако, мы должны будем поставить жесткое ограничение на то, как сильно мы готовы замедляться. Нет смысла в замедлении системы до 0,1% времени, поскольку никто не сможет ничего сделать, и это ни к чему не приведёт. Я не знаю, где будет этот порог - это то, с чем мы должны будем поиграться после развертывания. Если бои будут постоянно превосходить этот порог, каким бы он не был выставлен, мы окажемся ровно там же, где и сегодня – с сервером, становящимся невосприимчивым, противным, и прочим. Посмотрим.

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


Короткая версия блога:

Замедление времени замедляет время так, чтобы сервер мог справляться со всем, что вы все там делаете. Мы собираемся поработать над этим, и если всё сработает, вы увидите всё это, но не совсем скоро.


--------

Выборочные посты CCP Veritas в теме с обсуждением:

#1
McThife: Мне не понравилось, как вы отбросили вариант с многопоточностю. Работа в многопоточных средах на различных платформах с различными серверами приложений показывает, что многопоточность в системах с высокой нагрузкой является решением №1. Я знаю, что это, вероятно, не самая простая вещь для воплощения, и движок EvE, вероятно, архитектурно построен вокруг однопоточной модели, но, пожалуйста, не говорите, что этот подход не дал бы выигрыша.

CCP Veritas: Я лишь сказал, что он не дал бы такого большого выигрыша, как многие думают. Переход к, скажем, 4-ём потокам не учетверяет производительность, за исключением ошеломляюще лёгких случаев. С накладными расходами, и требующимися блокировками, нам сильно повезёт, если мы получим 2х-3х кратный прирост производительности при 4-ёх потоках.
Учитывая количество усилий, которые необходимо предпринять, чтобы это реализовать, и последующих усилиях на поддержку многопоточного кода, это не будет лучшим планом прямо сейчас. Мы это неизбежно сделаем, через какое-то время. По этому пути сейчас идут очень многие.


#2

fossura: Какого размера будет зона, испытывающая эффект замедления, будет ли это грид, в котором происходит бой в системе, и т.д. Интересует вопрос, если битва длится в 5 раз дольше обычного, даст ли это одной из сторон преимущество в возможности привести подкрепления, и можно ли вызвать такой эффект по желанию, к примеру, группируя оружие и выпуская/отзывая дронов всем флотом ?

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

CSM6 Elections - The Results!

Выборы CSM6 закончились, результаты были объявлены только сейчас, на Фанфесте EVE, здесь, в Рейкьявике. Мы снова увидели рекордную явку, побившую предыдущие результаты (почти на 10.000 голосов больше, чем на предыдущих выборах), и самую крупную избирательную кампанию, которую мы когда-либо видели. Без лишних слов, я очень горд, что могу сообщить, что вашими делегатами  CSM6 являются:

Голосов Персонаж			Настоящее имя		Страна5,365	The Mittani		Alexander Gianturco	United States 3,813	Seleene			Mark Heard		United States 3,320	UAxDEATH		Mikhail Romanchenko	United States3,306	Trebor Daehdoow		Robert Woodhead		United States2,925	Killer2			Tim Pluples		Australia2,539	White Tree		Ross McDermott		Ireland2,240	Vile Rat		Sean Smith		Canada2,086	Meissa Anunthiel	Stephan Pirson		Belgium1,986	Draco Llasa		Rob Weatherly		United States

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

Альтернативными кандидатами в делегаты, получив позиции 10-14 в выборах, являются:

ГолосовПерсонаж			Настоящее имя		Страна1,747	Elise Randolph		Peter Farrell		United States1,341	Prometheus Exenthal	Adrian Mugnieco		Canada1,090	Krutoj			Mikhail Margulev	New Zealand956 	Two Step		Joshua Goldshlag	United States921	Darius III		Joseph W Morris		United States

Первый саммит CSM6-ССР в штаб-квартире CCP в Исландии, в Рейкьявике, будет проходить с 18 по 20 мая. Если у вас есть вопросы, которые вы хотели бы задать через CSM, убедитесь, что сообщите об этом, создав тему в Assembly Hall!

Демография избирателей
Как и со всеми результатами по выборам, их формат будет идентичен предыдущим.
Свои голоса отдали 49096 избирателей (то есть старше 30 дней и, следовательно, обладающих возможностью проголосовать), в сумме составляя 14,25% - в очередной раз рекорд явки избирателей. Из общего числа поданных голосов, 659 избирателей (1,34%) предпочли воздержаться. Этот % воздержавшихся намного ниже, чем в предыдущих выборах, что говорит о том, что игроки лучше понимают, за кого они хотели бы проголосовать, по сравнению с предыдущими выборами.

На этих выборах также сохранилась тенденция, что проголосовавших женщин-пользователей меньше, чем мужчин. Избиратели-мужчины составляют 96,9% голосов от общего числа избирателей, а женщин 3,1%. База пользователей EVE состоит из 96% мужчин, и 4% женщин.

Средний возраст проголосовавших пользователей - 31,3, увеличение, по сравнению с 30,8 на предыдущих выборах. Средний возраст проголосовавших учётных записей -  2,66 лет, также значительное увеличение относительно предыдущих выборов. Это может указывать на повышение интереса к CSM среди ветеранов EVE. 55,44% избирателей имели учетные записи старше 2 лет, 13,33% старше 5 лет и 2,88% старше 7.

Возраст в днях Частота Суммарно30.00	7200	14.67%250.00	7724	30.40%500.00	7748	46.18%750.00	5415	57.21%1000.00	5748	68.92%1250.00	4186	77.44%1500.00	3499	84.57%1750.00	3342	91.38%2000.00	1388	94.20%2250.00	1145	96.54%2500.00	922	98.41%2750.00	779	100.00%

Информация о голосовании по странам еще не доступна, однако мы добавим её в ближайшие несколько дней.

Вы можете сравнить эти результаты с результатами предыдущих выборов, прочитав следующие дев-блоги:

CSM 1 Результаты выборов
CSM 2 Результаты выборов
CSM 3 Результаты выборов
CSM 4 Результаты выборов
CSM 5 Результаты выборов

Еще раз поздравляем делегатов, и спасибо всем, кто принял участие в выборах.

-  CCP Diagoras


----------------
отсебятина:

5,365	The Mittani 		Goonswarm Federation, GoonWaffe3,813	Seleene			Cascade Imminent, Body Count Inc.3,320	UAxDEATH		Legion of xXDEATHXx, The xDEATHx Squadron3,306	Trebor Daehdoow		Initiative Mercenaries, Gallente Sane Industries Inc.2,925	Killer2			Morsus Mihi, 4S Corporation2,539	White Tree		TEST Alliance Please Ignore, Autistic Sharks2,240	Vile Rat		Goonswarm Federation, GoonWaffe2,086	Meissa Anunthiel	Rooks and Kings, Redshift Industrial1,986	Draco Llasa		RAZOR Alliance, Thundercats

источник

И снова это время года, когода люди дарят подарки, даже люди через 23000 лет, в будущем. CONCORD присоединился к сезонным торжествам, набив свои ангары специальным подароком для капсулиров Нового Эдема. С 14 декабря пилоты EVE Online получат последний корабль, сошедший со стапелей CONCORD - Echelon.



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


Начиная с 14 декабря 2010, вы сможете получить новый корабль на экране входа в игру. Вы сможете назначить его определенному персонажу, и CONCORD доставит его в ваш ангар. Вы сможете получить корабль-подарок единожды для каждого активного (не триального) аккаунта, и такая возможность больше не будет доступна после 3 января 2011, поэтому убедитесь, что вы своевременно войдете в игру, и получите ваш подарок.

Вот как можно его получить:
- Войдите в клиент EVE Online.
- На экране выбора персонажа будет кнопка Redeem Items (активировать предмет)  в правом нижнем углу. Выберите персонажа, который получит Echelon и нажмите на кнопку Redeem Items.



- Установите флажок рядом с Echelon и Purloined Sansha Codebreaker в окне подтверждения, и нажмите кнопку Redeem Selected Items (Активировать выбранные предметы).
- Вы получите окно подтверждения, с информацией о том, какой персонаж получает Echelon, и в какой станции он будет помещен. Он всегда помещается в текущей станции персонажа. Корабль не может быть получен, если принимающий персонаж не находится на NPC-станции.
- Нажмите кнопку «Да» в окне подтверждения, если вас устраивает ваше решение
- Войдите в игру этим персонажем, и запрыгивайте в свой новый корабль!
- Специальное примечание: Вы можете выполнить только одну транзакцию, используя эту систему, которая также управляет PLEX’ами, в течение 24 часов.



Поздравления, и счастливых праздников, от всех из CCP !

- CCP Loktofeit

источник
The stats of the Echelon are fairly equal to an average T1 frigate, except that it can only fit one module and no rigs. The module itself is similar to a T1 codebreaker, except it has twice the range and an eight-second cycle time.

Параметры Echelon довольно схожи с параметрами обычного T1-фригата, за исключением того, что он может нести лишь один модуль, без ригов. Сам же модуль аналогичен T1-codebreaker'у, но имеет в два раза большее расстояние, и 8-ми секудный цикл.

Интервью с ведущим разработчиком CCP Games, Noah Ward, от 30 ноября, на Ten Ton Hammer
source

Ведущий дизайнер игры раскрывает детали по кораблям, CSM, Noctis, и других темах.

Сегодня, с выходом первой частью Incursion для EVE Online, игроки требуют более подробную информацию о предстоящих изменениях в своей любимой MMOG. Чтобы выведать эту информация, Ten Ton Hammer поговорил с Noah Ward, ведущим разработчиком в CCP Games. Вопросы предоставлены постоянными EVE-писателями, The Mittani и Space Junkie.



Ten Ton Hammer: Атаки Sansha, часть Incursion будут потрясающими, но, по существу, будут блокировать большие области космоса, до тех пор, пока они не отбиты. Встряска hi-sec пространства - это хорошо, но, вполне возможно, некоторые игроки будут расстроены таким взбалтыванием их песочницы, которая в ином случае предсказуема. Что бы вы сказали этим игрокам ?

Noah Ward: Такие игроки должны рассматривать это как возможность насладиться новым содержанием, познакомиться с новыми людьми и, возможно, получить большие прибыли. Игроки EVE в целом достаточно хорошо адаптируются к изменениям и новым вызовам. Я ожидаю, что большинство будет рады этому вызову. Приятно то, что если люди действительно ненавидят его, им просто нужно эвакуироваться в соседнее созвездие на время действия, пока более храбрые члены сообщества дают отпор вторжению.



Ten Ton Hammer: Части Incursion отложены до декабря и января, для дальнейшего совершенствования, но сообщество фанов EVE кажется вполне довольным. Насколько рады CСP такой реакции на их решение?

Noah Ward: Я думаю, каждый игрок время от времени приходил в ярость из-за запуска продукта прежде, чем тот был доведен до совершенства. CCP очень рады, что сообщество понимает, мы лучше выпустим законченный продукт поздно, чем поспешно выпустим что-то с дисбалансом, ошибками в графике, и проблемами с удобством использования.



Ten Ton Hammer: Изменения, которые разворачиваются в ноябре, являются исправленими, или незначительные измененими, предложенными советом CSM. Как вы думаете, каким образом это изменит восприятие CSM?

Noah Ward: Мы надеемся, что когда люди увидят, что мы прислушиваемся к предложениям CSM, больше людей будут вовлекаться в процесс голосования в выборах, и поддержку вопросов, поднимаемых в разделе Assembly Hall на форуме. Это заключается в простом переходе на форуме EVE, и нажатии на кнопку поддержки в темах, касающихся интересующих вас вопросов, или создании новой темы с идеями о том, что бы вы хотели изменить. Затем CSM производит организацию и приоритизацию идей, и передает их CCP для дальнейшего обсуждения. Конечно, мы также читаем форумы, и отслеживаем горячие темы. Говоря о форумах EVE, им делают подтяжку лица, и интегрируют с EVE Gate, нашим сайтом социальной сети для персонажей EVE. Эта подтяжка должна сделать их как приятней для глаз, так и проще в использовании.



Ten Ton Hammer: Многие игроки кажутся наиболее разочарованы задержкой выпуска Noctis, хотя и не ясно, когда корабль будет выпущен. Какие-нубдь комментарии? Какие еще инициированые CSM элементы будут в Incursion ?

Noah Ward: Это сообщение CCP Explorer на форуме отвечает на оба вопроса:

Мы развертываем то, что сделали с лета в 3 выпуска: 1-ый в конце ноября, 2-ой в середине декабря и 3-ий в середине-конце января. Развертывание Incursion растянется примерно на полтора месяца. Как и все хорошие фейерверки, оно будет начато с приманки, будет с сюрпризом, и закончится большим взрывом:

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

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

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

Блестящии корабли - есть Noctis. Может быть, будут и другие.



Ten Ton Hammer: Как отложенный выпуск влияет на весеннии дополнения CCP?

Noah Ward: Нет, это не должно повлиять на наши дополнения 2011 года. Многие команды сейчас работают над Incarna, и не планировали выложить свои наработки этой зимой, так что задержка не повлияет на них. Другим командам не требовалось так много времени для дополнительной шлифовки, и они могли начать закладывать основы для следующего выпуска. С нашим переходом на принцип гибкого предприятия по всей организации, мы стали довольно хорошо реагировать на изменения.



Ten Ton Hammer: В отчете CSM minutes отмечено, что вторжений Саньша может вплоть до одного на регион. Если это так, то почему так много?

Noah Ward: Это было бы верхней границей, которую мы рассматривали, и, вероятно, этого не будет в начальном выпуске. Нижней границей мы выбрали 2 в high-sec, 2 в low-sec, и 2 в null-sec. Но эти цифры являются полностью открытыми для изменений, и мы можем легко настроить количество вторжений, основываясья на активности игроков. Мы хотим достичь баланса, когда их достаточно, чтобы каждый, кто хотел, мог бы принять участие, но не настолько много, что некоторые бы игнорировались, или чтобы они были переполнены вплоть до точки разочарования игрока.



Ten Ton Hammer: Мы знаем, что новый LP-магазин CONCORD будет иметь улучшенные версии capital-модулей, но будет ли что-нибудь новое и интересное для кораблей меньшего размера ?

Noah Ward: Да, в магазине CONCORD'а предлагается множество новых имплантатов. Другим интересным фактом о CONCORD LP является то, что они могут быть обменены на LP в других магазинах LP основных имерских фракций.



Ten Ton Hammer: Не сделают ли новые capital-модули убийство supercarrier ещё более трудным ? Не вышли ли уже supercarriers из под контроля ? Существующий баланс в EVE сильно благоприятствует supercapital-кораблям, вплоть до точки, что игра иногда именуется "Supercapitals Online". Incursion впервые вводит именованные модули capital-класса, совестно с фракционным supercapital кораблём, для использования игроками. Как Incursion предотвратит то, что supercapital’ы станут даже более важны для игры?

Noah Ward: Мы хорошо осведомлены об именовании "Supercaps Online" некоторыми из игроков-ветеранов, и мы понимаем, что не каждый хочет принимать участие в боях кап-флота. С учетом сказанного однако, есть игроки, которые действительно наслаждаются таким геймплеем, и у них не было такого же выбора в фите своих кораблей, как у пилотов кораблей меньших размеров. Таким образом, хотя некоторые игроки чувствуют, что capital-корабли становятся все более распространенными на современном поле боя, чем они должны были бы быть, мы не хотим наказывать игроков, которые наслаждаются их пилотированием. Новые улучшенные модули наверняка сделает capital’ы еще лучше, но они также сделают их гораздо более сочными целями из-за стоимости модулей. В центре внимания дополнения Incursion не было балансировки крупномасштабного PVP, этому было уделено наше внимание в последние сессии планирования для 2011 и пследующих дополнений. Мы будем рады поговорить напрямую с игроками об этих вещах, во всей глубине, на следующем фанфесте.

Вне всякой связи с балансом capital-кораблей, в созвездиях с вторжением в них будет эффект cyno-jammer, так что никакие capital-корабли не будет позволены в этих системы. Black-ops cyno по-прежнему будет работать. Так что большие группы не-capital кораблей потребуются для уничтожения вторжений, и такие игроки в более мелких кораблях будут в состоянии получить прибыль от продажи модулей capital-класса.


Благодарим Noah Ward за это интервью.

источник

Второе обновление клиента для Tyrannis 1.2 будет доступно в четверг, 11 ноября 2010. Это обновление клиента будет включать в себя исправления для пользовательского интерфейса, API, и EVE Voice. Пожалуйста, обратите внимание, что у игроков будет возможность отказаться от этого обновления, но мы настоятельно призываем всех принять его. Процесс развертывания начнется во время downtime в 11:00 UTC и, как ожидается, будет завершено в 11:45 UTC. Patch Notes доступны для просмотра здесь. Обсуждение ведется здесь


Patch Notes для обновления клиента Tyrannis 1.2

Развертывается в четверг, 11 ноября 2010

ИСПРАВЛЕНИЯ

Пользовательский интерфейс
- При наведении указателя мыши на полужирный текст ссылки, он теперь подсвечивается правильно.
- При переключении на вкладку атрибутов со вкладки истории навыков, текст будет показываться правильно.
- Размер текста более не будут уменьшаться в чат-канале при наборе на любом языке.
- При открытии нового списка в окне рынка, предыдущий просмотренный список теперь будет сворачиваться.
- Папки больше не будут выбыраться при использовании CTRL+А на древовидных структурах, таких, как список в окне Places.
- Окно услуг станции больше не будут появляться в случайном месте на экране при восстановлении перекрывающегося окна.
- Поле суммы в разделе Денежные переводы в кошельке корпорации было исправлено. Вы можете писать напрямую в поле при открытии окна.
- Контейнеры в пространстве будут открываться в том же месте, где и последнее передвинутое окна, или любой стек контейнеров. Выпущенные из трюма контейнеры, контейнеры останков, и контейнеры с грузом, оставшиеся после гибели корабля, теперь приведены в соответствие друг с другом.
- Исправлена небольшая проблема с окном Предстоящие события.
- Исправлена проблема с функциональностью End & Backspace в текстовых полях.
- Если звездная карта была открыта в то время, как игрок отстыковался, объекты в локальном пространстве не появлялись на звездной карте.
- Когда в врутриигровой браузер минимизирован, текст в нем больше не будет искажаться.

API
- Строка кода в API была обновлена, чтобы исправить ошибки со списками рассылки. ToListID в MailMessages API теперь будет возвращать пустую строку, а не 0, если оно не было отправлено в список рассылки.

EVE Voice, Mail, и Чат
- Цветовое форматирование в чате теперь будет работать правильно.
- Выход из канала голосового чата больше не приводит к ошибке.

Оружие и боеприпасы
- Исправлена проблема с модулями, не отвечавшими на щелчки мыши.

Разное
- Исправлена Repair Tool.exe чтобы работать даже тогда, когда он не может найти файл msvcp71.dll
- Исправлена ошибка, когда игроки будут в состоянии успешно перерабатывать еденичные элементы или единичный стек элементов.

Изменения

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