Apa Hubungan Poker, Blackjack, Belot, dan Preferensi dengan Basis Data?

Bagaimana merancang database yang cukup fleksibel untuk mengakomodasi beberapa permainan kartu yang sangat berbeda.

Baru-baru ini, kami menunjukkan bagaimana database dapat digunakan untuk menyimpan hasil permainan papan. Permainan papan memang menyenangkan, tetapi itu bukan satu-satunya versi online dari permainan klasik. Permainan kartu juga sangat populer. Mereka memperkenalkan elemen keberuntungan ke dalam gameplay, dan ada lebih dari sekadar keberuntungan yang terlibat dalam permainan kartu yang bagus!

Dalam artikel ini, kami akan fokus membangun model data untuk menyimpan pertandingan, hasil, pemain, dan skor game. Tantangan utama di sini adalah menyimpan data yang terkait dengan banyak permainan kartu yang berbeda. Kami juga dapat mempertimbangkan untuk menganalisis data ini untuk menentukan strategi kemenangan, meningkatkan keterampilan bermain kami sendiri, atau membangun lawan AI yang lebih baik.

Empat Permainan Kartu yang Akan Kami Gunakan di Database Kami

Karena pemain tidak dapat mengontrol kartu yang dibagikan, permainan kartu menggabungkan strategi, keterampilan, dan keberuntungan. Faktor keberuntungan itu memberi kesempatan bagi pemula untuk mengalahkan pemain berpengalaman, dan itu membuat permainan kartu membuat ketagihan. (Ini berbeda dengan permainan seperti catur, yang sangat mengandalkan logika dan strategi. Saya mendengar dari banyak pemain bahwa mereka tidak tertarik bermain catur karena mereka tidak dapat menemukan lawan pada tingkat keahlian mereka.)

Kami akan fokus pada empat permainan kartu terkenal:poker, blackjack, belot (atau belote) dan préférence. Masing-masing dari mereka memiliki aturan yang relatif kompleks dan membutuhkan waktu untuk dikuasai. Rasio keberuntungan vs pengetahuan juga berbeda untuk setiap permainan.

Kami akan melihat sekilas aturan dan spesifikasi yang disederhanakan untuk keempat game di bawah ini. Deskripsi game cukup jarang, tetapi kami telah menyertakan cukup banyak untuk menunjukkan mode permainan yang berbeda dan beragam aturan yang akan kita temui selama proses desain database.

Blackjack:

Dek: Satu sampai delapan deck masing-masing 52 kartu; tidak ada kartu joker
Pemain: Dealer dan 1 atau lebih lawan
Satuan yang Digunakan: Biasanya uang
Aturan Dasar: Pemain mendapatkan 2 kartu yang hanya bisa dilihat oleh mereka; dealer mendapat dua kartu, satu menghadap ke atas dan yang lainnya menghadap ke bawah; setiap pemain memutuskan untuk menarik lebih banyak kartu (atau tidak); dealer menarik terakhir. Kartu telah menetapkan nilai poin mulai dari 1 hingga 11.
Kemungkinan Tindakan Pemain: Pukul, Berdiri, Berpisah, Menyerah
Kondisi Tujuan &Kemenangan: Jumlah kartu pemain lebih besar dari dealer; jika ada pemain yang melewati 21, pemain itu kalah.

Poker (Texas Hold'Em):

Dek: Standar (juga dikenal sebagai setelan Prancis) dek 52 kartu; tidak ada kartu joker. Kartu paling sering berwarna merah dan hitam.
Pemain: Dua sampai sembilan; pemain bergiliran menangani
Unit yang Digunakan:Biasanya chip
Aturan Dasar: Setiap pemain mulai dengan dibagikan dua kartu; pemain memasang taruhan mereka; tiga kartu dibagikan menghadap ke atas di tengah meja; pemain kembali memasang taruhan mereka; kartu keempat ditempatkan di tengah dan pemain bertaruh lagi; kemudian kartu kelima dan terakhir ditempatkan dan ronde pertaruhan terakhir selesai.
Kemungkinan Tindakan Pemain: Lipat, Panggil, Angkat, Blind Kecil, Blind Besar, Angkat Kembali
Tujuan: Kombinasikan lima kartu terbaik (dari dua kartu di tangan pemain dan lima kartu di tengah meja)
Kondisi Kemenangan:Biasanya untuk memenangkan semua chip di atas meja

Belot (Varian Belote dalam bahasa Kroasia):

Dek: Biasanya dek 32 kartu tradisional Jerman atau Hungaria; tidak ada kartu joker
Pemain: Dua sampai empat; biasanya empat pemain berpasangan dua
Satuan yang Digunakan: Poin
Aturan Dasar: Untuk permainan empat pemain, setiap pemain mendapat enam kartu di tangan dan dua kartu tertutup; pemain tawaran pertama untuk setelan truf; setelah truf ditentukan, mereka mengambil dua kartu tertutup dan meletakkannya di tangan mereka; putaran deklarasi berikut, di mana kombinasi kartu tertentu diumumkan untuk poin tambahan; permainan berlanjut sampai semua kartu telah digunakan.
Kemungkinan Tindakan Pemain: Pass, Bid Suit, Deklarasi, Kartu Lempar
Gol untuk tangan: Untuk memenangkan lebih dari setengah poin
Kondisi Kemenangan: Jadilah tim pertama yang mencetak 1001 poin atau lebih

Preferensi:

Dek: Paling sering, dek 32 kartu tradisional Jerman atau Hongaria; tidak ada kartu joker
Pemain: Tiga
Satuan: Poin
Aturan Dasar: Semua pemain dibagikan 10 kartu; dua kartu "kitty" atau "talon" ditempatkan di tengah meja; pemain menentukan apakah mereka ingin menawar setelan; pemain memutuskan untuk bermain atau tidak.
Kemungkinan Tindakan Pemain: Pass, Bid Suit, Mainkan, Jangan Mainkan, Lempar Kartu
Tujuan: Tergantung pada varian Préférence yang dimainkan; dalam versi standar, penawar harus memenangkan total enam trik.
Kondisi Kemenangan: Ketika jumlah skor ketiga pemain adalah 0, pemain dengan jumlah poin terendah menang.

Mengapa Menggabungkan Basis Data dan Permainan Kartu?

Tujuan kami di sini adalah merancang model basis data yang dapat menyimpan semua data yang relevan untuk keempat permainan kartu ini. Basis data dapat digunakan oleh aplikasi web sebagai tempat untuk menyimpan semua data yang relevan. Kami ingin menyimpan pengaturan awal game, peserta game, tindakan yang diambil selama bermain, dan hasil dari satu kesepakatan, tangan, atau trik. Kita juga harus mengingat fakta bahwa kecocokan dapat memiliki satu atau lebih kesepakatan yang terkait dengannya.

Dari apa yang kami simpan di database kami, kami harus dapat membuat ulang semua tindakan yang terjadi selama permainan. Kami akan menggunakan bidang teks untuk menjelaskan kondisi kemenangan, aksi permainan, dan hasilnya. Ini khusus untuk setiap game dan logika aplikasi web akan menafsirkan teks dan mengubahnya sesuai kebutuhan.

Pengantar Singkat Model

Model ini memungkinkan kami untuk menyimpan semua data game yang relevan, termasuk:

Properti game
Daftar game dan pertandingan
Peserta
Tindakan dalam game

Karena permainan berbeda dalam banyak hal, kami akan sering menggunakan varchar(256) tipe data untuk mendeskripsikan properti, pergerakan, dan hasil.

Pemain, Pertandingan, dan Peserta

Bagian model ini terdiri dari tiga tabel dan digunakan untuk menyimpan data tentang pemain yang terdaftar, pertandingan yang dimainkan, dan pemain yang berpartisipasi.

player tabel menyimpan data tentang pemain terdaftar. username dan email atribut adalah nilai unik. nick_name atribut menyimpan nama layar pemain.

match tabel menyimpan semua data kecocokan yang relevan. Umumnya, pertandingan terdiri dari satu atau lebih kesepakatan kartu (juga dikenal sebagai ronde, tangan, atau trik). Semua pertandingan telah menetapkan aturan sebelum permainan dimulai. Atributnya adalah sebagai berikut:

game_id – merujuk tabel yang berisi daftar permainan (poker, blackjack, belot, dan préférence, dalam hal ini).
start_time dan end_time adalah waktu sebenarnya saat pertandingan dimulai dan berakhir. Perhatikan bahwa end_time bisa NULL; kita tidak akan memiliki nilainya sampai permainan berakhir. Juga, jika kecocokan ditinggalkan sebelum selesai, end_time nilai bisa tetap NULL.
number_of_players – jumlah peserta yang dibutuhkan untuk memulai permainan
deck_id – mereferensikan dek yang digunakan dalam game.
decks_used – adalah jumlah deck yang digunakan untuk memainkan game. Biasanya nilai ini adalah 1, tetapi beberapa game menggunakan banyak deck.
unit_id – adalah unit (poin, chip, uang, dll.) yang digunakan untuk menilai permainan.
entrance_fee – adalah jumlah unit yang dibutuhkan untuk bergabung dalam permainan; ini bisa menjadi NULL jika game tidak mengharuskan setiap pemain untuk memulai dengan sejumlah unit yang ditentukan.
victory_conditions – menentukan pemain mana yang memenangkan pertandingan. Kami akan menggunakan varchar tipe data untuk menggambarkan kondisi kemenangan setiap pertandingan (yaitu tim pertama yang mencapai 100 poin) dan meninggalkan aplikasi untuk menafsirkannya. Fleksibilitas ini memberi ruang bagi banyak game untuk ditambahkan.
match_result – menyimpan hasil pertandingan dalam format teks. Seperti halnya victory_conditions , kami akan membiarkan aplikasi menafsirkan nilainya. Atribut ini dapat berupa NULL karena kita akan mengisi nilai tersebut bersamaan dengan memasukkan end_time nilai.

participant tabel menyimpan data tentang semua peserta dalam pertandingan. match_id dan player_id atribut adalah referensi ke match dan player tabel. Bersama-sama, nilai-nilai ini membentuk kunci alternatif tabel.

Sebagian besar gim memutar pemain mana yang menawar atau bermain lebih dulu. Biasanya pada babak pertama, pemain yang bermain terlebih dahulu (pemain pembuka) ditentukan oleh aturan permainan. Di babak berikutnya, pemain di sebelah kiri (atau kadang-kadang ke kanan) dari pemain pembuka asli akan menjadi yang pertama. Kami akan menggunakan initial_player_order atribut untuk menyimpan nomor urut pemain pembuka babak pertama. match_id dan initial_player_order atribut membentuk kunci alternatif lain karena dua pemain tidak dapat bermain secara bersamaan.

score atribut diperbarui ketika seorang pemain menyelesaikan pertandingan. Terkadang ini terjadi pada saat yang sama untuk semua pemain (mis. di belot atau préférence) dan terkadang saat pertandingan masih berlangsung (mis. poker atau blackjack).

Tindakan dan Jenis Tindakan

Saat memikirkan tindakan yang dapat dilakukan pemain dalam permainan kartu, kami menyadari bahwa kami harus menyimpan:

Apa tindakannya
Siapa yang melakukan tindakan itu
Kapan (kesepakatan mana) tindakan itu terjadi
Kartu mana yang digunakan dalam tindakan tersebut

action_type tabel adalah kamus sederhana yang berisi nama-nama tindakan pemain. Beberapa nilai yang mungkin termasuk draw card, play card, pass card ke pemain lain, check dan raise.

Dalam action tabel, kami akan menyimpan semua peristiwa yang terjadi selama kesepakatan. deal_id , card_id , participant_id dan action_type_id adalah referensi ke tabel yang berisi nilai kesepakatan, peserta kartu, dan tipe_tindakan. Perhatikan bahwa participant_id dan card_id dapat berupa nilai NULL. Hal ini disebabkan oleh fakta bahwa beberapa tindakan tidak dilakukan oleh pemain (misalnya dealer menarik kartu dan menempatkannya menghadap ke atas), sementara beberapa tidak memasukkan kartu (misalnya kenaikan dalam poker). Kami perlu menyimpan semua tindakan ini untuk dapat membuat ulang seluruh pertandingan.

action_order atribut menyimpan nomor urut dari tindakan dalam game. Misalnya, tawaran pembukaan akan menerima nilai 1; tawaran berikutnya akan memiliki nilai 2, dst. Tidak boleh ada lebih dari satu tindakan yang terjadi pada waktu yang sama. Oleh karena itu, deal_id dan action_order atribut bersama-sama membentuk kunci alternatif.

action_notation atribut berisi deskripsi rinci tentang suatu tindakan. Dalam poker, misalnya, kita dapat menyimpan kenaikan tindakan dan jumlah yang sewenang-wenang. Beberapa tindakan bisa lebih rumit, jadi sebaiknya simpan nilai ini sebagai teks dan biarkan aplikasi menafsirkannya.

Penawaran dan Pesanan Transaksi

Pertandingan terdiri dari satu atau lebih kesepakatan kartu. Kita telah membahas participant dan match tabel, tetapi kami telah menyertakannya dalam gambar untuk menunjukkan hubungannya dengan deal dan deal_order tabel.

deal table menyimpan semua data yang kami butuhkan tentang satu instance kecocokan.

match_id atribut menghubungkan instance itu dengan kecocokan yang sesuai, sementara start_time dan end_time menunjukkan waktu yang tepat ketika instance itu dimulai dan kapan selesai.

move_time_limit dan deal_result atribut adalah bidang teks yang digunakan untuk menyimpan batas waktu (jika berlaku) dan deskripsi hasil kesepakatan itu.

Di participant tabel, initial_player_order atribut menyimpan pesanan pemain untuk instance pertandingan pembuka. Menyimpan pesanan untuk giliran berikutnya membutuhkan tabel yang sama sekali baru – deal_order tabel.

Jelas, deal_id dan participant_id adalah referensi ke instance pertandingan dan peserta. Bersama-sama, mereka membentuk kunci alternatif pertama di deal_order meja. player_order atribut berisi nilai yang menunjukkan urutan pemain yang berpartisipasi dalam instance pertandingan itu. Bersama dengan deal_id , itu membentuk kunci alternatif kedua dalam tabel ini. deal_result atribut adalah bidang teks yang menjelaskan hasil pertandingan untuk pemain individu. score atribut menyimpan nilai numerik yang terkait dengan hasil kesepakatan.

Jas, Pangkat, dan Kartu

Bagian model ini menjelaskan kartu yang akan kami gunakan di semua game yang didukung. Setiap kartu memiliki setelan dan peringkat.

suit_type table adalah kamus yang berisi semua jenis setelan yang akan kita gunakan. Untuk suit_type_name , kami akan menggunakan nilai seperti “Setelan Prancis”, “Setelan Jerman”, “Setelan Swiss-Jerman”, dan “Setelan Latin”.

suit tabel berisi nama-nama semua setelan yang dikandung oleh jenis dek tertentu. Misalnya, dek Prancis memiliki setelan yang disebut "Sekop", "Hati", "Berlian" dan "Klub".

Di rank kamus, kita akan menemukan nilai kartu terkenal seperti “Ace”, “King”, “Queen” dan “Jack”.

card tabel berisi daftar setiap kartu yang mungkin. Setiap kartu akan muncul di tabel ini hanya sekali. Itulah alasan mengapa suit_id dan rank_id atribut membentuk kunci alternatif tabel ini. Nilai kedua atribut bisa NULL karena beberapa kartu tidak memiliki suit atau rank (misalnya kartu joker). is_joker_card adalah nilai Boolean yang cukup jelas. card_name atribut menjelaskan kartu dengan teks:"Ace of Spades".

Kartu dan Dek

Kartu milik deck. Karena satu kartu dapat muncul di beberapa dek, kita memerlukan n:n hubungan antara card dan deck tabel.

Di deck tabel, kami akan menyimpan nama semua deck kartu yang ingin kami gunakan. Contoh nilai yang disimpan di deck_name atributnya adalah:“Standar 52 kartu (Prancis)” atau “32 kartu (Jerman)”.

card_in_deck relasi digunakan untuk menetapkan kartu ke deck yang sesuai. card_id – deck_id pair adalah kunci alternatif dari deck meja.

Cocokkan Properti, Dek, dan Unit yang Digunakan

Bagian model ini berisi beberapa parameter dasar untuk memulai permainan baru.

Bagian utama dari bagian ini adalah game meja. Tabel ini menyimpan data tentang game yang didukung aplikasi. game_name atribut berisi nilai seperti “poker”, “blackjack”, “belot”, dan “préférence”.

min_number_of_players dan max_number_of_players adalah jumlah minimal dan maksimal peserta dalam suatu pertandingan. Atribut ini berfungsi sebagai batasan untuk permainan, dan ditampilkan di layar pada awal pertandingan. Orang yang memulai pertandingan harus memilih nilai dari rentang ini.

min_entrance_fee dan max_entrance_fee atribut menunjukkan kisaran biaya masuk. Sekali lagi, ini didasarkan pada game yang dimainkan.

Dalam possible_victory_condition , kami akan menyimpan semua kondisi kemenangan yang dapat ditetapkan ke pertandingan. Nilai dipisahkan oleh pembatas.

unit kamus digunakan untuk menyimpan setiap unit yang digunakan di semua game kami. unit_name atribut akan menampung nilai-nilai seperti “poin”, “dolar”, “euro”, dan “chip”.

game_deck dan game_unit tabel menggunakan logika yang sama. Mereka berisi daftar semua deck dan unit yang dapat digunakan dalam pertandingan. Oleh karena itu, game_id – deck_id pasangkan dan game_id – unit_id pasangan membentuk kunci alternatif di tabel masing-masing.

Skor

Dalam aplikasi kami, kami ingin menyimpan skor untuk semua pemain yang berpartisipasi dalam permainan kartu kami. Untuk setiap permainan, satu nilai numerik dihitung dan disimpan. (Perhitungan didasarkan pada hasil pemain di semua game dari satu jenis.) Skor pemain ini mirip dengan peringkat; ini memungkinkan pengguna mengetahui secara kasar seberapa bagus seorang pemain.

Kembali ke proses perhitungan. Kami akan membuat n:n hubungan antara player dan game tabel. Itu adalah player_score tabel dalam model kami. player_id dan score_id ” bersama-sama membentuk kunci alternatif tabel. “score atribut digunakan untuk menyimpan nilai numerik yang disebutkan sebelumnya.

Ada berbagai permainan kartu yang menggunakan aturan, kartu, dan deck yang sangat berbeda. Untuk membuat database yang menyimpan data lebih dari satu permainan kartu, kita perlu membuat beberapa generalisasi. Salah satu cara kami melakukan ini adalah dengan menggunakan bidang teks deskriptif dan membiarkan aplikasi menginterpretasikannya. Kita bisa menemukan cara untuk menutupi situasi yang paling umum, tetapi itu akan secara eksponensial memperumit desain database.

Seperti yang ditunjukkan artikel ini, Anda dapat menggunakan satu database untuk banyak game. Mengapa Anda melakukan ini? Tiga alasan:1) Anda dapat menggunakan kembali database yang sama; 2) itu akan menyederhanakan analitik; dan ini akan mengarah pada 3) pembentukan lawan AI yang lebih baik.