Приветствуем, Хабр.

Врываемся в новую неделю с обширным интервью от Сергея Кушниренко @dalerank автора одной из лучших наших книг 2025-2026 года: "Game++. Устройство и оптимизация игрового движка". Сергей ведёт на Хабре отличный блог, а также создал сайт https://dalerank.github.io/, на котором выкладывается более глубокий и обширный контент, чем обычные лонгриды в формате Хабра. Под катом Сергей ответил на наши вопросы, рассказал о своём подходе к профессии и искусству программирования, языке C++, своей прекрасной дебютной книге, а также о новой книге "Прагматичный C++", которую только что сдал в редактуру.

Добро пожаловать под кат

1. Расскажи о себе, твоей текущей работе, опыте написания статей на Хабре

Я разработчик, с джуна добрался до должности техдира, писал на разных языках от ассемблера до С++и Js, начинал с разработки гидроакустических станций, последние пятнадцать лет занимаюсь разработкой игр. В игровой разработке успел поработать над разными проектами, от инструментов для разработчиков до портирования игр на консоли и оптимизации производительности. В основном специализируюсь на C++, работе с памятью, устройстве движков и всём том, что обычно находится за пределами непосредственно игрового процесса, но без чего он довольно быстро перестаёт работать так, как задумано.

В разработке игр меня всегда интересовала возможность реализовать что-то новое, почему одни решения работают лучше других и какие последствия возникают, когда мы выбираем определённую архитектуру. Первые статьи появились в 2014 г, что накопилось достаточно материала во время восстановления старенького ситибилдера Caesar III, которым хотелось поделиться. В какой-то момент понимаешь, что многие проблемы, с которыми сталкиваются разработчики, вовсе не уникальны и большинство наступают на одни и те же грабли, просто в другой компании и на другом проекте. Было бы неплохо оставить после себя хотя бы описание этих граблей, чтобы другие могли наступать на них более осознанно.

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

2. Как пришла идея писать книгу, как ты искал контакты с издателем?

Я думаю, книга редко начинается с решения написать книгу, по крайней мере, у меня никогда не получалось писать что-то большое сразу. Сначала появляется тема, вот как с последними статьями, про "некоторые поблажки игрокам" в играх, тема не помещается в одну статью, потом обнаруживается, что для её объяснения необходимо рассказать ещё о нескольких вещах, потом оказывается, что и эти вещи тоже требуют отдельного объяснения.

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

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

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

3. Какие книги по C++ на тебя повлияли? По каким книгам можно изучить C++, прежде, чем читать твою книгу?

Я не знаю, как ответить, я просто беру понравившиеся по обложке и начинаю читать. Если первая треть не вызывает желания пойти поспать и грусти по утраченным шекелям — значит книга хорошая :) Автор может прекрасно знать синтаксис C++, разбираться в шаблонах, и при этом написать ужасно скучную книгу. Поэтому мне не все книги дяди Боба нравятся, какие-то я дочитывал просто усилием воли.

Из книг конечно Страуструп, лучше в английском издании, неважно какая, но лучше что-то из современного. В последнее время я меньше обращаю внимания на сами примеры и больше читаю про философию языка, еще мне понравилась «C++ Primer» Стэнли Липпмана. Очень люблю статьи и книги Александреску, вот уж кто действительно умеет рассказывать интересно про скучные вещи так это он, он вообще редко рассказывает про какие-то базовые вещи, больше про всякую дичь, которую можно творить с языком.
Для тех, кто уже пишет на C++ и хочет лучше понимать, как пользоваться языком, могу порекомендовать курсы и книги Константина Владимирова, как минимум будет нескучно, и заодно вы поймете что С++ вы не знаете. Мейерса как-то не очень люблю, автор заслуженный и отличный практик, но сами книги не заходят.

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

4. Расскажи, о чём и для кого твоя книга "Game++. Устройство игрового движка"

Что касается моей книги, то здесь важно понимать её назначение. «Game++» это не учебник по C++ и язык там рассматривается в контексте инженерных задач, когда надо построить систему, которая будет работать в условиях ограниченных ресурсов. С++ там потому я знаю его лучше других, там вообще может быть любой язык и необязательно знать тонкости языка, но желательно уже сталкиваться с задачами, в которых выбор структуры данных или способа управления памятью начинает влиять на результат.

На днях ребята из DeepL, originalityAI и мою коллеги помогли допереводить книгу на английский и можно её будет купить на Amazon или через Patreon, часть книги для ознакомления можно посмотреть тут: dalerank.github.io.

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

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

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

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

5. Какова роль примеров с кодом в технической книге, как подбирать листинги?

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

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

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

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

6. Как ты относишься к идее "Пиши, сокращай"? Было ли ощущение, что многое из твоих идей осталось в черновиках?

К подобным рекомендациям отношусь спокойно, половина книги Game++ так и осталась в черновиках, и потом я опубликовал несколько статей на Хабре по ним, так что сокращать текст ради самого сокращения не менее бессмысленно, чем увеличивать его объём ради увеличения объёма. Если убрать из технического объяснения отступления, примеры и рассуждения, можно получить очень компактный текст, который перестанет выполнять свою основную функцию и станет просто справочником. Интересно ли читать справочники отдельный вопрос, мне - нет.

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

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

7. Как ты считаешь, в технической книге важнее излагать общие принципы или описывать примеры и рецепты?

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

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

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

8. Как ты относишься к языку Rust? Рекомендуешь ли ты специалистам по C++ изучать Rust, если да, то по каким книгам?

Нормальный, современный, интересный язык, как и десятки других. Фразу про плохие языки напомнить? Не пишу на нем.

9. Расскажи, какие сложности и интересные моменты возникли при работе с редактором?

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

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

Работа с редактором для меня, прежде всего, была возможностью посмотреть на собственный текст со стороны.

10. Как изменилась твоя профессиональная жизнь после того, как была издана твоя книга?

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

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

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

11. Как человеку понять, что он пишет в стол, и пора выходить на контакт с издательством?

Не знаю, сложный вопрос, не могу ничего посоветовать, наверное не писать в стол.

12. Расскажи, о чём твоя новая книга.

Книга изначально называлась «Нескучное программирование» и опять же черновики были выложены на Хабре, потом проектник издательства "БХВ" Олег Сивченко @OlegSivchenko предложил «Прагматичный С++». Она не об устройстве игрового движка, хотя между ними есть определённая связь и много примеров там построены на разных игровых кейсах и задачах, но и скатываться в очередной учебник по С++ и пересказ сайта cppreference тоже как-то грустно и непродуктивно.

Поэтому я ушел в более фундаментальные вопросы из разряда "что вообще происходит, когда мы программируем"? Обычно изучение программирования начинается с языка, и мы узнаём, как объявлять переменные, писать функции, создавать объекты, использовать циклы и условия, потом осваиваем библиотеки, инструменты и все более сложные конструкции.

Это нормальный и естественный путь, но человек довольно быстро учится писать код и не всегда успевает разобраться в том, что именно он создаёт. Что такое объект не только с точки зрения синтаксиса языка, но и с точки зрения его смысла? Или что означает существование переменной? Или как связаны типы, значения и память? Что происходит между записью исходного кода и выполнением программы? Почему одни способы организации кода позволяют строить сложные системы, а другие довольно быстро приводят к проблемам?

Я хотел поговорить об этих вещах. Как я уже сказал, книга не задумывалась как очередной учебник по синтаксису C++, он там есть и новички даже смогут по нему начать программировать. В тоже время я старался показать, что фундаментальные вещи могут быть интересными сами по себе, если не превращать их в перечень определений, которые необходимо запомнить перед экзаменом.

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