CoOp:Anything
Search any game and see how much of it you can play with friends: every co-op mod, its stage, quality and community rating.
Otwarty świat w przeglądarce (Stare Miasto w Zamościu z OpenStreetMap), który rozwija lokalny Bielik — opisujesz zmianę po polsku, bramka jakości pilnuje, żeby gra się nie zepsuła.
Translation pending
GamesGitHub @kapoostOnlineOwner unconfirmed
Have you tried it? One tap is enough. No sign-in needed.
Repository information has not been collected yet.
No updates detected yet. GitHub releases will appear here.
The maker's introduction consists of the line above. Read the repository README for more details. Repository README ↗
Loading the full README.
Read the full README ↗Otwarty świat w przeglądarce — zbieranie, wytwarzanie, budowanie — który rozwija Bielik, polski model językowy działający lokalnie.
Świat nie jest wymyślony: to Stare Miasto w Zamościu, wczytane z OpenStreetMap. Siatka kafli jest obrócona o zmierzone 13,93°, więc ulice biegną prosto, a kamienice stoją równo w pierzejach.
Opisujesz zmianę po polsku. Model ją klasyfikuje, proponuje, system ją stosuje i testuje. Jeśli coś się psuje, zmiana nie wchodzi.
npm run instalacja # sprawdza, czego brakuje, i dopina to z Tobą
npm start # gra + pętla agenta + kontrola wstępna
npm run zu -- "dodaj drewnianą fujarkę, NPC lubią gdy im zagrasz"
Instalator nie pobiera niczego bez pytania — modele to razem siedemnaście gigabajtów, a model kodujący jest opcjonalny: do grania i do zmian w treści wystarczy Bielik. Można go uruchamiać wielokrotnie; każdy krok sprawdza, czy nie jest już zrobiony.
Chcesz tylko pograć? npm install && npm run dev — i tyle.
opis po polsku
│
▼
Bielik 11B ──► klasyfikacja: DANE czy KOD?
│
├─ DANE ─► Bielik proponuje operacje ─► deterministyczny applier ─► treść gry
│
└─ KOD ──► Qwen2.5-Coder 14B pisze patch ─► pliki rdzenia
│
▼
BRAMKA JAKOŚCI
schematy → typy → testy → symulacja
│
zielona ─────┴───── czerwona
│ │
commit na gałęzi błędy wracają
│ do modelu, kolejna runda
┌─────────┴─────────┐ │
dane: kod: po wyczerpaniu prób
warunek intencji PR gałąź znika, main nietknięty
spełniony?
tak → main
nie → gałąź
Orkiestracja jest deterministyczna. Model nie jest agentem — dostaje wąskie, walidowalne zadania. To jedyny sposób, w jaki model ogólnego przeznaczenia może rozwijać grę i jej nie zepsuć.
https://kapoost.github.io/zagroda/ — nic nie trzeba instalować. Instrukcja: https://kapoost.github.io/zagroda/instrukcja.html
To wersja bez modelu: gra działa w całości (ruch, zbieranie, wytwarzanie, zadania, wymiana z postaciami), a P otwiera pracownię zamienioną w eksponat — prompt, który model dostawał, dziennik przebiegów z prawdziwymi wynikami i stan bramki.
Jeśli masz Ollamę i pobranego Bielika, gra rozmawia z nim bezpośrednio z przeglądarki, bez żadnego serwera pośrodku:
ollama pull hf.co/speakleash/Bielik-11B-v3.0-Instruct-GGUF:Q5_K_M
npm run build && npx serve game/dist # albo cokolwiek, co postawi to na localhoście
Gra sama znajdzie model na 127.0.0.1:11434 i powie w oknie rozmowy, z czym gada.
To ten sam kod promptów, co w pętli agenta — gdyby był inny, dostałbyś inną grę.
Pracownia dalej nie zadziała: zapisuje pliki, uruchamia testy i robi commity.
Strona z internetu tego nie potrafi i nie jest to kwestia konfiguracji — sprawdziłem:
| strona | → Ollama na 127.0.0.1:11434 |
|---|---|
https://kapoost.github.io | timeout, 6 s, żadnej odpowiedzi |
http://127.0.0.1:5190 | HTTP 200 w 23 ms |
Ta sama przeglądarka, ten sam Ollama, ta sama chwila. Przeglądarki blokują zapytania ze stron publicznych do sieci lokalnej (Private Network Access) i nie pomaga nawet serwer odpowiadający najbardziej liberalnym CORS-em, jaki da się ustawić. Model lokalny działa więc tylko wtedy, gdy strona też stoi lokalnie.
Trzy poziomy, każdy pokazuje co innego:
| poziom | czego wymaga | co widać |
|---|---|---|
| statyczna gra | npm run build, dowolny hosting | pełna rozgrywka: ruch, zbieranie, wytwarzanie, zadania, wymiana, kwestie postaci |
| gra + dowody | to samo — dowody są w paczce | pracownia staje się eksponatem: prompt, dziennik przebiegów, wynik bramki |
pełny npm start | Ollama i 8,5 GB modelu | żywe rozmowy po polsku i prawdziwe zgłaszanie zmian |
Paczka ma 211 kB (57 kB po gzipie) i zawiera całą mapę Zamościa — zero zapytań sieciowych przy starcie.
Gra sprawdza raz, czy ma z kim rozmawiać, i od tego zależy, co pokazuje. Bez modelu znika pole do pisania i przycisk „Wyślij do Bielika", bo przycisk, który nie może zadziałać, jest gorszy od jego braku. Zostaje wymiana — kurs i tak liczy silnik, więc nie zależy od niczego poza treścią gry.
Dowody odświeża npm run dowody (robi to też npm run build): prompt klasyfikacji
powstaje z tej samej funkcji, co w pętli, a dziennik i wynik bramki pochodzą z .agent/.
Rozwijanie gry modelem bez wglądu w prompt jest rzucaniem zdania w ciemno, więc prompt da się obejrzeć z dwóch stron — i składa go ta sama funkcja, która składa go naprawdę:
npm run zu -- --prompt "dodaj gliniany dzban na wodę"
wypisze krok po kroku: blok systemowy, blok użytkownika i gramatykę dekodowania, z liczbą znaków i przybliżoną liczbą tokenów. Krok klasyfikacji renderuje się bez żadnego wywołania modelu; prompty tworzące treść wymagają jednego pytania do Bielika, bo zależą od tego, które kolekcje wybrał.
To samo jest w grze: P otwiera pracownię, a w niej „Pokaż prompt, który dostanie model".
Wiedza o tym, jak zabrifować model kodujący, nie siedzi w wagach Bielika, tylko
w plikach pisanych ręcznie — agent/skills/*.md. Bielikowi zostaje klasyfikacja
(„który to rodzaj zmiany") i wypełnienie dwóch slotów, czyli to, co robi bezbłędnie.
Każdy skill niesie trzy rzeczy, których model nie ma skąd wiedzieć:
| gdzie zaczepić | „zużycie energii przechodzi przez spend() w tick.ts" |
| czego nie łamać | „koszt nigdy poniżej 1 — inaczej bot progresji zapętla się" |
| które pliki wysłać | 2–3 zamiast całego rdzenia |
Dopisanie skilla kosztuje pięć minut i nie wymaga ani jednej pary treningowej. Gdy jakiś rodzaj zmiany uporczywie nie wychodzi, odpowiedź brzmi „dopisz skill", a nie „zbierz dane i trenuj". Gdy żaden nie pasuje, pętla mówi to wprost — i to jest lista zadań na przyszłość.
Większość zmian to dane, nie kod. Nowa broń, surowiec, potrawa, budynek czy
postać to wpisy w game/content/*.json walidowane schematami Zod. Model nie pisze
tych plików — emituje deklaratywne operacje, a stosuje je zwykły kod.
Bramka jest niezapisywalna dla agenta. Schematy, walidator, testy i sama bramka leżą poza dozwoloną powierzchnią zmian. Najprostsza droga do zielonego światła to naprawienie kodu, nie rozmontowanie testów.
Testy sprawdzają grywalność, nie tylko spójność. Bot progresji startuje z pustym ekwipunkiem i musi dojść do każdego kamienia milowego. Receptura, której w praktyce nie da się wykonać, pęknie tutaj — nawet jeśli schematy są zielone.
Komunikat błędu jest interfejsem. Czyta go model, który ma zmianę poprawić, więc walidator nie mówi „nie ma itemu trzcina", tylko „trzcina to surowiec rosnący w świecie, nie przedmiot — użyj tego, co z niego wypada: wlokno". Ta jedna zmiana przeniosła pętlę z „trzy rundy, ten sam błąd" do „druga runda, zielono".
| Plik | Co opisuje |
|---|---|
game/content/items.json | przedmioty: narzędzia, jedzenie, półprodukty, rzeczy do postawienia |
game/content/recipes.json | receptury: wsad, wynik, stanowisko, czas |
game/content/resources.json | surowce w świecie: biom, gęstość, narzędzie, łup |
game/content/structures.json | budynki: stanowiska wytwórcze, schowki, ściany |
game/content/biomes.json | biomy: kolor, przechodniość, zakres wysokości i wilgotności |
game/content/npcs.json | postacie: dom, upodobania, kwestie |
game/content/config.json | parametry świata: rozmiar, seed, długość doby, energia |
| Komenda | Działanie |
|---|---|
npm run instalacja | sprawdza środowisko i dopina braki — nic nie pobiera bez pytania |
npm start | wszystko naraz: gra, pętla agenta i kontrola wstępna |
npm run dev | sama gra w przeglądarce |
npm run npc-model | przebuduj model rozmów — po każdej zmianie treści |
npm run gate | pełna bramka jakości |
npm test | same testy |
npm run sim | raport progresji: ile ticków do kamieni milowych |
npm run zu -- "..." | zmiana opisana po polsku |
npm run zu -- --dry "..." | sama klasyfikacja, bez zapisu |
npm run zu -- --prompt "..." | dokładny prompt, który dostanie model |
| Rola | Model | Dlaczego ten |
|---|---|---|
| polski ↔ struktura | Bielik 11B v3.0 (Q5_K_M) | trenowany na polskim korpusie; rozumie opisy i pisze teksty do gry |
| patche kodu | Qwen2.5-Coder 14B | dostaje prompty po angielsku, zwraca kod |
| eskalacja | Claude Opus 5 | wchodzi, gdy lokalne modele nie dadzą rady po N próbach |
Eskalacja do API jest opcjonalna — bez ANTHROPIC_API_KEY pętla działa wyłącznie
lokalnie, tylko z niższą skutecznością.
ollama pull hf.co/speakleash/Bielik-11B-v3.0-Instruct-GGUF:Q5_K_M
ollama pull qwen2.5-coder:14b
To nie jest pętla do pracy interaktywnej. Jedno wywołanie modelu 11B z gramatyką JSON trwa dziesiątki sekund do kilku minut; pełna zmiana z rundą poprawek to kilka minut.
Skuteczność też warto znać z góry. Faza klasyfikacji (dane czy kod, które kolekcje)
jest niezawodna. Faza generowania wpisów bywa loteryjna — bramka to wyłapuje, więc gra
jest bezpieczna, ale część zmian kończy się porzuceniem gałęzi. Każda próba trafia do
.agent/journal.jsonl razem z powodem porażki; to materiał na przyszłe dostrojenie
modelu albo na lepsze przykłady w prompcie.
Zgłoszenia są mile widziane i mają własny szablon: opisujesz pełnym zdaniem po polsku, co ma się zmienić — dokładnie tak, jak w pracowni w grze. Takie zgłoszenie jest gotowym wejściem do pętli.
Pull requesty też. Bramka uruchamia się na każdym z nich i sprawdza to samo, co
lokalnie: siedem etapów, bez modelu, kilkanaście sekund. Sprawdzone na żywo —
PR z celowo zepsutym młotem (wytrzymałość 30 przy kilofie 200) został zatrzymany
w 13 sekund komunikatem [DOMINACJA] kosztuje więcej niż "kilof_kamienny", a jest od niego gorsze.
Kod: MIT (LICENSE).
Dane mapy to osobna sprawa: game/content/mapa.json jest bazą pochodną z
OpenStreetMap i podlega ODbL 1.0 — razem ze wszystkim, co z niej powstaje.
Szczegóły i atrybucja w NOTICE.md. Kto bierze stąd mapę, bierze też ten obowiązek.
© OpenStreetMap contributors · openstreetmap.org/copyright