Hvis du er Star Trek-fan, ved du sandsynligvis, at kaptajn Kirk og Mr. Spock ofte spiller en variant af skak kaldet Tri-Dimensional Chess, eller 3D skak, et spil, der ligner standard skak, men med bemærkelsesværdige forskelle. I denne artikel bygger vi en datamodel til en 3D skakapplikation, der giver spillere mulighed for at konkurrere mod hinanden. Send os op, Scotty!
Konceptet med 3D skak
Selvom skak i sig selv allerede er et komplekst spil, kan en kombination af brædder og flere sæt brikker øge spillets kompleksitet betydeligt.
I 3D skak er brædder stablet i parallelle lag, og særlige bevægelsesregler gælder for visse brikker, afhængigt af hvor de er placeret. For eksempel kan bønder på det midterste bræt efterligne en dronnings opførsel. Brikker kan også flyttes fra et bræt til et andet, med visse begrænsninger, og brætterne selv kan endda flytte rundt og rotere. Ikke underligt, at Kirk og Spock nød 3D-skak så meget – det kræver en hel del taktisk finesse!
Tredimensionelt skak afviger også fra standardskak med hensyn til egenskaberne af dets brædder. I 3D skak er der syv forskellige brædder med forskellige egenskaber. Tre af disse brædder er 4x4, mens de resterende fire brædder er 2x2. Du kan flytte rundt på disse mindre brædder.
Vores datamodel vil forhåbentlig dække alt, hvad vi behøver for at spille et spil 3D skak i en webapp. Vi vil arbejde under den antagelse, at alt kan bevæge sig rundt, og at brædder kan pålægge de samme stykker forskellige bevægelsesrestriktioner. Dette burde være tilstrækkeligt til at dække alle mulige 3D-skakvarianter. Lad os springe direkte ind i datamodellen!
Datamodellen
Vores datamodel består af tre sektioner:
- Spillere og spil
- Spilopsætning
- Match
Vi vil nu diskutere hvert af disse områder mere detaljeret.
Afsnit 1:Spillere og spil
Alt i vores model er enten direkte eller indirekte relateret til spil. Selvfølgelig kan et spil ikke fortsætte uden spillere!
Listen over alle spillere er gemt i player bord. I vores model er spillere alle de registrerede brugere af vores applikation. For hver spiller gemmer vi følgende oplysninger:
first_nameoglast_name– henholdsvis for- og efternavn på spilleren.user_name– brugernavnet, den valgte spiller, som skal være unikt.password– en hashværdi af spillerens adgangskode.nickname– spillerens skærmnavn, som ligesom deres brugernavn skal være unikt.email– spillerens e-mailadresse, som de oplyser under registreringsprocessen. Den nødvendige kode for at fuldføre registreringsprocessen vil blive sendt til denne e-mail.confirmation_code– koden, der blev sendt til spillerens e-mailadresse for at fuldføre deres registreringsproces.confirmation_date– tidsstemplet for, hvornår spilleren bekræftede sin e-mailadresse. Denne egenskab gemmer NULL, indtil spilleren bekræfter sin e-mail.current_rating– spillerens aktuelle rating, beregnet ud fra deres præstation mod andre spillere. Spillere starter med en vis begyndelsesværdi, og deres vurderinger vil stige eller falde i overensstemmelse med deres modstanderes rækker og deres spilresultater.
result tabel er en ordbog, der gemmer værdierne af alle mulige unikke spilresultater, nemlig "i_gang", "uafgjort", "vind" og "tab".
Den måske vigtigste tabel i hele datamodellen er game , som gemmer oplysninger om hvert spil 3D skak. I denne model antager vi, at to menneskelige spillere vil konkurrere mod hinanden, og at de kan vælge at gemme deres nuværende spiltilstand og genoptage på et senere tidspunkt (såsom hvis de gerne vil lave et træk om dagen, i hvilket tilfælde spillerne vil logge ind på appen, se deres modstanders seneste træk, tænke på deres eget træk, udføre deres træk og derefter logge ud). Vi gemmer følgende værdier i denne tabel:
player_id_1ogplayer_id_2– referencer tilplayertabel, der angiver begge deltagere i et spil. Som nævnt antager vi, at et spil udelukkende foregår mellem to menneskelige spillere.number_of_moves– angiver antallet af træk, der er blevet udført indtil videre i det aktuelle spil. Når spillet starter, er dette tal sat til 0 og øges med 1, hver gang en spiller foretager et træk.player_id_next– en reference til den spiller, der skal foretage det næste træk i det aktuelle spil.result_id_1ogresult_id_2– referencer tilresulttabel, der gemmer udfaldet af spillet for hver spiller.player_1_points_wonogplayer_2_points_won– angiv antallet af point, som spillerne blev tildelt, i overensstemmelse med resultatet af spillet.
Vi vil diskutere, hvordan spillere kan holde styr på alle træk i sektionen Kampe nær slutningen af denne artikel. Indtil videre går vi videre til spilopsætningen.
Afsnit 2:Spilopsætning
Spilopsætningssektionen indeholder en beskrivelse af alle brædder og brikker i 3D skak, samt en liste over alle lovlige træk, som spillere kan foretage.
Som vi nævnte tidligere, involverer 3D skak ofte mere end ét bræt. Disse brædder kan holde sig til standard 8x8 dimensioner med faste positioner, men det behøver ikke at være tilfældet. Listen over alle tavler er gemt i board bord. For hver tavle gemmer vi et unikt board_name , starting_position af tavlen i forhold til vores valgte 3D-koordinater, og alle yderligere details .
Dernæst vil vi definere alle mulige typer brikker, der kan dukke op på vores skakbrætter. For at gøre det bruger vi piece_type ordbog. Ud over dens primære nøgle indeholder denne ordbog kun én unik værdi, typenavn. For et standard skaksæt forventer vi at se værdierne "bonde", "rook", "ridder", "biskop", "konge" og "dronning" i denne ordbog.
Listen over alle individuelle brikker, der bruges i et spil 3D skak, er gemt i piece bord. For hvert stykke gemmer vi følgende oplysninger:
piece_name– et unikt navn, der beskriver briktypen og dens startposition.starting_position– en værdi, der angiver det præcise bræt og kvadrat, hvorpå brikken oprindeligt er placeret.board_id– en henvisning til det bræt, hvor brikken oprindeligt er placeret.piece_type_id– en reference, der angiver stykkets type.
Til sidst bruger vi move_type tabel for at gemme listen over alle mulige træk, brikkerne kan foretage på vores brædder (såvel som alle bevægelser, som brætterne selv kan foretage). Husk fra introduktionen, at visse brædder anvender særlige bevægelsesregler på deres brikker. For hvert træk definerer vi følgende:
type_name– et navn, vi vil bruge til at angive det træk, der blev foretaget, som ikke vil være en unik værdi (f.eks. kan vi have "bonde rykket 1 felt frem" så mange gange som nødvendigt).piece_type_id– en henvisning til den type brik, der blev flyttet. Hvis denne værdi tilfældigvis er NULL, så vedrører bevægelsen et helt bræt og ikke et bestemt stykke.board_id– angiver det bræt, hvor dette træk vil finde sted (hvis en skakbrik bevæger sig). Hvis selve brættet bevæger sig, vil denne værdi naturligvis repræsentere brættet, der flyttes. Sammen med to tidligere attributter danner dette den unikke nøgle til denne tabel.is_piece_moveogis_board_move– angiv, om et træk vedrører en skakbrik eller et bræt. Kun ét af disse flag kan indstilles til sand for et bestemt træk.
Da der er for mange brikbevægelser og -rotationer at overveje, gemmer vi ikke alle sådanne muligheder i vores database. I stedet gemmer vi blot flyttenavnene og implementerer den faktiske logik i selve applikationen. For eksempel vil vi definere, at bønder enten kan rykke frem et enkelt felt, rykke to felter frem fra deres startposition, gøre krav på brikker diagonalt, flytte fra et bræt til et andet og flytte som en dronning på det centrale bord. Så vi har fem mulige træktyper defineret for bønder, afhængigt af det bræt de er placeret på og deres nuværende position.
Afsnit 3:Matcher
Vi er næsten færdige! Den sidste sektion af vores model hedder Matches og indeholder tre nye tabeller, som vi vil bruge til at holde styr på bevægelseshistorien i et spil 3D skak. De resterende tabeller er blot kopier af andre tabeller fra vores datamodel, hvilket hjælper med at undgå overlappende relationer. Vi gemmer også de aktuelle positioner for alle boards og deres brikker i dette område. Lad os dykke direkte ind.
move tabel er faktisk den mest komplekse tabel i dette afsnit. Den indeholder listen over alle træk udført i løbet af et spil. Denne tabel viser listen over alle træk til spillere, som senere kan bruges til at gennemgå eller analysere kampen. For hvert træk gemmer vi følgende:
game_id– en reference tilgamehvori flytningen blev foretaget.player_id– en reference tilplayerhvem der foretog flytningen.move_in_the_game– trækets ordenstal. Dette tal, kombineret med en brikkes startposition og alle andre træk, kan bruges til at genskabe hele spillet. Ideen er at give spillerne mulighed for at simulere spillet, når det er afsluttet, så de kan analysere resultaterne af kampen.piece_id– en reference tilpieceder blev flyttet. Dette gør det nemt at spore et stykkes bevægelse fra start til slut (hovedsageligt til analyseformål).piece_type_id– en henvisning til den type brik, der blev flyttet. Selvom en brikkes reference altid vil forblive konstant, kan dens type ændre sig gennem spillet (såsom hvis en bonde forfremmes). Hvis vi flytter tavlen, vil denne attribut indeholde værdien NULL.board_id– en henvisning tilboardhvorpå flytningen fandt sted.move_notation– en aftalt notation, som vi vil bruge til at repræsentere træk.
De resterende to tabeller giver os mulighed for at gemme et øjebliksbillede af den aktuelle spiltilstand i databasen, hvilket er nyttigt, hvis spillerne ønsker at genoptage spillet på et senere tidspunkt.
current_board_position bruges til at gemme placeringen af alle tavler i vores 3D-koordinatsystem. Dette er nødvendigt for 3D skakspil, hvor mindst et bræt kan ændre sin position. For hver post i denne tabel gemmer vi en reference til det relaterede spil og bræt samt notationen af et bræts position. To specifikke attributpar, game_id + board_id og game_id + position_notation , danner de unikke nøgler til denne tabel.
Vores sidste tabel er current_piece_position , som gemmer referencer til det relaterede spil, en bestemt brik, brikkens type og en positionsnotation for brikken. Vi vil igen have to par attributter, der fungerer som de unikke nøgler til denne tabel:game_id og piece_id parret og game_id og position_notation par.
Konklusion
Det er omkring det for denne datamodel – vi er stolte over at kunne meddele, at kaptajn Kirk og hr. Spock nu kan spille 3D skak på en computer!
Har du forslag til forbedring af vores datamodel? Du er velkommen til at efterlade dine kommentarer nedenfor. Lev længe og trives ??