Игры и игровые консоли

И для начала отправимся в середину 90-х годов. В то время на свет, благодаря стараниям известнейшего режиссёра Стивена Спилберга и бывшего руководителя анимационного подразделения «Диснея» Джеффри Катценберга, появилась компания «DreamWorks», что начала клепать фильмы и мультфильмы, причём весьма успешные. И спустя год после основания, под крылом гиганта, при сотрудничестве с Microsoft, родилась студия «DreamWorks Interactive», что должна была производить видеоигры.

Упомянутый выше Спилберг был большим поклонником этого вида развлечений, и однажды, увидев, как его сын играет в шутер «GoldenEye 007», решил создать что-то зрелищное и интересное для юного поколения. За спиной режиссёра к концу десятилетия уже был успешный фильм «Спасти рядового Райана», а потому Спилберг решил перенести атмосферу сражений Второй Мировой в видеоигру. Да ещё и сделал этот проект эксклюзивом для PlayStation 1. Так в 1999 году вышла самая первая часть «Medal of Honor».

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

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

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

На протяжении более двух лет я много времени уделял разработке моего собственного эмулятора Game Boy, GameRoy. Я немало успел сделать. В эмуляторе был готов графический пользовательский интерфейс (с отладчиком и дизассемблером), сама программа прошла многочисленные тесты и могла сравниться с некоторыми наиболее точными эмуляторами. Я даже портировал её на Android!

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

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

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

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

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

Краткий список, наиболее важных игр на ПК, которые несомненно повлияли на мою жизнь больше, чем какие либо ещё явления или события может выглядеть так: Heroes 3, Warcraft 3, Half-Life / CS1.5, Diablo 2, Morrowind 2, Serious sam. Мне кажется, именно эти игры причины того, что я смог стать программистом (и наверняка они повлияли не только на меня). Вы могли бы спросить, где тут связь и что общего между этими играми, кроме того, что они примерно из одной эпохи? Все эти игры имели потрясающую поддержку комьюнити, где то благодаря, а где то и вопреки воле разработчиков. Мощнейшие редакторы карт (и миров! чего только стоит название Warcraft 3 World Editor) в комплекте с игрой или фанатская любовь, которая выражалась в потрошение ресурсов и кода игр до последнего байта. Я помню, что мой первый диск (или один из) был с игрой CS1.5. Я тогда был несколько удивлён, что в комплекте с контрой зачем то засунули какое то недоразумение с нудной покатушкой на вагонетке. То, что игра Counter-Strike 1.5 это всего лишь фанатское дополнение к Half-Life ещё предстояло узнать.

Дисклеймер: время описываемых в тексте событий — половина и более жизни назад, или примерно 2005–2010 гг, что могло привести к ряду неточностей и ложной памяти.

А сегодня у нас на повестке — Сид Мейер.
Не-не-не, никаких «Цивилизаций».

В общем я тут напродавал карточек в Стиме аж на целых пятьдесят рублей и искал, куда пристроить неожиданно свалившееся на меня богатство. И вот после минут двадцати поисков… Не, ну а как иначе-то? Дело очень серьезное, двузначная сумма как никак. Так вот, спустя двадцать минут я наткнулся на… приготовьтесь: Sid Meier's Covert action.

Концепт альтернативной версии старого советского конструктора - своеобразный "Полёт 2.0", ремейк классики на новый лад.

Наступил Год Змеи. Грех не вспомнить чудо финской игровой мысли, его побратимов, истоки, взгрустнуть по Nokia и залам с игровыми автоматами.

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

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

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

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

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

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

Грандиозный удар по репутации «Акелла» перенесла с видимой лёгкостью. Ветки на форумах тёрлись безжалостно, коробочки с «Корсарами» 3 продавались тысячами. Невероятно, но самая провальная игра серии принесла больше всех денег! Настоящий Клондайк! Но надо было меняться, и в «Акелле» это понимали. После российского релиза игру доводили до ума для релиза за рубежом ещё практически год, и почти пофиксили все значимые баги. Но... То, что мертво, оживить невозможно... И поэтому не в странах СНГ «Корсары» 3 провалились в продажах, и понятно почему. В то время плохие игры не вытягивал хороший пиар, как в наши дни, да собственно и пиара-то особенного не было. По правде говоря, наибольший успех вышел-таки у «Пиратов карибского моря» благодаря всевозможным модам, но об этом позднее.

Вы когда-нибудь хотели узнать, как работала предварительно вычисленная видимость в Quake? Я хотел, поэтому написал программу vis.py, воссоздающую этот алгоритм на Python. В этой статье представлена вся информация, необходимая для понимания vis, — инструмента, применявшегося в Quake, Half-Life и играх на Source Engine.

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

Как снизить объём перерисовки? Давайте начнём с высокоуровневого обзора возможных решений.