Kaption: Nakładka OCR, która Tłumaczy Dialogi Hoyoverse w Czasie Rzeczywistym

Genshin Impact i Honkai: Star Rail mają ogromne społeczności w Polsce, ale żadna z tych gier nie doczekała się polskiej lokalizacji. Gracze, którzy angielski znają tylko okazjonalnie, tracą niuanse fabularne, imiona bóstw, żarty w dialogach i wątki poboczne. W grach, które opierają się na długich rozmowach NPC i rozbudowanym świecie, to nie drobiazg — to połowa tego, za co się je lubi.

Kaption (wcześniej "Genshin-Subtitles") to aplikacja desktopowa na Windows, która czyta dialogi wprost z okna gry, dopasowuje rozpoznany tekst do wewnętrznej listy linii gry, a następnie pokazuje polskie tłumaczenie w nakładce nad oknem dialogu. Bez modów. Bez haczenia pamięci. Bez streamowania obrazu do chmury. Aplikacja czyta piksele tak, jak robi to Windows Snipping Tool, i cała reszta dzieje się lokalnie na Twojej maszynie.

To studium przypadku pokazuje, jak zbudowaliśmy Kaption od strony technicznej — potok OCR na GPU, trzystopniowy matcher, który radzi sobie z typowymi pomyłkami rozpoznawania, predykcję kolejnej linii dialogu, ochronę pakietów tłumaczeń i dystrybucję przez Velopack. Po drodze opiszę też błędy, które kosztowały nas trzy weekendy, oraz decyzje, które wydawały się oczywiste dopiero z perspektywy czasu.

Problem: Luka Lokalizacyjna i Złe Rozwiązania Zastępcze

Hoyoverse lokalizuje swoje gry na kilkanaście języków, ale polski nie jest na tej liście. W grach fabularnych, gdzie jedno zadanie potrafi mieć setki linii dialogu, bariera językowa skraca rozgrywkę do rzucania okiem na minimapę i klikania "pomiń". Znika cały kontekst — kto do Ciebie mówi, dlaczego, czego od Ciebie chce i co się właśnie wydarzyło w świecie gry.

Społeczność próbowała to rozwiązać na własną rękę, ale każda z istniejących ścieżek ma swoją cenę. Tłumaczenia na streamie wymagają drugiego monitora i osoby, która na żywo tłumaczy scenę — działa, ale nie w nocy o drugiej, gdy siadasz do gry po pracy. Mody, które podmieniają pliki gry, łamią sygnatury i potrafią zahaczyć o systemy anti-cheat. Zewnętrzne programy, które czytają pamięć procesu gry, budzą podobny niepokój i padają przy każdej aktualizacji.

Chcieliśmy narzędzia, które będzie czyste z perspektywy zasad korzystania z gry, odporne na patche i na tyle szybkie, żeby tłumaczenie pojawiło się zanim gracz zdąży przeczytać oryginał. Żadne z istniejących rozwiązań nie spełniało tych trzech warunków jednocześnie.

Dlaczego Nakładka, a nie Mod

Decyzja o formie aplikacji zapadła najwcześniej i była w zasadzie bezdyskusyjna. Nakładka pozostaje całkowicie poza procesem gry — nie musi wiedzieć o jej wewnętrznej strukturze, nie wymaga uprawnień administracyjnych i nie "rozmawia" z klientem gry na żadnym poziomie. Jedyne, co robi, to odczytuje piksele wyświetlone na ekranie i rysuje własne okno nad oknem gry.

Ta decyzja ma oczywiście koszty. Musimy rozpoznać tekst z obrazu zamiast po prostu go przeczytać z pamięci, a OCR bywa zawodny. O tym, jak sobie z tym radzimy, za chwilę. To podejście ma też naturalny związek z nowoczesnymi aplikacjami WPF, które pozwalają zbudować warstwowe okno z obsługą click-through — gracz klika "przez" nakładkę wprost w okno gry.

Potok od Pikseli do Tłumaczenia

Kaption działa w pięciu krokach, które powtarzają się dziesięć razy na sekundę. Każdy z nich ma budżet czasowy i osobny mechanizm zabezpieczający przed śmieciowymi wynikami. Całość zamknięta jest w twardej pętli czasu rzeczywistego — jeśli któryś krok się nie zmieści, porzucamy klatkę i czekamy na następną.

Typowy budżet end-to-end na średnim sprzęcie to około 80 ms od pojawienia się nowej linii w grze do wyświetlenia tłumaczenia. W praktyce gracz rzadko dostrzega to opóźnienie, bo linie dialogowe pojawiają się z efektem "maszyny do pisania" — znaki dolatują stopniowo, a tłumaczenie bywa gotowe zanim litery przestaną się dopisywać.

W architekturze Kaption biegną dwa niezależne timery. Jeden odpala OCR co 100 ms. Drugi odświeża UI co 200 ms. Dzięki temu rendering nakładki pozostaje płynny nawet wtedy, gdy OCR akurat pracuje, a pojedynczy dłuższy cykl rozpoznawania nie zamraża tekstu na ekranie. To podejście bliskie temu, co opisywaliśmy w kontekście aplikacji czasu rzeczywistego: rozdzielenie warstwy akwizycji danych od warstwy prezentacji upraszcza obie strony.

Matcher to Najciekawsza Część

OCR nigdy nie zwraca dokładnie tego, co jest na ekranie. Rozpoznaje "l" jako "1", myli "rn" z "m", "O" z "0", gubi kropki po skrótach. Naiwne porównywanie rozpoznanego tekstu z TextMap gry po prostu nie zadziała. Zamiast tego mamy trzy etapy, każdy szybszy od następnego i każdy szerszy w swojej tolerancji błędów.

Etap 1: SymSpell (około 5 µs)

SymSpell to algorytm symmetric-delete spellcheck — zamiast porównywać każdą parę stringów znak po znaku, przygotowuje wcześniej słownik usunięć i szuka po hashu. Dla 500 000+ linii dialogowych w indeksie pojedyncze zapytanie schodzi do pojedynczych mikrosekund. Jeśli OCR-owana linia trafia w SymSpell bezpośrednio, kończymy na tym etapie. Dla typowego polskiego gracza to około 70–80% dopasowań.

Etap 2: Selekcja kandydatów n-gramami

Gdy SymSpell nie trafi, musimy zawęzić pole. Zamiast liczyć Levenshteina dla wszystkich 500 000 linii, używamy trigramowego indeksu odwróconego. Linia dialogowa rozbijana jest na trójki znaków; szukamy kandydatów, którzy dzielą najwięcej trigramów z naszym rozpoznanym tekstem. Zwykle zostaje nam kilkaset linii zamiast pół miliona — i dopiero na nich uruchamiamy trzeci etap.

Etap 3: Ważony Levenshtein

Klasyczny Levenshtein traktuje każdą pomyłkę jednakowo — zamiana "l" na "1" kosztuje tyle samo, co zamiana "l" na "q". W OCR to bzdura. Nasza implementacja używa macierzy kosztów, w której typowe pomyłki mają wagę bliską zeru, a nietypowe — wagę pełną. Kilka przykładów:

cost('l', '1') = 0.1    // wysokie i chude, często mylone
cost('O', '0') = 0.1    // koło okrągłe vs cyfra
cost('rn', 'm') = 0.2   // klasyk OCR
cost('I', 'l') = 0.1    // bez szeryfów nie do rozróżnienia
cost('a', 'q') = 1.0    // zwykłe dwa różne znaki

Próg akceptacji ustawiliśmy empirycznie po przeanalizowaniu kilkuset godzin rozgrywki. Jeśli najlepszy kandydat przekracza próg błędu, odrzucamy klatkę zamiast pokazać złe tłumaczenie — w fabule pomyłka wprowadza więcej szumu niż brak tłumaczenia w ogóle. Efekt: trafność dopasowania w rzeczywistej rozgrywce oscyluje wokół 97%.

Cała struktura matchera jest świetnym miejscem, żeby zastosować techniki z naszego przewodnika po testowaniu wydajności i optymalizacji — każdy z trzech etapów ma swój benchmark, a regresja w którymkolwiek zapala czerwoną lampkę w CI.

Graf Dialogów i Predykcja Kolejnej Linii

Dialogi w grach Hoyoverse nie są losowe. Mają strukturę: linia wprowadzająca, opcje odpowiedzi gracza, reakcje NPC, linia domykająca. Kaption ładuje ten graf razem z pakietem tłumaczeń i używa go do predykcji — gdy rozpoznamy linię X, wiemy, że kolejna będzie jedną z niewielu konkretnych linii Y, Z, W.

Pre-cache oznacza, że zanim OCR zdąży rozpoznać nową linię, jej tłumaczenie jest już przygotowane w pamięci. W wielu przypadkach tłumaczenie pojawia się dosłownie w tej samej klatce, w której linia staje się widoczna w grze — OCR tylko potwierdza, którą z przewidywanych opcji faktycznie wybrała gra.

Bonusowa korzyść: graf dialogów pozwala też odróżnić dwie identyczne linie, które pojawiają się w różnych zadaniach. Mała uwaga w kontekście — wystarczy, że wiemy, w którym łuku fabularnym jesteśmy — i pokazujemy właściwy przekład zamiast arbitralnie pierwszego z brzegu.

Jakość Tłumaczenia — To Nie Google Translate

Tłumaczenia w Kaption są generowane przez model AI linia po linii, z pełnym kontekstem: kto mówi, do kogo, w którym zadaniu, jakie były poprzednie dwie–trzy linie. To znaczy, że "Lord" w ustach szlachcica w Mondstadt zostaje przełożony inaczej niż "Lord" w pojedynku magicznym, a imiona własne, regiony i terminy gry pozostają spójne przez całą grę.

W praktyce przekłada się to na trzy rzeczy. Po pierwsze, gra czyta się jak książka, a nie jak automat — akapity mają sens, żarty zostają zachowane, a kwestie postaci brzmią jak one. Po drugie, terminologia nie skacze: ta sama broń, ten sam region, ten sam element mają zawsze tę samą nazwę. Po trzecie, jakość przekładu nie zależy od jakości OCR — dopasowanie trafia w konkretny wiersz w TextMap, a my pokazujemy wcześniej przygotowane tłumaczenie.

Pipeline tłumaczeń działa offline w środowisku Node i Python i publikuje paczki na R2. Szczegóły technologiczne zostawiamy na koniec, ale istotne jest jedno: gracz ściąga gotowy pakiet i dostaje stabilny przekład bez obciążania swojej maszyny pracą modelu AI.

Local-first, Prywatność, Bezpieczeństwo

Kaption działa w całości lokalnie. OCR liczymy na Twoim GPU (albo CPU), dopasowanie do TextMap liczymy w Twojej pamięci, tłumaczenie masz zrzucone na dysk w pakiecie. Żadna klatka z gry nie opuszcza Twojej maszyny. Do chmury idą tylko dwie rzeczy: sprawdzenie, czy jest nowa wersja aplikacji, i — jeśli włączysz tę opcję — anonimowy raport o awarii. Telemetria jest domyślnie wyłączona.

Pakiety tłumaczeń zabezpieczamy AES-256-CBC z dodatkowym HMAC-SHA256 i kluczem pochodnym PBKDF2 związanym z maszyną. Nie chodzi o paranoję, tylko o prostą ekonomię: pakiety są wynikiem wielu godzin pracy modelu AI i ludzkiej redakcji, a ich bezpośrednie kopiowanie obniżyłoby wartość projektu. Dla użytkownika końcowego jest to niezauważalne — pakiet działa po instalacji.

Aplikacja nie czyta pamięci gry, nie wstrzykuje DLL, nie haczy funkcji systemowych. Z perspektywy systemu operacyjnego wygląda tak samo jak Snipping Tool: proces użytkownika, który zrzuca obraz z ekranu i rysuje własne okno. Dzięki temu podejście do obserwowalności i monitoringu w produkcjiogranicza się do rozsądnych podstaw — logi aplikacyjne, raporty awarii, nic więcej.

Dystrybucja i Aktualizacje

Aktualizacje idą przez Velopack. Wybraliśmy go, bo robi delta-updates — ściąga tylko zmienione fragmenty aplikacji, a nie cały pakiet od nowa. Feed aktualizacji siedzi na Cloudflare R2: zero opłat za egress, dobre latencje w Europie i spokojne życie, gdy pojawi się skok ruchu po patchu gry.

Instalator jest samowystarczalny — nie wymaga osobnego instalowania .NET 10 Desktop runtime, nie prosi o uprawnienia administratora. Pobierasz plik, klikasz, aplikacja ląduje w profilu użytkownika. Instalacja waży około 350 MB (w tym .NET runtime) i po niej Kaption pracuje off-line — do działania nie potrzebuje internetu poza pierwszym pobraniem pakietu tłumaczeń.

Kreator konfiguracji pokazuje się raz, przy pierwszym uruchomieniu. Wykrywa okno gry, proponuje prostokąt obszaru dialogu na podstawie znanej rozdzielczości i pozwala poprawić go ręcznie. Dla typowego gracza to pięć kliknięć.

Crash reports (opt-in) idą do Sentry. Nie zbieramy zawartości ekranu ani treści dialogów — tylko stack trace, wersję aplikacji, model GPU i rozdzielczość. Doświadczenia z wcześniejszych projektów pokazały, że to wystarczy, żeby w 90% przypadków odtworzyć problem lokalnie.

Liczby, Które się Liczą

Zamiast okrągłych przymiotników, kilka konkretnych metryk. Wszystkie pochodzą z pomiarów na średnim sprzęcie testowym (Ryzen 5 5600, GTX 1660 Super, 16 GB RAM) albo z rzeczywistej rozgrywki testerów.

Stack Technologiczny — Dlaczego Takie Wybory

Każda warstwa Kaption ma konkretne uzasadnienie. Nie wybieraliśmy najnowszych technologii dla zasady — wybieraliśmy te, które rozwiązują problem bez zaciągania niepotrzebnego długu. Projekt korzysta z nowoczesnej platformy .NET 10, ponieważ cały ekosystem desktopowy Microsoftu wreszcie złożył się w spójną całość.

Czego Nauczyliśmy się po Drodze

Trzy historie, które nie zmieściły się w materiale marketingowym, ale w naszej pamięci zostały na długo.