Cobalah untuk menjaga ini sesederhana mungkin dan antarmuka didefinisikan dan didokumentasikan dengan baik. Mempertahankan dan men-debug sistem yang kompleks dalam produksi dengan mudah berubah menjadi neraka. Jadi, jika ada pendekatan yang sederhana dan kompleks, pikirkan dua kali sebelum Anda menggunakan pendekatan yang kompleks.
Mendefinisikan Layanan
Saya pikir langkah pertama adalah mengidentifikasi layanan dan dependensinya : Konten Statis, Otentikasi, Obrolan Lokal, Saluran Obrolan Global, Saluran Obrolan Regional, Daftar Teman, Serikat, Tas / Inventaris, Rumah Lelang, Peta Global, Dunia, ...
Kemudian untuk masing-masing layanan ini diputuskan jika klien dapat berbicara dengan mereka secara langsung. Misalnya, cukup mudah untuk membiarkan klien berbicara langsung dengan server yang bertanggung jawab atas Saluran Obrolan Global. Server dunia tidak harus terlibat dalam pesan obrolan sama sekali. Obrolan Regional dapat diimplementasikan dengan cara yang sama, tetapi server dunia harus memberi tahu server obrolan ketika pemain mengubah wilayah. Sekali lagi, mereka tidak perlu peduli dengan pesannya.
Langkah ketiga adalah memikirkan tentang load balancing dalam suatu layanan . Misalnya saluran obrolan global dan regional dapat dibagi ke beberapa server berdasarkan namanya. Mungkin ide yang bagus untuk tidak mengkode kode pemisahan ini ke klien, tetapi menyediakan layanan pencarian.
Server Dunia
Bagian yang paling sulit biasanya server dunia , jadi saya mulai dengan pendekatan sederhana. Mungkin ide yang baik untuk membiarkan klien berbicara langsung ke server yang bertanggung jawab untuk wilayah di mana dia berada. Jadi pada login atau melintasi wilayah klien harus diberitahu ke server mana yang harus disambungkan.
Pendekatan sederhananya adalah membagi dunia menjadi wilayah-wilayah independen . Dengan wilayah independen yang saya maksudkan bahwa seorang pemain tidak dapat melihat dari satu bagian ke bagian lain dan monster tidak dapat melintasi bagian. Wilayah-wilayah itu berbeda dari wilayah yang dilihat pemain berdasarkan lanskap dan kisah dunia luar. Biasanya sebagian besar monster berada di ruang bawah tanah dan pemain cenderung menerima bahwa mereka harus berjalan melalui gateway untuk memasuki ruang bawah tanah. Terutama jika ruang bawah tanah itu dipakai berdasarkan per kelompok pemain. Contoh lain di dunia luar adalah berbagai benua dan lembah yang dikelilingi oleh pegunungan tinggi.
Sebuah dunia yang terus-menerus pendekatan mendapat kompleks benar-benar cepat, sehingga masuk akal untuk merencanakan dengan baik: Apa informasi apakah kebutuhan klien? Informasi apa yang harus dibagikan server? Pemain sebagian besar hanya akan berinteraksi dengan objek (termasuk monster dan NPC) di wilayah yang sama. Anda dapat menipu dengan menempatkan objek di luar rentang klik dari batas zona. Ini berarti bahwa klien sebagian besar tertarik hanya membaca informasi untuk zona tetangga. Untuk kasus ini server zona tidak harus mengoordinasikan apa pun kecuali untuk izin memeriksa bahwa pemain cukup dekat untuk terhubung ke zona tetangga.
Ini hanya menyisakan sejumlah kecil kasus sulit di mana objek atau tindakan harus melewati batas server. Yang merupakan hal yang baik karena kasus-kasus seperti panah dan mantra sangat kritis terhadap kinerja. Mungkin ide yang bagus untuk membagi pertempuran menjadi menyerang dan bertahan. Jadi server spell-caster akan menentukan parameter serangan termasuk posisi caster. Server pembela akan menerima pesan tentang serangan dan menghitung dampaknya. Server penyerang tidak perlu tahu tentang dampaknya; klien akan mempelajarinya menggunakan koneksi read only-nya.
Tergantung pada seberapa kompleks model pemain Anda, mungkin diperlukan beberapa detik untuk mentransfernya ke server lain (Second Life memiliki masalah besar dengan ini). Masalah ini dapat dikurangi dengan menyiapkan transfer terlebih dahulu saat pemain mendekati perbatasan virtual. Sehingga sebagian besar data pemain sudah di-cache di server tujuan ketika serah terima aktual terjadi.
Ringkasan
Membagi masalah dengan mendefinisikan berbagai layanan yang dapat dipisah antar server dengan sedikit ketergantungan. Sebagai langkah selanjutnya lihat bagaimana melakukan keseimbangan beban dalam layanan kritis. Mendelegasikan pekerjaan penyeimbangan ke klien dengan menginstruksikannya untuk terhubung langsung ke server yang relevan (jelas server harus memeriksa izin). Buat sesederhana mungkin, dokumentasikan tanggung jawab berbagai layanan dan server dengan baik, berikan opsi untuk mengaktifkan hasil debug.
PS: Beberapa teknik ini dapat digunakan untuk meningkatkan keandalan. Dan Anda harus mengingatnya karena menggunakan banyak server menyiratkan risiko jauh lebih tinggi dari kerusakan; tidak hanya di perangkat lunak tetapi juga di tingkat perangkat keras.