Программирование игр руководство

Инструкция начинающего разработчика игр

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

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

И так Вы решили сделать свою игру, о чём Вам нужно подумать…

Думаем – нужно ли это тебе

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

Я перечислю основные ошибки в их представлении:

• Нет романтики. Многие начинающие разработчики, наигравшись вдоволь в игры, приходят к мысли, что создавать игры также интересно, как и играть, только чуть-чуть сложнее. Это очень частая ошибка. Чем больше и сложнее игра тем, скучнее и безынтереснее процесс её разработки. Романтики совершенно нет.
• Трудно и даже невозможно. Многие после нескольких (или даже одного) успешного проекта наполняются уверенностью, что написать игровой проект им по силам. На самом деле, игры – это одно из самых сложных направлений разработки. И чем «серьёзнее» игра, тем проект сложнее. В процессе создания игры разработчик может столкнуться с нерешаемыми проблемами, которые убивают на корню энтузиазм даже у самых упёртых.
• Отвращение к играм. Со временем у каждого матёрого разработчика игр развивается отвращение к играм. Сначала просто они становится менее интересными. Затем начинаешь замечать, что они вовсе не интересны, а интересно только, как они работают. Чем дальше, тем хуже.
• Конкуренция и качество продукта. Играми занимаются многие студии и независимые разработчики. Существует своеобразный «уровень вхождения» в этот бизнес. Сейчас нельзя сделать успешную игру, нарисованную акварелью (да, такие игры встречались в начале 2000-х). Она просто не выдержит конкуренции. Соответственно, абы что не сделаешь. Тут скрывается важный психологический момент – начинающий разработчик вынужден делать хороший продукт, иначе он будет испытывать постоянное чувство страха неуспешности своего продукта.
• Время и ресурсы. И самая распространенная ошибка – это то, что ресурсов (время, деньги, знания) им хватит. Чтобы понять объём работ, читайте следующие пункты.

Концепция и ТЗ

Когда-то давно я написал довольно неплохую статью о концепции проекта. За последние пару лет мои взгляды слегка поменялись, но суть осталась та же.

• Что же такое концепция? Концепция игрового проекта — это документ, описывающий цели, задачи, основные особенности проекта, исследование рынка и целевой аудитории, условия его выполнения. Также, так как проект игровой, обязательно описание игровой механики, игровых понятий, примерный сценарий и концепт-арт. Если Вы ещё рассчитываете делать проект не в одиночку (что весьма вероятно), то понадобится ещё техническое задание (ТЗ) – документ, содержащий описание необходимых работ, сроки и условия.
• Зачем нужна концепция? Очень хороший вопрос. Зачем заниматься какой-то «писаниной», когда нужно собирать команду и писать код?
  В первую очередь концепция нужна, чтобы самому получить полноценное представление о конечном результате и оценить объём работ. Без чёткой и продуманной концепции у Вас в итоге получится, соответственно, противоречивая и непродуманная игра. Без концепции существует большая вероятность возникновения ошибок организации игровой механики или ошибок реализации.
  Во вторую очередь концепция нужна для того, что бы другие поняли то, что Вы хотите сделать. Все члены команды должны работать над одним общим проектом. Об этом общем проекте члены команды узнают из документа концепции проекта. Это нужно, чтобы не было расхождений в представлениях о конечном результате. Если Вы решили создать игру и для этого собираете команду, то первые вопросы от будущих членов команды будут: «А что предстоит мне сделать? Что в итоге мы должны получить?». Вы должны будете им предоставить концепцию проекта и ТЗ. Без концепции и ТЗ Вы не привлечёте ни одного нормального специалиста.
• Объёмы. Весьма интересен вопрос объёма концепции. Тут необходимо отталкиваться от сложности игры и её разработки. Если у Вас простая игра, Вы работаете один и Вы способны удержать идею игры в своей голове, то можно вообще не писать концепцию. Если удержать в памяти все моменты нельзя, то необходимо перенести их на бумагу (или другой носитель). Если Вы будете работать в команде или использовать помощь других людей (инвесторы, художники и прочие), то Вам просто необходима развёрнутая концепция и ТЗ для каждого человека. Критерий один – понятность. Нужно чтобы любой человек, ознакомившись с концепцией и ТЗ, представил конечный результат, так же как и Вы.
  Обратите внимание на то, что, если Вы понимаете свою концепцию, то это не значит, что её поймут другие. Написание концепции выполняет роль «лакмусовой бумажки». Если Вы не можете написать понятную концепцию (примерно, 5 страниц для небольшой игры, несколько десятков страниц для большой), то вряд ли Вы закончите в итоге проект.
• Детальность. В концепции должны быть ответы на все вопросы. После прочтения концепции должно сформироваться полное представление о проекте. Специалисты первым делом смотрят на концепцию, если концепция окажется для них не полной и непонятной, то они не будут с Вами работать.
  Отдельно стоит упомянуть концепт-арт. Он должен быть, хотя бы в простейшем виде. Он является доказательством решения проблемы с контентом, содержимым игры (смотрите следующий раздел).
• Русский язык. Для многих это серьёзная проблема. Если документ концепции содержит множество грамматических, орфографических и синтаксических ошибок, то ни один специалист не воспримет его всерьёз. Помните: незнание русского языка очень вредит бизнесу.
• Время. Желательно в сразу в ТЗ указать сроки выполнения работ. Проблема в том, как оценить это время, если никогда подобным не занимался. Точно ответа на этот вопрос Вы никогда не получите, всё придёт с опытом. Я только дам один совет: учитывайте не только время разработки, но и время на исправление ошибок (примерно 50% от времени на разработку).

Контент

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

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

Разберём основные моменты этого раздела.

• Сложность. Это самая главная проблема в вопросе контента. Оказывается, в большинстве случаев подготовка контента является самой сложной задачей, сложнее написания программного кода, сложнее тестирования и отладки, и сложнее реализации игры. Естественно, если игра маленькая, то это не так заметно, а если большая, то на долю создателя контента выпадает до 80% работы по проекту.
• Объёмы. Часто из-за того, что разработчики никогда не выполняли задачи создателей контента, им очень сложно оценить объёмы. Кажется, что там такого ¬– пара десятков картинок и 3-4 звука. Но если посчитать, то получается 40 крупноразмерных изображений, 400 мелких изображений, два десятка звуков (я привел пример среднестатистической BMMORPG). Хорошо, что это всё можно подсчитать при подготовке концепции.
• Качество. Во-первых, надо понимать, что игроки работают непосредственно с контентом. Во-вторых, надо помнить, что существует огромное количество игр-конкурентов с хорошим контентом. Можно сделать вывод: игра с плохим контентом будет не конкурентоспособна, т.е. контент в игре должен быть высокого качества.
• Время. Вполне логично, что на подготовку больших объёмов качественного контента уходит очень много времени. Времени уходит больше, чем на все остальные направления вместе взятые (маленькие игры не в счёт). Учитывайте это, когда будете планировать и рассчитывать сроки.
• Стоимость контента. Хороший контент стоит «хороших» денег. Очень «хороших» денег, которых у начинающих разработчиков игр обычно нет. Многие разработчики питают иллюзорную надежду найти «бесплатного» создателя контента (или дешёвого). Найти можно, но он либо будет создавать низкопробный контент, либо создаст для Вас немного контента, а затем переметнётся к тем, кто будет ему платить. Короче говоря, «бесплатного» создателя хорошего контента Вы никогда не найдёте. Именно по этой причине нет хороших «OpenSource» игр.
• Воровство. Из-за существования проблемы дорогого контента, иногда появляются разработчики игр, которые его воруют. Мол, что такого?.. возьму-ка я из этой игры десяток картинок, а фоновые изображения найду на DA, а в качестве фоновой музыки поставлю пару любимых песенок Rammstein. Проблема в том, что авторское право контента достаточно легко подтвердить. У «жертвы» воровства есть либо исходные файлы контента, либо документ о передаче контента от его создателя. Для воров контента очень велик шанс нарваться на статью 146 УК РФ.
• Единый стиль. Ещё один важный момент, о котором часто забывают. Что бы игра смотрелась цельной и продуманной, ей нужно иметь единый стиль. Создатели контента не роботы, поэтому делают работы в своём индивидуальном стиле. Отсюда можно сделать вывод: желательно чтобы содержимое игры создавало как можно меньше человек.
• Дилемма. После прочтения описанных выше моментов можно построить следующую цепочку: Конкурентоспособная игра требует использование качественного контента. Качественный контент может сделать только профессиональный создатель контента. Профессиональный создатель контента стоит недёшево. Решений данной проблемы всего лишь три:
  1. Не делать игру, то есть отказаться от направления разработки игр.
  2. Найти инвестора. Но тут сразу нас поджидает проблема концепт-арта. Кто будет подготавливать концепт-арт, если нет денег на художника? А без концепт-арта никто не будет инвестировать в Вас.
  3. Решать проблему собственными силами. То есть кто-то из членов команды должен быть создателем контента и должен получать зарплату, даже если все остальные сосут палец.

Программирование

Как ни странно, создание программного кода для игр не является самой сложной задачей, но в тоже время и не является простой.

• Команда. В отличие от создателей контента программистов для своей команды найти легко. Это объясняется тем, что при определённом уровне подготовки написание программного кода игры не такая уж сложная задача. Можно найти «бесплатных» программистов, готовых работать ради интереса. А за плату и «имя» (упоминание, как разработчика игры) можно найти программиста, который будет писать хороший годный код. Но… сейчас не начало 2000-х и программисты поумнели. Первым делом адекватный программист попросит разработчика продемонстрировать концепцию и ТЗ. Затем спросит про создание контента или финансирование, которое пойдёт на его создание. Специалисты прекрасно понимают, что незачем вкладывать силы в изначально провальный проект. Если у Вас нет концепции и не решен вопрос с контентом, то нормального программиста Вы не найдёте.
• Сначала делаем большое, потом маленькое. Достаточно простой совет, но ему чаще всего не следуют. Игровой проект в большинстве случаев сложен и имеет множество зависимостей. Все это сложно просчитать на уровне составления концепции, частенько приходиться что-то менять в планах. Поэтому, чтобы не выполнять двойную работу, сначала необходимо сделать общую работающую конструкцию (прототип), а затем углубляться в детали.
• Что сначала контент или код? Прочитав раздел про контент, Вы уже, наверное, поняли, что современные игры основаны на контенте, а не на программировании. Отсюда дилемма – код подгонять под контент или контент подгонять под код. Оба подхода имеют место в современном процессе разработки. Если подгонять код под контент, то нагрузка падает на программиста, время разработки увеличивается. Это дешёвый способ. Если контент подгонять под код, то нагрузка с программиста спадает, и при учёте, что контент подготавливают наёмные работники, время разработки сокращается. Это дорогой способ, так как нагрузка падает на наёмных создателей контента. Заранее оцените ситуацию и придерживайтесь одного из подходов.
• Нерешаемые ошибки. Это даже не проблема, а предубеждение. Разработка игры весьма сложный процесс. Бывает, что разработчик сталкивается с нерешаемыми проблемами (либо решаемыми крайне тяжело) и ему приходиться пересматривать чуть ли не весь проект. Психологически это очень трудно. Многие, даже самые упёртые разработчики, попав в такой «тупик», теряют энтузиазм и закрывают проект. Предубеждение в том, что все считают, что с ними такого не случиться. Совет один: будьте психологически готовы пересмотреть весь проект и выполнить работу заново.
• Журналы. Совет лично от меня. Ведите три журнала:
  1. Журнал выполненной работы по проекту для отслеживания динамики разработки;
  2. Журнал идей по проекту, чтобы не забыть их и, если возможно, включить в концепцию;
  3. Журнал найденных багов и ошибок, которые необходимо исправить в будущем.

  Эти три журнала помогут избежать ошибок и двойной работы в процессе разработки.

• Время. При определении времени, которое планируется на написание кода, часто делают одну ошибку – не учитывают затраты времени на исправление багов и отладку кода.
• Авторство программного кода. Определённый «маразм» наблюдается, у некоторых программистов. Они считают, что обладают абсолютными правами на код, который ими написан, что даже после релиза игры они могут предъявить права на «часть кода» игры. Что бы защитить это «священное» право они могут пойти на всякие низости (программные бомбы, бакдоры, отказ от передачи исходных кодов и прочие). Мой совет прост – остерегайтесь таких неадекватных программистов. Программный код не контент. Доказать его авторство очень сложно. Поэтому нормальный программист сначала договаривается, что он получит за код; затем его пишет; потом передаёт разработчику и получает вознаграждение; после чего уже ни на что не претендует. Также должно быть организовано и в команде.

Тестирование

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

• Тестирование сторонними людьми. В процессе разработки тестирование проводиться в основном своими средствами. Со временем глаза привыкают к имеющимся игровым моментам, вырабатываются умение работать в данной системе, короче, ошибки становятся менее заметными. Поэтому устраивайте периодические тесты продукта сторонними людьми, которые никогда не видели ваш продукт. Следите за их реакцией на различные игровые моменты, как они воспринимают меню игры и, вообще, расспросите их общее впечатление. Поверьте мне, один такой тест даст Вам очень большой объём полезной информации. Проводите их чаще, прислушивайтесь к обратной связи, и Вы получите на выходе хорошую игру.
• Женщины. Когда-то я написал неплохую статью про женщин и игры. Смысл в том, что женщины видят всё по другому. Поэтому, желательно, чтобы в тесте игры участвовала хотя бы одна женщина (девушка), даже если игра не рассчитана на женскую аудиторию. Их обратная связь будет невероятно полезна.

Организационные моменты

• Команда. Как Вы могли догадаться, созданием таких проектов, как игры, лучше заниматься командой. Это обосновано тем, что создание контента совершенно другой вид деятельности отличный от программирования и организации проекта и одному заниматься такими разными видами деятельности сложно. Минимальная команда – это два человека, создатель контента и разработчик. Чтобы не было непонимания, уточню – наёмный работник, по-моему, тоже в какой-то мере член команды.
  Конечно, можно заниматься разработкой и в одиночку. Есть такие «сумасшедшие», которые и пишут код, и рисуют графику, и сочиняют музыку, но это их проблемы.
  Собрать команду при наличии финансирования легко – форумы программистов и создателей контента, биржи фрилансеров Вам в помощь. При отсутствии финансирования можно найти только программиста, а вот нормального создателя контента не найдёте – здесь надо надеяться либо на себя, либо на удачу.
• Юридическое оформление. Здесь всё просто. Хотите иметь с игры деньги и обезопасить себя от рейдерского захвата (когда кто-то внаглую ворует вашу игру), то вам нужно юридическое оформление на уровне индивидуального предпринимателя. Если Вы ещё собираетесь распределять проект по долям, то нужно оформление на уровне ООО. Поэтому если при поиске членов команды Вы обещаете долю в проекте, то не удивляйтесь, что Вас будут просить предъявить реквизиты вашей организации.
• Контакты. Никогда не пренебрегайте знакомствами. Знакомьтесь с другими разработчиками, общайтесь и обменивайтесь контактами. В будущем, возможно, знакомство с ними принесёт Вам пользу.
• Реклама. Так как игр на рынке много, то чтобы пользователи выбрали именно вашу игру, нужно привлечь к себе внимание. Делается это при помощи рекламы на различных ресурсах. Логично, что реклама эта требует: во-первых денег, а во-вторых, рекламный контент (банеры, видеоролики, статьи). Возможны и другие способы ¬– связи, спам, рекламные акции и прочие, но они не всегда эффективны.
  Без рекламы игра, точно также как и без контента, является провальным проектом. Обратите на это внимание. Но тут ситуация может достаточно легко исправлена инвестированием и сторонней помощью.
• Инвестирование. Понятное дело, что с деньгами игру делать гораздо легче, но без развёрнутой концепции (с концепт-артом), команды и рабочего прототипа никто не будет финансировать ваш проект. То есть на начальных этапах на финансирование не надейтесь. А вот на последних этапах разработки ситуация может в корне поменяться – могут появиться инвесторы и Вам всё равно будут нужны деньги для организации рекламной компании.
  Чтобы найти инвесторов, собирайте контакты.
• Сторонняя помощь. Вместо инвесторов можно найти стороннюю помощь (реклама за рекламу, помощь в распространении за процент и прочие). Тут надо ориентироваться по ситуации. Чтобы найти стороннюю помощь, так же собирайте контакты.

Послесловие

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

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

начинающих

разработчиков игр, претендующих на роль

лидера

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

function jump() {
If(gamer.jumpTimer >= 1) {
   gamer.y++; 
   gamer.jumpTimer --;
   } else {
      If(gamer.y >= ground.y) {
         gamer.y--;
      }
   }
}

Как зарабатывать больше с помощью нейросетей?
Бесплатный вебинар: 15 экспертов, 7 топ-нейросетей. Научитесь использовать ИИ в своей работе и увеличьте доход.
Узнать больше

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

К концу этой статьи вы сможете:

Предыстория и установка

pygame представляет собой оболочку Python для библиотеки SDL, что означает Simple DirectMedia Layer. SDL обеспечивает межплатформенный доступ к базовым мультимедийным аппаратным компонентам вашей системы, таким как звук, видео, мышь, клавиатура и джойстик. pygame начал жизнь как замена застопорившемуся проекту PySDL . Кроссплатформенный характер SDL pygame означает, что вы можете писать игры и многофункциональные мультимедийные программы Python для любой платформы, которая их поддерживает!

Для установки pygame на вашей платформе используйте соответствующую команду pip:

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

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

Базовая программа PyGame

Прежде чем перейти к специфике, давайте взглянем на основную программу pygame. Эта программа создает окно, заливает фон белым цветом и рисует синий круг посередине:

Когда вы запустите эту программу, вы увидите окно, похожее на это:

Разберем этот код по частям:

Это была база pygame. Теперь давайте углубимся в концепции, лежащие в основе этого кода.

Концепции PyGame

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

Инициализация и модули

Библиотека pygame состоит из ряда конструкций Python, которые включают в себя несколько различных модулей . Эти модули обеспечивают абстрактный доступ к определенному оборудованию в вашей системе, а также унифицированные методы работы с этим оборудованием. Например, display обеспечивает единый доступ к вашему видеодисплею, а joystick позволяет абстрактно управлять вашим джойстиком.

После импорта библиотеки pygame из приведенного выше примера первое, что вы сделали, — это инициализировали PyGame с помощью pygame.init(). Эта функция вызывает отдельные init() функции всех включенных модулей pygame. Поскольку эти модули являются абстракциями для конкретного оборудования, этот шаг инициализации необходим, чтобы вы могли работать с одним и тем же кодом в Linux, Windows и Mac.

Дисплеи и поверхности

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

В pygame всё просматривается в одном созданном пользователем display, который может быть окном или полным экраном. Дисплей создается с помощью .set_mode(), который возвращает представление Surface видимой части окна. Surface — это то, что вы передаете в функции рисования, такие как pygame.draw.circle(), и содержимое этого Surface выталкивается на дисплей, когда вы вызываете pygame.display.flip().

Изображения и прямоугольники

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

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

Ладно, хватит теории. Давайте придумаем и напишем игру!

Базовый дизайн игры

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

Один мой бывший коллега , описывая программные проекты, говорил: «Вы не знаете, что делаете, пока не узнаете, чего не делаете». Имея это в виду, вот некоторые вещи, которые не будут рассмотрены в этом руководстве:

Вы можете попробовать свои силы в добавлении этих и других функций в свою программу.

Давайте начнем!

Импорт и инициализация PyGame

После импорта pygame вам также потребуется инициализировать его. Это позволяет подключить абстракции pygame к вашему конкретному оборудованию:

Библиотека pygame определяет множество вещей помимо модулей и классов. Она также определяет некоторые локальные константы для таких вещей, как нажатия клавиш, движения мыши и атрибуты отображения. Вы ссылаетесь на эти константы, используя синтаксис pygame.<CONSTANT>. Импортируя определенные константы из pygame.locals, вы можете вместо этого использовать синтаксис <CONSTANT>. Это сэкономит вам несколько нажатий клавиш и улучшит общую читаемость.

Настройка дисплея

Теперь вам нужно то, на чём вы будете рисовать! Создайте экран , который будет общим холстом:

Вы создаете экран для использования, вызывая pygame.display.set_mode() и передавая кортеж или список с желаемой шириной и высотой. В данном случае окно имеет размер 800×600, как определено константами SCREEN_WIDTH и SCREEN_HEIGHT в строках 20 и 21. Это часть окна, которой вы можете управлять, в то время как ОС управляет границами окна и строкой заголовка.

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

Настройка игрового цикла

Каждая игра от Pong до Fortnite использует игровой цикл для управления игровым процессом. Игровой цикл делает четыре очень важные вещи:

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

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

Обработка событий

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

Каждое событие в pygame имеет связанный с ним тип события. В вашей игре типы событий, на которых вы сосредоточитесь, — это нажатия клавиш и закрытие окна. События нажатия клавиш имеют тип события KEYDOWN, а событие закрытия окна имеет тип QUIT. Различные типы событий также могут иметь другие связанные с ними данные. Например, у типа события KEYDOWN также есть переменная , вызываемая key для указания того, какая клавиша была нажата.

Вы получаете доступ к списку всех активных событий в очереди, вызывая pygame.event.get(). Затем вы просматриваете этот список, проверяете каждый тип события и отвечаете соответствующим образом:

Давайте подробнее рассмотрим этот игровой цикл:

Когда вы добавите эти строки к предыдущему коду и запустите его, вы увидите окно с пустым или черным экраном:

Окно не исчезнет, пока вы не нажмете клавишу Esc или иным образом не вызовете событие QUIT, закрыв окно.

Рисование на экране

В примере программы вы рисовали на экране с помощью двух команд:

Теперь вы узнаете о третьем способе рисования на экране: использовании файла Surface.

Напомним, что Surface— это прямоугольный объект, на котором можно рисовать как, например, на чистом листе бумаги. Объект screen представляет собой Surface, и вы можете создавать свои собственные Surface — объекты отдельно от экрана дисплея. Давайте посмотрим, как это работает:

После того, как экран заполнен белым цветом в строке 45, в строке 48 создается новый Surface. Он имеет ширину 50 пикселей, высоту 50 пикселей и назначается surf. На этом этапе вы относитесь к нему так же, как к файлу screen. Итак, в строке 51 вы заполняете его черным цветом. Вы также можете получить доступ к его основе, используя .get_rect(). Это сохраняет rect для последующего использования.

Использование .blit() и .flip()

Просто создать новое Surface недостаточно, чтобы увидеть его на экране. Для этого вам нужно скопировать на Surface другой Surface. Термин blit означает Block Transfer, а .blit() означает, как вы копируете содержимое одного Surface в другое. Вот как происходит процесс рисования surf на экране:

Вызов .blit() в строке 55 принимает два аргумента:

Координаты (SCREEN_WIDTH/2, SCREEN_HEIGHT/2) говорят вашей программе разместить surf точно в центре экрана, но это не совсем так:

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

Обратите внимание на вызов pygame.display.flip() после вызова blit(). Это обновляет весь экран с момента последнего перелистывания. Без вызова .flip() ничего не будет отображаться.

Спрайты

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

В терминах программирования спрайт — это двухмерное представление чего-либо на экране. По сути, это картинка. pygame предоставляет класс Sprite , предназначенный для хранения одного или нескольких графических представлений любого игрового объекта, который вы хотите отобразить на экране. Чтобы использовать его, вы создаёте новый класс, который расширяет Sprite. Это позволяет использовать его встроенные методы.

Игроки

Вот как вы используете объекты Sprite в текущей игре для определения игрока. Вставьте этот код после строки 18:

Сначала вы определяете Player, расширяя строку 22 pygame.sprite.Sprite. Затем используете .__init__() .super()для вызова метода.

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

Запустите этот код. Вы увидите белый прямоугольник примерно посередине экрана:

Как вы думаете, что произойдет, если вы замените строку 59 на screen.blit(player.surf, player.rect)? Попробуйте и посмотрите:

Когда вы передаете Rectto .blit(), он использует координаты верхнего левого угла для рисования поверхности. Вы будете использовать это позже, чтобы заставить вашего игрока двигаться!

Пользовательский ввод

Итак, вы узнали, как создавать pygame и рисовать объекты на экране. Теперь начинается настоящее веселье! Вы сделаете плеер управляемым с помощью клавиатуры.

Ранее вы видели, что pygame.event.get() возвращает список событий в очереди, которую вы сканируете на наличие типов событий KEYDOWN. Ну, это не единственный способ читать нажатия клавиш. pygame также предоставляет pygame.event.get_pressed(), который возвращает словарь , содержащий все текущие события в очереди KEYDOWN.

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

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

K_UP, K_DOWN, K_LEFT и K_RIGHT соответствуют клавишам со стрелками на клавиатуре. Если словарная статья для этой клавиши — True, то эта клавиша нажата, и вы перемещаете игрока в правильном направлении. Здесь вы используете .move_ip(), что означает перемещение на месте , чтобы переместить текущий Rect.

Затем вы можете вызвать каждый кадр .update() для перемещения спрайта игрока в ответ на нажатия клавиш. Добавьте этот вызов сразу после вызова .get_pressed():

Теперь вы можете перемещать прямоугольник вашего плеера по экрану с помощью клавиш со стрелками:

Далее необходимо решить 2 проблемы:

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

Здесь вместо использования .move() вы просто меняете соответствующие координаты .top, .bottom, .leftили .right напрямую. Проверьте это, и вы обнаружите, что прямоугольник игрока больше не может перемещаться за пределы экрана.

Теперь давайте добавим врагов!

Враги

Какая игра без врагов? Вы будете использовать методы, которые вы уже изучили, чтобы создать базовый класс врагов, а затем создать множество из них, чтобы ваш игрок их избегал. Сначала импортируйте библиотеку random:

Затем создайте новый класс спрайтов с именем Enemy, следуя тому же шаблону, который вы использовали для Player:

Есть четыре заметных различия между Enemy и Player:

Итак, что делает .kill()? Чтобы понять это, вы должны знать о группах спрайтов .

Группы спрайтов

Еще один очень полезный класс, предоставляющий возможности — Sprite Group. Это объект, который содержит группу объектов Sprite. Так зачем его использовать? Разве вы не можете вместо этого просто отслеживать свои объекты в списке? Ну, можете, но преимущество использования заключается в методах Group, которые он раскрывает. Эти методы помогают определить, не столкнулся ли кто-либо с файлом Player, что значительно упрощает обновление.

Давайте посмотрим, как создавать группы спрайтов. Вы создадите два разных объекта Group:

Вот как это выглядит в коде:

Когда вы вызываете .kill(), Sprite удаляется из всех Group, которым он принадлежит. Это также удаляет ссылки на, что позволяет сборщику мусора Python освобождать память по мере необходимости.

Теперь, когда у вас есть группа all_sprites, вы можете изменить способ рисования объектов. Вместо того, чтобы вызывать .blit(), вы можете перебрать всё в all_sprites:

Теперь all_sprites с каждым кадром будет прорисовываться что угодно, будь то враг или игрок.

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

Пользовательские события

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

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

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

pygame внутренне определяет события как целые числа, поэтому вам необходимо определить новое событие с уникальным целым числом. Последнее резервное событие pygame называется USEREVENT, поэтому определение ADDENEMY = pygame.USEREVENT + 1 в строке 83 гарантирует его уникальность.

Затем вам нужно вставить это новое событие в очередь через равные промежутки времени на протяжении всей игры. Вот тут-то и появляется модуль time. Строка 84 запускает новое событие ADDENEMY каждые 250 миллисекунд, или четыре раза в секунду. Вы вызываете .set_timer() вне игрового цикла, так как вам нужен только один таймер, но он будет срабатывать на протяжении всей игры.

Добавьте код для обработки вашего нового события:

Всякий раз, когда обработчик событий видит новое событие ADDENEMY в строке 115, он создает Enemy и добавляет его в enemies и all_sprites. Поскольку Enemy находится в all_sprites, он будет отображаться в каждом кадре. Вам также нужно вызвать строку 126 enemies.update(), которая обновляет все в enemies, чтобы убедиться, что они перемещаются правильно:

Однако это не единственная причина, по которой существует группа только для enemies.

Обнаружение столкновений

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

В этом уроке вы будете использовать метод под названием .spritecollideany(), который читается как «столкновение спрайтов». Этот метод принимает Sprite и Group в качестве параметров. Он просматривает каждый объект в Group и проверяет, пересекается ли .rect с объектом .rect в Sprite. Если да, то возвращается True. В противном случае возвращается False. Это идеально подходит для этой игры, так как вам нужно проверить, не сталкивается ли сингл player с одним из Group enemies.

Вот как это выглядит в коде:

Строка 135 проверяет, не столкнулся ли player с каким-либо из объектов в enemies. Если это так, то player.kill() вызывается удалить его из каждой группы, к которой он принадлежит. Поскольку рендерятся только объекты в all_sprites, они больше не будут этого делать. Как только игрок был убит, вам также нужно выйти из игры, поэтому вы устанавливаете running = False в строке 138.

На данный момент у вас есть основные элементы игры:

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

Изображения спрайтов

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

Ранее вы узнали, что изображения на диске могут быть загружены в файл Surface с помощью модуля image. Для этого урока мы сделали небольшой реактивный самолет для игрока и несколько ракет для врагов. Вы можете использовать этот вариант, рисовать свои собственные или загружать некоторые бесплатные игровые изображения. Вы можете щелкнуть ссылку ниже, чтобы загрузить рисунок, использованный в этом уроке:

Изменение конструкторов объектов

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

Давайте немного распакуем строку 31 pygame.image.load(), которая загружает образ с диска. Вы передаете её путь к файлу. Она возвращает Surface, а вызов .convert() оптимизирует Surface, ускоряя будущие вызовы .blit().

Строка 32 .set_colorkey() используется для указания того, что цвет pygame будет отображаться как прозрачный. В этом случае вы выбираете белый, потому что это цвет фона изображения. Константа RLEACCEL — это необязательный параметр, который помогает pygame ускорить отрисовку на неускоренных дисплеях. Это добавляется в pygame.locals оператор импорта в строке 11.

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

Вот как выглядят похожие изменения Enemy:

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

Добавление фоновых изображений

Для фоновых облаков используются те же принципы, что и для Player и Enemy:

Вот как это выглядит:

Это должно выглядеть очень знакомо. Это почти то же самое, что и Enemy.

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

Это говорит о том, что нужно подождать 1000 миллисекунд или одну секунду, прежде чем создавать следующий файл cloud.

Затем создайте новый Group для хранения каждого вновь созданного cloud:

Затем добавьте обработчик нового события ADDCLOUD в обработчик событий:

Наконец, убедитесь, что clouds обновляются каждый кадр:

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

Обратите внимание, что каждый новый Cloud и Enemy добавляется all_sprites так же, как clouds и enemies. Это сделано потому, что каждая группа используется для отдельной цели:

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

Скорость игры

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

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

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

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

Второй вызывает .tick(), чтобы сообщить pygame, что программа достигла конца кадра:

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

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

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

Звуковые эффекты

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

Название mixer относится к тому факту, что модуль смешивает различные звуки в единое целое. С помощью подмодуля music вы можете транслировать отдельные звуковые файлы в различных форматах, таких как MP3 , Ogg и Mod . Вы также можете использовать Sound для хранения одного звукового эффекта, который будет воспроизводиться в формате Ogg или несжатом формате WAV . Все воспроизведение происходит в фоновом режиме, поэтому при воспроизведении Sound метод возвращает значение сразу после воспроизведения звука.

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

Как и в большинстве случаев pygame, использование mixer начинается с шага инициализации. К счастью, этим уже занимается pygame.init(). Вам нужно только вызвать pygame.mixer.init(), если вы хотите изменить значения по умолчанию:

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

После инициализации системы вы можете настроить звуки и фоновую музыку:

Строки 138 и 139 загружают фоновый звуковой клип и начинают его воспроизведение. Вы можете указать звуковому клипу зацикливаться и никогда не заканчиваться, установив именованный параметр loops=-1.

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

Итак, как вы используете звуковые эффекты? Вы хотите воспроизводить каждый звук, когда происходит определенное событие. Например, когда корабль движется вверх, вы хотите сыграть move_up_sound. Поэтому вы добавляете вызов .play() всякий раз, когда обрабатываете это событие. В дизайне это означает добавление следующих вызовов .update() для Player:

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

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

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

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

Вот и все! Проверьте это снова, и вы должны увидеть что-то вроде этого:

Примечание об источниках

Вы могли заметить комментарий к строкам 136-137 при загрузке фоновой музыки, в котором указан источник музыки и ссылка на лицензию Creative Commons. Это было сделано потому, что этого требовал создатель этого звука. В лицензионных требованиях говорилось, что для использования звука необходимо указать как правильное указание авторства, так и ссылку на лицензию.

Вот несколько источников музыки, звука и изображений, в которых вы можете найти полезный контент:

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

Заключение

Из этого руководства вы узнали, чем программирование игр pygame отличается от стандартного процедурного программирования. Вы также узнали, как:

Для этого вы использовали подмножество модулей pygame, включая модули display, mixer и music, time, image, event, и key. Вы также использовали несколько классов pygame, в том числе Rect, Surface, Sound и Sprite. Но это только царапает поверхность того, что в pygame можно сделать! Ознакомьтесь с официальной документацией pygame для получения полного списка доступных модулей и классов.

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

Спасибо за прочтение данной статьи!

Главный вопрос в следующем: вы хотите создать одну игру и забыть о ней или сделать карьеру в геймдеве?

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

Хочу стать профессионалом в геймдеве

Если вы хотите сделать карьеру в геймдеве, то учить C++ (например) — точно придётся, это лишь вопрос времени. Знание этого языка поможет вам, даже если вы не будете работать на нем регулярно. Как только вы освоите C++, вы сможете легко перейти к другим языкам, которые как раз и используются в программировании игр. И это не только языки группы С.

Какой язык программирования нужен

Языков — очень много. Но профессионалам геймдева, в конце концов, требуется 2-3 языка, не больше. В любом случае, понадобится C++ — это самый важный язык программирования в индустрии игр. Другие языки, которые вы должны знать: Python — для сред сборки, C# — для написания инструментов и Lua — для написания сценариев. 

Пример скриптинга на Lua

Но если вам нужно сконцентрироваться на чём-то одном и то, что 100% пригодится в дальнейшем — это C++. Единственное исключение из этого правила: если вы хотите писать игры для устройств iOS (iPhone и iPad) — учите Objective-C.

Вот самые популярные инструменты, которые сегодня применяются в геймдеве:

• Unity.
• CryEngine.
• RPG Maker.
• Unreal.
• LibGDX.
• Godot.
• Game Maker (только 2D)

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

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

Пример элементарной игры на C++

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

Игровые движки

Для программирования игр пригодны далеко не все языки. Например, тот же Python — предназначен для удобства чтения. И на самом деле он используется в геймдеве, но для второстепенных задач (например, для создания прототипов игровых идей). Для разработки конечного продукта — Python не подходит. Ниже мы разобрали пять языков, которые точно пригодятся разработчику игр.

Lua

Легкий скриптовый язык, который используется во многих отраслях, включая гейм-разработку. Lua прост в изучении и использовании, а также быстр (что, кстати, является необычным сочетанием).

Скрипты Lua часто используются с мощными движками, например, с Unreal Engine

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

Хотя некоторые игровые движки поддерживают Lua, он не так широко используется, как другие языки, но все же — это отличный выбор для создания 2D-игр.

Популярные игровые движки, использующие Lua:

• Solar2D.
• LÖVE.
• Gideros.

Недостатки Lua:

• Используется не повсеместно.
• Ограничен индустрией.

C++

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

В чем разница между С++ и C#

C++ — это реально очень сложный язык для обучения, поэтому начните свои первые шаги с хорошего игрового движка. Создавать игровые движки — также очень сложно, но вот писать игры поверх готовых движков — гораздо проще. Существует множество бесплатных движков, хотя большинство из них — это просто рендеры 3D-графики. 

C++ априори будет быстрее, чем C#, но для запуска игры он требует больше времени. С++ также может показаться более сложным (например, из-за указателей).

И в С++ вообще очень много вещей, которые могут сбить с толку, если вы не разбираетесь в программных компонентах компьютера. Если вы не разбираетесь в аппаратной части и не хотите разбираться — лучше выбрать C#.

Почему С++ быстрее

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

Пример простой игры на С++

C++ также предлагает различные парадигмы программирования (объектно-ориентированное и на основе данных). Многие из самых популярных игровых движков поддерживают C++, а это значит, что существует множество инструментов и готовых библиотек, которые разработчики могут использовать для создания своих игр.

Популярные движки, использующие C++:

• Unreal Engine.
• Unity.
• CRYENGINE.
• Amazon Lumberyard.

Минусы C++:

• Сложно изучать.
• Небезопасное управление памятью.
• Не кроссплатформенный. Да, вы можете написать код на C++, который будет компилироваться на разных платформах, однако, скомпилированные двоичные файлы не будут кроссплатформенными. Кроме того, многие функции и библиотеки зависят от платформы. Так что, написание действительно кроссплатформенного кода на C++ — будет ограничено.

Язык C#

Обладает многими теми же преимуществами, что и C++. Особенно хорошо подойдет для разработки 2D- и 3D.

Одним из плюсов C# перед C++ является фактор простоты: его легче изучить. C# также является кроссплатформенным языком, что означает, что игры, разработанные на C#, можно запускать на Windows, macOS и Linux.

Пример игры на Unity, созданной на основе языка C#

Интеграция между C# и Visual Studio (также созданной Microsoft) превосходна, как и все инструменты отладки / тестирования.

Популярные движки, использующие C#:

• Unity.
• Unreal Engine.
• Godot.

Недостатки C#:

• Широко не используется.
• Ограничен экосистемой Microsoft.

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

Что выбрать для игр: C# или C++

• Если вы собираетесь использовать C# — выбирайте Unity.
• C++ поддерживается большим количеством движков. Оптимальные варианты — Unreal или Godot.

Java

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

Будучи платформо-независимым языком, благодаря виртуальной машине JVM, игры на Java можно запускать на любой операционной системе, включая Windows, macOS и Linux. 

Игра на языке Java

Java популярный выбор для разработки и мобильных игр, поскольку его можно запускать на устройствах iOS и Android. Кроме того, Java — язык для разработки нативных приложений в Android Studio. 

Некоторые игровые движки поддерживают Java, хотя он не так быстр, как C++, что может быть существенным недостатком для некоторых типов игр.

Движки, использующие Java:

• jMonkeyEngine.
• libGDX.
• Java 3D.

Недостатки:

• Сложный для изучения.
• Может быть медленным, особенно в устаревших устройствах.
• Не так популярен как C++.

JavaScript

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

JS не так быстр, как C++ или Java, но он подходит для разработки двухмерных игр.

Эта игра на JavaScript занимает около 13 килобайт

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

Популярные движки, использующие JavaScript:

• Phaser.
• PixiJS.
• Cocos2d-x.

Недостатки JavaScript:

• Не такой быстрый, как другие языки.
• Не так распространен в gamedev.
• Ограничен браузером.

Как выбрать платформу 

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

Пример игры на Godot

Вот лучшие движки для различных целей:

• 2D: Buildbox и Godot.
• 3D: Unity и Unreal Engine.
• Разработка для iOS: SpriteKit (только 2D).
• Создание для Android: Unity.
• Мобильный движок, удобный для новичков: Buildbox и Unity (судя по огромному количеству обучающих материалов).
• Кроссплатформенный движок (мобильный, ПК и игровые консоли): Unity и Unreal Engine.
• Движки без кода: Buildbox и Gamemaker.
• Разработка гиперказуальных продуктов: Buildbox и Unity.

Основные компоненты игры

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

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

Прокачка уровня героя является одним из элементов игровой механики

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

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

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

Место действия Far Cry 4 — Кират, вымышленная страна в Гималаях. Описание игрового мира и есть сеттинг

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

Серия GTA — пример проработанного и открытого мира с которым можно взаимодействовать 

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

Многие тайтлы хочется проходить, не в последнюю очередь, из-за интересного сюжета

При этом важно, чтобы сценарий представлен в последовательной и понятной форме, чтобы персонаж мог с ним взаимодействовать. Если сюжет / повествование / история беспорядочны, игра может развалиться.

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

Многие удачные игрушки мы помним только благодаря качественной музыке

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

Как строится игровой код

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

ИИ

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

NPC в Counter Strike: Source

Физические законы

Эта часть кода регламентирует физические законы внутри игры. Например, как падает предмет с высоты на землю или как двигается стрела, выпущенная из лука (и куда она отлетает, в случае столкновения с твердым препятствием).

Физика не может быть одинаковой для каждого объекта

Внутриигровой баланс

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

Без баланса геймплей просто развалиться

Графическая оболочка

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

Графика, все еще, отличима от реального мира, но в некоторых случаях — она максимально приближена к нему

Этапы создания

Этапов создания, конечно, гораздо больше, чем три. Но мы рассмотрим основные стадии разработки.

Pre-Production

На пре-продакшене решается множество вопросов:

• О чем будет игра.
• На какую аудиторию она рассчитана.
• На какой рынок она нацелена.
• Какие игры будут конкурентами.
• Где и когда она будет опубликована.
• Как будет продаваться.
• Сколько времени потребуется на разработку.
• Какие ресурсы и какой бюджет потребуются для производства.

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

В идеале предпроизводство, обычно, занимает около 20% времени, отведенного на все этапы процесса разработки продукта.

Производство

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

Пост-продакшн

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

Первый проект — с чего начать

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

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

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

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

Что посмотреть: видеоуроки, каналы ютуб

Наконец — несколько видео, которые помогут сформировать правильное представление о том, как это: быть геймдевом и программировать в этой отрасли.

One Year of Game Development with Unreal Engine: My Journey. Одиночный независимый разработчик, пытается делать игры. Самоучка в области 3D-моделирования и разработки с базовыми знаниями Java, полученными в университете, расскажет о своем опыте использования Unreal Engine 4 и 5, а также Unity.

ЧТО Я УЗНАЛ ЗА 9 ЛЕТ В ГЕЙМДЕВЕ | Game dev by Artalasky. Действующий геймдев делится своим опытом за 9 лет. Колоссальный багаж знаний, реальный опыт, неприятные ошибки, несколько инсайтов. Все это ждет вас в видео.

8 Months of Game Dev in 13 Minutes. Разработчик делится опытом создания игры в течение восьми месяцев за 13 минут. Концепция, сложности, движки, механика, и всё это — в одном видео.

IT профессии: РАЗРАБОТЧИК ИГР или GAME DEVELOPER. Как попасть в ГЕЙМДЕВ c нуля? Видео о профессии Game Developer. Всё, что нужно знать будущему разработчику в одном видео.

Game development is HARD. Gamedev — это всегда сложно. И в этом видео — вы узнаете, почему. Обязательно посмотрите, чтобы понять основные вызовы, с которыми сталкиваются game-разработчики.

Should You Be a Game Developer?

Если вы когда-нибудь задумывались о том, стоит ли становится Game Developer — это видео для вас. Разработчик с 20-летним стажем в играх расскажет о том, каково это на самом деле — быть геймдевом. Интересные подробности о Unity3D и Unreal. А также — плюсы и минусы профессии. 

Коротко о главном

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

1. Тщательно документируйте дизайн в том виде, в котором вы видите его в данный момент. Не пытайтесь расширить его, просто зафиксируйте то, что у вас есть сейчас.
2. Выберите инструмент и язык. Вариантов много, C++, Java, Unity, UE — лучшие из них.
3. Изучите инструменты, движки и язык досконально. Сделайте несколько простых проектов с изучаемыми инструментами. Например, создайте локальную игру по типу танчиков для Dendy, а затем — расширьте ее до многопользовательской. После — придумайте еще более сложный вариант.
4. После каждого небольшого подпроекта — пересматривайте свой проект и подумайте: чему вы научились и как это повлияло на ваш стек.