Как обещал в день рождения, под тегом "тренд" буду писать всякие глупости про строительство коттеджа и переезд на ПМЖ в Подмосковье. Пока что писать особенно не о чем, поскольку продолжается препродакшен. Препродакшен включает в себя:

• согласование диздока получение документов и регистрация в инстанциях;
• скетчи, сеттинг и вижуал архитектурный проект. Занимаюсь этим последние 3 месяца, освоил казуальный Google SketchUp почти в совершенстве :);
• бюджет будщего строительства. К вопросу бюджета подхожу очень тщательно, поскольку у этого проекта нет издателя богатого дядюшки и рассчитывать приходится только на свои силы. Интересно будет сравнить в конце следующего года, что было запланировано и что в результате потрачено на строительство. К выбору middleware поставщиков приступлю после нового года.

По текущим планам, препродакшен будет продолжаться до марта следующего года, first playable, по которому можно уже будет угадать размеры, планировку и т.п. должен будет появиться к концу лета, альфа-версия проекта запланирована на осень 2010 года, бета-версия зависит от апрувалов разрешений на подключение к коммуникациям, и, как надеюсь, будет выпущена в конце следующего года. Мастер-версия должна появится весной 2011 года, в лучших традициях современного геймдева строительства потом будет аддон вторая очередь, в которую войдут: зимний сад, сауна, камин и исправление критических багов, найденных в мастер-версии :)

Про логи - завтра будет финальная часть.

Чтобы чуть-чуть отвлечься от ругани в комментариях про третью часть логов, напишу провокационно-отвлеченное. Опять про мои любимые синглетоны.

static Obj* instance() { static Obj obj; return &obj; }

_Winnie C++ Colorizer

Взглянем на ассемблерный код:

( Взглянем )

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

( Read more... )

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

1. Прошел игру. В тяжелой и длительной борьбе получил обе награды - "Дальнобойщик Года" (после цепочки долгих миссий раздавил бандитское логово и вернул Калифорнии покой и счастье) и "Золотой Перевозчик" (зохавал лидерство по грузоперевозкам и обложил всю Калифорнию своими офисами). Калифорния в игре получилась охрененно аутентична, вплоть до отдельно стоящих зданий и указателей улиц.
2. Отправили игру в печать. Ждите на прилавках страны 27.11, как и было обещано. Поздравляю всех-всех-всех причастных к проекту. Отдельное и самое огромное спасибо - команде разработчиков. Ребята, вы молодцы. Ура.

P.S. Если от нас с Мальцевым завтра на работе будет нести перегаром, не обижайтесь :).

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

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

( Read more... )

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

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

( Read more... )

Развивая тему анализа нестабильностей, которую я начал еще весной (http://ddima.livejournal.com/48573.html и http://ddima.livejournal.com/49288.html), оставалось рассмотреть нестабильности третьего рода - это собственные ошибки функции. То есть когда все наружные условия соблюдены, объект или модуль находятся в правильном состоянии, все переданные аргументы являются правильными, а результат работы функции все равно оказывается некорректным. Но как показала последующая практика, эти нестабильности полезно разделить еще на два независимых вида - это нестабильности, связанные с ошибками алгоритма, непроинициализированными переменными и т.п. (нестабльности третьего рода) и нестабильности, связанные с некорректной обработкой результатов функций (четвертого рода).

( Read more... )

Сегодня какой-то особенный наплыв спам-комментариев к записям. Вот последнее, что получил и не стал уже удалять, ибо надоело: http://ddima.livejournal.com/63713.html?thread=761057#t761057. Ссылка внутри ведет на bestbestbestxxx.blogspot.com/, щелкать что-то не хочется )))).

Вопрос в зал - как с этим в своем ЖЖ можно бороться?

Несколько замечаний про программирование. Частично раскрыто в других постах, но тут собрано все вместе. Частично противоречат друг другу (как например пункты 1 и 3) - в этом случае искусство проектирования как раз и заключается в том, чтобы свести вместе несводимое.
( Read more... )

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

Но фиг с ней, с работой. Сегодня не о том. Задуманная мною и родителями многоходовая комбинация с куплей продажей недвижимости (а это произошло еще в прошлом году), после череды договоров, подписаний, оформлений и прочего, совершенно удивительным образом (ничего специально к этой дате не планировал) завершилась сегодня, именно в день рождения. Именно сегодня я наконец-то приблизился к давней мечте - убежать из шумного и пыльного города на природу, и жить не в съемной квартире, а в собственном коттедже на своей собственной земле. Так что самому себе на тридцатишестилетие я сделал подарок, которым никогда в жизни себя еще не баловал - это несколько соток подмосковной земли :)))))))).

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

Как оно все сложится - не знаю, но надеюсь, что следующую дату (34.3) можно будет встречать уже за городом на постоянной, а не на временной основе :)

Мысль тривиальная, но тем не менее, регулярно реализуемая в играх с точностью до наоборот.

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

Почему разработчики в мастер-версии так любят оставлять текстовые XML файлы, да еще и с тормознутым парсингом (и это несмотря на наличие скоростных библиотек; за подробностями обращайтесь к zeux ) - для меня является загадкой. Впрочем, системы, например, проприетарного локкита с бинарными файлами данных и без всякой возможности смержить вместе выполненные в разных местах переводы на английский и немецкий - тоже уже воспринимаются устало-обыденно.

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

Играясь с прогнозом погоды от Яндекса, не поверил своим глазам. Как же мне сильно хочется туда, после того, как я два дня скакал по холодному и ветреному подмосковью! (наверное, хочется еще и туда, где еще теплее и море, но для начала вполне сойдет и Лодейка).

Предыдущий пост оказался очень неожиданным по результатам. И несмотря на то, что первый вариант действительно имеет в три с лишним больше промахов по кешу (и изучался он по быстродействию именно с предположения об ускорении bubblesort), основным результатом торможения неождиданно оказалось совсем не это.
Ближе всех к разгадке подобрался _winnie, который предположил влияние предсказания переходов (каюсь, изначально у меня и в мыслях этого не было).
Ну и точная проверка была проведена Сашой Лазаревым в лаборатории Интела (хотя его коммент по дате был раньше, чем у _winnie, он, к сожалению, был скрыт, пока я не добрался до компа). Действительно, основное именно дело в предсказании переходов. В свете этого интересно, можно ли аналогичным образом ускорить quicksort, как того хочет cppguru ?

Несколько интересных соображений, навеянных публикациями по dual-pivot quicksort.

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

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

Я обещал после чистки ресурсов рассказать про стабильные моменты в программе и контроль в процессе исполнения. balmerdx правильно написал и в коментах, и у себя в ЖЖ про слежение в процессе игры, только все же ИМХО не раскрыл тему до конца.

Основная мысль, которая заставляет переживать за проект - это не проблема memory leaks в конце. Memory leaks в конце чреваты только deinitialization hell, оставлением глобальных ресурсов винды и еще кое-какими мелочами. На самом деле гораздо более серьезная вещь - это операции, которые происходят в оперативке во время самой игры. Причем тем дальше, тем больше эта проблема начинает меня волновать даже на PC, потому что все чаще появляются падения игр при достижении предела 1.7 Гб аллокаций. Понятно, что повсеместный переход на x64 эту проблему снова нивелирует, но он не решит ее целиком.

( Read more... )

На прошлой неделе в комментах возникла еще одна стороняя дискуссия - про чистку ресурсов приложения при его завершении. Про memory leaks, надеюсь, даже вариантов нет - все согласны, что текущих (в смысле, регулярно возникающих в процессе работы приложения и постепенно жрущих память) memory leaks в игре быть не должно. Но вот надо ли чистить ресурсы при выходе или можно положиться на операционную систему? Есть несколько вариантов:

Опрос #1461419 Чистка ресурсов
Открыт: Всем, подробные результаты видны: Всем, участников: 81

Надо ли чистить ресурсы на выходе?

Так чистить или не чистить?

( Читать дальше после голосования :) ... )

Во первых, спасибо Алексею Буйницкому из 4A Games, который наконец-то надоумил меня в коментах, какого хрена я регулярно вижу в диффах sln/vcproj строчки "8.00" и "8,00". Вижу такое регулярно, но никак не приходило на ум, что это связано именно с разницей Regional Settings на компьютерах.

Во вторых, я совсем забыл отметить тот факт, что даже аккуратное использование char* не спасает, если у вас начинается микс CRT и STL функций. Потому что CRT работает как правило через ANSI вызовы WinAPI, а оно транслирует юникод через current thread locale. А вот попытка унификации STL функций привела к тому, что они зависят от setlocale() и CRT преобразования из ansi в unicode.

Поэтому у секвенции getcwd() -> fopen() гораздо больше шансов выжить в суровой операционной среде, так как их преобразование проходит через GetCurrentDirectoryA() и CreateFileA(), что приводит к единым правилам применения codepage.

А вот секвенция getcwd() -> std::ifstream проходит через GetCurrentDirectoryA() и mbstowcs_s() в CreateFileW(). Что будет работать только в том случае, если
а) результат getcwd() содержит только первую половину ASCII таблицы;
б) результат getcwd() содержит символы, которые совпали в текущих установках Windows Thread Locale и CRT setlocale().

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

( Read more... )

В пятницу президент России Дмитрий Медведев подписал указ об учреждении Дня программиста в качестве официального профессионального праздника. С чем и поздравляю себя и всех коллег по цеху! Ура!!! :)

Хотел по поводу праздника рассказать страшную историю из "рецептов отладки", но мне сегодня в 5 вечера, несмотря на праздник, предстоить лететь в очередную командировку, и я не успеваю с текущими делами. Поэтому напишу в четверг, уж извиняйте.

Давно уже пользуюсь сабжем, и даже стал иногда забывать взять с собой маршрутную квитанцию. Ну а зачем она нужна, если во всех нормальных аэропортах кроме первого Шарика (млять, ну когда же откроют Ш3???) достаточно протянуть паспорт или подойти к стойке саморегистрации?
Как тут в прошлый четверг случилось неожиданное. Полетели мы вдвоем в СПб. Туда - все без проблем. Обратно в тот же день в Пулково пытаемся зарегистрироваться, мне посадочный талон система отдает, коллеге - фиг! Начинаем разбираться - выясняется, что каким то хитрым раком система (или замотанная делами кассирша) выдала правильную маршрутную квитанцию, а вот на обратный рейс вписала только одного человека.
В общем, маршрутную квитанцию забывать не стоит. Может иногда сослужить хорошую службу.