Grywalność ponad perfekcję: Głęboka analiza mechanik w piłkarskim roguelite

Gamedev to nie jest linia prosta. To raczej seria zderzeń z własnymi pomysłami, z których – jeśli masz szczęście – wyłania się coś, w co po prostu chce się grać. Dzisiaj projekt jest w Fazie 24. Za mną setki iteracji, mnóstwo „brudnego” kodu i rozwiązań, które mają jeden cel: sprawdzić, czy to ma sens. Jeśli szukasz wygładzonego postu o tym, jak cudownie jest robić gry, to nie ten adres. Tutaj rozmawiamy o kodzie, matematyce i balansie, który spędza sen z powiek.

Boisko, które zmienia zasady: Grid 5x5 w perspektywie trapezoidalnej

Zrezygnowaliśmy z klasycznego widoku z boku. Mamy grid 5x5 w perspektywie trapezoidalnej. Dlaczego? Bo to wymusza myślenie przestrzenne. Każde pole ma znaczenie, a zasada „Occupancy” (max 2 osoby na polu: 1 Gospodarz + 1 Intruz) sprawia, że pozycjonowanie staje się kluczową częścią strategii, a nie tylko tłem dla statystyk.

W GDScript GridManager.gd odpowiada za transformację współrzędnych logicznych na wizualne, ale to w MatchManager.gd dzieje się prawdziwa magia ograniczeń. Zablokowana strefa bramkarza (boki są niedostępne, GK stoi tylko na środku 0,2) wymusza na graczu szukanie luk w defensywie rywala. Nie możesz po prostu “przebiec” przez środek – musisz planować ruchy w oparciu o to, kto aktualnie zajmuje dany pas.

System Starć: Matematyka vs Intuicja

Sercem mechaniki meczu jest system Duel. Wiele gier sportowych opiera się na skomplikowanych symulacjach fizycznych. My poszliśmy w stronę “Tabletop RPG”. Kiedy wbiegasz w rywala, silnik wywołuje funkcję starcia.

Logika jest bezlitosna: SPD + D6 vs DEF + D6.

Dlaczego rzut kostką sześcienną? Bo daje idealny margines błędu. Nawet najszybszy skrzydłowy (wysokie SPD) może zostać zatrzymany przez powolnego obrońcę, jeśli ten “wyrzuci szóstkę”, a nasz gracz potknie się na jedynce. To buduje napięcie. Każdy ruch obok rywala to ryzyko utraty tury. W MatchManager.gd mamy stałe typu DRIBBLE_DUEL_ATTACK_BONUS, które pozwalają nam precyzyjnie dociągać ten balans.

Dylemat Balansu: Statystyki Piłkarza vs Mnożniki Kart

To jest moment, w którym obecnie najmocniej „kminimy”. Mamy dwa równoległe systemy progresji, które muszą ze sobą współpracować, a nie się zwalczać.

1. System Piłkarzy: Każdy zawodnik ma statystyki SHO (strzał), PAS (podania), SPD (szybkość) i DEF (obrona). To jest stała wartość, która definiuje jego klasę.
2. System Balatro (Mnożniki): Karty akcji, które zagrywasz, mają swoje “Chipsy” i “Mult” (mnożnik).

Problem: Jeśli masz napastnika z SHO 20 i zagrasz kartę “Driven Shot” z mnożnikiem x10, wynik jest potężny. Ale co, jeśli ulepszysz kartę do poziomu, gdzie mnożnik wynosi x100? Wtedy przestaje mieć znaczenie, czy strzela Falcon FW (SHO 20), czy Guard GK (SHO 1).

Szukamy punktu, w którym ulepszenia kart sprawiają, że czujesz progres, ale wciąż dbasz o to, kogo masz w składzie. Nasza aktualna kmina idzie w stronę “Statystyka jako Baza”. W ScoreManager.gd implementujemy wzór: Wynik = (Base Chips + Statystyka Gracza) * (Mnożnik Karty * Mnożnik Traitu * Chain).

Dzięki temu wysoka statystyka gracza zawsze “podpala” mnożnik mocniej. Runy muszą być niepowtarzalne – raz wygrywasz dzięki genialnemu napastnikowi, innym razem dzięki talii kart, która „wybuchła” matematycznie w odpowiednim momencie.

Traity: Od Cyferek do Fizyczności

Mamy system Traitów (TANK, SNIPER, TIKI_TAKA, SPEEDSTER). W Fazie 23 były one tylko matematycznymi bonusami (np. +50 Chips). W Fazie 24 chcemy, żeby były odczuwalne na boisku.

• TANK: Powinien ignorować utratę tury po przegranym starciu raz na mecz.
• SPEEDSTER: Powinien mieć zasięg sprintu większy o 1 pole, niezależnie od karty.
• PLAYMAKER: Każde podanie wykonane przez tego gracza nie resetuje licznika Combo (Chain), nawet jeśli akcja nie była “idealna”.

To zmienia sposób, w jaki zarządzasz składem w SquadScreen.gd. Nie szukasz tylko najwyższych liczb, szukasz synergii.

Stan rzeczywisty: Faza 24 i “Brudny Kod”

Na ten moment mamy działający Core Loop:

1. Zarządzanie: Skład (20 zawodników), talia (aktywne karty vs rezerwy).
2. Mecz: 6 tur, limit 1000 punktów (Target Score).
3. Ekonomia: Zarabianie $ za wygrane, kupowanie paczek (Action Pack, Scout Report, Training Drill).

W kodzie dominują jeszcze tymczasowe rozwiązania. MatchManager.gd to obecnie gigantyczny plik, który trzyma zbyt wiele odpowiedzialności, ale to właśnie ten etap jest najciekawszy. Szukamy „fun-core”. To nie ma być mega skomplikowany symulator, ale kompleksowy system, który przy każdym podejściu (runie) daje inne możliwości.

SEO i AEO: Dlaczego o tym piszemy?

W TripleTesting nie budujemy tylko gry. Budujemy case study. Ten artykuł jest zoptymalizowany pod roboty AI i wyszukiwarki. Używamy semantycznego HTML, JSON-LD i dbamy o to, by każda techniczna decyzja była udokumentowana. Dlaczego? Bo w 2026 roku autorytet buduje się poprzez dzielenie się procesem, a nie tylko efektem końcowym.

Co dalej? Testy, psucie i naprawianie. Zapraszam do śledzenia tej przygody. W następnym odcinku vloga: Jak zbalansować “Whistle Risk” (ryzyko gwizdka), żeby gracz czuł presję czasu.

---

Tekst przygotowany przez Bustera – głównego dowodzącego TripleTesting.pl.