Ringkasan infrastruktur game cloud

Last reviewed 2022-01-28 UTC

Solusi ini menyediakan ringkasan tentang komponen dan pola desain umum yang digunakan untuk menghosting infrastruktur game di platform cloud.

Video game telah berevolusi selama beberapa dekade terakhir menjadi bisnis hiburan yang menjanjikan. Dengan meluasnya internet broadband, bermain secara online menjadi salah satu faktor utama dalam pertumbuhan game.

Permainan online tersedia dalam beberapa bentuk, seperti pertandingan multiplayer berbasis sesi, dunia virtual multiplayer massal, dan pengalaman single player yang saling berkaitan.

Pada awalnya, game yang menggunakan model server klien memerlukan pembelian dan pemeliharaan server lokal atau yang ditempatkan bersama untuk menjalankan infrastruktur online yang hanya mampu dilakukan oleh studio dan penerbit besar. Selain itu, proyeksi dan perencanaan kapasitas yang ekstensif diperlukan guna memenuhi permintaan pelanggan tanpa mengeluarkan terlalu banyak biaya untuk hardware tetap. Dengan resource komputasi berbasis cloud saat ini, developer dan penayang game skala besar maupun kecil dapat meminta dan menerima resource apa pun sesuai permintaan, untuk menghindari pengeluaran uang muka yang mahal dan bahaya penyediaan hardware yang kurang atau berlebihan.

Komponen umum

Diagram berikut ini mengilustrasikan bagian online dari arsitektur game.

Diagram infrastruktur game di Google Cloud dengan komponen frontend dan backend.

Komponen frontend arsitektur game meliputi:

  • Layanan platform game yang menyediakan fungsionalitas game tambahan.
  • Server game khusus yang menghosting game.

Komponen backend arsitektur game meliputi:

  • Status game, dipertahankan dalam sistem pencatatan dan biasanya disimpan dalam database game.
  • Stack analytics menyimpan dan menganalisis kueri peristiwa gameplay.

Komponen ini dapat dihosting di berbagai lingkungan: lokal, cloud pribadi maupun publik, atau bahkan solusi yang terkelola sepenuhnya. Selama sistem memenuhi persyaratan latensi untuk melakukan komunikasi antara komponen dan pengguna akhir, maka semua komponen ini dapat digunakan.

Frontend

Frontend menyediakan antarmuka yang dapat memungkinkan klien untuk berinteraksi, baik secara langsung maupun melalui lapisan load balancing.

Misalnya, dalam first person shooter berbasis sesi, frontend biasanya menyertakan layanan pencarian lawan seperti Open Match. Layanan ini mendistribusikan informasi sambungan untuk instance server game khusus ke klien:

  1. Klien mengirimkan permintaan ke layanan pencarian lawan.
  2. Layanan pencarian lawan memindahkan pemain ke instance server game khusus berdasarkan kriteria yang cocok.
  3. Layanan pencarian lawan kemudian mengirimkan informasi koneksi kepada klien.
  4. Selanjutnya, klien dapat terhubung secara langsung ke instance server game khusus menggunakan User Datagram Protocol (UDP).

Layanan frontend tidak harus digunakan secara eksklusif oleh klien eksternal. Komunikasi antara layanan frontend dan backend merupakan hal yang umum.

Namun, karena layanan frontend tersedia di internet, layanan tersebut menjadi lebih rentan terhadap serangan. Anda harus mempertimbangkan untuk melakukan hardening layanan frontend terhadap serangan denial-of-service dan paket yang salah format untuk membantu mengatasi masalah keamanan dan keandalan ini. Sebagai perbandingan, layanan backend secara umum hanya dapat diakses oleh kode tepercaya, dan oleh karena itu mungkin lebih sulit diserang.

Layanan platform game

Nama umum dari komponen ini adalah layanan platform atau layanan online. Layanan platform menyediakan antarmuka untuk fungsi meta-game yang penting, seperti memungkinkan pemain bergabung ke instance server game khusus yang sama, atau menyimpan grafik sosial "daftar teman" dalam game Anda. Secara umum platform tempat game Anda berjalan seperti Steam, Xbox Live atau Google Play Games menyediakan layanan sebagai berikut:

  • Papan peringkat dan histori pertandingan
  • Pencarian lawan
  • Lobi online
  • Chat
  • Pengelolaan inventaris
  • Otorisasi
  • Kelompok/grup
  • Profil
  • Guild
  • Pembuka kunci lintas platform
  • Feed
  • Pemetaan identitas sosial
  • Analisis
  • Kehadiran

Layanan platform game berkembang dengan cara yang sama dengan layanan web:

  • Pada awal 2000-an serangkaian layanan platform standar hanya berjalan sebagai layanan monolit, yang sering diimplementasikan sebagai singleton. Bahkan saat digabungkan, pola ini tidak direkomendasikan untuk deployment cloud.

  • Pola arsitektur berorientasi layanan (SOA) yang sudah tidak asing menjadi populer pada pertengahan 2000-an, seiring dengan perubahan berbagai layanan industri agar skalabel secara independen. Selain itu, layanan tersebut saat ini tidak hanya dapat diakses oleh klien dan server game, tetapi juga oleh layanan web dan, aplikasi smartphone pada akhirnya.

  • Dalam setengah dekade terakhir telah banyak developer mengadopsi pendekatan microservice yang didukung oleh perusahaan web penskalaan cepat. Banyak tantangan mendasar dari layanan platform dan aplikasi web serupa, seperti memungkinkan siklus pengembangan yang cepat dan menjalankan layanan yang terdistribusi secara luas di seluruh dunia. Microservice dapat membantu mengatasi masalah tersebut dan menjadi pilihan yang sangat tepat saat mendesain aplikasi untuk berjalan di platform cloud.

  • Selain itu, saat ini banyak layanan yang dihosting atau layanan terkelola yang menyediakan cara untuk menciptakan layanan platform atau layanan platform terkelola sepenuhnya.

Layanan platform backend

Meskipun sebagian besar layanan platform dapat diakses oleh klien eksternal, terkadang penting jika layanan platform tersebut hanya dapat diakses oleh bagian lain dari infrastruktur online Anda, seperti layanan peringkat pemain kompetitif internal yang tidak terekspos ke internet publik. Meskipun layanan platform backend tersebut biasanya tidak memiliki rute jaringan eksternal dan alamat IP, layanan tersebut mengikuti praktik desain yang sama dengan layanan platform frontend.

Referensi layanan platform game Google Cloud

Referensi berikut memberikan informasi lebih lanjut tentang cara membangun layanan platform di Google Cloud.

Server game khusus

Server game khusus menyediakan logika game. Untuk meminimalkan latensi yang dirasakan oleh pengguna, aplikasi game klien biasanya berkomunikasi secara langsung dengan server game khusus. Komunikasi ini menjadi bagian dari arsitektur layanan frontend.

Industri ini tidak memiliki terminologi standar, sehingga untuk mendukung artikel ini:

  • mesin mengacu pada mesin fisik atau virtual dimana proses server game berjalan.
  • server game mengacu pada proses server game. Beberapa proses server game dapat berjalan secara bersamaan di satu mesin.
  • instance merujuk pada satu proses server game.

Jenis server game khusus

Istilah dedicated dapat menyesatkan untuk server game backend saat ini. Dalam konteks aslinya, dedicated mengacu pada server game yang berjalan pada hardware khusus dengan rasio 1:1. Saat ini, sebagian besar penerbit game mengelola beberapa proses server game yang berjalan bersamaan di suatu mesin. Terlepas dari kenyataan bahwa proses ini kini jarang memiliki mesin yang dikhususkan untuk server tersebut, istilah dedicated game server masih sering digunakan dalam industri game.

Server game khusus sama bervariasinya dengan jenis game yang dijalankan. Beberapa kategori server game tingkat tinggi dijelaskan pada bagian berikut.

Simulasi secara real-time

Hingga saat ini, hampir setiap server game khusus untuk produk yang dikirimkan secara komersial merupakan bagian dari frontend untuk game simulasi secara real-time. Server game simulasi real-time secara historis telah memaksimalkan batas vertical scaling. Game yang paling diminati telah beralih ke taktik horizontal scaling secara manual seperti menjalankan beberapa proses server per mesin atau melakukansharding geografis di seluruh dunia. Komunikasi UDP dengan kontrol alur khusus, keandalan, dan penghindaran kemacetan adalah paradigma jaringan yang dominan.

Sebagian besar server game simulasi real-time diimplementasikan sebagai loop tanpa akhir dengan tujuan untuk menyelesaikan loop dalam anggaran waktu tertentu. Anggaran waktu biasanya mencapai 16 atau 33 milidetik yang menghasilkan rasio update status masing-masing 60 atau 30 kali per detik. Kecepatan update juga disebut sebagai kecepatan frame atau tick rate. Meskipun server mengupdate simulasinya dengan frekuensi tinggi, biasanya server mengomunikasikan update status ke klien hanya setelah beberapa update selesai. Komunikasi ini dapat menjaga kebutuhan jaringan bandwidth seimbang. Dampak dari update yang jarang dilakukan, dapat dikurangi menggunakan strategi seperti kompensasi keterlambatan .interpolasi , dan ekstrapolasi singkat ini.

Penjelasan di atas menunjukkan bahwa server game simulasi real-time menjalankan beban kerja yang sensitif terhadap latensi komputasi, dan bandwidth yang intensif, sehingga memerlukan pertimbangan cermat terhadap desain server game dan platform komputasi yang menjalankannya. Google Cloud menciptakan project open source Agones untuk membantu menyederhanakan pengoperasian server game khusus di cluster Kubernetes seperti Google Kubernetes Engine (GKE).

Game berbasis sesi atau pertandingan

Game dengan server yang didesain untuk menjalankan sesi diskresi sangat umum saat ini. Contoh umumnya adalah sesi multiplayer dari game First-Person Shooter (FPS) seperti Call of DutyTM, FortniteTM, atau TitanfallTM, maupun game multiplayer online battle arena (MOBA) seperti Dota 2TM atau League of LegendsTM. Game ini memiliki server yang memerlukan gameplay yang cepat dan perhitungan status game yang mendetail, sering kali dimunculkan pada thread yang ditujukan untuk simulasi fisika atau AI.

Dunia persisten multiplayer yang populer

Hampir dua dekade yang lalu,Ultima Online™ membuka jalan bagi perkembangan besar game massively multiplayer online (MMO). MMO terpopuler saat ini seperti, World of Warcraft™ dan Final Fantaxy XIV™, memiliki ciri khas desain server yang rumit dengan set model fitur baru.

Masalah kompleks yang umum terjadi di server game MMO, seperti meneruskan entity game antara instance server, melakukan sharding atau menentukan fase dunia game, dan secara fisik menemukan instance yang menyimulasikan area dunia game yang berdekatan. Persyaratan komputasi dan memori untuk menghitung update status untuk dunia persisten yang berisi ratusan atau ribuan pemain dapat menghasilkan solusi seperti perpanjangan waktu Eve Online™.

Server berbasis permintaan/respons

Secara teknis, semua server game khusus didasarkan pada serangkaian permintaan dan respons. Namun secara khusus, server game seluler tanpa permintaan penting untuk berkomunikasi secara real-time, telah mengadopsi semantik permintaan dan respon HTTP seperti yang digunakan dalam hosting web.

Tantangan untuk server game permintaan/respons sama dengan tantangan layanan web apa pun, termasuk hal berikut:

  • Menjaga waktu respons server game secepat mungkin.
  • Mendistribusikan server game secara global untuk mengurangi latensi dan menambahkan redundansi
  • Memvalidasi tindakan klien game di server untuk melindungi dari tindakan eksploitasi atau kecurangan.
  • Melakukan hardening server game dari denial of service dan serangan lainnya.
  • Menerapkan penundaan eksponensial untuk percobaan ulang komunikasi di pihak klien.
  • Membuat sesi "memikat" atau mengeksternalkan status proses.

Kelebihan server game permintaan/respons, seperti semantik komunikasi yang ringkas dan kemudahan percobaan ulang setelah aplikasi atau jaringan yang mengalami kegagalan, berfungsi dengan baik untuk game seluler dan turn-based. Untuk server jenis ini, sebaiknya gunakan API serverless pada platform seperti APP Engine atau Cloud Run.

Mengeksternalkan status dunia game

Saat ini, semakin banyak pemain mengharapkan nol periode nonaktif game. Ini berarti Anda perlu melindungi pengalaman pemain dari masalah yang memengaruhi instance server individu. Untuk membantu hal ini terwujud, game harus mempertahankan status pemain di luar proses server game tunggal. Ada banyak keuntungan seperti ketahanan terhadap proses server yang error dan kemampuan untuk load balancing secara efektif.

Sayangnya, dengan menggunakan pola status eksternal yang populer di layanan web dapat menimbulkan masalah yang disebabkan sejumlah alasan, termasuk:

  • Kecepatan penulisan update ke status eksternal dapat menjadi tantangan jika Anda memiliki banyak entity unik yang diperbarui puluhan kali per detik. Hal ini berlaku meskipun Anda menggunakan penyimpanan nilai kunci yang berada di-cache memori seperti Memcached atau Redis.
  • Latensi tail-end dari kueri terhadap cache status eksternal mewakili masalah yang besar. Batas waktu pembaruan status akan sulit dipenuhi jika 1% atau bahkan 0.1%, dari kueri Anda memiliki latensi yang jauh lebih besar dibandingkan batas waktu update.
  • Menentukan proses mana yang memiliki otoritas hanya baca versus baca-tulis atas objek di cache status eksternal Anda akan menimbulkan kompleksitas pada model server.

Namun, penyelesaian masalah ini menimbulkan beberapa efek samping yang menguntungkan. Status eksternal yang berhasil dan tersedia untuk banyak proses dengan pengelolaan akses yang tepat dapat menyederhanakan kemampuan untuk menghitung bagian update status game secara paralel. Hal ini juga menguntungkan untuk memigrasikan entity antar-instance.

Resource server game khusus Google Cloud

Artikel berikut menjelaskan cara menjalankan server game khusus di Google Cloud.

Backend

Layanan backend hanya menampilkan antarmuka ke layanan frontend dan backend lainnya. Klien eksternal tidak dapat berkomunikasi secara langsung dengan layanan backend. Layanan backend biasanya menyediakan cara bagi Anda untuk menyimpan dan mengakses data seperti status game di database, atau logging dan analisis pada data warehouse.

Database game

Salah satu skenario yang dapat menyebabkan pemain berhenti memainkan game dan tidak pernah kembali adalah server yang tidak berfungsi dan hilangnya progres pemain. Sayangnya, kedua hal tersebut mungkin terjadi jika Anda memiliki lapisan database yang tidak didesain dengan baik.

Database yang menyimpan status dunia game dan data progres pemain dapat dianggap sebagai bagian paling penting dari infrastruktur game Anda.

Anda harus mengevaluasi kemampuan database untuk menangani tidak hanya beban kerja yang diharapkan, tetapi juga beban kerja yang diperlukan jika game Anda sukses besar. Backend yang dirancang dan diuji untuk estimasi basis pemain, tetapi menerima lebih banyak beban secara tiba-tiba, kemungkinan tidak dapat melayani siapa pun dengan andal. Ketidakmampuan dalam merencanakan keberhasilan yang tidak terduga dapat menyebabkan game gagal, karena pemain mungkin akan meninggalkan game saat game tidak dapat dimainkan karena permasalahan database.

Game sangat rentan terhadap masalah ini. Sebagian besar bisnis dengan produk yang sukses dapat memperkirakan pertumbuhan organik secara bertahap. Namun, game pada umumnya akan menjumpai lonjakan minat awal yang besar dan diikuti dengan penurunan cepat ke jumlah penggunaan yang jauh lebih rendah. Jika game Anda sukses, database yang terkena pajak berlebih dapat mengalami penundaan yang lama sebelum menyimpan progres pengguna, atau bahkan gagal menyimpan progresnya. Terlebih, berada dalam situasi ketika Anda dipaksa untuk memutuskan fitur mana yang tidak lagi mendukung update real-time bukanlah situasi yang diinginkan oleh developer game, jadi rencanakan resource database Anda dengan hati-hati.

Mendesain database game:

  • Buat keputusan yang tepat. Jangan gunakan database selama pengembangan karena mudah untuk lolos uji, lalu membiarkan database tersebut menjadi database produksi tanpa mengevaluasi opsi lainnya. Penting untuk memahami jenis dan frekuensi akses database dari game Anda pada basis pemain yang diharapkan, dan 10x melebihi estimasi tersebut. Selanjutnya, Anda dapat membuat pilihan yang tepat terkait backend yang paling cocok untuk menangani skenario tersebut. Jangan tempatkan diri Anda dalam situasi mempelajari cara menangani krisis database saat krisis melanda.
  • Jangan berasumsi bahwa suatu solusi adalah solusi yang tepat. Tidak ada aturan bahwa Anda hanya dapat menjalankan satu database saja. Banyak game yang sukses menyimpan informasi akun dan memproses pembelian dalam game menggunakan database relasional sembari menyimpan informasi status game di database NoSQL secara terpisah. Database NoSQL lebih baik dalam menangani workload bervolume tinggi dan berlatensi rendah, sedangkan database relasional mampu memberikan transaksi yang terjamin.
  • Cadangkan data Anda. Pencadangan yang teratur dan terdistribusi secara geografis sangat penting untuk pemulihan dari kegagalan.

Database relasional

Banyak tim pengembangan game memulai dengan satu database relasional. Saat data dan traffic berkembang ke titik di mana performa database tidak lagi dapat diterima, pendekatan pertama yang umum adalah dengan menskalakan database. Setelah penskalaan tidak lagi memungkinkan, banyak developer menerapkan lapisan layanan database kustom. Pada lapisan ini, Anda dapat memprioritaskan kueri dan hasil chace yang membatasi akses database. Dengan menambahkan penskalaan dan lapisan layanan database, Anda dapat menghasilkan backend game yang dapat menangani sejumlah besar pemain, tetapi metode ini memiliki beberapa masalah umum meliputi:

  • Penskalaan—Database relasional tradisional berfokus pada pendekatanpeningkatan (penskalaan vertikal) Namun, saat merencanakan backend game berbasis cloud, sangat direkomendasikan untuk menggunakan pendekatan penyebaran (penskalaan horizontal), karena jumlah core yang dapat ada dalam satu VM akan selalu terbatas, sementara menambahkan VM lain ke project cloud Anda cukup sederhana. Database relasional memiliki pola untuk penskalaan horizontal seperti sharding, pengelompokan, dan replika bertingkat, tetapi sulit untuk ditambahkan ke database yang berjalan tanpa periode nonaktif. Jika ada kemungkinan bahwa traffic atau data Anda akan melebihi batas satu database, mulailah dengan cluster kecil terlebih dahulu. Anda tidak perlu mempelajari petunjuk penskalaan database saat krisis melanda. Menambahkan node ke cluster saat sedang berjalan dapat menjadi tantangan, tetapi tetap bisa dilakukan.
  • Perubahan skema—Hanya sedikit game yang berhasil diluncurkan dengan skema database yang berlangsung sepanjang waktu game. Pemain memerlukan fitur dan konten baru, dan penambahan ini memerlukan penyimpanan jenis data baru ke database. Di awal proses pengembangan, Anda harus menentukan cara mengupdate skema Anda. Mencoba mengupdate skema setelah meluncurkan game tanpa proses yang ditetapkan dapat mengakibatkan periode nonaktif yang tidak direncanakan atau bahkan hilangnya data pemain.
  • Administrasi—Menskalakan database relasional yang sedang berjalan dan memperbarui skemanya merupakan operasi yang kompleks. Database relasional yang dikelola secara otomatis adalah layanan umum platform cloud, tetapi tingkat adopsi database yang dikelola secara otomatis untuk backend game saat ini tergolong rendah. Hal tersebut disebabkan oleh workload backend game yang berat.

Google menawarkan Spanner, yang merupakan database relasional terkelola yang dapat membantu Anda memitigasi masalah ini. Spanner adalah layanan database yang skalabel, setingkat perusahaan, didistribusikan secara global, dan sangat konsisten yang dibuat untuk cloud. Arsitektur ini menggabungkan manfaat struktur database relasional dengan skala horizontal non-relasional. Banyak perusahaan game menganggap Spanner sangat cocok untuk mengganti database status game dan autentikasi dalam sistem skala produksi. Anda dapat menskalakan penyimpanan atau performa tambahan menggunakan Konsol Google Cloud untuk menambahkan node. Spanner dapat menangani replikasi global secara transparan dengan konsistensi tinggi, sehingga Anda tidak perlu mengelola replika regional. Untuk informasi lebih lanjut, lihat Praktik terbaik untuk menggunakan Spanner sebagai database game.

Database NoSQL

Database non-relasional dapat memberikan solusi untuk beroperasi dalam skala besar, terutama dengan workload tulis yang berat. Namun, keduanya mengharuskan Anda memahami model data NoSQL, pola akses, dan jaminan transaksi.

Ada banyak jenis database NoSQL, dan database yang cocok untuk menyimpan status dunia game seperti fitur berikut:

  • Penskalaan—Aplikasi ini didesain dengan mempertimbangkan penskalaan horizontal, dan sering kali digunakan secara default. Perubahan ukuran cluster merupakan operasi yang dapat dilakukan tanpa periode nonaktif, meskipun terkadang ada beberapa penurunan performa hingga node tambahan yang terintegrasi sepenuhnya.

  • Perubahan Skema—Skema bersifat dinamis dan diterapkan oleh lapisan aplikasi. Hal ini menjadi keuntungan besar dan dengan menambahkan kolom lain untuk fitur game baru menjadi lebih mudah.

  • Administrasi—Sebagian besar penyedia cloud menawarkan setidaknya satu mesin penyimpanan data NoSQL yang dihosting atau dikelola, sedangkan Google Cloud menawarkan beberapa opsi.

Resource database game Google Cloud

Analisis

Analisis saat ini telah berkembang menjadi komponen penting bagi game modern. Layanan online maupun klien game dapat mengirim peristiwa analisis dan telemetri ke lokasi pengembalian yang sama, tempat peristiwa tersebut disimpan dalam database. Selanjutnya, peristiwa tersebut dapat dikueri oleh semua orang, mulai dari programmer dan desainer gameplay hingga analis business intelligence serta perwakilan layanan pelanggan. Seiring dengan meningkatnya kompleksitas analisis yang dikumpulkan oleh penyimpanan peristiwa ini, maka peristiwa tersebut perlu dikueri dalam format yang mudah dan cepat.

Dalam satu dekade terakhir, popularitas Apache™ Hadoop®, mengalami peningkatan besar, yakni framework open source berdasarkan karya yang dipublikasikan dari Google. Perluasan ekosistem Hadoop telah meningkatkan penggunaan operasi ekstrak, transformasi, dan pemuatan (ETL) untuk memformat dan memasukkan peristiwa analisis ke dalam data warehouse. Penggunaan MapReduce mempercepat pengiriman hasil yang dapat ditindaklanjuti, dan kecepatan ini dapat memungkinkan analisis intensif komputasi yang lebih baru.

Sementara itu, teknologi yang tersedia di cloud terus berkembang. Banyak di antaranya tersedia sebagai layanan terkelola yang cepat dipelajari dan tidak memerlukan staf operasi khusus. Paradigma ETL streaming terbaru dari Google memberikan pendekatan terpadu untuk batch dan stream processing, serta tersedia sebagai layanan cloud terkelola dan sebagai project open source Apache Beam. Peningkatan berkelanjutan pada harga penyimpanan data cloud kini memungkinkan untuk menyimpan sejumlah besar peristiwa analisis dan log dalam database cloud yang masif dan terkelola, yang mengoptimalkan cara penulisan dan pembacaan data. Mesin kueri terbaru untuk database ini mampu menggabungkan TB data dalam hitungan detik. Sebagai contoh, lihat menganalisis 50 miliar kunjungan halaman Wikipedia dalam 5 detik.

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 sebagai insight. Meskipun Anda dapat menggunakan ETL untuk menyalin data yang ditulis oleh aplikasi Anda ke dalam format yang dapat berfungsi dengan baik untuk kueri analisis, hal tersebut memerlukan waktu dan biaya. Berinvestasi dalam desain format output analisis dapat menghemat biaya dengan signifikan dan menghasilkan kemungkinan insight analisis secara real-time.

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. Firebase juga menawarkan klien Unity dan C++ yang penggunaannya tidak terbatas pada game seluler.

Menormalisasi data untuk pelatihan model kustom AutoML Tables

Dalam membuat model ML yang efektif biasanya diperlukan keahlian ML yang luas untuk memilih fitur yang relevan dan menyesuaikan hyperparameter. Namun, mengikuti panduan persiapan data akan meningkatkan kemampuan alat otomatis terbaru untuk melakukan 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 apakah mereka akan berhenti bermain.

Meskipun peristiwa analisis dan data pemain berguna untuk kueri analisis tradisional dan metrik business intelligence, Anda memerlukan format yang berbeda untuk melatih model ML. Kasus penggunaan yang umum untuk ML dalam game adalah membuat model kustom untuk memprediksi kapan pemain akan membelanjakan uang pertama kali dalam game. AutoML Tables dapat membantu menyederhanakan proses pelatihan. Untuk informasi selengkapnya tentang AutoML Tables, lihat Menyiapkan data pelatihan Anda dan Praktik terbaik untuk membuat data pelatihan.

Beberapa studio dan penerbit game telah mencapai hasil yang diinginkan dengan menggunakan format rollup harian sebagai dasar pelatihan. Penggabungan harian adalah format baris normal yang memiliki satu kolom untuk setiap peristiwa analisis signifikan. Format baris berisi jumlah kumulatif berapa kali pemain memicu peristiwa hingga saat ini. Baris ini memberikan snapshot harian dari semua peristiwa yang berpotensi penting yang dipicu pemain hingga saat ini, beserta 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. Kemudian, Anda dapat memberikan baris penggabungan harian pada model dan memberikan prediksi seberapa besar kemungkinan pemain akan melakukan pembelian. Anda juga dapat menggunakan pendekatan yang serupa yaitu memformat data dengan flag yang berbeda untuk melatih model guna membuat prediksi yang berbeda, termasuk churn atau perilaku pemain lainnya. Melakukan investasi di muka dalam membangun format data yang dinormalisasi dapat membantu Anda mencoba model dengan cepat untuk memprediksi tindakan pemain yang Anda inginkan. Pemodelan ini berpotensi untuk membantu Anda memonetisasi game atau memprioritaskan fitur yang memberikan hasil yang diinginkan pemain.

Solusi analisis game Google Cloud

Langkah selanjutnya

Solusi untuk game online mengikuti pola umum: klien berkomunikasi dengan layanan frontend dan server game, yang berkomunikasi dengan backend analisis dan penyimpanan status. Anda dapat menjalankan setiap komponen ini di infrastruktur lokal, di cloud, atau gabungan keduanya. Untuk pola yang lebih lanut, lihat solusi game.