Se sei un fan di Star Trek, probabilmente saprai che il Capitano Kirk e il signor Spock giocano spesso a una variante degli scacchi chiamata Scacchi Tridimensionali, o Scacchi 3D, un gioco simile agli scacchi standard ma con notevoli differenze. In questo articolo creeremo un modello di dati per un'applicazione di scacchi 3D che consente ai giocatori di competere l'uno contro l'altro. Teletrasmettici, Scotty!
Il concetto di scacchi 3D
Sebbene gli scacchi stessi siano già un gioco complesso, la combinazione di scacchiere e più set di pezzi può aumentare significativamente la complessità del gioco.
Negli scacchi 3D, le tavole sono impilate in strati paralleli e regole di movimento speciali si applicano a determinati pezzi, a seconda di dove si trovano. Ad esempio, i pedoni sul tabellone centrale possono imitare il comportamento di una regina. I pezzi possono anche spostarsi da una tavola all'altra, con determinate restrizioni applicate, e le tavole stesse possono anche muoversi e ruotare. Non c'è da stupirsi che Kirk e Spock si siano divertiti così tanto con gli scacchi 3D:richiedono molta finezza tattica!
Gli scacchi tridimensionali si discostano anche dagli scacchi standard in termini di proprietà delle sue scacchiere. Negli scacchi 3D, ci sono sette tavole distinte con proprietà diverse. Tre di queste schede sono 4x4, mentre le restanti quattro schede sono 2x2. Puoi spostare queste schede più piccole in giro.
Si spera che il nostro modello di dati copra tutto ciò di cui abbiamo bisogno per giocare a scacchi 3D in un'app web. Lavoreremo partendo dal presupposto che tutto può muoversi e che le tavole possono imporre restrizioni di movimento diverse sugli stessi pezzi. Questo dovrebbe essere sufficiente per coprire tutte le possibili varianti di scacchi 3D. Passiamo subito al modello di dati!
Il modello dei dati
Il nostro modello di dati è composto da tre sezioni:
- Giocatori e giochi
- Impostazione del gioco
- Partite
Ora discuteremo ciascuna di queste aree in modo più dettagliato.
Sezione 1:Giocatori e giochi
Tutto nel nostro modello è direttamente o indirettamente correlato ai giochi. Naturalmente, un gioco non può procedere senza giocatori!
L'elenco di tutti i giocatori è memorizzato nel player tavolo. Nel nostro modello, i giocatori sono tutti gli utenti registrati della nostra applicazione. Per ogni giocatore, memorizzeremo le seguenti informazioni:
first_nameelast_name– rispettivamente il nome e il cognome del giocatore.user_name– il nome utente selezionato dal giocatore, che deve essere univoco.password– un valore hash della password del giocatore.nickname– il nome utente del giocatore, che, come il suo nome utente, deve essere univoco.email– l'indirizzo email del giocatore, che fornirà durante il processo di registrazione. Il codice necessario per completare la procedura di registrazione verrà inviato a questa email.confirmation_code– il codice che è stato inviato all'indirizzo email del giocatore per completare il processo di registrazione.confirmation_date– il timestamp di quando il giocatore ha confermato il proprio indirizzo e-mail. Questo attributo memorizzerà NULL fino a quando il giocatore non confermerà la propria email.current_rating– la valutazione attuale del giocatore, calcolata in base alla sua prestazione contro altri giocatori. I giocatori inizieranno con un valore iniziale e le loro valutazioni aumenteranno o diminuiranno in base ai gradi dei loro avversari e ai loro risultati di gioco.
Il result table è un dizionario che memorizza i valori di tutti i possibili risultati di gioco unici, ovvero "in_progress", "draw", "win" e "losing".
Forse la tabella più importante nell'intero modello di dati è game , che memorizza le informazioni su ogni partita di scacchi 3D. In questo modello, assumiamo che due giocatori umani competano l'uno contro l'altro e che possano scegliere di salvare il loro stato di gioco attuale e riprenderlo in un secondo momento (come se volessero fare una mossa al giorno, in in tal caso i giocatori accederanno all'app, vedranno la mossa più recente dell'avversario, penseranno alla propria mossa, eseguiranno la propria mossa e quindi si disconnetteranno). Memorizzeremo i seguenti valori in questa tabella:
player_id_1eplayer_id_2– riferimenti alplayertabella che denota entrambi i partecipanti a un gioco. Come accennato, presumiamo che una partita si svolgerà rigorosamente tra due giocatori umani.number_of_moves– indica il numero di mosse che sono state eseguite finora nella partita in corso. All'inizio del gioco, questo numero viene impostato su 0 e aumenta di 1 ogni volta che un giocatore effettua una mossa.player_id_next– un riferimento al giocatore che deve fare la mossa successiva nella partita in corso.result_id_1eresult_id_2– riferimenti alresulttavolo che memorizza l'esito del gioco per ogni giocatore.player_1_points_woneplayer_2_points_won– indicare il numero di punti assegnati ai giocatori, in base al risultato della partita.
Discuteremo come i giocatori possono tenere traccia di tutte le mosse nella sezione Partite verso la fine di questo articolo. Per ora, passeremo alla configurazione del gioco.
Sezione 2:Configurazione del gioco
La sezione Configurazione del gioco contiene una descrizione di tutte le scacchiere e i pezzi degli scacchi 3D, nonché un elenco di tutte le mosse legali che i giocatori possono fare.
Come accennato in precedenza, gli scacchi 3D spesso coinvolgono più di una tavola. Queste schede possono aderire alle dimensioni standard 8x8 con posizioni fisse, ma non è necessario che sia così. L'elenco di tutte le bacheche è memorizzato nella board tavolo. Per ogni scheda, memorizzeremo un board_name univoco , il starting_position della scheda in relazione alle nostre coordinate 3D scelte e tutti i details aggiuntivi .
Successivamente, definiremo tutti i possibili tipi di pezzi che potrebbero apparire sulle nostre scacchiere. Per farlo, utilizzeremo il piece_type dizionario. Oltre alla chiave primaria, questo dizionario contiene un solo valore univoco, type_name. Per un set di scacchi standard, ci aspettiamo di vedere i valori "pedone", "torre", "cavaliere", "vescovo", "re" e "regina" in questo dizionario.
L'elenco di tutti i singoli pezzi utilizzati in una partita di scacchi 3D è memorizzato nel piece tavolo. Per ogni pezzo, memorizzeremo le seguenti informazioni:
piece_name– un nome univoco che descrive il tipo di pezzo e la sua posizione di partenza.starting_position– un valore che denota la tavola e il quadrato precisi su cui il pezzo è inizialmente posizionato.board_id– un riferimento alla tavola su cui è originariamente posizionato il pezzo.piece_type_id– un riferimento che denota il tipo del pezzo.
Infine, utilizzeremo il move_type tabella per memorizzare l'elenco di tutte le mosse possibili che i pezzi possono fare sulle nostre tavole (così come tutte le mosse che le tavole stesse possono fare). Ricordiamo dall'introduzione che alcune tavole applicano regole di movimento speciali ai loro pezzi. Per ogni mossa, definiremo quanto segue:
type_name– un nome che useremo per denotare la mossa che è stata fatta, che non sarà un valore univoco (ad esempio, possiamo avere "pedone avanzato di 1 casella in avanti" tutte le volte che è necessario).piece_type_id– un riferimento al tipo di pezzo che è stato spostato. Se questo valore è NULL, allora il movimento riguarda un'intera scacchiera e non un pezzo particolare.board_id– indica la scacchiera su cui avverrà questa mossa (se si sta muovendo un pezzo degli scacchi). Se il tabellone si sta muovendo, questo valore rappresenterà naturalmente il tabellone che si sta muovendo. Insieme a due attributi precedenti, questo costituisce la chiave univoca per questa tabella.is_piece_moveeis_board_move– indica se una mossa riguarda un pezzo degli scacchi o una scacchiera. Solo uno di questi flag può essere impostato su true per una determinata mossa.
Poiché ci sono troppe mosse e rotazioni da considerare, non memorizzeremo tutte queste possibilità nel nostro database. Invece, memorizzeremo semplicemente i nomi delle mosse e implementeremo la logica effettiva nell'applicazione stessa. Ad esempio, definiremo che i pedoni possono avanzare di una singola casella, avanzare di due caselle dalla loro posizione iniziale, rivendicare i pezzi in diagonale, spostarsi da una scacchiera all'altra e muoversi come una regina sulla scacchiera centrale. Quindi, avremo cinque possibili tipi di mosse definiti per i pedoni, a seconda del tabellone su cui sono posizionati e della loro posizione attuale.
Sezione 3:Partite
Abbiamo quasi finito! L'ultima sezione del nostro modello si chiama Matches e contiene tre nuove tabelle che useremo per tenere traccia della cronologia dei movimenti in una partita di scacchi 3D. Le tabelle rimanenti sono solo copie di altre tabelle del nostro modello di dati, il che aiuta a evitare relazioni sovrapposte. Conserveremo anche le posizioni correnti di tutte le schede e dei loro pezzi in quest'area. Entriamo subito.
La move table è in realtà la tabella più complessa di questa sezione. Contiene l'elenco di tutte le mosse eseguite durante una partita. Questa tabella mostrerà ai giocatori l'elenco di tutte le mosse, che possono essere utilizzate in seguito per rivedere o analizzare la partita. Per ogni mossa, memorizzeremo quanto segue:
game_id– un riferimento algamein cui è stato effettuato il trasloco.player_id– un riferimento alplayerchi ha fatto la mossa.move_in_the_game– il numero ordinale della mossa. Questo numero, combinato con la posizione iniziale di un pezzo e tutte le altre mosse, può essere utilizzato per ricreare l'intero gioco. L'idea è quella di consentire ai giocatori di simulare il gioco una volta completato in modo da poter analizzare i risultati della partita.piece_id– un riferimento alpieceche è stato spostato. Ciò semplifica il monitoraggio del movimento di un pezzo dall'inizio alla fine (principalmente a scopo di analisi).piece_type_id– un riferimento al tipo di pezzo che è stato spostato. Sebbene il riferimento di un pezzo rimanga sempre costante, il suo tipo può cambiare durante il gioco (come se un pedone fosse promosso). Se stiamo spostando il tabellone, questo attributo conterrà un valore di NULL.board_id– un riferimento alboardsu cui è avvenuto il trasloco.move_notation– una notazione concordata che useremo per rappresentare le mosse.
Le restanti due tabelle ci consentono di memorizzare un'istantanea dello stato attuale del gioco nel database, utile se i giocatori desiderano riprendere il gioco in un secondo momento.
Il current_board_position viene utilizzato per memorizzare la posizione di tutte le schede nel nostro sistema di coordinate 3D. Ciò è necessario per le partite di scacchi 3D in cui almeno una tavola può cambiare la sua posizione. Per ogni record in questa tabella, memorizzeremo un riferimento al gioco e al tabellone correlati, nonché la notazione della posizione di un tabellone. Due coppie di attributi specifici, game_id + board_id e game_id + position_notation , formano le chiavi univoche per questa tabella.
La nostra ultima tabella è current_piece_position , che memorizza i riferimenti al gioco correlato, un pezzo particolare, il tipo del pezzo e una notazione di posizione per il pezzo. Avremo ancora due coppie di attributi che fungono da chiavi univoche per questa tabella:il game_id e piece_id coppia e il game_id e position_notation coppia.
Conclusione
Questo è tutto per questo modello di dati:siamo orgogliosi di annunciare che il Capitano Kirk e il signor Spock ora possono giocare a scacchi 3D su un computer!
Hai qualche suggerimento per migliorare il nostro modello di dati? Sentiti libero di lasciare i tuoi commenti in basso. Vivi a lungo e prospera??
