F# *

Сегодня мы закончим ковырять порт тайловых миров на F#. Правда, в прошлый раз мы исчерпали запас того, что вообще можно было «портировать», поэтому переключим внимание на совершенно новые фичи. Все они касаются UI (в узком смысле), ну или, говоря терминами игровой индустрии, HUD (Heads-Up Display).

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

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

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

При этом следует понимать, что код разбираемого проекта предшествовал написанию текста и послужил первопричиной выбора тех тем, что попали в цикл. Поэтому нас ждёт очень много очень простого кода с примечаниями вида «это стало возможно благодаря <штуковине, что мы разбирали в цикле>». Конечно-же, я добавил некоторое количество экзотики, но сегодня наша задача — закончить с рисованием чего-либо (если не считать мини-карты, она вместе с GUI попала в последнюю главу) и собрать все заготовки в подобие игры.

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

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

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

Есть повод для размышлений!

Можно ли использовать размеченные объединения с одним вариантом (SCDU, Single Case Descriminated Unions) не только со строками, но и с другими типами? Можно ли накладывать бизнес-ограничения на такие штука, как количество позиций в заказе или дата рождения?

Скотт Влащин делится секретами разработки бизнес-логики на языке с алгебраическими типами. Подробности внутри.

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

Разберёмся, как это выглядит в языках с алгебраическими типами.

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

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

Попробуем?

Четвёртый пост из серии Скотта Влащина посвящена предметной области. Как с помощью типов описывать бизнес-правила? Как типы позволяют углубить понимание предметной области?

Узнаем прямо сейчас.

Новая глава из цикла Скотта Влащина. Обсуждаем, как сделать код надёжным с помощью развитых типов из F#.

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

<Картинка не влезла в превью.>

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

За остаток цикла мы должны выяснить, как можно строить среднеразмерные игровые сцены на F#, а также почему этот цикл называется так, как называется. Конкретно в этой главе мы разберёмся с RenderingServer-ом (бывший VisualServer), но не с нуля, а с позиций достигнутых в «Godot — рисование без правил» и «Прямоугольные тайловые миры». Если вы уже прочитали эти статьи, то вам должно быть известно, что рисование через RenderingServer — это довольно экзотический подход, который воспринимает хождение сквозь стены как рядовое событие. Авторы движка этому не препятствуют, но и не содействуют, поэтому документации по этому серверу — кот наплакал. Мне так и не удалось выудить ответы на все интересующие меня вопросы в словесной форме и их пришлось выковыривать при помощи живых экспериментов. Последние ни в статью, ни в проект не влезли, но тут важна сама парадигма, при которой мы всегда отталкиваемся от практики, а не от теории, которой пока просто нет.

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

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

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

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

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

<Картинка не влезла в превью.>

Она написана с применением только тех приёмов, что уже были хотя бы надкусаны в цикле, поэтому концовка получилась очень щадящая.

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

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

F# и C# в плане выразительности ООП различаются не так радикально, как некоторым кажется. Но у них разные дефолты, и мы вольны как бороться с ними, так и эксплуатировать их на полную катушку. Для этого необходимо понять, что F#-ный подход ориентирован на симуляцию процессов, а C#-ный — на симуляцию данных. Формально от нас требуется и то, и то, но по моему мнению, моделирование процессов — это 80% моей работы. Оставшиеся 20% — это данные, которые затачиваются под те же самые процессы.

C#-еры то ли обитают в другом мире, то ли как-то пропустили этот момент, поэтому систематически пишут код в обратном направлении — от данных к процессам. Первое время я думал о Godot в том же ключе, но чем больше ковырял <Prefix>Server-ы (там их много, VisualServer — это лишь один из подобных), тем больше у меня складывалось ощущение, что где-то в недрах его команды сидит вменяемый ФП-программист. Уж слишком сильно некоторые решения напоминали наши. К сожалению, я ещё многое не расковырял из того, что нужно расковырять для потенциального разрыва с дефолтным API. Поэтому в рамках текущего цикла мы не будем избавляться от ООП-нагромождений. Вместо этого мы нагородим новых, но так, чтобы нам было удобно работать в ФП-парадигме.

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

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

Мы ковыряли поиск пути через A* на протяжении двух глав и при этом были сосредоточены на синтаксических изысках F#. В этой главе мы отдохнём от синтаксиса и посмотрим на то, как этот алгоритм мог бы развиваться в более функциональном стиле.

В прошлой главе мы перенесли A* на F#, после чего в образовательных целях занялись выдёргиванием его «кишок» наружу. Тогда процесс «потрошения» не был завершён до конца, но сегодня мы его добьём. Что касается метагейма, то мы продолжим путь от функции к конструктору и даже успеем слегка залезть на «ту сторону».

Концепция этого цикла начиналась с простого переноса тайловых миров на F#. Однако в процессе его описания я основательно растёкся по древу, за счёт чего у нас образовался большой подготовительный этап из пяти глав про языковые фичи и прочую «фундаменталочку». Думаю, что с подготовкой закончено, поэтому сегодня мы обратимся непосредственно к тайловым мирам.

Но начнём мы практически с конца — с адаптации поиска пути. Это несложная задачка, но в процессе её решения мы успеем закрепить пройденный материал и по инерции заскочить в новый.