В конце 90-х, в эпоху таких игр, как Caesar III, Pharaoh, Stronghold и Zeus: Master of Olympus, если вы не знали, то отцом всех этих игр был Simon Bradbury (хотя в Фараоне и Zeus скорее только крестным), начала набирать популярность идея упрощения пользовательского интерфейса. Во многом это было ответом на критику, что перегруженные UI отпугивают широкую аудиторию (и это действительно так, адепты Евы не в счет), надо было как-то привлечь людей помоложе, которые ни тогда, ни сейчас не отличались желанием глубоко вникать в механики. На этом фоне начали сознательно скрывать сложные внутренние механики (black box gameplay) от игрока — в том числе в градостроительных стратегиях.

Уже в Caesar III (1998), хоть та и имела отличную визуализацию потребностей домов и цепочек производства, всё же оставляла за кадром множество числовых значений: точное количество работников, занятых в зданиях, внутреннюю очередь обработки запросов, приоритеты в распределении ресурсов. Игроку приходилось догадываться о многом опытным путём и считать на бумаге параметры райнов и рисовать цепочку распределения товаров. Сравните это с мануалами Age of Empires II, где на сотнях страниц подробно разбирались все коэффициенты.

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

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

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

Статья рассчитана на читателей, которые не являются гуру C++ или знатоками тонкостей языка, но в целом знакомы с языком и его идеями, хотя знание ассемблера x86 не требуется, я буду прикладывать ссылки на примеры кода quickbench, чтобы объяснить, почему даю те или иные советы.

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

Путь от простых хижин к роскошным особнякам, украшенным фресками и колоннами, в Pharaoh — это не просто вопрос архитектуры и разные текстуры. Это отражение заботы игрока о своём виртуальном городе, его нуждах, вере и безопасности. Каждое жилище в городе это FSM, реагирующая на условия вокруг: достаток еды, доступ к воде, религиозные обряды, культурные радости и много чего еще.

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

В этой статье попробую рассказать, как устроена эволюция домов, какие требования стоят за каждым уровнем жилья и как это было реализовано в оригинальной игре. Если вы вдруг пропустили встречу нашего жреческого круга... простите, предыдущие статьи про восстановление исходников этого старого ситибилдера, — обязательно найдите время, чтобы взглянуть на пару интересных моментов (Добро пожаловать в Древний…, ecs, dynvtbl, логические потоки и Фараоне, Как построить мастабу, Как рисуется карта в Фараоне, Новый дом для Фараона)

Все скриншоты в статье сделаны уже на рендере проекта, исходники на github

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

Эта серия статей родилась как заметки на полях к замечательной книге Game Engine Architecture, книга большая, объемная и охватывает все аспекты создания движка. Но там нет нюансов практической разработки. А чтобы видеть нюансы надо понимать не только теорию, все же GAE больше теория, но знать как работает код игры изнутри. Чтобы понимать как, и главное почему, используются выбранные механизмы внутри игры, чтобы видеть проблемы с производительностью и архитектурой, как их искать и как чинить, для этого придется понять как работают и как создавались игровые движки.

Если мне не изменяет память - Кармак сказал, что лучший способ [создания игр] — написать собственный движок ( "The right move is to build your own engine" ), на что многие возразят: это вовсе не так просто. Но папа Doom'a известен не только своим вкладом в разработку игровых движков, но и довольно часто высказывался критически о развитии игровых движков в целом, и о преимуществах создания собственных технологических решений вместо использования готовых.

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

Книга Design Patterns: Elements of Reusable Object-Oriented Software («Приёмы объектно-ориентированного проектирования. Паттерны проектирования»), также известная под названием "синей книги", по цвету обложки первого издания, или книги "банды четырех/GoF" издана почти тридцать лет назад.

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

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

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

Заходите, великов и граблей хватит на всех.

По мотивам статьи: Не пиши простой код и старого манифеста

Эта статья о других, о тех кто случайно просто пишет код, или кому случайно пришлось писать код раньше. Или о тех, кто случайно код не пишет, но очень хочет.

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

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

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

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

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

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

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

Просто пиши код, потому что Хабр завален «Как я продаю на маркетах когтеточки» и «Как я уволился ради душевного баланса», а вот статью про memory fences или perf counters — хрен найдёшь.

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

Модели выполнения используются разные — от простой многопоточности с ручной синхронизацией до более продвинутых систем акторов, job-based подходов или task graph. Например, системы поведения ИИ могут обновляться параллельно с физикой, пока основной поток отвечает за рендеринг. Некоторые движки, такие как Unreal Engine, используют task graph (граф задач), где зависимости между задачами выражаются явно, и задачи автоматически распределяются по доступным ядрам. Другие подходы, как в CryEngine Perth (аналог ECS, матрица задач), позволяют организовать данные так, чтобы минимизировать ложные зависимости и повысить кэш-эффективность. Конечный выбор всегда зависит от архитектуры движка, платформы и требований конкретной задачи или группы задач.

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

В std::move никто никуда не двигается

В undefined behavior поведение вполне себе определено, просто крашит игру

В GameObject нет ни игры ни объекта, а только баги и куча антипаттернов

Memory leak detector сам протекает

В PhysicsEngine физики столько же, сколько в сказке про Колобка

Из 8 часов работы 6 уходят на попытку собрать билд после мержа со стейблом.

В ProfileMode тормозит всё кроме профайлера

В retrospective meeting обсуждают, почему всё плохо, но оставляют как есть.

В debug билде багов меньше чем в релизном и выше фпс

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

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

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

Попробую убедить вас не использовать std::string/vector в функциях. При написании кода для пк, неважно - игры это или что-то другое, программа обычно разделяется на условно пять областей памяти.

Последние пару-тройку лет на конференциях все чаще я слышу жалобы знакомых в игрострое о том, что текущий вектор развития "современного C++" не соответствует потребностям игровой разработки. Реальные полезные нововведения фактически закончились с выходом C++17, а попытки внедрить C++20 часто заканчиваются обнаружением множества "гейзенбагов" и существенным снижением производительности - критичные для нас на 10-15% от сборки к сборке. Пошатавшись по разным игровым студиям, блин, скоро будет 15 лет как я тут, у меня таки немножечко есть, что вам рассказать.

Все современные студии, что крупнее двух с половиной землекопов, пишущие игры на плюсах, шарпе или чем-то близком - используют Visual Studio или переходят со своих поделок на Unreal/Unity, который так-то тоже плюсы, хоть и со странностями. Так исторически сложилось, что винда и майки были, есть и в ближайшем будущем горизонта лет десяти останутся самым крупным рынком ПК-консольных игр, а сами консоли давно стали "ну совсем ПК", но чтобы не терять эксклюзивы (и шекели) вендоры в этом не признаются никогда.

Мобилки, как-бы отдельно, и там свои свои покемоны Mac с Android, но в Visual Studio в том или ином виде создаются, дебажатся и оптимайзятся 95% игр, остальное - погрешность. С момента начала золотой эры игростроя (где-то в конце 90-х), большинство игр писались с учетом того, что они будут выпущены на ПК, под ПК понимается - под винду. И наследие многих A+-студий так или иначе связано с Microsoft, даже для не-Microsoft консолей и мобилок.

Независимо от того, начинаете ли вы разрабатывать свою игру или присоединяетесь к уже существующему проекту, когда приходит время оптимизировать память и заниматься разным улучшайзингом, то всегда встают одни и те же вопросы. Стоит ли использовать собственные контейнеры? Если использовать свои, то какой лучше выбрать - похожий на vector, или больше подойдет map? Является ли связный список наилучшим выбором при частых вставках и удалениях элементов? А откуда эти вставки вообще взялись, но это конечно другой вопрос.

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

Если вы не готовы писать и поддерживать свою STL, старайтесь, использовать vector, он хотя бы предсказуем по времени на всех платформах. Так вам скажет большинство разработчиков игр на C++, но проблема в том, что vector перераспределяет хранимые объекты в памяти при вставке новых элементов, а также при удалении любого элемента, кроме последнего. Это означает, что указатели на элементы вектора становятся недействительными, и тогда все зависимости и взаимодействия между элементами перестают работать.

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

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

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

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

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

Тем временем, в тишине университетских корпусов, среди гудящих cтоек и залежей перфокарт, заспанные и перегруженные учебой студенты, будущие светила программирования и предлагатели новых стандартов превращали огромные дорогущие мейнфреймы в примитивные игровые приставки. Вместо добивания перфокартами сложных математических расчётов или моделей для научных работ, эти люди писали код для первых игр. Не могу их в этом винить, потому что сам в конце 90х прокрадывался в зал, где стоял отцовский комп и тайком запускал SimCity или Цезаря, или пытался накропать морской бой на BASIC руководствуясь исходниками, напечатанными в каком-то журнале и молясь, чтобы скрип жесткого диска и попискивание бипера не были услышаны родителями.

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

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

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

За кажущейся простотой скрывается множество граблей и ловушек: взаимные блокировки (deadlock), «голодание» потоков, асинхронные ошибки. Это похоже на попытку дирижировать оркестром, где музыканты игнорируют ритм. Проще говоря, любые действия над данными могут привести к проблемам, и чтобы этого не происходило, операции над данными должны быть атомарными, это решается вводом в код примитивов синхронизации, вроде мьютексов, семафоров, спинлоков.

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

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

stl::vector numbers = {1, 2, 3, 4, 5};
int sum = 0;
for (int num : numbers) {
sum += num;
}

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

Алгоритмы STL — это настоящий швейцарский нож для разработчика. Они не просто помогают писать код, а делают его чище, понятнее и надежнее. В проектах с большими кодовыми базами, где легаси код не всегда стабилен и удобен для поддержки, это особенно важно. Каждый, кто писал циклы вручную, сталкивался с ошибками: вылезли за границы массива, забыли обработать пустой контейнер, сделали лишнее копирование. STL-алгоритмы избавляют от многих проблем, позволяя выразить мысли кратко и четко. Вместо простыней кода с индексами — несколько строк с понятным смыслом. Так что, если вы еще не знакомы со стандартными алгоритмами, самое время это исправить. Это один из тех инструментов, которые однажды освоив, уже невозможно забыть, это как езда на велосипеде, хорошем промышленном велике, за авторством Кнута или Саттера - надежном и с серийным номером.

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

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

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

C и C++ не имеют встроенной сборки мусора, поэтому разработчик сам решает, как и когда выделять и освобождать память. Мы, конечно, можем покивать в сторону STL, сокрытия аллокаций в контейнерах, но от этого они никуда не денутся. Просто если раньше приходилось думать про выделенный кусок памяти, понимать, как он скажется на времени фрейма, помнить, что его надо удалить (а может, не надо и стоит оставить на следующий фрейм), то теперь всё заворачивается в сахарные контейнеры и разработку в стиле STL-blin-vse-sterpit. STL-то может и стерпит, и даже как-то будет ворочаться, однако не стоит полагаться исключительно на системный аллокатор, бездумно вызывая new или malloc для каждого запроса памяти. Вы ведь понимаете, что std::vector посреди цикла или горячей функции — это плохая идея?

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

Пытаться оптимизировать код, который использует системные аллокаторы, — всё равно что сгребать листья в кучу ветреным днём: куча, конечно, сгребается, но постоянно приходится махать грабельками, чтобы она оставалась на одном месте. Даже если выделения памяти происходят последовательно, друг за другом, вот прям без всяких перерывов, нет гарантии, что эти участки будут расположены хотя бы близко друг к другу. В результате при обработке таких данных процессору приходится прыгать по разным участкам памяти, теряя такты просто на поиск данных вместо того, чтобы работать с ними.

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

Ребята из HFT, Database, Automotive и Embedded-систем наверняка могут рассказать немало интересных историй про оптимизацию new/delete. Давайте я расскажу немного про разные аллокаторы в играх?

В студии Arkane в Лионе на входе в офис есть стена с разными вещами, которые присылают фанаты. Одно время там висела большая борда с цитатами великих разработчиков игр, к сожалению, тогда не подумал её сфотографировать. Это была не просто декорация, часто там стояли люди, даже читавшие её не один раз. Где-то в середине разработки Deathloop этот источник вдохновения, который встречал каждого входящего, убрали на склад. Впрочем там поменяли большинство экспонатов. Среди цитат можно было найти слова Джона Кармака, говорящего о важности технологии, или слова Сида Мейера о том, что игра — это серия выборов, мысли главного "Марио" Шигэру Миямото о том, что плохая игра останется плохой навсегда. Эти цитаты напоминали людям, что они не просто создают игры, а продолжают традиции, заложенные легендами индустрии. Слова мастеров оставались в памяти, напоминая, что каждое решение — от механики до дизайна уровней — должно быть осмысленным и значимым. Цитат было немного, точно не считал, но около тридцати, подумал может кому будут интересны высказывания мэтров. Все на память не помню, пришлось спрашивать у гугла.

...Египет — мир величественных пирамид, бурных вод Нила и одной из самых теплых и ламповых 2D-стратегий из 1999 года! Здесь вы станете архитектором и правителем, строя города, заботясь о благополучии жителей и возводя памятники, достойные фараонов. А вы знали, что у Фараона была полноценная демка? Хотя это нормально для индустрии того периода, вот о различиях с retail версией и пойдет речь.

…но помните, что в 2025-м всё это великолепие может не завестись и потребует доработки напильником, для работы на современных системах. Самый надежный способ насладиться стареньким, но не потерявшим свою магию, ситибилдером без глюков — это установить виртуалку с WinXP, но и это не всегда работает. Виртуалка поможет избавиться от большинства проблем, к сожалению на всех ОС после XP игра работает все хуже и хуже.