Spiiin's blog

О книгах и самообразовании

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

Как я читаю книги

Читать техническую литературу “от корки до корки”, на мой взгляд, не правильно и не эффективно — часто необходимо отвлекаться, делать заметки, изучать дополнительные материалы, прямо или косвенно упоминаемые в книге/статье/докладе, пробовать экспериментировать с кодом. На первый взгляд, такой способ работы увеличивает время изучения, но, в длительной перспективе, наоборот, ускоряет понимание материала.

Прежде, чем начать детально “прорабатывать” книгу, очень эффективно оказывается просмотреть её бегло по диагонали, чтобы примерно представить себе содержимое. Не знаю, есть ли у такого подхода официальное название, поэтому называю придуманным термином "метод спирали" (по аналогии с “спиральным методом разработки”):

  • Сначала просматривается оглавление и пролистывается вся книга “по диагонали”, с рассматриванием картинок, можно понять про что вообще книга и её структуру
  • Если что-то сильно заинтересовало, можно сразу остановиться и изучить материал детальнее
  • Полезно затем поискать отзывы и краткие пересказы глав книги, если можно найти их, на популярные книги не представляет сложности, иногда также автор сам рассказывает о книге на каких-нибудь конференциях или докладах
  • Если что-то непонятно, или хочется глубже раскопать тему, то сразу стоит поискать дополнительную литературу. Это поначалу кажется очень большим увеличением объёма работы, но если изучать книги на какую-либо тематику, то понимешь, что они часто ссылаются на одну-две основные, после изучения которых все остальные станут или простыми и понятными, или вообще ненужными, так как не добавляют новой информации
  • Если нет подходящей литературы, можно поискать дополнительную информацию в других книгах того же автора, его сайте, докладах или в его соцсетях (иногда можно просто взять и спросить в e-mail или твиттере “а что вы тут имели ввиду ваще?” - это работает чаще, чем кажется). Если автор не оставил никаких следов, можно попробовать найти заинтересованных людей, и обсудить это с ними

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

  • Насколько полезно будет изучить книгу, какие-то на этом этапе можно отбросить, какие-то заставят добавить в свой список для изучения дополнительные 2-3 книги
  • Если уже знаешь >70-80% материала, который излагается в книге, то изучать её внимательно нет смысла, это будет просто скучно, можно просто пролистать, немного заполнив пробелы в знаниях или в поисках занимательных мелочей. Какие-либо новые навыки вы из такой книги не получить
  • Если знаешь менее 10-20% материала, изложенного в книге - скорее всего она окажется слишком сложной, придётся слишком часто отвлекаться на поиск дополнительной информации и практику, и будет читаться медленно.Лучше попробовать сначала изучить что-то проще
  • Идеально и наиболее быстро усваивается материал, которой получен из книги, известной где-то на 40-50%. В этом случае, скорее всего либо уже пробовал похожее на практике, либо обдумывал и приходил к схожим идеям, так что часто нет необходимости проверять и пробовать каждую изложенную идею

Информационная энтропия

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

Очень эффективно читать одновременно 3-4 книги. Как минимум 2 на исследуемую тему и 1 на отвлеченную. Пересекающиеся факты из двух книг улучшают запоминание материала, за счёт перекрёстных ссылок, а книга на другую тему позволяет “отдыхать” от однообразного материала, при этом продолжая изучение в одном из желаемых направлений.

Для улучшения запоминания материала полезно вести заметки, кратко конспектируя определенную тему, с перекрёстными ссылками на материалы (метод Zettelkasten и Obsidian как система ведения заметок — бесплатная, расширяемая плагинами, данные хранятся локально в виде текстовых файлов, обзор всей сети заметок в виде графа).

Этот же алгоритм можно применять не только к книгам, но и статьям, докладам, презентациям etc.

Как заставить себя изучать такое количество материала

Естественно, чтобы выполнить такой большой объём работы, необходима сильная мотивация. Например, заставить себя поверить в то, что от изучения зависит твоя карьера/успешность. Как в универе, когда нужно быстро подготовиться к сессии ненормальными темпами. Без этого мозг тупить будет, и учиться не получится.

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

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

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

Основной вопрос, который я задал себе — "Как делать игры быстрее, качественнее и успешнее?". Основной стимул, чтобы спросить себя об этом — желание понять, почему разные компании делают игры различного уровня, и как получается, что команда из 100 человек может сделать за тот же период больше, чем команда из 1000 человек (разницу в 10 раз сложно списать на то, что в более производительных компаниях каждый сотрудник в 10 раз лучше, чем у конкурентов). А также осознание собственных пробелов в знаниях в разработке игр, несмотря на то, что я занимаюсь этим уже много лет, вариант синдрома самозванца.

Ещё одно желание - лучше понять рынок, на котором зарабатывают деньги компании, в которых я работал и работаю (и, вероятно, буду работать). Вопрос об уровне понимания рынка также можно сформулировать более прагматично, “Если я буду делать то же, что и сейчас, где я окажусь через 10 лет?”, или, более правильно, "Что я должен сделать сегодня, чтобы через 10 лет оказаться там, где я планирую оказаться?".

Я понял, что люди боятся задавать себе такие вопросы по банальной причине, у них нет ответа на намного более простой вопрос - “Хочу ли я заниматься тем, чем занимаюсь, через 10 лет”. Если скрываемый ответ на него - “нет, я мечтаю совсем о другом”, то любые попытки планировать на длительный срок провалятся. Очень сложно планировать то, чего втайне пытаешься избежать. Из-за этого люди так редко могут заниматься планированием собственной смерти, хочется увиливать от этого вопроса, обманывая себя тем, что ещё не время думать о том, чего не желаешь. И, наоборот, уважение других к тем, кто планирует собственную смерть, базируется на предположении других людей о том, что человек, занимающийся планированием, или хочет умереть, или не боится смерти настолько, чтобы не прятать свои мысли и планы об этом.

Мы все немного боимся неизвестности будущего, но каждый из нас окажется в точке “через 10 лет”, просто кто-то придёт туда с закрытыми глазами, а кто-то — с предположениями о том, через что ему предстоит пройти. Тот, чьи предположения более качественны, будет в лучшем положении, чем тот, кто идёт вслепую, или тот, чьи догматические представления устарели, потому что мир изменился. Это не какие-то высокие красивые пафосные речи, а простое желание жить и работать качественно и комфортно.

Все люди умеют мыслить, но мышление происходит только в рамках усвоенного понятийного аппарата — рассуждения о заработке денег закончившего 9 классов классов выпускника будут отличаться от успешного 23-летнего сениора-программиста (хотя их рассуждения о политике, например, или о прививких от коронавируса, могут находится на одном уровне). Нейронная сеть, обученная на неверных данных, будет давать неправильные результаты. Обучение, во многом - это усвоение новых понятий, чтобы позволить себе производить операции над новыми данными. Однако, с чем пока не справляются искусственные нейронные сети, это осмысление полученного ранее материала, и отброс “мусора”, хранимого в голове. Иногда цель обучения — позволить себе обнаружить мусор в собственной голове.

Зачем заниматься самообразованием

Кроме перечисленных выше идей, полезно расширять знания, чтобы:

  • Изучить прошлое, почему какая-либо вещь сделана так, а не иначе, и какие были альтернативные варианты решения
  • Изучить настоящее — разобраться с тем, какие вообще решения есть на рынке, чтобы иметь возможность аргументировано выбирать из доступных вариантов, а не пользоваться теми, которые “выбирают все” (если используешь решение, которое выбирают 99%, то навряд ли сможешь обогнать 99% участников рынка)
  • Изучить будущее. Понять, что сейчас обсуждают лучшие, и почему они обсуждают именно это. Отчасти, чтобы понять, “куда дует ветер”, и куда будут вкладываться ресурсы, отчасти чтобы понять, правильно ли то, что делаешь ты (если ты собираешься идти по альтернативной дороге, то нужно понимать, собираешься ли ты идти по ней, потому что знаешь что-то, чего не знают другие, или потому, что не знаешь чего-то, что уже знают все)
  • Прокачать мозг. Если давно не изучал ничего нового, есть риск того, что мозг просто отвыкнет это делать. В этом случае полезнее учить что-то максимально отличающееся от того, что уже знаешь
  • Расширить кругозор. Во многих трудоемких производствах специалисты узкоспециализированы настолько, что могут плохо понимать друг друга. Иногда настолько, что для налаживания контактов между ними нанимается отдельный человек. Пример из геймдева: технический артист, как посредник между 3д-артистами и программистами. В разработке игр иногда программист — слепой исполнитель идей геймдизайнера, что не всегда приятно как для дизайнеров (== проектировщиков игры), так и для программистов
  • “Выйти” на идеи действительно крутых людей, которые не будешь понимать без определенной базы. Примеры: по цепочке “Nim->Smalltalk” я обнаружил идеи Алана Кея, а по цепочке “Архитектура движков от Naughty Dog -> Scheme -> Racket” - эссе Пола Грэма. И Кей, и Грэм — культовые персонажи в мире IT, однако шанс понять, о чём они пишут, а не просто принимать на веру их идеи, немного больше, если имеешь некоторый фундамент
  • Нафаршировать голову полезными сведениям. Иногда не знаешь заранее, какие знания могут понадобиться, и где можно найти ответ на интересующие вопросы. Изредка получается, что ответ находится случайно (“серендипные” открытия), так что общая эрудированность может оказаться полезной для решения узкоспециализированных проблем. Отличие самообразования от фаршировки головы в универе — полезные знания не требуется зазубривать, иногда достаточно просто того, чтобы они сидели где-то в подсознании
  • Систематизировать знания. Программисты часто являются самоучками, из-за чего часто даже опытные могут иметь пробелы в определенных областях, особенно в тех, которые напрямую не касаются специализации. Особенно много пробелов встречается там, где встречается много Rule-of-thumb, превращающихся со временем в мифы (к примеру, оптимизация кода). Самоучкам тяжелее пересмотреть собственные взгляды из-за того, что исследованное самостоятельно воспринимается более “правильным”, чем чужие идеи
  • Оставаться конкурентоспособным. Если ваша команда/компания использует технологии, которые позволяют делать что-то, что не могут конкуренты, то скорее всего ваш продукт будет иметь фичи, которых не будет у конкурентов

"Саморазвитие"

Желание саморазвития само по себе — дурацкий стимул для самообразования. Попробую объяснить, почему так считаю. Во-первых, “саморазвитие” — часто просто эвфемизм для желания стоить больше, как специалист. Это неплохо само по себе, но сейчас возводится в культ в различных компаниях. Я не до конца понимаю, почему компании воспитывают взаимоотношения с программистами, как к наёмниками. Возможно, просто подстройка под моду на самоидентификацию свободного человека (“я свободен, потому что не привязан, и в любой момент могу уйти работать туда, где предложат лучшую зарплату”), или же удобнее для компаний (найм стоит дешевле, чем формы совладения).

Со стороны компаний — ни разу не видел, чтобы “бюджет на саморазвитие”, или “ценим и поддерживаем стремление к саморазвитию” выражалось в том, что предлагали оплату за изученный материал. Максимум подразумевается компенсация за прохождение курсов начального уровня или возмещение поездок на конференции (но тогда лучше так и писать в объявлениях о найме, будет понятнее и привлекательнее). Часто также со стороны компании под саморазвитием подразумевается прокачка только софт-, а не хард-скиллов.

Главная проблема — с определенной фазы роста, возможно ли, что программиста или руководителя удержит только его зарплата? Нужны ли компании руководители, выросшие с идеей и привыкшие к тому, что их взаимоотношения с компаниями строятся по принципу “работаю там, где больше платят”?

В эссе Пола Грэма “Первоклассные хакеры”, есть много тезисов о том, что денег недостаточно, чтобы привлекать высококлассных специалистов (так же, как недостаточно фразы “у нас есть бесплатный кофе и печеньки”). Более привлекательными являются возможность решать интересные задачи, а также работать в коллективе таких же высококлассных специалистов (про это — эссе Города и амбиции). Ценит ли самый лучший специалист возможность саморазвития в таких условиях? Вообще нет, ценится качество общения с коллегами и возможность решения таких задач как самоцель. Хакер подсознательно избегает решения скучных задач, как манекенщица избегает употребления чизбургеров, но возможность решения сложных задач для него — это жажда удовлетворять собственное любопытство, он не думает о саморазвитии, так как это отдаёт тщеславием, которое отупляет не меньше, чем решение скучных задач (“скучные” тут — задачи, решение которых настолько несистематическое, что не даёт возможность сделать каких-либо обобщений). В какой-то степени, для лучших специалистов, качество решаемых ими задач является мерой качества их жизни. Нет какого-либо “развития” в вакууме, есть уровень сложности и количество сложных задач, решённых специалистом. То есть, если приобретение знаний нужно для поиска решения какой-либо сложной задачи (или же, для правильного переформулирования сложной задачи) — это достойная для хакера цель (это не “саморазвитие”, это естественная потребность искателя решения), если же поглощение информации используется как самоцель — это пустая трата времени.

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

В русской IT-культуре происходили процессы, сформировавшие определённое мировоззрение “олдфагов” (хорошо описаны в докладе Евгения Кота, Мама, мы все тяжело больны, ссылка на тайминг, другие его доклады тоже неплохи, сборник по ссылке). Одна из проблем, которую он описывает в докладе — культ роста, о котором я пишу тут, но я хочу сослаться на описание того, как формировалась IT-отрасль. Какое-то время в IT не было случайных людей, и работать программистами приходили фанатики. Это ещё более актуально для геймдева, где по большей части зарплаты ниже, чем “в среднем по больнице”. Сама специфика разработки игр привлекает фанатиков, и программисты чаще — не наёмники, а творцы, одержимые результатом. Часто в разработке игр именно это творческое желание сделать отличную игру является необходимым условием для того, чтобы игра получилась хорошей. Если взять какую-нибудь книгу типа "Кровь, пот и пиксели", то, даже, с поправкой на небольшую художественность, видна тенденция к легкой маниакальности творцов (что ближе к саморазрушению, чем к саморазвитию), необходимой для создания шедевров. Индустрия ищет пути создания хитов без боли, но пока не нашла.

Ещё один аргумент против “саморазвития” как цели — с возрастом всё меньше людей мотивируются именно этим. Я не считаю, что у молодости или зрелости как возраста самого по себе есть какие-либо преимущества, но если данный стимул совсем не работает для людей определенного возраста, то, возможно, это маячок о том, что это ложная ценность. Чем обычно заменяется желание саморазвиваться у более взрослых программистов? Более прагматичным желанием больше зарабатывать, комфортом (иметь возможность больше отдыхать, беречь здоровье, проводить время с семьёй, заниматься хобби). Возможно, самообразование на перспективу 10-15 лет должно быть стимулировано чем-то, что в перспективе приводит именно к таким возможностям.

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

Гигиена

Про желание работать комфортно я расписывал подробнее в посте Мотивация "честного" программиста. Во всех компаниях достаточно различного треша, связанного с тем, что всё нужно было сделать быстро, а денег вначале мало, но с какого момента в некоторых компаниях волшебным образом всё становится немного лучше, чем в других. Все хотят работать там, где хорошо, но кто и в какой момент превращает “плохо” в “хорошо”?
(если кратко, то порядок трансформации мышления с моей точки зрения такой: честность с собой -> гигиена -> экономия времени -> работа на результат -> икигай)
Такая трансформация тоже требует работы над собой и самообразования, и служит одним из главных стимулов становиться лучше в личном и профессиональном плане — что может быть лучше, чем повысить качество жизни и работы себе и окружающим?

Список книг по темам

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

Гейм дизайн

Сборник книг и материалов - Путь гейм-дизайнера

Большая тройка книг по “классическому” гейм-дизайну:

“Джесси Шелл - Геймдизайн” - самая крутая книга по гейм дизайну, меняющая отношение к разработке игр. У автора есть также несколько очень интесных докладов на различные тематики, от будущего разработки игр, до организации игровых компаний.
“Костер Р. - Разработка игр и теория развлечений” + блог автора
“Cильвестр Т. - Геймдизайн. Рецепты успеха лучших компьютерных игр”

“Lovell N. - F2PToolbox”, “The Pyramid of Game Design Designing” - очень важные книги по Free-to-Play геймдизайну.
Суперфанаты - небольшая выдержка одной из глав, а также несколько статей на схожую тематику.

“Роджер С. - Новый уровень!”,
“Game Design Vocabulatory”,
“Adams E. Dormans J. - Fundamentals of Game Design”, “Game mechanics - Advanced game design”,
“Fullerton T - Game Design Workshop”,

“Salen K., Zimmerman E. - Rules of Play Game Design Fundamentals/Anthology” - большая пачка статей с различных сайтов

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

“Коплиен Дж. - Программирование на C++” - книга об идиомах раннего C++, можно почитать для фанатов истории.
“Страуструп Б. - Дизайн и эволюция C++” - история о том, почему C++ такой, какой он есть, и как работает комитет по стандартизации.
“Реймонд Э. - Искусство программирования для Unix”
C++ Core Guidelines
More C++ Idioms - сборник идиом на C++, много устаревшних, но некоторые полезны для понимания кода из STL и Boost.

“Lippman - Inside the C++ Object Model” - устарело, лучше почитать что-нибудь типа Itanium C++ ABI
“Scott Meyers - Effective STL” - по большей части устаревшие советы Мейерса по STL, в дополнение к его более известным книгам из серии “Effective”.

Доки по Nim, Racket
“Stanford LISP 1.6 Manual” - классический мануал по старому лиспу, ради примера на 13-й странице (интерпретатор лиспа на лиспе)
Заметки о языках программирования - сборник материалов по языкам

Многопользовательские игры
Шпаргалка по разработке MMO - различные материалы
Доклады и интервью Максима Барышникова из Wargaming по устройству их игровых серверов
Доклады по устройству серверов Toontown от Disney, сетевому коду файтингов Mortal Kombat/Injustice, Overwatch
Документация к Photon

Программирование игр
“Джейсон Грегори - Игровой движок” - азбука для того, чтобы начать разбираться в движках. Пара тем освещены более детально (скелетная анимация, система задач для игр). Must read, если ещё нет опыта ковыряние с 1-2 движками, иначе — полезно как сборник доп ссылок или для систематизации знаний. Также несколько инсайдов об тулзах, используемых Naugty Dogs. Интересно посмотреть доклады про внутреннее устройство самой компании, а также несколько докладов про использование ими Lisp в играх, и тулзах (Data compiler).

“Robert Nystrom - Game programming patterns” - хороший сборник паттернов в геймдеве, так или иначе встречающихся почти в каждой игре/движке, уникальная по тематике книга.

Cборник статей на различные темы - Gamedev-ссылки

Разработка ПО
“Физерс М. - Эффективная работа с унаследованным кодом” - на мой взгляд более общая и полезная книга о рефакторинге, чем известные книги о шаблонах (которые, вообщем-то, азбука для разрботчиков, которые много работали с различным кодом).
“Фаулер М. - Рефакторинг - улучшение существующего кода” - классика, пролистал немного вспомнить содержимое.

Немного покопался в идеях XP, Scrum, Agile и прочих не очень любимых некоторыми программистами слов в поисках полезных методов.

“Кент Бек - Экстремальное программирование” - устаревший материал, историческая ценность посмотреть, с каких идей всё начиналось.
“Кент Бек - Экстремальное программирование. Разработка через тестирование” - более новый подход, больше о важности тестов и невозможности безопасно изменить старый код и внедрять практики CD без него.
“Книберг Х. Скаррин М. - Scrum и Канбан - Выжимаем максимум” - сборник подходов из различных методологий.
“Мартин Р. - Идеальный программист. Как стать профессионалом разработки ПО” - скорее сборник эссе том, как применять XP. “Чистый код”, “Чистая архитектура” и “Чистый agile” - все о том же, рассказы с расмазанными по ним общими полезными идеями.

“Эванс Эрик - Предметно-ориентированное проектирование (DDD)”, “Вон Вернон - Предметно-ориентированное проектирование” - кажется, немного банальные вещи о том, как проектировать программы.
“David W. - Object Thinking” - рекомендованная книга по Object Oriented Design.
“Fabian R. - Data-Oriented Design” - подход к ECS.

Cборник материалов - Прототипирование в геймдеве
Cборник материалов - ECS. Ссылки

Бизнес
“Эрик Рис - метод стартапа”, “Бланк С. - 4 шага к озарению”, “Рис Эрик - Бизнес с нуля. Метод Lean Startup” - много полезной информации по методу развития продукта Lean development.
“Nicholas Lovell - The Curve - How Smart Companies Find High-Value Customers” - понимание бизнес-модели free-to-play и freemium, есть дополнительные доклады и сайт.
Ещё немного о командах:
“Кэтмелл Э. Уоллес Э. - Корпорация гениев”, доклады про устройство Valve, Supercell, Unity, про бирюзовые организации.
“Клейтон М. - Дилемма инноватора”.

“Коллинз Дж - От хорошего к великому”, “Построенные навечно”, “Великие по собственному выбору” - попытка выделить правила для руководителей успешных компаний. Также иногда просто полезные правила для жизни.
“Erika Hall - Just Enough Research”, есть доклады от автора по книге

Cборник материалов - Метод Lean Startup

Проектирование, дизайн

“Кристофер Александер - Язык шаблонов”

“Купер К. - Психбольница в руках пациентов” - взаимоотношение программистов и проектировщиков программ.
“Норман Д. - Дизайн привычных вещей” - про то, как дизайн продуктов влияет на то, как их используют пользователи.
“Круг С - Не заставляйте меня думать!” - сборник советов по дизайну интерфейсов (на примере веб-страниц).
“Stephen P. - Seductive Interaction Design”
“Arnheim R. - Visual Thinking” - баловство с тем, чтобы рисовать вместо схем картинки. Скорее вредно, в том виде как подаётся в книге (не поддаётся критике или обработке, в отличие от нормальных схем), но может быть полезным на ранних этапах проектирования.
“Эдвард Де Боно - 6 шляп мышления” - способ различного обсуждения идей, кроме критики.
Паттерны организации разработки уровней игр - сборник материалов

Компьютерные науки
“Александр Степанов - Начала программирования”, “Alexander Stepanov - Notes on Programming” - математический формальный подход к описанию системы типов c++. Полезно, если хочется понять, почему std такой, а не другой, или как туториал к пониманию концептов, ну или просто упороться по формальным описаниям (на мой взгляд, с++ не самый лучший язык для такого).

Пачки советов, интервью
“97 этюдов для архитекторов программных систем”, “97 этюдов для программистов” - занимательное чтиво, некоторые советы интересны, некоторые смелы, возможно найти что-нибудь интересное для себя.
“Сейбел П. - Кодеры за работой”

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

“Чалдини Р. - Психология влияния” - книга, которую важно понять, и на которую часто ссылаются.
“Чалдини Р. - Психология убеждения. 50 доказанных способов быть убедительным” - больше примеров к предыдущей книге.
“Грин Р. - 48 законов власти и обольщения”
“Дэн Ариели - Предсказуемая иррациональность” - объяснение логики потребителя. У Ариэли много докладов и дополнительных материалов с объяснениями различных неосознанных привычек.
“Дэниел Канеман - Думай медленно, решай быстро” - понимание того, что у нас 2 системы мышления.
“Дернер Д. - Логика неудачи” - старая книга о том, что люди плохо умеют быть рациональными в сложных решениях. Полезна руководителям. Из самых интересных экспериментов — вредность состояния потока при решении сложных задач (поток неосознанно уводит внимание от самой задачи к более простой и увлекающей подзадаче).
“Нир Эяль - На крючке” - способ пошагового формирования привычек. ATARI: Модель крючка
“Чиксентмихайи М. - Поток”, так есть много доклады и другие книги, по большей части повторяющие основную идею.

“Bartle R. - Designing Virtual Worlds” - дизайн виртуальных MUD-миров и психология поведения игроков в них.

“Madigan J. - Getting gamers”

Арт
“Betty Edwards - The New Drawing on the Right Side of the Brain”
“Mccloud S - Understanding Comics”

Литература
“Кэмпбелл Дж. - Мифический образ”, “Тысячеликий герой”, “Мифы, в которых мы живём”
“Пропп В. - Морфология волшебной сказки”, “Народные русские сказки”
“Воглер К. - Путешествие писателя”
“Даль В. - О поверьях, суевериях и предрассудках русского народа”

История игр
“Кушнер Д. - Властелины Doom”
“Ramsay M., Molyneux P. - Gamers at Work”,
“Kent S. - The ultimate history of video games”,
“Донован Т. - Играй! История видеоигр”,
“Шрейер Дж. - Кровь, пот и пиксели”

Не по темам
“Минский М. - Вычисления и автоматы”, “Сообщество разума”, “Герберт С - науки об искусственном”, “Armstrong J. Making reliable distributed systems in the presence of sodware errors”, “Адитья Бхаргава - Грокаем алгоритмы”.
“Hampden-Turner C. - Maps of the Mind”
“Мандельброт Б. - Фрактальная геометрия природы” - крутое введение во фракталы для тех, кому это нужно.

Доклады/статьи
Devgamm, White Nights, GDC - просто смотрел всё интересное лет за 5 :)
CppCon, Accu
Отдельно искал информацию про организацию работы в компаниях Wargaming, Playrix, CD Project Red, Pixonic, студий Disney, Naughty Dog, Blizzard, Bethesda, о движках Unity и Unreal (доступные инструменты, причины выбранных решений, формирование взаимоотношений с клиентами, устройство компаний), е-спорт.

Entitas - Entity System Architecture with Unity - Unite Europe 2015
Unite Europe 2016 - ECS architecture with Unity by example
Кирилл Надеждин (Kumo Kairo) - ECS в разработке игр — хорошая архитектура приложений для всех
Overwatch Gameplay Architecture and Netcode
itCppCon19 - ECS back and forth (Michele Caini)
Wargaming.net: Архитектура современных 3D движков (DevGAMM Minsk 2014)
CppCon 2014: Mike Acton “Data-Oriented Design and C++”
Entity system architecture with Unity - Unite Europe 2015
Building a Data-Oriented Future - Mike Acton
Unity at GDC - ECS for Small Things
Unity at GDC - C# to Machine Code
Unity at GDC - A Data Oriented Approach to Using Component Systems
Entitas ECS Unity Tutorial - Setup & Basics
Maxim Zaks - Entity Component System - A Different Approach to Game / Application Development
RustConf 2018 - Closing Keynote - Using Rust For Game Development by Catherine West
CppCon 2018: Stoyan Nikolov “OOP Is Dead, Long Live Data-oriented Design”
Pixonic DevGAMM Talks: Как ECS, C# JS и SRP меняют подход к архитектуре (Валентин Симонов, Unity)

CppCon 2016: Chandler Carruth “High Performance Code 201: Hybrid Data Structures”
Game Development with SDL 2.0 (Steam Dev Days 2014)
Painting a Selfie Girl, with Maths
Evolution of Torque 3D Engine Games 2001-2016
Evolution of Avalanche Engine Games 2006-2019

Архитектура сервисов Wargaming.net / Максим Барышников / WGDC 13.12.2014
Бэкенд-разработка в геймдеве – Максим Барышников, Wargaming
Максим Барышников, «WoT: Geographically distributed cluster of clusters»
Online Feedme::Meetup #1: Максим Барышников (Wargaming, Head of Platform)

Photogrammetry w/PhotoScan & Unity - Bring your Photos to Life! (Oculus Rift & Touch)
Лекция 9. C10K problem.
Threads are an illusion - asynchronous programming with boost::asio - Chris Kohlhoff
Witcher Combat part 4 - Hit reaction by body part - UE4 Advanced Blueprints Tutorial
8 Frames in 16ms: Rollback Networking in Mortal Kombat and Injustice 2
Unite Europe 2016 - Building a PvP focused MMO
Balancing Cards in Clash Royale
Making a Standard (and Trying to Stick to it!): Blizzard Design Philosophies
Интерактивная геометрия на примере кривых Безье
Андрей Давыдов — Концепты: упрощаем реализацию классов std utility
Custom Editor Window for 4.22 UE4 / Unreal Engine 4
КДИ - 172. Unreal Engine
КДИ - 248. Польский геймдев
Unreal Engine 5 Revealed! | Next-Gen Real-Time Demo Running on PlayStation 5
КДИ - 289. Unreal Engine 5
КДИ - 280. Naughty Dog, необязательность менеджмента и построение будущего с Promethean AI
КДИ - 261. Продюсирование игр
КДИ - 172. Unreal Engine
КДИ - 206. Playrix про рост, распределенные команды и хиты
КДИ - 212. 2D-движки для разработки игр Defold и Corona
Психотерапия для геймдева: вопросы, инструменты, практики / DevGAMM Stream
От артиста до арт-директора. Путь роста специалиста в геймдеве / Александр Данилов (Playgendary)
Илья Крутихин (DigitalForms.info) – Создание игровых персонажей на основе 3D сканов
Оптимизация анимационного пайплайна для ААА проектов / Евгений Молоцкий (1C Entertainment)
Ты не выгораешь, если ты - огонь! / Вера Величко (Owl Studio)
Jonathan Blow, цикл про Jai
Дмитрий Гладилин - Проблемы и решения при создании графики для мобильного шутера Guns of Boom
Tutorial: extracting textures and 3D models from Android games (part 1: simple example)
HOW RIP from OPENGL APPLICATIONS_GAMES
Free software, free society: Richard Stallman at TEDxGeneva 2014
Animation driven locomotion
Сергей Гиммельрейх (GDCuffs) - Паттерны Игровых Механик
Pitfalls of Object Oriented Programming, Revisited - Tony Albrecht (TGC 2017)
Keynote: CMake: One Tool To Build Them All - Bill Hoffman [ CppNow 2021 ]

Илья Степанов - пачка лекций по психологии

LISA13 - Blazing Performance with Flame Graphs
Improve app performance with Android Studio Profilers (Google I/O ‘18)
Flame graph новый взгляд на привычное профилирование, Кирилл Борисов, Яндекс
CppCon 2016: Nicholas Ormrod “The strange details of std::string at Facebook”
The Performance Price of Dynamic Memory in C++ - Ivica Bogosavljevic - [CppNow 2021]
Classes With Many Fields - Stanisław J. Dobrowolski [CppNow 2021]
Keynote: SOLID, Revisited - Tony Van Eerd - [CppNow 2021]

An Approach to Holistic Level Design
Мастер-класс The Art of Legend of Zelda
Создание The Legend of Zelda: Breath of the Wild — Начало (часть 1)

Как создать реалистичную модель города. Проектирование игровых городов
Jonathan Blow: Indie Prototyping
Game Studio Management: Making It Great
When Games Invade Real Life
Jesse Schell Keynote: “Information Flow: The Secret to Studio Structure”
The Curve - Nicholas Lovell
DICE 2010: “Design Outside the Box” Presentation
You Don’t Need a F-ing Publisher
DYK: Hideo Kojima has built Metal Gear Solid with LEGO
Intrinsic vs Extrinsic - Designing Good Rewards in Games - Extra Credits
Chris Anderson - Free: The Future of a Radical Price
Jesse Schell Keynote at SIEGE2017: Game Studio Management
Jesse Schell Keynote: “Information Flow: The Secret to Studio Structure”
Game Studio Leadership: You Can Do It
КДИ - 310. Геймджемы
КДИ - Дыбовский и Гуро про эволюцию возможностей
КДИ - 129. Геймдизайн
Stan Just (CD Projekt RED)- Better, Faster, Smarter, Witcher.
Создание пользовательской карты для Dota 2
Stan Just (CD Projekt Red) - Creating Amazing Art in The Witcher 3: Wild Hunt
Creation Kit Tutorial Series - Episode 3: Basic Layout II
How Modding Made Bethesda Better
How We Used Iterative Level Design to Ship Skyrim and Fallout 3
Fallout 4’s Modular Level Design
Основы левел-дизайна ярослав кравцов
How One Gameplay Decision Changed Diablo Forever | War Stories | Ars Technica
Grzegorz Mazur (11 bit studios) - This War of Mine: Under the hood

How Forza’s Drivatar Actually Works | AI and Games
Exploring the AI of Command & Conquer | AI and Games

Working at the Heart of the Team Part TWO!
Give Up Control: Zen and the Art of Leadership
Classic Game Postmortem: Sid Meier’s Civilization
Absolutely No Pressure: Continuing a Successful Game Series with Civilization VI
Ten Principles for Good Level Design
Денис Арманд про дизайн уровней War Thunder, Heroes 7 и Destroy All Humans
Prototype Based Design
Can we Improve Tutorials for Complex Games?
GlitchCon 2014: Level Design by Joel Burgess

CRESSTCon ‘16 Alan Kay Keynote - The Best Way to Predict the Future is to Invent It
Алан Кэй делится яркой идеей об идеях
Будете гореть, горите! — Евгений Кот, Wrike
Евгений Кот | Мама, мы все тяжело больны: 5 проблем в IT, которые вас сломают
Евгений Кот — Почему разрабы несчастны — Мы обречены #19
Теперь я - тимлид, но почему мне так плохо? Практические советы / Евгений Кот (Wrike)
Про инженерный шовинизм: отвратительно быть менеджером / Евгений Кот (Wrike)
Lean gamedev
Rovio: Angry Birds: Behind The Scenes (Flash GAMM Kyiv 2012)

Just Enough Research
Just Enough Research / Erika Hall - UX Salon 2016
Love your Freeloaders, Love your Fans | Nicholas Lovell | TEDxBrum
Don’t Call Them Whales: F2P Spenders and Virtual Value
Visions of the Gamepocalypse | Jesse Schell

Алексей Мерсон — Domain-driven design: рецепт для прагматика
What is DDD - Eric Evans - DDD Europe 2019
Чистая архитектура и Domain-Driven Design

How Minecraft Changes the Future of Games - Minecraft Generation - Extra Credits
Doing Free to Play Wrong - How Bad Monetization Harms F2P Games - Extra Credits

Дмитрий Алексеев, Евгений Шумаков — Есть ли автотестирование в мобильных видеоиграх?
Self control: Dan Ariely at TEDxDuke
Cursed Problems in Game Design
Александр Штаченко (Playbeat) - Три главных фокуса продюсера
Predictably Irrational - basic human motivations: Dan Ariely at TEDxMidwest
“Что делать программисту, которого жизнь заставляет заниматься менеджментом?”
Level Design in a Day: Level Design Histories and Futures
Level Design: Modular Levels in Nier
Play Early, Play Often: Prototyping Civilization 4 (GDC 2006)

CppCon 2019: Andrei Alexandrescu “Speed Is Found In The Minds of People”
Bjarne Stroustrup: Why you should avoid Linked Lists
Give me 15 minutes and I’ll change your view of Linux tracing
Sean Parent - Polymorphic Task - Secret Lightning Talks @ Meeting C++ 2017
CppCon 2019: Herb Sutter “De-fragmenting C++: Making Exceptions and RTTI More Affordable and Usable”
John Bandela “Polymorphism != Virtual: Easy, Flexible Runtime Polymorphism Without Inheritance”
Better Code: Runtime Polymorphism - Sean Parent
Dynamic Polymorphism with Metaclasses and Code Injection - Sy Brand - CppCon 2020
CppCon 2018: Sean Parent “Better Code: Human Interface”
CppCon 2015: Sean Parent “Better Code: Data Structures”
Pacific++ 2018: Sean Parent “Generic Programming”

Gamelab2018 - Jon Blow’s Design decisions on creating Jai a new language for game programmers
C++ as Assembly 2.0 - Hello Nim - Viktor Kirilov - code::dive 2019
Nim - First natively compiled language w/ hot code-reloading at runtime - Viktor Kirilov [ACCU 2019]
RacketCon 2013: Dan Liebgold - Racket on the Playstation 3? It’s Not What you Think!
Lambda World 2019 - Language-Oriented Programming with Racket - Matthias Felleisen
CLRium #3: Язык программирования Nemerle (Влад Чистяков)
Thinking in Immediate: ImGUI - Zhihao Yuan [ ACCU 2021 ]
Why Isn’t Functional Programming the Norm? – Richard Feldman
Modern C and What We Can Learn From It - Luca Sas [ ACCU 2021 ]
Interactive C++: Meet Jupyter / Cling - Neil Horlock [ACCU 2019]
Haxe: An understated powerhouse for software development - George Corney [ACCU 2019]
CppCon 2016: “WG21-SG14 – Making C++ better for games, embedded and financial developers”
The Road to Zig 1.0 - Andrew Kelley
Zig: A programming language designed for robustness, optimality, and clarity – Andrew Kelley
Reflection: Compile-Time Introspection of C++ - Andrew Sutton [ ACCU 2021 ]
C++20 + Lua = Flexibility - James Pascoe [ ACCU 2021 ]
Nemerle pattern matching and algebraic data types
Async await in Nim A demonstration of the flexibility metaprogramming can bring to a language

Блоги:
http://www.kostyushko.com/
http://level-design.ru/
https://gdcuffs.com/category/articles/
http://aushestov.ru/

https://realtimecollisiondetection.net/blog/
https://aras-p.info/
https://floooh.github.io/
https://www.gameenginebook.com/coursemat.html
https://solid-angle.blogspot.com/
http://ithare.com/
https://cpp-optimizations.netlify.app/