Однако ни в 2009-м году, ни в 2010-м игра так и не вышла, хотя на всевозможных выставках у нее непременно были стенды, где поначалу крутились ролики, а под конец 2010-го уже стали давать поиграть в один из эпизодов. Выглядело все довольно симпатично, но скучновато. Дата выхода игры упорно замалчивалась и стала известной лишь в конце сентября 2011-го. Правда, назвав ее, разработчики снова чуть-чуть наврали, и вместо 3 ноября новый Postal вышел 23-го, а в Steam появился и вовсе 21 декабря. У меня конец года получился крайне насыщенным, поэтому премьеру, каюсь, пропустил. И все же за разнообразными хлопотами не покидала мысль – почему же никто из знакомых в соцсетях ни словом не обмолвился о выходе почти легендарного долгостроя? Почему не дают ссылки на обзоры и не рапортуют о набегах на магазины? Неужели игра так и не вышла?

Но вот новогодние праздники закончились, за ними пронеслась и CES, и я наконец-то решил попробовать Postal III. Правда, в Steam его почему-то найти не удалось, и по прямой ссылке из пресс-релиза меня просто выбрасывало на главную страницу. Ну да ладно, обойдемся архаичными DVD. Ставлю игру, активирую, запускаю и понимаю - почему молчат соцсети. Видимо, они оказались шокированы не меньше моего.

Напомню, Postal III делали без малого шесть лет. Если верить пресс-релизу, за это время «у пятерых разработчиков родились дети, двое человек, причастных к проекту, и одна собака отправились в лучший мир, дата релиза проекта переносилась раз 9. Студия TrashMasters сменила три офиса, 4 сотрудников проводили работать в заграничные компании. За годы разработки было выпито 69 800 литров кофе, 56 700 литров чая, 138 900 литров пива. Подсчитать количество более крепкого алкоголя не представляется возможным в силу провалов в памяти сотрудников». Жаль, что не уточняется – на каком этапе от издателей в ужасе убежала совесть. Потому что большей лажи я и припомнить не могу. На фоне Postal III многострадальный Duke Nukem Forever выглядит вполне приличной игрой.

В Postal III ужасно практически все. Графика – на уровне худших образцов года эдак 2006-го (поддержка только DirectX 9 в конце 2011-го, каково?). Сюжет по разнообразию уступает даже любовным романам в мягкой обложке, которые давно пишутся специально натасканными текстогенераторами. Играть в новый Postal просто дико неудобно – действительно разнообразное оружие интегрировано в геймплей из рук вон плохо, и применять его по назначению порой невозможно. Наконец, стабильность работы отсутствует: игра вылетает по поводу и без, иногда даже слегка «подвешивая» компьютер. Ну и, конечно, «потрясает» дизайн. Авторы игры явно пытались замаскировать уродливые меню под эдакий хитрый панк-стиль, где все нарочито небрежно и кривовато. Но нет: игра ДЕЙСТВИТЕЛЬНО сляпана на коленке, и ни под какой мусорный дизайн не замаскировать полное отсутствие последнего.

Полное ощущение, что Postal III забросили и похоронили еще года три назад, а потом, вдохновившись примером несчастного кадавра Duke Nukem, решили быстренько соорудить нечто из имеющихся набросков и запустить ЭТО в продажу. Народ, конечно, будет плеваться, но сотню-другую тысяч копий продать непременно успеем, пока раскушают. Всё деньги…

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

Мне же остается надеяться, что в лапы подобных раздолбаев не попадет бренд Full Throttle.

P.S. И угадайте – почему я на этот раз даже не вспомнил о поддержке многоядерных процессоров?

Каюсь, я и сам постепенно переключился с квестов на шутеры, а в последнее время прохожу от и до только сериалы FarCry/Crysis и GTA. «Раньше у нас было время, теперь у нас есть дела», как пел классик. Ну и жизнь порой подкидывала такие квесты, что компьютерные аналоги как-то перестали цеплять. Последним прошел, кажется, «Грим Фанданго» - и все, отрезало.

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

Но в Rockstar Games решили немного воскресить старый жанр. Еще в далеком 2004-м году они поддержали материально австралийскую компанию Team Bondi и приступили к совместной разработке полицейского триллера о Лос-Анджелесе конца сороковых. Чтобы с беготней по улицам, ездой на машинах, стрельбой – но и реальным участием геймера в расследовании преступлений. Для этого на лицах персонажей появилась почти естественная мимика, по которой можно определить – врет ли он, нервничает или, наоборот, рубит правду-матку от души. Планировалось, что игра выйдет в 2008 году, но тут некстати подкрался мировой финансовый кризис, и L.A. Noire отложили до лучших времен. Которые наступили только в мае сего года для приставочников и в ноябре для нас, обладателей настоящих компьютеров. Выход Windows-версии пришелся на не самый лучший период в жизни Team Bondi: в октябре компания обанкротилась, оставив кредиторам разного рода расписок на миллион с лишним долларов США. К счастью, повлиять это может разве что на выход сиквела, если таковой вдруг случится, а оригинальная игра к тому моменту была закончена полностью.

Итак, что такое L.A. Noire?

Во-первых, это GTA IV с сильно улучшенной графикой, действие которой происходит на улицах Лос-Анджелеса образца 1947 года. Ездят машины, ходят люди, дома и улицы очень похожи на настоящие – в общем, залюбуешься. Вот только машины угонять теперь не надо, у полицейского всегда есть своя. И давить людей не рекомендуется, за это жестоко штрафуют и заставляют переигрывать эпизоды. Стрелять можно, но только в конченных негодяев, а так – только в воздух.

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

Я бывал в Лос-Анджелесе, но не могу сказать, что опознал в игре хоть кусочек города, не считая нескольких знаковых зданий. Наверное, за пятьдесят с лишним лет в нем действительно изменилось немало. Но нарисовано все удивительно симпатично, саундтрек идеально дополняет картинку, а диалоги, как это всегда бывает у Rockstar, радуют слух. Конечно, в них чуть не хватает мрачных и одновременно пошлых шуток из оригинальной GTA, ну да ничего, ее у нас никто не отнимал (как раз недавно еще разок прошел четвертую часть и жду пятую).

Преступления в L.A. Noire приходится расследовать самые разные – от угона автомобиля у аргентинского посла, оказавшегося… не очень хорошим человеком, до негодяйств серийного убийцы. Приятно, что тебе не дают притомиться от однообразия. Едешь с локации на локацию, а тут тебе подбрасывают какую-то мелочевку, вроде кражи в магазине. Несешься, разбираешься, а потом уже снова занимаешься серьезным делом.

Системные требования у игры приемлемые. На Radeon 6850 она неплохо работает при разрешении 1600х1200 при почти максимальных графических настройках, и только со сглаживанием лучше не перебарщивать. На опробованной недавно GeForce 560Ti (ультратихой, производства Palit) все совсем хорошо. И теперь главное, ради чего, собственно, этот пост и написан С поддержкой многоядерности у L.A.Noire порядок: два ядра процессора нагружены постоянно, а остальные – в зависимости от сложности сцены. Конечно, хотелось бы перетащить на CPU еще больше, чтобы GPU грелся поменьше, но это, пожалуй, уже из области капризов.

Так что очень толковая получилась игра (продано уже больше 4 миллионов копий), и если на новогодних праздниках у вас будет свободное время – очень рекомендую. Можно смело брать и локализованную версию, потому что переозвучивать прекрасные диалоги никто не стал, а просто пустили снизу субтитры. Идеальный вариант.

На сим закругляюсь. Надо уже наказать этого неуловимого маньяка…

Компания id Software имеет лицензию на PVS-Studio. Тем не менее, мы решили проверить исходные коды Doom 3, которые недавно были выложены в сеть. Результат - ошибок найдено мало, но всё-таки найдено. Я предполагаю, что это можно объяснить так.

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

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

Исходный код Doom 3 опубликован на GitHub и на официальном FTP компании под лицензией GPL v3. Для анализа я использовал инструмент PVS-Studio 4.39. Кряки для программы прошу не искать. Я уже встречал трояны, замаскированные под ключи и кряки к PVS-Studio. Лучше напишите нам, и мы дадим пробный ключ на некоторое время.

Фрагмент 1. Подозрительное условие.

#define BIT( num ) ( 1 << ( num ) )
const int BUTTON_ATTACK = BIT(0);
void idTarget_WaitForButton::Think( void ) {
  ...
  if ( player &&
      ( !player->oldButtons & BUTTON_ATTACK ) &&
      ( player->usercmd.buttons & BUTTON_ATTACK ) ) {
  ...
}

Диагностическое сообщение PVS-Studio:

V564 The '&' operator is applied to bool type value. You've probably forgotten to include parentheses or intended to use the '&&' operator. Game target.cpp 257

Обратите внимание на фрагмент "!player->oldButtons & BUTTON_ATTACK". Здесь хотели проверить, что самый младший бит равен 0. Но приоритет оператора '!' выше, чем оператора '&'. Это значит, что условие работает следующим образом:

(!player->oldButtons) & 1

Получается, что условие истинно, только если все биты равны нулю. Корректный вариант кода:

if ( player &&
    ( ! ( player->oldButtons & BUTTON_ATTACK ) ) &&
    ( player->usercmd.buttons & BUTTON_ATTACK ) ) {

Фрагмент 2. Подозрительный цикл.

void idSurface_Polytope::FromPlanes(...)
{
  ...
  for ( j = 0; j < w.GetNumPoints(); j++ ) {
    for ( k = 0; k < verts.Num(); j++ ) {
      if ( verts[k].xyz.Compare(w[j].ToVec3(),
                                POLYTOPE_VERTEX_EPSILON ) ) {
        break;
      }
    }
    ...
  }
  ...
}

Диагностическое сообщение PVS-Studio:

V533 It is likely that a wrong variable is being incremented inside the 'for' operator. Consider reviewing 'j'. idLib surface_polytope.cpp 65

Вложенный цикл увеличивает переменную 'j', а не 'k'. Переменная 'k' вообще не увеличивается. Последствия работы такого цикла непредсказуемы. Корректный вариант кода:

for ( k = 0; k < verts.Num(); k++ ) {

Фрагмент 3. Другой подозрительный цикл.

bool idMatX::IsOrthonormal( const float epsilon ) const {
  ...
  for ( int i = 0; i < numRows; i++ ) {
    ...
    for ( i = 1; i < numRows; i++ ) {
      ...
    }
    if ( idMath::Fabs( sum ) > epsilon ) {
      return false;
    }
  }
  return true;
}

Диагностическое сообщение PVS-Studio:

V535 The variable 'i' is being used for this loop and for the outer loop. idLib matrix.cpp 3128

Вложенный цикл организован с помощью той же переменной, что и внешний цикл. Оба цикла имеют условие остановки: i < numRows. Получается, что внешний цикл всегда выполняет только одну итерацию. Для исправления кода, можно использовать другую переменную во внутреннем цикле.

Фрагмент 4. Неопределенное поведение.

int idFileSystemLocal::ListOSFiles(...)
{
  ...
  dir_cache_index = (++dir_cache_index) % MAX_CACHED_DIRS;
  ...
}

Диагностическое сообщение PVS-Studio:

V567 Undefined behavior. The 'dir_cache_index' variable is modified while being used twice between sequence points. TypeInfo filesystem.cpp 1877

Переменная "dir_cache_index" изменяется дважды в одной точке следования. То, что используется префиксный инкремент, не имеет значение. Компилятор теоретически вправе создать код следующего вида:

A = dir_cache_index;
A = A + 1;
B = A % MAX_CACHED_DIRS;
dir_cache_index = B;
dir_cache_index = A;

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

dir_cache_index = (dir_cache_index + 1) % MAX_CACHED_DIRS;

Фрагмент 5. Подозрительная очистка массива.

void idMegaTexture::GenerateMegaMipMaps() {
  ...
  byte *newBlock = (byte *)_alloca( tileSize );
  ...
  memset( newBlock, 0, sizeof( newBlock ) );
  ...
}

Диагностическое сообщение PVS-Studio:

V579 The memset function receives the pointer and its size as arguments. It is possibly a mistake. Inspect the third argument. DoomDLL megatexture.cpp 542

Нулями заполняется только часть массива 'newBlock'. По всей видимости, это неправильно. Как мне кажется, раньше было написано так:

byte newBlock[ CONST_ARRAY_SIZE ];
...
memset( newBlock, 0, sizeof( newBlock ) );

Потом требования изменились и размер массива 'newBlock' стал изменяться. Но про функцию его очистки забыли. Корректный вариант кода:

memset( newBlock, 0, tileSize );

Фрагмент 6. Еще одна подозрительная очистка массива.

void Sys_GetCurrentMemoryStatus( sysMemoryStats_t &stats ) {
  ...
  memset( &statex, sizeof( statex ), 0 );
  ...
}

Диагностическое сообщение PVS-Studio:

V575 The 'memset' function processes '0' elements. Inspect the third argument. DoomDLL win_shared.cpp 177

Здесь при вызове функции 'memset' перепутаны аргументы. Функция очищает 0 байт. Это кстати весьма распространенная ошибка. Я встречал её многократно в разных проектах.

Корректный вызов функции:

memset( &statex, 0, sizeof( statex ) );

Фрагмент 7. Здравствуй, Copy-Paste.

void idAASFileLocal::DeleteClusters( void ) {
  ...
  memset( &portal, 0, sizeof( portal ) );
  portals.Append( portal );

  memset( &cluster, 0, sizeof( portal ) );
  clusters.Append( cluster );
}

Диагностическое сообщение PVS-Studio:

V512 A call of the 'memset' function will lead to underflow of the buffer '& cluster'. DoomDLL aasfile.cpp 1312

Обратите внимания, как похожи две верхние и две нижние строчки кода. Скорее всего, две последних строки были написаны с использованием технологии Copy-Paste. Это и привело к ошибке. В одном месте забыли заменить слово 'portal' на слово 'cluster'. В результате очищается только часть структуры. Корректный вариант кода:

memset( &cluster, 0, sizeof( cluster ) );

Я видел в коде и другие "недоочищенные" массивы, но про них писать не интересно.

Фрагмент 8. Подозрительная работа с указателем.

void idBrushBSP::FloodThroughPortals_r(idBrushBSPNode *node, ...)
{
  ...
  if ( node->occupied ) {
    common->Error( "FloodThroughPortals_r: node already occupied\n" );
  }
  if ( !node ) {
    common->Error( "FloodThroughPortals_r: NULL node\n" );
  }
  ...
}

Диагностическое сообщение PVS-Studio:

V595 The 'node' pointer was utilized before it was verified against nullptr. Check lines: 1421, 1424. DoomDLL brushbsp.cpp 1421

Сначала указатель 'node' разименовывается: node->occupied. А затем, вдруг проверяется, не равен ли он NULL. Это очень подозрительный код. Я не знаю, как его сделать правильным, так как не знаю логику работы функции. Возможно, достаточно написать так:

if ( node && node->occupied ) {

Фрагмент 9. Подозрительный формат строки.

struct gameVersion_s {
  gameVersion_s( void )
  {
    sprintf(string, "%s.%d%s %s %s",
            ENGINE_VERSION, BUILD_NUMBER, BUILD_DEBUG,
            BUILD_STRING, __DATE__, __TIME__ );
  }
  char string[256];
} gameVersion;

Диагностическое сообщение PVS-Studio:

V576 Incorrect format. A different number of actual arguments is expected while calling 'sprintf' function. Expected: 7. Present: 8. Game syscvar.cpp 54

Подозрительно то, что аргумент '__TIME__' никак не используется.

Фрагмент 10. Код, который сбивает с толку.

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

static bool R_ClipLineToLight(..., const idPlane frustum[4], ...)
{
  ...
  for ( j = 0 ; j < 6 ; j++ ) {
    d1 = frustum[j].Distance( p1 );
    d2 = frustum[j].Distance( p2 );
    ...
  }
  ...
}

Для подсказки, программист написал, что массив 'frustum' состоит из 4 элементов. Но обрабатывается 6 элементов. Если посмотреть вызов 'R_ClipLineToLight', то там массив из 6 элементов. То есть всё должно работать правильно, но код заставляет задуматься.

Другие ошибки и недочеты, можно увидеть, запустив анализатор PVS-Studio. Кстати, пользуясь, случаем хочу передать привет Джону Кармаку и сообщить ему, что мы скоро исправим недочет, который не позволяет в полную силу использовать PVS-Studio в компании id Software.

Этим недочетом является низкая скорость работы анализатора. Учитывая большой объем исходного кода, с которым работает компания, это существенное ограничение. В PVS-Studio версии 4.50, которая выйдет в этом году, можно будет в качестве препроцессора использовать Clang, а не препроцессор от Visual C++. Это позволит существенно ускорить проверку проектов. Например, при использовании препроцессора от Visual C++ исходные коды Doom 3 проверяются за 26 минут. А при использовании препроцессора от Clang - за 16 минут. Пример, правда, получился не очень удачный. На большинстве проектах выигрыш по скорости анализа будет значительно сильнее.

Правда по умолчанию, пока придется использовать препроцессор от Visual C++. У Clang все еще есть некоторые несовместимости и недоделки, касающиеся Windows-платформы. Так что успешно удаётся проверить только 80% проектов.

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

Задача:  необходимо разработать сервер и клиент для игры через интернет, с количеством одновременно играющих игроков не менее 1000.

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

Выбор языка программирования

Из знакомых мне языков, с помощью которых можно было бы реализовать, были следующие: php, c#, c++. Из плохо известных: Java. Остальные не рассматривались ввиду отсутствия опыта работы с ними.

За год до этого был опыт разработки более упрощенной задачи подобного вида, при этом стояло жесткое условие: язык программирования PHP. Так что я сполна оценил все недостатки этого языка применительно к подобной задаче (все же он предназначен для других целей, хотя при желании и топором можно торт нарезать, но что из этого выйдет – вопрос интересный). С# представлялось сложным использовать на Debian. Java был отклонен ввиду маленького опыта работы с ним. Вероятно, люди, хорошо в нем разбирающиеся, смогли бы качественно реализовать подобный сервер. В итоге: C++.

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

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

Выбор инструментов языка

Тут тоже было просто. Исходя из того, что разработка велась на Windows 7, а работать должно на Debian, все средства должны быть переносимы. В качестве основы кроссплатформенности была выбрана библиотека boost. Основную роль сыграло то, что boost является основой для вышедшего и следующих стандартов языка C++, других значительных «за и против» применительно к данной задаче я не нашел (сравнивания например с Qt). Как позже выяснилось, нужны были только базовые возможности библиотеки (потоки, работа с файловой системой), а потому не было особой разницы, что выбирать.

Вывод: если не находишь разницы между вариантами, выбери любой , и делай, там будет видно.

Проектирование

Любопытна склонность к необоснованному преувеличению сложности программы. Это проявляется как на уровне алгоритмов и структур данных (желание сразу все оптимизировать), так и на уровне архитектуры приложения (к примеру, попытка сделать все сверхпараллельно). И как следствие: рост сложности программы, отсюда большее число ошибок и возрастающая трудность в их исправлении, отсюда затягивание сроков, нервы и т.д. Кому такое надо? Правильно, никому.

Как сказано в одной книге: «программирование – есть управление сложностью».

Взять хотя бы конкретный пример (задачи конкурса Acceller8). За время конкурса решение эволюционировало и прошло следующие этапы:

1. Используем библиотеку TBB. И сразу пошло-пошло распараллеливание по задачам. Что будет дальше не знаю, но точно будет много потоков (не сделал, осталось только в планах).
2. Запущенны N потоков стандартной функцией, они из общего массива каждый в своем порядке (чтобы не мешать друг другу) берут матрицы для вычисления и считают, когда очередь заканчивается они просматривают сначала потоки, запущенные на этом же процессоре, чтоб им помочь. Если на этом процессоре потоки всё посчитали, то поиск производиться на других (реализовано).
3. Запущенны N потоков стандартной функцией, они из очереди подряд берут матрицы для вычисления и считают, когда очередь заканчивается они просматривают подряд все другие потоки, чтоб им помочь (реализовано).
4. Запущенны N потоков стандартной функцией, они из очереди берут матрицы и считают (уже не было времени рефакторить старый код из п.3 чтоб убрать лишний функционал. Это ж надо, что получается: реализовываешь этот лишний функционал, реализовываешь, время тратишь... Так чтоб его еще и убрать потом, нужно время тратить!

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

Вывод: если хочется сделать суперпрограмму, то стоит обосновать действительную необходимость тех или иных «улучшений», иначе, в лучшем случае, они не нанесут вреда. Хотя, с другой стороны, это лишь вопрос опыта и времени, требуемого на его приобретение.  

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

Реализация сервера: от сложного к простому

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

Параллельная обработка бывает разная

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

Есть управляющий поток, содержащий списки активных соединений и текущие сражения. Каждые 100 мс (для разрабатываемой игры +/- 100 мс не значительно) сражения и соединения передаются в очередь менеджеру потоков на выполнение (для соединений проверяется поступление команд игрока, для сражений – происходит обработка 100мс игрового времени).

Минусы, из-за которых пришлось отказаться от данной модели:

1. Сложность всвязи с возможностью одновременного выполнения сражений и соединений, возникает необходимость гарантировать, что состояние игры будет изменено в один момент времени либо командой от игрока, либо внутренней обработкой. В результате, ко всем функциям, изменяющим состояние игры необходимо добавлять мьютексы и т.д.
2. Сложность контроля за выполнением потоков в менеджере. Выполнил он потоки? Или еще выполняет?

В результате была реализована модель представленная ниже:

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

Алгоритм обработки внутри потоков:

1. последовательно проверить поступление новых команд от пользователей и передать им данные,
2. последовательно обработать сражения,
3. подождать до следующего цикла.

Преимущества данной модели в отсутствии недостатков прошлой:

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

Проблема большого кода

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

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

Рыцарь атакует орка, которого убивает эльф

Рассмотрим пример с добрым рыцарем, спящим орком и славным эльфом. Добрый рыцарь видит спящего орка, решает атаковать его и начинает подкрадываться к нему, делая себе пометку, что на это уйдет 10 сек. Славный эльф тоже видит сложившуюся ситуацию и решает помочь доброму рыцарю, и потому в течении 5 сек выпускает пять стрел, которые убивают орка. В реальной жизни славный рыцарь прокравшись в течении 10 сек (в соответствии со своей пометкой), понял что его опередили и стал бы подкрадываться к следующему спящему орку. В игре же возможен вариант, что подкравшись к орку, он увидит «Access violation at address 0A6C77BE», и, вероятно, упадет вместе с сервером.

Решение очевидно – хранения счетчика ссылок на орков, а в общем случае – на игровые объекты. Ниже приведена первоначальная реализация:

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

После наступления события, «рыцарь» сообщает менеджеру объектов, что «орк» не представляет для него интереса (через вызов RemoveDependency). Если от объекта больше никто не зависит, то объект удаляется.    Проблема возникла, когда стало понятно, что на каждое событие приходиться писать по две строчки кода для добавления зависимостей (по одной при создании и наступлении события).

Если есть работа, которую можно не делать, то ее лучше не делать. Потому модель была изменена на следующую:

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

Сохранение сражения

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

В общем случае всё сражение строится на объектах и событиях, поэтому задача сохранения – есть задача сохранения всех объектов и событий (в реальной игре также необходимо сохранять: текущее время, количество очков у игроков и т.д., эта часть задачи рассмотрена не будет– на смысл примера это не повлияет). Итак,  первоначальный вариант предполагал сохранение данных путем их сериализации и последующей десериализации. Каждый объект наследуется от базового класса с виртуальными функциями сериализации и десериализации, объекты событий – аналогично. В качестве формата хранения данных предполагалось использовать JSON. А в качестве места хранения - базу данных.

Проблема стала очевидна при дальнейшей  модификации объектов (их наборов свойств), ведь любое добавление или удаление вело к необходимости переписывания функций сериализации/десериализации. Решением проблемы было сохранение дампа памяти:

Фактически, сохраняется область памяти, в которой размещены данные менеджеров объектов и событий. Здесь пришлось модифицировать программу таким образом, чтобы все данные сражения (класс Game) располагались в памяти последовательно (сюда относятся пулы для выделения памяти под объекты и события, информация о ресурсах, игроках и т.д.). Сейчас сохранение занимает порядка 250КБ, сюда входит возможность одновременного присутствия в сражении 1000 игровых объектов (монстров, зданий и т.д.) и 3000 событий (ничего не мешает при необходимости увеличить их количество в будущем).

Также потребовалось: (1) преобразование адресов в индексы, и обратно. Это пришлось сделать из-за отсутствия гарантии на то, что память под класс будет выделена в том же самом месте (внести это изменения было несложно, т.к. адреса объектов хранятся только в менеджере событий, и в очень-очень малом числе игровых объектов). (2) Потребовалось добавить проверки на изменение версии сервера и модели карты (т.к. она хранится в памяти отдельно).

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

Заключение

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

Battlefield – это бренд крупнейшего издателя игр Electronic Arts. Он (бренд) на рынке с 2002-го, и с тех пор вышло аж 19 (!) частей. Это значит, что каждый год минимум два продолжения, а бывает и по три. На фоне Call of Duty, главного бренда-конкурента издателя Activision, под которым выходит максимум одна игра в год, налицо сильный отрыв по очкам. Но так получилось, что Call of Duty я перепробовал практически все, начиная с первой части, а Battlefield как-то проходил мимо вплоть до октября нынешнего года. Так бы, наверное, и продолжалось, но на одном из форумов попались очень эмоциональные комментарии по поводу вышедшей на днях Battlefield 3. Мол, тоска страшная, графика никакая, глючит страшно – не покупайте ни в коем случае. После провальной Rage мне стало немножко страшно – а ну как и Electronic Arts теперь пытается продавать недоделанные игры? Решил попробовать, и вот уже третий день, воспользовавшись индульгенцией на грех безделья в виде довольно тяжкой простуды, не без удовольствия изучал данный продукт.

Помню, году в 95-м были модны игры-видеотиры. Уже не могу припомнить ни одного названия, но смысл такой: вся игра представляла собой фильм, для просмотра которого целиком пользователю надо было шустро и довольно точно наводить курсор и кликать мышью. Попал – смотри кино дальше. Не попал – кликай, пока не попадешь. С тех пор игровая графика шагнула далеко вперед, и для создания действительно убедительной картинки больше не надо снимать фильм – все можно рисовать в реальном времени. Но сам жанр этого не изменился: фактически пользователь в Battlefield остается «мышенажимателем», потому что абсолютно все в игре проскприптовано насквозь, и сотворить что-нибудь эдакое не получится при всем желании. Например, попробовал я в одной из миссий спрятаться за заборчик и обойти врага с тыла. Ага! Счаз! Игра тут же сообщила, что я покинул игровое поле и потребовала срочно вернуться обратно. За ослушание же покарала необходимостью переигрывать эпизод с начала. И ее ни капельки не смутило, что всего через несколько секунд после уничтожения нужного количества виртуальных террористов зона за заборчиком стала вполне игровой, и по ней стало возможным перемещаться без неприятных последствий.

Сюжет я, честно говоря, перестал понимать уже минут через сорок. Надо отдать авторам должное: дикое мешанину из эпизодов, происходящих в разных концах света, они маскируют за флэшбэками некоего морпеха, допрашиваемого по подозрению в чем-то очень нехорошем. Бегать по охваченному беспорядками мегаполису за него было довольно весело, и я даже почти поверил, когда он перевоплотился в русского парня Диму, но вот с инкарнацией в девушку-летчицу уже случился перебор, и за дальнейшими скачками фантазии предпочел следить чуть отстраненно. Зато не только побегал, но и покатался на машинке с пулеметом, полетал на истребителе и погромыхал на танке. В игре постоянно что-то происходит, расслабиться она не даст, но и перенапрячь мозг не получится, ведь по каждому пустяковому поводу последует подсказка в виде строчки текста на экране или, как минимум, реплики напарников. На особенно важных целях просто появляется горящий значок, означающий «СТРЕЛЯТЬ ТУДЫ». Стреляешь – и цель красиво падает или вовсе разлетается на тысячу осколков. Кррасота!

Игра сделана на движке Frostbite 2. Он же используется и в консольных версиях, однако графика там просто драматически хуже, чем на PC. Настолько, что фанаты сериала (есть и такие) выключали свои Xbox и шли покупать новую видеокарту для компьютера. Меня картинка порадовала, но не потрясла. А вот движок все же немного потряс своей удивительной всеядностью. Хочешь – рисуй очень естественно передвигающихся людей, хочешь переполненные движущимися автомобилями улицы, хочешь пустыню, по которой движется танковый взвод, а хочешь – полет сверхзвукового истребителя над штормящим морем. И все это с вполне достаточным уровнем убедительности. Звук в данном случае является неотъемлемой частью движка и сделан он весьма добротно. Мне в свое время приходилось попадать под настоящие обстрелы с участием танков и вертолетов, и звуковые впечатления отложились в памяти довольно прочно. Так вот здесь все очень, очень похоже. Кстати, движок настолько продвинут, что игра не поддерживает DirectX 9 и, соответственно, даже не запустится на Windows XP. Жестоко, но по-своему логично.

В системных требованиях к BattleField 3 рекомендуется использовать четырехъядерный процессор. Проверил – действительно, не для красоты написали. Два ядра загружены постоянно практически под завязку, а на остальных нагрузка плавающая, от 30 до 60%. GPU при этом загружен полностью, и уже минут через двадцать кулер видеокарты начинает давать о себе знать довольно отчетливо. Тут уж ничего не поделаешь: быстрые и холодные графические чипы пока встречаются только в сказках да роадмапах Intel Справедливости ради, несмотря на заметное отставание моего Radeon 6850 от рекомендованного разработчиками 6950, игра очень быстро носится в разрешении 1600х1200 со всеми графическими настройками на максимуме. Достойно уважения.

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

Вот же чудеса: вроде и понимаешь, что имеешь дело с поточной штамповкой, просто сделанной на приличном заводе и умелыми руками, а ведь радует! Радует! Вот и поди разбери: то ли и на конвейере можно делать хорошие вещи, то ли все дело в том, что автор этого поста в последние годы смотрит сериалы гораздо чаще, чем художественные фильмы…

P.S. С мест сообщили, что за первую неделю люди купили 5 000 000 копий Battlefield 3. Лучший результат в истории Electronic Arts. Вот тебе и сериал.

Как известно, проще всего придираться, потому что небанальные оборотцы так и лезут в голове. А вот хвалить почему-то трудно. Правда, Дмитрий Рыжков недавно потребовал вообще все обзоры сводить к одному предложению: мол, хочется сразу прочитать вывод, а не продираться через словеса, таблички и графики. Поэтому специально для Дмитрия я напишу, что N9 на MeeGo – это очень интересный и самобытный аппарат, просто феноменально хорошо допиленный для первого блина, каковым он, несомненно, является. А для тех, кто еще не привык к столь коротким формам, допишу еще несколько слов.

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

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

Также MeeGo воплощает в себе мечту целого поколения разработчиков, когда с одной стороны мы имеем действительно простой, красивый и быстро работающий интерфейс, а с другой – самый настоящий матерый Linux с возможностью допиливания всего и вся, а также установкой DEB-пакетов. Причем линуксовая составляющая спрятана настолько аккуратно, что обычный пользователь может о ней никогда и не узнать, просто пользуясь N9 в свое удовольствие.

Правда, как и следовало ожидать, ПО для MeeGo пока очень негусто. Почти все необходимое для жизни стоит на аппарате изначально – от достойного почтового клиента до абсолютно всеядного плеера со всеми остановками. Но если захочется излишеств – увы, придется подождать. Порадовало, кстати, что в магазине приложений уже живет Alchemy Classic, написанная знакомыми нам парнями из Самары. Работает нормально, но над интерфейсом и иконками еще надо чуть-чуть помозговать, а то уж слишком мелко. И, конечно, хочется верить, что подобную оперативность проявят разработчики из других городов и стран.

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

Long Live MeeGo!

P.S. Если хотите прочитать действительно большой текст о первом смартфоне на MeeGo, рекомендую труд Сергея Маленковича, подготовленный при некотором вмешательстве с моей стороны.

Еще до покупки игры мне приходилось слышать, что с ней не все в порядке: мол, глючит страшно, и в id Software объясняют проблемы очень просто – мол, компания не рассматривает PC, как основную платформу для игр. И все же я был уверен, что трудности преувеличены: ну может где-нибудь текстурка мигнет, или игра зависнет пару раз за день… В конце концов, это же id Software, «премиальный бренд», не может же она выпустить на рынок совсем недоделанный продукт?

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

Расскажу о своих мытарствах подробнее. Игра поставляется аж на 3 DVD и занимает на жестком диске больше 15 гигабайт. При первом запуске она порадовала меня дикой мешаниной из текстур, исключающей возможность собственно играть. Несколько озадаченный, я стал советоваться с Интернетом, вывалившим на меня целую груду рецептов. Перво-наперво порекомендовали установить новую бета-версию драйвера для моего Radeon HD6850. Я скачал сначала неправильную, выпущенную 8 октября, и она решала проблему капитально: просто отключала ВСЕ текстуры и всё. Картинка выглядела чуть лучше, чем в легендарном Wolfenstein 3D,но желания поиграть почему-то не вызывала. Добрые люди прислали ссылку на правильную бету, которая Preview 3. При ее установке компьютер впервые за очень долгое время продемонстрировал синий экран, но после аварийной перезагрузки Rage запустилась с текстурами. Счастье, правда, длилось недолго: продемонстрировав свою красоту, игра начала зависать. Делала она это настолько регулярно и разнообразно, что невольно вспомнился перечень способов приготовления креветок из фильма «Форрест Гамп». Она зависала при загрузке уровня, при попытке выйти в главное меню, при переключении задач, при оглашении сути очередного задания, при сохранении игры, при подгрузке текстур… Наконец, больше всего ей нравилось зависать просто так. А бета-драйвер оказался настолько совершенным, что намертво вешал Adobe Photoshop, пока я не догадался отключить в нем поддержку вычислений на GPU.

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

И вот это – id Software. Легенда, технологический лидер и просто небедный коллектив разработчиков, уж точно способный позволить себе целую банду QA-специалистов. Провал же получился такой, что я даже не могу припомнить аналогов. Да, бывало, новые игры неприлично тормозили и вылетали, но чтобы вообще толком не работали… Нет, не могу вспомнить.

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

Что характерно, приставочные версии работают стабильно, но тут всплывает другой меганедостаток: Rage безнадежно однообразна и скучна. Как только надоедает смотреть по сторонам, любуясь действительно роскошными пейзажами, желание играть тут же пропадает. Сюжет никогда не был сильной стороной игр id Software, но тут на нем отдохнули как-то особенно хорошо.

В те короткие моменты, когда игра работала, я смог понаблюдать за нагрузкой на процессор и GPU. С удовлетворением отметил, что движок id Tech 5 эффективно использует четыре ядра процессора, распределяя между ними нагрузку практически поровну. Пиковая нагруженность графического чипа составила 69% (разрешение 1600х1200), но обычно она не превышает 62%. В результате компьютер не перегревается и не шумит.

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

P.S. Заголовок этого поста отсылает к популярному в свое время боевику "Слепая ярость" с Рутгером Хауэром в главной роли. Вот только не уверен, что нынешняя молодежь его вообще помнит

Первую часть, отправленную на золото в мае 2000-го года, журнал PC Gamer назвал лучшей игрой всех времен и народов. И, пожалуй, было за что: игра очень гармонично сочетала в себе стрелялку и RPG, а работало все на прокачанной первой версии Unreal Engine. Правда, с прокачкой чуть переборщили, и на типовых конфигурациях того времени игра малость того… подтормаживала-с. Ну и особенно дотошные геймеры немного покричали, что-де уж очень похоже на System Shock 2. И все же – продажи за миллион копий, куча наград и, понятное дело, неплохая прибыль для Eidos и Ion Storm.

Сиквел Invisible War, выпущенный в 2003-м аккурат под Рождество, критику имел пожиже, но по продажам обошел оригинал. Движком выбрали Unreal Engine 2, снова все подтормаживало, но это бы еще полбеды. Сюжет, так цеплявший в первой части, на этот раз был уныл до предела, и, положа руку на сердце, еще одного продолжения никто ждать не собирался.

Но вот в августе 2011-го полыхнуло: на прилавках появилась Deus Ex: Human Revolution, приквел к самой первой части. Не удержался, купил, благо 600 рублей – вполне гуманная цена. Ну и сработал тот же механизм, что и с «Дюком»: раз за первые версии не платил, зашлю денег хоть сейчас.

Сначала вроде бы пошло неплохо. Занимательные ролики, болтливые статисты на этажах здания таинственной био-нанотехнологической корпорации, персонажи с характером. Вроде бы неплохой выбор оружия, многовариантные задания. Вот только графика… Вместо Unreal Engine на этот раз выбрали Crystal Engine, гостя с приставок. Именно на нем всю последнюю пятилетку клепали одинаково тоскливых Tomb Raider’ов, работавших одновременно на PS3, Nintendo Wii, Nintendo DS, PSP и даже мобильных телефонах. Как добиться работы на всем подряд минимальными усилиями? Правильно, упростить все до предела! Вот бедный Deus Ex: Human Revolution и выглядит, как привет из начала двухтысячных: ни следов от пуль, ни разбитых стекол, ни даже отражений в зеркале, которые в игре почему-то все перебиты. Более-менее прилично картинка выглядит только в роликах, сделанных отнюдь не на движке. Но вот кино заканчивается, и ты снова оказываешься в сером мире с жуткими текстурами…

Задания поначалу кажутся интересными, но скоро разнообразие оказывается дутым. Все сводится к «убей или обойди», перемежаемому опросами жителей виртуального мира на предмет подсказок к загадкам. Враг скучен, однообразен. Уничтожать его не интересно, а прятаться от этой серой стреляющей массы – стыдно. Мегананотехнологичный герой, в котором по сюжету все, что можно и нельзя, заменено на железки, мало чем уступает в хрупкости гуттаперче и гибнет под первым же залпом врага. Сохраненные же игры загружались поначалу просто безумно долго, и это вылечилось только после первого патча. Интересно, чем занимался QA в Eidos Montreal?

Я честно побродил по дурно нарисованному Детройту один из выходных, а потом понял, что мне дико скучно. Словно еще раз прохожу первый Deus Ex, время которого давным-давно ушло. На прощание проверил, как у нас там с многоядерностью. Выяснилось, что никак: игра грузит только одно ядро CPU, что значительно усиливает мои подозрения в нетронутости движка года с 2006-го.

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

Но нет уж. Умерла – так умерла.

P.S. Кстати, можете и не доверять моему мнению. Этот заунывный как бы триллер за месяц разошелся двухмиллионным тиражом (с учетом версий для приставок). Не могли же они все ошибиться, верно?

Сам патч относительно невелик (мегабайт сто) и скачивается автоматически (если, конечно, у вас лицензионная копия игры). А вот для всех красот DirectX 11 надо стянуть файл размером больше 500 мегабайт, что при небыстром соединении может занять некоторое время. Еще по соседству лежит комплект текстур высокой четкости, тянущий аж на 1.6 гигабайт, но я его решил отложить на потом. И правильно сделал.

Сама установка обоих патчей прошла очень гладко. После запуска Crysis 2 отрапортовал о появлении возможности включить все прелести DirectX 11, включил их и… на этом, в общем-то, игра закончилась. Нет, я правда верю, что картинка стала красивее и натуральнее, благодаря улучшенной модели теней, освещения и bump-mapping’у. Вот только раньше в Crysis 2 можно было играть. А теперь он превратился в динамичное слайд-шоу. Да, я не шучу: на системе с Core i7-965 Extreme Edition с 6 гигабайтами ОЗУ и ускорителем Radeon HD 6850 играть невозможно вообще.

Если DirectX 11 отключить, а графические настройки откатить на пару уровней назад, играбельность возвращается. Но осадочек, мягко говоря, остается: если патч пробудил комплекс неполноценности у обладателя, прямо скажем, не самой слабой системы, можно только представить реакцию людей с «просто компьютерами».

Не поленился, проверил – вдруг после установки патча в Crysis 2 появилась поддержка действительно многоядерных процессоров. Куда там: как налегала игра на два ядра, не обращаясь к остальным, так все и осталось. Неважно, дорогой пользователь, что у тебя хороший CPU. Давай, чеши в магазин за новой видеокартой. И пусть она будет реветь, как слон во время брачного сезона, и греться, как веселый тульский самовар, зато сможешь увидеть объемные кирпичи в стенах. Извини за неудобства, но нам так улучшать привычнее.

Дорогой, безмерно уважаемый CryTek! То, что ты делаешь – это очень, очень важно для нас. Но временами создается ощущения, что мы любим тебя чуть больше, чем ты нас. Первого июля Intel проводит вебинар "Инструменты для разработчиков игр в действии". Так как раз будут говорить о том, как выявить причины ограниченной производительности приложения и выполнить детальный анализ и оптимизацию отдельных фреймов игры. Ну и о других полезных в данном случае вещах. Пусть его послушают твои русскоязычные сотрудники, расскажут остальным, и следующие патчи смогут улучшать игру, не вгоняя пользователей в комплексы и долги.

А пока пойду давать объявление об обмене Radeon 6850 на 6970 с щедрой доплатой.

Хорошо помню позднюю осень 2000-го. За окном моей иерусалимской квартиры было дождливо, тепло, а по вечерам иногда постреливали. Настроение было, что называется, разнонаправленным, но в целом все складывалось неплохо. В компьютере с основательно разогнанным Pentium III стояла видеокарта GeForce 256 DDR, и по тем временам это была неплохая конфигурация. Времени на компьютерные игры, в общем, хватало, потому что Интернет был довольно медленным, а соцсети еще не изобрели. И вот как-то раз я пришел домой с диском, на обложке которого была нарисована маленькая девочка с огромными глазами, как у котика из «Шрека». С той лишь поправкой, что «Шрек» тогда еще не вышел и никаких ассоциаций с котами оттуда не возникало. Называлась игра American McGee's Alice.

Надо сказать, что сам American McGee – мужчина очень суровый и склонный к непростым экспериментам над психикой. В ID Software он приложил руку к первым двум частям Doom и Quake, но там ему особо развернуться не давали, зато в Electronic Arts, куда он пришел на позицию креативного директора (красивая должность, кстати), по рукам никто не бил. И вот вышла игра про Алису, где в кислотной, но очень красивой игровой вселенной бегали персонажи Кэролла и с удовольствием уничтожали друг друга. Работало все на движке Quake III, который, в общем-то, слабо подходил для создания флоры и фауны, однако МакДжи смог превратить угловатость в своеобразный стиль, и выглядело все очень концептуально и законченно. А уж что вытворяла маленькая Алиса, вооруженная тесаком…

Игра продавалась неплохо, однако почти сразу после завершения работ над ней МакДжи ушел из Electronic Arts, а без него сиквела случиться не могло никак. Да я, честно говоря, и не думал о продолжении – уж больно штучный продукт получился. Прошел «Алису» до самого конца, и время от времени вспоминал о ней, как об игре, сделанной очень качественно, необычно и с душой. Пусть душа эта и подпитывалась странными материями.

Но вот в 2009-м сиквел внезапно анонсировали, а 16 июня сего года готовая игра Alice: Madness Returns поступила в продажу. По доброй традиции сооружать свой движок не стали, а взяли Unreal Engine 3. Стоит уточнить, что это не самая свежая версия, уже вовсю выходят игры на 3.5, однако МакДжи, видимо, испытывает слабость к раритетам.

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

Вообще, сделать из чуть странной детский сказки такое брутальное месилово – это покруче, чем по развеселой книге про балбеса Форреста Гампа снять историко-душещипательную мелодраму. МакДжи этот фокус удался дважды, и во второй раз, кажется, даже лучше. Особенно в игре хорош Чеширский Кот, которого явно рисовали с самого дизайнера игры. Ну и, конечно, мила сама Алиса, которая в момент гибели не лежит неподвижной кучкой текстур, а превращается в стаю синих-синих бабочек…

Серьезно, если в жизни осталось еще место для игр, купите новую Алису. В ней есть еще приятный бонус: грамотная поддержка многоядерных процессоров. Нагрузка пропорционально распределена по всем доступным ядрам, и в моем случае каждое загружалось не больше, чем на треть. Плюс, как и в Bulletstorm, грамотно загруженный CPU не доводил до изнеможения видеокарту, и та не перегревалась и не жужжала кулером даже через пару часов игры.

Каких еще приветов из прошлого ждать от игровой индустрии? Я бы, например, с удовольствием вернулся в мир Full Throttle, который, с учетом нынешних возможностей компьютеров, можно было сделать очень ярким. Главное, чтобы занялись этим не только денег ради (куда ж без этого), но и просто по велению души. Еще одного виртуального кадавра, коим сделали несчастного Дюка, сердце может и не выдержать…