Seberapa sering menyimpan status pemain dalam game daring yang persisten?


9

Dalam permainan online, orang lebih suka masuk dan keluar kapan pun mereka mau. Biasanya, pencapaian gim mereka disimpan dengan mulus di server. Itu tidak terlalu sulit untuk dicapai, tetapi saya bertanya-tanya bagaimana bisa dilakukan dengan cara yang efisien yang masuk akal dan kemauan.

Apakah masuk akal untuk menyimpan koordinat dan status pemain setiap kali mereka mengirimnya? Server node.js saya dapat melakukan itu dengan mudah tanpa memblokir respons, dan saya ingin menggunakan database Mongo, tapi mungkin lebih tepat untuk melakukannya satu detik sekali dan dalam acara di seluruh server, mengumpulkan semuanya sekaligus?


Saya menyimpan status permainan setiap 10 detik. Saya pikir itu sudah cukup, tidak diketahui (dan saya menjalankan server MMORPG saya di netbook saya yang memiliki RAM 512Mb).
jcora

Jawaban:


10

Saya memiliki MMORPG tradisional seperti World of Warcraft.

Simpan setelah setiap perintah dari setiap pemain dan hal otonom (mis. NPC)

  • Pencadangan konstan. Server bisa turun kapan saja, dan keadaan gim disimpan hingga saat itu (atau yang terbaru mungkin).
  • Dampak terhadap kinerja server; bahkan jika itu non-blocking (yaitu di utas lain), bahkan jika database ada di server lain, ia sedang memproses yang seharusnya tidak Anda lakukan. Jika non-pemblokiran seperti yang Anda katakan, maka utas lain harus menanganinya, dan itu adalah utas yang bisa ditempati dengan sesuatu yang lain.
  • Peningkatan disk I / O, sehingga meningkatkan risiko / tingkat kegagalan. Ini terutama menjadi masalah jika Anda menggunakan SSD untuk penyimpanan, mengingat umurnya yang lebih rendah.
  • Jika Anda menurunkan database ke server lain, maka bandwidth bertambah; ini mungkin menjadi masalah jika Anda membayar bandwidth, dan jika tidak pada kartu jaringan yang terpisah maka itu mengambil sumber daya yang bisa lebih baik menggunakan penanganan lalu lintas pemain.
  • Apa yang terjadi jika server semakin tertinggal dalam menyimpan status perintah ini? Yaitu jika lebih banyak perintah masuk daripada yang bisa disimpan, jadi mereka menumpuk dalam antrian? Apakah antrian ini meluap dan menyebabkan kesalahan? Apakah Anda menghentikan semuanya sehingga antrian bisa menyusul?
  • Menurut saya pendekatan ini, walaupun kedengarannya sederhana, perlu direncanakan dengan hati-hati. Misalnya, perintah berurutan yang mengandalkan satu sama lain perlu disimpan bersama; jika tidak, kegagalan dapat terjadi di tengah-tengah perintah, dan hanya satu yang akan disimpan tetapi tidak yang lain. Pertimbangkan jika dua pemain melakukan perdagangan dan dua perintah disimpan ke disk: "tambahkan 1 item ke penerima" dan "kurangi 1 item dari pengirim". Jika kegagalan terjadi setelah perintah pertama tetapi sebelum perintah kedua disimpan, Anda memiliki duplikasi item. (jika pesanan dibalik, maka barang Anda hilang)

Simpan semuanya secara berkala

  • Dalam hal terjadi kegagalan, server akan agak ketinggalan zaman. Semoga Anda menggunakan sesuatu seperti pendekatan jurnal, sehingga snapshot terbaru setidaknya akan utuh dan konsisten, dan semua pemain aktif diatur kembali dengan jumlah waktu yang sama.
  • Sistem basis data apa pun yang Anda gunakan mungkin memiliki optimasi untuk pembaruan batch, yang lebih efisien (lebih sedikit overhead) daripada memperbarui satu per satu.
  • Jika Anda memilih untuk sistem file biner, metode ini sangat sederhana. Buat file baru, masukkan memori ke dalamnya, letakkan penanda di ujung yang menandakan bahwa cadangan telah selesai sepenuhnya. Setelah satu cadangan selesai, hapus cadangan sebelumnya (atau tidak).
  • Proses pencadangan juga mungkin perlu memperhitungkan hal-hal yang disebutkan dalam poin-poin terakhir dari bagian lain, seperti menyimpan di tengah-tengah perintah berturut-turut yang tidak boleh dipecah. Anda mungkin memilih untuk mengunci seluruh rangkaian data, membuangnya ke disk, dan membuka kuncinya, tetapi tergantung pada berapa banyak waktu yang dibutuhkan, itu bisa mengakibatkan jeda atau perlambatan yang cukup besar dalam permainan.

Simpan karakter saat keluar (jangan simpan yang lain)

  • Yang paling penting bagi seorang pemain adalah karakter mereka, yang meliputi barang-barang yang mereka miliki, keterampilan yang mereka peroleh, daftar teman-teman mereka, dan sebagainya. Jika mereka membunuh monster dan rampasan ada di tanah di depan mereka dan kemudian server gagal, mereka akan sedikit patah hati karena tidak memiliki kesempatan untuk mengambil jarahan mereka, tetapi mereka akan mengatasinya. Jadi simpan saja barang-barang penting, dan jangan berkeringat dengan barang-barang kecil. Jangan simpan posisi NPC, misalnya; jika server turun, ketika muncul kembali, mereka akan muncul di area umum di mana mereka seharusnya berada. Pengecualian, tentu saja, untuk setiap NPC "pintar" yang karena alasan tertentu harus tetap berada di tempat mereka saat server turun.
  • Selain itu, seorang pemain tidak boleh login terlalu banyak pada satu waktu (perhatikan bahwa di sini saya sedang mempertimbangkan "kembali ke lobi" sebagai logout). Mereka pada akhirnya akan perlu istirahat di kamar mandi atau mendapatkan makanan atau terganggu oleh orang tua / teman mereka / apa pun atau tidur. Jadi mereka seharusnya tidak masuk secara realistis di nonstop lebih dari, katakanlah, 8 jam bahkan untuk gamer paling hardcore sekalipun. Jika "pemain" masuk untuk jangka waktu yang sangat lama, ada kemungkinan bahwa itu adalah beberapa orang atau bot, dan tidak ada yang diinginkan atau normal.
  • Selain itu, proses keluar Anda harus sudah memeriksa hal-hal seperti perintah berturut-turut yang disebutkan di atas. Ini seharusnya sudah mengepak karakter, jadi jelas waktu utama untuk membuangnya ke disk.

Pikiran penutup

  • Jelas saya mendukung pendekatan terakhir, tetapi saya mencoba bersikap tidak memihak tentang ketiganya.
  • Sulit untuk mengatakan yang mana dari dua metode pertama yang lebih boros. Dengan metode pertama, jika karakter mengirim beberapa perintah pindah, masing-masing akan disimpan ke disk dan ditimpa, ketika jelas mereka dapat dikemas menjadi satu. Tetapi dengan metode kedua, jika Anda memiliki setengah dari populasi Anda berdiri, posisi mereka disimpan ke disk bahkan jika mereka sama persis sejak operasi cadangan terakhir. Dalam kasus ketiga, sangat mungkin bahwa seseorang dapat masuk dan segera keluar, tetapi paling sering, banyak hal tentang pemain akan berubah sehingga pemborosan sepertinya sangat minim.
  • Ingatlah bahwa ini sepenuhnya untuk cadangan jika terjadi kegagalan, dan kegagalan harus benar-benar diminimalkan. Ini bagus untuk menangani kasus pengecualian ini, tetapi pada akhirnya, jika server gagal, beberapa data akan hilang dan beberapa pemain akan marah. Jadi, terapkan saja metode apa pun yang Anda bisa, apa pun yang menurut Anda paling sederhana atau terbaik, dan teruskan.
  • Jangan mengandalkan ini sebagai penyimpanan default; masukkan tombol shutdown yang bagus pada aplikasi server Anda, yang dengan anggun menutup koneksi dan menulis semuanya ke database. Gunakan itu secara normal.

Terakhir, jangan menganggap nasihat ini sebagai kebenaran absolut. Saya belum menulis sistem cadangan multipemain. Saya sedang mengerjakan "game" online, itulah sebabnya saya memikirkan hal ini dan menulis pemikiran saya di atas, tetapi saya belum sampai pada tahap implementasi ini. Jadi ini ditulis tanpa pengalaman nyata, tetapi setelah banyak membaca dan mengumpulkan pengetahuan tentang topik tersebut.


4
Dari apa yang saya pribadi amati, MMO komersial menggunakan kombinasi ketiganya. Penghematan terjadi setelah peristiwa dan tindakan penting seperti bos membunuh / menjarah / berdagang, secara berkala untuk mencegah tindakan yang tidak kritis terlewatkan (dan untuk tidak menghukum mereka yang login untuk jangka waktu yang lama), dan selalu saat logout. Satu metode tunggal umumnya tidak cukup. Hampir semua metode ini bergantung pada database gaya SQL yang mendasarinya yang didukung dan dipulihkan secara transparan jika ada kerusakan perangkat keras.
NtscCobalt

@NtscCobalt - Saya bersama Anda sampai "database gaya SQL". Apakah SQL benar-benar persyaratan? Bagaimana dengan NoSQL?
beatgammit

@tjameson Yah komentar saya ditulis sebelum saya menyentuh NoSQL. Saya hanya mencoba untuk mengatakan bahwa Anda tidak boleh menggulung format Anda sendiri tetapi tetap saya masih merekomendasikan SQL karena Anda harus tahu skema sebelumnya (atau menjadi malas dan menggunakan Entity-Key-Value) dan konsistensi lebih penting daripada kemampuan untuk mempartisi data itu. Lihat stackoverflow.com/questions/7339374/… untuk info lebih lanjut.
NtscCobalt

1

Saya kira itu tergantung pada jenis permainan dan jumlah lalu lintas antara pemain dan server.

Dalam MMORPG, tidak masuk akal untuk menyimpan posisi pemain setiap kali mereka mengirim informasi ke server. Akan lebih masuk akal untuk memperbarui ketika data pemain saat ini 'basi', bisa dikatakan. Mungkin juga bermanfaat untuk menyelamatkan keadaan pemain pada acara-acara besar seperti menyeberang ke wilayah baru, mengalahkan bos atau meninggalkan toko.

Dalam permainan berbasis giliran, masuk akal untuk menyelamatkan keadaan pemain setiap kali mereka mengakhiri giliran mereka serta setelah giliran pemain lawan (menghemat kehilangan kesehatan, efek mantra, dll.).

Sekali lagi, jawabannya tergantung sepenuhnya pada skala dan kemampuan server Anda. Ini semua tentang menemukan keseimbangan terbaik dan mengoptimalkan sebanyak mungkin tanpa mengorbankan kualitas.


1

Jika satu-satunya kekhawatiran Anda adalah ketika mereka keluar, maka satu jawaban sederhana adalah untuk menyimpan posisi mereka ketika kondisi apa pun bagi mereka tidak ada lagi di dunia game (karena keluar atau terputus) terjadi.

Di samping catatan, saya akan agak waspada terhadap klien melaporkan ke posisi server itu, atau setidaknya tanpa beberapa bentuk pemeriksaan sisi server kewarasan. Jika Anda sudah memiliki ini di tempat, Anda mungkin dapat menyimpan posisi itu log off atau putuskan karena Anda tidak perlu khawatir mendapatkan data apa pun dari klien secara langsung.


Ya, karenanya perlu mengirim pembaruan rutin ke server pada nilai-nilai seperti posisi dan XP. Semakin lama Anda meninggalkannya, semakin bisa diperdebatkan menjadi apakah pemain benar-benar menyimpan delta yang dilaporkan atau tidak. Jika Anda membatasi periode waktu "check-in" itu, jauh lebih mudah untuk memantau / mengontrol.
Insinyur

Masalah mengatakan kapan tepatnya seorang pemain keluar dari sebuah gim browser yang berjalan lama sebenarnya bukan masalah sepele.
Lanbo

Saya setuju itu tidak sepele, tapi itu masalah Anda harus mengatasi satu atau lain cara di sebagian besar permainan, bahkan jika hanya untuk memutuskan kapan avatar mereka tidak lagi muncul. Setelah itu selesai, itu seharusnya menjadi masalah yang relatif sederhana untuk menghubungkan ke skenario itu dan menyimpan posisi terakhir mereka yang valid.
Lunin
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.