Почитайте отчётик (осторожно, Habr!) о мероприятии — я прям проникся!

Сам давно хочу поучаствовать в чём-то таком — самодельщицко-ролевиковом! Чтоб прям и софт тематический пописать, попаять да помакетировать из скотча, картона и поликапролактона (#diy or die!).

Надо-бы узнать, как в такое вписаться в следующий раз…

​​VR нынче на рынке много, а вот AR-проектов маловато — всех потеснил MicroSoft с их Holo Lens. И тем интереснее каждый новый проект в этой области. А уж Tilt Five просто чудесный!

Сейчас проект выставлен на KickStarter, описан довольно подробно, но вот промо-видео у кампании — исключительно развлекательно-завлекательное. А интересно-то как раз "мясо"! За мясом предлагаю пройти сюда: тут вам и описание технологий от одной из создателей, и демонстрация работы, и вѝдение перспектив проекта — рекомендую к просмотру!

Из видео я лично вынес следующее. Очки работают на отражённом свете, поэтому формируют сцену только в рамках специального коврика, покрытого отражающими микросферами (я бы уголковым отражателям порадовался, но сферы сделать проще, конечно). На каждый глаз работает свой проектор. Свет идёт от очков к коврику, отражается обратно и через специальное стекло попадает в глаз — никакого короткофокусного проецирования прямо в глаза, как у Google Glasses!. До смотрящего доходит 85% света от проектора, и это при том, что сами очки довольно прозрачные и не мешают смотреть на реальность одновременно с разглядыванием дополнений к оной! При этом каждый смотрящий видит только свою картинку, хотя коврик для всех общий — отличная задумка для любителей настолочек (это основная ЦА на данный момент).

Проекторы использованы собственной разработки, сильно широкоугольные, с поляризованным светом. Первое даёт возможность видеть сцену даже боковым зрением, если вдруг отвернёшься, а ещё — масштабировать пространство за счёт дополнительных ковриков. Второе (поляризация) нужно для селективности и для фильтрации стеклом очков. Теперь о выдаваемой картинке: 720р при 180 к/с на каждый глаз — внушительно!

Спросите, как быть уверенным, что картинка с заданными характеристиками будет успевать доезжать до очков с вычислителя (любой совместимый девайс, умеющий в USB)? Отвечу: это и не нужно, ведь вся геометрия отображения сцены на плоскость с учётом положения игрока относительно коврика делается на девайсе! Да, очки получают трёхмерную модель, не учитывающую положение головы игрока, а весь трекинг делают очки, используя широкоугольную ИК-камеру с подсветкой (эта камера и даёт привязку к границам коврика). Вторая камера, подсвечиваемая и "видящая" на другой длине волны, трекает физические предметы на столе — фишки и карточки с QR-кодами, а также специальные контроллеры-волшебные палочки.

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

Сейчас девайс работает с Unity, но потенциально сможет работать с другими движками. Создатели уже договорились с Fantasy Grounds о портировании их виртулальных сред для игры в настолки, а это уже серьёзно! Более того, будет работать cross play с теми, у кого ещё нет очков, но есть компьютер или мобильный девайс! Не замкнутая на себя система — это отлично!

Давно такого не было и вот я опять воодушевлён! Буду следить за прокетом!

#ar #gamedev

​​Есть такой аудиочип — MOS6581, в народе SID (Sound Interface Device). Чип очень любим и комодорщиками (фанатами #retrocomputer Commodore 64), и в целом любителями #chiptune.

Микросхема содержит три управляемых генератора тона и набор фильтров. Генераторы тона умеют генерировать колебания разной формы — пила, треугольник, прямоугольник и шум. Из фильтров доступны ФНЧ, ФВЧ, ПФ и комбинации. Более того, каждый генератор поддерживает управление ADSR! Словом, SID — настоящий трёхголосый Lo-Fi синтезатор в одном Narrow-DIP корпусе!

Для #sid пишется огромное количество музыки и сейчас, да и во времена молодости Коммодора писались свои "нетленки", вроде Monty's run от Роба Хаббарда (здесь можно и послушать и посмотреть визуализацию сигналов генераторов).

Существуют и специальные модификации железа вроде 2SID, позволяющие с того же C64 управлять сразу парой SID-чипов. Вот интересное видео по теме, заодно демонстрирующее работу в специальном композиторском ПО для C64 — MSSIAH (советую вообще присмотреться к каналу автора, если вас в целом цепляют чиптюн, синтезаторы и ретро-железки. И circuit bending заодно — про это тоже расскажу как-нибудь).

SID прекрасен, но вот ведь незадача, сами чипы уже давно не выпускаются. Да и в силу особенностей тех.процесса существующих чипов становится всё меньше — многие из них "умирают" в процессе перестановки с устройства на устройство (статика убивает)! Донорами являются всё те же C64, но и их кол-во ограничено.

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

Вторым может серьёзно помочь проект FPGASID. Как можно догадаться по названию, это реализация SID на #fpga. По заверениям авторов, FPGASID старается быть неотличимым от оригинала с точки зрения аналоговой части и самого звука. А ещё является "drop-in заменой" для старичка, т.е. может быть вставлен в кроватку, рассчитанную на оригинал! Более того, FPGASID умеет притворяться не только одиночным SID-чипом, но и той самой 2SID-сборкой! Теперь и у желающих "просто приобщиться", вроде меня, появилась возможность распробовать SID-чиптюн без необходимости шерстить eBay в поисках заветного "дохлого C64 с живым SID"!

В заключение добавлю ссылку на 2SID-кавер на "Space Oddity" Дэвида Боуи. Трек прям "с пылу, с жару", презентован в сентябре этого года. А тут, если не хватит одной лишь музыки, можно посмотреть на запуск FPGASID в космос под микс 2SID-версии "Space Oddity" с оригинальной песней — эпичненько!

​​Вот ещё пример #sid-музыки: шедевральный Last Ninja 2 OST, Central Park (по ссылке заодно и графику можете оценить. ИМХО, C64 в первую очередь звуком примечателен — на её фоне картинка впечатляет меньше).

У этого трека есть уйма каверов, вроде этого от Fastloaders, или этой версии от KATOD (модифицированный С64 с оригинальным SID, а ещё — электрогитара :)) и просто неплохого "метал-ремикса".

P.S. К KATOD присмотритесь, если ретромузычка подобного плана вам нравится. У них как раз недавно клип "Superkomputer" вышел тематический: PowerGlove, спектрумы, ковёр, бигуди — очень аутентично!

Я уже писал про свои эксперименты с WebAssembly/WASI, недавно даже подкаст-монолог про это дело записал. Словом, я за темой слежу, причём слежу именно за направлением "универсальных бинарников".

А тут такая новость: Mozilla, Intel, RedHat и Fastly создали Bytecode Alliance — сообщество по пилению того самого нового формата бинарников.

Суть: реализовать возможность запускать универсальны WASM-бинарники в защищённых окружениях на разных системах и при этом управлять а) зависимостями и б) доступом зависимостей к системным ресурсам. Пункт "б", ИМХО — самый интересный! Можно взять стандартную библиотеку работы со строками (ага, leftpad) и запретить ей доступ ко всему, кроме, собственно, работы со строками!

Fastly регулярно пишут про свои эксперименты с Rust/Wasmer и им очень интересна вся эта тема с управлением правами wasm-бинарников. FastlyLabs открытые проекты по теме пилят. Словом, прямой коммерческий интерес к такому применению Wasm уже есть. А это очень важно для выживания технологии!

Отдельно радует роль #rust в около'wasm'овой экосистеме: на нём и рантаймы пишутся и инструментарий вроде wascap. Не говоря уж о том, что Rust — один из первых языков, начавших прорабатывать компиляцию в Wasm.

Ждём, надеемся, держим руку на пульсе #wasm :)

​​Так уж случилось, что я тут веду очные занятия по "основам типизированного ФП", в качестве учебного языка использую, как водится, #haskell. На днях мы прошли монады и написали библиотечку парсер-комбинаторов. На очереди Transformers, robots in disguise… ой, не эти, а обычные ("monads in disguise"?).

Изначально записалось аж тридцать человек(!), десятка два начали ходить, сейчас ходят 8-10. Один ученик в своём блоге о занятиях даже заметку написал — приятно! А вот домашние задания делают не все, поэтому приходится разбирать оные на самих уроках…

Зато потихоньку нарабатываю методтички (Literate Haskell + PDF) — пригодятся для будущих сессий!

(на картинке находится акроним TFPB, от Typed Functional Programming Basics)

​​Я почему-то всегда думал, что я уже писал здесь про Propeller и саму контору Parallax. Оказалось — нет, не писал. Восполняю пропуск!

Есть такая фирма, Parallax. Занимается разработкой своих линеек микроконтроллеров, а также наборов для обучения робототехнике.

Эпоха Stamps

В 199х Parallax была известна своими BASIC Stamp — это такие микроконтроллеры, которые работают под управлением специализированной версии #BASIC. Каждый контроллер выглядел, как 24-ногая микросхема (на самом деле это была маленькая платка), которая для работы требовала только батареи на 9В. Достаточно высокоуровневый, язык PBASIC позволял управлять множеством видов периферии, код загружался в ППЗУ по последовательному порту (позже через USB2UART), а ведь до Arduino оставался ещё десяток лет! Платформа была достаточно популярна тогда, но имеет своих почитателей и сейчас.

В 1997 году Parallax запустили образовательную программу "Stamps in Class", которая знакомила учеников с микроконтроллерами, основам разработки программ и электронных схем. Ученики даже программировали роботов Boe-Bot (один из самых популярных продуктов Parallax), имеющих BASIC Stamp 2 в роли "мозга".

Что интересно, по началу BASIC Stamp и BASIC Stamp 2 делались на баже микроконтроллеров PIC, которые устанавливались на ту самую плату-сборку, имитирующую DIP-корпус. Позже Parallax начали применять свой собственный PIC-подобные контроллеры Parallax SX, и продолжали применять до 2009г, когда чипы были сняты с производства.

В 2002г Parallax сделали смелый шаг — выпустили Javelin Stamp. На этот раз "почтовые марки" предлагалось программировать на Java! Да, это была урезанная версия и языка и платформы, но всё равно это было впечатляюще!

А потом в 2006г stamps наконец перешли на Parallax Propeller и язык Spin. Об этом в следующем посте <музыка из JoJo>

​​(продолжение предыдущей записи)

Эпоха Propeller

Propeller, это уже полностью детище самой Parallax, микроконтроллер с процессором 32-битной RISC-архитектуры, имеющим восемь ядер (2006г, напомню!). Программировался контроллер на своём ассемблере, а также на отдельном языке Spin — всё это, а также IDE для Spin разработали сами Parallax!

Для чего же микроконтроллеру восемь ядер, спросите вы? Ответ на этот вопрос и делает Пропеллер таким интересным! Дело в том, что Propeller не нёс на своём борту выделенных аппаратных шин, вроде UART, SPI и i2c: вместо этого предлагалось реализовывать соответствующие шины программно и поручать их обслуживание отдельным ядрам! Даже вместо прерываний и таймеров предполагалось использовать именно отдельные ядра. Потенциальные возможности поражали, ведь получился "почти ПЛИС", только программируемый на процедурном языке: представьте, что вы можете сделать контроллер с семью последовательными портами (одно ядро будет таки выполнять вашу программу) или что-то вроде "3 SPI + 2 TWI + 2 Dallas 1-wire"!

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

Ввод-вывод был организован через один общий 32-битный порт со специальной подсистемой, защищающей от конфликтов при совместном доступе. Каждый из 32 пинов мог выдавать ШИМ!

Сам Spin был высокоуровневым языком, компилирующимся в байткод, который и выполнял Propeller на отдельных ядрах (их называли Cogs) — по интерпретатору на ядро. Язык использовал отступы для обозначения блоков, в коде допускались ассемблерные вставки.

Со временем появились компиляторы для C и PropBASIC (специальный диалект для Propeller), пара реализаций #Forth и прочие менее успешные поделки вроде подмножеств Pascal и Java.

Увы, железка получилась слишком уж специфической: для новичков она была сложна (трудно в голове уложить восемь программ), а для промышленности — слишком необычна. К 2010ым производство свернули.

В 2014 Parallax открыла под GPL 3.0 как всё ПО, так и всё "железо": код интерпретатора Spin, сред разработки, Verilog-описание процессора, HDL-файлы для обвеса. Так что Propeller 1 теперь полностью открыт. Хотя бы это радует!

Parallax тогда же объявил, что теперь они занимаются разработкой нового Propeller с производительностью 200 MIPS/Cog (вместо 20 MIPS на ядро у Propeller 1). Но я не знаю, в каком состоянии сейчас проект находится :(

Вторая жизнь Propeller 1

Так как платформа открыта, энтузиасты воплощают её в том или ином виде на FPGA. Есть и коммерческие реализации. Например, Soft Propeller от Trenz-Electronic — реализация Propeller на базе Xiliz Zinq (я как-то писал про Pynq — ПЛИС из этого же семейства, программируемый на Python). Что интересно, Soft Propeller физически совместим со старым "пропеллерным" железом: платка с ПЛИС, выполнена в том же формфакторе Narrow DIP, в котором выпускался оригинал, и может быть просто вставлена на место старого чипа! Люблю такое!

Давненько не писал. Будем считать, что был в творческом отпуске. Буду навёрстывать!

​​В прошлый раз я писал про #propeller, поделюсь ещё одной интересной штучкой с пропеллером!

К DEFCON'22' (DEFCON — это такая конференция для технарей) бейджики готовили сами Parallax. И, конечно же, бейджики были сделаны на основе Propeller! Тут можно почитать подробности. А я пройдусь "по верхам".

Каждый бейдж имел на борту помимо пропеллера ещё и ИК-трансивер (приёмник + светодиод), восемь светодиодов и четыре сенсорные кнопки. Ну и USB, конечно. При этом каждый бейдж был ещё и полноценной dev board для пропеллера: все порты были выведены на пятачки для пайки. ИК-трансивер был рассчитан на общение бейджиков между собой(!). Участники конференции обменивались таким образом контактами — забавно, правда? С эстетической точки зрения бейджи были тоже очень хороши: фигурные платы в разных цветовых схемах (фото прикреплю ниже), прям глаз радуется. Что интересно, именно на DEFCON'22 параллаксовцы официально объявили об открытии "исходников" Propeller — Verilog, схемы, вот это всё.

Но про бейдж DEFCON'22 я узнал, исследуя интернеты в поисках информации об этой прелести! Это тоже бейдж на пропеллере, но с OLED-экраном, тем же беспроводными средствами связи (ИК), и тоже представленный в нескольких цветах (разные цвета для персонала конференции, и для гостей). Пока я нашёл только эту заметку, в которой авторы делятся своим видением будущего устройства. Буду искать дальше, очень уж интересно.

​​В прошедшие выходные добрался таки до Pollen — системы для написании/программирования книг, построенной на базе #racket.

Racket я использую давно и знаю, что документация к языку и пакетам написана на отдельном диалекте Scribble, как уж это водится у "рэкетиров". И даже о Pollen я давно был наслышан — на Pollen "написана" отличная книга "Beautiful Racket" (а ещё "Practical Typography").

Pollen умеет обрабатывать Markdown и генерировать на его основе HTML, но может быть использован и в других сценариях. Самое интересное в системе, это специальный язык X-expressions — описание дерева документа, пригодное для дальнейшей обработки.

Так, все входные форматы сначала преобразуются в X-exps, а уже потом перегоняются в тот же HTML. Даже Markdown может быть преобразован в X-exps и дообработан программно перед преобразованием в HTML. И конечно же, обрабатывать X-exps и даже формировать можно с помощью Racket — Pollen является его надмножеством.

Подкину коду для демонстрации:

#lang pollen

◊(define who "World!")

◊div[#:class "content"]{
  ◊h1{
    Hello ◊|who|!
  }
  ◊strong{text}
}

"Ромбики" являются началами команд. S-exps являются Racket-кодом, а другие описывают разметку. Разметка при этом не выполняется, она просто записывается в X-exps как есть. А если учесть, что X-exps, имеет вид (div ((#:class "content")) (h1 () "Hello " who)) то вы можете догадаться, как Racket обрабатывает разметку и генерирует её сам :)

В конце итоговое X-exp скармливается шаблону, который превращает разметку в текст выходного формата. Причём выходных форматов может быть несколько! Книгу, скажем, можно преобразовать в HTML, а можно и в LaTeX/PDF.

При этом обрабатывает Pollen проекты по-взрослому — кэширует, раздаёт встроенным сервером контент (формирует контент налету).

Я на всём этом добре решил сгенерировать страничку для моей VDS с хобби-проектами. Получилось что-то такое: recursive.one. Контента, как обычно для меня, нет. Но сам "движок" писать мне понравилось :D. Как и в прошлый раз, когда я на #haskell и Shake движок написал.

Забыл написать, что этот свой Pollen generated site я запихал в #docker контейнер с lighttpd, чтобы самораздавайка получилась.

А контейнер задеплоил на VDS, на котором Dokku бегает — такой вот PaaS у меня для микропроектиков. Вот только heroku-style deploying через гит я не люблю, да и Heroku CLI мне не особо нравится. Поэтому загружаю образы целиком через docker save | ssh ... — для моих поделок на "не самых популярных стеках" самое то. Уже успешно "задоккивал" проект на #Clojure, Web-приветмир на #Racket.

Кому-то это всё покажется детскими играми. Но я не умею в этот ваш DevOps современный да и не очень-то и хочу уметь. Из современного освоил только Docker, а вся автоматизация на Makefiles сделана — не могу в k8s, зато могу в GNU m2e! И мне норм :)

Попробую новый экспериментальный формат: "Смотрите, какую дичь я писал когда-то", то есть "мои #old_projects".

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

Я, как настоящий самоучка, аж до моей второй работы варился исключительно в собственном соку. Учась в институте, я делал все свои проекты на Delphi, который изучил по его же встроенной документации, а дополнял знания из .CHM-книжек "Kuliba3000" (а может 4000, я уже и не помню) — был такой "самиздат" сборников статей из интернетов, прикладывался к дискам "сколько-то-там компонент для Delphi". Интернета у меня не было курса до третьего, так что на этом, собственно, мои источники информации и исчерпывались. Это к концу учёбы я добрался до интернета, форумов, Хабра. И узнал, что на Delphi писать зазорно. Ну да ладно, пост не об этом.

То, что я писал на QBASIC и TurboPascal в школе, увы не сохранилось — померло то ли на одном из старых "винтов", то ли на старых же дискетах. Этого вашего Git тогда ещё не было, а без интернета я бы всё равно не смог бы его использовать. Чудом сохранились лишь мои студенческие Delphi-поделки. Про одну из таких я и хочу рассказать.

​​Часть 1

Задумал я как-то написать движок для "point&click" квестов. Да, сразу движок. Потому что я откуда-то знал, что игры делают на движках, а не хардкодят каждый экран. Об анимации и визуализации персонажа я в принципе не думал. Предполагалось, что игры будут "от первого лица", как в "7th Guest" (ага, oldschool!). Был намечен абсолютный минимум: кликабельные объекты на экране, имеющие всплывающие подсказки, какой-то инвентарь, возможность изменять часть сцены (то есть наложение объектов на фон).

Нарисовал я пару экранов в XaraX, и начал думать, как бы разметить объекты сцены. В итоге выкрутился так: сделал невидимое изображение в 16-цветном .BMP, подложенное под изображение сцены. Позиция мыши "прокалывала" холст и я мог получить цвет задника. Цвет и был идентификатором объекта. 16 цветов, это 16 объектов — для одного экрана достаточно. Зато объекты могли состоять из нескольких областей и вообще иметь произвольную форму. А самое главное, я эту цветовую карту мог очень просто выгружать: я просто делал равномерную заливку в векторе, убирал сглаживание и экспортировал в .BMP. Этот формат использовался потому, что Delphi мог читать такие файлы самостоятельно и сжатие не вводило новые цвета, то есть не портило мне разметку.

Самый первый экран выглядел так:

​​Часть 2

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

Имя секции соответствовало имени файла (его базовой части) изображения фона — вот вам "convention over configuration"! Первая сцена имела фиксированное имя "begin", соответственно подгружались файлы "begin.bmp" и "begin_m.bmp" — второй, это "маска", то есть тот самый невидимый слой с выделенными цветом объектами.

В секции писалось что-то такое:

[begin]
00FF00=j{waystone}
00FF00_h=Путевой камень
FF00FF=m{Бедный Ёрик}
FF00FF_h=Череп
FF0000=j{pogost}
FF0000_h=Дорога налево
FFFF00=j{rockwall}
FFFF00_h=Дорога направо

При перемещении мыши брался текущий цвет подложки, по нему как по ключу, доставались действие по клику и hint (всплывающая подсказка) для объекта: в примере эти ключ в формате RRGGBB и он же, но с суффиксом "_h" (hint). С текстом всё понятно, а действие "j{pogost}" означает "перейти(jump) к секции pogost".

Ключи секции, имеющие префикс "#", описывали "спрайты", то есть накладываемые на подложку объекты. Имя ключа (без префикса) служило именем файла, а значение было числом, которое в формате "640 * y + x" кодировало позицию спрайта относительно верхнего левого угла. Ага, тут я поленился вводить раздельное кодирование координат ;). Если же значение было меньше нуля, то спрайт не рисовался — так можно было показывать и прятать спрайты.

Вот вам спрайт дерева, которое рисовалось поверх пенька на стартовом экране (смотрите предыдущий пост).

Часть 3

Использование координат спрайтов, а точнее — их изменение, это уже попахивает переменными! Да, таковые я тоже предусмотрел. Даже секцию "vars" завёл, которая инициализирует все переменные игры. Переменные имеют префикс "$", могут встречаться в роли значений, а в секции "vars" в роли ключей. Тут всё понятно и просто.

Но переменные нужно изменять. Для этого я прикрутил целый мини-DSL. Тот самый "j{…}", упомянутый ранее, это команда языка как раз. Изменяла переменные команда "s{$x=y}" — тут тоже всё очевидно, надеюсь.

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

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

[invnames]
001=Ворота (украдены на кладбище)
002=Топор (взят в Пещере Гоблинов)
003=Дубовое бревно

А вот так выглядело срубание дерева на стартовом экране:

00FFFF=i{002}g{003}s{$tree=-1}.M{Вы срубили топором дуб и сделали из него бревно}
00FFFF_h=Сухое дерево (Дуб)
#tree=$tree

- "i{002}" — если есть "топор",
- "g{003}" — дать "бревно",
- "s{$tree=-1}" — присвоить переменной $tree значение -1, то есть спрятать спрайт дерева,
- "." — перерисовать сцену (максимально лаконично!),
- "M{…}" — показать message box с указанным текстом.

"#tree=$tree" помещает спрайт дерева туда, куда указывает переменная. При перерисовке сцены переменная читается каждый раз, поэтому изменения и вступают в силу. Так на картинке первого экрана и появляется пень — просто пропадает дерево, выводимое поверх него!

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

Часть 4

Язык сценариев получился вполне себе выразительный — для данной задачи, конечно же. Можно было описать довольно сложные сценарии.

Например, в игре вы шли на кладбище, брали там ворота (дверцу калитки), шли с ней к пещере со рвом перед входом, перекидывали калитку через ров на манер моста, и попадали в пещеру. Тут вам и взятие объектов и выбрасывание ("d{id}"), условные переходы, опять же.

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

С технической стороны всё получилось максимально прямолинейно. Парсер DSL у меня был однопроходный — просто посимвольно обходил строку однократно, сразу же выполняя команды. Никаких грамматик, никакого backtracking: я и слов-то таких не знал тогда — имел то, до чего додумался сам. Зато было весело!

Игру саму я тогда не доделал, конечно. Допилил движок, и игра стала "реализуема". Дальше уже наступал черёд игрового дизайнера и сценариста, затем — художника. А вот эти роли мне были не так интересны, поэтому игра осталась в виде "proof of concept" с четырьмя игровыми экранами. Но своё удовольствие я получил. И догадался сохранить исходники, что позволило в итоге написать эту серию %^D