Modify zip commands in release workflow to include files in the folder with the wildcard

Update zip commands to include all files in the directories.

.github/workflows/dispatcher.yml

@@ -0,0 +1,98 @@
+name: Dispatcher
+
+on:
+  push:
+    branches:
+      - '**'
+
+permissions:
+  contents: write
+
+jobs:
+  dispatch:
+    runs-on: self-hosted
+    outputs:
+      engine: ${{ steps.check.outputs.engine }}
+      server: ${{ steps.check.outputs.server }}
+      ui: ${{ steps.check.outputs.ui }}
+    steps:
+      - name: Determine which tests to run
+        id: check
+        run: |
+          BRANCH="${{ github.ref_name }}"
+          echo "Branch: $BRANCH"
+
+          ENGINE=false
+          SERVER=false
+          UI=false
+
+          if [[ "$BRANCH" == *"Engine"* ]]; then
+            ENGINE=true
+          fi
+          if [[ "$BRANCH" == *"Server"* ]]; then
+            SERVER=true
+          fi
+          if [[ "$BRANCH" == *"UI"* ]]; then
+            UI=true
+          fi
+
+          # Run all on master
+          if [[ "$BRANCH" == "master" ]]; then
+            ENGINE=true
+            SERVER=true
+            UI=true
+          fi
+
+          echo "engine=$ENGINE" >> $GITHUB_OUTPUT
+          echo "server=$SERVER" >> $GITHUB_OUTPUT
+          echo "ui=$UI" >> $GITHUB_OUTPUT
+
+  engine:
+    needs: dispatch
+    if: needs.dispatch.outputs.engine == 'true'
+    uses: ./.github/workflows/engine_test.yml
+    secrets: inherit
+
+  server:
+    needs: dispatch
+    if: needs.dispatch.outputs.server == 'true'
+    uses: ./.github/workflows/server_test.yml
+    secrets: inherit
+
+  ui:
+    needs: dispatch
+    if: needs.dispatch.outputs.ui == 'true'
+    uses: ./.github/workflows/ui_test.yml
+    secrets: inherit
+    
+
+  test-data-upload:
+    needs: [engine, server, ui]
+    runs-on: self-hosted
+    if: always()
+    #uses: ./.github/workflows/upload_data.yml
+    steps:
+      - name: Temp turn off
+        run: |
+          echo "Uploading data to table"
+
+  release:
+    needs: test-data-upload
+    if: github.ref == 'refs/heads/master'
+    uses: ./.github/workflows/release.yml
+    secrets: inherit
+
+  cleanup:
+    runs-on: self-hosted
+    needs: [engine, server, ui, test-data-upload, release]
+    if: always()
+    steps:
+      - name: Final cleanup
+        run: |
+          echo "Final cleanup on self-hosted runner..."
+          cd "$GITHUB_WORKSPACE"
+          git clean -fdx
+          git reset --hard
+
+
+

.github/workflows/engine_test.yml

@@ -0,0 +1,17 @@
+name: Engine Tests
+
+on:
+  pull_request:
+  workflow_dispatch:
+  workflow_call:
+
+jobs:
+  engine-tests:
+    runs-on: self-hosted
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Run Engine tests
+        run: |
+          bash .github/workflows/test.sh engine/

.github/workflows/release.yml

@@ -0,0 +1,106 @@
+name: Release build
+
+on:
+  pull_request:
+  workflow_dispatch:
+  workflow_call:
+
+permissions:
+  contents: write
+
+jobs:
+  release:
+    name: Build and release (master only)
+    runs-on: self-hosted
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Build Engine for Linux
+        run: |
+          cd $(git rev-parse --show-toplevel)
+          pwd
+          mkdir release/linux -p
+          cd engine/
+          rustup target add x86_64-unknown-linux-gnu
+          cargo build --release --target x86_64-unknown-linux-gnu
+          pwd
+          cp target/x86_64-unknown-linux-gnu/release/engine $(git rev-parse --show-toplevel)/release/linux/engine
+
+      - name: Build Server for Linux
+        run: |
+          cd $(git rev-parse --show-toplevel)
+          pwd
+          mkdir release/linux -p
+          cd server/
+          rustup target add x86_64-unknown-linux-gnu
+          cargo build --release --target x86_64-unknown-linux-gnu
+          pwd
+          cp target/x86_64-unknown-linux-gnu/release/server $(git rev-parse --show-toplevel)/release/linux/server
+
+      - name: Build UI for Linux
+        run: |
+          cd $(git rev-parse --show-toplevel)
+          pwd
+          mkdir release/linux -p
+          cd ui/
+          rustup target add x86_64-unknown-linux-gnu
+          cargo build --release --target x86_64-unknown-linux-gnu
+          pwd
+          cp target/x86_64-unknown-linux-gnu/release/ui $(git rev-parse --show-toplevel)/release/linux/ui
+
+
+      - name: Build Engine for Windows
+        run: |
+          cd $(git rev-parse --show-toplevel)
+          pwd
+          mkdir release/windows -p
+          cd engine/
+          rustup target add x86_64-pc-windows-gnu
+          cargo build --release --target x86_64-pc-windows-gnu
+          pwd
+          cp target/x86_64-pc-windows-gnu/release/engine.exe $(git rev-parse --show-toplevel)/release/windows/engine.exe
+
+      - name: Build Server for Windows
+        run: |
+          cd $(git rev-parse --show-toplevel)
+          pwd
+          mkdir release/windows -p
+          cd server/
+          rustup target add x86_64-pc-windows-gnu
+          cargo build --release --target x86_64-pc-windows-gnu
+          pwd
+          cp target/x86_64-pc-windows-gnu/release/server.exe $(git rev-parse --show-toplevel)/release/windows/server.exe
+
+      - name: Build UI for Windows
+        run: |
+          cd $(git rev-parse --show-toplevel)
+          pwd
+          mkdir release/windows -p
+          cd ui/
+          rustup target add x86_64-pc-windows-gnu
+          cargo build --release --target x86_64-pc-windows-gnu
+          pwd
+          cp target/x86_64-pc-windows-gnu/release/ui.exe $(git rev-parse --show-toplevel)/release/windows/ui.exe
+      
+      - name: Compress build folders for upload
+        run: |
+          cd $(git rev-parse --show-toplevel)
+          pwd
+          cd release/
+          zip linux.zip linux/*
+          zip windows.zip windows/*
+
+      - name: Create GitHub Release
+        uses: softprops/action-gh-release@v2
+        with:
+          tag_name: "v${{ github.run_number }}"
+          name: "Release v${{ github.run_number }}"
+          generate_release_notes: true
+          files: |
+            release/linux.zip
+            release/windows.zip
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+

.github/workflows/server_test.yml

@@ -0,0 +1,17 @@
+name: Server Tests
+
+on:
+  pull_request:
+  workflow_dispatch:
+  workflow_call:
+
+jobs:
+  server-tests:
+    runs-on: self-hosted
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Run Server tests
+        run: |
+          bash .github/workflows/test.sh server/

.github/workflows/test.sh

@@ -0,0 +1,37 @@
+#!/usr/bin/env bash
+set -e
+
+# --- ARGUMENT CHECK ---
+if [ -z "$1" ]; then
+  echo "Usage: $0 <project_path>"
+  exit 1
+fi
+
+# --- SETUP VARIABLES ---
+PROJECT_PATH="$1"
+PROJECT_NAME=$(basename "$PROJECT_PATH")
+ROOT_DIR=$(git rev-parse --show-toplevel)
+
+LOG_FILE="${PROJECT_NAME}_test.log"
+FINAL_LOG="${ROOT_DIR}/test_data.log"
+
+# --- MOVE TO PROJECT DIRECTORY ---
+echo ">>> Running tests for project: $PROJECT_NAME"
+cd "$PROJECT_PATH" || { echo "Error: Could not cd into $PROJECT_PATH"; exit 1; }
+
+# --- RUN TESTS ---
+cargo test --verbose | tee full_test_output.log
+
+# --- EXTRACT TEST SECTION ---
+# Create the log file with the project name as the first line
+echo "$PROJECT_NAME" > "$LOG_FILE"
+
+# Then append only the lines between "running X test(s)" and the first empty line
+awk '/^running [0-9]+ test[s]?$/,/^$/' full_test_output.log >> "$LOG_FILE"
+
+# --- APPEND TO GLOBAL LOG (in repo root) ---
+cat "$LOG_FILE" >> "$FINAL_LOG"
+
+# --- SUMMARY ---
+echo ">>> Test output extracted to $PROJECT_PATH/$LOG_FILE"
+echo ">>> Appended to $FINAL_LOG"

.github/workflows/ui_test.yml

@@ -0,0 +1,17 @@
+name: UI Tests
+
+on:
+  pull_request:
+  workflow_dispatch:
+  workflow_call:
+
+jobs:
+  ui-tests:
+    runs-on: self-hosted
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Run UI tests
+        run: |
+          bash .github/workflows/test.sh ui/

.github/workflows/upload_data.yml

@@ -0,0 +1,57 @@
+name: Upload Test Results to Google Sheets
+
+on:
+  workflow_dispatch:
+
+jobs:
+  upload:
+    runs-on: self-hosted
+    steps:
+      - name: Checkout repo
+        uses: actions/checkout@v4
+
+      - name: Setup Python (for Google Sheets API)
+        uses: actions/setup-python@v5
+        with:
+          python-version: '3.x'
+
+      - name: Install dependencies
+        run: |
+          pip install gspread google-auth
+
+      - name: Upload test_data.log to Google Sheets
+        env:
+          GOOGLE_SERVICE_ACCOUNT_JSON: ${{ secrets.GOOGLE_SERVICE_ACCOUNT_JSON }}
+          SPREADSHEET_ID: ${{ secrets.SPREADSHEET_ID }}
+        run: |
+          echo "$GOOGLE_SERVICE_ACCOUNT_JSON" > service_account.json
+          
+          python <<'PYCODE'
+          import gspread, json, time
+
+          # credentials
+          creds = json.load(open("service_account.json"))
+          gc = gspread.service_account_from_dict(creds)
+          sh = gc.open_by_key("${{ secrets.SPREADSHEET_ID }}")
+
+          with open("test_data.log", "r") as f:
+              lines = [line.strip() for line in f if line.strip()]
+
+          project = lines[0].lower()
+          worksheet = sh.worksheet(project)
+
+          # project name
+          data = lines[1:]
+
+          #blank rows
+          existing_rows = len(worksheet.get_all_values())
+          start_row = existing_rows + 3
+
+          # Split data into columns (by spaces)
+          rows_to_append = [row.split() for row in data]
+
+          for i, row in enumerate(rows_to_append):
+              worksheet.insert_row(row, start_row + i)
+
+          print(f"Uploaded {len(rows_to_append)} rows to '{project}' tab.")
+          PYCODE

Docs/funk_spec.md

@@ -0,0 +1,51 @@
+## 5. Követelménylista
+
+### Szerver
+| Név | Verzió | Leírás |
+| --- | ------ | ------ |
+| **WebSocket**                  | 1.0    | A szerver és a kliens között folyamatos kétirányú kommunikációt biztosít. A kapcsolat létrejötte után a szerver valós időben képes fogadni és továbbítani az eseményeket (pl. lépés végrehajtása, állapotfrissítés). Hiba esetén a kapcsolat automatikusan újraépül.              |
+| **Kapcsolatok csoportosítása** | 1.0    | A szerver figyeli az elérhető, szabad klienseket, majd két szabad kapcsolatot automatikusan összerendel egy meccsbe. A csoportosítás után a játékosok azonos „room”-ba kerülnek, és a szerver biztosítja az egymás közötti adatkommunikációt.                                     |
+| **Kommunikáció az engine-nel** | 1.0    | A szerver a játékosoktól érkező lépéseket és játékinformációkat továbbítja az engine-nek feldolgozásra. Az engine válasza után a szerver visszaküldi az eredményt a klienseknek (pl. érvényes lépés, matt, patt). A kommunikáció aszinkron módon zajlik, válaszidő-ellenőrzéssel. |
+| **Kommunikáció a UI-al**       | 1.0    | A szerver WebSocket-en keresztül adatokat továbbít a felhasználói felület és az engine között. A UI által kért műveletek (pl. új meccs létrehozása, állapotlekérés) feldolgozását a szerver közvetíti.|
+### Engine
+| Név | Verzió | Leírás |
+| --- | ------ | ------ |
+| **Bitboard** | 1.0 | A játék táblaállapotát bitműveletekkel reprezentálja a hatékonyság érdekében. Minden bábu típus és szín külön bitmask-on kerül tárolásra, lehetővé téve a gyors lekérdezéseket és lépésellenőrzéseket. |
+| **Lépésgenerálás LUT** | 1.0 | Előre kiszámított lookup táblák segítségével gyorsítja a lépésgenerálást és szabályellenőrzést. Ez csökkenti a számítási időt, és optimalizálja az engine teljesítményét. |
+| **Lépésgenerálás** | 1.0 | A különböző bábutípusok (gyalog, bástya, futó, stb.) lépési logikáját valósítja meg. A függvények ellenőrzik a lépés érvényességét, figyelembe véve az aktuális állást, sakkhelyzetet és speciális szabályokat (pl. sáncolás, en passant). |
+| **Util függvények** | 1.0 | Segédfüggvények az engine belső működéséhez, például raycast műveletek, bitműveleti maszkok kezelése, valamint logikai ellenőrzések a lépések és ütések számításához. |
+
+### UI
+| Név | Verzió | Leírás |
+| --- | ------ | ------ |
+| **Belépés** | 1.0 | A felhasználó a kezdőképernyőn keresztül adhatja meg a nevét lokális játékhoz, vagy hitelesítheti magát online játékmód esetén. Hibás adatok esetén a rendszer figyelmeztetést küld. |
+| **Főmenü** | 1.0 | Az alkalmazás központi navigációs felülete, ahol a felhasználó meccset kereshet, új játékot indíthat lokálisan, vagy beállításokat módosíthat. A menü megjeleníti az aktuális státuszt (online/offline). |
+| **Játék** | 1.0 | A játékfelület megjeleníti a táblát, bábukat, lépéseket, és az aktuális játékállást. Támogatja mind az online, mind a lokális módot. A felület kezeli az interakciókat (lépéskattintás, visszavonás, végeredmény kijelzés). |
+| **Kommunikáció a szerverrel** | 1.0 | A kliens a szerveren keresztül kommunikál az engine-nel. A UI felel az üzenetek küldéséért (lépés, új játék, visszajelzés), valamint a szervertől kapott események vizuális megjelenítéséért. |
+
+
+### GitHub Actions (CI/CD)
+| Név | Leírás |
+| --- | ------ |
+| Folyamatos tesztelés | A projekt minden commit után automatikusan tesztelődik. A pipeline lefuttatja a teszteket, és értesítést küld hibás build esetén. |
+| Folyamatos integráció | Az új funkciók beolvadásakor a rendszer automatikusan integrálja a változtatásokat, új buildet hoz létre, és frissíti a fejlesztői környezetet. |
+| Tesztadatok | A tesztadatok legyenek elérhetőek egy táblázatban, dátummal ellátva. (Google Sheets) |
+
+## A github workflow folyamata:
+
+A githubon tárolt kód minden feltöltésnél a kód mindig automatikus tesztelve van, egy workflow által. Ennek a működése:
+1. A brancheket a következő képpen kell elnevezni: Projekt/task_neve (a task neve a kanban tablabol jon).
+2. 3 projekt van a github repository-ban: Engine, Server és a UI. Ennek megfelelően a következőképpen kell kinézniük a brancheknek: 
+    - Engine/task_1
+    - Server/task_1
+    - UI/task_1
+    Erre azért van szükség mert a github workflow ezek alapján az elnevezések alapján fogja eldönteni melyik teszteket futtassa. Ha az Engine projekthez lett feltöltve kód, akkor csak az ahhoz tartozó teszteket futtassa.
+3. A workflow folyamat a következő:
+    Amikor feltöltődik a három projekt közül valamelyikére egy új commit. A github workflow megnézni mi a branch neve. Ezután letölti a projektet githubról, és lefuttatja azon projekt teszteit. A tesztek eredményét feltölti egy google táblazat fájlba, ahonnan bármikor visszenézhető. Minden teszt eredmény az annak megfelően elnevezett munkalapra kerül be (Engine, Server, UI), egymás alá táblázatos elrendezésben. Az oszlopok a következőek: Dátum, függvény neve, teszt bemenet, teszt kimenet, sikeres-e.
+    Amikor a main/master branchre kerül fel kód. A teszt az előbbiek alapján ugyanúgy lefut, csak itt mind a 3 projekt tesztje le fog futni és az eredmény egy main/master nevű munkalapra fog feltöltődni a táblázatban. Amint sikeresen lefut a tesztelés, elindul egy automatikus build, ami le fogja build-elni a projekteket. Ezután létrehoz egy új Release-t githubon, ahol beállítja a verzió számot a rust projektben beállított verzió számra, majd feltölti oda a fájlokat amiket a build hozott létre, és kiteszi ezt a buildet.
+
+
+A workflow 3 külön fáljba van bontva:
+1. A dispatcher (dispatch.yml). Ez indítja el a workflow-t ami teszteli a kódot a megfelelő branchen, elindítja a release workflow-t ami feltölti a master branchről buildelt projekt fájlokat.
+2. A teszter (tests.yml). Ez a workflow bele fog lépni a megfelelő projekt mappába és lefutattja a megírt teszteket, és feltölti az eredményt egy google spreadsheet-be.
+3. A release (release.yml). Amint sikeresek a tesztek elindul ez a workflow és lefordítja a kódot majd feltölti github-ra egy új release-ként

Docs/kovspec.md

@@ -1,187 +0,0 @@
-# Követelmény-specifikáció
-
-## 1. Áttekintés
-
-A jelen dokumentum célja, hogy bemutassa a CastlingCreations megrendelésére készülő Knightly nevű alkalmazás alapvető céljait, funkcionális és nem funkcionális követelményeinek áttekintését, valamint a fejlesztés kontextusát.
-
-A Knightly egy modern, digitális sakkalkalmazás, amely kezdetben helyi hálózaton (LAN) keresztül teszi lehetővé két játékos számára, hogy valós időben mérkőzzenek meg egymással. A rendszer egy grafikus felhasználói felületen keresztül biztosítja a játék indítását, a szerver futtatását és a másik félhez történő csatlakozást.
-
-A projekt hosszú távú célja, hogy a Knightly egy online platformmá fejlődjön, amely hasonló módon működik, mint a népszerű sakkportálok (pl. chess.com): a felhasználók fiókot hozhatnak létre, bejelentkezhetnek, és egy központi szerveren keresztül kereshetnek, illetve indíthatnak mérkőzéseket.
-
-A fejlesztés első szakasza azonban a LAN-alapú verzió megvalósítására koncentrál, amely a sakkjátszma logikai alapjainak, a játékállapot kezelésének és a hálózati kommunikáció modelljének megvalósítását célozza. A későbbi online verzió ezekre az alapokra építkezve bővíthető tovább.
-
-## 2. Vágyálom rendszer
-A vágyálom rendszer célja egy teljes körű, modern online sakkplatform létrehozása, amely nemcsak a klasszikus sakkjáték digitális megvalósítását kínálja, hanem egy közösségi, versenyképes és kényelmes felhasználói élményt is biztosít. A hosszú távú cél, hogy a rendszer működése és felépítése a nagyobb nemzetközi sakkoldalakhoz (például a chess.com-hoz vagy a lichess.org-hoz) hasonló legyen, de saját, könnyen kezelhető és letisztult felülettel.
-
-A felhasználók a rendszerben saját profilt hozhatnak létre, amellyel be tudnak jelentkezni, és részt vehetnek online mérkőzéseken más játékosok ellen. A rendszer automatikusan párosítaná őket ellenfelekkel, de lehetőséget adna arra is, hogy barátokat hívjanak meg privát meccsekre. A lejátszott mérkőzések mentésre kerülnének, így a játékosok bármikor visszanézhetnék vagy elemezhetnék azokat.
-
-A játék mellett a felhasználók statisztikákat is láthatnának magukról, például nyerési arányt, aktuális értékszámot (rating), leggyakoribb megnyitásokat, illetve fejlődési tendenciát az idő során. A rendszer ezen felül egy egyszerű chat funkciót is tartalmazna, hogy a játékosok kommunikálhassanak egymással a játszmák közben vagy akár azokon kívül is.
-
-A vágyálom rendszer alapját egy központi szerver képezné, amely kezeli a felhasználói fiókokat, a bejelentkezéseket, a matchmaking folyamatot, valamint a játékok futását és szinkronizálását. A szerver a kliensalkalmazásokkal valós idejű adatkapcsolatot tartana fenn, így a játék során minden lépés azonnal megjelenne a másik játékosnál is.
-
-A platform célja a megbízható és folyamatos működés, akár nagyobb terhelés mellett is. A rendszer fejlesztése során kiemelt szempont lenne a biztonság (adatvédelem, csalás elleni védelem), a stabil hálózati kommunikáció, valamint a bővíthetőség – például ranglisták, versenyek vagy mobilalkalmazás későbbi integrálásának lehetősége.
-
-Összességében a vágyálom rendszer egy minden szempontból teljes értékű, közösségorientált sakkalkalmazás lenne, amely a mostani, helyi hálózaton működő változatból fejlődne tovább egy interneten keresztül bárhonnan elérhető platformmá.
-
-## 3. Igényelt funkciók
-
-### Alapok
-- Két játékos közti sakkjátszma lebonyolítása.
-- Teljes szabályrendszer megvalósítása (érvényes lépések, sakk/sakkmatt/patt felismerése).
-- Új játék indítása.
-- Játékosok nevének megadása a játszma elején.
-- Felhasználóbarát grafikus felület (UI) – látható tábla, figurák, órák, státuszjelzések.
-- Játékoslépések vizuális kiemelése (pl. kijelölt mező, lehetséges lépések megjelenítése).
-- A játék állapotának kijelzése (folyamatban, sakk, matt, döntetlen).
-  
-### LAN és hálózati funkciók
-- „Szerver indítása” funkció – a játékos hostként indíthat egy helyi szervert.
-- „Csatlakozás” funkció – másik játékos IP-cím alapján tud csatlakozni.
-- Helyi hálózaton keresztüli valós idejű kommunikáció.
-- LAN játék automatikus felfedezése (broadcast keresés).
-- Játék mentése és visszatöltése hálózati módban.
-
-### Online vágyálom funkciók
-- Felhasználói regisztráció és bejelentkezés.
-- Jelszóval védett fiókok, email- vagy OAuth-alapú hitelesítés (Google, GitHub stb.).
-- Profiloldal megtekintése (név, avatar, statisztikák, értékszám).
-- Automatikus matchmaking rendszer.
-- Kézi játékindítás – meghívó küldése barátnak.
-- Játszmák mentése és visszajátszása.
-- Játszmaelemzés – lépések listázása, hibák kiemelése.
-- Webes felület vagy mobilalkalmazás támogatása.
-- Játék előzményeinek és statisztikáinak megtekintése (győzelmek, vereségek, döntetlenek).
-- Automatikus szervermentés és adatbázis szinkronizáció.
-
-### Felhasználói felület
-- Letisztult, reszponzív, platformfüggetlen felület (asztali és webes verzió).
-- Sötét/világos téma lehetősége.
-- Egyéni figurakészlet vagy tábla kinézet választása.
-- Animált figuramozgások.
-- Egérrel és billentyűzettel is vezérelhető játék.
-- Hangjelzések a lépésekhez és az idő lejártához.
-- Lépéselőzmények (move list) megjelenítése oldalt.
-- Tábla forgatásának lehetősége (pl. a fehér vagy fekete nézőpontból).
-- Állapotjelzők (sakk, matt, döntetlen, várakozás az ellenfélre).
-- Teljes képernyős mód.
-
-### Technikai / fejlesztői funkciók
-- Kliens–szerver architektúra.
-- REST API vagy WebSocket alapú kommunikáció.
-- Adatbázis a felhasználói adatok és meccsek tárolására (pl. SQLite, PostgreSQL, MongoDB).
-- Logolási és hibakezelési rendszer.
-- Automatikus mentés és adatvisszaállítás.
-- Verziókezelés (Git).
-- Tesztelhető, moduláris kódszerkezet (külön modulok: logika, UI, hálózat, adat).
-- Cross-platform működés (Windows, Linux, esetleg web).
-
-### További funkciók
-- Egyszemélyes mód (ember vs. gép, AI-bot).
-- Több nehézségi szintű AI.
-- Oktató mód (javasolt lépések, hibák magyarázata).
-- Hivatalos FEN/PGN formátum export/import.
-- Beépített sakkfeladványok, kihívások.
-- Érintéses vezérlés mobilon.
-- Többnyelvű felület (pl. magyar, angol).
-
-## 4. Rendszer követelmények
-
-A rendszer célja egy kétjátékos sakkalkalmazás megvalósítása, amely alapvetően hálózati kapcsolat (LAN vagy internet) segítségével biztosítja a valós idejű játékot. A rendszer kliens–szerver architektúrán alapul, ahol az egyes komponensek jól elkülönülten, meghatározott feladatokat látnak el.
-
-### 4.1 Kötelező funkcionális követelmények
-
-A rendszernek az alábbi alapvető funkciókat mindenképpen biztosítania kell:
-- Két játékos közötti sakkjátszma lebonyolítása, a hivatalos sakk szabályai alapján.
-- A játékosok felváltva tehetnek lépéseket, a lépések érvényességét a kliens oldali logika ellenőrzi.
-- A rendszer valós időben szinkronizálja a két kliens állapotát (mindkét fél ugyanazt a táblát látja).
-- A játék vége (sakkmatt, patt, idő lejárta) automatikusan felismerésre kerül.
-- A szerver egyidejűleg több játékot is képes kezelni (külön szobákban vagy sessionökben).
-- A játékosok elindíthatnak új meccset, illetve befejezett játék után visszatérhetnek a főmenübe.
-- A rendszer minden játékban egyedi azonosítót (Game ID) használ a játékállapot nyomon követéséhez.
-- A kliens értesítéseket kap az ellenfél lépéseiről és a játék állapotváltozásairól.
-
-### 4.2 Kliens oldali követelmények
-
-A kliens felelős a játékos felhasználói élményéért, a grafikus megjelenítésért és a játéklogika helyi működéséért.
-
-A kliensnek tudnia kell:
-- A sakk tábla és a figurák megjelenítése, lépések kezelése (egérkattintás vagy billentyűparancsok).
-- Lépések érvényesítése és elküldése a szervernek.
-- A szervertől érkező események (ellenfél lépése, állapotváltozás) feldolgozása és megjelenítése.
-- Hibák és megszakadt kapcsolat kezelése (újracsatlakozási lehetőség).
-- Saját IP vagy szerver cím megadása LAN esetén.
-- Alapvető menürendszer (csatlakozás, szerverindítás, új játék, kilépés).
-- A hálózati kommunikáció egységes formátumban történjen (pl. JSON alapú üzenetek).
-
-### 4.3 Szerver oldali követelmények
-
-A szerver feladata a kliensek közti kommunikáció kezelése, az állapotok szinkronizálása és a játék logikai integritásának megőrzése.
-
-A szervernek tudnia kell:
-- Kapcsolatok fogadása és kezelése több kliens esetén is.
-- Új játék (session) létrehozása és azonosító kiosztása.
-- Üzenetek továbbítása a kliensek között (pl. lépés, visszajelzés, játék vége).
-- A játékállapot naprakészen tartása és küldése mindkét félnek.
-- Kapcsolat megszakadása esetén az érintett játék szüneteltetése vagy lezárása.
-- Üzenetformátumok ellenőrzése és hibás adatok elutasítása.
-- Kliensazonosítás és egyszerű hitelesítés (pl. játékosnév alapján).
-- A kommunikáció biztonságos kezelése (üzenetduplikáció, szinkronizációs hibák elkerülése).
-
-### 4.4 A komponensek közti kommunikáció (szerződések)
-
-A rendszer komponensei egy meghatározott üzenetprotokollon keresztül kommunikálnak egymással.
-A kommunikáció kétirányú, valós idejű, és az alábbi szerződések szerint zajlik:
-
-A kliens minden lépést csak akkor hajt végre a felhasználói felületen, ha a szervertől visszaigazolást kapott az érvényességéről.
-A szerver az üzeneteket sorosítva, FIFO-elv szerint dolgozza fel, és broadcastolja a változásokat az adott játékhoz tartozó összes kliensnek.
-
-### 4.5 Nem funkcionális követelmények
-
-- Megbízhatóság: a rendszernek stabilan kell működnie hálózati késleltetés és csomagvesztés esetén is.
-- Teljesítmény: a szerver legalább 10 párhuzamos játékot képes kezelni érezhető lassulás nélkül.
-- Biztonság: a kliens csak a szerver által engedélyezett parancsokat hajthatja végre.
-- Bővíthetőség: a rendszer felépítése moduláris legyen, hogy később könnyen kiterjeszthető legyen (pl. online matchmaking).
-- Platformfüggetlenség: a kliens és a szerver futtatható legyen Windows, Linux és esetleg webes környezetben.
-- Karbantarthatóság: kódmodulok (logika, hálózat, UI) elkülönítése, jól dokumentált interfészekkel.
-
-### 4.6 Minimális technikai elvárások
-
-- Programozási nyelv: Rust, C#, Python vagy más, hálózati alkalmazásokra alkalmas nyelv.
-- Kommunikációs protokoll: TCP vagy WebSocket alapú kapcsolat.
-- Adatcsere formátum: JSON.
-- Grafikus felület: desktop GUI (pl. egérvezérlés, drag & drop lépés).
-- Követelmény kliensoldalon: legalább 4 GB RAM, modern operációs rendszer.
-- Követelmény szerveroldalon: 1 CPU mag, 512 MB RAM, állandó hálózati kapcsolat.
-
-## 5. Követelménylista
-
-### Szerver
-| Név | Verzió | Leírás |
-| --- | ------ | ------ |
-| **WebSocket**                  | 1.0    | A szerver és a kliens között folyamatos kétirányú kommunikációt biztosít. A kapcsolat létrejötte után a szerver valós időben képes fogadni és továbbítani az eseményeket (pl. lépés végrehajtása, állapotfrissítés). Hiba esetén a kapcsolat automatikusan újraépül.              |
-| **Kapcsolatok csoportosítása** | 1.0    | A szerver figyeli az elérhető, szabad klienseket, majd két szabad kapcsolatot automatikusan összerendel egy meccsbe. A csoportosítás után a játékosok azonos „room”-ba kerülnek, és a szerver biztosítja az egymás közötti adatkommunikációt.                                     |
-| **Kommunikáció az engine-nel** | 1.0    | A szerver a játékosoktól érkező lépéseket és játékinformációkat továbbítja az engine-nek feldolgozásra. Az engine válasza után a szerver visszaküldi az eredményt a klienseknek (pl. érvényes lépés, matt, patt). A kommunikáció aszinkron módon zajlik, válaszidő-ellenőrzéssel. |
-| **Kommunikáció a UI-al**       | 1.0    | A szerver WebSocket-en keresztül adatokat továbbít a felhasználói felület és az engine között. A UI által kért műveletek (pl. új meccs létrehozása, állapotlekérés) feldolgozását a szerver közvetíti.|
-### Engine
-| Név | Verzió | Leírás |
-| --- | ------ | ------ |
-| **Bitboard** | 1.0 | A játék táblaállapotát bitműveletekkel reprezentálja a hatékonyság érdekében. Minden bábu típus és szín külön bitmask-on kerül tárolásra, lehetővé téve a gyors lekérdezéseket és lépésellenőrzéseket. |
-| **Lépésgenerálás LUT** | 1.0 | Előre kiszámított lookup táblák segítségével gyorsítja a lépésgenerálást és szabályellenőrzést. Ez csökkenti a számítási időt, és optimalizálja az engine teljesítményét. |
-| **Lépésgenerálás** | 1.0 | A különböző bábutípusok (gyalog, bástya, futó, stb.) lépési logikáját valósítja meg. A függvények ellenőrzik a lépés érvényességét, figyelembe véve az aktuális állást, sakkhelyzetet és speciális szabályokat (pl. sáncolás, en passant). |
-| **Util függvények** | 1.0 | Segédfüggvények az engine belső működéséhez, például raycast műveletek, bitműveleti maszkok kezelése, valamint logikai ellenőrzések a lépések és ütések számításához. |
-
-### UI
-| Név | Verzió | Leírás |
-| --- | ------ | ------ |
-| **Belépés** | 1.0 | A felhasználó a kezdőképernyőn keresztül adhatja meg a nevét lokális játékhoz, vagy hitelesítheti magát online játékmód esetén. Hibás adatok esetén a rendszer figyelmeztetést küld. |
-| **Főmenü** | 1.0 | Az alkalmazás központi navigációs felülete, ahol a felhasználó meccset kereshet, új játékot indíthat lokálisan, vagy beállításokat módosíthat. A menü megjeleníti az aktuális státuszt (online/offline). |
-| **Játék** | 1.0 | A játékfelület megjeleníti a táblát, bábukat, lépéseket, és az aktuális játékállást. Támogatja mind az online, mind a lokális módot. A felület kezeli az interakciókat (lépéskattintás, visszavonás, végeredmény kijelzés). |
-| **Kommunikáció a szerverrel** | 1.0 | A kliens a szerveren keresztül kommunikál az engine-nel. A UI felel az üzenetek küldéséért (lépés, új játék, visszajelzés), valamint a szervertől kapott események vizuális megjelenítéséért. |
-
-
-### GitHub Actions (CI/CD)
-| Név | Leírás |
-| --- | ------ |
-| Folyamatos tesztelés | A projekt minden commit után automatikusan tesztelődik. A pipeline lefuttatja a teszteket, és értesítést küld hibás build esetén. |
-| Folyamatos integráció | Az új funkciók beolvadásakor a rendszer automatikusan integrálja a változtatásokat, új buildet hoz létre, és frissíti a fejlesztői környezetet. |
-| Tesztadatok | A tesztadatok legyenek elérhetőek egy táblázatban, dátummal ellátva. (Google Sheets) |

engine/.cargo/config.toml

@@ -0,0 +1,4 @@
+[target.x86_64-unknown-linux-gnu]
+linker = "x86_64-linux-gnu-gcc"
+[target.x86_64-pc-windows-gnu]
+linker = "x86_64-w64-mingw32-gcc"

server/.cargo/config.toml

@@ -0,0 +1,4 @@
+[target.x86_64-unknown-linux-gnu]
+linker = "x86_64-linux-gnu-gcc"
+[target.x86_64-pc-windows-gnu]
+linker = "x86_64-w64-mingw32-gcc"

ui/.cargo/config.toml

@@ -0,0 +1,4 @@
+[target.x86_64-unknown-linux-gnu]
+linker = "x86_64-linux-gnu-gcc"
+[target.x86_64-pc-windows-gnu]
+linker = "x86_64-w64-mingw32-gcc"