1. Cel

Stworzenie uniwersalnego systemu do obsługi turniejów dartowych, który może być wykorzystany zarówno do pojedynczej imprezy, jak i do różnych formatów rozgrywek.

2. Turniej jest konfigurowalny

Turniej nie ma jednego z góry ustalonego schematu.

Typ turnieju powstaje z predefiniowanych klocków/faz, które można:

• wybierać,
• konfigurować,
• łączyć,
• pomijać,
• a w razie potrzeby wykorzystywać wielokrotnie.

Przykładowo:

Round Robin → Classification → Seeding → Playoff → Final

albo:

Round Robin → Classification → Main Playoff → Lucky Losers → Secondary Playoff → Final

Gotowe typy turniejów będą jedynie szablonami złożonymi z tych klocków.

3. Liczba zawodników jest zmienna

System od początku musi obsługiwać różne liczby uczestników:

30 → 50 → 200 → więcej

Nie zakładamy konkretnej liczby zawodników ani wielkości drabinki.

Przypadki takie jak:

• nieparzysta liczba zawodników,
• liczba niepasująca do liczby grup,
• konieczność zastosowania bye,

są normalnymi przypadkami systemu, a nie błędami.

4. Zasady ustala organizator

System nie wymyśla zasad turnieju.

Organizator podczas konfiguracji określa m.in.:

• format,
• liczbę grup,
• liczbę zawodników w grupie,
• liczbę zawodników awansujących,
• zasady rozstawienia,
• zasady tie-break,
• sposób kwalifikacji,
• format kolejnych faz,
• zasady gry.

Po rozpoczęciu turnieju ustalone zasady powinny być odpowiednio chronione przed przypadkowymi zmianami.

5. Konfigurowalność nie może komplikować obsługi

System ma być elastyczny, ale domyślne wartości mają pozwalać na szybkie rozpoczęcie meczu.

Użytkownik, który chce po prostu rozegrać standardowy mecz, nie powinien przeklikiwać kilkunastu ustawień.

Model:

wartości domyślne ↓ preset ↓ zasady turnieju ↓ ewentualne ustawienia fazy/meczu

Czyli:

„Chcę po prostu zagrać” → minimum kliknięć.

6. Rozstawienie jest osobnym, wielokrotnie używanym mechanizmem

Rozstawienie nie jest jednorazową czynnością na początku turnieju.

Może wystąpić:

• przed pierwszą fazą,
• po Round Robin,
• przed Playoff,
• przed kolejną drabinką,
• przed dowolną fazą, która tego wymaga.

Rozstawienie może być:

ręczne — organizator zaznacza zawodników,

lub w przyszłości:

automatyczne — np. na podstawie rankingu.

Rozstawienie jest związane z konkretną fazą/przejściem, a nie na stałe z zawodnikiem.

7. Ranking i tie-break są elementami zasad

System musi być przygotowany na sytuacje, w których standardowe kryteria nie pozwalają jednoznacznie ustalić kolejności.

Przykład:

A = 6 pkt, +8 B = 6 pkt, +8 C = 6 pkt, +8

Organizator wybiera sposób rozstrzygnięcia.

Domyślna metoda: złoty leg.

Inne metody mogą być dodawane jako opcje. gdzieś wyżej wymieniliśmy te opcje - dodajmy je od razu

8. System turniejowy i system gry są rozdzielone

Turniej określa:

kto, z kim, kiedy i w jakiej fazie gra.

Klocek gry określa:

jak przebiega sam mecz i jak liczony jest wynik.

Podstawowym klockiem gry będzie:

01

z domyślnym presetem:

501 / Straight In / Double Out zrobiłbym straight i straight, a opcje double dodał obok jako przyciski

Parametry będą jednak konfigurowalne, m.in.:

• 301 / 501 / 701 / ...
• Straight In / Double In,
• Straight Out / Double Out,
• legi,
• sety,
• limit rund,
• zasady bust,
• statystyki.

9. Jeden silnik danych — wiele interfejsów

System ma być przygotowany do obsługi przez:

• organizatora,
• sędziego,
• publiczny interfejs,
• telebim,
• a później tablety przy tarczach.

Tablet nie będzie osobnym systemem. Będzie kolejnym interfejsem korzystającym z tego samego silnika gry i tych samych danych.

10. System ma być rozwijany etapami

Najpierw powstaje rdzeń logiczny, później interfejsy dodatkowe.

Priorytet:

klocki turniejowe ↓ mecze ↓ silnik gry ↓ wyniki ↓ interfejs organizatora/sędziego ↓ live / telebim ↓ tablety ↓ rejestracja online

11. Fabrik jest narzędziem realizacji, nie definicją systemu

Najpierw definiujemy model działania systemu, a dopiero potem przekładamy go na Joomla + Fabrik.

Nie dopasowujemy logiki turnieju do ograniczeń narzędzia, jeśli można tego uniknąć.

1. Tworzenie zawodników

Przy tworzeniu turnieju admin określa liczbę zawodników.

System automatycznie generuje odpowiednią liczbę rekordów:

Zawodnik 01 Zawodnik 02 Zawodnik 03 ... Zawodnik 32

Nie ma potrzeby ręcznego tworzenia każdego zawodnika.

2. Domyślna nazwa

Jeżeli admin nie zmieni rekordu, zawodnik pozostaje na liście startowej jako:

Zawodnik XX

Jest to prawidłowy uczestnik turnieju, a nie błąd systemu.

3. Przypisanie nazwiska

Admin może w dowolnym momencie przypisać zawodnikowi właściwe dane, np.:

Zawodnik 07 ↓ Jan Kowalski

Zmiana może nastąpić w dowolnym momencie trwania turnieju, również po rozpoczęciu rozgrywek.

Ma to zabezpieczyć system przed przeoczeniami przy wprowadzaniu zawodników.

4. ID zawodnika

Każdy zawodnik ma stały identyfikator techniczny.

Zmiana nazwy zawodnika nie tworzy nowego zawodnika.

Przykład:

ID: 07 Zawodnik 07 ↓ Jan Kowalski

System nadal traktuje to jako tego samego zawodnika.

Dzięki temu zmiana nazwy nie wpływa na:

• grupę,
• rozstawienie,
• rozegrane mecze,
• wyniki,
• klasyfikację,
• dalszy awans w turnieju.

5. Dane zawodnika

Na tym etapie podstawowe dane to:

• ID — nadawane przez system,
• nazwa/imię i nazwisko — edytowalne przez admina,
• ewentualnie nick/pseudonim — do ustalenia.

Nie wprowadzamy jeszcze:

• kont zawodników,
• rejestracji online,
• automatycznego rankingu,
• punktów rankingowych.

Te elementy mogą zostać dodane później.

6. Ważne rozróżnienie

Zawodnik jest rekordem, a jego nazwa jest tylko edytowalną informacją o tym rekordzie.

To pozwala na swobodne poprawianie danych bez naruszania historii turnieju.

Status: 🟢 ustalone

Tutaj proponuję na razie nie wchodzić jeszcze w klocki faz. Najpierw definiujemy sam obiekt „Turniej” — czyli co admin tworzy, zanim zacznie układać jego przebieg.

<details> <summary>🏆 03. TURNIEJ — karta robocza</summary>

1. Utworzenie turnieju

Admin tworzy nowy turniej i określa jego podstawowe dane.

Minimalnie:

2. Liczba zawodników

Admin określa liczbę uczestników.

System na tej podstawie automatycznie tworzy rekordy:

Zawodnik 01 Zawodnik 02 ... Zawodnik 200

Szczegóły opisane w 02. Zawodnik.

3. Turniej ma własne zasady

Turniej posiada zestaw ustawień, które określają jego przebieg.

Przykładowo:

• format rozgrywek,
• liczba grup,
• sposób rozstawienia,
• liczba zawodników awansujących,
• sposób rozstrzygania remisów,
• format meczów,
• zasady gry,
• ewentualne Lucky Losers.

Te ustawienia obowiązują jako zasady tego konkretnego turnieju.

4. Turniej składa się z faz

Turniej nie jest jednym sztywnym algorytmem.

Jego przebieg tworzymy z predefiniowanych klocków faz.

Przykład:

ROUND ROBIN ↓ CLASSIFICATION ↓ SEEDING ↓ PLAYOFF ↓ FINAL

Każda faza posiada własną konfigurację, ale korzysta ze wspólnych danych turnieju.

5. Turniej może być zapisany jako szablon

To jest jeszcze rzecz do ustalenia, ale proponuję przewidzieć możliwość:

„Zapisz konfigurację jako szablon”

Dzięki temu organizator może później stworzyć np.:

Puchar Polski — format 2027

i w kolejnym roku rozpocząć od istniejącej konfiguracji zamiast budować wszystko od zera.

Nie oznacza to kopiowania zawodników ani wyników — tylko ustawienia i strukturę turnieju.

Status: 🟡 propozycja

6. Status turnieju

Roboczo proponuję:

PRZYGOTOWANIE ↓ OTWARTY / REJESTRACJA ↓ GOTOWY ↓ W TRAKCIE ↓ ZAKOŃCZONY

Ale nie zamykajmy jeszcze tej listy. Statusy będą miały znaczenie przy późniejszym projektowaniu uprawnień i zmian ustawień.

Status: 🟡 do ustalenia

7. Zasada nadrzędna

Turniej powinien mieć jedno miejsce, w którym przechowywane są jego zasady i konfiguracja.

Poszczególne fazy i mecze korzystają z tych ustawień, chyba że zgodnie z projektem dana faza posiada własny parametr.

</details>

I tutaj zatrzymałbym się na chwilę przy dwóch rzeczach oznaczonych na żółto — szablonach i statusach.

Nie musimy ich teraz rozstrzygać. Możemy je zostawić i przejść dalej do 04. KLOCKI, gdzie zaczniemy od SEEDING, bo właśnie ten klocek mamy już całkiem dobrze przemyślany.

Tak. Zrobiłbym teraz ostateczną wersję punktu 04 „Klocki turniejowe”, ale na poziomie architektury — bez rozpisywania jeszcze szczegółów każdego klocka. Uwzględniam już dzisiejsze ustalenia z ekspertem.

<details open> <summary>🧱 04. KLOCKI TURNIEJOWE — v0.1</summary>

1. Zasada ogólna

Turniej nie jest jednym sztywnym typem rozgrywek.

Jest budowany z predefiniowanych klocków, które odpowiadają za poszczególne etapy lub operacje.

Przykład:

ZAWODNICY ↓ SEEDING ↓ ROUND ROBIN ↓ CLASSIFICATION ↓ BRACKET MAPPING ↓ PLAYOFF ↓ FINAL

Inny turniej może wykorzystywać tylko część z nich:

ZAWODNICY ↓ PLAYOFF ↓ FINAL

Klocki mogą być konfigurowane i — tam, gdzie ma to sens — wykorzystywane wielokrotnie.

2. SEEDING / ROZSTAWIENIE

Rozstawienie służy do wskazania zawodników, których należy odpowiednio rozdzielić przed losowaniem początkowym, przede wszystkim do grup.

Podstawowym sposobem będzie:

Ręczne rozstawienie

Admin zaznacza zawodników:

☑ Jan Kowalski ☑ Piotr Nowak ☐ Adam Wiśniewski ☐ Zawodnik 04

System następnie odpowiednio rozdziela wskazanych zawodników podczas losowania.

W przyszłości możliwe będzie:

Automatyczne rozstawienie na podstawie rankingu.

Na pierwszym etapie nie budujemy systemu rankingowego.

Ważne

Nie wykonujemy ponownego rozstawienia zawodników po Round Robin.

Nie wykonujemy również tak rozumianego rozstawienia przed turniejem składającym się wyłącznie z fazy pucharowej.

Rozstawienie nie jest stałą cechą zawodnika, lecz elementem konfiguracji początkowego losowania.

3. ROUND ROBIN

Klocek odpowiada za fazę grupową.

Organizator określa przede wszystkim:

• liczbę grup,
• liczbę zawodników awansujących z grupy,
• zasady rozgrywania meczów,
• zasady klasyfikacji.

System na podstawie liczby zawodników i liczby grup tworzy grupy możliwie równej wielkości.

Różnica między najmniejszą a największą grupą może wynosić maksymalnie 1 zawodnika.

Przykład:

42 zawodników 10 grup → 8 grup × 4 → 2 grupy × 5

Liczba awansujących nie jest stała.

Może być np.:

3 zawodników w grupie → awansuje 2 4 zawodników w grupie → awansuje 2 4 zawodników w grupie → awansuje 3

Decyzję podejmuje organizator.

System wylicza i pokazuje wynik konfiguracji, np.:

192 zawodników 64 grupy 3 zawodników / grupa 2 awansuje ──────────────────── 128 zawodników → Playoff

System nie dobiera za organizatora optymalnej struktury turnieju. Organizator ustala ją tak, aby odpowiadała warunkom konkretnej imprezy.

4. CLASSIFICATION / KLASYFIKACJA

Klocek odpowiada za ustalenie kolejności zawodników na podstawie wyników poprzedniej fazy.

W przypadku Round Robin tworzy klasyfikację każdej grupy.

Uwzględnia:

• wyniki meczów,
• punkty,
• legi,
• bezpośrednie spotkania,
• reguły tie-break określone dla turnieju.

Jeżeli standardowe kryteria nie pozwalają ustalić kolejności, uruchamiana jest określona wcześniej metoda rozstrzygnięcia.

Domyślną metodą dla omawianego przypadku pozostaje:

złoty leg.

Inne metody mogą być dostępne jako opcje konfiguracji turnieju.

5. BRACKET MAPPING / PRZYDZIAŁ DO DRABINKI

To nie jest rozstawienie zawodników.

Klocek odpowiada za przełożenie wyników poprzedniej fazy na konkretne miejsca w drabince pucharowej.

Przykład:

A1 ─────┐ ├── mecz C2 ─────┘ B1 ─────┐ ├── mecz D2 ─────┘

Reguła przydziału jest elementem zasad danego turnieju.

System nie wykonuje po grupach nowego seeding zawodników, lecz realizuje wcześniej określoną regułę przejścia do drabinki.

6. PLAYOFF

Klocek odpowiada za fazę pucharową.

Otrzymuje zawodników oraz ich miejsca w drabince i generuje kolejne mecze:

Runda 1 ↓ Runda 2 ↓ Ćwierćfinał ↓ Półfinał ↓ Finał

Playoff może być używany:

• po Round Robin,
• bezpośrednio jako główny format turnieju,
• jako osobna drabinka dodatkowa.

Sam Playoff nie wykonuje rozstawienia zawodników.

7. DOUBLE ELIMINATION

Osobny klocek rozgrywek pucharowych.

Zawodnik nie odpada po pierwszej porażce.

System prowadzi odpowiednie ścieżki:

WINNERS BRACKET │ porażka ↓ LOSERS BRACKET

Dokładne reguły przejść pomiędzy drabinkami zostaną określone podczas szczegółowej analizy tego klocka.

8. LUCKY LOSERS / DRABINKA DODATKOWA

Opcjonalny klocek umożliwiający utworzenie dodatkowej grupy lub drabinki dla zawodników, którzy nie zakwalifikowali się do głównej fazy.

Źródłem zawodników mogą być wyniki wcześniejszej fazy.

Dokładne kryteria kwalifikacji są elementem zasad turnieju.

Klocek może następnie przekazać zawodników do kolejnego PLAYOFF.

9. FINAL

Finał traktujemy jako końcowy etap rozgrywek.

Otrzymuje zawodników wyłonionych przez poprzednią fazę i określa:

• zwycięzcę,
• finalistę,
• końcowy wynik turnieju.

Format samego meczu finałowego może różnić się od wcześniejszych rund, np. liczbą legów lub setów.

10. Klocki mogą przekazywać dane między sobą

Każdy klocek ma:

WEJŚCIE → DZIAŁANIE → WYJŚCIE

Przykład:

ROUND ROBIN │ │ wyniki grup ▼ CLASSIFICATION │ │ A1, A2, B1, B2... ▼ BRACKET MAPPING │ │ konkretne miejsca w drabince ▼ PLAYOFF │ │ zwycięzcy ▼ FINAL

Dzięki temu poszczególne elementy nie muszą wiedzieć, jak skonstruowany jest cały turniej.

11. Organizator decyduje — system realizuje

To jedna z głównych zasad całej architektury.

Organizator określa m.in.:

liczbę grup liczbę awansujących zasady klasyfikacji tie-break przejście do kolejnej fazy format rozgrywek

System:

liczy ↓ sprawdza ↓ pokazuje konsekwencje ↓ generuje strukturę ↓ prowadzi rozgrywki

System nie próbuje zgadywać, jaki turniej organizator powinien zrobić.

12. Roboczy katalog klocków

Status: 🟢 architektura klocków ustalona

Szczegółowe reguły każdego klocka będą definiowane osobno.

</details>

To już spokojnie możesz kopiować jako naszą wersję referencyjną 04. KLOCKI TURNIEJOWE v0.1.

<details open> <summary>🎯 05. KLOCEK GRY — 01 — v0.1</summary>

1. Zasada ogólna

Nie tworzymy osobnego silnika dla 301, 501, 701 itd.

Tworzymy uniwersalny klocek:

01

a 501 jest jego podstawową i domyślną konfiguracją.

Silnik turniejowy określa:

kto z kim gra i w jakiej fazie

natomiast klocek 01 odpowiada za:

przebieg samego meczu i jego wynik.

2. Domyślna konfiguracja

Podstawowym wariantem jest:

501 Straight In Double Out

Parametry gry pozostają konfigurowalne.

Przewidujemy m.in.:

Konfigurowalność nie może utrudniać obsługi.

Jeżeli organizator nie potrzebuje nietypowych zasad, korzysta z wartości domyślnych.

3. Struktura gry

Silnik 01 ma hierarchię:

MECZ │ ├── SET ← opcjonalny │ │ │ ├── LEG │ │ │ │ │ ├── KOLEJKA / VISIT │ │ ├── KOLEJKA / VISIT │ │ └── ... │ │ │ └── LEG │ └── ...

Jeżeli mecz nie wykorzystuje setów:

MECZ ├── LEG ├── LEG ├── LEG └── ...

4. Podstawową jednostką zapisu jest KOLEJKA / VISIT

Podstawowym elementem zapisywanym podczas gry jest cała kolejka zawodnika, a nie pojedyncza lotka.

Przykład:

Kowalski 501 ↓ 140 ↓ 361

Dzięki temu podstawowy interfejs sędziego pozostaje prosty — wystarczy wpisać wynik kolejki.

5. Pojedyncze lotki — dane opcjonalne

Silnik powinien od początku dopuszczać zapis pojedynczych lotek, ale nie może go wymagać.

Przykład podstawowy:

VISIT score: 140

Przykład rozszerzony:

VISIT dart 1: T20 dart 2: T20 dart 3: 20 score: 140

Oba sposoby reprezentują tę samą kolejkę.

Pozwoli to w przyszłości stworzyć interfejs odwzorowujący tarczę bez przebudowy silnika gry.

6. Dlaczego zapis pojedynczych lotek może być potrzebny

Sam wynik kolejki nie określa jednoznacznie trafionych pól.

Przykładowo 171 można uzyskać m.in.:

T19 + T19 + T19 T20 + T20 + T17 T20 + T19 + T18

Dlatego:

wynik kolejki jest informacją podstawową, a trafienia poszczególnych lotek są opcjonalną informacją szczegółową.

Dzięki szczegółowemu zapisowi w przyszłości możliwe będą znacznie pełniejsze statystyki zawodników.

7. Liczba wykorzystanych lotek

Kolejka powinna umożliwiać zapisanie liczby rzeczywiście wykorzystanych lotek.

Jest to szczególnie istotne przy zakończeniu lega.

Przykład:

pozostało: 40 D20 pierwszą lotką darts_used = 1 score = 40 LEG WYGRANY

Nie można w takiej sytuacji zakładać automatycznie wykorzystania trzech lotek, ponieważ wpłynęłoby to na statystyki.

8. Statystyki

Zawodnicy przywiązują wagę do statystyk, dlatego silnik powinien być przygotowany do ich zbierania.

Już zapis całych kolejek pozwala później wyliczać podstawowe statystyki.

Przykładowo wynik:

180

jednoznacznie pozwala odnotować maximum.

Opcjonalny zapis pojedynczych lotek umożliwi w przyszłości tworzenie bardziej szczegółowych statystyk dotyczących trafianych pól.

9. Liczba legów jest konfigurowalna

Liczba legów nie może być ustawiona na stałe dla całego turnieju.

Poszczególne etapy mogą mieć różny format.

Przykład:

grupy → First to 2 playoff → First to 3 półfinał → First to 4 finał → First to 5

Nie tworzymy z tego osobnych rodzajów gry.

Cały czas jest to ten sam klocek 01, któremu zmienia się odpowiedni parametr.

10. Dziedziczenie ustawień

Ustawienia powinny być dziedziczone:

DOMYŚLNE SYSTEMU ↓ TURNIEJ ↓ FAZA ↓ RUNDA ↓ MECZ

Niższy poziom może nadpisać parametr wyższego poziomu.

Przykładowo:

TURNIEJ 501 / Straight In / Double Out / First to 3 ↓ PÓŁFINAŁ First to 4 ↓ FINAŁ First to 5

Pozostałe ustawienia są dziedziczone.

Dzięki temu nie trzeba konfigurować każdego meczu oddzielnie.

11. Przyszły interfejs przy tarczy

Interfejs tabletowy nie będzie osobnym silnikiem gry.

Będzie korzystał z tego samego 01.

Na początku sędzia może wpisywać:

140

W przyszłości zawodnik/sędzia może użyć graficznej tarczy:

T20 → T20 → 20 ↓ 140

W obu przypadkach do silnika trafia ta sama kolejka (VISIT).

12. Rozdzielenie gry od turnieju

Po zakończeniu meczu silnik 01 przekazuje do systemu turniejowego jego wynik.

Przykład:

GRA 01 │ │ Kowalski 3 : 1 Nowak ▼ MECZ ZAKOŃCZONY │ ▼ ROUND ROBIN / PLAYOFF

System Round Robin czy Playoff nie musi znać przebiegu poszczególnych kolejek.

Dostaje wynik meczu potrzebny do dalszego prowadzenia turnieju.

Status

🟢 Architektura podstawowa ustalona

Do dalszego rozpracowania pozostają m.in.:

• dokładny model LEG,
• Bust,
• checkout,
• Double In / Double Out,
• sety,
• sposób określania formatu meczu (First to X / Best of X),
• szczegółowy zakres statystyk.

</details>

To jest wersja, którą już spokojnie możesz wkleić do swoich notatek jako 05. Klocek gry — 01 v0.1.

Jasne. Robimy 06. MECZ — wersję do skopiowania, już z poprawką, że ręczne wpisywanie końcowego wyniku jest tylko rozwiązaniem testowym/awaryjnym.

<details open> <summary>⚔️ 06. MECZ — v0.1</summary>

1. Czym jest mecz

Mecz jest pojedynczym spotkaniem pomiędzy zawodnikami.

Powstaje w wyniku działania odpowiedniego klocka turniejowego:

ROUND ROBIN ─┐ │ PLAYOFF ─────┼──→ MECZ │ FINAL ───────┘

Mecz nie decyduje, kto ma z kim grać. Otrzymuje zawodników od fazy turnieju, która go utworzyła.

Mecz stanowi łącznik pomiędzy silnikiem turniejowym a silnikiem gry.

2. Podstawowe dane meczu

Mecz musi posiadać lub otrzymywać z powiązanych elementów informacje takie jak:

Nie oznacza to, że wszystkie te informacje muszą być powielane w rekordzie meczu. Część może pochodzić z konfiguracji turnieju, fazy lub rundy.

3. Mecze są generowane automatycznie

Podstawowym sposobem powstawania meczów jest generowanie ich przez odpowiedni klocek turniejowy.

Przykład Round Robin:

GRUPA A A B C D ↓ GENERUJ MECZE A–B A–C A–D B–C B–D C–D

Przykład Playoff:

A1 ─┐ ├── MECZ 1 D2 ─┘ B1 ─┐ ├── MECZ 2 C2 ─┘

Admin nie powinien ręcznie tworzyć wszystkich spotkań turnieju.

4. Konfiguracja gry

Mecz korzysta z zasad odziedziczonych z wyższych poziomów:

DOMYŚLNE SYSTEMU ↓ TURNIEJ ↓ FAZA ↓ RUNDA ↓ MECZ

Niższy poziom może nadpisać wybrany parametr.

Przykład:

TURNIEJ 501 / Straight In / Double Out / First to 3 ↓ PÓŁFINAŁ First to 4 ↓ FINAŁ First to 5

Pozostałe parametry pozostają odziedziczone.

Dzięki temu wygenerowany mecz powinien być od razu gotowy do rozpoczęcia.

5. Przypisanie tarczy

Mecz może zostać przypisany do konkretnej tarczy.

Przykład:

TARCZA 7 Kowalski vs Nowak 501 / Double Out First to 4 [ START ]

Przypisanie tarczy będzie wykorzystywane zarówno przez organizatora, jak i przez przyszły interfejs znajdujący się przy tarczy.

6. Docelowy sposób prowadzenia meczu — KOLEJKI

Podstawowym sposobem prowadzenia meczu będzie interfejs przy tarczy.

Domyślnie wynik wprowadzany jest całymi kolejkami (VISIT).

Przykład:

Kowalski 501 [ 140 ] → ENTER 361

Naciśnięcie ENTER kończy kolejkę i przekazuje dane do silnika 01.

Podstawową jednostką zapisu pozostaje więc:

VISIT / KOLEJKA

a nie końcowy wynik meczu.

7. Interfejs podstawowy

Podstawowy interfejs nie wymaga wpisywania każdej lotki.

Użytkownik wpisuje wynik kolejki:

140 ENTER

Silnik:

• zapisuje kolejkę,
• odejmuje wynik,
• oblicza pozostały wynik,
• zmienia zawodnika,
• kontroluje Bust,
• kontroluje zakończenie lega,
• aktualizuje przebieg meczu.

Dzięki temu obsługa przy tarczy pozostaje szybka.

Do czasu zakończenia meczu musi istnieć możliwość korekty błędnie wprowadzonej kolejki i ponownego przeliczenia wynikającego z niej stanu gry.

8. Interfejs rozszerzony — pojedyncze lotki

Silnik jest od początku przygotowany na możliwość późniejszego zastosowania interfejsu odwzorowującego tarczę.

Zamiast wpisania:

140 ENTER

użytkownik może w przyszłości zaznaczyć:

T20 T20 20

System sam oblicza:

140

i tworzy tę samą kolejkę VISIT.

Czyli:

VISIT wynik = 140 / \ / \ 140 + ENTER T20 T20 20

Są to dwa sposoby wprowadzania danych do tego samego silnika gry.

9. Historia meczu

Normalnie rozegrany mecz powinien posiadać historię przebiegu kolejka po kolejce.

Przykład:

LEG 1 Kowalski 501 → 140 → 361 Nowak 501 → 100 → 401 Kowalski 361 → 180 → 181 Nowak 401 → 85 → 316 ...

Historia kolejek pozwoli później tworzyć statystyki bez konieczności zmiany sposobu działania systemu.

10. Statystyki

Dane z przebiegu meczu mogą być wykorzystywane do wyliczania statystyk zawodników.

Już tryb kolejkowy pozwala gromadzić wiele informacji, m.in.:

• średnią,
• liczbę kolejek,
• liczbę wykorzystanych lotek,
• maximum 180,
• checkouty,
• wyniki legów.

Opcjonalny zapis każdej lotki umożliwi w przyszłości tworzenie znacznie bardziej szczegółowych statystyk.

11. Ręczne wpisanie końcowego wyniku

Możliwość wpisania bezpośrednio:

Kowalski 4 : 2 Nowak

pozostawiamy jako:

• narzędzie podczas testowania systemu,
• rozwiązanie awaryjne,
• ewentualne narzędzie administracyjne.

Nie jest to docelowy sposób prowadzenia turnieju.

Docelowo normalny wynik meczu powstaje z rozegranych i zapisanych legów oraz kolejek.

12. Status meczu

Podstawowe statusy:

OCZEKUJE ↓ W TRAKCIE ↓ ZAKOŃCZONY

W przyszłości mogą być potrzebne dodatkowe stany, np.:

• walkower,
• przerwany,
• anulowany.

Ich dokładne zachowanie zostanie określone później.

13. Zakończenie meczu

Silnik 01 kontroluje liczbę wygranych legów/setów.

Po osiągnięciu warunku zwycięstwa:

Kowalski 4 Nowak 2 ↓ KONIEC MECZU

mecz otrzymuje:

wynik: 4 : 2 zwycięzca: Kowalski przegrany: Nowak status: ZAKOŃCZONY

14. Przekazanie wyniku do turnieju

Po zakończeniu meczu jego wynik wraca do klocka turniejowego.

Round Robin:

MECZ ↓ 4 : 2 ↓ CLASSIFICATION

Playoff:

MECZ ↓ ZWYCIĘZCA ↓ następna runda

Double Elimination:

MECZ ├── zwycięzca → dalsza ścieżka └── przegrany → odpowiednia ścieżka

Sam mecz nie decyduje, co dalej dzieje się z zawodnikami. Odpowiada za to klocek turniejowy.

15. Zasada nadrzędna

TURNIEJ ↓ FAZA ↓ MECZ ↓ GRA 01 ↓ KOLEJKI ↓ LEGI / SETY ↓ WYNIK MECZU ↓ FAZA TURNIEJU

Mecz łączy strukturę turnieju z rzeczywistą rozgrywką przy tarczy.

Podstawowym docelowym sposobem prowadzenia meczu jest zapis kolejka po kolejce, natomiast sposób wprowadzania kolejki może być prosty (140 + ENTER) lub w przyszłości szczegółowy (T20 + T20 + 20).

Status

🟢 Architektura podstawowa ustalona

Do późniejszego dopracowania pozostają m.in. statusy awaryjne, walkowery, korekta błędnie wprowadzonego wyniku oraz szczegółowe zasady przypisywania tarcz.

</details>

Tak. To teraz zamykamy 07. WYNIKI w wersji do skopiowania, z uwzględnieniem naszych najnowszych ustaleń o korektach, jednym źródle danych i statystykach dodatkowych. 05 i 06 na razie zostawiasz u siebie bez przepisywania.

<details open> <summary>📊 07. WYNIKI — v0.1</summary>

1. Jedno źródło wyniku

Wynik meczu istnieje w systemie tylko raz.

Nie tworzymy osobnych kopii wyniku dla:

• tabeli grupowej,
• drabinki,
• telebimu,
• strony publicznej,
• panelu administratora,
• interfejsu przy tarczy.

Wszystkie te widoki korzystają z tego samego źródła danych.

MECZ ↓ WYNIK ├── ADMIN ├── TABELA ├── DRABINKA ├── WWW ├── TELEBIM └── TABLET

2. Wynik powstaje z przebiegu meczu

Docelowo wynik meczu nie jest zwykle wpisywany ręcznie jako 3:1.

Powstaje z przebiegu:

KOLEJKI / VISITS ↓ LEGI ↓ SETY (jeśli używane) ↓ WYNIK MECZU

Przykład:

Kowalski 3 Nowak 1

Po zakończeniu meczu wynik zostaje przekazany do odpowiedniego klocka turniejowego.

3. Znaczenie wyniku zależy od fazy

W Round Robin:

Kowalski 3 : 1 Nowak

oznacza m.in.:

• zwycięstwo/przegraną,
• liczbę wygranych i przegranych legów,
• dane potrzebne do klasyfikacji grupy.

W Playoff ten sam wynik oznacza przede wszystkim:

Kowalski → awans Nowak → odpada

W Double Elimination wynik może powodować przekazanie zwycięzcy i przegranego do odpowiednich ścieżek.

Sam wynik nie decyduje, co dalej robić z zawodnikami. Robi to odpowiedni klocek turniejowy.

4. Wynik sportowy i statystyki są oddzielone

Rozdzielamy:

wynik sportowy

3 : 1

od:

statystyk przebiegu

np.:

• średnia 3-dartowa,
• First 9,
• 100+,
• 140+,
• 180 / maxy,
• bull,
• checkout,
• High Finish,
• Best Leg,
• liczba lotek.

Statystyki nie zmieniają samego wyniku meczu.

5. Punkty klasyfikacyjne i rankingowe to dwa różne pojęcia

System powinien od początku rozróżniać:

Punkty klasyfikacyjne

• wynikają z wyniku meczu,
• służą np. do tabeli Round Robin.

Punkty rankingowe / bonusowe

• mogą wynikać ze statystyk,
• są opcjonalne,
• ich zasady określa dana liga lub turniej.

Przykładowo konkretna liga może przyznawać dodatkowe punkty za:

• maxy,
• bulle,
• zakończenia powyżej 100.

Nie jest to część podstawowego wyniku sportowego.

6. Statystyki mogą być agregowane

Dane z pojedynczego meczu nie powinny ginąć po jego zakończeniu.

Powinny dać się agregować:

KOLEJKA ↓ LEG ↓ MECZ ↓ FAZA ↓ TURNIEJ ↓ HISTORIA ZAWODNIKA

Dzięki temu możliwe będzie później pokazanie np.:

180: mecz → 3 turniej → 11 sezon → 87

Zakres takich statystyk może być później rozwijany.

7. Korekta podczas trwającego meczu

Pomyłki wprowadzania wyniku są normalnym przypadkiem.

Dopóki mecz trwa, interfejs przy tarczy musi umożliwiać:

• poprawienie wcześniejszej kolejki,
• cofnięcie się do wcześniejszego lega,
• ponowne przeliczenie stanu meczu.

Historia przebiegu meczu może być jednocześnie interfejsem korekty.

Przykład:

180 ↓ klik 140 ↓ system przelicza dalszy stan

8. Zakończenie meczu blokuje korekty przy tarczy

Po zakończeniu meczu wynik staje się oficjalny.

Interfejs przy tarczy nie może wtedy samodzielnie ponownie otworzyć meczu.

TRWAJĄCY MECZ → korekty dozwolone przy tarczy ZAKOŃCZONY MECZ → korekta tylko ADMIN

Ma to chronić dane, ponieważ wynik mógł już:

• zmienić klasyfikację,
• przesunąć zawodnika w drabince,
• wygenerować kolejny mecz,
• zostać opublikowany.

9. Korekta administracyjna

Administrator może skorygować również zakończony mecz.

Zmiana źródłowego wyniku powinna powodować automatyczne przeliczenie wszystkich danych zależnych, o ile jest to jeszcze bezpiecznie możliwe.

KOREKTA MECZU ↓ NOWY WYNIK ↓ PRZELICZENIE ↓ KLASYFIKACJA / DRABINKA / WIDOKI

Szczególne przypadki, w których kolejna faza już trwa, zostaną opracowane później jako sytuacje administracyjne.

10. Wyniki grupowe

Na podstawie wyników meczów Round Robin system buduje tabelę grupy.

Przykładowe dane mogą obejmować:

mecze wygrane przegrane legi + legi - bilans punkty klasyfikacyjne

Dokładna kolejność kryteriów i zasady klasyfikacji należą do klocka Classification.

11. Aktualizacja jest automatyczna

Po zatwierdzeniu wyniku nie ma dodatkowego ręcznego przepisywania.

MECZ ZAKOŃCZONY ↓ WYNIK ↓ ┌──────────────┬──────────────┬──────────────┐ │ klasyfikacja │ drabinka │ widoki live │ └──────────────┴──────────────┴──────────────┘

Wszystkie elementy korzystają z jednego źródła.

12. Live

Podstawowy tryb prowadzenia przy tarczy zapisuje dane po zatwierdzeniu kolejki:

140 ENTER ↓ VISIT ZAPISANY ↓ LIVE

Nie ma potrzeby wysyłania danych bez przerwy.

Jeżeli w przyszłości powstanie interfejs pojedynczych lotek, można zdecydować, czy dane publiczne odświeżać po każdej lotce, czy nadal po zakończeniu kolejki.

Nie zmienia to struktury wyniku.

13. Historia

Wyniki rozegranych meczów pozostają dostępne także po przejściu turnieju do następnej fazy i po jego zakończeniu.

Powinna być możliwa nawigacja:

TURNIEJ ↓ FAZA / GRUPA ↓ MECZ ↓ WYNIK ↓ PRZEBIEG / STATYSTYKI

Wyniki są więc nie tylko bieżącym stanem turnieju, ale również jego archiwum.

14. Zasada nadrzędna

Wynik powstaje raz i stanowi jedno źródło prawdy dla całego systemu.

Statystyki są osobną warstwą danych, a wszelkie korekty odbywają się na źródle i powodują przeliczenie danych zależnych.

Status

🟢 Architektura podstawowa ustalona

Do późniejszego dopracowania pozostają:

• szczegółowe kryteria Classification,
• zachowanie przy korekcie meczu, gdy następna faza już się rozpoczęła,
• szczegółowy system punktów bonusowych/rankingowych,
• dokładny zakres statystyk.

</details>

Jasne. Robimy wersję do skopiowania. Nie dokładam już nowych pomysłów — zapisuję to, co ustaliliśmy.

<details open> <summary>⚖️ 08. REGUŁY KLASYFIKACJI / TIE-BREAK — v0.1</summary>

1. Zadanie Classification

Classification odpowiada za ustalenie kolejności zawodników na podstawie wyników rozegranych meczów.

W przypadku Round Robin:

WYNIKI MECZÓW ↓ CLASSIFICATION ↓ 1. Kowalski 2. Nowak 3. Wiśniewski 4. ... ↓ A1 / A2 / A3 / ...

Ostateczna kolejność może następnie zostać wykorzystana przez kolejną fazę turnieju.

2. Łańcuch kryteriów

Kryteria klasyfikacji mają określoną kolejność.

KRYTERIUM 1 ↓ remis KRYTERIUM 2 ↓ remis KRYTERIUM 3 ↓ remis ... ↓ ROZSTRZYGNIĘCIE SPECJALNE

Kolejne kryterium jest sprawdzane tylko wtedy, gdy poprzednie nie pozwoliło jednoznacznie ustalić kolejności.

3. Kryteria są elementem zasad turnieju

Organizator określa sposób klasyfikacji przed rozpoczęciem turnieju.

System posiada wartości domyślne, ale tam, gdzie regulamin na to pozwala, organizator może wybrać inną metodę lub kolejność kryteriów.

Przyjęte zasady powinny być możliwe do opublikowania razem z regulaminem turnieju.

Dzięki temu zawodnicy przed rozpoczęciem rozgrywek wiedzą, w jaki sposób będą rozstrzygane remisy.

4. Podstawowe kryteria

Klasyfikacja może wykorzystywać m.in.:

• punkty klasyfikacyjne,
• wygrane/przegrane mecze,
• wygrane/przegrane legi,
• bilans legów,
• wynik bezpośredniego spotkania.

Dokładna kolejność kryteriów wynika z konfiguracji danego turnieju.

5. Nierozstrzygnięty remis

Może wystąpić sytuacja, w której wszystkie automatyczne kryteria zostały wykorzystane, a system nadal nie jest w stanie jednoznacznie ustalić kolejności.

Typowym przypadkiem jest remis trzech zawodników:

A wygrał z B B wygrał z C C wygrał z A

przy jednoczesnym braku rozstrzygnięcia przez pozostałe kryteria.

W takim przypadku system nie ustala kolejności arbitralnie.

Zgłasza konieczność przeprowadzenia dodatkowego rozstrzygnięcia.

6. Metoda rozstrzygnięcia

Domyślną metodą dla nierozstrzygniętego remisu trzech zawodników jest:

GOLDEN LEG — 3 zawodników

Metoda rozstrzygnięcia jest jednak elementem konfiguracji turnieju.

Organizator może wybrać inną dopuszczoną metodę.

W wersji ostatecznej należy tutaj umieścić pełną listę metod tie-break ustaloną wcześniej.

7. Golden Leg 3P

Golden Leg 3P jest specjalnym trybem rozgrywki przeznaczonym wyłącznie do rozstrzygnięcia nierozstrzygalnego remisu trzech zawodników.

NIEROZSTRZYGNIĘTY REMIS ↓ 3 ZAWODNIKÓW ↓ GOLDEN LEG 3P ↓ USTALONA KOLEJNOŚĆ ↓ CLASSIFICATION

Nie jest to normalny mecz Round Robin ani dodatkowy mecz turniejowy.

8. Golden Leg nie zmienia wcześniejszych wyników

Golden Leg 3P służy wyłącznie do ustalenia kolejności remisujących zawodników.

Nie powoduje:

• dodania zwycięstwa do wcześniejszych wyników grupowych,
• dodania porażki,
• zmiany punktów klasyfikacyjnych,
• zmiany bilansu legów,
• zmiany wyników wcześniej rozegranych spotkań.

Jego wynikiem jest wyłącznie:

1. zawodnik A 2. zawodnik C 3. zawodnik B

Ta informacja wraca do Classification.

9. Specjalny tryb silnika 01

Standardowy silnik 01 obsługuje mecz dwóch zawodników.

Dla tego szczególnego przypadku przewidujemy specjalny tryb:

01 / Golden Leg 3P

obsługujący dokładnie trzech zawodników.

Nie generalizujemy obecnie silnika na dowolną liczbę zawodników, ponieważ nie ma takiej potrzeby w normalnym przebiegu turnieju.

10. Zakończenie klasyfikacji

Dopóki istnieje nierozstrzygnięty remis mający znaczenie dla kolejności, klasyfikacja nie jest ostateczna.

WYNIKI ↓ CLASSIFICATION ↓ REMIS? ┌─┴─┐ NIE TAK │ ↓ │ TIE-BREAK │ ↓ │ WYNIK │ │ └────┘ ↓ KLASYFIKACJA OSTATECZNA

Dopiero po rozstrzygnięciu system może przekazać ostateczne pozycje A1, A2, A3 itd. do następnego klocka.

11. Zasada nadrzędna

System stosuje ustalone wcześniej kryteria tak długo, jak długo możliwe jest automatyczne rozstrzygnięcie. Jeżeli kryteria nie wystarczają, nie zgaduje wyniku — uruchamia określoną w zasadach turnieju procedurę tie-break.

Dla szczególnego remisu trzech zawodników domyślną procedurą jest Golden Leg 3P.

Status

🟢 Architektura podstawowa ustalona

Do wersji ostatecznej pozostaje uzupełnienie pełnej listy alternatywnych metod tie-break ustalonej wcześniej.

</details>

08 możemy uznać za zamknięty.

<details open> <summary>🔄 08. DZIEDZICZENIE USTAWIEŃ — v0.1</summary>

1. Zasada podstawowa

Turniej definiuje domyślne ustawienia gry, które są automatycznie przekazywane do każdego tworzonego meczu.

TURNIEJ ↓ USTAWIENIA DOMYŚLNE ↓ MECZ ↓ INTERFEJS PRZY TARCZY

Dzięki temu przed każdym meczem nie trzeba ponownie konfigurować tych samych parametrów.

2. Ustawienia meczu

Przykładowa konfiguracja turnieju:

Gra: 501 In: Straight In Out: Double Out First to: 2 Limit rund: 15

Nowy mecz otrzymuje te wartości automatycznie.

Jeżeli nie ma potrzeby ich zmiany, zawodnicy mogą praktycznie od razu rozpocząć grę.

3. Zmiana przed rozpoczęciem meczu

Wybrane ustawienia mogą zostać zmienione bezpośrednio przy tarczy przed rozpoczęciem konkretnego meczu.

Przykładowo:

TURNIEJ First to: 2 ↓ FINAŁ przy tarczy: First to: 4 ↓ START

Zmiana dotyczy wyłącznie tego konkretnego meczu i nie zmienia ustawień całego turnieju.

4. Limit rund

Tak samo działa opcjonalny limit rund.

Domyślnie turniej może mieć:

Limit rund: ON Rundy: 15

ale przed rozpoczęciem konkretnego meczu można go wyłączyć, np. dla rozgrywek dziecięcych:

Limit rund: OFF

5. Ustawienia po rozpoczęciu meczu

Konfiguracja gry jest ustalana przed rozpoczęciem meczu.

Po rozpoczęciu rozgrywki nie traktujemy zmiany zasad jako zwykłej funkcji interfejsu.

Ewentualne sytuacje wyjątkowe mogą być później obsługiwane administracyjnie.

6. Zasada nadrzędna

Turniej określa wartości domyślne. Mecz je dziedziczy, a wybrane parametry można nadpisać przy tarczy przed rozpoczęciem gry.

Nie budujemy bardziej skomplikowanego systemu dziedziczenia, dopóki nie pojawi się rzeczywista potrzeba.

Status

🟢 Ustalone

</details>

I tyle. 08 zamknięte. Następny: 09. Interfejsy — i tam już materiału mamy zdecydowanie więcej.