Halo, Habr! Selama hampir satu setengah dekade, kami telah menciptakan dan mengembangkan layanan web. Anda mungkin mengenal beberapa dari mereka, memiliki pengalaman menggunakan, mencintai dengan penuh gairah atau memiliki perasaan campur aduk, tetapi ini bukan tentang itu sekarang.
Jadi, kami memiliki 2 pembangun situs web yang dikenal oleh pasar - uCoz dan uKit, 90+ persen pendaftaran yang tidak pernah dikonversi untuk membuat situs Anda sendiri, keinginan yang ambisius untuk menyelamatkan setidaknya 5 persen dari pemirsa ini, dan juga dua setengah orang di tim yang memiliki beberapa jenis tidak ada pengalaman dalam pengembangan game. Bukannya itu pasokan yang diperlukan untuk rilis game tentang industri web ... Yah, kau mengerti.
Awal dari jalan yang berliku
59.845 baris kode di backend dan 65675 frontend. Lebih dari 2 tahun pengembangan, gagal dan deadlock, 7 opsi antarmuka. Semua ini sekarang ada di belakang kita, meskipun mungkin perlu waktu lama untuk datang ke salah satu anggota tim dalam mimpi.
Bagaimana bisa terjadi bahwa orang-orang dan sebuah perusahaan yang terutama berurusan dengan pembangun situs tiba-tiba mengambil (dan melakukannya!) Strategi multipemain daring . Bahkan jika tematik: tentang situs dan webmaster?
Pada titik tertentu, kami menyadari bahwa uCoz, sebagai produk, mulai menjadi usang, dan ini adalah salah satu motif untuk menciptakan uKit. Semuanya akan baik-baik saja, tetapi ternyata masalahnya lebih dalam dan akarnya tidak pergi ke mana pun, tetapi menjadi psikologi manusia. Tidak masalah secara global pembuat situs mana yang harus dibicarakan - uKit, uCoz, Wix, Tilda, Jimdo, LPmotor (maafkan semua kolega lain yang belum saya sebutkan, kami beberapa ratus, saya ingat semua orang, saya suka semua orang). Sebagian besar pengguna terdaftar tidak akan pernah membuat situs . Ini adalah fakta yang mudah diverifikasi, cukup untuk membandingkan jumlah pendaftaran (hitung tanpa bot) dan jumlah domain / klien aktif yang benar-benar dilayani.
Kenapa begitu Pertanyaan yang bagus, mencari jawaban yang kami gunakan untuk menelepon dan bukan hanya pengguna. Karena besok . Atau minggu depan. Semuanya jelas, semuanya nyaman, tetapi tidak ada waktu. Ini seperti pergi ke gym.
Saat itulah muncul pemikiran sederhana - untuk orang-orang ini, untuk ketertarikan mereka, kami sudah membayar, dan tidak mencoba menyelamatkan setidaknya sebagian dari audiens ini dengan membiarkan mereka bermain dalam pembuatan situs?
“Saya percaya bahwa setiap orang yang entah bagaimana terhubung dengan penciptaan proyek Internet pasti harus bermain dengan manajemen situs sebagai bagian dari strategi ekonomi ini. Tidak heran mereka mengatakan bahwa permainan dapat mengajarkan sesuatu ... Ini adalah salah satu dari sedikit kasus ketika Anda benar-benar dapat memahami beberapa prinsip dalam mengelola tim situs dan fitur-fitur bekerja di banyak situs. Dan bagi mereka yang baru saja akan terjun ke industri ini, mempelajari mekanika yang disajikan dalam permainan adalah suatu keharusan! ”
Dmitry G. aka Dimok (terkenal di kalangan sempit webmaster Runet, blogger)
Semua orang ingin membuat game untuk diri mereka sendiri.
Jangan sampai ada yang memercayai saya sepenuhnya, tapi ini bukan prasyarat nomor satu. Meskipun sejarah setua dunia. “Saya seorang musisi, mari buat game untuk musisi!”, “Saya game dev, mari kita buat Game Dev Tycoon!” - ada banyak contoh mainan seperti itu, terutama dalam genre indie.
Ngomong-ngomong, Game Dev Tycoon adalah kesuksesan yang jelas. Ini dibuktikan dengan sekelompok klon, pengembangan pada massa. platform. Permainan kami pada dasarnya berbeda (mekanik lain, pengaturan yang berbeda), tetapi Web Tycoon paling sering dibandingkan dengan mereka.
Nyeri pertama
Keputusan dibuat, kami membuat game. Dia menulis tentang pengalaman tim di paragraf pembuka, di samping itu, orang-orang sudah sibuk dengan proyek yang sedang berlangsung, yang tidak masuk akal untuk lepas dari mereka. Jadi apa Jadi, Anda perlu mempercayakan pekerjaan kepada para profesional. Ini adalah rasa sakit pertama kami.
Pertama dan terutama, upaya jujur dilakukan untuk menyewa studio pengembangan game yang dikembangkan dengan baik untuk pengembangan. Untungnya, ada kemungkinan untuk mendapatkan rekomendasi dari rekan-rekan di bengkel yang lebih baik untuk ditelusuri. Pada tingkat ide, semua orang menyukai proyek tersebut, dan studio siap untuk mengambil pekerjaan seperti itu.
Berikut adalah beberapa skenario yang kami temui nanti:
- Ya, kami akui, gamedes kami tidak. Semoga berhasil dengan proyek ini!
- Ingin permainan browser? Mari kita lakukan di Unity, bukan pertanyaan. Dan fakta bahwa pengguna perlu menginstal plug-in ke browser (pada waktu itu hanya seperti itu) bukan masalah, harganya hampir semua orang!
Dua studio dibayar bukan diz termurah. dermaga. Menerima hasil yang sangat produktif. Banyak pekerjaan telah dilakukan, tidak ada pertanyaan. Namun, itu semua tentang beberapa game lain. Mungkin bahkan bagus, tetapi berbeda. Untuk deskripsi, yang paling populer adalah: "Apa pun yang dilakukan orang Rusia, semuanya berubah menjadi senapan serbu Kalashnikov." Jelas bahwa orang sudah terbiasa dan ingin melakukannya dalam genre yang mereka kenal, dengan mekanik terkenal dan berkembang dengan baik, dan itulah sebabnya mereka figuratif dalam diz. doc
Namun, tidak ada hikmahnya. Dari tahap ini terhuyung-huyung dari studio ke studio, kami mengeluarkan satu, tapi sangat berharga, nama. Kode aslinya adalah uWebmaster (gim ini tentang webmaster, dan kami terbiasa memanggil semuanya dengan huruf U). Opsi yang jelas lebih relevan diusulkan - Internet Tycoon, yang kemudian diubah menjadi Web Tycoon.
Rasa sakit kedua, lakukan sendiri
Ketika kami harus mengakui bahwa tidak ada yang bekerja dengan studio bersama kami (atau dengan kami), kami memutuskan untuk membuat rumah. Seleksi panjang orang mendasar untuk proses, desainer game, dimulai. Siapa yang akan menangkap ide itu, pada awalnya tertarik pada genre yang sama, memiliki kompetensi yang diperlukan, dll.
Saya tidak ingin berbicara lama tentang topik yang sangat sulit, siapa desainer game ini. Seperti yang diperlukan dan apakah perlu untuk menulis diz. dermaga. Jika seorang perancang permainan memainkan permainannya, berkomunikasi dengan audiens, jadilah seorang manajer. Ini adalah percakapan yang sangat terpisah dan holistik. Saya akan mengatakan satu hal: hari ini, untuk alasan yang sangat berbeda, proyek dan tim telah bertahan 4 desainer game (termasuk satu junior).
Perekrutan tidak mudah di semua lini. Untuk waktu yang lama, satu-satunya wakilnya adalah gameplay tunggal (salah satu dari 4 yang disebutkan di atas). Alasan utama untuk ini adalah "prinsip residual" dengan persyaratan yang cukup tinggi. Artinya, pertama-tama, pengembang membutuhkan proyek utama, dan di sana mereka dipekerjakan dengan cukup sukses. Dan techdir untuk game tidak mengkristal. Ini, tentu saja, tidak bisa dilakukan. Memutuskan untuk melakukan - lakukan itu. Tapi kami terus menyapu ini untuk waktu yang lama.
Bahkan ketika techdir akhirnya muncul, ia sudah lama menjadi pemimpin tim, arsitek, dan, untuk set lengkapnya, seorang pemain. Staf yang dikoreksi omong kosong. Butuh waktu sekitar enam bulan untuk membentuk tim yang lengkap. Anehnya, mereka sudah lama mencari ilustrator. Dan tiba-tiba manajer kantor kami menjadi mereka.
Merangkum hasil tertentu pada bagian cerita ini, kita dapat mengatakan bahwa 2 tahun yang lalu tim game kita menjadi benar-benar bekerja. Itu untuk siapa menggambar antarmuka, dan untuk siapa menulis kode, dan bahkan scrum diperkenalkan sedikit kemudian, yang sudah menjadi praktik mapan bagi perusahaan secara keseluruhan.
Desain dan Antarmuka
Sekarang kita terlihat seperti ini:
Agak tidak lazim untuk gim ini, dan orang bahkan bisa mengatakan itu membosankan dan tidak menyenangkan. Tetapi ini adalah pilihan yang bermakna. Sepintas lebih mirip portal web daripada game.
Orang menyukai:
Menampilkan tangkapan layar kepada kenalan, saya sering mendengar sesuatu seperti: "Jadi ini adalah panel admin", "Saya pikir itu adalah statistik seseorang, bukan permainan." Mereka yang menjadi audiens kami segera pergi dengan keras. Mereka menginginkan sesuatu yang benar-benar otentik, bukan toons. Mungkin kami kehilangan beberapa pemain kasual karena gaya yang dipilih, tetapi kami percaya pada keringkasannya.
Dia akhirnya yakin bahwa permainan tidak harus terlihat seperti permainan biasa, lihat Football Manager. Simulator mungkin tidak terlihat sangat lucu, tetapi berhasil. Ini adalah genre.
Dalam gaya yang dipilih ada beberapa opsi untuk visual. Di bawah ini adalah solusi berbeda dari desainer yang berbeda.
Semua lebih baik jika Anda menambahkan AI
Pemain suka kosmetik. Kami belum mengimplementasikannya, tetapi sudah belajar bagaimana membuat avatar untuk pemain dari foto. Yang paling menarik, ini terjadi dengan pendekatan spesifik yang sangat inovatif untuk pembelajaran mesin dan pelatihan model tanpa dataset.
Ini dihasilkan dari elemen desainer avatar kami, dan tidak bergaya dari foto a la Prisma. Dan meskipun mesin itu tidak memenangkan seorang pria dalam hal kualitas, itu menyusulnya dalam hal kualitas, yang, mengingat tugasnya, dianggap sukses.
Teknologi itu sendiri memiliki rencana untuk dikembangkan. Kisah ini layak untuk pos yang terpisah, atau bahkan tidak satu, dan itu pasti akan ada di Habré. Jika seseorang sangat tidak sabar, mengetuk PM, kami akan memberikan kesempatan untuk bermain dengan ini secara pribadi.
Inggris Pertama, Ponsel Pertama
Semakin dekat kami dengan rilis, semakin kami menyadari bahwa permainan kami sangat cocok untuk perangkat seluler. Di suatu tempat bahkan lebih baik daripada di desktop. Pada saat yang sama, selama periode uji coba, pemain browser kami sangat senang dengan penonton kami. Mereka melakukan percakapan IT aktif di ruang obrolan game, menulis bot untuk mengotomatisasi permainan, dan memilih API kami yang tidak berdokumen.
Awalnya, game ini dikembangkan dengan gagasan bahwa kami saat ini sedang melakukan browser, di dalamnya kami menguji mekanik, keseimbangan, dan kemudian dengan cepat, berkat API yang tertanam, kami mengumpulkan aplikasi asli. Realitas telah membuat penyesuaian.
Tidak ada waktu atau anggaran yang tersisa untuk rencana hebat ini. Pada saat yang sama, hampir semua penerbit yang berbicara dengan kami terutama tertarik pada ponsel dan menawarkan untuk datang kepada mereka ketika kami memilikinya.
Itu perlu dikompromikan, karena di Cordova selama beberapa bulan kami mengumpulkan aplikasi iOS dan Android. Jelas bahwa mereka tidak standar (walaupun sangat layak), tetapi Anda bisa bermain dengan cukup nyaman. Dan adalah mungkin untuk menguji hipotesis "bagaimana hasilnya" secara tepat.
Masalah dengan App Store
Dengan Apple dan moderasi di App Store, saya harus sedikit bergulat. Pada awalnya ada perancangan dengan motivasi: “Anda adalah aplikasi web. "Perangkat Apple memiliki Safari, dan tinggal di dalamnya, jangan repot-repot." Tapi kami menang.
Kemudian, sayangnya, karena persyaratan Apple, saya harus mengubah nama mata uang permainan Bitcoin menjadi Webcoin. Dalam keadilan, mereka benar, mislid sangat mungkin. Meski bagi kami sensasinya tidak sama.
Adapun pelokalan, kami sepenuhnya siap untuk memulai pada audiensi berbahasa Inggris. Namun, lebih mudah dan lebih murah bagi kita untuk mengasah dan menguji pasar asli berbahasa Rusia kita. Karena itu, sejauh ini kami baru mulai di Rusia, tetapi dalam satu atau dua minggu kami berharap untuk kembali ke Bahasa Inggris terlebih dahulu.
Poin teknis
Bermigrasi dari Bereaksi dan Redux ke Vue dan Vuex
Saya mengerti bahwa sekarang kita menginjak es tipis dari kemungkinan holivar, oleh karena itu saya akan segera membuat reservasi bahwa kita tidak memaksakan sesuatu atau menyatakan sesuatu, kita dengan sadar setuju dengan "Anda hanya tidak tahu cara memasaknya." Ini hanya deskripsi jalan kami, alasan untuk pilihan dan pengalaman.
Revolusi pertama dalam proses pembuatan game, meskipun cukup lunak, adalah transisi dari React dan Redux ke Vue dan Vuex.
Kami di perusahaan mencoba mengembangkan semua produk dengan tumpukan teknologi yang kira-kira sama. Ini terutama masalah akumulasi keahlian, dan, dalam hal ini, transfer yang mudah antara tim pengembangan. Dasar untuk kita hari ini: NodeJS, React dan MongoDB.
Membuat game dengan banyak data dan koneksi pada awalnya bodoh di NoSQL. Akibatnya, berdarah selama seminggu kami semua bermigrasi ke sana, tetapi hal pertama yang pertama.
Mengapa separuh perubahan dari React ke Vue?
Munculnya desainer game baru mengubah mekanika game sentral, yang menyebabkan perubahan serius sebagian besar antarmuka dalam game. Mekanik baru dengan cepat prototipe pada Vue, kriteria untuk pilihan ini adalah ambang rendah untuk memasuki teknologi. Pada periode yang sama, kami muncul dan mulai memperkenalkan sistem vektor pertumbuhan lalu lintas, laba, dan energi. Sebelum itu, mereka hanya menulis data tepat waktu, tetapi tidak beroperasi pada tingkat perubahan mereka.
Awalnya, bersama dengan React, kami menggunakan Redux. Spread tumbuh sangat cepat - setiap aksi pengguna dengan situs web di dalam game menciptakan entri baru. Dengan demikian, seluruh cerita bermutasi dan getter diceritakan, dan mereka memiliki perhitungan lalu lintas dan laba yang rumit, sebagai hasilnya - semua ini sangat melambat. Tentu saja, Anda dapat mengambil MobX, mengulang logika perhitungan, tetapi saat ini bertepatan dengan perubahan serius dalam mekanika pusat, entah bagaimana tidak sebelumnya. Atau bintang-bintang bertepatan. Di mana mereka mencoba menyelesaikan masalah di Redux dengan menghubungkan beberapa pihak, di Vuex semuanya bekerja di luar kotak dan dibagi menjadi sejumlah submodul tanpa gerakan yang tidak perlu.
Gula sintaksis dan fleksibilitas Vue benar-benar "memukul" kita. Misalnya, sekarang, untuk memperbarui nilai dalam komponen secara teratur, kami bukannya menghitung properti
foo() { return bar + baz; }
tulis
foo() { return (this.oneTick, bar + baz); }
Sihir kecil disembunyikan di properti this.oneTick, yang reaktif dan diperbarui sekali setiap detik, menyebabkan komponen dirender jika hasil bilah ekspresi + baz berubah.
Migrasi basis data
Dari backend, kami memiliki satu migrasi kecil dan besar. Awalnya, proyek dilakukan pada MySQL. Karena cepat, hanya berpikir bahwa kami membutuhkan relay dan kesenangan lainnya. Setelah itu, kami menjadi sedikit lebih dewasa dan dengan tidak susah payah beralih ke PostgreSQL.
Lebih luas dan kompleks adalah perpindahan ke MongoDB. Keputusan itu karena skalabilitas yang mudah dan kinerja yang relatif lebih besar. Ada lebih banyak masalah selama langkah kedua, meskipun ada ORM. Tetapi pengaturan standar ReplicaSet dan AutoFailOver hanya membutuhkan waktu satu jam.
Beberapa kata tentang penerbit
Untuk memulainya, kami menunggu mereka. Sejauh ini, hanya Mail.Ru yang percaya pada kami. Terima kasih kolega untuk itu. Kami akan segera mengetahui bagaimana versi browser kami menjangkau pemirsa mereka.
Dalam buku dan podcast cerdas, mereka mengatakan bahwa penerbit harus datang ke suatu tempat di tengah jalan, dan tidak dalam tahap rilis. Kami melakukannya, mulai berbicara di muka, termasuk pergi ke DevGamm pada bulan November.
Apa yang kami harapkan:
"Ya, baiklah, ulangi ini dan ini, dan inilah kita dan keahlian kita!"
Apa yang kita dapatkan:
"Ini keren, sesuatu yang segar dan tidak standar, pengaturan yang menarik, tetapi bagaimana Anda memulai dan akan ada teknik monetisasi - ayo."
Secara umum, teori itu mengecewakan kita. Mencoba memahami mengapa ini terjadi, berikan jawaban: "Anda memiliki standar, jadi ini dia."
Sepenuh hati, saya akan mengatakan bahwa menurut saya tidak banyak yang tidak standar, tetapi mereka lebih tahu.
Secara umum, perwakilan dari game dev bereaksi terhadap kami secara positif. Dapat dilihat bahwa pasar bosan dengan "Kill the Dragon" dan "Conquer the Castle" berikutnya. Meskipun ini mungkin persepsi orang yang terdistorsi dari dalam.
Terakhir
Dengan jalan yang berduri dan bengkok, kami tiba di makan siang yang lembut. Ini bukan kasus ketika pemenang tidak dihakimi, dan itu belum bisa disebut sebagai kemenangan. Karena itu, kami menunggu di komentar untuk tanggapan dan pertanyaan Anda. Kami akan segera menanggapi semuanya!
Jika Anda siap menawarkan kerja sama, kami bahkan siap untuk mempertimbangkannya.