Стикнулися тут з проблемою: текст для перекладу гри — це просто здоровезний список рядків у довільному порядку без жодного контексту. Виходить, що перша фраза в діалозі може бути з аідійшкою #23456, а наступна вже #76543 (тобто між ними 50 тисяч інших текстових шматків). Отже, дуже складно зробити переклад узгодженим — купу енергії потребує.

Але ж у самій-то грі ці рядки якось повʼязані в суцільний діалог! А значить, є шанс цю інформацію звідти видобути. Цим я й зайнявся.

Про сам процес розкопування ресурсів гри я згодом ще розповім, а зараз скажу лише, що мені це вдалося. Половина справи зроблена.

А інша половина — це відображення цих даних. Тож сів і зробив інструмент для перегляду діалогів. Про фічі вже розповів у відосі, а тут напишу про технічну складову.

У вебі я не тямлю, але знайомий топовий чувак @marktanashchuk порадив мені SvelteKit, і мені норм зайшло. Замість ноди я взяв Bun, бо він принаймні швидко працює, до того ж підтримує 🕸 з коробки.

Майже все написав мені 🐈 Copilot (з Claude 4). За три дні на це пішла приблизно половина місячної норми токенів 😆 Закласти фундамент проєкту було найскладніше. ШІ-шка традиційно згенерувала дохуїльйон коду, зробивши низку некоректних припущень. Довелося це все видаляти й іти дрібнішими кроками. Згодом в пригоді став 💻-сервер для DevTools, завдяки якому можна ШІ-агенту прям сказати: «Піди й сам подивися, що за лайно ти наробив», — а він іде, дивиться й виправляє (а завдяки хот-релоаду й перевіряє одразу).

Всі діалоги насправді експортовані в JSON Canvas, який виявився відкритим форматом. Рендер графа робиться через D3 в SVG з домішками HTML через <foreignObject>. Потім з цього збирається статичний вебсайт, який я через GitHub Actions розгортаю на Cloudflare Pages.

Завдяки цьому всьому тулза не залежить від конкретної гри. На прикладі у відео діалоги з першої Baldur's Gate, яка звісно вже давно перекладена. З 18 МБ вхідних даних на виході отримав 56,5 МБ сайт, тобто роздуло його втричі. Зате не вимагає виконання жодного коду на сервері взагалі.

На перших порах розробки, коли мій рендер був ще такий собі, використовувати JSON Canvas було дуже зручно, адже будь-який експортований діалог можна було переглянути в тому ж Obsidian. Зараз вже бачу, наскільки їхня спека мене обмежує. Думаю, згодом, може, зроблю власну надбудову.

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

Згодом зʼявився настрій то все покращити. А для цього треба розібратися, як у ресурсах гри що зберігається. На щастя основну роботу зворотної розробки вже проробили модери й навіть документували структуру файлів, тож мені лишалося цим скористатися.

Отже, в старих іграх на рушії Infinity Engine — Baldurʼs Gate, Planescape: Torment тощо — структура приблизно така: є key-файл (зазвичай називається chitin.key) і є тека data з низкою BIF-файлів (не дуже багато — штук 80, наприклад). Але фактично рушій працює з конкретними ресурсами: маю на увазі всілякі скрипти, зображення, описи анімацій, діалогів, звуки тощо. От їх якраз купа. Наприклад, у першій Baldurʼs Gate їх 37341 штука.

Але жорсткі диски в компах раніше були доволі повільні, а інколи й доволі малі, тому в певних випадках доводилося грати зі вставленим CD, який ще повільніший. Ну а файлові системи на вінді й зараз не фонтан у сенсі швидкодії. Тому читання такої кількості дрібних файлів напряму з жорсткого диска — це вирок. Натомість краще мати меншу кількість великих файлів. Саме так розробники й зробили (та й досі роблять).

Отож key-файл — це бінарний формат, який описує всі ресурси, а також де саме вони лежать. А лежать вони в BIF-файлах. Кожний BIF — теж бінарний: фактично архів, у який напаковані різні ресурси, тобто файли й тайлсети. Розробники їх згрупували якось для зручності.

Я вже мільйон разів писав, як мені подобається Kaitai Struct 🏗, тож не обійшлося без нього й цього разу. Писати бінарний парсер по готових спеках — якесь дивне задоволення, трохи медитативний процес навіть. Сидиш ото, пиришся в hex-редактор, щоб переконатися, що ніде не сплутав big-endian з little-endian — кайф! Хоча цього разу парсери конкретно для key та BIF сів писати мій дружбан.

А мені ж треба було вже працювати з конкретним типом ресурсів. В ідеалі я хотів би читати їх прямо з key+bif-файлів так само як це робить гра, але на той момент єдиним виходом було експортувати їх вручну іншим інструментом в локальну файлову систему. Постає питання: як написати код так, щоб потім не треба було його адаптувати?

Я пишу на 🦶 і спочатку думав абстрагувати якось процес читання в якийсь Reader абощо, а потім передавати його у свої обробники всюди. Але це якось кволо. До того ж якщо подумати, будь-який файл — це вже Reader, а точніше io.Reader. Тож гіпотетично можна написати свою імплементацію. Правда, виявилося, що для Kaitai одного io.Reader замало — треба ще io.Seeker, щоб можна було читати з будь-якого офсета.

Тут я натрапив на лібу spf13/afero, яка ніби трохи спрощувала все це. Тож я просто завʼязався на інтерфейс afero.Fs усюди у своєму коді, і на той момент працював з локальною файлухою. А згодом написав свою «віртуальну» файлову систему, яка дає змогу працювати з усіма запакованими ресурсами гри «прозоро» для користувача, хоча насправді я читаю їх прямо з BIF-файлів без проміжного видобування. І вуаля: підмінив одну фс на іншу, а воно досі працює 😎

Повільнувато трохи тільки 😅 Наприклад, видобування ~1200 файлів на 25 МБ загалом у мене на M1 Max ішло 2,5 хвилини 😂 Довелося зайнятися профілюванням, яке, маю зазначити, в Go дуже легко додати в програму! Посиділи трохи з тим же друганом, знайшли найболючіші місця, і тепер видобування всіх ресурсів на майже 2 ГБ загалом триває близько 12 секунд.

У підсумку скажу (знову) пару слів про Go 💻: я ще починаючи з торішнього Advent of Code писав, що мова мені не подобається. І в принципі це досі так. Вона якось деревʼяно відчувається, немає в ній наче фану зовсім. Але наскільки ж легко й зручно в ній доводити справу до кінця! От просто сідаєш і пишеш без виїбонів, а воно потім працює, так ще й компілюється в один бінарь для будь-якої системи. І тулінг зручний. Можливо, це наразі єдина розробка від ґуґла, яку я поважаю.

На торішньому Advent of Code я з певним успіхом намагався розвʼязувати задачі щодня різними мовами, зокрема на Haskell 💻, 💻, Nushell 🆕, Swift 🕊, Python 💻, Red 🔺, 💻, Nim 👑, 🦶, Elixir 💻, Dart 💻, SWI-Prolog 🦉, 💻, Janet 👩‍🦰, Crystal 🔮, 💻 й 🕸.

Не певен, чи цього року я робитиму так само, але накидайте мені, може, ще пропозицій? Напишіть, яку мову програмування на вашу думку варто спробувати й чому ✍️🧐

Там 🌌🌌🌌🌌 у стімі з 9️⃣2️⃣ знижкою (усього 119₴). Хто ще не пограв — це ваш шанс )

До речі про Steam 💨

Днями вирішив зробити собі невеличку базу ігор, яку заповнювати, звісно, руками не будеш. Так виявилося, що у стіма є відкрита API-шка!

Можна отримати основну інформацію про гру, знаючи її ідентифікатор. Останній можна подивитися, наприклад, в урлі сторінки в магазині. І потім хоп-хоп — і вся інформація легко дістається:

let gameId = '1328670'
let info = http get https://store.steampowered.com/api/appdetails?appids=($gameId) 
  | get $gameId 
  | get data

І далі вже можна дивитися, шо там:

> $info.name
Mass Effect™ Legendary Edition

> $info.genres
╭───┬────┬─────────────╮
│ # │ id │ description │
├───┼────┼─────────────┤
│ 0 │ 1  │ Action      │
│ 1 │ 3  │ RPG         │
╰───┴────┴─────────────╯

> $info.ratings.pegi
╭──────────────┬──────────────╮
│ rating       │ 18           │
│ descriptors  │ Violence     │
│              │ Bad Language │
│              │ Gambling     │
│ use_age_gate │ true         │
│ required_age │ 18+          │
╰──────────────┴──────────────╯

Або навіть отак:

> $info.supported_languages | split words | 'Ukrainian' in $in
false  # 😭

(Підіть, може, хоча б ШБТ 💙 попросіть у дискорді, щоб вони переклали… Ех.)

Я собі так навіть знятки екрана всі стягнув. Важать вони, до речі, доволі дофіга: на ≈150 ігор вийшло близько 900 МБ 🤯 Треба, мабуть, у WebP конвертнути.

Апішка має ліміти на кількість запитів за певний проміжок часу. Скільки точно, я не знаю. Якщо робити десь два запита на секунду, то наче не рубає зʼєднання, але якщо флудити частіше, то сервер починає кидати якусь з 500-х помилок, здається. За який час його попускає, я теж хз — просто VPN перемкнув собі, і далі запрацювало норм.

Уважний читач (так, ти 🫵) міг побачити, що URL-параметр в запиті називається appids, а не appid. Однак ні — одразу декілька передавати не можна, бо тоді їхній сервер повертає HTTP 400. Єдиний виняток — це комбінація з фільтром price_overview, яка працює:

> http get https://store.steampowered.com/api/appdetails?appids=1328670,1091500&filters=price_overview | transpose -d | rename id val | select id val.data.price_overview
╭───┬─────────┬────────────────────────────────╮
│ # │   id    │    val.data.price_overview     │
├───┼─────────┼────────────────────────────────┤
│ 0 │ 1328670 │ ╭───────────────────┬────────╮ │
│   │         │ │ currency          │ EUR    │ │
│   │         │ │ initial           │ 5999   │ │
│   │         │ │ final             │ 479    │ │
│   │         │ │ discount_percent  │ 92     │ │
│   │         │ │ initial_formatted │ 59,99€ │ │
│   │         │ │ final_formatted   │ 4,79€  │ │
│   │         │ ╰───────────────────┴────────╯ │
│ 1 │ 1091500 │ ╭───────────────────┬────────╮ │
│   │         │ │ currency          │ EUR    │ │
│   │         │ │ initial           │ 5999   │ │
│   │         │ │ final             │ 5999   │ │
│   │         │ │ discount_percent  │ 0      │ │
│   │         │ │ initial_formatted │        │ │
│   │         │ │ final_formatted   │ 59,99€ │ │
│   │         │ ╰───────────────────┴────────╯ │
╰───┴─────────┴────────────────────────────────╯

Тепер можна нагенерувати собі сторінок в обсідіані або кудись ще покласти 😎

#TIL на ґітгабі 🐈 в налаштуваннях можна ввімкнути режим високої контрастності. Значно ліпше виглядає!

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

Прочитав пару тижнів назад у пана К. (в «Мамкіному Архітекторі») допис із закликом писати в коментарі, хто чим користувався. І там хто про шо — від make до Jenkins. Воно й дійсно різниця не завжди очевидна, бо і те, й інше може виконувати приблизно ту саму роботу, а саме: запускати якісь скрипти, що викликають тули, туди-сюди перекладають файли, качають щось з інтернетів тощо.

Раніше я вже казав, що люблю, коли можна повністю зібрати й запустити проєкт однією командою, проте, так було не завжди. Користувався я й TeamCity, і Jenkins і ще бозна-чим. Коли GitHub Actions зʼявилися, я одразу на них перестрибнув через їхню (нібіто) простоту. Тож білд-система в мене щось компілювала базово, а потім вже Actions хоп-хоп файли кудись з теки у теку поклали, заархівували або викликали скрипт для інсталятора й оце все. Іншими словами, побудова проєкту була розмазана між білд-системою і CI.

Це незручно з низки причин.

По-перше, CI-ні скрипти дуже важко запускати локально: на вашому CI-сервері є власне оточення, нерідко доволі крихке 😆 гг, а також є купа додаткових штук для якоїсь там безпеки та ізоляції (щоб не вийшло, що дві джоби якось конфліктують) — це все важко, та й не сильно треба повторити локально. І якщо частину важливої роботи робить саме CI, то в якийсь момент може виявитися, що ніхто не знає, як той проєкт взагалі зібрати без нього. Небезпечна залежність, ще й потенційно «вузьке місце».

По-друге, якщо щось піде не так на CI, а щось раз у раз йде не так, то полагодити це стає значно складніше. Навіть діагностувати не завжди легко, особливо якщо локально важко запустити. Підтримкою неперервної інтеграції найчастіше займається окрема команда, доступи до всього є тільки в них, специфіку й нюанси оточення розуміють тільки вони — інша залежність і вузьке місце ланцюжка.

Тобто є сенс якомога більше речей виводити на рівень нижче (що корелює з загальним розумінням і практиками) — у білд-систему. Чи можна було б наробити 🐈 Actions для виклику окремо компілятора, окремо компонувальника, окремо тулів для підписування бінарів ключем? Та можна, але чомусь ніхто так не робить. Беручи це до уваги, стає очевидним, що інші задачі також краще виконувати на рівні білд-системи: встановлювати залежності, пакувати документацію, збирати інсталятори тощо.

А чи є сенс іти ще на рівень нижче — у саму програму? Мабуть можна й без білд-системи обходитися, але тут вже треба оцінювати складність і вартість. Наразі не маю для цього хороших прикладів використання на думці.

Урешті в тому проєкті ми досягли відносного успіху. Головна частина нашої джоби на CI мала отакий вигляд:

- name: Create package
  run: qbs build config:release profile:github-${{ matrix.os }}-ci qbs.architecture:${{ env.QBS_ARCH }} -p megaapp-${{ matrix.os }}-installer

Буквально одна команда, яка все збирає і пакує. Але необхідні залежності вже були в оточенні (компілятор + Conan + Qt). А зараз з Xmake навіть це не обовʼязково, бо він вміє все сам стягувати.

Розумію, що в декого «поцікавіше» ситуації бувають, коли локально в принципі важко щось запустити, бо треба мільйон контейнерів підняти в кластері. Можу хіба що поспівчувати, бо це дійсно складно без належної організації процесів 🙂 Утім навіть у таких умовах можна зробити зручно, я певен.

Якийсь чувак «зібрав докупи свої нотатки» про розробку UI-фреймворків. Вийшло понад 200 сторінок 😯 Доведеться полистати, бо це одна з моїх найулюбленіших тем.

(Посилання підрізав у пана Лютікова в «Шось про айтішку»).

Прочитав десь фразу:

30+ років — це той вік, коли з'ясовується, що ти навіть дихав усе життя неправильно.

Але сьогодні буде не про дихання, а про чистку зубів 🦷🪥

В дитинстві мені показали «алгоритм»: повозюкав туди-сюди щіткою, сполоснув рота від пасти, виплюнув — ну я так роками й робив, а шо.

Деякі сумніви почали зʼявлятися з появою в мене іригатора. Це такий прикольний пристрій, який фігачить воду під тиском. Дуже раджу, до речі. Так от я просто додав його у свій алгоритм: якщо все одно споліскувати рота водою від пасти, то чого б не робити це іригатором? Логічно? Логічно.

В який момент навіть додавав туди Listerine. Знаєте ж цього виробника? Вони роблять ополіскувач для ротової порожнини якраз — по всьому світу продається. Взагалі-то спочатку вони свою «формулу» намагалися впарювати людям як засіб для миття підлоги, як ліки проти гонореї тощо — але не пішло. Зате як ополіскувач для рота зайшло аж бігом. Можете віддячити їм за світову одержимість «свіжим подихом», бо до нього це не було прям такою проблемою серед людей. (Тобто, проблема-то насправді була, але люди це не сприймали як проблему).

Але повернімося до теми. Прикол іригатора в тому, що як би ретельно і вправно ти не чистив зуби, щітка ніколи настільки добре не вичистить усі щілини від залишків їжі, як він. Після іригатора з рота летить усе шо можна, аж з-під ясен якісь рештки дістає, їй-богу. Топова штука. І якось воно дивно виходить… ну, тобто… ти чистиш зуби щіткою й пастою, а коли потім «споліскуєш» іригатором, то виявляється, що ще пів рота хавки. Дурня якась.

Мене, щоправда, не одразу осяяло. Ще десь рік-другий я в такому режимі й продовжував користуватися. А потім я-я-як збагнув! Треба ж їх місцями поміняти! Спочатку іригатор, потім щітка з пастою, потім сполоснув, щоб паста ротову порожнину не розʼїдала своєю мʼятою. І прям усе на свої місця встало!

Ну, майже все, точніше. Подумав я про це ще рік, і почав схилятися до того, що якось тупо наносити пасту й тут же її змивати. У чому сенс, себто? Ще й зуб один став трохи чутливіший до холодного, на що стоматологиня якраз порадила пасту лишати на зубах. Капе-е-ець! Тепер-то реально все на своїх місцях. Це ж як автомийка: навряд чи ви спочатку наносите всілякі захисні шари на тачку, а потім миєте її від бруду.

І раптом виявилося, що усі ці написи на зубних пастах типу там sensitive repair або whitening — це не стовідсоткова маячня рекламна. Воно справді діє й робить краще, якщо тільки дати йому змогу. А деякі пасти навіть не настільки й мерзенні, щоб їх лишати на зубах.

Закладаюся, що ви-то все життя правильно робите. І що все це давно відомі факти, які ґуґляться за 2 хвилини. Однак річ у тім, що ґуґлити-то й не спадало на думку ніколи: ти просто робиш те, що ніби знаєш, як робити. А деякі ще й примудряються інших навчати. Дивовижно все-таки, наскільки люди схильні за деревами лісу не бачити. І наскільки звичка впливає на наше сприйняття 😬

Цікаве спостереження про впровадження інструментів в європейському автомотіві (і, певно, ще багато де).

От робили колись всі дизайни для UI у фотошопі, і це здавалося зручно. А потім зʼявився Sketch, і всі дуже швидко перейшли на нього, бо він закривав цілу низку потреб: по-перше, це вектор, а не растр, по-друге, можна бібліотеку компонентів створювати було, перевикористовувати їх для різних скрінів тощо. Щоправда, тільки на macOS 🙁 Згодом зʼявилася Figma 💻, яка певні речі ще сильніше спрощувала, як то, наприклад, спільна робота над одним документом, можливість користуватися навіть у бравзері тощо.

Всі миттєво на неї перестрибнули… але не автомотів 🙁 Чому? Ну бо дані десь у хмарах, а Figma не запарювалася зробити варіант з виділеним сервером абощо. А раптом дизайн майбутньої системи кудись не в ті руки потрапить (промисловий шпіонаж досі існує, я думаю), раптом хвіґму ту вашу зламають — гігантські втрати грошей потенційно. Отак воно роками тягнулося, і все нарешті узгодили, домовилися й вирішили мігрувати в неї. Що ж змінилося для цього? А нічого! Дані досі в хмарах 😆 Просто криза підтискає, конкуренти в Китаї не сплять (а роблять чік-чік і в продакшн™), а німці досі скетч-файли пересилають імейлами.

Ну нічого… Краще пізно, ніж ніколи. Хоча деякі виробники тільки зараз оце поступово на фігму переходять. Та годі про неї.

Тепер же в нас всюди ШІ для програмування. Окрім автомотіва звісно. Чому? Ну бо дані в хмари кудись ідуть 😂 І я не про написання якихось критичних систем в автомобілях — там ясно, що є купа сертифікацій, які просто не пройдеш зі згенерованим ШІ кодом (а якщо пройдеш, і потім щось «вистрілить», то це ще гірше) — ні, я про внутрішні тулзи навіть. Спочатку було повністю заборонене будь-яке використання. Згодом почали потроху послаблювати: можна отримати ліцуху на умовний копайлот чи клод, щоб потестувати, але спочатку треба створити заявку з детальним описом, нащо воно тобі, підписатися кровʼю, що використовуватимеш ШІ максимум для прототипів, які йдуть у смітник, почекати на апрув членів спеціальної ради, й тоді можна буде навайбкодити свій перший hello world.

Чи вважаю я, що це погано? Ні, не вважаю, бо дійсно є ціла низка нюансів, яким творці генеративних ШІ не приділяли значної уваги. Наприклад, використання чужих робіт для навчання своїх ВММ-ок, захист даних досі не надто переконливий, захист від нових векторів атак через ШІ-агентів тощо.

Чи знаю я, як правильно варто було б розвʼязувати питання активнішого впровадження ШІ? Ні, на це в мене теж рішення нема. Всі занепокоєння дійсно актуальні, ризики реальні й далі по списку.

Але що я знаю, так це те, що років за 3–5 жодні з цих питань так само не будуть вирішені. Навіть доволі ймовірно, що ще гірше стане. Але хтось з босів в автомотіві скаже: «та пофіг! впроваджуймо всюди ШІ!» — бо ринок змусить.

От тоді покатаємося 😂 (А взагалі я б, мабуть, не радив купувати моделі автівок пізніше за 2025 рік, бо хто його зна 😂)