Tragicomedy in NaN bertindak: bagaimana kami membuat game di JS dan merilisnya di Steam

"Eka tidak terlihat," Anda berkata, "tidak ada permainan Anda di 100 teratas, jadi itu tidak aman." Hal yang sama juga benar. Namun seiring perkembangan tahun Protolife, kami telah memperoleh beberapa pengalaman yang dapat kami bagikan dengan igrodelov masa depan yang potensial. Veteran industri, saya khawatir, tidak akan menemukan sesuatu yang menarik untuk diri mereka sendiri. Tapi mungkin setidaknya bersenang-senang dari hati.

Game macam apa itu? Dan siapakah kita?

Kami adalah tim yang terdiri dari tiga orang ( GRAAL , A333 , icxon ), berdasarkan kehendak takdir yang disebut Volcanic Giraffe tanpa maksud apa pun. Kami bekerja bersama untuk waktu yang lama, kami bertiga berpartisipasi dalam Ludum Dare (kompetisi penulisan game akhir pekan), dan suatu kali memutuskan untuk membawa untuk merilis salah satu kerajinan kami yang disebut Protolife.

Singkatnya: ini adalah menara pertahanan yang tidak biasa, di mana Anda harus menjalankan kursor pahlawan dan membangun pertahanan balok terhadap biomassa merah yang terus tumbuh.

Dari komentar di draft artikel:
icxon : Anda harus menulis sedikit tentang gameplay terlebih dahulu. Dan kemudian beberapa tangkapan layar di mana lobak mengerti apa yang terjadi

Jika Anda melukis dengan lebih detail, maka apa yang ada dalam game:

1. Ada satu set level, di setiap level ada basis kami dan avatar kami - pembangun robot.
2. Sebagian dari level diisi dengan biomassa merah yang tumbuh yang memuntahkan berton-ton massa.
3. Gerombolan, tentu saja, lari ke pangkalan dan mencoba untuk menghancurkannya. Dan kami sedang membangun pertahanan dari menara dan kami tidak membiarkannya dilakukan.

"Tapi apa yang tidak biasa?" - kamu bertanya. Dan perbedaan utama dari sebagian besar menara pertahanan adalah sebagai berikut:

1. Kami mengontrol robot konstruksi langsung dari kunci, mis. Anda harus secara manual bergegas tentang level dan punya waktu untuk membangun / memperbaiki semuanya.
2. Yang bisa dilakukan robot adalah membangun dan membongkar balok biru. Satu blok semacam itu tidak ada gunanya, tetapi beberapa blok yang ditata menurut pola tertentu berubah menjadi struktur yang bermanfaat. Contoh templat:
   

• Pola 1: pistol sederhana
• Pola 2: dinding
• Pola 3: Pistol AA. di sini Anda harus menggunakan juga kristal kuning, yang sudah ditambang lebih sulit
• Templat 4: senapan mesin

Dan begitulah permainannya: kita berlari, membangun, mendapatkan jawaban, cepat memperbaikinya. Visualisasi langsung dari proses pengembangan game diperoleh.

Tapi permainan seperti itu tidak langsung berhasil. Kembali pada bulan April 2017, di Ludum Dare 38, tampak seperti ini:

Jika Anda tidak memperhatikan perbedaan dalam jadwal, maka tampaknya tidak banyak yang berubah. Sudah pada versi LD ada pembangun kursor, pembangunan menara dari blok dan konfrontasi dengan biomassa merah. Kami meninggalkannya karena berhasil dan orang-orang menyukainya.

Tetapi pada kenyataannya, banyak yang telah berubah di bawah tenda selain konsentrasi graphonium per piksel persegi. Sepanjang jalan setahun, kami harus membuat berbagai keputusan - gameplay, teknis, organisasi, dan bahkan pemasaran. Beberapa berhasil, beberapa tidak.

Saya ingin memberi tahu tentang keputusan seperti itu.

Saya akan segera melakukan pemesanan - mungkin akan ada beberapa artikel, karena Jika Anda mulai menggali, banyak material yang keluar. Di akhir artikel ini Anda akan menemukan survei singkat - topik mana yang paling menarik bagi Anda. Nah, tautan ke gim itu sendiri juga.

Kisah penciptaan yang membosankan.

Saya tidak berpikir bahwa ada orang yang benar-benar tertarik dengan bagaimana game itu dipikirkan, jadi saya akan menghapusnya di bawah spoiler.

Memilih game untuk implementasi penuh

Seperti yang sering terjadi, setelah kita semua memikirkan kita bertiga - tetapi apakah ini saatnya untuk mencoba membuat permainan penuh. Seringkali pada tahap ini beberapa konsep diambil dari kepala, "permainan impian", dan pekerjaan sedang dilakukan dengannya. Dan kemudian betapa beruntungnya menebak dengan keinginan penonton.

Tugas kami disederhanakan sedikit karena kehadiran "portofolio" kecil di Ludum Dare. Kami melihat bagaimana orang bereaksi terhadap permainan yang berbeda, dan kami dapat membandingkan. Protolife memiliki respons terbesar, dipuji karena orisinalitas dan untuk gameplay yang menarik - ini berada pada level nol grafis dan hanya 4 level!

Selain itu, gatal membantu kami membuat keputusan, di mana kami menerbitkan kerajinan kami. Ternyata, ada orang yang pergi ke gatal untuk bermain game web. Beberapa dari mereka menyukai genre menara pertahanan, dan 5-10 orang datang (dan masih masuk!) Untuk memainkan Protolife tua itu setiap hari .
^{Statistik panggilan sebelum rilis game di Steam}

Dapat dikatakan, ini adalah riset pemasaran pertama kami. Kami berpikir dan memutuskan bahwa “pertahanan menara non-standar” dapat menembak dengan baik. Tidak ada begitu banyak pertahanan Tower, banyak dari mereka mirip dengan dua tetes air, dan kita bisa cukup menonjol di antara mereka.

Ke depan, saya dapat mengatakan bahwa taktik itu membuahkan hasil.

Kiat yang Tidak Diminta # 1: Lebih Baik Jangan Bertingkah Blindly. "Permainan impian" yang ideal di kepala Anda mungkin tidak diperlukan bagi siapa pun. Jika Anda tidak berpartisipasi dalam semua jenis kemacetan, selalu masuk akal untuk membuat sketsa gameplay (!) Dan mengujinya pada diri sendiri, teman, dan kenalan.

Counter-Council: Jika Anda tidak takut bahwa setengah orang akan memainkan "permainan mimpi", lalu siapa yang peduli? Lakukan itu! Mungkin beruntung.

Mesin: Bukan solusi terbaik

Kami membuat versi di Ludum Dare di mesin Phaser.js . Kami mengetahuinya dengan baik, kami tahu javascript dengan baik, game web mendapatkan lebih banyak umpan balik, cukup mudah dan mudah dipelajari - dongeng, bukan mesin.

Dan kami menghadapi pertanyaan penting: mengganti mesin atau meninggalkan semuanya apa adanya?

Pertanyaannya rumit. Tak satu pun dari kami yang tahu atau mempelajari mesin lain pada saat itu. Menghabiskan waktu belajar adalah hal yang baik, tetapi itu mungkin untuk kehilangan semua antusiasme. Dan kemudian - apa yang harus diambil? Javascript - satu-satunya bahasa yang kita ketahui, untuk menggunakan mesin C ++ / Java / C # - berarti langsung kehilangan setengah dari pengembang. Dan mesin level Unity pada saat itu tampak terlalu rumit untuk "permainan 2D sederhana."

Dan kemudian: sudah ada game. Tetap memperbarui graphene, menyelesaikan level - dan itu saja. Bekerja selama beberapa bulan. Dan kemudian belajar, tulis ulang ...

Secara umum, kami memutuskan untuk menginap di Phaser.js. Lebih buruk lagi - kami memutuskan untuk tetap pada basis kode yang sama, yaitu Bangun game di atas prototipe Ludum Dare.

Dari komentar pada draft artikel
a333 : Maaf, saya tidak punya foto itu dengan kruk, bukan Menara Eiffel ”

Kiat Tidak Diminta # 2: Never Do That! Ini terutama berlaku untuk penggunaan kembali prototipe. Kode macet selalu ditulis dengan cepat dan kotor, tanpa memperhitungkan pengembangan di masa mendatang. Ada kruk, ada kruk, dan sekarang Anda mengerti bahwa Anda sedang menulis kode warisan segera, dan segera Anda mulai menderita karenanya. Prototipe harus dibaca dengan hati-hati, dan kemudian dibakar menjadi / dev / null dan ditulis ulang, hanya sudah penuh dan bersih.

Saran kontra: pertimbangkan, bagaimanapun, karakteristik psikologi. Itu terjadi bahwa penundaan dalam beberapa minggu sudah cukup untuk "menenangkan diri". Lebih baik membuat game dengan arsitektur yang buruk daripada tidak melakukannya sama sekali.

Dari komentar di draft artikel:
A333 : Saya sangat menyukai opsi ini. Sejauh yang saya tahu, ini adalah cara sebagian besar permainan dilakukan, karena waktu dan sekering memainkan peran kunci. Jika Anda memiliki kesempatan untuk menulis ulang semuanya dengan rapi di mesin baru - bagus, tetapi ini tidak selalu terjadi. Jangan takut untuk menulis cepat dan kotor, bangun prototipe awal, salin dan tempel potongan kode, dan lepaskan zabago ... * suara pukulan dan rintihan meredam *

Sebenarnya, apa masalahnya dengan Phaser.js?

• Mesinnya, seperti yang Anda duga, berbasis web. Tahu cara merilis game web di Steam? Itu benar, berikan dengan Chrome menggunakan nw.js atau Electron. Saya pikir kelemahan dari pendekatan ini tidak perlu dijelaskan.
  
• Kinerja javascript tentu cukup bagus, tetapi kode asli akan berjalan lebih cepat, dan Anda bisa menghemat pertandingan.
  
• Kontrol render sangat lemah. Phaser sendiri merender semuanya, dan melakukannya secara keseluruhan dengan cukup baik, tetapi kadang-kadang Anda ingin masuk ke proses atau melakukan sesuatu di webGL sendiri. Sayangnya, satu-satunya hal yang diperbolehkan Phaser adalah menerapkan fragmen shader ke layar secara keseluruhan atau beberapa sprite terpisah di layar, dan juga dalam jumlah sedang. Itu sama sekali tidak memungkinkan bekerja dengan vertex shader (dan memang bekerja dengan simpul), dan banyak keputusan dalam permainan dengan mereka akan jauh lebih mudah.
  
• Masalah dengan sejumlah besar sprite (objek aktif) di layar. Selain itu, "jumlah besar" adalah beberapa ribu, bukan jutaan. Dan "objek aktif" akan menjadi batu pembohong tanpa animasi. Untuk setiap centang, Phaser akan melalui semua objek dan melakukan sihir phaser khusus sendiri, menghapus waktu dari logika permainan.
  

Kami memecahkan banyak masalah ini di sepanjang jalan, beberapa tidak menyelesaikan sampai akhir. Sulit untuk menilai tanpa pengalaman dengan mesin lain, tetapi bagi saya sepertinya mesin lain akan memungkinkan untuk memproses ribuan objek permainan tanpa trik jahat. Namun, saya bisa saja salah.

Perang gaya

Apakah Anda masih ingat "desain asli" dari versi asli game?


Tentu saja, ia memiliki daya tarik tersendiri, tetapi itu tidak cocok untuk produk yang serius. Ya, dan artis kita baru saja kembali dari perjalanan bisnis, apa yang dia duduk diam?

Dia tidak duduk, setelah membuat beberapa sketsa desain yang mungkin. Sejarah telah memelihara dua kursi gaya, di antaranya kita harus membuat pilihan.

Kandidat 1: desain minimalis. Bahkan - "piksel" yang sama, hanya lebih simpatik. Semuanya cerah, kontras. Kelihatannya bagus, tapi, katakanlah, solid. Dalam arti bahwa permainan yang terlihat seperti ini akan terlihat bagus di ponsel atau VKontakte di suatu tempat antara tetris dan arkanoid. Tapi dengan cepat dan murah.


Kandidat 2: realistis, fantastis, kasar. Di sini Anda sudah dapat melihat cerita, konteks tertentu. Tanpa diduga, kontras bekerja tidak hanya dalam warna, tetapi juga dalam bentuk - bangunan kita lebih teratur dan persegi, bangunan musuh - bulat, bentuknya tidak beraturan.



Ini bukan untuk mengatakan bahwa kita ragu-ragu untuk waktu yang sangat lama. Kami membayangkan "tangkapan layar" mana yang ingin kami mainkan lebih banyak, dan kandidat pertama tidak memiliki kesempatan untuk bertahan hidup. Kami tidak tahu apa yang akan kami miliki untuk plot, di mana semua ini terjadi, apa yang terjadi - tetapi kami memilih opsi dua.

Tentu saja, tidak ada yang bisa dibandingkan, tetapi menurut saya ini adalah pilihan yang baik. Ya, kami akan menyelesaikan opsi pertama dengan lebih cepat, itu akan mengurangi tuntutan pada kinerja dan grafik, dan mungkin bahkan mungkin untuk porting ke ponsel.

Tapi kami ingin memainkan opsi kedua.

Jadi mikroorganisme dan cawan Petri digantikan oleh planet yang jauh, robot, dan organisme alien yang misterius.

Saran dangkal nomor 3 yang tidak diminta: lakukan apa yang ingin Anda mainkan sendiri.

Saran balasan: jika Anda memiliki 3 hipotek dan tidak ada pekerjaan lain, tidak ada yang akan menyalahkan Anda karena melakukan sesuatu yang laku, tetapi Anda ingin mencuci mata dan tangan Anda dengan sabun.

Meringkuk Biomassa, Mengintai Cacing

Saya menyebutkan kontras warna dan bentuk, dan jika Anda membandingkan sketsa itu dan versi final - kontrasnya semakin meningkat. Bandingkan - bujur sangkar bangunan kita, bangunan bundar musuh, dan kebulatan umum massa merah.


Ngomong-ngomong, massa merah, seperti hampir semua yang ada di game, di suatu tempat di dalam logika game cocok dengan grid dengan cara yang sama seperti blok. Tapi dia tampak kacau pada saat yang sama, seolah-olah dia terlepas dari jala.

Saya masih memiliki demo di mana saya mendebat penampilan biomassa. Semuanya diatur di sana sebagai berikut: "kotak" bersyarat diambil dan diisi dengan lingkaran dengan ukuran yang serekat mungkin. Di bawah ini adalah contoh pengisian seperti itu. Dalam permainan itu sendiri, isiannya lebih padat (dan karena itu lebih buruk dibaca).

Di antara lingkaran ada garis - koneksi. Jika biomassa perlu tumbuh menjadi beberapa sel, maka lingkaran yang sesuai dipilih yang berpotongan dengan sel yang diperlukan, dan pertumbuhan terjadi di dalamnya di sepanjang garis.


Inilah yang terlihat seperti bergerak:

Dari komentar di draft artikel:
icxon : pertama kali saya melihat demo ini, lol

Dalam gim itu sendiri, semuanya bekerja dengan cara yang persis sama, kecuali bahwa semua ukuran, warna, dan kecepatan disesuaikan oleh artis kami untuk terlihat lebih baik.


Oh, saya sepertinya lupa mengatakan dari mana tepatnya keputusan itu berasal, bagaimana tahapan diskusi, para kandidat tersapu ...

Tapi tidak, saya belum lupa. Tidak ada. Awalnya, kami merencanakan untuk melakukan semuanya seperti dalam versi LD, mis. pertumbuhan dengan kotak. Hanya satu malam saya bosan, dan saya membuat sketsa demo ini untuk berlatih. Dan mereka pergi. Jadi mereka melakukannya.

Kiat # 4 yang tidak diminta: rencana, rencana, tetapi jangan takut untuk mencoba sesuatu yang baru. Intuisi dapat memberi tahu Anda beberapa keputusan bagus.

Saran balasan: jika Anda telah menetapkan tanggal rilis dan menandatangani kontrak dengan penerbit - mungkin Anda tidak boleh bereksperimen.

Animasi biomassa

Dalam gif di atas, Anda dapat melihat animasi biomassa yang menganggur - bahkan saat istirahat, ia bernafas dengan intens, kuncup merah tampaknya membuka dan menutup kembali. Di dunia yang ideal, ini akan berupa sprite dengan animasi yang digambar dengan cermat oleh seniman, yang disusun dalam pola yang sama dengan lingkaran. Pada kenyataannya, ini akan menjadi ribuan objek game yang tidak bisa ditangani oleh Phaser.js. Dan ini sudah menjadi fakta yang terverifikasi - dalam versi dengan Ludum Dare saya sudah menemukan rem neraka ketika biomassa mengisi setidaknya setengah dari peta, dan bahkan tidak ada animasi iseng di sana.

Shader datang untuk menyelamatkan, yang berputar di sana pada GPU dan tidak mengambil prosesor. Lebih baik lagi, jika shader ini benar-benar sederhana - maka itu tidak akan memuat kartu video terlalu banyak.

Shader perlu entah bagaimana mengatakan apa dan bagaimana cara menggambarnya. Apa cara mentransfer informasi ke shader:

• Hardcode dalam kode shader itu sendiri. Dalam kasus kami, itu tidak cocok, tetapi secara umum kadang-kadang opsi ini juga masuk akal untuk dipertimbangkan.
  
• Melalui variabel seragam (ini adalah variabel yang sama untuk setiap piksel dalam gambar)
  
• Melalui berbagai variabel (variabel yang diinterpolasi antara dua simpul)
  
• Melalui tekstur (mengkodekan beberapa nilai dengan warna)
  

Metode 3 bisa bermanfaat bagi kita, tetapi dalam kasus Phaser.js tidak tersedia bagi kita. Anda tidak akan melewati banyak seragam (katakanlah, array semua lingkaran dengan jari-jari mereka tidak akan cocok dengan seragam - ada batasan). Teksturnya tetap.

Kuncinya adalah ini: Saya pertama menggambar satu negara (katakanlah, tunas tertutup) dengan warna biru:


Kemudian status kedua (kuncup terbuka) berwarna merah:


Jika Anda menambahkannya bersama-sama, Anda mendapatkan kekacauan ungu:


Shader, di sisi lain, melihat tekstur, melihat waktu saat ini, dan dengan periode tertentu menunjukkan kepada kita bahwa "biru", kemudian "merah", mengalir dengan lancar di antara mereka. Nah, dengan sendirinya menerapkan palet warna yang diinginkan. Ternyata seperti ini:

Dari komentar di draft artikel:
a333 : Ah begitulah b *** i f *** a berfungsi
icxon : ini keren karena saya masih tidak mengerti cara kerjanya

Sama, tetapi dengan contoh persegi panjang:

Tekstur:

Animasi terakhir:

Teksturnya diperbarui hanya ketika ia tumbuh / runtuh, sisa waktu hanya gpu-animasi bekerja.

Perawatan pemain

Dalam proses pengembangan, kami berusaha untuk tidak melupakan para pemain yang melihat permainan kami untuk pertama kalinya. Ini tidak sesederhana kelihatannya - setelah beberapa saat mata menjadi kabur, dan Anda mulai mempertimbangkan dengan jelas segala sesuatu yang Anda, sebagai pengembang, sudah tahu.

Kami memahami hal ini, dan uji beta pertama dilakukan 8 bulan sebelum rilis - segera setelah kami memiliki 10 level pertama dan 40-50% dari konten siap. Uji beta itu memberikan umpan balik desain tingkat luar biasa yang akan saya bicarakan di lain waktu. Pada saat yang sama, kami belajar bahwa kami sendiri memiliki beberapa prediksi yang bagus tentang beberapa hal.

Situasi: ada pangkalan pemain yang perlu dipertahankan - penghancurannya menyebabkan kegagalan misi. Pemain tidak terus-menerus memonitor pangkalan - ia menonton avatar robotnya. Dan dia terus-menerus memonitor - laju permainannya cukup cepat, tidak ada banyak waktu untuk berdiri dan merenung. Akibatnya, kami, penguji itu, terkadang tidak memperhatikan musuh yang ada di belakang, membom pangkalan.

Solusi: pertama, kami menunjukkan kerusakan pada pangkalan di lingkaran konsentris melalui setengah peta.


Kedua, jika pangkalan rusak secara signifikan, maka secara independen menyerang kembali, menyapu musuh, yang jelas terlihat dan disuarakan. Ini menarik perhatian pemain ke masalah dan memberi waktu untuk mengambil tindakan.


Situasi: seperti dalam pertahanan Menara yang khas, musuh mengikuti jalan yang dipukuli. Namun, rute ini tidak selalu dapat ditebak. Dan memahami rute sangat penting untuk pertahanan yang sukses: beberapa menara menembak sangat dekat, dan terlalu dekat menara akan dihancurkan oleh gelombang berikutnya.

Solusi: mengambil darah setelah membunuh musuh. Setelah beberapa saat, jejak yang jelas muncul di tanah, yang dapat Anda fokuskan:


Pertanyaan: tapi, sebenarnya, mengapa jalurnya terpukul? Apakah Anda tahu cara menerapkan A *?

Jawaban: diimplementasikan beberapa kali :) kami dengan jujur ​​bereksperimen dengan musuh AI. Kami memiliki cacing pintar yang mencari jalan, dan slimes menghindari peluru. Menjadi tidak mungkin dimainkan. Pemain tidak bisa membangun pertahanan yang efektif dan tidak bisa bahagia menyaksikan cara kerjanya. Kesenangan game anjlok. Ini tidak berarti bahwa musuh "pintar" itu jahat. Hanya untuk mekanik yang dipilih - ketika bangunan kita statis - musuh seperti itu tidak cocok. Untuk "musuh cerdas" Anda harus memasang senapan mesin ke robot, atau kaki ke menara. Dan ini adalah permainan yang sama sekali berbeda - bukan yang disukai orang di LD dan itchio.

Dari komentar di draft artikel:
icxon : Tapi masih ada slime. Dan mereka masih menghindari
GRAAL : pikirkan sedikit fiksi

^{Memang benar, tetapi mereka menghindar lebih malas daripada di versi aslinya}

Situasi: musuh memiliki senjata jarak jauh (mortir) yang bisa berada di luar jarak pandang pemain. Pada awalnya, hampir seluruh bidang tersembunyi di balik kabut perang, karena itu kedatangan kerang musuh dapat diketahui - mereka terbang keluar dari kegelapan dan segera menyebabkan kerusakan. Jika pemain melihat momen itu di arah yang berlawanan, dia mungkin tidak mengerti apa yang terjadi.

Solusi: proyektil terbang terlihat di atas kabut perang. Ini memberi pemain kesempatan untuk memperhatikan ancaman dan mengambil tindakan.


Berbicara tentang kerang. Mari mengalihkan perhatian dari masalah gameplay-UX.

Penanganan Tabrakan

Dalam versi LD objek bergerak tidak ada begitu banyak - selusin peluru dan selusin cacing pada waktu tertentu. Ini tidak cukup dalam permainan. Untuk merasakan tantangan, Anda harus meningkatkan jumlah lawan, dan pada saat yang sama memberikan pemain senjata api cepat untuk melawan. Jadi dalam permainan, situasi ini tidak jarang:


Untuk semua objek game, tabrakan harus dipertimbangkan. Peluru menabrak cacing, cacing menabrak blok, dan semuanya muncul di layar - terkadang beberapa ratus. Dan senjata harus memilih target mereka dalam jangkauan. Jika dalam versi LD kita bisa beralih dari semua musuh untuk mencari yang cocok, maka di sini sudah mulai melambat.

Secara umum, masalah ini memiliki solusi, pada habr saya sering bertemu artikel tentang hal ini (di sini adalah salah satunya ). Karena kami memiliki kotak logis di layar, dan sebagian besar objek aktif tidak melebihi ukuran sel permainan 2x2, kami memutuskan untuk menggunakan kotak ini untuk menentukan tabrakan.

Setiap sel memiliki daftar objek yang ada di dalam sel itu. Ada objek statis (seperti balok atau batu) yang menempati tepat satu sel secara keseluruhan dan tidak bergerak ke mana pun. Dan ada yang dinamis yang bergerak di sepanjang grid, "mengalir" dari satu sel ke sel lainnya.


Karena sebuah objek dapat ditemukan di suatu tempat di perbatasan dua sel (meskipun pusatnya jelas terletak di dalam hanya satu), maka ketika mempertimbangkan tabrakan, semua sel tetangga diperiksa. Yaitukita mengambil peluru dengan koordinat X, Y, dan lihat apa yang ada di dalam sel (X, Y), (X + 1, Y), (X-1, Y), (X, Y + 1), (X, Y -1). Jika ada benda-benda yang dapat berinteraksi dengan peluru, maka untuk masing-masingnya persis tabrakan dihitung berdasarkan bentuk dan ukurannya.

Agar tidak bangun dua kali, kisi yang sama digunakan untuk memilih target berdasarkan menara. Setelah pembuatan, menara "berlangganan" ke sel-sel kotak tertentu. Jika sesuatu yang dapat ditembak masuk ke dalam sangkar, menara menerima pemberitahuan (dan biasanya setelah itu menembak). Jadi, jika seribu musuh merayap jelas jauh dari menara, menara tidak akan membuang waktu untuk menghitung jarak ke mereka.


Jika peta besar, maka sel-sel di grid juga menjadi banyak, dan semua pembaruan dan pemeriksaan mulai memakan waktu lebih lama. Juga, masalah dimulai jika ada bangunan / unit ukuran beberapa sel - untuk mereka Anda harus memeriksa lebih banyak sel di sekitar.

Untuk meningkatkan level momen ini, kami menempatkan yang besar, berukuran 16x16 sel, di atas jaring halus. Semuanya dianggap sama untuknya, dan digunakan untuk dengan cepat menyaring situasi ketika tidak ada dalam radius beberapa sel di sekitar objek dan tabrakan tidak dapat diperiksa.

Tautan dan Survei yang Dijanjikan

Artikel itu ternyata sudah cukup lama, dan Tuhan melarang daftar topik saya di notebook berkurang seperempatnya. Katakan, apa yang ingin Anda dengar di artikel selanjutnya? Anda dapat memilih beberapa poin.

Nah, jika tiba-tiba ada pertanyaan spesifik tentang bagaimana hal itu dilakukan, atau mengapa itu dilakukan - tulis di komentar. Kami akan menjawab jika kami ingat :)

Tautan ke permainan:

• Protolife: versi dari Ludum Dare di itch.io (gratis).
  
• Protolife: versi rilis di Steam (dibayar, permisi).
  

Terima kasih atas perhatiannya.