Sejarah partisipasi dalam Game Jam. Snowbox

Pada akhir 2017, saya memiliki kesempatan untuk menguji kekuatan dan antusiasme saya sebagai peserta di salah satu dari banyak Game Jams dunia.

Karena ini adalah pengalaman pertama saya dalam proyek seperti itu, saya belajar beberapa pelajaran yang berguna dan beberapa kejutan yang menyenangkan. Yah, saya juga punya mainan yang bisa saya mainkan dengan rekan-rekan saya di hari libur Jumat.

Di bawah kucing, deskripsi tentang seberapa intensif pengembangan selama 30 hari dan lambatnya 20 hari menunggu hasil.

Catatan: artikel ini bersifat naratif, dengan sedikit rincian teknis.

Prolog

Saya sudah lama ingin mencoba sendiri sebagai pengembang game, dan pada tahun terakhir keinginan ini menjadi semakin dan semakin mengganggu. Pada akhir tahun, saya memutuskan untuk mulai melakukan sesuatu - menghadiri pertemuan tentang pengembangan game, membaca buku, dan bahkan membuat prototipe kecil dari game.

Dan kemudian suatu hari, Selim, kolega saya, menawarkan diri untuk berpartisipasi dalam salah satu dari banyak Game Jam dan saya berpikir bahwa ini adalah kesempatan terbaik untuk belajar dapur permainan tanpa kewajiban jangka panjang. Ini bukan prototipe, tetapi belum Proyek yang sudah lama dimainkan. Selain itu, tenggat waktu yang ketat seringkali merupakan beberapa motivator terbaik. Dan kelebihan utama adalah bahwa bagaimanapun, output adalah sesuatu yang holistik dan lengkap, yang selalu menginspirasi pencapaian baru.

Jadi kami memutuskan untuk mengambil bagian. Dua pengembang java, sama sekali tidak memiliki pengalaman dalam pembuatan game. Tetapi kapan seseorang harus memulai?

Persiapan

Game Jam yang dipilih bersifat tematik, dan panitia harus mengumumkan topik tersebut secara ketat sebelum memulai pengembangan. Para kontestan diberi waktu 1 bulan untuk membuat game.

Kami mendaftar seminggu sebelum memulai dan, karena kurangnya topik, menghabiskan waktu untuk mengantisipasi dan tidak melakukan apa pun. Mungkin lebih baik menghabiskan waktu ini memilih genre dan mekanik game. Dan kemudian bungkus dengan gaya yang sesuai.

Pada jam X, panitia mengumumkan tema kontes - Kemunduran (kembali) dan hitung mundur dimulai.

Selim memiliki satu-satunya harapan untuk permainan - keberadaan server permainan dan tentu saja waktu nyata. Dia tertarik untuk mengetahui kelezatan dan kesulitan mengembangkan sisi server. Selain itu, permainan seharusnya sederhana, kalau tidak kita mungkin tidak punya waktu untuk menyelesaikannya.

Mengenai topik, pemikiran pada awalnya adalah tentang retro, atau tentang zaman prasejarah. Tema retro tidak menarik bagi saya, jadi saya mencoba untuk membuat sesuatu tentang dinosaurus atau orang kuno. Namun, saya tidak dapat menemukan sesuatu yang sederhana dan multi-pengguna pada topik ini.

Dan kemudian saya datang dengan ide untuk membuat permainan kotak pasir, dalam arti harfiah - referensi untuk hiburan anak-anak di pantai. Kami membangun istana, berlari dan melempar pasir ke musuh-musuh kami (saya harap tidak semua orang memiliki masa kanak-kanak yang sulit), tetapi orang tua yang tidak puas dihukum untuk ini. Semua ini dalam 2D ​​dengan tampilan atas.

Selim menganggap bahwa pasir terlalu kejam di mata dan menyarankan untuk mengganti pasir dengan salju dan kastil dengan benteng es. Pada opsi ini, kami berhenti. Untuk yang terbaik dari kemampuan dan waktu kami, kami dapat menambahkan fungsionalitas dan variasi baru.

Pengembangan. Minggu 1

Peran kami dalam proyek dibagi sendiri. Seperti yang saya katakan, Selim hanya tertarik pada pengembangan server. Dan saya tertarik mencoba pengembangan UI, karena, menurut saya, ini paling berbeda dari pengembangan aplikasi bisnis. Antarmuka game direncanakan web.


Pengembangan dimulai dengan pertemuan bersama pada hari libur. Dalam 2 jam pertama, saya mengambil sprite "sementara" dan menyadari seorang bocah berlari yang tahu cara melempar bola salju. Bisa saja ada gambaran "sudah / sudah menjadi", tetapi tidak memiliki makna apa pun - secara visual apa yang ada, kemudian tetap ada.

Memiliki UI yang berfungsi, tetap hanya untuk mempererat interaksi server. Karena itu, sisa hari itu ditujukan untuk integrasi: diskusi tentang API, mengatur koneksi, implementasi interaksi. Pada akhir hari, pria kecil kami dapat memindahkan 1 piksel ke samping, dengan menekan tombol. Itu sederhana, tetapi masih berhasil.

Pengembangan lebih lanjut hanya berlanjut di waktu luang dari pekerjaan, dengan 6 hari seminggu secara terpisah untuk rumah, dan satu hari libur bersama. Ini cukup berkat API sederhana dan distribusi peran yang kaku.

Untuk mengulangi kesuksesan hari pertama (berlari dan melempar bola salju), tetapi sudah melalui server, kami butuh seminggu. Ini sama-sama dipengaruhi oleh banyak faktor teknis, termasuk masalah dengan alat yang tidak dirancang dengan baik untuk model interaksi klien-server kami. Saya ingin membahas model ini secara lebih rinci.

Model Interaksi Klien-Server

Awalnya, diputuskan bahwa server akan bertanggung jawab atas gerakan apa pun, dan klien hanya akan mengirim perintah, seperti menekan tombol, dan menggambar apa yang datang dari server. Kemudian, filosofi ini sedikit dimodifikasi, tetapi server sampai akhir tetap menjadi tautan utama.

Dalam implementasi pertama, server mengirim pembaruan ke klien setiap centang. Yaitu misalnya, jika tombol ditekan, maka posisi pemain berubah setiap beberapa milidetik dan posisi baru dikirim ke klien.

Dengan menggunakan algoritma sederhana seperti itu, kami menerapkan gerakan pemain. Tetapi berjuang untuk yang terbaik mendorong kami untuk mengubah algoritme menjadi peristiwa satu: hanya peristiwa penting yang cukup untuk sinkronisasi dikirim ke server, serta ke klien.

Misalnya, untuk memindahkan pemain ke peta Anda memerlukan 4 acara:

1. Klien : tombol atas ditekan;
2. Server : pemain mulai bergerak dari titik [x, y1 ], pada sudut α, dengan kecepatan ν;
3. Klien : tombol atas ditekan;
4. Server : pemain telah selesai bergerak di titik [x, y2 ].

Pendekatan ini memiliki pro dan kontra.

Cons

• lebih banyak logika pada klien: klien itu sendiri harus menghitung pergerakan, tabrakan, dll.
• logika pada klien harus mengulangi logika pada server dengan sangat akurat, jika tidak, lompatan dalam pergerakan objek diperoleh. Selanjutnya dalam artikel akan ada beberapa contoh tentang hal ini;
• dalam hal terjadi masalah jaringan, menerima peristiwa di kemudian hari dapat menyebabkan kondisi yang salah (keluar dari batas, melewati objek, dll.);
• secara umum, jauh lebih mudah untuk mendapatkan keadaan tidak sinkron di server dan klien.

Pro

• beban jauh lebih sedikit pada I / O;
• logika tambahan dapat digantung pada acara. Misalnya, di awal / akhir gerakan, Anda dapat memulai / menghentikan animasi;
• masalah jaringan kurang mempengaruhi kelancaran gerakan. Saat bola salju melayang, penundaan bahkan satu detik tidak akan memengaruhi apa pun, karena server tidak boleh mengirim apa pun;
• API dan interaksinya sendiri menjadi lebih transparan.

Dari daftar ini jelas bahwa jika Anda bekerja keras dalam implementasi klien, maka ada hampir satu nilai tambah. Untuk proyek kami, kami berhasil mencapai ini dan interaksi klien-server bekerja dengan sempurna. Tapi kita harus membayar upeti, butuh kekuatan dan saraf yang cukup banyak.

Pengembangan. Minggu 2 dan 3

Seminggu kemudian, ketika kami berhasil menguasai integrasi paling tidak dan membuat dukungan untuk beberapa jenis pesan antara server dan klien, sudah waktunya untuk menambahkan lebih banyak ke permainan daripada sekadar anak yang berjalan.

Karena itu, kami memutuskan untuk menambahkan gadis yang sedang berlari! Sepanjang jalan, untuk gadis itu aku harus membuat jendela pemilihan karakter. Dan karena jendela masih harus dilakukan, itu dosa untuk tidak menambahkan nama juga. Selain itu, saya harus meregangkan gambar, mirip dengan pendekatan 9-patch .


Itu terlihat seperti versi pertama dari jendela login

Karena semua ini, tugas yang begitu sederhana dan penting untuk menambahkan seorang gadis memerlukan beberapa malam, tapi itu jelas sepadan. Dan kemudian muncullah kehidupan sehari-hari kelabu dengan tugas yang sama: fungsi sederhana baru, perbaikan bug, perbaikan visual kecil.

Saat kemajuan saya berkembang di sisi klien, masalah kecepatan pengembangan server yang tidak merata dan UI muncul. Dan karena server adalah bagian utama dari interaksi apa pun, tanpa fungsi yang selesai dan berfungsi pada server, pengembangan klien telah terhenti.

Oleh karena itu, saya menerapkan server mock sederhana langsung di klien. Banyak hal di dalamnya dilaksanakan dengan sangat canggung, termasuk melalui penggunaan kondisi global dunia game. Ini cukup untuk mengembangkan UI yang sepenuhnya independen dari server dan menyelamatkan saya banyak waktu.

Server tiruan memiliki nilai tambah pasti lainnya. Ada bot di dalamnya yang tidak tahu cara menembak, jadi ada kesempatan setidaknya bagi seseorang untuk menang.

Pada saat yang sama, Selim berjuang dengan server. Di server, ia menghubungkan mesin fisika box2d untuk mensimulasikan fisika dalam permainan. Mesin ini memiliki banyak nuansa, dan studi mereka membutuhkan banyak waktu. Kesulitan terbesar dalam pengembangan adalah kurangnya visualisasi dunia game. Klien kami hanya memberikan apa yang dibutuhkan. Dan beberapa elemen "dunia server" disembunyikan dari sisi klien. Selain itu, tidak ada jaminan penuh bahwa klien membuat semuanya dengan benar.

Salah satu sub-tugas penting yang harus diselesaikan Selim adalah memeriksa tabrakan objek. Pada klien, tumbukan diperiksa hanya untuk elemen tetap. Di server, itu perlu untuk melakukan segalanya dengan jujur ​​agar tidak melanggar hak benda bergerak.

Selama pengembangan tabrakan, saya ingat satu bug lucu yang bisa berpura-pura fungsi khusus: ketika seorang pemain melempar bola salju, itu dilemparkan kembali dengan "kickback". Ini terjadi karena dalam box2d, secara default, semua orang bisa bertabrakan dengan semua orang, dan tolakan selalu terjadi.

Masalah ini diselesaikan dengan memperkenalkan topeng, yaitu, dengan menentukan kelas objek yang tidak dapat saling bertabrakan. Misalnya, untuk pemain dan bola salju, topengnya dibuat sama.

Selim memutuskan untuk tidak membuang waktu dalam penanganan tabrakan bola salju satu sama lain dan berkomentar tentang tabrakan tersebut:

// for the unlikely event that we collide with a sibling snowball

Seperti yang telah ditunjukkan oleh praktik, frekuensi peristiwa "tidak mungkin" ini cenderung pada frekuensi lemparan bola salju, karena ketika Anda berdiri berhadapan satu sama lain, lintasan bola salju bertepatan. Karena itu, bola salju alien terus-menerus menghantam bola mereka sendiri. Pendapat kami tentang perilaku ini berbeda, jadi kami membiarkannya apa adanya.

Sementara Selim bersenang-senang dengan tabrakan, saya debugged gerakan sinkron objek di server dan klien. Ada bug kecil dalam implementasi kami sendiri, tetapi Phaser menyajikan kejutan terbesar. Dalam mesin fisika-nya, kecepatan benda yang sebenarnya disesuaikan dengan FPS dan menghentikan dunia. Ini dilakukan untuk meningkatkan kehalusan. Sayangnya, perilaku pintar ini tidak konsisten dengan operasi sinkron sehubungan dengan server, dan saya harus membuat implementasi sendiri dari objek yang bergerak.


Dengan lelucon dan lelucon seperti itu, kami diam-diam melewati minggu kedua dan ketiga. Terlebih lagi, setiap minggu dimulai dengan frasa "yah, minggu depan kita wajib menyiapkan versi yang bisa dimainkan" - setiap kali kita merasa kita siap. Kurangnya pengalaman dan kehadiran optimisme yang luar biasa adalah cara terburuk untuk menilai kerangka waktu.

Seminggu sebelum pengiriman, pada pertemuan pengembang, kami bahkan tidak dapat menampilkan versi normal dan harus menunjukkan server tiruan.

Tentu saja, dengan kecepatan pengembangan seperti itu, tidak ada yang perlu diimpikan tentang daftar fungsi yang awalnya disusun, dan bahkan lebih baik untuk memiliki sesuatu. Karena itu, kami harus melupakan "kotak pasir" dan berhenti di penembak 2D paling sederhana.

Pengembangan. Minggu 4, terakhir

Dalam minggu terakhir pengembangan, kami fokus memperbaiki bug. Lebih baik memiliki sesuatu yang sederhana dan berfungsi daripada multi-fungsional, tetapi berantakan. Ada banyak masalah, dan kebanyakan dari mereka menyangkut integrasi naas. Di sana-sini, cacat kecil muncul, sangat memperburuk kesan permainan.

Selain memperbaiki bug, saya juga membawa gloss akhir ke UI: menambahkan musik dan suara, bermain dengan font dan meningkatkan detail kecil.

Dari semua fungsionalitas, minggu ini hanya sistem poin ditambahkan, serta keterbatasan stok bola salju dan pemulihannya.

Di hari terakhir Game Jam, kami bisa bermain sedikit dengan rekan-rekan. Meskipun ulasan positif secara umum, sesi permainan ini tidak berhasil karena bug kritis - bola salju terbang di server dan pada klien dengan kecepatan yang berbeda. Karena itu, masuk ke pemain lain lebih mungkin kecelakaan.


Jadi, senang dari bug tertutup dan mainan yang berfungsi, 2 jam sebelum batas waktu, kami siap untuk menyerah. Tinggal mengirim game ke situs web proyek.

Saya berharap bahwa mematikan permainan akan berjalan lancar, dan sia-sia. Itu perlu untuk membuat halaman proyek, membuat deskripsi, mengunggah tangkapan layar dan banyak lagi. Kami bertemu, seperti yang diharapkan, ujung ke ujung. Meskipun kemudian penyelenggara masih secara individual menerima proyek terlambat.


Cuplikan layar versi final game

Voting

Menurut ketentuan kompetisi, segera setelah selesainya pembangunan, pemungutan suara 20 hari dibuka. Selama periode ini, siapa pun dapat melihat proyek yang diselesaikan, yang lebih dari 200 diakumulasikan. Hanya peserta yang diizinkan memilih proyek tersebut. Setiap game dapat dinilai dalam kategori berikut: umum, grafik, suara, gameplay, inovasi dan relevansi dengan tema.

Tahap pemungutan suara telah menyiapkan kejutan mengejutkan bagi kami terkait dengan sifat multi-pemain dalam game kami. Ada relatif sedikit orang yang menonton pertandingan dan kesempatan untuk bertemu musuh cenderung nol. Yaitu orang-orang pergi ke kartu kosong, melemparkan beberapa bola salju, berlari beberapa meter dan pergi dengan kecewa.

Kami mencoba mengatur sesi permainan melalui forum proyek. Juga, Selim dan aku secara berkala memasuki permainan, berharap untuk menghibur pengembara yang bosan dan kesepian. Ini semua menghasilkan hampir tidak ada hasil.

Saya tertarik menonton beberapa orang menguji permainan. Saya terutama ingat kasus ketika seorang pemain memasukkan beberapa karakter pada saat yang sama dan membangun pentagram anak laki-laki. Saya tidak tahu apa yang ingin penulis katakan, tetapi saya masih memiliki tangkapan layar dari proses pembuatannya.



Pemain lain "meretas" game kami. Kami memiliki pemeriksaan panjang nama, tetapi hanya di sisi klien. Oleh karena itu, dia menghindari pertahanan ini dan mulai berkorespondensi dengan saya dengan cara ini, setiap kali memasukkan karakter baru, dan memasukkan frasa atas nama seorang pria.

Seiring dengan pemungutan suara, saya dan kolega saya bermain lagi, membalas dendam untuk permainan yang gagal pada hari proyek selesai. Kali ini semuanya berjalan sangat lancar dan kami mendapat sejumlah ide untuk fungsi-fungsi baru, yang, bagaimanapun, sudah terlambat untuk ditambahkan.

Menurut pendapat saya, kualitas permainan, terutama mengenai interaksi dengan server, ternyata pada tingkat yang sangat baik. Berapa kali kami memainkannya, kami tidak melihat adanya masalah, kami juga tidak mendengarnya dari pemain lain. Bagi saya pribadi, ini mengejutkan, mengingat kualitas dan jumlah kesalahan beberapa hari sebelum pengiriman.

20 hari yang diberikan untuk evaluasi permainan berlangsung sangat lama, tetapi pada akhirnya mereka berakhir dan waktu yang lama ditunggu-tunggu hasilnya datang.



Dengan demikian, kami mengambil tempat ke-36 dari sedikit lebih dari 200 peserta. Yang, di satu sisi, tidak buruk untuk proyek pertama, tetapi di sisi lain, agak tidak menyenangkan untuk kesombongan. Terutama mengingat bahwa 10 besar mendapat game bagus, tetapi tidak semuanya layak mendapat perhatian khusus.

Pelajaran yang dipetik

Demi mendapatkan pelajaran dalam kondisi semi-rumah kaca, ini semua dimulai. Kami mencoba untuk menemukan banyak hal sendiri dan membatasi diri pada serangkaian alat minimal untuk merasakan masalah dan mengalami pendekatan buruk di kulit kita sendiri. Tetapi sekarang memiliki pengetahuan tentang bagaimana melakukannya dan mengapa, mempelajari teori itu akan lebih mudah.

Kebutuhan akan seorang seniman . Seperti yang telah ditunjukkan oleh latihan (bukan hanya milik kami), Anda dapat membuat game yang bagus tanpa grafis yang bagus. Namun, memilih gambar, font, dan elemen antarmuka pengguna yang tepat membutuhkan sebagian besar waktu. Dan yang terburuk adalah bahwa pada akhirnya mereka tidak bertepatan. Dari sini, atmosfer tabung hangat hilang dan permainan tidak terlihat holistik.

Tes permainan sangat penting . Karena masalah dengan kecepatan pengembangan, kami hampir tidak bisa menguji kemampuan implementasi kami. Ketika kami bisa bermain dengan normal, terlalu sedikit waktu untuk memperbaiki area yang bermasalah. Dan kami sangat beruntung tidak ada banyak masalah seperti itu.
Menurut pendapat saya, untuk permainan pengujian seperti itu pada pengguna nyata jauh lebih penting daripada untuk aplikasi bisnis, karena selain untuk kenyamanan dan menyelesaikan masalah pengguna, masih diperlukan untuk mempertahankan tingkat emosi dan keterlibatan tertentu.

Tidak semua perpustakaan sama bermanfaatnya . Hampir tidak ada yang mengembangkan game di mesin mereka sendiri dan ada mesin di pasar untuk semua kesempatan. Di halaman itu tahun 2017, dan orang akan mengharapkan kualitas tinggi mereka. Saya memilih Phaser sebagai salah satu mesin JS termuda dan paling direkomendasikan. Setelah semua masalah yang kami alami dengannya, saya takut membayangkan bagaimana mesin terlihat lebih buruk. Tidak, secara umum, kesan bekerja dengan Phaser agak positif, terutama mengingat dokumentasi dan contoh yang baik. Tetapi bekerja dengannya tanpa mengetahui banyak nuansa sangat sulit. Pada musim semi versi baru keluar dan saya berharap untuk peningkatan yang signifikan. Dan juga dalam rencana saya adalah proyek mini pada beberapa mesin lain untuk membandingkan.
Dan saya akan mengingat masalah itu dengan kecepatan maksimum di box2d untuk waktu yang lama.

Dalam proses Game Jam sangat mungkin untuk belajar . Memulai proyek ini, kami hampir tidak tahu apa-apa tentang pengembangan game, atau tentang perpustakaan yang kami gunakan. Dan sebagian besar waktu dihabiskan untuk mempelajari hal-hal ini. Meskipun demikian, kami masih berhasil membawa permainan ke kondisi lengkap.

Tidak banyak fungsi yang dibutuhkan . Saya sedikit terkejut bahwa banyak orang menyukai permainan kami. Ya, mereka tidak duduk di dalamnya setiap malam, tetapi menikmati satu atau dua sesi kecil. Namun dalam permainan kami, tidak ada ide orisinal, atau fungsionalitas dalam jumlah besar, atau sejarah. Hal yang sama dapat dikatakan untuk sebagian besar game di Game Jam yang telah menerima peringkat positif.

(Game) Jam adalah alasan yang bagus untuk mencoba . Tidak masalah apa pun: ide, perpustakaan baru, kekuatan Anda sendiri. Ketika ada tujuan yang jelas dan orang lain harus melihat hasil Anda, sangat memotivasi untuk tidak menjadi lemas dan memberikan yang terbaik. Dan bahkan jika hasilnya lebih buruk dari yang diharapkan, tidak akan sayang untuk membuangnya, belajar pelajaran untuk diri sendiri dan bergerak maju!

Tautan ke sumber daya:

• selim.co/snowbox - game itu sendiri. Kami tidak mendorongnya ke stress testing, jadi saya jauh dari yakin bahwa itu akan menahan semua pendatang. Jika server berbohong, Anda dapat mencoba mock - selim.co/snowbox/#mock
• github.com/wowselim/gameserver - repositori kode server
• github.com/bugy/snowbox-ui - repositori klien
• itch.io/jam/game-off-2017 - halaman Game Jam
• itch.io/jam/game-off-2017/rate/199650 - halaman pemilihan game
• opengameart.org - sumber utama sumber daya game
• freesound.org - suara game diambil dari sini

Terima kasih atas waktu dan suasana hati yang baik!