Praktik terbaik untuk arsitektur online game seluler di Google Cloud

Dokumen ini menjelaskan praktik terbaik untuk menjalankan backend game seluler berbasis API di Google Cloud. Dokumen ini memberikan referensi yang dapat digunakan developer game sebagai titik awal untuk mendesain arsitektur online untuk game seluler. Praktik terbaik dalam dokumen ini dapat berlaku untuk semua jenis game seluler. Namun, dokumen ini berfokus pada game yang menyimpan progres pemain dan informasi akun dalam database, serta mengakses data tersebut melalui API antarmuka kustom yang ditulis oleh developer game.

Dokumen ini ditujukan untuk tim yang mengembangkan video game seluler seperti Pokemon Go dari Niantic, Super Mario Run dari Nintendo, atau King's Candy Crush Saga. Praktik terbaik dalam dokumen ini bukan untuk game untung-untungan (game kartu dan game kasino) atau aplikasi olahraga fantasi (misalnya, sepak bola fantasi), yang umumnya diskalakan seperti aplikasi web atau aplikasi sosial pada umumnya.

Sifat game berbasis hit dapat mendorong lonjakan permintaan yang besar-besaran selama jam-jam sibuk. Karena aplikasi Anda mungkin ditampilkan oleh app store atau didukung oleh komunitas streaming, penting untuk mempertimbangkan skenario bencana, dan pastikan Anda memiliki jalur yang jelas untuk melakukan penskalaan saat game menjadi populer. Membuat keputusan yang tepat selama pengembangan dapat membantu meminimalkan risiko.

Memperkirakan pemuatan pengguna yang diharapkan

Saat mendesain backend online game seluler, Anda harus memiliki perkiraan perkiraan pemuatan pengguna terbaik. Jika Anda mendesain arsitektur untuk menggunakan sebagian besar resourcenya pada beban yang diharapkan, arsitektur itu mungkin akan gagal jika mendapat perhatian dari komunitas gamer yang lebih besar dan tidak dapat menyesuaikan skala untuk memenuhi permintaan tersebut. Kegagalan untuk melakukan penskalaan dapat mengakibatkan hilangnya peluang pendapatan dan kerusakan pada reputasi studio Anda. Mungkin akan menjadi tantangan untuk mendesain arsitektur yang berjalan dengan baik pada beban yang Anda harapkan, tetapi memiliki jalur yang jelas ke skala yang jauh lebih tinggi jika Anda memiliki keberhasilan yang tidak terduga.

Estimasi beban pengguna selalu didasarkan pada banyak bagian data, tetapi ada dua kategori penting yang harus disertakan:

• Jumlah pemain dan frekuensi sesi bermain: Ini biasanya merupakan perkiraan yang didasarkan pada jumlah pemain yang memainkan game serupa di pasar dan anggaran Anda untuk mendapatkan pengguna melalui pengeluaran pemasaran.
• Beban API yang disebabkan oleh setiap pemain: Hal ini dapat diukur melalui pengujian beban yang komprehensif.

Membuat perkiraan awal

Saat membuat estimasi awal, pertimbangkan semua faktor yang Anda miliki, seperti berikut ini:

• Kesuksesan game sebelumnya atau game serupa di pasar
• Popularitas kekayaan intelektual (KI) yang disertakan
• Waktu peluncuran ke pasar
• Jumlah prapendaftaran atau promosi silang di bagian lain portofolio aplikasi Anda
• Anggaran pemasaran

Setelah Anda memperkirakan jumlah pengguna, biasanya Anda membuat skenario kasus terbaik dengan empat kali (4X) estimasi. Namun, sebaiknya pertimbangkan skenario bencana sukses saat game menjadi viral atau mengalami keberhasilan yang tidak terduga. Beberapa studio meningkatkan estimasi penggunanya sebesar 10 kali (10X), tetapi peluncuran game yang lalu di Google Cloud telah meningkatkan estimasi mereka 20 kali lipat (20X) atau bahkan 40 kali (40X) dalam situasi yang ekstrem. Meskipun angka tersebut sangat kecil kemungkinannya, sebaiknya hitung angka-angka tersebut dan validasi bahwa arsitektur Anda dapat diskalakan ke level tersebut.

Menjalankan uji beban

Mengetahui jumlah pengguna yang diharapkan tidak akan cukup untuk memahami kebutuhan penskalaan game seluler Anda. Sangat penting untuk menjalankan pengujian beban dengan kondisi yang sedekat mungkin dengan keadaan di dunia nyata. Uji beban harus dijalankan dengan penguji beta tertutup menggunakan versi game yang hampir final. Dengan pengujian beban, Anda dapat membuat profil performa database penyimpanan status dan lapisan API untuk memastikan headroom yang tersedia cukup. Pengguna sungguhan sering kali bisa membuat pola penggunaan yang tidak dapat diperkirakan oleh developer. Oleh karena itu, penting untuk mendapatkan beberapa pembuatan profil penggunaan pemain langsung untuk digunakan sebagai model untuk pengujian beban dengan skala yang lebih besar. Sebaiknya gunakan framework pengujian beban untuk mereplikasi pola pengguna dari uji beta pada skala yang ditentukan berdasarkan perkiraan awal yang Anda hitung di bagian sebelumnya.

Saat Anda menjalankan uji beban berskala besar, hubungi tim penjualan Google Cloud dan ajukan tiket Cloud Customer Care yang sesuai untuk jangka waktu saat Anda berencana untuk melakukan stress testing. Dengan mengisi tiket Layanan Pelanggan, tim dapat membantu Anda secara proaktif meminta peningkatan kuota jika diperlukan. Hal ini juga membantu memastikan bahwa engineer Layanan Pelanggan tersedia untuk menjawab pertanyaan Anda jika produk Google Cloud tidak berperilaku seperti yang Anda harapkan.

Memvalidasi berdasarkan arsitektur referensi

Diagram berikut memberikan arsitektur referensi untuk praktik terbaik dalam dokumen ini:

Pada diagram sebelumnya, klien game Anda terhubung ke backend game seluler melalui load balancer. Backend memiliki koneksi langsung ke database data pemain, dengan lapisan cache berkecepatan tinggi opsional di depannya yang menyimpan dan mengambil progres pemain, hak, dan data lainnya. Backend memancarkan metrik operasi dan log ke Kemampuan observasi Google Cloud. Metrik dan log sangat penting untuk memantau performa backend Anda, dan juga dapat diakses oleh data warehouse Anda. Spesialis analisis dapat langsung mengakses data warehouse menggunakan BigQuery, dan AutoML dapat digunakan untuk membuat model yang digunakan untuk memprediksi pembelanjaan dan churn. Prediksi ini kemudian dapat tersedia untuk backend game Anda. Komponen berikut akan dijelaskan secara mendetail nanti dalam dokumen ini:

1. Komputasi yang digunakan untuk API yang ditampilkan kepada klien
2. Database yang digunakan untuk penyimpanan status
3. Kemampuan observasi dan pemantauan kemampuan observasi Google Cloud
4. Analisis

Beberapa game seluler menawarkan multiplayer real-time menggunakan server game khusus atau server TURN/STUN. Praktik terbaik dalam dokumen ini tidak menyertakan server tersebut secara eksplisit, tetapi praktik tersebut kompatibel dengan server game.

Opsi Compute

Google Cloud menyediakan beberapa opsi komputasi untuk backend game seluler Anda, mulai dari opsi skalabel yang terkelola sepenuhnya seperti App Engine, hingga lingkungan yang dapat disesuaikan sepenuhnya seperti Google Kubernetes Engine (GKE). Penting untuk memahami kebutuhan Anda secara detail dan mengambil keputusan yang sesuai. Semua opsi di bagian berikut menawarkan integrasi penuh dengan Cloud Load Balancing sehingga traffic HTTP(S) Anda dapat memanfaatkan penskalaan yang lancar. Opsi tersebut juga mencakup fitur Google Cloud Armor, seperti perlindungan DDoS tingkat perusahaan.

Menggunakan App Engine untuk mendapatkan model serverless yang skalabel

App Engine adalah platform serverless yang terkelola sepenuhnya dari Google Cloud yang memungkinkan Anda berfokus pada penulisan kode tanpa harus mengelola infrastruktur dasar. Anda dapat mengonfigurasi App Engine agar dapat melakukan penskalaan sesuai kebutuhan game Anda. Hal ini juga memungkinkan waktu iterasi yang lebih cepat bagi developer Anda dengan mem-build dan men-deploy langsung dari sumber dengan satu perintah. App Engine adalah pilihan ideal untuk tim berukuran kecil atau yang memiliki pengalaman terbatas dalam melakukan penskalaan operasi infrastruktur. Hal ini terbukti dalam skala besar melalui beberapa peluncuran game seluler, termasuk peluncuran dari Nintendo, Madfinger Games, Pocket Gems, dan Backflip Studios.

Saat mengevaluasi apakah App Engine tepat untuk game Anda, penting untuk memahami bahwa instance dapat dimulai atau dihentikan berdasarkan rasio kueri dari pemain. Oleh karena itu, desain layanan tidak boleh berencana untuk mempertahankan status dalam memori di antara permintaan pengguna. Jika perlu mempertahankan status antarpermintaan, Anda harus menyimpan dan mengambil status tersebut di database penyimpanan status (dibahas di bagian berikutnya) atau menggunakan cache terpisah seperti Memorystore (Memcached atau Redis).

Aplikasi App Engine mungkin memerlukan waktu atau resource tambahan agar dapat berjalan secara efisien di lingkungan runtime lainnya. Jika Anda memerlukan satu target runtime yang dapat di-deploy di lingkungan multi-cloud atau hybrid cloud, sebaiknya gunakan Cloud Run atau Google Kubernetes Engine.

Gunakan Cloud Run untuk aplikasi serverless baru

Dengan Cloud Run, Anda dapat mengembangkan aplikasi baru dalam container untuk backend game, tanpa harus mengelola cluster Kubernetes. Cloud Run dapat menskalakan container API Anda secara otomatis untuk memenuhi kebutuhan permintaan basis pemain Anda. Layanan ini menawarkan banyak manfaat App Engine, termasuk lingkungan runtime yang terkelola sepenuhnya tempat infrastruktur diabstraksi dan penskalaan ditangani secara otomatis sesuai dengan konfigurasi yang Anda pilih. Karena dibangun di atas Knative standar terbuka, menulis layanan portabel menjadi lebih mudah saat Anda menggunakan Cloud Run. Aplikasi Cloud Run berjalan dalam container di Kubernetes, yang memberikan jalur jelas untuk beralih ke Kubernetes yang dikelola sendiri jika Anda memerlukan kontrol lebih besar di masa mendatang.

Menggunakan GKE untuk mendapatkan kontrol penuh atas workload Anda

Google Kubernetes Engine adalah opsi bagi developer yang memerlukan kontrol lebih besar atau yang bekerja dengan tim operasi yang berpengalaman. Jika tim Anda sudah menggunakan Kubernetes untuk app stack, GKE memungkinkan mereka menjalankan backend game bersama dengan layanan yang sudah ada, menggunakan antarmuka Kubernetes dan antarmuka command line (CLI) yang sama. Jika tim Anda ingin menjalankan aplikasi di beberapa cloud atau secara lokal, GKE menyediakan platform target tunggal untuk aplikasi yang dibangun untuk cloud (aplikasi berbasis cloud). Beberapa game telah berhasil diluncurkan ke skala besar di GKE, termasuk Pokémon GO.

Database penyimpanan status

Saat memilih database untuk game seluler, Anda perlu mempertimbangkan cara menskalakan dan mengelola basis pemain yang berkembang serta meningkatkan kompleksitas game. Spanner dan Firestore kaya fitur, menawarkan pengalaman yang terkelola, dan memiliki kisah sukses game seluler yang telah terbukti dalam skala besar. Google Cloud juga menawarkan Cloud SQL, yaitu database MySQL terkelola. Namun, Cloud SQL dapat menjadi tantangan untuk diskalakan karena sharding atau pengelompokan database manual dapat menimbulkan kesulitan dan kompleksitas yang signifikan pada lapisan penyimpanan status Anda, yang menyebabkan periode nonaktif yang tidak diinginkan dan dampak terhadap pelanggan.

Gunakan Spanner untuk game global dengan berdagang antar-pengguna

Spanner adalah database relasional yang terkelola sepenuhnya dengan skala tanpa batas, konsistensi kuat, dan ketersediaan hingga 99,999%. Alat ini menampilkan semantik SQL dan antarmuka yang sudah dikenal bagi developer yang terbiasa menangani database relasional. Spanner dapat di-deploy secara global, tetapi diakses secara regional, sehingga Anda memiliki kemudahan seperti satu instance database dengan performa replika terdistribusi.

Spanner menyediakan skala tanpa batas, sehingga berfungsi dengan baik untuk profil pemain dan penyimpanan inventaris. Layanan ini juga memberikan jaminan transaksi yang memungkinkan Anda menyediakan fungsi perdagangan pemain-ke-pemain atau rumah lelang yang andal bagi pelanggan game. Spanner menyediakan beberapa alat untuk migrasi, pengembangan, kemampuan observasi, dan introspeksi untuk orientasi developer dan administrasi database. Spanner secara bertahap menskalakan ke jutaan kueri per detik (QPS). Untuk peluncuran besar, seperti peluncuran yang mengharapkan lebih dari 1.000 QPS pada hari ke-1, sebaiknya ikuti praktik terbaik pemanasan dan benchmark.

Spanner dapat menskalakan kasus penggunaan dengan miliaran pengguna, dan memberikan fleksibilitas untuk mengelola skala guna memenuhi performa yang Anda butuhkan. Spanner memiliki penggunaan yang signifikan dalam ruang game seluler. untuk mengetahui informasi tentang cara menggunakannya dalam game, lihat Praktik terbaik untuk menggunakan Spanner sebagai database game.

Gunakan Firestore untuk kecepatan pengembangan dan overhead operasional yang rendah

Firestore adalah database dokumen NoSQL yang skalabel dan terkelola sepenuhnya. Hal ini menawarkan pengalaman developer yang disederhanakan, dan tidak memerlukan pembaruan skema saat Anda ingin menyimpan informasi baru. Layanan ini juga menawarkan konsistensi yang kuat, jaminan transaksional, dan ketersediaan hingga 99,999%. Firestore juga dapat diakses langsung dari game seluler Anda yang menggunakan library klien Firebase.

Pendekatan umumnya adalah menggunakan satu dokumen Firestore per pemain, dan menyimpan semua progresnya dalam dokumen tersebut dalam hierarki yang berfungsi baik dengan desain game Anda. Saat Anda mendesain game untuk menggunakan Firestore, pertimbangkan batasan Firebase dan praktik terbaik Firestore. Berdasarkan praktik terbaik ini, beban kerja yang memerlukan pembaruan berkala pada dokumen yang sama mungkin tidak cocok. Game berskala sangat tinggi seperti Pokemon GO telah berhasil diluncurkan menggunakan Firestore (sebelumnya dikenal sebagai Datastore). Game-game tersebut berhasil diskalakan untuk memenuhi permintaan yang luar biasa lebih dari 50 kali lipat estimasi traffic pemain.

Firestore dapat otomatis menangani penskalaan. Namun, guna memastikan penskalaan yang lancar untuk peningkatan penggunaan yang tiba-tiba (misalnya, setelah pengeluaran pemasaran yang besar), Anda harus melakukan percakapan perencanaan kapasitas terlebih dahulu dengan Account Manager Google Cloud Anda.

Mengevaluasi ulang penyimpanan dalam cache sebagai pengoptimalan performa

Untuk mengoptimalkan performa, strategi game seluler yang umum digunakan adalah dengan menempatkan cache dalam memori di depan database. Cache dalam memori menyimpan data yang sering dibaca atau mengelompokkan update berprioritas rendah. Strategi ini dapat menambah kompleksitas desain ke arsitektur, dan sering kali tidak diperlukan dengan database yang skalabel dan terkelola seperti Spanner atau Firestore, yang dapat menangani beban baca dan tulis. Jika Anda menguji beban pola akses database dan masih memerlukan cache, pertimbangkan opsi terkelola seperti Memorystore untuk Redis atau Memcache untuk mengurangi overhead administrasi Anda.

Pilih lokalitas data untuk memenuhi persyaratan kepatuhan

Saat dimainkan di seluruh dunia, banyak game yang harus mematuhi hukum lokalitas data seperti GDPR. Untuk membantu mendukung kebutuhan GDPR Anda, lihat laporan resmi Google Cloud dan GDPR lalu pilih Spanner atau konfigurasi regional Firestore yang benar.

Kemampuan observasi

Sebaiknya terapkan kemampuan observasi lebih awal. Kemampuan observasi infrastruktur aplikasi dan backend penting untuk menemukan dan memperbaiki masalah dengan cepat, memungkinkan siklus pengembangan yang lebih cepat, dan mengurangi dampak pelanggan saat terjadi kesalahan. Anda dapat menghemat waktu dan uang dengan mengadopsi format yang berfungsi baik dengan Kemampuan Observasi Google Cloud di awal pengembangan.

Menggunakan standar open source untuk memasukkan metrik aplikasi Anda ke Cloud Monitoring

Semua resource Google Cloud Anda telah memiliki instrumentasi yang telah terintegrasi ke dalam Cloud Monitoring dan terlihat di Konsol Google Cloud. Oleh karena itu, sebaiknya Anda juga melengkapi backend game seluler untuk berintegrasi dengan Cloud Monitoring. Integrasi dengan Cloud Monitoring memungkinkan Anda menggunakan dasbor pemantauan antarmuka terpadu (terkadang disebut satu panel terpadu) untuk infrastruktur dan aplikasi Anda. Dengan antarmuka terpadu, Anda dapat melihat metrik utama untuk antarmuka dan aplikasi secara berdampingan, serta membantu Anda menemukan dan mengisolasi masalah dengan cepat.

Saat menerapkan metrik kustom dan pelacakan terdistribusi ke aplikasi, sebaiknya gunakan OpenTelemetry, project open source gratis yang sebelumnya dikenal sebagai OpenCensus. OpenTelemetry memberikan dukungan yang netral terhadap vendor untuk mengumpulkan metrik dan trace di banyak bahasa, serta dapat mengekspornya ke banyak produk kemampuan observasi, termasuk Cloud Monitoring dan Cloud Trace. Untuk mengetahui informasi selengkapnya, lihat Metrik kustom dengan OpenCensus.

Menggunakan logging terstruktur

Saat Anda memilih format logging, sebaiknya gunakan logging terstruktur, dan urutkan fitur menarik log Anda ke dalam kolom JSON. Implementasi ini memungkinkan Anda mengurutkan, menelusuri, dan memfilter log dengan cepat di Cloud Logging. Banyak bahasa pemrograman memiliki library atau modul logging terstruktur populer yang dapat diekspor ke Cloud Logging. Google Cloud juga menawarkan banyak Library Klien Logging idiomatis.

Membuat sink log BigQuery

Jika Anda perlu menganalisis log nanti, atau menyimpannya karena hukum retensi data di wilayah tempat Anda beroperasi, siapkan sink BigQuery untuk log Anda terlebih dahulu. Hanya log baru yang dihasilkan setelah sink dibuat yang akan ditulis ke BigQuery. Jika Anda menulis log dalam volume besar ke BigQuery, sebaiknya pilih opsi untuk menggunakan tabel berpartisi.

Analisis

Sebaiknya buat format analisis Anda untuk masa mendatang. Saat Anda memutuskan peristiwa dan metrik yang ditulis game ke backend analisis, pertimbangkan format yang paling mudah digunakan untuk menambang data untuk mendapatkan insight. Meskipun Anda dapat menggunakan ekstrak, transformasi, dan muat (ETL) untuk menyalin data yang ditulis aplikasi Anda ke dalam format yang cocok untuk kueri analisis, diperlukan waktu dan uang untuk melakukannya. Berinvestasi dalam desain format output analisis dapat menghemat biaya secara signifikan dan kemungkinan insight analisis secara real-time. Sebaiknya Anda meninjau presentasi dan testimoni dari Square Enix, King, dan LINE GAMES singkat ini. Presentasi ini dapat memberi Anda insight dunia nyata tentang penggunaan produk analisis Google Cloud untuk meningkatkan game seluler Anda.

Gunakan batch processing untuk format yang sudah ada

Jika ingin menganalisis data metrik dengan format output yang tidak Anda kontrol (misalnya, data dari integrasi atau layanan pihak ketiga), sebaiknya mulai dengan menyimpan data metrik ke Cloud Storage. Jika format data didukung, Anda dapat membuat kuerinya langsung dari antarmuka BigQuery menggunakan kueri gabungan BigQuery. Jika format data tidak didukung, Anda dapat menggunakan ETL untuk menyalin data dari Cloud Storage menggunakan Dataflow atau alat lain, lalu menyimpan hasil data yang sudah diformat di BigQuery bersama data dari sumber lainnya. Sebaiknya siapkan tugas batch reguler untuk menghemat biaya, daripada melakukan streaming, kecuali jika Anda sangat membutuhkan data secara real time. Untuk informasi selengkapnya tentang pendekatan ini, lihat Mengoptimalkan penyerapan peristiwa dan log analisis dalam skala besar.

Memprediksi churn dan pembelanjaan dengan model yang telah terbukti

Anda mungkin sudah menggunakan Firebase pada game seluler dengan salah satu fitur lain seperti konfigurasi jarak jauh .pesan dalam aplikasi, atau Library klien Firestore singkat ini. Firebase juga menawarkan model machine learning (ML) prediksi churn dan pembelanjaan bawaan. Anda dapat mengintegrasikan personalisasi Remote Config untuk menerapkan ML ke data analisis Anda, yang dapat membuat segmen pengguna dinamis berdasarkan prediksi perilaku pengguna. Data ini dapat digunakan untuk memicu fitur lainnya, atau diekspor ke BigQuery agar lebih fleksibel.

Menormalisasi data untuk pelatihan model kustom AutoML Tables

Dalam membuat model ML yang efektif biasanya diperlukan keahlian machine learning yang luas untuk memilih fitur yang relevan dan menyesuaikan hyperparameter. Namun, mengikuti panduan persiapan data akan meningkatkan kemampuan alat otomatis terbaru untuk menangani tugas-tugas ini dan membuat model yang berguna untuk Anda. Setelah dibuat, model dapat dihosting di Google Cloud untuk melakukan prediksi batch atau online—misalnya, memprediksi apakah pemain akan melakukan pembelian dalam game atau akan berhenti bermain.

Meskipun peristiwa analisis dan data pemain berguna untuk kueri analisis tradisional dan metrik business intelligence, diperlukan format yang berbeda untuk melatih model ML. Kasus penggunaan umum untuk ML di game seluler adalah membuat model kustom untuk memprediksi kapan pemain pertama kali akan menghabiskan uang dalam game. AutoML Tables dapat menyederhanakan proses pelatihan secara signifikan. Untuk ringkasan umum, lihat dokumentasi AutoML Tables Menyiapkan data pelatihan Anda dan Praktik terbaik untuk membuat data pelatihan.

Beberapa studio dan penerbit game meraih hasil luar biasa dengan menggunakan format daily-rollup sebagai dasar pelatihan. Penggabungan harian adalah format baris yang dinormalkan yang memiliki satu kolom untuk setiap peristiwa analisis penting, yang berisi jumlah kumulatif berapa kali pemain memicu peristiwa hingga hari itu. Baris ini memberikan ringkasan harian tentang semua peristiwa berpotensi penting yang dipicu pemain sejauh ini, bersama dengan tanda has made a purchase benar atau salah.

Proses yang dijelaskan dalam dokumentasi panduan memulai AutoML Tables dapat menghasilkan model berkualitas tinggi saat melakukan pelatihan dengan data yang diformat dengan cara ini. Model ini kemudian dapat diberi baris singsingan harian dan memberikan prediksi seberapa kemungkinan pemain akan melakukan pembelian. Pendekatan serupa untuk memformat data juga dapat digunakan bersama berbagai tanda untuk melatih model agar membuat prediksi yang berbeda, termasuk churn atau perilaku pemain lainnya. Melakukan investasi awal dalam membangun format data yang dinormalkan dapat membantu Anda mencoba model dengan cepat untuk memprediksi tindakan pemain yang dapat Anda bayangkan. Pemodelan ini berpotensi untuk membantu Anda memonetisasi game atau memprioritaskan fitur yang memberikan hasil yang diinginkan pemain.

Menjalankan analisis pada database game Spanner Anda

Spanner juga memungkinkan administrator dan spesialis analisis mengakses data tanpa memengaruhi traffic database game. Gabungan BigQuery-Spanner memungkinkan BigQuery mengueri data yang ada di Spanner secara real-time, tanpa menyalin atau memindahkan data. Spanner juga mendukung ekspor data menggunakan template Dataflow yang dapat Anda analisis di Looker atau di Konsol Google Cloud, atau yang dapat Anda simpan di platform analisis lain pilihan Anda.

Distribusi, notifikasi, dan topik lainnya

Pengembangan game seluler adalah bidang yang luas dan beragam. Meskipun setiap aspek tidak dapat dibahas dalam satu panduan, bagian berikut menjelaskan pertimbangan penting tambahan.

Menggunakan Cloud CDN untuk mendistribusikan aset game Anda

Cloud CDN dapat mendistribusikan aset game Anda ke klien seluler, serta memiliki integrasi Cloud Monitoring dan Cloud Logging bawaan. Jika Anda sudah memiliki hubungan dengan vendor, sebagian besar CDN utama dapat menggunakan Cloud Storage sebagai server asal.

Mengurangi perilaku penyalahgunaan menggunakan reCAPTCHA

Meskipun secara teknis reCAPTCHA bukan bagian dari infrastruktur backend Anda, reCAPTCHA dapat menjadi integrasi yang berharga ke klien Anda. Duet AI menggunakan tantangan adaptif untuk mengurangi aktivitas penyalahgunaan di aplikasi Anda, dan untuk game seluler, fitur ini sering digunakan untuk menurunkan jumlah pendaftaran pengguna otomatis (bot). Untuk informasi lebih lanjut, lihat dokumentasi reCAPTCHA.

Notifikasi push ke klien dengan Firebase Cloud Messaging

Jika game seluler Anda perlu mengirim notifikasi push atau menawarkan kemampuan kepada pengguna untuk saling mengirim pesan, pertimbangkan Firebase Cloud Messaging (FCM). FCM adalah layanan pesan lintas platform yang dapat Anda gunakan untuk mengirim pesan tanpa biaya. Fungsi ini juga dapat digunakan untuk mengirim pesan data, yang memungkinkan Anda menentukan sepenuhnya apa yang terjadi dalam kode aplikasi. Anda dapat menulis aplikasi backend pesan Anda sendiri atau menggunakan model serverless Cloud Functions untuk membuat pesan, lalu mengirimkannya menggunakan Firebase Admin SDK atau Protokol server FCM singkat ini.

Menyederhanakan distribusi konfigurasi game

Pendekatan umum untuk penyeimbangan game di game seluler adalah dengan menentukan sebagian besar parameter gameplay yang ditentukan dalam data. Selanjutnya, Anda dapat mendistribusikan update dengan aman kepada klien saat perlu memperbaiki parameter seperti tingkat drop-down atau statistik serangan senjata. Firebase Remote Config dirancang untuk memungkinkan Anda mengubah perilaku dan tampilan aplikasi tanpa mengharuskan pengguna mendownload update aplikasi. Dengan fitur ini, Anda dapat menentukan nilai default di aplikasi, yang dapat diganti untuk semua segmen atau segmen tertentu basis pengguna Anda menggunakan Firebase console, atau secara terprogram dari API backend Remote Config.

Mengevaluasi ML untuk keseimbangan game

Penelitian terkait penggunaan ML untuk keseimbangan game telah menghasilkan beberapa studi kasus yang sukses dan dipresentasikan di GDC dan peristiwa lainnya. Sebagian besar studi kasus ini berasal dari solusi khusus yang dibuat oleh data scientist dan engineer ML, dan tidak mudah direplikasi tanpa tim yang berpengalaman. Jika Anda ingin mengevaluasi ML untuk keseimbangan game atau sebagai lawan AI, alat seperti AutoML Tables dapat membantu Anda bereksperimen dengan model kustom tanpa keahlian ML yang luas. Untuk memprediksi perilaku pemain, seperti pemilihan item atau gerakan berikutnya, gunakan pendekatan yang mirip dengan yang dijelaskan dalam artikel Menormalisasi data untuk pelatihan model AutoML Tables di bagian sebelumnya dalam dokumen ini.

Langkah selanjutnya

• Google Cloud untuk game
• Ringkasan Infrastruktur Cloud Game
• Untuk arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.