Kami mencari tahu dengan pimpinan teknis kami
Untuk proyek pendidikan Bank Rusia, kami telah membuat game web yang menarik "The Mystery of the Lost Piggy Bank " . Dia menarik perhatian anak-anak sekolah ke topik literasi keuangan, memperkenalkan istilah, mengajari mereka cara mengelola uang dengan bijak. Permainan ini disukai tidak hanya oleh anak-anak, tetapi juga oleh orang dewasa dari berbagai kota di Rusia - lebih dari 30.000 orang memainkannya.
Kami sudah lama meminta pimpinan teknis kami untuk memberi tahu kami tentang pengembangan game web. Dia tidak hanya memberi tahu, tetapi juga menulis artikel berapi-api tentang pengalaman kami dalam proyek ini, tentang kesulitan yang muncul, dan juga berbagi peretasan hidup dalam pengembangan game browser. Hasilnya adalah materi yang penuh kegunaan. Lanjutkan membaca.
Game web pada dasarnya berbeda dari game komputer biasa dan situs web biasa di browser. Dalam permainan biasa, semua sumber daya permainan tersedia secara offline, mesin permainan mengetahui informasi tentang prosesor, memori dan kartu video dari komputer. Situs biasa membutuhkan sedikit sumber daya komputer, dan jika terjadi masalah, Anda dapat memuat ulang laman tersebut.
Kami memiliki asumsi tentang fitur game browser - batasan signifikan pada ukuran RAM yang tersedia dan digunakan (misalnya, dinyatakan dalam TOR bahwa 1 GB RAM harus cukup untuk perangkat seluler), keseimbangan antara kualitas sumber daya game (gambar, tekstur, sprite, suara, video) dan kecepatan unduh mereka.
Ditambahkan ke ini adalah persyaratan dari klien - game harus berjalan dan bekerja di semua browser seluler dan desktop yang dinyatakan (termasuk IE 11), dengan karakteristik perangkat keras serendah mungkin. Persyaratan ini berawal dari fakta bahwa game seharusnya ditampilkan pada kesempatan apa pun yang nyaman, di perangkat apa pun yang ada - misalnya, di sekolah.
Bagaimana mesinnya dipilih
Kami sudah memiliki pengalaman dalam pengembangan game, jadi petunjuk untuk memilih mesin segera ditunjukkan:
- Phaser — /.
- Unity Web — .
- LibGDX, Godot, PlayCanvas.
Pilihan yang tidak diketahui jatuh karena alasan yang jelas - mereka harus dikuasai dan dipelajari, yang, dalam beberapa hal, menakutkan, meskipun tampaknya tidak mustahil. Opsi Unity tidak berfungsi karena mesin dan pembatasan ekspor tidak memungkinkan, misalnya, menggunakan audio di IE 11. Dan juga karena Javascript yang diekspor dari Unity sangat besar, dan IE 11 jauh lebih lambat dalam penguraian dan eksekusi kode daripada yang modern. browser.
Jadi, diputuskan untuk mengambil versi baru dari mesin Phaser (pada saat pengembangan, itu adalah versi Phaser 3.11). Kami memilih mesin ini juga karena semua logika dan rendering adalah perangkat lunak, yang berarti bahwa kami benar-benar dapat mengontrol aspek apa pun dari game yang akan datang dalam kode.
Saat mereka menulis
Pada awalnya, kami tidak memiliki mekanisme yang rumit, tetapi kami tahu bahwa ini pasti akan menjadi platformer. Oleh karena itu, kami memutuskan untuk mengumpulkan setidaknya beberapa prototipe untuk menyegarkan pengetahuan kami tentang mesin, serta untuk membuat perkiraan pengukuran sumber daya yang dikonsumsi dan beban pada browser.
Kami mengambil dari contoh "gerakan karakter" dan "peta ubin" yang siap dalam dokumentasi, dirakit, diluncurkan - berfungsi: karakter berjalan, melompat, bergerak di platform. Diluncurkan di semua perangkat yang tersedia - masih berfungsi. Menambahkan tombol kontrol virtual dari contoh "tombol virtual" dan diluncurkan di seluler - masih berfungsi. Menambahkan sedikit mekanik - memukul, musuh, menangani dan menerima kerusakan, mengumpulkan koin - sudah cukup untuk prototipe.
Dalam prototipe, ada sedikit lebih dari yang diperlukan. Misalnya, mekanisme pengendalian dua karakter diterapkan, di antaranya Anda dapat beralih kapan saja.
Setelah prototipe berhasil, kami memiliki pemahaman tentang bagaimana arsitektur akan diimplementasikan dan kode diatur. Jika kita berbicara tentang bagian infrastruktur, maka ini bekerja dengan mesin dalam hal memuat sumber daya, membuat objek game, beralih layar. Adapun logika permainan itu sendiri, ini adalah implementasi karakter, implementasi mekanisme interaksi dengan mangsa, jebakan, musuh.
Tumpukan pengembangan diambil cukup umum untuk proyek serupa - webpack, webpack-dev-server, babel, babel / preset-typescript.
Kesulitan apa itu
Kesulitan ditemui dalam memenuhi persyaratan kinerja dan komunikasi tim. Saya harus bekerja dengan alat baru dan mentransfer materi satu sama lain dalam format baru, jadi tidak selalu semuanya berjalan lancar saat pertama kali.
Misalnya, telah ditetapkan dalam TOR bahwa game mencoba menentukan kinerja perangkat saat memulai, dan pemberitahuan terkait ditampilkan jika kinerja rendah. Pada tahap ini, kita dihadapkan pada dua masalah. Pertama, browser praktis tidak memberikan informasi apa pun tentang masalah ini. Kedua, kinerja tab browser tertentu pada titik waktu tertentu sangat bergantung pada faktor eksternal - berapa banyak tab yang terbuka, apakah ada situs berat di tab lain, apakah browser diminimalkan.
Beberapa hipotesis teoritis dan praktis diuji, dari mana solusi akhir lahir. Solusinya adalah sebagai berikut:
- Pada layar pemuatan game, di mana ada kemajuan dari 0 hingga 100%, pemuatan sumber daya sebenarnya berakhir pada 92%.
- Setelah itu, sebuah adegan dibuat di luar layar, di mana animasi berat dan sedikit efek fisika ditempatkan.
- Kemudian, dalam 5 detik, waktu rendering rata-rata untuk satu frame diukur.
- Setelah itu, keputusan dibuat tentang kinerja perangkat dan kemajuannya mencapai 100%.
Sangat penting adalah persyaratan agar game berfungsi penuh di IE 11, yang juga menyebabkan ketidaknyamanan. Ternyata dengan alat pengembang yang berjalan, eksekusi Javascript yang sudah lambat di browser ini semakin melambat.
Artinya, Anda dihadapkan pada rem dalam permainan, Anda membuka alat pengembang untuk menemukan alasannya, dan permainan semakin melambat.
Mekanika game
Mekanika gimnya sendiri tidak rumit, sebagian besar terinspirasi oleh gim yang sudah ada.
Karakter utama, misalnya, adalah sprite animasi satu bagian dengan senjata. Solusi ini dipilih untuk menghindari ketidaksesuaian antara animasi ayunan dan senjata. Oleh karena itu, kerusakan yang ditimbulkan diperiksa sebagai berikut - pada saat bingkai tertentu dari animasi tumbukan (bingkai dari perkiraan ketiga), kami menghitung luas persimpangan, yang berlaku untuk beberapa bingkai animasi lainnya. Beginilah cara kami berhasil mencapai operasi senjata yang realistis.
Kelemahan dari keputusan dalam animasi karakter utama ini adalah bahwa untuk setiap jenis kelamin di setiap level, Anda memerlukan satu set animasi yang disiapkan terpisah dengan senjata. Dan pada tingkat kedua, satu set tambahan diperlukan - dengan sepatu kets kredit. Secara total, kami mendapat empat set animasi lengkap untuk setiap karakter.
Hal lucu lainnya di sini adalah ketika Anda memilih senjata untuk pertempuran terakhir, Anda sebenarnya memilih seluruh karakter dari level yang sesuai. Jadi, semua pahlawan dengan pedang akan memakai sepatu kets biasa.
Mekanisme menangkap kunci dari peti itu menarik. Untuk kunci yang perlu ditangkap, area pemicu dibuat lebih kecil dari visual sprite kunci, dan juga sedikit bergeser ke samping secara acak. Hal ini menyebabkan efek yang diinginkan "kunci saya tidak akan dirakit pertama kali" - terkadang Anda perlu mencoba mengumpulkan kunci beberapa kali untuk mencapai area penggeraknya. Jika tidak, itu terlalu mudah, meskipun pada pelepasan terakhir, area pemicu sedikit ditingkatkan untuk mengurangi persentase upaya yang tidak berhasil.
Semua mekanisme lainnya sebenarnya sama - memicu pendekatan dan perpotongan karakter dan objek game pada titik waktu dan animasi tertentu.
Mekanika Dragon of Insurance, penerbangan di atas jurang dan pertempuran terakhir sedikit lebih rumit. Tekniknya sama, tetapi jeda dan ketidakaktifan juga diatur untuk mereproduksi animasi karakter lain saat ini.
Kesimpulan dan saran
Tentukan genre sejak awal.
Game di web adalah fenomena nyata, dengan pemirsanya sendiri dan aturannya sendiri. Permainan semacam itu tidak memerlukan instalasi, mereka memungkinkan Anda mengatur sesi permainan singkat, mereka menarik lebih banyak mekanik daripada penampilan.
Tip - perlakukan pengembangan game web seperti game nyata, bukan hanya "skrip di halaman" lainnya. Uji, buat profil, dan hindari kebocoran memori dan overhead CPU. Pemain dan baterai perangkat mereka akan senang.