Model danych szachowych Star Trek 3D

result table to słownik, który przechowuje wartości wszystkich możliwych unikalnych wyników gry, a mianowicie „w toku”, „remis”, „wygrana” i „przegrana”.

Być może najważniejszą tabelą w całym modelu danych jest game , który przechowuje informacje o każdej partii szachów 3D. W tym modelu zakładamy, że dwóch ludzkich graczy będzie rywalizować ze sobą i że mogą zdecydować się na zapisanie swojego aktualnego stanu gry i wznowienie w późniejszym czasie (np. jeśli chcieliby wykonać jeden ruch dziennie, w w takim przypadku gracze zalogują się do aplikacji, zobaczą ostatni ruch przeciwnika, wymyślą własny ruch, wykonają ruch, a następnie wylogują się). W tej tabeli będziemy przechowywać następujące wartości:

• player_id_1 i player_id_2 – odniesienia do player tabela oznaczająca obu uczestników gry. Jak wspomniano, zakładamy, że gra będzie ściśle odbywać się między dwoma ludzkimi graczami.
• number_of_moves – oznacza liczbę ruchów, które zostały wykonane do tej pory w bieżącej grze. Na początku gry liczba ta jest ustawiona na 0 i wzrasta o 1 za każdym razem, gdy gracz wykona ruch.
• player_id_next – odniesienie do gracza, który musi wykonać następny ruch w bieżącej grze.
• result_id_1 i result_id_2 – odniesienia do result tabela, która przechowuje wynik gry dla każdego gracza.
• player_1_points_won i player_2_points_won – oznaczają liczbę punktów, które otrzymali gracze, zgodnie z wynikiem gry.

Omówimy, jak gracze mogą śledzić wszystkie ruchy w sekcji Mecze pod koniec tego artykułu. Na razie przejdziemy do konfiguracji gry.

Sekcja 2:Przygotowanie gry

Sekcja Przygotowanie gry zawiera opis wszystkich plansz i pionów w szachach 3D, a także listę wszystkich dozwolonych ruchów, które gracze mogą wykonać.

Jak wspomnieliśmy wcześniej, szachy 3D często wymagają więcej niż jednej planszy. Tablice te mogą być zgodne ze standardowymi wymiarami 8x8 ze stałymi pozycjami, ale nie musi tak być. Lista wszystkich tablic jest przechowywana na board stół. Dla każdej tablicy przechowujemy unikalną board_name , starting_position planszy w stosunku do wybranych przez nas współrzędnych 3D oraz wszystkie dodatkowe details .

Następnie zdefiniujemy wszystkie możliwe typy bierek, które mogą pojawić się na naszych szachownicach. W tym celu użyjemy piece_type słownik. Oprócz klucza podstawowego ten słownik zawiera tylko jedną unikalną wartość, typ_nazwa. W przypadku standardowych szachów spodziewamy się, że w tym słowniku pojawią się wartości „pionek”, „wieża”, „rycerz”, „biskup”, „król” i „królowa”.

Lista wszystkich pojedynczych bierek używanych w grze w szachy 3D jest przechowywana w piece stół. Dla każdego elementu przechowujemy następujące informacje:

• piece_name – unikalna nazwa opisująca typ figury i jej pozycję startową.
• starting_position – wartość określająca dokładną planszę i pole, na którym znajduje się pionek.
• board_id – odniesienie do planszy, na której pierwotnie znajduje się pionek.
• piece_type_id – odnośnik określający typ utworu.

Na koniec użyjemy move_type tabela do przechowywania listy wszystkich możliwych ruchów, które pionki mogą wykonać na naszych planszach (a także wszelkich ruchów, które mogą wykonać same plansze). Przypomnij sobie ze wstępu, że niektóre plansze stosują specjalne zasady ruchu do swoich pionów. Dla każdego ruchu zdefiniujemy następujące elementy:

• type_name – nazwa, której będziemy używać do oznaczenia wykonanego ruchu, która nie będzie unikalną wartością (np. możemy mieć „pionek przesunięty o 1 pole do przodu” tyle razy, ile potrzeba).
• piece_type_id – nawiązanie do rodzaju utworu, który został przeniesiony. Jeśli ta wartość jest NULL, to ruch dotyczy całej planszy, a nie konkretnej figury.
• board_id – oznacza planszę, na której nastąpi ten ruch (jeśli pionek się porusza). Jeśli sama plansza się porusza, ta wartość będzie naturalnie reprezentować planszę, która jest przesuwana. Wraz z dwoma poprzednimi atrybutami tworzy to unikalny klucz dla tej tabeli.
• is_piece_move i is_board_move – zaznacz, czy ruch dotyczy figury szachowej, czy szachownicy. Tylko jedna z tych flag może być ustawiona jako prawda dla konkretnego ruchu.

Ponieważ jest zbyt wiele ruchów i rotacji bierek do rozważenia, nie będziemy przechowywać wszystkich takich możliwości w naszej bazie danych. Zamiast tego po prostu zapiszemy nazwy ruchów i zaimplementujemy rzeczywistą logikę w samej aplikacji. Na przykład zdefiniujemy, że pionki mogą albo przesunąć się do przodu o jedno pole, przesunąć się o dwa pola ze swojej pozycji początkowej, przejąć pionki po przekątnej, przesunąć się z jednej planszy na drugą i poruszać się jako królowa na planszy środkowej. Tak więc będziemy mieć pięć możliwych typów ruchów zdefiniowanych dla pionków, w zależności od planszy, na której są umieszczone i ich aktualnej pozycji.

Sekcja 3:Mecze

Już prawie skończyliśmy! Ostatnia sekcja naszego modelu nosi nazwę Mecze i zawiera trzy nowe tabele, których użyjemy do śledzenia historii ruchów w grze w szachy 3D. Pozostałe tabele to tylko kopie innych tabel z naszego modelu danych, co pomaga uniknąć nakładania się relacji. Będziemy również przechowywać aktualne pozycje wszystkich plansz i ich elementów w tym obszarze. Zanurzmy się od razu.

move tabela jest w rzeczywistości najbardziej złożoną tabelą w tej sekcji. Zawiera listę wszystkich ruchów wykonanych podczas gry. Ta tabela wyświetli listę wszystkich ruchów dla graczy, która może być później wykorzystana do przeglądu lub analizy meczu. Dla każdego ruchu zapiszemy:

• game_id – odniesienie do game w którym dokonano przeprowadzki.
• player_id – odniesienie do player kto wykonał ruch.
• move_in_the_game – liczba porządkowa ruchu. Ta liczba, w połączeniu z pozycją początkową pionka i wszystkimi innymi ruchami, może zostać wykorzystana do odtworzenia całej gry. Chodzi o to, aby gracze mogli symulować grę po jej zakończeniu, aby mogli analizować wyniki meczu.
• piece_id – odniesienie do piece który został przeniesiony. Ułatwia to śledzenie ruchu elementu od początku do końca (głównie w celach analitycznych).
• piece_type_id – nawiązanie do rodzaju utworu, który został przeniesiony. Chociaż odniesienie bierek zawsze pozostanie stałe, ich typ może się zmieniać w trakcie gry (np. jeśli pionek jest promowany). Jeśli przenosimy tablicę, ten atrybut będzie zawierał wartość NULL.
• board_id – odniesienie do board na którym nastąpiła przeprowadzka.
• move_notation – uzgodniony zapis, którego użyjemy do reprezentowania ruchów.

Pozostałe dwie tabele pozwalają nam przechowywać w bazie danych migawkę aktualnego stanu gry, co jest pomocne, jeśli gracze chcą wznowić grę w późniejszym czasie.

current_board_position służy do przechowywania pozycji wszystkich płyt w naszym układzie współrzędnych 3D. Jest to niezbędne w grach w szachy 3D, w których przynajmniej jedna plansza może zmienić swoją pozycję. Dla każdego rekordu w tej tabeli przechowamy odniesienie do powiązanej gry i planszy, a także zapis pozycji planszy. Dwie konkretne pary atrybutów, game_id + board_id i game_id + position_notation , utwórz unikalne klucze dla tej tabeli.

Nasza ostatnia tabela to current_piece_position , który przechowuje odniesienia do powiązanej gry, konkretnego utworu, typu utworu i notacji pozycji dla utworu. Ponownie będziemy mieć dwie pary atrybutów, które służą jako unikalne klucze dla tej tabeli:game_id i piece_id para i game_id i position_notation parować.

Wniosek

To wszystko w przypadku tego modelu danych — z dumą ogłaszamy, że kapitan Kirk i pan Spock mogą teraz grać w szachy 3D na komputerze!

Czy masz jakieś sugestie dotyczące ulepszenia naszego modelu danych? Możesz zostawić swoje komentarze poniżej. Żyj długo i szczęśliwie??