игры на python примеры кода
Разработка игры под Android на Python на базе Kivy. От А до Я: подводные камни и неочевидные решения. Часть 1
Некоторое время тому назад я решил попробовать написать что-то на Python под Android. Такой странный для многих выбор обусловлен тем, что я люблю Python и люблю Android, а ещё люблю делать необычное (ну хорошо, не самое обычное). В качестве фреймворка был выбран Kivy — фактически, безальтернативный вариант, но он мне очень понравился. Однако, по нему не так уж много информации (нет, документация отличная, но иногда её недостаточно), особенно на русском языке, а некоторые вещи хоть и можно реализовать, но их то ли никто раньше не делал, то ли не счёл нужным поделиться информацией. Ну а я счёл 🙂 И этот пост тому результатом.
Под катом я расскажу обо всех этапах разработки, о том, как развивалась простая идея и как для этого приходилось искать новые возможности, о возникших подводных камнях и багах, о неочевидных решениях и устаревшей документации 🙂 Цель — описать в одном тексте основные пункты, чтобы человеку, решившему написать что-то немного сложнее игры Pong из официального туториала, не приходилось перерывать официальный форум поддержки и StackOverflow и тратить часы на то, что делается за пару минут, если знаешь, как.
0. Если вы впервые слышите о Kivy.
… то всё зависит от того, любите ли вы Python и Android, и интересно ли вам в этом разобраться. Если нет — проще забить 🙂 А если да, то начать нужно с официальной документации, гайдов, и уже упомянутого официального туториала по игре Pong — это даст базовое представление о фреймворке и его возможностях. Я же не буду останавливаться на столь тривиальных вещах (тем более, для понимания базовых принципов туториал отлично подходит) и сразу пойду дальше. Будем считать, что это было вступление 🙂
1. Немного о моей игре
Для начала нужна была идея. Мне хотелось что-то достаточно простое, чтобы оценить возможности фреймворка, но и достаточно интересное и оригинальное, чтобы не программировать ради программирования (это здорово, но когда это не единственная цель — это ещё лучше). Я неплохо проектирую интерфейсы, но не умею рисовать, поэтому игра должна была быть простая графически, или вообще текстовая. И тут так уж сложилось, что у меня есть заброшенный сайт с цитатами, с которого я когда-то начинал свой путь в web-разработке (я о нём даже писал на Хабре много лет назад). Поэтому идея возникла такая: игра-викторина «Угадай цитату». В русскоязычном Google Play ничего подобного не было, а в англоязычном была пара поделок низкого качества с сотней скачиваний.
Почти сразу же стало понятно, что просто так отгадывать цитату за цитатой — скучно. Так появились первые «фишки», которые, в итоге, и определили итоговую игру. В первую очередь это были тематические пакеты (то есть пакеты цитат, объединённые одной темой или автором) и баллы (которые начисляются за отгадывание цитат и прохождение пакетов, и тратятся на подсказки и разблокировку новых тем), а также статистика, достижения и избранное.
Так всё начиналось (кликабельно): 
Ну ладно, ладно, больше не буду показывать такой ужас 🙂 Кстати, вот так оно выглядит сейчас (тоже кликабельно, скрины взяты с Google Play):
Первые проблемы начались с первого же экрана…
2. Kivy тормоз или я что-то делаю не так?
Один мой друг любит отвечать на такие вопросы «да» 🙂 На самом деле, некоторые вещи в Kivy действительно работают медленно, например, создание виджетов. Но это не значит, что это дело нельзя оптимизировать. Об этом я и расскажу.
Так как цитаты и темы хранятся в БД, то, само собой, кнопки с пакетами генерируются динамически. И вот тут-то я обнаружил, что происходит это очень медленно: примерно полсекунды на список из 20 кнопок. Возможно, это и не очень много при загрузке приложения, но при переходе на главный экран из других внутренних экранов приложения — непозволительно много. Здесь стоит отметить, что кнопка к тому моменту уже представляла собой, на самом деле, набор из нескольких элементов, визуально составляющих одну кнопку:
Первым моим побуждением было тем или иным образом закешировать их, и, действительно, опыт показал, что если создать все виджеты заранее, и сохранить их как свойство объекта StartScreen, то всё (кроме первой генерации) работает достаточно быстро. Однако же, данные в кнопках нужно периодически обновлять (хотя бы то же количество отгаданных цитат). Да и загрузку новых пакетов я уже тогда планировал. Конечно, не проблема реализовать и это, но я решил не изобретать велосипед и подумать.
Сначала стоило убедиться, что проблема именно в создании виджетов, поэтому я за несколько минут набросал простенькое приложение на два экрана, в каждом из которых генерировался набор строк из лейбла и чекбокса количеством 50 шт. 🙂
Запустил на своём стареньком Moto G (gen3) и получил:
И далее в том же духе. Поиск по этому вопросу ничего не дал, поэтому я обратился к разработчикам. И получил ответ: «Создание виджетов относительно медленное, особенно в зависимости от того, что они содержат. Для создания больших списков лучше использовать RecycleView». Здесь хочу пояснить, почему я вообще описываю этот момент, ведь описание RecycleView есть в документации. Да, действительно, есть, но мало кто способен изучить и запомнить всю документацию перед тем, как начнёт разработку, и найти нужный инструмент бывает непросто, особенно если он нигде не описан в контексте решения конкретной проблемы. Теперь же он описан 🙂
Более чем в 100 раз быстрее. Впечатляет, не правда ли?
В завершение следует упомянуть, что RecycleView — не панацея. Он не подходит, если размер элемента зависит от содержимого (например, Label, размер которого меняется в зависимости от количества текста).
3. Сервисы. Автозапуск и перезапуск
Следующая проблема, с которой я столкнулся, не поддавалась решению так долго, что я уже малодушно подумывал счесть данный фреймворк непригодным и забить 🙂 Проблема была с сервисами (в Android так называется процессы, выполняющиеся в фоновом режиме). Создать сервис не так уж и сложно — немного сбивает с толку устаревшая документация, но и только. Однако, в большинстве случаев, много ли толку от сервиса, который, во-первых, не запускается автоматически при загрузке телефона, а во-вторых, не перезапускается, если «выбросить» приложение свайпом из диспетчера задач? По-моему, нет.
На тот момент по этой теме была всего лишь одна статья в официальной wiki, но она, хоть и называлась «Starting Kivy service on bootup», на самом деле всего лишь рассказывала, как при загрузке телефона запустить приложение, но не его сервис (да, такое тоже бывает полезно, но значительно реже, как по мне). Ту статью я, в итоге, переписал, а здесь расскажу подробности.
Допустим, у нас есть примитивный сервис, который всего-то и делает, что периодически выводит в лог строку (этим мы заранее исключаем баги, которые могут возникать из-за особенностей самого сервиса).
Из приложения мы запускаем его методом основного класса при помощи PyJnius:
Если APK собран правильно, при запуске приложения сервис будет стартовать, но этого недостаточно.
Для начала, попробуем сделать так, чтобы он перезапускался при остановке приложения (например, при снятии его из диспетчера задач). Конечно, можно было бы использовать startForeground, но это уже не совсем фоновое выполнение задачи 🙂 Для него потребуется, как минимум, уведомление — это не всегда подходит. В данном случае идеально подходит флаг START_STICKY, но мы же пишем на Python, что делает задачу не столь тривиальной — по крайней мере, при помощи PyJnius она уже не решается.
Ура, сервис рестартится. Всё? Конечно, нет 🙂 Потому что он тут же валится с ошибкой:
Проблема в функции onStartCommand(Intent intent, int flags, int startId), поскольку после перезапуска intent у нас null. Что ж, перепишем и её:
Проблема в том, что функция nativeStart() не получает нужных Extras. К сожалению, два из них мне пришлось захардкодить. В итоге выглядит это так:
Перейдём к автозапуску сервиса при запуске телефона. После предыдущей проблемы это будет уже проще. (На самом деле же всё было наоборот — я очень долго не мог понять, что именно нужно добавить, поскольку информации об этом не было вообще нигде, и сами разработчики тоже не знали, как решить данную задачу. И только разобравшись параллельно с вопросом перезапуска, я понял, что нужно сделать.)
Для начала понадобится разрешение RECEIVE_BOOT_COMPLETED — это просто. А затем — BroadcastReceiver, его придётся добавить в AndroidManifest вручную, но это тоже не проблема. Проблема в том, что в нём писать 🙂
Решение для запуска приложения (не сервиса) выглядит так:
Сначала я попытался просто переписать его для сервиса:
Думаю, вам уже понятно, что проблема в тех самых Extras. Мне же тогда об этом было узнать неоткуда. Но не буду тянуть, рабочий код выглядит так:
Локализация и мультиязычность
В целом, для локализации можно использовать gettext, или же поступить ещё проще — создать папку lang, в ней по файлу на каждый язык (например, en.py и ru.py), определить там все слова и фразы в виде переменных/констант, и далее подключить нужный модуль. Примерно так:
Статическая переменная использована для того, чтобы языковые константы было удобно использовать в kv-файле:
Библиотека Pygame / Часть 1. Введение
Это первая часть серии руководств «Разработка игр с помощью Pygame». Она предназначена для программистов начального и среднего уровней, которые заинтересованы в создании игр и улучшении собственных навыков кодирования на Python.
Код в уроках был написан на Python 3.7 и Pygame 1.9.6
Что такое Pygame?
Pygame — это «игровая библиотека», набор инструментов, помогающих программистам создавать игры. К ним относятся:
Игровой цикл
В сердце каждой игры лежит цикл, который принято называть «игровым циклом». Он запускается снова и снова, делая все, чтобы работала игра. Каждый цикл в игре называется кадром.
В каждом кадре происходит масса вещей, но их можно разбить на три категории:
Речь идет обо всем, что происходит вне игры — тех событиях, на которые она должна реагировать. Это могут быть нажатия клавиш на клавиатуре, клики мышью и так далее.
Изменение всего, что должно измениться в течение одного кадра. Если персонаж в воздухе, гравитация должна потянуть его вниз. Если два объекта встречаются на большой скорости, они должны взорваться.
В этом шаге все выводится на экран: фоны, персонажи, меню. Все, что игрок должен видеть, появляется на экране в нужном месте.
Время
Еще один важный аспект игрового цикла — скорость его работы. Многие наверняка знакомы с термином FPS, который расшифровывается как Frames Per Second (или кадры в секунду). Он указывает на то, сколько раз цикл должен повториться за одну секунду. Это важно, чтобы игра не была слишком медленной или быстрой. Важно и то, чтобы игра не работала с разной скоростью на разных ПК. Если персонажу необходимо 10 секунд на то, чтобы пересечь экран, эти 10 секунд должны быть неизменными для всех компьютеров.
Создание шаблона Pygame
Теперь, зная из каких элементов состоит игра, можно переходить к процессу написания кода. Начать стоит с создания простейшей программы pygame, которая всего лишь открывает окно и запускает игровой цикл. Это отправная точка для любого проекта pygame.
В начале программы нужно импортировать необходимые библиотеки и задать базовые переменные настроек игры:
Дальше необходимо открыть окно игры:
Теперь необходимо создать игровой цикл:
Раздел рендеринга (отрисовки)
Начнем с раздела отрисовки. Персонажей пока нет, поэтому экран можно заполнить сплошным цветом. Чтобы сделать это, нужно разобраться, как компьютер обрабатывает цвета.
Экраны компьютеров сделаны из пикселей, каждый из которых содержит 3 элемента: красный, зеленый и синий. Цвет пикселя определяется тем, как горит каждый из элементов: 
Каждый из трех основных цветов может иметь значение от 0 (выключен) до 255 (включен на 100%), так что для каждого элемента есть 256 вариантов.
Узнать общее количество отображаемых компьютером цветов можно, умножив:
Теперь, зная, как работают цвета, можно задать их в начале программ:
А после этого — заполнить весь экран.
Но этого недостаточно. Дисплей компьютера работает не так. Изменить пиксель — значит передать команду видеокарте, чтобы она передала соответствующую команду экрану. По компьютерным меркам это очень медленный процесс. Если нужно нарисовать на экране много всего, это займет много времени. Исправить это можно оригинальным способом, который называется — двойная буферизация. Звучит необычно, но вот что это такое.
Представьте, что у вас есть двусторонняя доска, которую можно поворачивать, показывая то одну, то вторую сторону. Одна будет дисплеем (то, что видит игрок), а вторая — оставаться скрытой, ее сможет «видеть» только компьютер. С каждым кадром рендеринг будет происходить на задней части доски. Когда отрисовка завершается, доска поворачивается и ее содержимое демонстрируется игроку.
А это значит, что процесс отрисовки происходит один раз за кадр, а не при добавлении каждого элемента.
В pygame это происходит автоматически. Нужно всего лишь сказать доске, чтобы она перевернулась, когда отрисовка завершена. Эта команда называется flip() :
Главное — сделать так, чтобы функция flip() была в конце. Если попытаться отрисовать что-то после поворота, это содержимое не отобразится на экране.
Раздел ввода (событий)
Игры еще нет, поэтому пока сложно сказать, какие кнопки или другие элементы управления понадобятся. Но нужно настроить одно важное событие. Если попытаться запустить программу сейчас, то станет понятно, что нет возможности закрыть окно. Нажать на крестик в верхнем углу недостаточно. Это тоже событие, и необходимо сообщить программе, чтобы она считала его и, соответственно, закрыла игру.
События происходят постоянно. Что, если игрок нажимает кнопку прыжка во время отрисовки? Это нельзя игнорировать, иначе игрок будет разочарован. Для этого pygame сохраняет все события, произошедшие с момента последнего кадра. Даже если игрок будет лупить по кнопкам, вы не пропустите ни одну из них. Создается список, и с помощью цикла for можно пройтись по всем из них.
Контроль FPS
Пока что нечего поместить в раздел Update (обновление), но нужно убедиться, что настройка FPS контролирует скорость игры. Это можно сделать следующим образом:
Команда tick() просит pygame определить, сколько занимает цикл, а затем сделать паузу, чтобы цикл (целый кадр) длился нужно время. Если задать значение FPS 30, это значит, что длина одного кадра — 1/30, то есть 0,03 секунды. Если цикл кода (обновление, рендеринг и прочее) занимает 0,01 секунды, тогда pygame сделает паузу на 0,02 секунды.
Наконец, нужно убедиться, что когда игровой цикл завершается, окно игры закрывается. Для этого нужно поместить функцию pygame.quit() в конце кода. Финальный шаблон pygame будет выглядеть вот так:
В следующем руководстве этот шаблон будет использован как отправная точка для изучения процесса отрисовки объектов на экране и их движения.
Библиотека Pygame / Часть 3. Больше о спрайтах
Третья часть серии руководств «Разработка игр с помощью Pygame». Она предназначена для программистов начального и среднего уровней, которые заинтересованы в создании игр и улучшении собственных навыков кодирования на Python. Начать стоит с урока: «Библиотека Pygame / Часть 1. Введение».
Графические спрайты
Разноцветные прямоугольники вполне можно использовать на старте разработки, чтобы убедиться, что игра работает, но рано или поздно захочется задействовать изображение космического корабля или персонажа для спрайта. Это подводит к первому вопросу: где брать графику для игры?
Где искать арт
Когда вам нужен арт для игры, у вас есть 3 варианта:
Первый и второй варианты подходят для творческих людей или тех, у кого есть талантливые друзья, но у большинства программистов рисование не входит в набор навыков. Поэтому остается интернет. Но здесь важно помнить, что нельзя использовать изображения, на которые у вас нет прав. Вы без проблем найдете изображение с Марио или любимым Покемоном, но их нельзя использовать, особенно если планируется выкладывать игру в интернет для других пользователей.
К счастью, есть хорошее решение — OpenGameArt.org. На этом сайте полно изображений, звуков, музыки и другого контента. Весь он лицензирован так, что его можно свободно использовать в играх. Один из лучших создателей контента на этом сайте — Kenney. Его можно найти, просто введя это имя в строку поиска или зайти на его сайт.
Особенность арта Kenney (помимо отличного качества) — он выпускает контент в коллекциях. Это значит, что разработчик получает различные изображения, выполненные в едином стиле, и нет необходимости брать картинки в разных источниках.
В этом уроке будет использоваться набор Platformer Art Complete Pack от Kenney, в котором полно графики для создания игры в жанре платформера. Нужно всего лишь скачать его и распаковать. Начнем с изображения p1_jump.png.
Или же можете просто скачать картинку отсюда.
Организация игровых ассетов
В первую очередь нужна папка для хранения ассетов. В играх так называют, например, арты или звук. Назовем папку “img” и перенесем туда изображение игрока.
Чтобы использовать изображение в игре, нужно сообщить библиотеке Pygame, чтобы она загружала файл. Для этого необходимо указать его местоположение. В зависимости от используемого компьютера этот процесс может отличаться, но поскольку нужно сделать так, чтобы игра работала на любом устройстве, необходимо загрузить библиотеку Python под название os и указать, где находится игра:
Специальная переменная __file__ относится к папке, в которой сохранен код игры, а команда os.path.dirname указывает путь к папке. Например, путь к коду на компьютере с macOS может быть такой:
Если используется Windows, тогда он будет выглядеть приблизительно вот так:
Разные операционные системы по-разному подходят к поиску местоположения файлов. С помощью команды os.path можно позволить ПК самостоятельно определять правильный путь (вне зависимости от того, используется “/” или “”).
Теперь можно точно указать местоположение папки “img”:
Если сейчас запустить программу, вы увидите маленького инопланетянина, который двигается по экрану. Но осталась одна проблема, которой не видно из-за черного фона. С помощью команды screen.fill() нужно поменять цвет фона, например, на синий. Теперь понятно, в чем проблема.
Файл изображения на компьютере — это всегда сетка пикселей. Вне зависимости от нарисованной формы, имеются дополнительные пиксели, заполняющие «фон». Нужно сообщить Pygame, чтобы она игнорировала пиксели, которые не нужны. В случае этого изображения речь идет о черном цвете, поэтому в код необходимо добавить следующее:
set_colorkey() говорит Pygame игнорировать любые пиксели конкретного цвета. Так выглядит намного лучше:
Вы освоили основы работы с Python! Время переходить к созданию настоящей игры. У нас есть руководство с процессом создания игры Shoot ’em up от начала и до конца.
Создание игр на Python 3 и Pygame: Часть 5
Это последняя из пяти частей туториала, посвящённого созданию игр с помощью Python 3 и PyGame. В четвёртой части мы научились распознавать коллизии, реагировать на то, что мяч сталкивается с разными игровыми объектами и создали игровое меню с собственными кнопками.
В последней части мы рассмотрим различные темы: конец игры, управление жизнями и очками, звуковые эффекты, музыку и даже гибкую систему спецэффектов. На десерт мы рассмотрим возможные улучшения и направления дальнейшего развития.
Конец игры
Рано или поздно игра должна закончиться. В этой версии Breakout игра заканчивается одним из двух способов: игрок или теряет все свои жизни, или разрушает все кирпичи. Следующего уровня в игре нет (но его легко можно будет добавить).
Game Over!
Полю game_over класса Game присваивается значение False в методе __init__() класса Game. Основной цикл продолжается до тех пор, пока переменная game_over не изменит значение на True:
Всё это происходит в классе Breakout в следующих случаях:
Отображение сообщения о конце игры
Обычно при завершении игры мы не хотим, чтобы окно игры молча пропадало. Исключением является случай, когда мы нажимаем на кнопку QUIT в меню. Когда игрок теряет последнюю жизнь, Breakout показывает традиционное сообщение ‘GAME OVER!’, а когда игрок выигрывает, она показывает сообщение ‘YOU WIN!’
Вот как выглядит функция show_message() :
Сохранение рекордов между играми
В этой версии игры я не сохраняю рекорды, потому что в ней только один уровень, и результаты всех игроков после разрушения кирпичей будут одинаковыми. В общем случае, сохранение рекордов можно реализовать локально, сохраняя рекорды в файл и отображая другое сообщение, если игрок побьёт рекорд.
Добавление звуковых эффектов и музыки
Игры — это аудиовизуальный процесс. Во многих играх есть звуковые эффекты — короткие аудиофрагменты, воспроизводимые при убийстве игроком монстров, нахождении сокровища или ужасной смерти. В некоторых играх также есть фоновая музыка, которая вносит свой вклад в атмосферу. В Breakout есть только звуковые эффекты, но я покажу вам, как воспроизводить музыку в ваших играх.
Звуковые эффекты
Давайте посмотрим, как эти звуковые эффекты загружаются и воспроизводятся в нужное время. Во-первых, для воспроизведения звуковых эффектов (или фоновой музыки) нам нужно инициализировать звуковую систему Pygame. Это делается в классе Game: pygame.mixer.pre_init(44100, 16, 2, 4096)
Затем в классе Breakout все звуковые эффекты загружаются из config в объект pygame.mixer.Sound и хранятся в словаре:
Теперь мы можем воспроизводить звуковые эффекты, когда происходит что-то интересное. Например, когда мяч ударяется об кирпич:
Звуковой эффект воспроизводится асинхронно, то есть игра не приостанавливается во время его звучания. Одновременно могут воспроизводиться несколько звуковых эффектов.
Запись собственных звуковых эффектов и сообщений
Запись собственных звуковых эффектов может быть простым и приносящим удовольствие занятием. В отличие от создания визуальных ресурсов, для него не требуется большого таланта. Кто угодно может сказать «Бум!» или «Прыг», или крикнуть «Вас убили. Повезёт в другой раз!»
Я часто прошу своих детей записывать звуковые эффекты и голосовые сообщения, сопровождающие текстовые сообщения, например ‘YOU WIN!’ или ‘GAME OVER!’ Единственное ограничение здесь — собственное воображение.
Воспроизведение фоновой музыки
Одновременно может играть только одна фоновая музыка. Однако поверх фоновой музыки может воспроизводиться несколько звуковых эффектов. Именно это называется микшированием.
Добавление расширенных возможностей
Давайте сделаем что-то любопытное. Разрушать кирпичи мячом интересно, но довольно быстро надоедает. Как насчёт общей системы спецэффектов? Мы разработаем расширяемую систему спецэффектов, связанную с некоторыми кирпичами, которая активируется при ударе мяча об кирпич.
Вот каким будет план. У эффектов есть время жизни. Эффект начинается, когда разрушается кирпич и заканчивается, когда завершается время действия эффекта. Что случится, если мяч ударится об другой кирпич со спецэффектом? В теории, можно создать сочетаемые эффекты, но чтобы упростить всё в исходной реализации активный эффект будет останавливаться, а новый эффект занимать его место.
Система спецэффектов
Спецэффект в наиболее общем случае можно определить как две функции. Первая функция активирует эффект, а вторая сбрасывает его. Мы хотим прикрепить эффекты к кирпичам и дать игроку чётко понять, какие из кирпичей являются особенными, чтобы они могли попробовать ударять их или избегать их в определённые моменты.
При создании кирпичей им может назначаться один из спецэффектов. Вот код:
Класс Brick имеет поле effect, которое обычно имеет значение None, но может (с вероятностью в 30%) содержать один из определённых выше спецэффектов. Заметьте, что этот код не знает о том, какие эффекты существуют. Он просто получает эффект и цвет кирпича и при необходимости назначает их.
В этой версии Breakout я выполняю срабатывание эффектов только при ударе об кирпич, но можно придумать и другие варианты срабатывания событий. Предыдущий эффект сбрасывается (если он существовал), а затем запускается новый эффект. Функция сброса и время запуска эффекта хранятся для будущего использования.
Увеличение ракетки
Эффект длинной ракетки заключается в увеличении ракетки на 50%. Её функция сброса возвращает ракетку к обычным размерам. Кирпич имеет цвет Orange:
Замедление мяча
Ещё один эффект, помогающий в погоне за мячом, заключается замедлении мяча, то есть уменьшении его скорости на одну единицу. Кирпич имеет цвет Aquamarine.
Больше очков
Если вы хотите больших результатов, то вам понравится эффект утроения очков, дающий по три очка за каждый разрушенный кирпич вместо стандартного одного очка. Кирпич имеет цвет dark green.
Дополнительные жизни
Наконец, очень полезным эффектом будет эффект дополнительных жизней. Он просто даёт вам ещё одну жизнь. Для него не нужен сброс. Кирпич имеет цвет gold.
Возможности, которые можно добавить в будущем
Существует несколько логичных направлений для расширения Breakout. Если вам интересно попробовать себя в добавлении новых возможностей и функций, то вот несколько идей.
Переход на следующий уровень
Чтобы превратить Breakout в серьёзную игру, нужны уровни, одного явно недостаточно. В начале каждого уровня мы будем сбрасывать экран, но сохранять очки и жизни. Чтобы усложнить игру, можно немного увеличивать скорость мяча на каждом уровне или добавить ещё один слой кирпичей.
Второй мяч
Эффект временного добавления второго мяча создаст огромный хаос. Сложность здесь в том, чтобы обрабатывать оба мяча как равные, вне зависимости от того, какой из них является исходным. Когда один мяч пропадает, игра продолжается с единственным оставшимся. Жизнь при этом не теряется.
Сохраняющиеся рекорды
Когда у вас есть уровни с увеличивающейся сложностью, желательно создать таблицу рекордов. Можно хранить рекорды в файле, чтобы они сохранялись после игры. Когда игрок побивает рекорд, можно добавить маленькие пиццы или позволить ему написать имя (традиционно всего из трёх символов).
Бомбы и бонусы
В текущей реализации все спецэффекты связаны с кирпичами, но можно добавить эффекты (хорошие и плохие), падающие с неба, которые игрок может собирать или избегать.
Подведём итог
Разработка Breakout с помощью Python 3 и Pygame оказалась очень увлекательным занятием. Это очень мощное сочетание для создания 2D-игр (и для 3D-игр тоже). Если вы любите Python и хотите создавать собственные игры, то не колеблясь выбирайте Pygame.
Я совершенно точно буду создавать на Python и Pygame и другие игры.