Jujur saja:kita semua suka bermain game, terutama di komputer kita. Sampai Internet tersebar luas, kebanyakan dari kita bermain game komputer sendiri, biasanya melawan lawan AI. Itu menyenangkan, tetapi begitu Anda menyadari bagaimana mekanisme permainan bekerja, permainan kehilangan sebagian besar keajaibannya.
Perkembangan Internet memindahkan game online. Sekarang, kita bisa bermain melawan lawan manusia dan menguji kemampuan kita melawan mereka. Tidak ada lagi permainan hafalan!
Kemudian game online multiplayer (MMO) besar-besaran muncul dan mengubah segalanya. Ribuan pemain menemukan diri mereka di alam semesta permainan yang sama, bersaing memperebutkan sumber daya, bernegosiasi, berdagang, dan bertarung. Untuk memungkinkan permainan seperti itu, diperlukan struktur basis data yang dapat menyimpan semua informasi yang relevan.
Dalam artikel ini, kami akan merancang model yang menggabungkan elemen paling umum yang ditemukan di game MMO. Kami akan membahas cara menggunakannya, batasannya, dan kemungkinan peningkatannya.
Pengantar Model Data untuk Game MMO
Ada banyak game MMO yang sangat populer saat ini, dan melibatkan semua jenis skenario. Saya akan fokus di sini pada game strategi seperti Ogame , Travian , Sparta :Perang Kerajaan dan Imperia Online . Permainan ini lebih banyak tentang perencanaan, pembangunan dan penyusunan strategi, dan lebih sedikit tentang tindakan langsung.
Game MMO diatur di alam semesta yang berbeda, secara visual berbeda, dan menggunakan opsi gameplay yang kurang lebih berbeda. Namun, beberapa ide tetap sama. Pemain bersaing untuk lokasi, berjuang untuk mereka, dan membentuk aliansi dengan (dan melawan) pemain lain. Mereka membangun struktur, mengumpulkan sumber daya, dan teknologi penelitian. Mereka membangun unit (seperti prajurit, tank, pedagang, dll.) dan menggunakannya untuk berdagang dengan sekutu atau untuk bertarung dengan lawan. Semua itu perlu didukung di database kami.
Kita dapat menganggap permainan ini sebagai permainan papan online dengan banyak kotak yang diindeks. Setiap kotak dapat memiliki banyak tindakan berbeda yang terkait dengannya; beberapa tindakan akan mencakup beberapa kotak – mis. ketika kita memindahkan unit atau sumber daya dari satu lokasi ke lokasi lain.
Basis data dibagi menjadi lima area utama:
Players / UsersAlliancesLocations and StructuresResearch and ResourcesUnits
Tujuh tabel ungrouped yang tersisa terkait dengan unit dan menggambarkan posisi unit dan pergerakan dalam game. Kita akan melihat masing-masing area ini dengan lebih detail, dimulai dengan Pemain dan Aliansi .
Pemain dan Aliansi
Tidak diragukan lagi, pemain adalah bagian terpenting dari game apa pun.
player tabel berisi daftar semua pemain terdaftar yang ambil bagian dalam instance game. Kami akan menyimpan nama pengguna, kata sandi, dan nama layar pemain. Ini akan disimpan di user_name , password , dan nickname atribut masing-masing.
Pengguna baru harus memberikan alamat email saat pendaftaran. Kode konfirmasi akan dibuat dan dikirim kepada mereka, yang akan mereka balas. Kami akan memperbarui confirmation_date atribut ketika pengguna memverifikasi alamat email mereka. Jadi, tabel ini memiliki tiga kunci unik:user_name , nickname dan email .
Setiap kali pengguna masuk, catatan baru ditambahkan di login_history meja. Semua atribut dalam tabel ini cukup jelas. logout_time spesifik. Itu bisa NULL saat sesi pengguna saat ini aktif atau saat pengguna keluar dari game (tanpa logout) karena masalah teknis. Dalam login_data atribut, kami akan menyimpan detail login seperti lokasi geografis pemain, alamat IP, serta perangkat dan browser yang mereka gunakan.
Sebagian besar game MMO memungkinkan kami bekerja sama dengan pemain lain. Salah satu bentuk standar kerjasama pemain adalah aliansi. Pemain membagikan "data pribadi" dalam game mereka (status online, rencana, lokasi kota dan koloni mereka, dll.) dengan orang lain untuk mendapatkan keuntungan dari tindakan sekutu dan untuk kesenangan belaka.
alliance tabel menyimpan informasi dasar tentang aliansi game. Masing-masing memiliki alliance_name yang unik yang akan kami simpan. Kami juga akan memiliki bidang, date_founded , yang menyimpan saat aliansi didirikan. Jika aliansi dibubarkan, kami akan menyimpan informasi tersebut di date_disbanded atribut.
alliance_member tabel menghubungkan pemain dengan aliansi. Pemain dapat bergabung dan meninggalkan aliansi yang sama lebih dari sekali. Karena itu, player_id – alliance_id pasangan bukanlah kunci yang unik. Kami akan menyimpan informasi mengenai kapan seorang pemain bergabung dengan aliansi dan kapan (jika) mereka pergi dalam date_from dan date_to bidang. membership_type_id atribut adalah referensi ke membership_type kamus; itu menyimpan tingkat hak pemain saat ini di aliansi.
Hak pemain dalam aliansi dapat berubah seiring waktu. membership_actions , membership_type dan actions_allowed tabel bersama-sama mendefinisikan semua kemungkinan hak untuk anggota aliansi. Model ini tidak memungkinkan pemain untuk menentukan tingkat hak mereka sendiri dalam aliansi, tetapi itu dapat dicapai dengan cukup mudah dengan menambahkan catatan baru di membership_type kamus dan menyimpan informasi tentang aliansi mana yang terkait dengan mereka.
Singkatnya:nilai yang disimpan dalam tabel ini ditentukan oleh kami selama pengaturan awal; mereka akan berubah hanya jika kami memperkenalkan opsi baru.
membership_history tabel menyimpan semua data mengenai peran atau hak pemain dalam aliansi, termasuk rentang saat hak ini berlaku. (Misalnya, dia dapat memiliki izin "pemula" selama sebulan, dan kemudian "keanggotaan penuh" sejak saat itu.) date_to atribut NULLable karena hak aktif saat ini belum berakhir.
membership_actions kamus berisi daftar setiap tindakan yang dapat dilakukan pemain dalam aliansi. Setiap tindakan memiliki action_name-nya sendiri dan logika permainan dibangun di sekitar nama-nama ini. Kita dapat mengharapkan nilai seperti “lihat daftar anggota” , “melihat status anggota” dan “kirim pesan” di sini.
membership_type kamus berisi nama-nama unik dari grup aksi yang digunakan dalam game. actions_allowed tabel memberikan tindakan ke jenis keanggotaan. Setiap tindakan dapat ditetapkan ke jenis hanya sekali. Oleh karena itu, membership_action - membership_type pair membentuk kunci unik untuk tabel ini.
Lokasi dan Struktur
Lokasi permainan adalah area di mana pemain mengumpulkan sumber daya dan membangun struktur dan unit. Beberapa game memiliki rentang kemungkinan lokasi yang telah ditentukan sebelumnya, sementara yang lain memungkinkan pengguna untuk menentukan lokasi mereka sendiri.
Dalam ruang 3D, lokasi dapat ditentukan dengan koordinat [x:y:z]. Jika sebuah game memiliki rentang yang telah ditentukan, itu mungkin tidak mengizinkan pemain untuk menggunakan lokasi apa pun di luar rentang [0:1000] untuk ketiga sumbu, jadi kami terbatas pada ruang 1000 * 1000 * 1000.
Di sisi lain, mungkin kami ingin mengizinkan pemain untuk memasukkan koordinat yang tepat dari lokasi baru mereka – mis. [1001:2073:4] – dan kami ingin game memprosesnya untuk mereka.
Kami akan menyimpan daftar semua lokasi yang digunakan dalam instance game kami di location meja. Setiap lokasi memiliki namanya sendiri, tetapi namanya tidak unik. Sebaliknya, coordinates atribut hanya boleh berisi nilai unik. Koordinat lokasi disimpan sebagai nilai teks, sehingga kita dapat menyimpan koordinat untuk game 3D sebagai [112:72:235]. Koordinat untuk game 2D dapat disimpan sebagai <1102:98>.
Dalam beberapa permainan, lokasi akan memiliki sejumlah kotak yang digunakan untuk menampung struktur atau unit. Kami akan menyimpan informasi tersebut di dimension atribut, yang merupakan bidang teks. Dimensi dapat berupa jumlah kotak dalam kisi 2D atau 3D. player_id atribut menyimpan informasi tentang pemilik lokasi tersebut saat ini. Ini bisa menjadi NULL ketika lokasi telah ditentukan sebelumnya dan pemain bersaing untuk menempatinya.
structure tabel berisi daftar semua struktur yang dapat kita bangun di berbagai lokasi permainan. Struktur mewakili peningkatan yang memungkinkan kita menghasilkan unit yang lebih baik, melakukan jenis penelitian baru, menghasilkan lebih banyak sumber daya, dll. Setiap struktur yang digunakan dalam game memiliki structure_name uniknya sendiri. . Beberapa kemungkinan structure_name nilai adalah "pertanian", "tambang bijih", "tanaman surya", dan "pusat penelitian".
Kami dapat mengharapkan setiap struktur ditingkatkan beberapa kali, jadi kami juga akan menyimpan informasi tentang levelnya saat ini. Setiap peningkatan meningkatkan keluaran struktur, sehingga menghasilkan lebih banyak sumber daya atau memungkinkan kami menggunakan fitur baru dalam game. Kami tidak dapat mengetahui tingkat maksimum peningkatan sebelumnya, jadi kami akan mendefinisikan semua hal yang terkait dengan level (biaya, waktu peningkatan, dan produksi) dengan formula. Semua formula yang disimpan dalam database adalah inti dari mekanisme game, dan penyesuaiannya sangat penting untuk keseimbangan game dan alur game secara umum.
Demikian juga dengan upgrade_time_formula atribut. Contoh nilai untuk bidang ini adalah “
Dalam kebanyakan kasus, ada persyaratan yang harus dipenuhi sebelum pemain melakukan tindakan tertentu. Mungkin kita perlu menyelesaikan sejumlah penelitian yang ditentukan sebelum kita dapat membangun struktur baru atau sebaliknya. Kami akan menyimpan tingkat penelitian yang diperlukan untuk membangun struktur di prerequisite_research meja. Hubungan dan tingkat struktur yang diperlukan untuk memulai berbagai penelitian disimpan dalam prerequisite_structure meja. Di kedua tabel, kunci asing research_id dan structure_id dipasangkan untuk membentuk kunci yang unik. level_required atribut adalah satu-satunya nilai.
Kedua tabel ini, prerequisite_research dan prerequisite_structure , juga merupakan inti dari game ini.
Untuk setiap struktur, kami akan menentukan daftar prasyarat:struktur lain dan level minimumnya yang harus mulai dibangun oleh pemain. Kami akan menyimpan data ini di structure_required meja. Di sini, structure_id mewakili struktur yang ingin kita bangun; structure_required_id adalah referensi ke struktur prasyarat, dan level adalah level yang dibutuhkan.
structure_built tabel menyimpan informasi tentang tingkat struktur saat ini di lokasi tertentu. upgrade_ongoing atribut akan disetel hanya jika peningkatan sedang berlangsung, sedangkan upgrade_end_time atribut akan berisi stempel waktu setelah peningkatan selesai.
structure_formula tabel berhubungan struktur dan sumber daya. Pasangan kunci asing ke tabel ini membentuk kunci uniknya. Tabel ini juga memiliki dua atribut teks yang berisi rumus dengan upgrade_time_formula . Kami membutuhkannya karena kami harus menentukan sumber daya yang dihabiskan untuk membangun setiap struktur. Kami juga perlu menentukan produksi sumber daya setelah peningkatan, jika struktur menghasilkan sumber daya apa pun (mis. tambang bijih akan menghasilkan
Penelitian dan Sumber Daya
Penelitian (atau teknologi) dalam game biasanya diperlukan untuk pembuatan fitur lain. Tanpa tingkat penelitian tertentu, struktur atau tipe unit baru tidak dapat dibangun. Penelitian juga dapat memiliki persyaratan tersendiri. Salah satu yang paling umum adalah tingkat struktur tertentu, biasanya disebut "laboratorium penelitian". Atau mungkin pemain perlu menyelesaikan tingkat penelitian tertentu sebelum mereka dapat memulai penelitian baru. Semua persyaratan ini akan ditangani di bagian ini. Di bawah ini, kita dapat menemukan model data untuk Riset dan Sumber Daya:
research tabel berisi daftar semua kemungkinan tindakan penelitian dalam game kami. Ini menggunakan logika yang sama dengan structure meja. research_name atribut adalah kunci unik tabel, sedangkan upgrade_time_formula field berisi representasi teks dari rumus kebutuhan waktu penelitian, dengan upgrade_formula disimpan di research_formula tabel.
Seperti halnya struktur, kami akan menentukan daftar semua penelitian lain dan levelnya yang harus diselesaikan sebelum kami dapat memulai jenis penelitian lain. Kami akan menyimpan data ini di research_required tabel, di mana research_id mewakili penelitian yang diinginkan; research_required_id adalah referensi ke penelitian prasyarat, dan level adalah level yang dibutuhkan.
Penelitian terkait dengan pemain individu, dan untuk setiap pemain – penelitian ch pair kita harus menyimpan level penelitian pemain saat ini dan status peningkatan apa pun yang sedang berlangsung. Kami akan menyimpan informasi ini menggunakan research_level tabel dengan cara yang sama seperti kita menggunakan structure_built tabel.
Sumber daya seperti kayu, bijih, permata, dan energi ditambang atau dikumpulkan dan digunakan kemudian untuk membangun struktur dan perbaikan lainnya. Kami akan menyimpan daftar semua sumber daya dalam game di resource kamus. Satu-satunya atribut di sini adalah resource_name bidang, dan itu juga merupakan kunci unik dari tabel.
Untuk melacak jumlah sumber daya saat ini di setiap lokasi, kami akan menggunakan resources_on_location meja. Sekali lagi, pasangan kunci asing (resource_id dan location_id ) membentuk kunci unik dari tabel, sedangkan number atribut menyimpan nilai sumber daya saat ini.
Unit dan Pergerakan
Sumber daya digunakan untuk memproduksi unit. Unit dapat digunakan untuk mengangkut sumber daya, menyerang pemain lain, atau secara umum menjarah dan membakar.
Daftar jenis unit yang digunakan dalam game kami disimpan di unit kamus dengan hanya satu nilai, unit_name; atribut itu adalah kunci unik dari tabel ini. Beberapa unit permainan yang umum adalah “swordsman”, “battlecruiser”, “griffin”, “jet fighter”, “tank”, dll.
Kita perlu menggambarkan setiap unit dengan karakteristik tertentu. Daftar semua karakteristik yang mungkin disimpan di characteristic kamus. characteristic_name bidang berisi nilai unik. Nilai dalam bidang ini dapat mencakup:"serangan", "pertahanan", dan "titik sasaran". Kami akan menetapkan karakteristik ke unit menggunakan unit_characteristic hubungan. Pasangan kunci asing unit_id dan characteristic_id membentuk kunci unik dari tabel. Kami hanya akan menggunakan satu atribut, value , untuk menyimpan nilai yang diinginkan.
research_unit tabel berisi daftar semua kegiatan penelitian yang harus diselesaikan sebelum kita dapat memulai produksi untuk jenis unit tertentu. unit_cost tabel mendefinisikan sumber daya yang dibutuhkan untuk menghasilkan satu unit. Kedua tabel memiliki kunci unik yang terdiri dari pasangan kunci asing (research_id atau resources_id digabungkan dengan unit_id ) dan satu bidang nilai (cost dan level_required ).
Dan sekarang, bagian yang menyenangkan. Produksi itu menyenangkan, tetapi memindahkan unit dan mengambil tindakan bahkan lebih baik. Kami telah memperkenalkan unit tabel, tetapi kami akan menyimpannya di sini karena hubungannya dengan tabel lain.
Entah unit ditempatkan di suatu lokasi atau mereka bergerak di antara lokasi. Menambahkan player_id kolom menentukan siapa yang memiliki lokasi atau grup yang berpindah antar lokasi.
Jika unit hanya ditempatkan di lokasi tertentu, kami akan menyimpan lokasi tersebut dan jumlah unit yang ditempatkan di sana. Untuk melakukannya, kami akan menggunakan units_on_location tabel.
Ketika unit tidak ditempatkan, mereka bergerak. Kita harus menyimpan titik keberangkatan dan tujuan mereka. Selain itu, kita perlu menentukan kemungkinan tindakan selama gerakan. Semua tindakan tersebut disimpan di movement_type kamus. type_name atribut unik sedangkan allows_wait atribut menentukan apakah suatu tindakan memungkinkan menunggu di titik tujuan.
Kami dapat memindahkan satu jenis unit, tetapi dalam hampir setiap kasus kami akan memindahkan banyak unit dari beberapa jenis unit yang berbeda. Grup tersebut akan berbagi data umum dan kami akan menyimpannya di group_movement meja. Dalam tabel ini, kita akan mendefinisikan item berikut:
- pemain yang memulai tindakan tersebut
- jenis tindakan
- titik awal
- titik tujuan
arrival_timedi tempat tujuanreturn_timeke titik awalwait_timedi tempat tujuan
return_time atribut bisa NULL jika ini adalah perjalanan satu arah, dan wait_time ditentukan oleh pemain. Unit milik grup ditentukan oleh nilai yang disimpan di units_in_group meja. Pasangan kunci asing units_id dan group_moving_id membentuk kunci unik dari tabel. Jumlah unit dari jenis yang sama dalam suatu grup didefinisikan dalam number atribut.
Setiap gerakan dapat mengangkut sumber daya dari satu lokasi ke lokasi lain. Oleh karena itu, kita akan mendefinisikan hubungan banyak ke banyak antara group_movement dan resource tabel. Selain kunci utama dan kunci asing, resources_in_group tabel hanya berisi number atribut. Bidang ini menyimpan jumlah sumber daya yang dipindahkan pemain dari titik awal ke tujuan mereka.
Dalam kebanyakan kasus, pemain dapat memanggil orang lain untuk bergabung dengan petualangan mereka. Untuk mendukungnya, kami akan menggunakan dua tabel:allied_movement dan allied_groups . Satu pemain akan memulai aksi bersama, dan itu akan membuat rekor baru di allied_movement meja. Semua grup unit yang mengambil bagian dalam aksi gabungan ditentukan oleh nilai yang disimpan di allied_groups meja. Setiap grup dapat ditugaskan ke tindakan sekutu hanya sekali, jadi kunci asing membentuk kunci unik dari tabel ini.
Model ini memberi kita struktur dasar yang dibutuhkan untuk membangun game strategi MMO. Ini berisi fitur permainan yang paling penting:lokasi, struktur, sumber daya, penelitian, dan unit. Ini juga menghubungkannya, memungkinkan kita mendefinisikan prasyarat dalam database, dan menyimpan sebagian besar logika game dalam database juga.
Setelah tabel ini diisi, sebagian besar logika game ditentukan dan kami tidak mengharapkan nilai baru ditambahkan. Hampir setiap tabel memiliki nilai kunci yang unik, baik nama fitur maupun pasangan kunci asing. Mengubah karakteristik unit dan formula produksi/biaya akan memungkinkan kita mengubah keseimbangan permainan di lapisan basis data.
Bagaimana Anda akan mengubah model ini? Apa yang Anda sukai, dan apa yang akan Anda lakukan secara berbeda? Beritahu kami di bagian komentar!
