как выглядит код игры
Как программировать игры: языки, движки и все, что нужно знать начинающему разработчику
Сперва это кажется дико сложным, но чем глубже погружаешься, тем лучше получается. Рассказываем, как начать делать игры,
Главное — в самом начале узнать, что нас ждёт, чтобы потом не свернуть на полпути, пройти все этапы и выпустить релиз. Подробно всем тонкостям, навыкам и хитростям мы обучаем на курсе «Профессия разработчик игр на Unity». Здесь же рассмотрим первые шаги, которые ждут разработчика.
С чего начать разработку игры
Рассчитываем, что вы уже придумали, какой будет игра, разработали концепт и уже ищете способы разработки. Настало время реализовать свои задумки. Есть несколько вариантов, как это сделать.
Все три способа подразумевают какое-никакое программирование, так что знать хотя бы основы вам точно придётся.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Языки программирования
Подойдут любые, от Python и C до Pascal и Java. От выбора зависит то, сколько времени уйдёт на игру и для какой платформы будет релиз. Также язык влияет на производительность.
На C++, например, пишут для любой платформы, а вот PHP или JavaScript лучше подходят для браузерных игр. Если же вы используете один из движков, то лучше вдобавок изучать C# — на нём прописывают скрипты. Главное — не недооценивать языки. Движок Unity дружит и с JavaScript, а MineCraft был написан на Java.
Движки для создания игр
Среди современных выделим:
Crysis, Far Cry, Sniper II: Ghost Warrior.
Gears of War 4, Dead Pool, Mortal Kombat X, Tekken 7
Outlast, Assassin’s Creed: Identity, Temple Run, Deus Ex: The Fall.
Большой популярностью пользуется Unity, он рассчитан как на 2D-, так и на 3D-игры. Он подходит под разные платформы и языки. На нём создается большинство мобильных и инди-игр. Он бесплатный, но если вы зарабатываете на своих играх больше 100 тысяч долларов в год, то придётся делиться ими с разработчиками Unity.
Как строится игровой код
Допустим, вы выбрали язык и движок, составили план. Что дальше? Продумайте всё от и до. В зависимости от выбранного вами пути (чистый язык или использование движка) будет отличаться и то, что вас ждёт на разных этапах разработки.
Если делаете всё своими силами, то на ваши плечи ляжет работа над физикой, механикой, графикой, искусственным интеллектом и балансом. Если выбрали движок — можно вздохнуть спокойно.
Физика
Физика — это то, как мир игры реагирует на действия игрока или объектов внутри мира. Вот какие могут быть физические действия:
Если пишете сами, то для обычного прыжка придется:
Не говоря уже о том, что нужно работать над анимацией всего этого.
В движках уже прописана физика, и нужно лишь подогнать её под свои нужды. Для примера:
И для этого не придётся писать код вообще — всё уже предусмотрено.
Механика
Игровая механика — это то, какими способами игрок взаимодействует с миром. Совокупность игровых механик составляет игровой процесс. Например, вы уже реализовали возможность ходьбы и прыжков. Эта игра, скорее, платформер.
А если добавите механику получения опыта, повышения уровней, прокачки навыков, — игра станет походить на RPG. Механика — такая же важная составляющая игры, как и сюжет или графика.
Ещё один пример: вы написали сценарий к игре, в которой нужно сбежать из тюрьмы. Даже если игра будет самой линейной в мире, игровая механика может всё изменить:
Будучи программистом, придётся уделять много времени механике.
Графика
Раньше графика создавалась с помощью программного кода, потом придумали текстуры и спрайты, а для 3D-игр используются модели. Подготовив все текстуры и модели, нужно добавить их в игру.
В движке достаточно просто загрузить нужные файлы и прикрепить их к нужным моделям. Иначе — прописывать всё вручную, в том числе и анимацию.
Для анимации 2D-объектов создаётся текстура по типу той, что на изображении выше. Она разбивается на равные части, которые сменяют друг друга. То есть игрок сначала видит первый кадр, который потом сменяется на второй, а затем на третий — это создает иллюзию движения.
Если брать 3D-модель, то используется скелетная анимация — модель как бы нанизывается на специальный каркас (скелет) с подвижными частями. Движение этих частей прописывается в коде.
На скриншоте видно, как персонаж сгибает руку в местах с точками (вершинами). Таких точек может быть очень много, если требуется сложная анимация — жесты, мимика и так далее.
Создаётся анимация так: прописываются точки координат или захватываются движения реального актера.
Первый способ сложный, но дешёвый, потому что от программиста требуется только прописать движения — сдвинуть точку A1 на координаты (50,240).
Второй проще, потому что достаточно одеть актеров в специальные костюмы с маячками, отснять это и перенести в игру. Но тут, конечно, придётся оплатить костюмы, павильон, работу операторов, постановщиков и актёров.
Баланс
Чтобы играть было интересно, нужен баланс. Это значит, что у каждого противника должны быть сильные и слабые стороны. Так геймплей не превратится в убийство одуванчиков или десятичасовые перестрелки с боссом.
Искусственный интеллект
Если геймплей предусматривает взаимодействие с NPC, то им нужно прописать модели поведения: реакцию на действия игрока, агрессивность, возможность вести диалоги или торговать.
Работа с ИИ — одна из самых сложных, потому что стоит учитывать множество ситуаций, для которых задумана реакция. Например, когда вы пытаетесь пройти в дверь, ваш компаньон обязательно должен преградить вам путь, чтобы жизнь малиной не казалась.
На какие платформы ориентироваться
Разобравшись с тем, как всё будет устроено в игре, можно приступать к разработке. Но чтобы проект был коммерчески успешен, выбирайте популярные платформы. Всего можно выделить четыре:
У каждой из этих платформ своя аудитория с вполне конкретными предпочтениями. На мобильных устройствах предпочитают головоломки (2048, 94%, Cut the Rope), аркады (Subway Surf, Temple Run, Angry Birds) и казуалы (Talking Cat Tom, Kitty Kate Baby Care, Hair Stylist Fashion Salon).
На компьютерах играют в MMORPG (Lineage II, World of Warcraft, Skyrim) или шутеры (Battlefield, Call of Duty, Counter-Strike).
Приставки подходят для гонок (Need for Speed, Blur, Burnout Paradise), приключенческих игр (Assassin’s Creed, Portal, The Walking Dead) и так далее.
В браузерах собирают пазлы и строят фермы.
Конечно, можно сделать и головоломку для PS4, и гонку для браузера — никто никого не ограничивает.
Заключение
Будьте готовы к тому, что ваша первая игра не станет шедевром. Но не расстраивайтесь, потому что такие проекты отлично подходят для обучения.
Подтяните свои навыки в программировании, чтобы научиться создавать игры, изучите современный язык, который часто используется разработчиками, и выпустите свой первый проект. А наш курс поможет вам в этом.
Профессия
Разработчик игр на Unity
Годичный учебный курс с полным погружением в профессию разработчика игр. Вы изучите основы геймдизайна, научитесь разрабатывать 2D-, 3D- и мобильные игры, освоите способы их монетизации и продвижения.
Пишем игру на Python
Прежде чем мы начнём программировать что-то полезное на Python, давайте закодим что-нибудь интересное. Например, свою игру, где нужно не дать шарику упасть, типа Арканоида. Вы, скорее всего, играли в детстве во что-то подобное, поэтому освоиться будет просто.
Логика игры
Есть игровое поле — простой прямоугольник с твёрдыми границами. Когда шарик касается стенки или потолка, он отскакивает в другую сторону. Если он упадёт на пол — вы проиграли. Чтобы этого не случилось, внизу вдоль пола летает платформа, а вы ей управляете с помощью стрелок. Ваша задача — подставлять платформу под шарик как можно дольше. За каждое удачное спасение шарика вы получаете одно очко.
Алгоритм
Чтобы реализовать такую логику игры, нужно предусмотреть такие сценарии поведения:
Хитрость в том, что всё это происходит параллельно и независимо друг от друга. То есть пока шарик летает, мы вполне можем двигать платформу, а можем и оставить её на месте. И когда шарик отскакивает от стен, это тоже не мешает другим объектам двигаться и взаимодействовать между собой.
Получается, что нам нужно определить три класса — платформу, сам шарик и счёт, и определить, как они реагируют на действия друг друга. Поле нам самим определять не нужно — для этого есть уже готовая библиотека. А потом в этих классах мы пропишем методы — они как раз и будут отвечать за поведение наших объектов.
По коням, пишем на Python
Для этого проекта вам потребуется установить и запустить среду Python. Как это сделать — читайте в нашей статье.
Начало программы
Чтобы у нас появилась графика в игре, используем библиотеку Tkinter. Она входит в набор стандартных библиотек Python и позволяет рисовать простейшие объекты — линии, прямоугольники, круги и красить их в разные цвета. Такой простой Paint, только для Python.
Чтобы создать окно, где будет видна графика, используют класс Tk(). Он просто делает окно, но без содержимого. Чтобы появилось содержимое, создают холст — видимую часть окна. Именно на нём мы будем рисовать нашу игру. За холст отвечает класс Canvas(), поэтому нам нужно будет создать свой объект из этого класса и дальше уже работать с этим объектом.
Если мы принудительно не ограничим скорость платформы, то она будет перемещаться мгновенно, ведь компьютер считает очень быстро и моментально передвинет её к другому краю. Поэтому мы будем искусственно ограничивать время движения, а для этого нам понадобится модуль Time — он тоже стандартный.
Последнее, что нам глобально нужно, — задавать случайным образом начальное положение шарика и платформы, чтобы было интереснее играть. За это отвечает модуль Random — он помогает генерировать случайные числа и перемешивать данные.
Запишем всё это в виде кода на Python:
Мы подключили все нужные библиотеки, сделали и настроили игровое поле. Теперь займёмся классами.
Шарик
Сначала проговорим словами, что нам нужно от шарика. Он должен уметь:
Платформа
Сделаем то же самое для платформы — сначала опишем её поведение словами, а потом переведём в код. Итак, вот что должна уметь платформа:
А вот как это будет в виде кода:
Можно было не выделять счёт в отдельный класс и каждый раз обрабатывать вручную. Но здесь реально проще сделать класс, задать нужные методы, чтобы они сами потом разобрались, что и когда делать.
От счёта нам нужно только одно (кроме конструктора) — чтобы он правильно реагировал на касание платформы, увеличивал число очков и выводил их на экран:
У нас всё готово для того, чтобы написать саму игру. Мы уже провели необходимую подготовку всех элементов, и нам остаётся только создать конкретные объекты шарика, платформы и счёта и сказать им, в каком порядке мы будем что делать.
Смысл игры в том, чтобы не уронить шарик. Пока этого не произошло — всё движется, но как только шарик упал — нужно показать сообщение о конце игры и остановить программу.
Посмотрите, как лаконично выглядит код непосредственно самой игры:
Что дальше
На основе этого кода вы можете сделать свою модификацию игры:
Пишем игры на C++, Часть 1/3 — Написание мини-фреймворка
На хабре не очень много уроков по созданию игр, почему бы не поддержать отечественных девелоперов?
Представляю вам свои уроки, которые учат создавать игры на C++ с использованием SDL!
Что нужно знать
О чем эта часть?
В следующих постах будет больше экшена, это лишь подготовка 🙂
Почему SDL?
Я выбрал эту библиотеку как наиболее легкую и быструю в освоении. Действительно, от первой прочитанной статьи по OpenGL или DirectX до стотысячного переиздания змейки пройдет немало времени.
Теперь можно стартовать.
1.1. Начало начал
Скачиваем SDL с официального сайта.
Создаем проект Win32 в Visual Studio, подключаем lib’ы и includ’ы SDL (если вы не умеете этого делать, то гугл вам в помощь!)
Также необходимо использовать многобайтную кодировку символов. Для этого идем в Проект->Свойства->Свойства конфигурации->Набор символов->Использовать многобайтную кодировку.
Создаем файл main.cpp
Пока что он ничего не делает.
Царь и бог каркаса — класс Game
Game.h
Создаем файл Project.h, он нам очень пригодится в будущем
Уже чуточку получше, но все равно как-то не густо.
1.2. Графика
Создаем аж 2 класса — Graphics для отрисовки графики и Image для отрисовки картинок
SDL_Surface — класс из SDL для хранения информации об картинке
Рассмотрим Graphics
NewImage — есть 2 варианта загрузки картинки. Первый вариант просто грузит картинку, а второй после этого еще и дает прозрачность картинке. Если у нас красный фон в картинке, то вводим r=255,g=0,b=0
DrawImage — тоже 2 варианта отрисовки картинки. Первый рисует всю картинку целиком, второй только часть картинки. startX, startY — координаты начала части картинки. endX, endY — конечные координаты части картинки. Этот метод рисования применяется, если используются атласы картинок. Вот пример атласа:
(изображение взято из веб-ресурса interesnoe.info)
Рассмотрим Image
Он просто держит свой сурфейс и дает право доступа к своим закрытым членам классу Graphics, а он изменяет сурфейс.
По сути, это обертка над SDL_Surface. Также он дает размер картинки
В конструкторе инициализируется SDL и создается экран.
Функция Flip должна вызываться каждый раз после отрисовки картинок, она представляет получившееся на экран и чистит экран в черный цвет для дальнешней отрисовки.
Остальные функции малоинтересны, рекомендую разобраться в них самому
Нет, вы все правильно делаете, этот файл и должен быть таким 🙂
Надо изменить Game.h, Game.cpp и main.cpp
Game.h
Тут мы добавляем указатель на Graphics и в Execute добавляем размер экрана
Ничего особенного, разве что не пропустите функцию SDL_Quit для очистки SDL
Тут мы создаем экран размером 500 на 350.
1.3. Ввод
Надо поработать со вводом с клавиатуры
SDL_Event — класс какого-нибудь события, его мы держим в Input’е для того, чтобы не создавать объект этого класса каждый цикл
Ниже расположены методы, не представляющие особого интереса. Примечание: методы с окончанием Down вызываются, когда клавиша была нажата, а с окончанием Up — когда опущена.
Здесь мы обрабатываем наш объект событий в функции Update, а остальные функции просто проверяют тип события и его значения.
Изменяем теперь Game.h и Game.cpp
Как видно, мы добавили указатель на Input и создали методы-возвращатели Graphics и Input
1.4. Итоги
Это был первый урок. Если вы дошли до этого места, я вас поздравляю! У вас есть воля, присущая программисту 🙂 Смотрите ссылки в начале статьи на последующие уроки для того, чтобы узнать еще много нового!
Заглянем за кулисы разработки: подборка исходных кодов классических игр
Обожаю заглядывать за кулисы. Мне интересно, как делаются вещи. Мне кажется, что большинству людей это тоже интересно.
Исторически так сложилось, что видеоигры не делятся исходниками. Конечно, они ведь предназначены для игроков. Но для программистов там всегда есть, на что посмотреть. И некоторые игры всё-таки выпускали свои исходники. А я давно намеревался сделать такую подборку.
К сожалению, почти все игры – для PC. Найти исходники для консолей или аркад почти нереально, и большинство программистов не в курсе различий подходов к программам на платформах, отличных от PC.
Многие игры после выпуска исходников были улучшены и дополнены сообществом – я намеренно даю ссылки только на оригинальные исходники. Так что, если вас вдруг интересуют апгрейды – они могут существовать.
Многие игры были рассмотрены на сайте Fabien Sanglard. Если вам интересны подробности их работы, то пожалуйте к нему.
Можно заметить, что многие игры принадлежат id Software/Apogee. Совпадение? Не думаю. id славится открытостью и привычкой выпускать исходники. Старые коммерческие игры уже не имеют ценности и были бы потеряны – не лучше ли, чтобы кто-то учился чему-то полезному на их основе?
Итак, приступим (в хронологическом порядке):
Colossal Cave Adventure (1976)
Разработчик: William Crowther and Don Woods
Издатель: Разные.
Платформа: PDP-10 и друзья.
“You are in a maze of twisty little passages, all alike.” («Вы находитесь в лабиринте из неотличимых друг от друга небольших извилистых проходов»).
Возможно, это не на 100% коммерческая игра. Но её продавали, кроме того, она имеет историческую важность. И, кстати, именно по мотивам названия этой игры все приключенческие игры называются adventure.
Оригинал был написан на Fortran, в котором современным программистам будет сложновато разобраться. Но последние версии были на C.
Catacomb (1989)
Разработчик: John Carmack
Издатель: Softdisk
Платформа: Apple II / DOS
Не путайте с Catacomb 3D. Это ранняя двумерная версия игры. Разработана Кармаком до создания id и полностью написана на Turbo Pascal.
Prince Of Persia (1989)
Разработчик: Jordan Mechner
Издатель: Brøderbund
Платформа: Apple II / DOS / many more
Обзор кода: fabiensanglard.net
Prince Of Persia произвёл фурор благодаря плавной анимации, голливудскому стилю подачи истории и интересному геймплею.
Написана полностью на ассемблере, что затрудняет задачу обзора кода. Рекомендую посмотреть интервью с Джорданом Мехнером, где он делится деталями о создании игры.
SimCity (1989)
Разработчик: Maxis
Издатель: Maxis / Brøderbund
Платформа: All
Игра начала новый жанр. В основе алгоритма – симуляция города посредством клеточных алгоритмов. Хороший пример кода, который стоит изучить для понимания принципов работы. Исходники для unix-порта 1990 года были выпущены в 2008 году.
Hovertank 3D / Catacomb 3D (1991)
Разработчик: id Software
Издатель: Softdisk
Платформа: DOS
Первая веха в истории трёхмерных шутеров id Software. Эти игры используют технику raycasting, которая была улучшена в следующем хите, Wolfenstein, где были добавлены текстуры.
Star Control II (1992)
Разработчик: Toys for Bob
Издатель: Accolade
Платформа: DOS / 3D0
Уникальная игра, не вписывающаяся ни в один из строгих жанров. Внешний вид чётко напоминает нам о 90-х годах и системе VGA, где цвета были подобраны не для красоты, а из стандартной палитры DPaint.
Рекомендую почитать обзор кода от The Escapist.
Исходник получен с порта на 3D0, оригинальный же был утерян. Это часто случается со старыми играми, когда разработчики уходят из компании.
Wolfenstein 3D / Blake Stone (1992/3)
На основе предыдущего движка Catacomb был сделан серьёзный апгрейд на VGA-графику. И играть стало интереснее. Как в большинстве случаев с компанией id, исходники сравнительно легко читать, хотя ключевые части написаны на 16-битном ассемблере (в Doom уже такого не встретишь).
Интересно отметить, что для рисования вертикальных линий они динамически генерируют разные функции для каждой из возможных высот стен.
У Fabien можно найти инструкцию по компиляции исходников на современных инструментах.
Blake Stone, ответвление от Apogee на том же движке, вышло в 1993 году, за неделю до Doom. Можно представить, почему оно кануло в лету.
Doom (1993)
В каком-то смысле это самый важный для изучения движок. В своё время это была революция – мир от первого лица, не плоский, как Wolf3D. Освещение, текстуры и изобретение DeathMatch.
Одной из самых знаковых вещей стало изобретение идеи «движка». До этого игры были сильно связаны с данными. Doom пропагандировал отвязку данных игры от движка. Это породило целые сообщества, модифицировавшие игры (Aliens TC, Fistful Of Doom).
Descent (1994)
Многие компании кинулись догонять Doom, запустив волну «Клонов Doom». Parallax удалось сделать нечто совсем другое.
В игре можно было летать на корабле по трёхмерному лабиринту из проходов, в отличие от 2.5D коридоров Doom (у id полная трёхмерность появилась лишь в Quake год спустя).
Gravity Force 2 (1994)
Разработчик: Jens Andersson and Jan Kronqvist
Издатель: Shareware
Платформа: Amiga
Многие современники вспомнят эту игру. Amiga Power однажды назвала её второй лучшей игрой всех времён.
Это не совсем коммерческая игра, она была выпущена по принципу платного shareware, а затем её раздавали бесплатно на диске Amiga Power. Включил её в список потому, что в ту пору вообще редкие игры выдавали свои исходники. Если вам интересно, как делались 16-битные игры, обратите внимание.
Heretic / Hexen (1994/5)
Это был уникальный клон Doom по двум причинам: 1) лицензированный движок Doom и 2) хороший геймплей
Заметные улучшения: возможность смотреть вверх и вниз, скриптовой движок для внутриигровых событий (новая идея на то время).
Rise Of The Triad: Dark War (1995)
ROTT это была странная игра. Она была порождена движком Wolfenstein 3D, при этом создатели умудрились эмулировать ощущения разных высот. Но всё равно игра не смогла конкурировать с Doom от 1993 года.
Marathon 2: Durandal (1995)
Разработчик: Bungie Software
Издатель: Bungie Software
Платформа: Apple Macintosh / Windows 95
Серия отличилась тем, что в своё время попала в крайне маленький список игр, доступных на Apple Macintosh. И, в общем-то, это клон Doom. А через 3 месяца после её выхода id Software выпустила знаменитый “qtest”, позволявший взглянуть на движок Quake.
Поскольку Маки тогда использовали лишь писатели с художниками, несмотря на все усилия, серия провалилась. Небольшая компания разработчиков имела неплохой успех на разных других платформах.
Duke Nukem 3D / Shadow Warrior (1996)
Разработчик: 3D Realms
Издатель: GT Interactive Software
Платформа: DOS
Code review: fabiensanglard.net
Из множества клонов, игры 3D Realms отличились хорошими попытками привнести нечто новое в игру. Движок Кена Сильвермана Build Engine добавил много интересных фич вроде наклонных полов, комнат, расположенных друг над другом и зеркал.
К сожалению, в отличие от самой игры, исходники просто ужасны. Я рылся в них несколько раз и до сих пор не могу разобраться, что там где. К счастью, обзор от Fabien проливает некоторый свет на происходящее в коде.
За дополнительной информацией обращайтесь на страницу автора.
Quake 1/2/3 (1996-1999)
Разработчик: id Software
Издатель: GT Interactive / Activision
Платформа: DOS / Windows / others
Code review: fabiensanglard.net (Quake 1)
Code review: fabiensanglard.net (Quake 3)
Тут писать особо нечего, вы и сами всё знаете. Знатная веха в создании полностью трёхмерных движков, без всяких хаков вроде 2.5D
Упомяну несколько интересных подробностей. Возможно, это первая коммерческая игра, скомпилированная компилятором с открытым исходным кодом (DJGPP for DOS, ранний порт gcc).
В игре был свой скриптовой язык “Quake C” (позже lcc у Quake 3). Он был встроен специально для того, чтобы игроки могли делать модификации. Это, вкупе с системой ресурсов PWAD, породило огромное сообщество моддеров.
В Quake 1 был инновационный механизм кэширования результатов шейдинга. Но после распространения 3D-ускорителей это потеряло смысл. Следующая игра от id, Rage, использовала эту же идею.
Кроме того, Quake был очень надёжным движком. Никаких глюков растра или обсчёта столкновений.
Abuse (1996)
Разработчик: Crack dot Com
Издатель: Electronic Arts / Origin Systems
Платформа: DOS / Linux / Mac
В игре было использовано несколько инноваций. Крутая система управления одновременно с мыши и клавиатуры. Динамическое освещение (неслыханная вещь для платформеров).
Но больше всего, как программисту, мне понравилась система «визуального Lisp». Вся игра заскриптована на языке, напоминающем Lisp. Поведение врагов можно изменять во время выполнения игры, а не просто включать в код.
Ещё одним интересным моментом стал способ, по которому события можно подключать во встроенном редакторе карт – визуально перетаскивать линии от выключателя к двери, или от ловушки к месту, где появляются враги. Присутствует возможность задавать логику И/ИЛИ в виде скрытых объектов на уровне. Такого я в других редакторах не встречал.
Коммерческого успеха игра не снискала и через два года исходники были опубликованы. Следующая игра от Crack Dot Com, Golgotha, была выпущена по принципу open-source, включая всю графику.
Aliens versus Predator (1999)
Какое облегчение видеть здесь шутер не за авторством id. И хотя технических инноваций в игре особо не было, сингл-кампания у неё вышла просто потрясающей. И игра остаётся хорошим примером движка не от id.
Freespace 2 (1999)
Как бы наследник франшизы Descent, но не совсем. Кампания и мультиплеер проходят полностью в космическом пространстве.
Прекрасный пример, как публикация исходников продляет жизнь игр на годы. К игре выпускаются всяческие наборы нового контента и апгрейды.
The Operative: No One Lives Forever (2000)
У движка LithTech история долгая, хотя он и находится в тени более известных Quake и Unreal engine. Я особенно не рылся в исходника NOLF, но я подозреваю, что там есть лишь исходники самой игры, но не графического движка. И однозначно там не будет частей, связанных с работой на PlayStation 2.
А жаль – разработка для PS2 в наши дни должна выглядеть для программистов инопланетным делом, поскольку она гораздо сильнее подходила в методу ориентации на данные, чем это делают современные API.
MechCommander 2 (2001)
Разработчик: FASA Interactive
Издатель: Microsoft
Платформа: Windows
Исторически Microsoft и открытые исходные коды вместе не уживались. Но на склоне лет ситуация начинает смягчаться. Всё-таки приятно видеть, что большие компании приходят к более открытым взглядам на вещи – все эти наработки имеют нулевую коммерческую ценность, они ценны лишь исторически.
В прошлом году даже были выпущены исходники ранних версий MS-DOS и Word, что было неслыханным делом лет 30 назад.
Doom 3 (2004)
Разработчик: id Software
Издатель: Activision
Платформа: Windows / Mac / Linux / Xbox / PS3
Code review: fabiensanglard.net
Если вы хотите изучить движки современных игр высшего класса, то Doom 3 – это один из наилучших примеров. На время выхода он был инновационным во многих областях. Метод использования моделей высокого разрешения на элементах низкого разрешения в игре сейчас является стандартом для коммерческих игр. В исходнике есть много всего интересного – одна лишь система обработки физики достойна изучения, в частности, отслеживание столкновений.
Это первая игра от id, написанная на С++. Прошлые игры из-за использования С несли в себе простоту. Doom 3 тоже довольно простой, но заметно уже изменение его вектора движения.
Также игра (печально) известна использованием трафаретных теней при расчёте освещения. Можно спорить, был это интересный эксперимент или поле для дальнейшей работы, но сегодняшние игры предпочитают использовать карты теней. Возможно, эта техника когда-нибудь ещё пригодится.
Gish (2004)
Разработчик: Cryptic Sea
Издатель: Chronic Logic / Stardock
Платформа: Windows / Linux
Gish был примечателен физикой «мягкого тела» и интересным подходом ко времени. Интересно разбираться в его исходниках и выяснять, как что работает. Никаких сторонних физических движков тут нет.
Интересно, что игра полностью написана на С – сейчас это редко встречается. Это не самый аккуратный из всех виденных мною исходников, но это хороший пример того, как игра может не превращаться в гигантскую расползшуюся базу кода с сотнями внешних зависимостей.
Canabalt (2009)
Разработчик: Adam Saltsman
Издатель: Semi-Secret / Beatshapers / Kittehface
Платформа: Flash / iOS / PSP / Android / Ouya
Не самая сложная игра, ну и что? Если вы хотите научиться делать игры, начинайте с простого – вот с этого.
Прототипирование заняло 5 дней, портирование на iOS – 10. Пример превращения простой идеи в достойное выражение. Это как бы возвращение 8-битной эпохи, когда еженедельно могли появляться новые жанры. Жаль, что с тех пор люди предпочитают клонировать идеи, а не творить самостоятельно.
Canabalt показывает, насколько вещи можно сделать просто, если захотеть.
Что я упустил
Нужно упомянуть ещё несколько игр. Они не выпускали исходников, но подверглись фанатскому обратному инжинирингу. Это, конечно, не то же самое, что настоящие исходники, но тоже может быть интересным:
Не попали в рейтинг
Сорцы следующих игр утекли в сеть нелегально, поэтому они не попали в зал славы:
Half Life 2
Falcon 4.0
ReVolt
Turrican III
Mr. Nutz: Hoppin’ Mad
Trespasser (ладно уж, вот вам обзор кода)