Оглавление "Программирование для игр"

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

Проблема №1. Символы Юникода могут состоять как из одного, так и из нескольких байтов. Использование последних в Thunkable X возникают сложности. Они автоматически не переносятся в текстовых полях, несколько символов воспринимаются как один, а при замене символов может произойти смещение оставшихся символов в текстовом поле или чудесное исчезновение одного или нескольких символов. Некоторое время назад бобёр отчитался, что проблема, вроде, решена, но товарищ явно поторопился. “Железное дерево” оказалось ему явно не по зубам. В результате, приходится довольствоваться однобайтовыми юнисимволами.

Проблема №2. Ширина символов разная и для создания ровного игрового поля без смещений приходится выбирать подходящие.

Для чего так напрягаться? Можно взять спрайты и напихать в них нужные изображения.

Проблема №3 – низкая производительность. Если Ёсик ещё как-то пытается бежать пешком, то Андроний сразу выбрасывает белый флаг. 200 спрайтов бобёр создаёт за 20 секунд (10 спрайтов в секунду). Так и хочется сказать, бобрик, заканчивай грызть деревья! Купи бензопилу и работай быстрее.

И как с такой производительностью можно что-то сделать? Это весёлая игра для тех, кто может что-то не только в God of War, Assassin’s Creed, Last of Us, танчики и ”нид фор спид”. Вместо игрового движка разработчики выкатили асфальтоукладочный каток, который может быстро лететь только в одном случае – даунхилл с Эвереста на свалку. Но мы попробуем расшевелить его и на прямой.

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

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

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

Символы Юникода имеют разную ширину по отношению к одинаковой высоте строки. Двумерное поле из них будет прямоугольным или квадратным.

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

  • Ширина символа рассчитывается исходя из необходимого их количества в строке
  • Количество символов в строке определяется исходя из заданной ширины символа

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

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

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

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


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

ширина холста / количество символов с строке

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

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