UnnyWorld: post-mortem

Setelah game UnnyWorld kami ditutup, banyak pengembang yang berteman meminta untuk menulis post mortem di game tersebut . Saya memutuskan untuk membagikan contoh-contoh spesifik, yang jumlahnya telah terkumpul selama periode pengembangan. Akan dianggap ada kesalahan yang kami buat, saya akan coba berikan beberapa tips yang bermanfaat.



Sebelumnya, saya menerbitkan sebuah artikel "Tiga tahun pengembangan MMO saya" , yang lebih banyak membahas tentang pencarian investasi, tim, dan jalan kita menuju "sukses". Sayangnya (atau untungnya?), Proyek harus ditutup. Pada artikel ini saya akan mencoba meninjau kesalahan yang dilakukan dan, mungkin, memberikan setidaknya beberapa tips yang bermanfaat.

Singkatnya tentang game

Secara konvensional, Unnyworld dapat dibagi menjadi dua bagian: City builder dan Arena.
Bagian tentang pembangun adalah Clash of Clans tertentu. Anda memiliki planet sendiri, yang perlu Anda lengkapi. Dan Anda dapat menyerang planet lain untuk mencuri sumber daya.



Serang pemain lain Anda adalah salah satu karakter Anda dan Anda mengendalikannya.

Arena - MOBA 3v3 khas dengan mode yang berbeda (tangkapan bendera, pengambilan titik, dll.).



Setiap karakter memiliki mantra mereka sendiri, yang dapat dikombinasikan dengan pemain lain.


Sebelum pertempuran, Anda dapat mengubah mantra.



Siklus game secara keseluruhan terlihat seperti ini:

1. Untuk memompa mantra, diperlukan gulungan yang jatuh dari peti. Peti dapat diperoleh dengan berbagai cara gratis (untuk liga, untuk memenangkan Battle Royal, dll.) Atau membeli.
2. Untuk memompa mantera, Anda perlu membangun dan meningkatkan pembangunan pahlawan ke tingkat tertentu.
3. Untuk memperbaiki bangunan pahlawan, perlu untuk memperbaiki bangunan lain (bangunan utama, altar, dll).

Yaitu, kami mencoba untuk menyelaraskan antara rezim planet dan arena. Kami mungkin melakukan semua yang salah.

Kurangnya rencana dan strategi yang jelas

Ya, banyak hal yang terus-menerus dibahas, tetapi menyadarkan mereka, tanpa menganalisa apa yang perlu dilakukan sejak awal.

Akibatnya, mereka mencoba melakukan semuanya sekaligus. Apakah Anda memerlukan sistem guild ketika game memiliki satu setengah pengguna? Hmm, sulit.

Apakah Anda memerlukan sistem yang memungkinkan Anda membuat pertandingan khusus, mengundang teman dan rekan di sana ketika gim memiliki CCU kecil? Tidak yakin

Selama proses pengembangan, kami mencoba banyak hal untuk melakukan sesuatu yang mungkin tidak perlu dilakukan pada tahap itu. Akibatnya, hal-hal yang benar-benar perlu tidak diterapkan.

Kurang pengalaman

Karena Sebelum kami bekerja terutama hanya dengan permainan bermain-tunggal, maka kami menginjak sejumlah besar garu ketika memilih satu atau beberapa teknologi lainnya.

Mari kita bicara sedikit tentang bagian teknis dari pertanyaan itu.

Pemilihan teknologi

Sedikit klarifikasi. Sebagian besar, kami murni pengembang klien. Dari seluruh tim, hanya beberapa orang yang memiliki pengalaman bekerja dengan teknologi server. Tentang administrasi, saya biasanya diam. Saya akan mencoba menggunakan teknologi spesifik dengan ringkasan kecil untuk masing-masing.

Penyedia cloud mana yang digunakan? AWS? Azure? Lapisan lembut

Pada saat itu tidak ada perbedaan mendasar. Plus, kami memiliki pinjaman untuk SoftLayer sebagai startup.

Oh, boi, jika Anda hanya tahu betapa buruknya hal itu:

- Saport tidak terlalu berpengalaman dalam masalah ini. Ada kasus ketika saya menoleh ke mereka tentang masalah pada mesin virtual tertentu (saya tidak bisa terhubung, dll.). Saya menerima jawabannya:

Kami me-reboot mobil, sekarang semuanya baik-baik saja

- Ada kasus ketika mesin virtual naik selama berjam-jam . Seperti yang Anda lihat, saya menunggu 4 jam, tetapi mesin virtual tidak pernah dibuat.



- Perawatan sering.



- Kebetulan bahwa tanpa peringatan mobil akan reboot, atau jaringan pribadi akan terputus.

Akibatnya, mereka beralih ke Azure. Tidak ada masalah seperti itu. Dukungan merespons dengan cepat dan selalu membantu jika terjadi sesuatu.

Baik: -

Buruk: mereka tidak menganalisis dengan benar semua opsi yang memungkinkan. Tetapi server adalah bagian terpenting untuk game online = /

Jadi, Anda harus memulai instance gim di server, entah bagaimana, membuangnya melalui sistem API setelah mengotorisasi pemain ke instance yang diinginkan. Apa yang akan kita lakukan Dan mari kita ambil solusi turnkey yang akan mengelola bisnis ini tergantung pada bebannya. Wow, ada sesuatu yang disebut Kubernetes. Benar, dia dalam versi beta ... Tapi bagaimanapun, mari kita coba!

Jika kami membuang fakta bahwa Anda perlu pengalaman untuk bekerja dengan teknologi ini, bahkan dengan pengaturan dasar bisnis ini, itu berhasil jatuh. Beberapa layanan jatuh, dll.

Nah, apa lagi yang ada di sana? Mesosphere dan Apache Mesos! Semuanya sama dengan dia, sulit tanpa pengalaman. Jika ada sesuatu yang jatuh, maka tanpa rebana Anda tidak dapat memperbaiki masalahnya.

Akibatnya, mereka menulis semuanya sendiri. Mesin virtual mulai dengan supervisor, seperti halnya manajer kecil di atas mereka (ditulis dalam bahasa Jawa). Aplikasi Java ttl'it ke layanan penemuan status (jumlah kamar gratis pada contoh, dll). Saat mengotorisasi dan meminta untuk membuat ruang untuk API menggunakan informasi ini tentang instance, permintaan menuju node kanan, yang memunculkan ruangan pada instance yang tepat.

Yaitu contoh selalu pre-run. Dengan kekurangan, kami menaikkan VPS baru.

Bagus: menganalisis alternatifnya.

Buruk: menghabiskan banyak waktu pada prototipe. Untuk versi pertama, Anda tidak perlu memikirkan hal-hal ini sama sekali, tetapi cukup memulai instans tanpa keluhan di atas. Dimungkinkan untuk secara langsung meng-hardcode alamat instance pada klien dalam prototipe.

Kami menggunakan www.consul.io untuk layanan pencarian.Ini mungkin salah satu solusi yang tidak kami sesali. Benar, ada masalah seperti ini ketika konfigurasi rusak saat reboot. Tetapi ini jarang terjadi dan dengan reboot mobil yang tidak terencana. Secara umum, untuk semua waktu itu adalah kesenangan bekerja dengan konsul.

Bagus: mereka membuat solusi yang sudah jadi, tetapi tidak mulai melihat sesuatu sendiri.

Untuk penyebaran, skrip bash pada awalnya digunakan.


Kemudian, saya memindahkan seluruh penyebaran ke Ansible. Saya tidak bisa mendapatkan cukup sampai hari ini. Tentu saja ada masalah pada awalnya. Tetapi sistem ini cukup sederhana untuk dipelajari, dan dokumentasinya secara massal.

Bagus: cepat tulis skrip bash, tidak perlu pengetahuan khusus.

Buruk: ketika beralih ke sistem penempatan normal, saya harus membuang hampir semua yang ditulis sebelumnya.

Untuk komunikasi antara layanan mereka, kami mencoba www.rabbitmq.com . Tapi dia hanya keluar topik dalam beberapa hari saja bisa berantakan. Sebagai hasilnya, mereka melakukannya dengan cara yang sederhana - semua layanan berinteraksi baik melalui soket tcp murni, atau permintaan http dengan tetap-hidup, jika Anda perlu mengirim permintaan hanya dalam satu arah.

Bagus: menganalisis alternatifnya. Kami memilih solusi yang baik.

Buruk: kurangnya pengalaman dengan teknologi. Tidak perlu menyeret barang ke dalam produksi yang tidak dapat Anda perbaiki jika ada masalah.

Bermain online berarti Anda memerlukan ruang obrolan. Menulis sendiri? Itu tidak mungkin terukur. Mari kita siapkan sesuatu. XMPP? Ejabberd? Sepertinya bagus. Secara umum, kami mencoba landak dan MongooseIM, tetapi akhirnya memilih landak. Ada beberapa masalah dengan menaikkannya di server mereka (tiang tembok dengan timing dalam pesan, crash, dll.). Kami memutuskan untuk menggunakan solusi cloud mereka ejabberd-saas.com . Ya, dibayar. Tapi itu berhasil tanpa masalah.

Bagus: menganalisis alternatifnya. Pilih opsi yang sesuai.

Buruk: alih-alih memilah masalah lokal, kami memutuskan untuk menggunakan solusi cloud berbayar. Harga ada dari 200 euro. Kami memiliki beberapa wilayah permainan. Untuk tim indie, ini datang dalam jumlah yang sangat besar, yang akan lebih baik dihabiskan untuk hal-hal lain.

Pada awalnya, kami umumnya tidak memiliki sistem untuk mengumpulkan metrik di server. Mengapa permintaan melambat? Apa yang salah dengan layanan ini? Berapa banyak kamar yang tersedia sekarang? Ya, kami bahkan tidak bisa melihat berapa banyak kamar yang tersedia saat ini!

Kemudian muncul kesadaran bahwa sesuatu harus dilakukan. Mencoba menggunakan Graphite + Grafana. Bahkan gambar pra-buruh pelabuhan lakukan dengan semua ini: github.com/Suvitruf/docker-grafana-graphite-diamond

Tapi itu tidak berhasil. Saya tidak ingin menghabiskan waktu untuk hal ini, kami memutuskan untuk menggunakan sesuatu yang sudah jadi. Pilihan ada di www.datadoghq.com

Semuanya bagus. Meter, peringatan, bagan. Driver klien hampir sama dengan untuk grafit. Kecantikan Tapi ... 10 + $ untuk setiap host per bulan. III ... keluar dengan harga 200 + $ per bulan.

Kesadaran bahwa kami kencing satu ton uang untuk ini sudah terlambat. Namun, kami memutuskan untuk melakukan ini di server kami. Siapkan www.influxdata.com . Akibatnya, satu mobil selama beberapa lusin dolar diam-diam memproses metrik dari puluhan / ratusan mobil.

Bagus: kami mencobanya dengan cepat. Menemukan alternatif yang sudah jadi. Mereka menyadari (meski terlambat) bahwa keputusan itu salah. Siapkan sistem yang nyaman secara lokal.

Buruk: tidak memahami masalah dengan benar. Menghabiskan banyak uang.

Mengenai metrik, masalah yang sama dengan kinerja. Pada awalnya, kami terutama bukan klien atau server di profil. Akibatnya, kebocoran memori pada server contoh permainan ditemukan terlambat. Mereka tidak dapat menentukan dan memperbaiki dengan segera. Sebagai hasilnya, mereka menulis sehingga setelah membuat sejumlah kamar, instance game restart.

Sedikit tentang solusi konseptual dan DG

Saya sekarang tidak dapat membuat urutan waktu yang tepat untuk semua acara ini, saya akan menyebutkan beberapa keputusan penting yang kami buat.

Pembagian permainan berdasarkan wilayah

Pemain meminta server Asia dan server di Amerika Selatan (sebelum server ini berada di Eropa dan Amerika Serikat). Kenapa tidak melakukannya, ya? Mereka berhasil. Akibatnya, satu setengah pengguna tersebar di 4 wilayah. Setelah beberapa daerah, maka Anda perlu membuat sistem transfer. Apakah ini logis? Masuk akal.

Bagus: beberapa orang mendapat ping yang lebih baik (｡ • ́︿ • ̀｡)

Buruk: banyak waktu yang dihabiskan untuk membuat daerah, sistem transfer, dll.

Penting untuk mendengarkan saran / saran pemain, tetapi Anda tidak harus segera melarikan diri dan menyadari semua ini.

Mengganti kotak persegi dengan heks dan membuat ulang serangan di planet

Sebelumnya, planet-planet itu tampak seperti ini:



Dan serangannya:



Beralih ke heks telah menyederhanakan banyak hal secara teknis. Plus itu terlihat jauh lebih baik, lebih mudah untuk bekerja dengan elemen-elemen game.

Sistem mantra yang dikerjakan ulang

Dulu terlihat seperti ini:



Pembaruan itu sendiri dilakukan untuk batu yang jatuh dari peti. Segalanya tidak jelas, membingungkan.

Akibatnya, mereka mengganti sistem batu dengan gulungan seperti di Clash Royale.



Untuk meningkatkan mantera, Anda memerlukan sejumlah gulungan. Semuanya sederhana dan jelas.

Bagus: mereka memperhatikan tempat yang bermasalah dan mengubahnya.

Buruk: awalnya mereka tidak menganalisis bagaimana para pemain akan melihatnya. Banyak hal yang jelas bagi pengembang, yang dirasakan pemain dengan cara yang sama sekali berbeda. Oleh karena itu, umpan balik harus dikumpulkan sedini mungkin, mengatur playtests, dll.

Berbelanja di Twitch

Kami bahkan setuju dengan www.twitch.tv untuk melakukan pembelian dalam game di halaman game.



Tapi sejak itu tidak ada yang mengalirkan permainan kami, maka arti dari keputusan seperti itu umumnya nol.

Bagus: tempat potensial untuk penarikan uang yang adil dari pemain.

Buruk: jika game Anda tidak dialirkan, maka tidak ada gunanya. Hanya membuang-buang waktu.

Modus pertempuran royale

Setelah hype, mereka memutuskan untuk memotong rezim seperti itu dalam permainan. Tapi sejak itu Ada sedikit online dalam permainan, maka dalam mode ini hampir ada hanya bot, yang menghilangkan semuanya menjadi sia-sia.

Tentang bug

Dalam proyek semacam itu, sulit untuk tidak membuat bug. Ada banyak bug GUI yang relatif tidak berbahaya.



Ada bug yang lebih serius, misalnya, ketika pemain langsung mati di tengah arena. Kami tidak dapat mencoba kembali bug ini secara lokal. Kadang-kadang terjadi pada para pemain, tetapi kami tidak dapat memperbaikinya.

Bug lucu ketika ketika mengganti karakter model yang sebelumnya tidak dihapus. Sebagai hasilnya, adalah mungkin untuk mengatur pesta dengan keras.



Ada juga bug yang terkait dengan platform / mesin.

Misalnya, terkadang seluruh GUI bisa hilang begitu saja. Tetapi jika Anda masuk ke hierarki objek dan cukup klik pada objek, maka itu muncul lagi.


Kami melaporkan tentang masalah ini Unity. Mereka menjawab bahwa mereka bisa memberi kami seorang karyawan untuk membantu $ 10rb per bulan ლ (ಠ_ಠ ლ)

Di platform Facebook, Gameroom memiliki masalah dengan penskalaan saat gim bereaksi terhadap tachy di tempat yang salah.



Ini, belum lagi bug di berbagai perpustakaan. Misalnya, pada beberapa mesin Steamworks.NET, github.com/rlabrecque/Steamworks.NET/issues/121 dapat macet .

Ringkasan

Kami hampir tidak berinvestasi dalam pemasaran, kami berharap akan ada arus pemain organik. Permainan sebagai hasilnya tidak mencapai massa kritis itu, setelah itu bot tidak diperlukan dan akan ada gelombang organik pemain baru.

Terutama tidak ada yang terlibat dalam manajemen konten dan komunikasi dengan pemain, tidak ada buletin.

Selama pengembangan, banyak waktu yang hilang dalam pemilihan dan pengujian berbagai teknologi.

Tidak ada rencana yang jelas untuk implementasi fitur / konten.

Secara umum, sebagian besar dari semua masalah ini adalah karena kurangnya pengalaman.

Apa selanjutnya

Unnyworld telah ditutup. Kami memutuskan untuk membuat proyek lebih kecil dalam kerangka peluang saat ini.

Satu artikel tidak mencakup semuanya. Dan apa yang saya tulis tentang, bagi orang luar, mungkin tampak seperti serangkaian fakta yang tidak jelas. Sayangnya, bukan ahli untuk menulis teks seperti itu.

Jika Anda memiliki pertanyaan, dengan senang hati saya akan menjawabnya di komentar atau di artikel baru.