Als je een Star Trek-fan bent, weet je waarschijnlijk dat Captain Kirk en Mr. Spock vaak een variant van schaken spelen genaamd Tri-Dimensional Chess, of 3D-schaken, een spel dat lijkt op standaard schaken, maar met opmerkelijke verschillen. In dit artikel bouwen we een datamodel voor een 3D-schaaktoepassing waarmee spelers tegen elkaar kunnen strijden. Straal ons omhoog, Scotty!
Het concept van 3D schaken
Hoewel schaken zelf al een complex spel is, kan het combineren van borden en meerdere sets stukken de complexiteit van het spel aanzienlijk vergroten.
In 3D-schaken worden borden in parallelle lagen gestapeld en zijn er speciale bewegingsregels van toepassing op bepaalde stukken, afhankelijk van waar ze zich bevinden. Pionnen op het middelste bord kunnen bijvoorbeeld het gedrag van een koningin nabootsen. Stukken kunnen ook van het ene bord naar het andere worden verplaatst, met bepaalde beperkingen, en de borden zelf kunnen zelfs bewegen en roteren. Geen wonder dat Kirk en Spock zo genoten van 3D-schaken - het vereist nogal wat tactische finesse!
Driedimensionaal schaken wijkt ook af van standaardschaak wat betreft de eigenschappen van zijn borden. In 3D-schaken zijn er zeven verschillende borden met verschillende eigenschappen. Drie van deze borden zijn 4x4, terwijl de overige vier borden 2x2 zijn. Je kunt deze kleinere borden verplaatsen.
Ons datamodel dekt hopelijk alles wat we nodig hebben om een spelletje 3D-schaak in een webapp te spelen. We gaan ervan uit dat alles kan bewegen en dat borden verschillende bewegingsbeperkingen kunnen opleggen aan dezelfde stukken. Dit zou voldoende moeten zijn om alle mogelijke 3D-schaakvarianten te dekken. Laten we meteen naar het datamodel springen!
Het gegevensmodel
Ons datamodel bestaat uit drie secties:
- Spelers en spellen
- Spelconfiguratie
- Overeenkomsten
We zullen nu elk van deze gebieden in meer detail bespreken.
Sectie 1:Spelers en spellen
Alles in ons model is direct of indirect gerelateerd aan games. Een spel kan natuurlijk niet doorgaan zonder spelers!
De lijst met alle spelers wordt opgeslagen in de player tafel. In ons model zijn spelers alle geregistreerde gebruikers van onze applicatie. Voor elke speler slaan we de volgende informatie op:
first_nameenlast_name– respectievelijk de voor- en achternaam van de speler.user_name– de gebruikersnaam die de speler heeft geselecteerd, die uniek moet zijn.password– een hash-waarde van het wachtwoord van de speler.nickname– de schermnaam van de speler, die net als hun gebruikersnaam uniek moet zijn.email– het e-mailadres van de speler, dat hij zal verstrekken tijdens het registratieproces. De code die nodig is om het registratieproces te voltooien, wordt naar deze e-mail verzonden.confirmation_code– de code die naar het e-mailadres van de speler is gestuurd om het registratieproces te voltooien.confirmation_date– het tijdstempel van wanneer de speler zijn e-mailadres heeft bevestigd. Dit kenmerk slaat NULL op totdat de speler zijn e-mail bevestigt.current_rating– de huidige rating van de speler, berekend op basis van zijn prestaties ten opzichte van andere spelers. Spelers beginnen met een bepaalde initiële waarde en hun beoordelingen zullen toenemen of afnemen afhankelijk van de rangen van hun tegenstanders en hun spelresultaten.
Het result table is een woordenboek dat de waarden van alle mogelijke unieke spelresultaten opslaat, namelijk "in_progress", "draw", "win" en "losse".
Misschien wel de belangrijkste tabel in het hele datamodel is game , waarin informatie over elk 3D-schaakspel wordt opgeslagen. In dit model gaan we ervan uit dat twee menselijke spelers tegen elkaar zullen strijden en dat ze ervoor kunnen kiezen om hun huidige spelstatus op te slaan en op een later tijdstip te hervatten (bijvoorbeeld als ze één zet per dag willen doen, in in dat geval zullen de spelers inloggen op de app, de meest recente zet van hun tegenstander zien, hun eigen zet bedenken, hun zet uitvoeren en vervolgens uitloggen). We slaan de volgende waarden op in deze tabel:
player_id_1enplayer_id_2– verwijzingen naar deplayertabel die beide deelnemers aan een spel aangeeft. Zoals vermeld, gaan we ervan uit dat een spel strikt tussen twee menselijke spelers zal plaatsvinden.number_of_moves– geeft het aantal zetten aan dat tot nu toe in het huidige spel is uitgevoerd. Wanneer het spel begint, wordt dit getal op 0 gezet en wordt het elke keer dat een speler een zet doet met 1 verhoogd.player_id_next– een verwijzing naar de speler die de volgende zet moet doen in het huidige spel.result_id_1enresult_id_2– verwijzingen naar hetresulttafel waarin de uitkomst van het spel voor elke speler wordt opgeslagen.player_1_points_wonenplayer_2_points_won– geef het aantal punten aan dat de spelers hebben gekregen, in overeenstemming met het resultaat van het spel.
We bespreken hoe spelers alle zetten kunnen bijhouden in het gedeelte Wedstrijden aan het einde van dit artikel. Voor nu gaan we verder met het instellen van het spel.
Sectie 2:Spelconfiguratie
De sectie Spelconfiguratie bevat een beschrijving van alle borden en stukken in 3D-schaken, evenals een lijst van alle legale zetten die spelers kunnen doen.
Zoals we eerder vermeldden, omvat 3D-schaken vaak meer dan één bord. Deze planken kunnen met vaste posities de standaard 8x8 maatvoering aan, maar dat hoeft niet zo te zijn. De lijst met alle borden wordt opgeslagen in het board tafel. Voor elk bord slaan we een unieke board_name op , de starting_position van het bord in relatie tot onze gekozen 3D-coördinaten, en alle aanvullende details .
Vervolgens definiëren we alle mogelijke soorten stukken die op onze schaakborden kunnen verschijnen. Om dit te doen, gebruiken we de piece_type woordenboek. Naast de primaire sleutel bevat dit woordenboek slechts één unieke waarde, type_name. Voor een standaard schaakspel verwachten we de waarden "pion", "toren", "ridder", "bisschop", "koning" en "koningin" in dit woordenboek te zien.
De lijst met alle afzonderlijke stukken die in een 3D-schaakspel worden gebruikt, wordt opgeslagen in het piece tafel. Voor elk stuk slaan we de volgende informatie op:
piece_name– een unieke naam die het type stuk en zijn startpositie beschrijft.starting_position– een waarde die het precieze bord en veld aangeeft waarop het stuk aanvankelijk is geplaatst.board_id– een verwijzing naar het bord waarop het stuk oorspronkelijk is geplaatst.piece_type_id– een referentie die het type van het stuk aangeeft.
Ten slotte gebruiken we de move_type tabel om de lijst op te slaan van alle mogelijke zetten die de stukken op onze borden kunnen maken (evenals alle zetten die de borden zelf kunnen doen). Bedenk uit de inleiding dat bepaalde borden speciale bewegingsregels toepassen op hun stukken. Voor elke zet definiëren we het volgende:
type_name– een naam die we zullen gebruiken om de uitgevoerde zet aan te duiden, wat geen unieke waarde zal zijn (we kunnen bijvoorbeeld zo vaak als nodig "pion 1 veld vooruit" laten zetten).piece_type_id– een verwijzing naar het type stuk dat werd verplaatst. Als deze waarde NULL is, heeft de beweging betrekking op een heel bord en niet op een bepaald stuk.board_id– geeft het bord aan waarop deze zet zal plaatsvinden (als een schaakstuk in beweging is). Als het bord zelf in beweging is, vertegenwoordigt deze waarde natuurlijk het bord dat wordt verplaatst. Samen met twee eerdere attributen vormt dit de unieke sleutel voor deze tabel.is_piece_moveenis_board_move– geef aan of een zet een schaakstuk of een bord betreft. Slechts één van deze vlaggen kan worden ingesteld op waar voor een bepaalde zet.
Aangezien er te veel stukzetten en -rotaties zijn om rekening mee te houden, zullen we niet al deze mogelijkheden in onze database opslaan. In plaats daarvan slaan we alleen de verplaatsingsnamen op en implementeren we de eigenlijke logica in de applicatie zelf. We zullen bijvoorbeeld definiëren dat pionnen ofwel een enkel veld vooruit kunnen gaan, twee velden vooruit kunnen gaan vanaf hun startpositie, diagonaal stukken kunnen claimen, van het ene bord naar het andere kunnen bewegen en als een koningin op het centrale bord kunnen bewegen. We hebben dus vijf mogelijke zettypes gedefinieerd voor pionnen, afhankelijk van het bord waarop ze staan en hun huidige positie.
Sectie 3:Wedstrijden
We zijn bijna klaar! Het laatste deel van ons model heet Matches en bevat drie nieuwe tabellen die we zullen gebruiken om de bewegingsgeschiedenis bij te houden in een 3D-schaakspel. De overige tabellen zijn slechts kopieën van andere tabellen uit ons gegevensmodel, waardoor overlappende relaties worden voorkomen. We zullen ook de huidige posities van alle borden en hun stukken in dit gebied opslaan. Laten we er meteen in duiken.
De move tabel is eigenlijk de meest complexe tabel in deze sectie. Het bevat de lijst met alle zetten die tijdens een partij zijn uitgevoerd. Deze tabel toont de lijst met alle zetten voor spelers, die later kan worden gebruikt om de wedstrijd te bekijken of te analyseren. Voor elke zet slaan we het volgende op:
game_id– een verwijzing naar hetgamewaarin de zet werd gedaan.player_id– een verwijzing naar deplayerwie heeft de stap gezet.move_in_the_game– het volgnummer van de zet. Dit nummer, gecombineerd met de startpositie van een stuk en alle andere zetten, kan worden gebruikt om het hele spel na te bootsen. Het idee is om spelers de game te laten simuleren zodra deze is uitgespeeld, zodat ze de resultaten van de wedstrijd kunnen analyseren.piece_id– een verwijzing naar hetpiecedat was verplaatst. Dit maakt het gemakkelijk om de beweging van een stuk van begin tot eind te volgen (voornamelijk voor analysedoeleinden).piece_type_id– een verwijzing naar het type stuk dat werd verplaatst. Hoewel de referentie van een stuk altijd constant blijft, kan het type tijdens het spel veranderen (bijvoorbeeld als een pion wordt gepromoveerd). Als we het bord verplaatsen, bevat dit kenmerk de waarde NULL.board_id– een verwijzing naar hetboardwaarop de verhuizing plaatsvond.move_notation– een afgesproken notatie die we zullen gebruiken om zetten weer te geven.
Met de overige twee tabellen kunnen we een momentopname van de huidige spelstatus in de database opslaan, wat handig is als de spelers het spel op een later tijdstip willen hervatten.
De current_board_position wordt gebruikt om de positie van alle borden in ons 3D-coördinatensysteem op te slaan. Dit is nodig voor 3D-schaakspellen waarbij ten minste één bord van positie kan veranderen. Voor elk record in deze tabel slaan we een verwijzing op naar het gerelateerde spel en bord, evenals de notatie van de positie van een bord. Twee specifieke attribuutparen, game_id + board_id en game_id + position_notation , vormen de unieke sleutels voor deze tabel.
Onze laatste tafel is current_piece_position , waarin verwijzingen naar het gerelateerde spel, een bepaald stuk, het type van het stuk en een positienotatie voor het stuk zijn opgeslagen. We hebben weer twee paar attributen die als unieke sleutels voor deze tafel dienen:de game_id en piece_id paar en de game_id en position_notation paar.
Conclusie
Dat was het zowat voor dit datamodel - we zijn trots om aan te kondigen dat Captain Kirk en Mr. Spock nu 3D-schaken op een computer kunnen spelen!
Heeft u suggesties om ons datamodel te verbeteren? Voel je vrij om je opmerkingen hieronder achter te laten. Leef lang en voorspoedig ??