Jika tidak memperhitungkan rilis untuk Android dan selusin proyek yang ditinggalkan sebelum mereka siap, maka ya, itu adalah game pertama kami yang sesuai untuk lebih dari satu platform. Bagaimana semuanya dimulai? Sangat sederhana. Kami mengerjakan proyek lain, sebut saja "proyek A", dan kami sudah lama mengerjakannya ketika kami memutuskan untuk membuat game selama beberapa bulan dan menggunakannya untuk melatih keterampilan pemasaran kami, dan kemudian segera lepaskan "proyek A" kami saat kami akan lebih berpengalaman dalam mempromosikan game. Tetapi rencana itu gagal dan “proyek A” tidak tersentuh sepanjang tahun. Tapi cerita ini bukan tentang "proyek A", ini tentang permainan logis yang disebut "Cubicity: Slide puzzle".
Draf pertama adalah sebagai berikut: grafis minimal, UI minimal, dan juga minimum segala sesuatu yang mungkin, permainan harus dalam gaya permainan kasual hari ini yang membanjiri pasar serta Match-3. Akibatnya, tujuan kami terlihat seperti ini: token bulat terhubung ke gambar, dipindahkan dengan gesekan 4 arah. Mereka yang telah memainkan Cubicity tahu bahwa kami belum sepenuhnya mengubah tugas tetapi dengan sangat meningkatkan aspek-aspek lain menjadi tim yang hanya terdiri dari dua orang.
Jika beberapa pembaca berharap menemukan rahasia pengembangan game yang sukses dan cepat di sini, maka tidak ada rahasia seperti itu. Di sini kami tidak berbagi pengalaman atau pengetahuan yang luas, kami hanya menceritakan kisah tentang satu proyek perusahaan kecil. Dan kita belum tahu, apakah itu berhasil atau tidak. Tetapi bagi banyak dari Anda, pembaca kami, ini adalah pesan dari masa lalu yang dikirim oleh pengembang.
Mari kita kembali ke sejarah tentang bagaimana Cubicity diciptakan. Terutama kami bekerja hanya dengan Unity dan di sini adalah set standar setiap pengembang Unity yang layak: Newtonsoft.json, Zenject, Cinemachine, Dotween dll. Seperti yang dapat dilihat pada gambar di atas, prototipe pertama dari permainan hanya menyertakan kubus dan keripik. Setelah seminggu memikirkan cara meningkatkan permainan dan menarik gamer, ada momen eureka ... Untuk mencari beberapa karakter kubik atau bundar di toko Aset. Maka beberapa paket karakter dibeli tanpa ragu-ragu. Situasi yang sama terjadi dengan blok di mana karakter bergerak sekarang. Juga daftar elemen gameplay baru ditulis dengan hampir 30 item baru yang darinya kami pertama-tama memilih hal-hal netral seperti blok / panah redirection, elevator dan teleport. Kami memutuskan untuk meninggalkan sisanya untuk level baru dan memperkenalkannya satu per satu di level 30-35.
Sejujurnya, kami bahkan tidak dapat mengingat apa yang menginspirasi kami untuk membuat begitu banyak level pada langkah pertama, tetapi kami memiliki apa yang kami miliki, dan rilis pertama termasuk 95 level. Terlalu banyak, untuk mengatakan yang sebenarnya, dan kami menyesalinya. Kenapa menyesal? Karena permainan tidak sepenuhnya siap dan banyak hal berubah setelah rilis. Sepertinya kami terjebak di Groundhog Day, karena kami perlu melakukan perubahan di setiap level dari 95. Dua bulan kerja terus-menerus dihabiskan di semua level. Tetap saja level-level itu belum 100% siap tetapi kami tidak jauh dari sana. Pada hari-hari paling produktif, 10 level dengan mudah dipindahkan dari kepala ke kertas dan kemudian ke tempat kejadian. Tetapi ada juga hari-hari ketika Anda merasa seperti Anda Hank Moody dari Californication, yang menderita blok penulis, dan Anda pikir Anda mencapai dasarnya, tetapi hari yang baru membawa ide-ide baru.
Mengenai komponen visual, itu sedikit lebih sulit. Menggambar seperti pada kebanyakan game dilakukan pada permukaan di luar layar dengan resolusi kurang dari asli dan mengaburkan ke permukaan utama, tetapi UI digambar tanpa perubahan resolusi untuk kejelasan dan keterbacaan yang lebih baik. Dengan demikian, kami mendapatkan yang terbaik dari dua dunia - bukan UI yang buram, dan bukan performa yang membuat performa dalam permainan. Setelah banyak percobaan kami memilih 2x MSAA + FXAA untuk antialiasing, karena mereka memberikan gambar terbaik dengan sumber daya paling sedikit. Kami cukup menyimpulkan, bahwa permainan logis tidak perlu 60 frame per detik, dan memutuskan untuk tidak menemukan kembali roda dan menetapkan batas bingkai ke 30fps (bahkan konsol biasanya melakukan ini). Mengatur batas bingkai memiliki efek positif tidak hanya pada konsumsi energi, tetapi juga pada pemanasan telepon, yang mencegah ponsel dari pelambatan karena terlalu panas.
Selanjutnya kami harus membuat keputusan yang sulit, dan itu adalah poin Selesai. Setiap kali level dimulai, karakter dipilih secara acak dari yang tersedia untuk pemain, itu sebabnya akan bermasalah untuk menggambar sosok miniatur beberapa karakter. Anda mungkin tidak percaya, tapi kami menghabiskan banyak waktu untuk menyelesaikan tugas ini setelah terus menunda-nunda pekerjaan itu. Kubus pada titik akhir tampaknya bukan ide yang mengerikan, dan melukis kertas membantu melewati level dan membawa semua orang ke tempat yang tepat. Kemudian diputuskan untuk menggunakan karakter yang sama, bukan kubus, tetapi dalam ukuran yang lebih kecil. Itu menjadi lebih baik, tetapi hanya untuk kita. Beberapa hari kemudian, karakter-karakter ini diputar dan disorot, dan itu menjadi jauh lebih jelas siapa, tetapi masih belum memuaskan. Versi final diadopsi sebulan kemudian, dengan coba-coba, dan setelah itu beberapa minggu dihabiskan untuk membuat ikon untuk selesai. Selamat tinggal musim panas, sampai jumpa lagi!
Menurut pendapat kami yang sederhana, awan ternyata tampak agak menyenangkan. Tetapi sebenarnya ini adalah hack yang paling sederhana. Ketika kami baru saja memutuskan untuk menambahkan cloud, pemikiran pertama adalah membuat video 360 latar belakang. Pendekatan ini gagal, karena untuk platform seluler diinginkan agar sesuai dengan permainan dalam batas ukuran untuk mengunduh melalui LTE. Jika kami ingin videonya tidak terlalu dikompresi, kami harus memberikannya 10-15 MB. Dikombinasikan dengan kehadiran level malam dalam game dengan cloud-nya, itu terlalu banyak (keseluruhan game Android terakhir membutuhkan 61 MB). Keinginan kedua adalah menulis sistem kami sendiri untuk awan. Itu menggoda bagi pengembang, tetapi bagi seseorang yang ingin menyelesaikan permainan sesegera mungkin itu tidak cocok. Solusinya datang dalam bentuk menciptakan tekstur untuk awan dan menciptakan sistem partikel dengan masa hidup partikel yang tak terbatas, dan juga jumlah partikel yang terbatas pada umumnya. Setelah itu, kami menambahkan ukuran acak antara dua konstanta bersama dengan rotasi acak. Hasilnya benar-benar memuaskan, langit kami penuh dengan awan yang cantik dan tidak membuat kami menangis melihatnya.
Bayangan dalam permainan (dalam versi seluler) seluruhnya terdiri dari paha depan yang hanya diatur dengan tangan, karena kami tidak ingin menambahkan bayangan nyata ke versi seluler. Salah satu alasannya adalah tidak adanya soft shadows pada platform mobile dengan OpenGLES 2.0, dan, tentu saja, penurunan kinerja pada perangkat yang lemah.
Seperti yang telah disebutkan sebelumnya, kami menggunakan 2x MSAA + FXAA untuk anti-aliasing, tapi bukan itu saja! Kami juga menambahkan AmplifyColor ke pemrosesan pos kami, karena ini merupakan aset besar untuk uang masuk akal yang memungkinkan Anda untuk menerapkan Lut-s yang berbeda pada pemrosesan pos. Lut yang dipilih dengan benar membuat gambar menjadi lebih baik. Selama proses pengembangan kami mencoba pendekatan yang berbeda, termasuk tumpukan pemrosesan pos kesatuan standar, tetapi dalam membangun shader dan opsi mengambil banyak. Beberapa solusi sangat indah, tetapi mereka bekerja sangat buruk pada ponsel yang tidak terlalu baru (percayalah, jika Anda berpikir bahwa setiap orang sekarang memiliki setidaknya ponsel 'normal', Anda salah. Banyak orang masih memiliki $ 40 ponsel China dan mengeluh kepada Anda di komentar bahwa DOOM Anda tidak berfungsi dengan baik pada sampah mereka).
Keseimbangan permainan selalu tidak mudah untuk dijangkau, dan bahkan sekarang kita kadang-kadang berpikir bahwa levelnya mungkin terlalu sulit, bahwa level sulit itu mungkin muncul terlalu sering dll. Setelah menyeimbangkan yang kami bisa, kami memutuskan untuk memperkenalkan alat untuk membuat hidup lebih mudah bagi pemain (Mundur, Bom, Blok Es, Teleport), dan ya, menjadi lebih mudah untuk hidup, tetapi tidak bagi kami, hanya untuk pemain masa depan. Jumlah pekerjaan dan bug meningkat untuk kami.
Kami sampai di menu permainan, dengan kekuatan kami memudar dan kembali tenang. Kreativitas menghantam rem. Terus terang, kami harus mendapatkan inspirasi dari game lain, dan kami berterima kasih banyak kepada mereka. Dan akhirnya kami berhasil, UI sudah siap pada layout sebelumnya.
Kami ingin menjadi modis juga. Jadi kami memutuskan untuk menambahkan penghematan pada penyimpanan cloud dan tidak menyesalinya. Tugas ini bukan yang termudah, karena pada platform yang berbeda ada penyedia penyimpanan cloud yang berbeda. Di Steam ada Steamworks, untuk seluler itu GooglePlay dan GameRoom. Jadi kami harus menyatukan sistem tabungan sehingga bisa diganti dengan platform yang diinginkan. Pada awalnya, kami memutuskan untuk menggunakan EasyMobile untuk tujuan ini, tetapi segera kami meninggalkan ide ini. Plugin ini cukup bagus dan memiliki banyak kemungkinan, tetapi kami tidak benar-benar suka bekerja dengan penyimpanan cloud asli. Akibatnya, kami memilih Firebase Realtime Database dan otentikasi Facebook. Singkatnya, kami harus melalui neraka untuk membuat semuanya berfungsi (dan ini bukan tentang pemrograman, melainkan sekitar 100500 pengaturan yang harus dilakukan di 100500 lokasi aplikasi dan di Facebook, Firebase dll.). Juga di basis data ada batasan lalu lintas dan untuk menyimpannya, setiap kali kita menulis, kita membuat GUID dan menuliskannya ke basis data dan di perangkat. Dengan demikian, jika kita melihat bahwa GUID pada perangkat dan dalam pencocokan cloud, kita dapat yakin bahwa kita tidak perlu membaca semua data dari cloud, tetapi kita dapat menggunakan salinan data lokal. Akibatnya, sinkronisasi ditambahkan, tetapi ... Salah satu bug paling aneh bagi kami adalah perilaku Firebase Database yang tidak terlihat dalam beberapa kasus. Karena kami menggunakan Json, kami membuat serial kelas untuk menyimpan status, tetapi Firebase terkadang berperilaku agak aneh.
Jika kita memasukkan objek kamus ke Firebase, misalnya:
var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 2, new SlotState() };
Ketika kita membacanya dari database, kita tidak akan mendapatkan objek Json, tetapi array dari Json (Apa?)
Baiklah, kita akan menggunakan daftar di mana-mana dan tidak akan memiliki masalah, bukan? Tetapi tampaknya itu tidak benar.
Jika kami menulis di Firebase:
var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 100500, new SlotState() };
Atau bahkan:
var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, null }, { 2, new SlotState() };
Ketika kita membacanya dari database, kita akan mendapatkan objek Json dengan kunci dan nilai.
Yah, logika pengembang dapat dipahami, tetapi dapat menyebabkan bug yang mungkin muncul setelah beberapa saat (Ingat GUID ditambahkan untuk menyimpan yang kami sebutkan di atas? Akibatnya, jarang membaca dari database dengan entri yang relatif sering ke sana) .
Kapan rilisnya? Pertanyaan ini paling sering didengar. Tetapi perlu dipersiapkan dengan baik untuk hari ini. Kami harus membuat daftar pasar, memilih tanggal rilis, menghindari penjualan besar, ada cukup banyak nuansa yang menunda rilis selama sekitar 2 bulan. Mengikuti saran dari satu artikel, kami memilih hari Selasa dan Rabu untuk rilis. Kami memutuskan untuk memesan ulasan pada 4pds, bercerita tentang permainan di beberapa forum dan mengiklankannya di jejaring sosial, khususnya di Instagram (tentu saja, dengan biaya tambahan). Apa yang berhasil dari semua ini, Anda akan mengetahui dari bagian kedua dari cerita ini, tetapi itu nanti.
Apa yang kita miliki pada akhirnya? Membuat game tidak selalu merupakan proses yang cepat. Dan mungkin saja waktu yang diharapkan untuk mengembangkan game harus dikalikan dengan 5. Dapatkan orang yang dapat membantu Anda dengan saran praktis di industri yang tidak dikenal. Bersantailah di setiap kesempatan, karena menciptakan sesuatu, bukan hanya permainan, membutuhkan banyak energi. Adalah tidak benar untuk menjadi dekat untuk melepaskan perasaan lelah dan menjadi kurang berguna daripada pada awal proyek. Dan uang, cari uang, Anda akan membutuhkannya. Dan dari kami, terima kasih atas perhatiannya, semoga sukses dan sampai jumpa di artikel selanjutnya.