Server game C ++ terdistribusi yang menggunakan basis data


11

Server permainan berbasiskan C ++ saya (yang menggunakan basis data) tidak bertentangan dengan jumlah rata-rata klien saat ini (pemain), jadi saya ingin memperluasnya ke beberapa (lebih dari satu) jumlah komputer dan basis data di mana semua klien masih akan tetap berada dalam dunia permainan tunggal (server harus berkomunikasi satu sama lain dan menggunakan banyak basis data).

Apakah ada tutorial / buku / standar umum yang menjelaskan cara melakukannya dengan cara terbaik?

Jawaban:


8

Terminologi MMO untuk "tetap dalam satu dunia game" adalah beling tunggal . EVE online adalah satu-satunya MMO utama yang mencoba menjejalkan setiap pemain ke dalam satu beling.

Beruntung bagi Anda, mereka menerbitkan artikel yang sangat informatif tentang cara mereka melakukannya.


(sumber: gamasutra.com )

Berita buruknya. Anda tidak dapat menerapkan teknik EVE online secara umum. Solusi mereka benar-benar disesuaikan dengan genre dan implementasi khusus mereka.
CATATAN : Untuk semua jaringan pecahan tunggal super mewah EVE online, mereka menggunakan satu basis data. Mereka tidak dapat merancang solusi yang terukur, konsisten, dan real-time untuk database terdistribusi.

Either way membaca bagaimana mereka melakukannya harus membantu Anda merancang solusi Anda sendiri. Namun waspadalah, Anda berusaha menyelesaikan masalah yang sangat sulit.

Alih-alih mendistribusikan server gim Anda, saya sarankan jelajahi jalan Anda yang lain terlebih dahulu.

  • Profil server game Anda.
    • Optimalkan kode server Anda untuk mengurangi beban CPU jika itu merupakan masalah.
    • Optimalkan protokol komunikasi antara klien dan server untuk mengurangi obrolan jaringan.
  • Optimalkan server gamer ke komunikasi basis data.
    • jalankan pengoptimal kueri lalu buat perubahan yang sesuai.
    • mengurangi interaksi DB seminimal mungkin
  • Pindahkan DB ke mesin yang terpisah.
    Ini sering membantu satu ton. Pertahankan DB di jaringan lokal yang sama jika mungkin tetapi itu harus membantu server gim Anda menjadi jauh lebih segar ketika itu satu-satunya yang berjalan pada perangkat keras server.

Bagaimana Anda mendefinisikan "utama"? Kingdom of Loathing menggunakan pecahan tunggal. Semua orang berbagi pecahan Farmville yang sama. Star Trek Online dan Champions Online keduanya menggunakan model shard tunggal, tetapi zona yang di-instanc.

Alih-alih menggunakan database SQL, Anda juga bisa menggunakan solusi noSQL yang dirancang untuk pengelompokan dan sharding, seperti MongoDB.
Philipp

1
@JoeWreschnig webgames bukan game waktu nyata, jauh lebih mudah ... Saya tidak yakin berapa banyak pemain yang dimiliki Star Trek Online dan Champions Online ...
o0 '.

4

Langkah pertama Anda harus memisahkan akses basis data langsung dari server game dan menggunakan middleware khusus penggunaan untuk menyiapkan data untuk server Anda (mis. XML, JSON). Ini akan dapat menangani sejumlah basis data dan yang lebih penting lagi dapat memberi Anda opsi caching khusus aplikasi. Cache apa pun yang Anda bisa dan cerewet db hanya ketika Anda harus. Lakukan pengambilan besar dan jarang alih-alih banyak kueri kecil untuk mencapai kinerja terbaik dalam skenario Anda.

Database pilihan Anda mungkin juga memungkinkan Anda untuk mengoperasikan cluster yang membuatnya mudah untuk memperluas sumber daya database yang tersedia dan memberikan hasil Anda lebih cepat, tetapi ini adalah subjek yang membutuhkan banyak pengalaman dan administrator database khusus untuk mengatur dan memelihara - dan tidak cukup untuk anggaran indie juga.


1
Ini semua terdengar baik sampai Anda menganggap bahwa ia berharap memiliki beberapa server mengakses satu set data - ini berarti bahwa tanpa koordinasi lebih lanjut, cache sisi aplikasi akan keluar dari sinkronisasi yang mengarah ke kesalahan permainan terbaik dan kehilangan data paling buruk. Saya tidak setuju dengan apa pun yang Anda katakan tetapi poster asli juga perlu mempertimbangkan masalah konsistensi lintas-server sebelum melanjutkan.
Kylotan

Middleware adalah terowongan data yang di satu sisi bertanggung jawab untuk caching data, dan juga untuk menyediakan data. Namun, itu hanya menyediakan data ke server (tidak pernah ke klien) dan server cache semua data master terkait game saat startup. Jadi bisa ada banyak sumber data dan banyak pemohon data yang terhubung kapan saja. MMO yang saya kerjakan menggunakan skema ini dengan agak efisien.
Konrad K.

Itu tidak menjelaskan bagaimana Anda memecahkan masalah konsistensi lintas-server sama sekali. Pada titik tertentu server perlu menyinkronkan data antara satu sama lain, atau Anda memiliki kondisi balapan, yang bermanifestasi sebagai terputus secara acak, pemain duplikat, barang duped, pencarian yang hilang, dll.

Data tidak pernah digandakan - setiap saat hanya ada satu server yang bertanggung jawab atas objek tertentu, dan bila diperlukan, ia meneruskan objek itu ke server lain. Objek adalah koneksi klien yang juga termasuk objek kontrol pemain. Namun, ini dilakukan melalui server master dan diperdebatkan antara server. Jadi kita berhadapan dengan dua jenis data - informasi basis data (yang berhubungan dengan posting asli saya) dan objek game yang dibuat saat runtime dan dapat diedarkan dalam mmo multi-server. Tidak satu pun dari ini harus jatuh ke dalam kondisi lomba atau diduplikasi pada tingkat aplikasi
Konrad K.

3

Mengenai server game: Strategi umum adalah menggunakan beberapa server di mana setiap server mengelola bagian dari dunia game. Setiap pengguna biasanya hanya perlu tahu tentang apa yang terjadi di sekitarnya, jadi masuk akal untuk membagi dunia berdasarkan lokasi. Sayangnya ini menjadi jauh lebih rumit ketika Anda memiliki dunia terbuka tanpa batas, bukan dunia yang terdiri dari zona tertutup dan pemain berteleportasi di antara mereka. Ketika Anda memiliki dunia terbuka, Anda perlu cara untuk mentransfer pemain antar zona dengan cara yang mulus dan cara untuk menyinkronkan area di dekat perbatasan antara server. Itu masalah yang sulit.

Mengenai database: Database SQL biasanya berskala buruk. Mereka tidak dirancang untuk didistribusikan. Tetapi saat ini ada tren baru dari database NoSQL seperti MongoDB atau Cassandra yang dirancang untuk didistribusikan melalui beberapa server. Mereka membuatnya lebih mudah untuk menambah kapasitas hanya dengan menambahkan lebih banyak server. Jadi mengapa tidak semua game besar beralih ke mereka? Karena:

  1. Basis data SQL ada selama lebih dari 40 tahun, basis data NoSQL itu hanya untuk beberapa tahun. Tidak banyak yang tahu bagaimana menggunakannya secara efisien dan perkembangan mereka berkembang dengan cepat. Ada banyak produk yang bersaing dan benar-benar tidak sesuai di pasar, dan tidak ada tanda-tanda mana dari mereka akan bertahan dan yang akan usang dan dihentikan dalam beberapa tahun. Sebagian besar pemain besar lebih suka kekurangan SQL yang diketahui daripada risiko yang tidak diketahui dari database NoSQL.
  2. Mereka bekerja sangat berbeda dari database SQL dan perlu memikirkan kembali seluruh strategi kegigihan Anda. Ini mungkin menghasilkan perubahan drastis di seluruh arsitektur perangkat lunak Anda.

Jadi, ketika proyek Anda sudah sangat maju, beralih ke solusi database lain mungkin merupakan risiko besar dan investasi waktu dan energi yang sangat besar.


0

Tidak. Ini adalah area yang sangat sulit yang belum terpecahkan.


Mungkin ada beberapa solusi "templat" (bukan sebagai "pola desain C ++)? Ada banyak MMORPG
Slav

2
Sebagian besar MMO didukung oleh bencana absolut untuk database.

Secara khusus, MMO sering memiliki pendekatan yang sangat berbeda untuk kegigihan datanya, yang seringkali dapat diterima untuk desain game mereka sendiri tetapi tidak untuk desain game lainnya. Karena desain gim adalah bagian yang paling penting, Anda tidak dapat menentukan strategi persistensi dan distribusi data tanpa cukup. (Yang dapat ditafsirkan sebagai: "Ajukan pertanyaan yang lebih spesifik, beri tahu kami jenis data apa yang Anda miliki, seberapa sering itu berubah, dan mengapa Anda pikir Anda ingin mendistribusikan satu dunia di beberapa server.")
Kylotan

0

Saya tahu ini sudah tua tapi ....

Sebenarnya ada dua area untuk fokus pada ini.

Anda perlu mendistribusikan aplikasi Anda di beberapa server. Anda perlu mendistribusikan database Anda di beberapa server.

Dan Anda harus memiliki redundansi untuk keduanya.

Ada beberapa solusi open source untuk ini. Farmville adalah contoh yang baik menggunakan MemSQL / Couchbase.


1
Mendistribusikan database ke berbagai server tentu saja merupakan masalah yang terpecahkan. Sayangnya itu biasanya bukan persyaratan penting untuk gim daring yang menjaga agar akses DB mereka minimum. Sebaliknya, mendistribusikan gameplay yang sebenarnya di beberapa server masih bukan masalah yang terpecahkan.
Kylotan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.