10 Kesalahan Paling Umum Yang Dilakukan Pengembang Unity

Unity adalah alat yang hebat dan mudah digunakan untuk pengembangan multi-platform. Prinsip-prinsipnya mudah dipahami, dan Anda dapat secara intuitif mulai membuat produk Anda. Namun, jika beberapa hal tidak diperhatikan, hal itu akan memperlambat kemajuan Anda saat Anda melanjutkan pekerjaan ke tingkat berikutnya, saat Anda berpindah dari fase prototipe awal atau mendekati rilis final. Artikel ini akan memberikan saran tentang cara mengatasi masalah yang paling umum dan bagaimana menghindari kesalahan mendasar dalam proyek baru atau yang sudah ada. Harap dicatat, perspektif artikel ini lebih fokus pada pengembangan aplikasi 3D, tetapi semua yang disebutkan juga berlaku untuk pengembangan 2D.

Kesalahan Umum Kesatuan #1: Meremehkan Tahap Perencanaan Proyek

Untuk setiap proyek, sangat penting untuk menentukan beberapa hal sebelum desain aplikasi dan bagian pemrograman proyek dimulai. Saat ini, ketika pemasaran produk merupakan bagian penting dari keseluruhan proses, penting juga untuk memiliki gagasan yang jelas tentang model bisnis dari aplikasi yang akan diimplementasikan. Anda harus yakin untuk platform apa Anda akan merilis produk, dan platform apa yang ada dalam rencana Anda. Anda juga perlu mengatur spesifikasi perangkat minimal yang didukung (apakah Anda akan mendukung perangkat kelas bawah yang lebih lama atau hanya model yang lebih baru?) untuk mengetahui kinerja dan visual yang Anda mampu. Setiap topik dalam artikel ini dipengaruhi oleh fakta ini.

Dari sudut pandang yang lebih teknis, perlu untuk mengatur terlebih dahulu seluruh alur kerja pembuatan aset dan model sambil memberikannya kepada programmer, dengan perhatian khusus pada proses iterasi ketika model akan membutuhkan lebih banyak perubahan dan penyempurnaan. Anda harus memiliki gagasan yang jelas tentang frame rate dan anggaran vertex yang diinginkan, sehingga seniman 3D dapat mengetahui resolusi maksimal model yang harus dibuat, dan berapa banyak variasi LOD yang harus dia lakukan. Ini juga harus ditentukan bagaimana menyatukan semua pengukuran untuk memiliki skala yang konsisten, dan proses impor di seluruh aplikasi.

Cara mendesain level sangat penting untuk pekerjaan di masa mendatang karena pembagian level sangat memengaruhi kinerja. Masalah kinerja harus selalu ada dalam pikiran Anda saat merancang level baru. Jangan pergi dengan visi yang tidak realistis. Itu selalu penting untuk bertanya pada diri sendiri pertanyaan "dapatkah itu dicapai secara wajar?" Jika tidak, Anda tidak boleh menyia-nyiakan sumber daya berharga Anda untuk sesuatu yang sulit dicapai (jika itu bukan bagian dari strategi bisnis Anda untuk menjadikannya sebagai keunggulan kompetitif utama Anda, tentu saja).

Kesalahan Umum Unity #2: Bekerja dengan Model yang Tidak Dioptimalkan

Sangat penting untuk menyiapkan semua model Anda dengan baik untuk dapat menggunakannya dalam adegan Anda tanpa modifikasi lebih lanjut. Ada beberapa hal yang harus dipenuhi oleh model yang baik.

Sangat penting untuk mengatur skala dengan benar. Terkadang tidak mungkin untuk mengaturnya dengan benar dari perangkat lunak pemodelan 3D Anda karena unit berbeda yang digunakan aplikasi ini. Untuk memperbaiki semuanya, atur faktor skala dalam pengaturan impor model (biarkan 0,01 untuk 3dsMax dan Modo, atur 1,0 untuk Maya), dan perhatikan bahwa terkadang Anda perlu mengimpor ulang objek setelah mengubah pengaturan skala. Pengaturan ini harus memastikan bahwa Anda hanya dapat menggunakan skala dasar 1,1,1 dalam adegan Anda untuk mendapatkan perilaku yang konsisten dan tidak ada masalah fisika. Batching dinamis juga akan lebih mungkin bekerja dengan benar. Aturan ini juga harus diterapkan pada setiap subobjek dalam model, bukan hanya yang utama. Saat Anda perlu mengubah dimensi objek, lakukan dengan objek lain dalam aplikasi pemodelan 3D daripada di Unity. Namun, Anda dapat bereksperimen dengan skala di Unity untuk mengetahui nilai yang sesuai, tetapi untuk aplikasi akhir dan alur kerja yang konsisten, ada baiknya untuk menyiapkan semuanya dengan baik sebelum mengimpor ke Unity.

Mengenai fungsionalitas objek dan bagian dinamisnya - buat model Anda terbagi dengan baik. Semakin sedikit subjek, semakin baik. Pisahkan bagian objek untuk berjaga-jaga jika Anda membutuhkannya, misalnya untuk bergerak atau berputar secara dinamis, untuk tujuan animasi, atau interaksi lainnya. Setiap objek dan sub-objeknya harus memiliki poros yang disejajarkan dan diputar dengan benar sesuai dengan fungsi utamanya. Objek utama harus memiliki sumbu Z yang mengarah ke depan dan pivot harus berada di bagian bawah objek untuk penempatan yang lebih baik ke tempat kejadian. Gunakan bahan sesedikit mungkin pada objek (lebih lanjut tentang ini di bawah).

Semua aset harus memiliki nama yang tepat yang akan dengan mudah menggambarkan jenis dan fungsinya. Pertahankan konsistensi ini di seluruh proyek Anda.

Kesalahan Umum Persatuan #3: Membangun Arsitektur Kode Interdependen

Pembuatan prototipe dan implementasi fungsionalitas di Unity cukup mudah. Anda dapat dengan mudah menarik dan melepaskan referensi apa pun ke objek lain, menangani setiap objek dalam adegan, dan mengakses setiap komponen yang dimilikinya. Namun, ini juga bisa berpotensi berbahaya. Di atas masalah kinerja yang terlihat (menemukan objek dalam hierarki dan akses ke komponen memiliki overhead), ada juga bahaya besar dalam membuat bagian kode Anda sepenuhnya bergantung satu sama lain. Atau bergantung pada sistem dan skrip lain yang unik untuk aplikasi Anda, atau bahkan pada adegan saat ini, atau skenario saat ini. Cobalah untuk mengambil pendekatan yang lebih modular dan buat bagian yang dapat digunakan kembali yang dapat digunakan di bagian lain aplikasi Anda, atau bahkan dibagikan di seluruh portofolio aplikasi Anda. Bangun kerangka kerja dan pustaka Anda di atas Unity API dengan cara yang sama seperti Anda membangun basis pengetahuan Anda.

Ada banyak pendekatan berbeda untuk memastikan hal ini. Titik awal yang baik adalah sistem komponen Unity itu sendiri. Komplikasi mungkin muncul ketika komponen tertentu perlu berkomunikasi dengan sistem aplikasi lain. Untuk ini, Anda dapat menggunakan antarmuka untuk membuat bagian dari sistem Anda lebih abstrak dan dapat digunakan kembali. Atau, Anda dapat menggunakan pendekatan berbasis peristiwa untuk bereaksi terhadap peristiwa tertentu dari luar lingkup, baik dengan membuat sistem pesan atau dengan mendaftar langsung ke bagian sistem lain sebagai pendengar. Pendekatan yang tepat akan mencoba memisahkan properti gameObject dari logika program (setidaknya seperti prinsip model-controller), karena sulit untuk mengidentifikasi objek mana yang memodifikasi properti transformasinya, seperti posisi dan rotasi. Ini harus menjadi tanggung jawab pengontrolnya secara eksklusif.

Cobalah untuk membuat semuanya didokumentasikan dengan baik. Perlakukan selalu seperti Anda harus kembali ke kode Anda setelah waktu yang lama dan Anda perlu memahami dengan cepat apa sebenarnya yang dilakukan bagian kode ini. Karena pada kenyataannya, Anda akan cukup sering sampai ke beberapa bagian dari aplikasi Anda setelah beberapa waktu dan itu merupakan hambatan yang tidak perlu untuk cepat melompat ke masalah. Tapi jangan berlebihan dalam hal ini. Terkadang, kelas, metode, atau nama properti yang sesuai sudah cukup memadai.

Kesalahan Umum Persatuan #4: Membuang-buang Performa Anda

Jajaran produk ponsel, konsol, atau komputer desktop terbaru tidak akan pernah secanggih ini sehingga tidak perlu mempedulikan kinerja. Optimalisasi kinerja selalu dibutuhkan, dan mereka memberikan dasar untuk membuat perbedaan dalam tampilan game atau aplikasi Anda dibandingkan dengan yang lain di pasar. Karena ketika Anda menyimpan beberapa kinerja di satu bagian, Anda dapat menggunakannya untuk memoles bagian lain dari aplikasi Anda.

Ada banyak area untuk pengoptimalan. Seluruh artikel akan diperlukan hanya untuk menggores permukaan tentang topik ini. Setidaknya, saya akan mencoba membagi domain ini menjadi beberapa area inti.

Perbarui Loop

Jangan gunakan hal-hal yang intensif kinerja dalam loop pembaruan, gunakan caching sebagai gantinya. Contoh tipikal adalah akses ke komponen atau objek lain dalam adegan atau perhitungan intensif dalam skrip Anda. Jika memungkinkan, tembolok semuanya dalam metode Awake() , atau ubah arsitektur Anda ke pendekatan yang lebih didorong oleh peristiwa untuk memicu sesuatu tepat saat dibutuhkan.

Instansiasi

Untuk objek yang cukup sering dipakai (misalnya, peluru dalam game FPS), buat kumpulan yang telah diinisialisasi sebelumnya dan cukup pilih satu yang sudah diinisialisasi saat Anda membutuhkannya dan aktifkan. Kemudian, alih-alih menghancurkannya saat tidak diperlukan lagi, nonaktifkan dan kembalikan ke pool.

Rendering

Gunakan oklusi pemusnahan atau teknik LOD untuk membatasi bagian adegan yang dirender. Coba gunakan model yang dioptimalkan untuk dapat menjaga jumlah vertex dalam adegan tetap terkendali. Perlu diketahui, jumlah simpul tidak hanya jumlah simpul pada model itu sendiri, tetapi juga dipengaruhi oleh hal-hal lain seperti normal (tepi keras), koordinat UV (lapisan UV), dan warna simpul. Selain itu, sejumlah lampu dinamis dalam pemandangan akan secara dramatis memengaruhi kinerja keseluruhan, jadi cobalah untuk memanggang semuanya terlebih dahulu jika memungkinkan.

Menggambar Panggilan

Cobalah untuk mengurangi jumlah panggilan undian. Di Unity, Anda dapat mencapai pengurangan panggilan undian dengan menggunakan pengelompokan statis untuk objek diam dan pengelompokan dinamis untuk objek bergerak. Namun, Anda harus mempersiapkan adegan dan model Anda terlebih dahulu (objek batch harus berbagi materi yang sama), dan batching objek dinamis hanya berfungsi untuk model beresolusi rendah. Atau, Anda dapat menggabungkan mesh dengan skrip menjadi satu ( Mesh.CombineMeshes ) daripada menggunakan batching, tetapi Anda harus berhati-hati untuk tidak membuat objek yang terlalu besar yang tidak dapat memanfaatkan view frustum culling pada beberapa platform. Secara umum, kuncinya adalah menggunakan bahan sesedikit mungkin dan membagikannya ke seluruh tempat. Terkadang Anda perlu membuat atlas dari tekstur untuk dapat berbagi satu materi di antara objek yang berbeda. Tip yang baik juga menggunakan resolusi yang lebih tinggi dari tekstur lightmap pemandangan (bukan resolusi yang dihasilkan, tetapi resolusi keluaran tekstur) untuk menurunkan jumlahnya saat Anda memanggang cahaya di lingkungan yang lebih besar.

Masalah Overdraw

Jangan gunakan tekstur transparan jika tidak diperlukan, karena akan menyebabkan masalah rasio pengisian. Tidak apa-apa untuk menggunakannya untuk geometri yang rumit dan lebih jauh, seperti pohon atau semak-semak. Saat Anda perlu menggunakannya, pilih shader alpha blended daripada shader dengan pengujian alpha atau daripada shader cutout untuk platform seluler. Untuk mengidentifikasi masalah ini secara umum, coba turunkan resolusi aplikasi Anda. Jika itu membantu, mungkin Anda memiliki masalah rasio pengisian ini, atau Anda perlu lebih mengoptimalkan shader Anda. Jika tidak, itu bisa menjadi lebih banyak masalah memori.

shader

Optimalkan shader Anda untuk kinerja yang lebih baik. Kurangi jumlah lintasan, gunakan variabel dengan presisi lebih rendah, ganti perhitungan matematika yang rumit dengan tekstur pencarian yang dibuat sebelumnya.

Selalu gunakan profiler untuk menentukan hambatan. Ini adalah alat yang hebat. Untuk rendering, Anda juga dapat menggunakan Frame Debugger yang luar biasa, yang akan membantu Anda belajar banyak tentang cara kerja berbagai hal secara umum saat menguraikan proses rendering dengannya.

Kesalahan Umum Persatuan #5: Mengabaikan masalah Pengumpulan Sampah

Perlu disadari bahwa meskipun Garbage Collector (GC) sendiri membantu kita untuk benar-benar efisien dan fokus pada hal-hal penting dalam pemrograman, ada beberapa hal yang harus kita sadari secara eksplisit. Penggunaan GC tidak gratis. Secara umum, kita harus menghindari alokasi memori yang tidak perlu untuk mencegah GC menembak dirinya sendiri terlalu sering dan dengan demikian merusak kinerja dengan lonjakan framerate. Idealnya, tidak boleh ada alokasi memori baru yang terjadi secara teratur di setiap frame. Namun, bagaimana kita bisa mencapai tujuan ini? Ini benar-benar ditentukan oleh arsitektur aplikasi, tetapi ada beberapa aturan yang dapat Anda ikuti yang membantu:

• Hindari alokasi yang tidak perlu dalam loop pembaruan.
• Gunakan struct untuk container properti sederhana, karena tidak dialokasikan di heap.
• Cobalah untuk melakukan pra-alokasi array atau daftar atau koleksi objek lainnya, alih-alih membuatnya di dalam loop pembaruan.
• Hindari menggunakan hal-hal bermasalah mono (seperti ekspresi LINQ atau loop foreach, misalnya) karena Unity menggunakan versi Mono yang lebih lama dan tidak dioptimalkan secara ideal (pada saat penulisan ini dimodifikasi versi 2.6, dengan peningkatan pada peta jalan).
• Cache string dalam metode Awake() atau dalam acara.
• Jika pembaruan properti string dalam loop pembaruan diperlukan, gunakan objek StringBuilder alih-alih string.
• Gunakan profiler untuk mengidentifikasi potensi masalah.

Kesalahan Umum Unity #6: Mengoptimalkan Memori dan Penggunaan Ruang Terakhir

Penting untuk tetap memperhatikan penggunaan memori dan ruang terendah dari aplikasi sejak awal proyek, karena lebih rumit untuk melakukannya ketika Anda meninggalkan pengoptimalan untuk fase pra-rilis. Pada perangkat seluler, ini bahkan lebih penting, karena kami cukup kekurangan sumber daya di sana. Selain itu, dengan melebihi ukuran instalasi 100MB, kami dapat kehilangan sejumlah besar pelanggan kami. Ini karena batas 100MB untuk unduhan jaringan seluler, dan juga karena alasan psikologis. Akan selalu lebih baik bila aplikasi Anda tidak menyia-nyiakan sumber daya telepon pelanggan yang berharga, dan mereka akan lebih cenderung mengunduh atau membeli aplikasi Anda ketika ukurannya lebih kecil.

Untuk menemukan penguras sumber daya, Anda dapat menggunakan log editor di mana Anda dapat melihat (setelah setiap build baru) ukuran sumber daya yang dibagi ke dalam kategori terpisah, seperti audio, tekstur, dan DLL. Untuk orientasi yang lebih baik, ada ekstensi editor di Unity Asset Store, yang akan memberi Anda ringkasan terperinci dengan sumber daya dan file yang dirujuk di sistem file Anda. Konsumsi memori yang sebenarnya juga dapat dilihat di profiler, tetapi disarankan untuk mengujinya saat terhubung untuk membangun platform target Anda karena ada banyak ketidakkonsistenan saat menguji di editor atau pada apa pun selain platform target Anda.

Konsumen memori terbesar seringkali adalah tekstur. Sebaiknya, gunakan tekstur terkompresi karena memakan lebih sedikit ruang dan memori. Buat semua tekstur menjadi kuadrat, idealnya, buat panjang kedua sisi pangkat dua (POT), tetapi perlu diingat Unity juga dapat menskalakan tekstur NPOT ke POT secara otomatis. Tekstur dapat dikompresi saat berada dalam bentuk POT. Tekstur atlas menyatu untuk mengisi seluruh tekstur. Terkadang Anda bahkan dapat menggunakan saluran alfa tekstur untuk beberapa informasi tambahan bagi shader Anda untuk menghemat ruang dan kinerja tambahan. Dan tentu saja, cobalah untuk menggunakan kembali tekstur untuk adegan Anda sebanyak mungkin, dan gunakan tekstur berulang jika memungkinkan untuk mempertahankan tampilan visual yang baik. Untuk perangkat kelas bawah, Anda dapat menurunkan resolusi tekstur di Pengaturan Kualitas. Gunakan format audio terkompresi untuk klip audio yang lebih panjang, seperti musik latar.

Saat Anda berurusan dengan platform, resolusi, atau pelokalan yang berbeda, Anda dapat menggunakan kumpulan aset untuk menggunakan kumpulan tekstur yang berbeda untuk perangkat atau pengguna yang berbeda. Bundel aset ini dapat dimuat secara dinamis dari internet setelah aplikasi diinstal. Dengan cara ini, Anda dapat melebihi batas 100MB dengan mengunduh sumber daya selama permainan.

Kesalahan Umum Kesatuan #7: Kesalahan Umum Fisika

Kadang-kadang, ketika memindahkan objek di tempat kejadian, kita tidak menyadari bahwa objek tersebut bertabrakan dan mengubah posisinya akan memaksa mesin untuk menghitung ulang seluruh dunia fisik dari awal. Dalam hal ini, Anda harus menambahkan komponen Rigidbody ke dalamnya (Anda dapat mengaturnya ke non-kinematik jika Anda tidak ingin kekuatan eksternal terlibat).

Untuk mengubah posisi objek dengan Rigidbody di atasnya, selalu atur Rigidbody.position saat posisi baru tidak mengikuti posisi sebelumnya, atau Rigidbody.MovePosition saat merupakan gerakan berkelanjutan, yang juga memperhitungkan interpolasi. Saat memodifikasinya, terapkan operasi selalu di FixedUpdate , bukan di fungsi Update . Ini akan memastikan perilaku fisika yang konsisten.

Jika memungkinkan, gunakan penumbuk primitif pada objek game, seperti bola, kotak, atau silinder, dan bukan penumbuk jala. Anda dapat membuat penumbuk terakhir Anda dari lebih dari satu penumbuk ini. Fisika dapat menjadi penghambat kinerja aplikasi Anda karena overhead CPU-nya dan tabrakan antara Collider primitif jauh lebih cepat untuk dihitung. Anda juga dapat menyesuaikan pengaturan Fixed Timestep di Pengelola waktu untuk mengurangi frekuensi pembaruan tetap fisika ketika akurasi interaksi fisika tidak begitu diperlukan.

Kesalahan Umum Persatuan #8: Menguji Semua Fungsi Secara Manual

Kadang-kadang mungkin ada kecenderungan untuk menguji fungsionalitas secara manual dengan bereksperimen dalam mode putar karena itu cukup menyenangkan dan Anda memiliki segalanya di bawah kendali langsung Anda. Tapi faktor keren ini bisa berkurang cukup cepat. Semakin kompleks aplikasi, semakin banyak tugas yang harus diulang dan dipikirkan oleh programmer untuk memastikan bahwa aplikasi berperilaku seperti yang dimaksudkan semula. Ini dapat dengan mudah menjadi bagian terburuk dari keseluruhan proses pengembangan, karena sifatnya yang berulang dan pasif. Juga, karena pengulangan skenario pengujian secara manual tidak begitu menyenangkan, jadi ada kemungkinan lebih tinggi bahwa beberapa bug akan berhasil melewati seluruh proses pengujian.

Unity memiliki alat pengujian yang hebat untuk mengotomatisasi ini. Dengan desain arsitektur dan kode yang sesuai, Anda dapat menggunakan pengujian unit untuk menguji fungsionalitas yang terisolasi, atau bahkan pengujian integrasi untuk menguji skenario yang lebih kompleks. Anda dapat secara dramatis mengurangi pendekatan coba-dan-periksa di mana Anda mencatat data aktual dan membandingkannya dengan keadaan yang diinginkan.

Pengujian manual tidak diragukan lagi merupakan bagian penting dari pengembangan. Tapi jumlahnya bisa dikurangi, dan keseluruhan proses bisa lebih kuat dan lebih cepat. Ketika tidak ada cara yang memungkinkan untuk mengotomatiskannya, persiapkan adegan pengujian Anda untuk dapat masuk ke masalah yang Anda coba selesaikan secepat mungkin. Idealnya, beberapa frame setelah menekan tombol play. Terapkan pintasan atau cheat untuk mengatur status yang diinginkan untuk pengujian. Juga, buat situasi pengujian terisolasi untuk memastikan apa yang menyebabkan masalah. Setiap detik yang tidak perlu dalam mode putar saat pengujian diakumulasikan, dan semakin besar bias awal pengujian masalah, semakin besar kemungkinan Anda tidak akan menguji masalah sama sekali, dan Anda akan berharap semuanya berfungsi dengan baik. Tapi mungkin tidak.

Kesalahan Umum Unity #9: Berpikir Plugin Unity Asset Store Akan Menyelesaikan Semua Masalah Anda

Percayalah kepadaku; mereka tidak akan. Ketika bekerja dengan beberapa klien, saya terkadang menghadapi kecenderungan atau peninggalan dari masa lalu menggunakan plugin toko aset untuk setiap hal kecil. Saya tidak bermaksud tidak ada ekstensi Unity yang berguna di Unity Asset Store. Ada banyak dari mereka, dan kadang-kadang bahkan sulit untuk memutuskan mana yang harus dipilih. Tetapi untuk setiap proyek, penting untuk mempertahankan konsistensi, yang dapat dihancurkan dengan tidak bijaksana menggunakan bagian-bagian berbeda yang tidak cocok satu sama lain.

Di sisi lain, untuk fungsionalitas yang membutuhkan waktu lama untuk Anda terapkan, selalu berguna untuk menggunakan produk yang telah teruji dengan baik dari Unity Asset Store, yang dapat menghemat banyak waktu pengembangan Anda. Namun, pilih dengan hati-hati, gunakan yang terbukti yang tidak akan membawa banyak bug yang tidak terkendali dan aneh ke produk akhir Anda. Ulasan bintang lima adalah ukuran yang baik untuk memulai.

Jika fungsionalitas yang Anda inginkan tidak sulit untuk diterapkan, tambahkan saja ke perpustakaan pribadi (atau perusahaan) Anda yang terus berkembang, yang dapat digunakan lagi di semua proyek Anda nanti. Dengan cara itu Anda meningkatkan pengetahuan dan perangkat Anda secara bersamaan.

Kesalahan Umum Unity #10: Tidak Perlu Memperpanjang Fungsi Dasar Unity

Terkadang tampaknya lingkungan Unity Editor cukup memadai untuk pengujian game dasar dan desain level, dan memperpanjangnya hanya membuang-buang waktu. Tapi percayalah, tidak. Potensi ekstensi besar Unity berasal dari kemampuan untuk menyesuaikannya dengan masalah spesifik yang perlu dipecahkan dalam berbagai proyek. Ini dapat meningkatkan pengalaman pengguna saat bekerja di Unity atau secara dramatis mempercepat seluruh alur kerja pengembangan dan desain level. Sangat disayangkan untuk tidak menggunakan fitur bawaan, seperti Laci Properti bawaan atau khusus, Laci Dekorator, pengaturan pemeriksa komponen khusus, atau bahkan tidak membangun seluruh plugin dengan Windows Editornya sendiri.

Kesimpulan

Saya harap topik ini akan berguna bagi Anda saat Anda memindahkan proyek Unity Anda lebih jauh. Ada banyak hal yang spesifik untuk proyek, sehingga tidak dapat diterapkan, tetapi selalu berguna untuk memiliki beberapa aturan dasar dalam pikiran ketika mencoba memecahkan masalah yang lebih sulit dan spesifik. Anda mungkin memiliki pendapat atau prosedur yang berbeda tentang bagaimana memecahkan masalah ini dalam proyek Anda. Yang paling penting adalah menjaga idiom Anda tetap konsisten di seluruh proyek Anda sehingga siapa pun di tim Anda dapat dengan jelas memahami bagaimana domain tertentu seharusnya diselesaikan dengan benar.

Bacaan Lebih Lanjut di Blog Teknik Toptal:

• Pengembangan Unity AI: Tutorial Mesin kondisi-terbatas