Иногда книга начинается с одной статьи, опубликованной в нужный момент и в нужном Хабре и в моём случае всё действительно началось с публикации про аллокаторы, которая несмотря на обилие технического материала, кода и схем набрала больше всего плюсов среди моих статей на околоплюсовую и игродев разработку. А дальше и сам цикл Game++ постепенно вырос из отдельных технических размышлений о C++, архитектуре движков и производительности в связный нарратив. За спиной Game++ стоит еще больше узкотехнических материалов в блоге и вики моей компании и я бы рад ими поделиться, да и делюсь периодически, но сами понимаете выкладывать можно не всё и даже из то, что выложено на Хабре, частенько было подрезано, ибо NDA и секретные технологии-бла-бла-бла. Та статья стала точкой, когда я увидел, что разрозненные тексты на самом деле образуют скелет будущей книги, нужно лишь перестать относиться к ним как к «постам» и начать воспринимать как главы. Идея написать книгу не пришла просто так, и несколько не связанных между собой людей и компаний связались и предложили переписать цикл статей в виде книги.
Оглавление
А еще в процессе написания статей я всё чаще стал замечать, что возвращаюсь к одним и тем же вопросам — что такое «хороший» C++ в движке, где проходит граница между философией и промкодом, и в какой-то момент стало понятно, что формат статьи не всегда подходит и слишком много контекста остаётся за скобками, слишком часто приходится обрывать рассуждение, потому что текст уже и так получился «слишком длинным для Хабра», я смотрю на доскролы и обычно статьи не читают дальше 15 минут. Книга стала способом расширить и объём, и примеры и дать больше философии.
Для меня особенно важно, что это не книга «про игровой движок» в узком смысле, и вы можете взять нетленку Грегори и там будет нужная и важная теория по разработке движка. Да у меня очень много примеров из движковой разработки, работы с памятью, потоками, аллокаторами, строками, практики оптимизации и архитектурных компромиссов, но по сути это книга о C++ как о языке инженерных решений и о том, как думать категориями данных, временем жизни, и поведением кода на реальном железе, а давижок здесь только среда повышенной сложности, своего рода стресс-тест для языка, в которой хорошо видно, где концепции работают, а где лажают.
Отдельной частью этой истории стали люди, которые тоже стали частью книги - Анатолий Мамаев @Serpentine который подарил книге большую часть рисунков, Олег Сивченко@OlegSivchenko, который курировал работу с издательством bhv и Леонид Кочин, который мужественно редактировал и вникал в эту туеву хучу терминов. С Олегом и Антатолием общение постепенно вышло за рамки Хабра и книги, в более общие вопросы инженерной культуры, качества технической литературы, надеюсь я могу называть их своими друзьями и наше общение не закончится с выходом книги. Не менее ценным стало общение с Андреем Карповым@Andrey2008 c его помощью и компании PVS получилось провести несколько вебинаров, которые оказались своеобразной проверкой на прочность, потому что объяснять свои идеи вслух, в живом формате, где аудитория задаёт вопросы и ловит тебя на неточностях, это не текст с картинками. Несомненно многие фрагменты книги стали лучше именно потому, что до этого были проговорены на таких встречах. А еще ребята теперь помогают с переводом книги на английский, за что им отдельная благодарность, надеюсь всё сложится.
Ну и конечно, отдельное спасибо Хабру и читателям, без вас этого бы тоже не случилось и лично @boomburum, за то, что свёл с нужными людьми. Из всего процесса работы больше всего запомнилось не написание как таковое, хотя если оглянуться назад, то подбор материала занял около десяти лет, наверное с того момента, как я собственно и стал писать документацию и статьи, но редактирование - это совершенно другой вид обработки материала, и собирать разрозненные заметки, листы, салфетки, файлы и просто рисунки, написанные в разные годы и в разном настроении, и найти внутреннюю логику, ту самую «кость», на которой держится текст и которая проходит через всю книгу. И да, книга — это не сборник статей, а последовательность идей, где каждая следующая глава отвечает на вопрос, поставленный предыдущей, и пришлось многое переписать, что-то выкинуть, что-то переосмыслить. А еще надо было выровнять стиль, потому что даже статьи написанные одним человеком оказались очень разные по настроению, стилистике и подходу. Это было непросто и то, что есть в книге фактически уже четвертая итерация текста, и местами переписано почти полностью.
Книга не обязательно начинается с чистого листа, иногда она начинается с обработки на уже проделанную работу и вопроса «что если это не просто так?» и может вы вдруг обнаружите, что у вас уже есть не просто тексты, а позиция, не просто статьи, а взгляд на профессию. На удивление достаточно узко-специальзированная тематика получила хороший отклик на Хабре/Линкеде/Cоцсетях и пришло много вопросов, оставлю здесь частые, может кому будет интересно:
Q: Долго работали над книгой?
A: Почти 10 лет, если считать с момента сбора первых материлов для статьи про аллокаторы, год на подготовку статей, полгода на Game++ на хабре, еще год на черновик и работу с BHV
Q: Когда выйдет и где купить?
A: Вышла, в онлайн магазинах. Может @OlegSivchenko подскажет где она есть в физ доступе чтобы полистать и присмотреться
Q: Где купить в Европе?
A: Честно не знаю, посоветовали Boxberry, но я через него не заказывал книги.
Q: Будет ли электронная версия или только бумага?
A: Будет, позже.
Q: Почему остановились на bhv?
A: Так сошлись звезды
Q: Какой тираж?
A: 1000
Q: Почему так много страниц в итоге получилось?
A: Имхо наоборот мало, треть материала так и осталась за рамками.
Q: Нужен ли опыт работы с игровыми движками, чтобы читать книгу, или достаточно знания C++?
A: Желательно, но не обязательно. Большинство примеров действительно разобраны на примере из игр, но применимы везде.
Q: С какой главы лучше начинать, если уже читал цикл на Хабре?
A: Материал очень сильно переработан и доработан, половины на Хабре нет, думаю лучше с начала.
Q: Когда ориентировочно выйдет английская версия?
A: Честно, не знаю. Материала много и он непростой для перевода.
Q: Продолжите ли писать на Хабр после выхода книги?
A: А то (Нескучное программирование)
Q: Можно ли позвать вас на лекцию, семинар, вебинар?
A: Без проблем и даже нужно, но есть нюансы.
Q: Будет ли вторая часть?
A: Тут бы с первой разобраться, не думал еще.
Q: Cколько человек работали над книгой?
A: Тексты мои, рисунки по схемам и описанию делал Анатолий, еще порядка 20 человек имели доступ к черновику, оставляли комментарии и предложения, со стороны издательства я знаю пятерых, тут больше Олег расскажет.
Q: Как AI использовали для помощи (это видимо очень всех волнует, потому что я получил порядка 40 сообщений с этим вопросом) ?
A: Originality.ai для проверки фактов и материалов, Claude Sonnet для обработки и сведения схем, разбора фоток рукописного текста и салфеток, PaperRater/Advego/Corrector для синтаксиса и пунктуации.
Q: Как с вами связаться?
A: Хабр, Linkedin, Game++ в tg, Boosty, Stepik
Комментарии (23)
Serpentine
22.02.2026 20:02Дополню небольшим инсайтом про работу над черновиком Game++ уже со своей колокольни. Да, будет практически дубль с моим комментом в анонсе от издательства, но молчать опять не могу :)
С Сергеем познакомился на Хабре и, когда я летом прошлого года в комментах оффтопнул с наивным вопросом: «а где прочитать разное структурированное про оптимизацию? чтобы не метаться по всему интернету и не тратить много лет, собирая в своей голове всё это воедино», он мне в личке предложил посмотреть черновик будущей книги и позадавать вопросы, если я чего-то не понял из материала. Вопросов я назадавал вдоволь, да и своими комментами буквально заспамил весь черновик.
Там поначалу была только половина (около 250 страниц) материала и ASCII-схемы из статей одноименного цикла (можете их увидеть на Хабре). В некоторые схемы я не врубился и вызвался их перевести в вектор (пришлось вспомнить университетские навыки работы с CorelDraw), чтобы было и красивее и понятнее (даже мне). Как результат: два или три месяца работы по вечерам/ночам и около 250 иллюстраций. Они с виду простенькие, но над некоторыми пришлось поработать дольше, почитать доп.литературу, статьи, собрать референсы, чтобы как можно локаничнее, точнее, нагляднее и грамотнее передать суть.
Теперь впечатления непосредственно про книгу — она вдохновляющая, когда я читал о некоторых аллокаторах (их не было, в статьях на Хабре, если что), у меня временами взрывался мозг — "а что так можно было? кто такое вообще придумал?". Вот игрушка на первый облыжный взгляд простенькая, ну не крузис же, чего сложного-то? — а под капотом тройной стековый аллокатор, еще и на асме, чтобы на железе тех лет она не то что летала, а вообще работала — вы представляете этот уровень мастерства и любви к искусству?
Далее порадовала часть про STL и вредные советы по алгоритмам (а-ля "Вредные советы для C++ программистов" Андрея Карпова — тоже классная книга), потому что там
мне иллюстрации не надо было рисоватья познакомился с очень сильной аргументацией и дельными замечаниями от практикующего С++ разработчика, а не теоретика. Эта часть на меня сильное влияние оказала, что не надо выпендриваться и отказываться от возможностей языка и его библиотеки, когда некоторые «мэтры» считают иначе, ты код пишешь и в процессе важно его таки написать в разумный срок, чтобы работал и другие читать смогли, а не только самоутвердиться.Про аудиторию. Game++ — это не учебник и не руководство для совсем уж начинающих, т.е. с одной только этой книгой вы движок не напишете, предполагается, что на плюсах писать вы можете и хотите. Более широкие знания / направления можно почерпнуть из GEA Грегори вкупе с Game Programming Patterns Найстрома, да и у них идет столько отсылок на источники, что лет за 50 всё не перечитать. Game++ эти книжки хорошо дополнит — можно (или лучше даже) читать их параллельно.
А еще у меня, как у начинающего, эта книга развеяла иллюзии про оптимизацию кода, в голове раньше была какая-то радужная картинка, мол, вот крестами/матаном/CS овладею, паттерны повторю, где-то алгоритм со SO подрежу и буду вторым Кармаком — авотфиг! — тонну кода пересмотри / сам напиши, инструментом овладей, матчасть прочитай, мозг включи, опыта / насмотренности наберись, вот тогда будет счастье (но не долго, т.к. эта музыка будет вечной, и придется повторять процедуру раз за разом).
Ну и еще много чего полезного я вынес из Game++, и про архитектуру и обзоры движков (юнити, анрил, дагор, край энжин и т.д.), как, кем, для чего они писались, что авторы хотели, на что обращали внимание, и про аллокаторы и контейнеры: какие бывают, где их применять, как их разогнать, какие нюансы и подводные камни бывают. И еще вагон с тележкой про многопоточность и паттерны разработки.
Сергея и причастных еще раз благодарю и поздравляю с выходом книги. Рад, что удалось внести свою лепту в ее создание.
Mingun
22.02.2026 20:02Хм, была же уже в пятницу или четверг эта статья? Я правда прочитать не успел, открыл на работе, но руки не дошли. Но начало вроде то же самое.
dalerank Автор
22.02.2026 20:02Таже, просто не все из тех кто на меня подписан читают блог bhv, поэтому с разрешения издательства я утащил текст к себе. Ну и тут часть материала, которая появилась у меня уже после постов в bhv и на линкеде.
SolidSnack
22.02.2026 20:02Круто! Спасибо вам за проделанную работу, обязательно куплю, как минимум для общего развития)
QtRoS
22.02.2026 20:02Большое уважение за проделанную работу! Всегда открываю ваши статьи на Хабре, хотя на C++ не пишу уже довольно давно - обычно есть что почерпнуть и без языковой специфики.
P.S. Книжку купить не обещаю, но интересно было бы полистать, покрутить в руках. Это можно сделать где-то?
OlegSivchenko
22.02.2026 20:02Здравствуйте. Да, обязательно будет в сети "Читай-Город", в Москве ожидаю, что попадёт в "Библиоглобус" а в Петербурге с высокой вероятностью в "Буквоед" и "Дом книги" на Невском. Просмотровый экземпляр обязательно найдётся в офисе издательства "БХВ".
MasterMentor
22.02.2026 20:02Писать код проще, чем книгу...
С этим не поспоришь. А написать плохую книгу, куда проще чем хорошую.
Книгу можно взять тут (с)
"Взять" можно за 1980 руб и в бумажном экземпляре.
...Что б писать хорошие книги, автору следует научиться точности слов. Руский язык богат, в нём есть более точное слово "купить", нежели "взять".
"Причастный" и знающий человек (с) пишет:
Game++ — это не учебник и не руководство для совсем уж начинающих, т.е. с одной только этой книгой вы движок не напишете
Сергея и причастных еще раз благодарю и поздравляю с выходом книги. Рад, что удалось внести свою лепту в ее создание.
https://habr.com/ru/articles/1002546/#comment_29569994Количество страниц 592
Ключевые темы:
Архитектура игровых движков
Работа с памятью в компьютерных играх AAA-класса и других приложениях с высокими требованиями к производительности
Структуры данных языка С++
Работа со стандартной библиотекой шаблонов C++ (STL)
Обработка исключений
Неопределённое поведение и способы его предотвращения
Память и аллокаторы
Оптимизация в C++
Многопоточность
Классические паттерны проектирования применительно к разработке игрПо описанию вялые и невнятные темы.
Книга представляет собой сборник размышлений о языке... это не академическое исследование и не руководство к действию — это личный перечень наблюдений, пожеланий и претензий к C++. В книге описаны подходы к разработке игр, выработанные автором на основе собственного опыта.
(с) аннотация на сайте издателя
Может, всё-таки не стоило писать книгу?
Kano
22.02.2026 20:02А главное о игровых функциях в ключевых темах ни слова. Ни лодов, ни текстур, ни анимаций, ни звука, ни управдение, состояния, ии, модульность... Да даже про gameloop нет отдельной темы и про скриптовые языки
pavlushk0
22.02.2026 20:02Автор про аллокаторы достаточно полно изложил, уже за это можно купить (я так и сделал). Да и что вы хотите про лоды, тектуры и геймлуп (и остальное)? В книге упомянуто, хотите подробнее - ищите в более специальных источниках.
dalerank Автор
22.02.2026 20:02Определенно стоило, думаю опыт разработки и оптимизации AoE2, Sims, WarThunder, Metro, Deathloop, Stellaris и еще пары крупных проектов интересен многим. Не всем надо писать с нуля игровой движок. Заглянуть стоит в оглавление, там темы не такие вялые ;)
Serpentine
22.02.2026 20:02Заглянуть стоит в оглавление, там темы не такие вялые
Не успел тебе написать, но на сайте издательства действительно нет доступа к оглавлению. Считаю надо добавить обязательно.
DanielKross
22.02.2026 20:02Может не стоит хамить людям? Если вы думаете что так выглядите умнее/круче, то у меня плохие новости….
alkneu
22.02.2026 20:02>Q: Где купить в Европе?
>Q: Будет ли электронная версия или только бумага?
>A: Будет, позже.Посмотрел оглавление, очень жду! (лучше раньше, чем позже :D)
here-we-go-again
22.02.2026 20:02А какая ситуация с современным С++, за 10 лет которые писалась книга она не успела устареть?
dalerank Автор
22.02.2026 20:02Ну так там не про современный с++, а про базовые вещи, структуры данных, работу с памятью, строки, паттерны оптимизации. Это все мало связано с конкретным стандартом, если охота 20/23 стандарта - это уже отдельно, в нескучное программирование.
NickSin
22.02.2026 20:02Не всегда увидишь актуальную литературу на русском. Зачастую, всегда приходится искать англоязычные источники, так как пока до нашей адаптации дойдет проходит 3-4 года. Так что авторам уважения.
Поддержку денежкой, закажу себя в коллекцию на полку)
Bibest
22.02.2026 20:02Благодарю за столь ценную работу! Книга имеет огромную ценность. Говорю, как человек, только начинающий работать с физическими движками.
Книг по этой теме и так очень мало, к тому же, их возраст оставляет желать лучшего (не имею ничего против). А тут столько свежей и полезной информации, самое главное, основанной на реальной практике, так еще и на русском языке. Заказал сразу, как только прочитал оглавление. Браво!
Emelian
Не знаю, как насчет книги, но написать статью о разработке кода своей программы – явно, тяжелее, чем написать саму программу.
Хотя, в моем случае, при написании обучающей (иностранным языкам) программы «L'école», я себе чуть мозги не сломал, пока не довел её до, более-менее, рабочего состояния. Но, только теперь, через полтора года публикации ее первой версии, я, наконец-то, дозрел до размышлений: «А как «правильно» ваять код подобной программы, особенно, если делать это в команде, а не самому?». До статьи на эту тему еще далеко, но некоторые мысли вполне уже можно сформулировать.
Например, пришел к выводу, что прототип программы должен разрабатывать архитектор программы. Это должен быть работающий минимальный код, в котором весь потенциальный функционал реализован в виде формальных классов – модулей. В данном случае я имею в виду оконные приложения на С++.
Все формальные классы представлены своими публичными функциями, которые ничего не возвращают (обмен данными происходит через их параметры), за исключением обработчиков сообщений. Те возвращают стандартные значения LRESULT (TRUE либо FALSE), но, как и все остальные публичные функции имеют пустые тела.
Приватные части автономных классов (на уровне файлов это *.h и *.cpp модули) находятся в компетенции членов команды.
Далее, архитектор программы фиксирует вызовы формальных публичных функций в «модуле управления» (для оконных интерфейсов это, как правило, обработчики класса типа CMainFrame либо CMainWindow). Но, поскольку, эти функции – пустые, то их использование никак не проявляется.
На примере моей обучающей программы, основными, независимыми друг от друга модулями, являются: класс для работы с чтением / записью текущего состояния приложения, класс логирования, классы для работы с графикой, текстом (отображение и редактирование), звуком и данными, классы вспомогательных окон («О программе», «Помощь», «Настройка» и прочее) и т.д. и т.п.
Для всех этих классов архитектор дает их формальную реализацию. Затем раздает копии своего проекта всем членам команды и говорит, кому, какой модуль реализовывать. Такой подход позволяет достаточно просто организовать коллективную работу без использования внешних систем контроля версий, вроде, гита.
Члены команды доводят до ума свои модули и передают их архитектору. Он замещает формальные модули – их полными версиями и тестирует общую реализацию. При необходимости вносит коррективы в работу команды.
При таком подходе члены команды могут работать удаленно и иметь минимальный конфликт интересов, о которых шла речь в статье.
Я даже не знаю, нужен ли, в таком случае, тимлид либо техлид. Наверное, да, для больших проектов. Но, для группы из нескольких программистов, думаю, без последних можно обойтись. В таком случае, архитектор «пишет» код прототипа либо ваяет его по принципу конструктора модулей.
Таким образом, используя модульное программирование либо итерационно-модульное (где предыдущие итерации, собственные для «своего» модуля каждого программиста, фактически являются просто бэкапами), можно, как мне кажется, упростить работу команды. Зато, основная нагрузка ложится на архитектора. А члены команды могут даже работать независимо друг от друга.
Однако, возможность «легко подключить модуль к проекту» (путем простой замены формальной реализации – полной) и «легко отключить модуль от проекта» (соответственно, наоборот, заменяя полную реализацию – формальной), позволяет, со временем, накаливать потенциальные модули для будущих проектов. Что дает возможность быстро создавать новые прототипы для новых проектов, аналогичного типа.
По сути, в идеале, мы получаем этакий конструктор для будущих программ.
Например, у меня есть неопубликованная программа «МедиаТекст».
http://scholium.webservis.ru/Pics/MediaText.png
Вместе, эти две программы, явно, могут иметь общие модули. При этом, в последней используются потоки и опенсорсный видеоплейер, для которых можно создать свою формальную реализацию.
Вот, приведение уже только этих двух программ к общему модульному типу (к ним можно добавить и мою третью программу – загрузчик «MiniDL» для любимых видосиков, которая опубликована здесь), позволит создать хорошую базу прототипов для будущих проектов данного типа задач. После чего можно будет уже спокойно предлагать себя в роли архитектора на похожую работу :) .
Но, даже если программировать только для себя на уровне пет-проектов, то данный подход кажется перспективным, по крайней мере, я перестану забывать программную логику своих давно написанных программ и смогу спокойно модернизировать их до новых версий. Чем и собираюсь заняться, в ближайшее время.
Как-то так.