Mengapa terlalu buruk untuk mengoptimalkan terlalu dini?

Setelah melihat ke dalam optimasi sedikit, saya telah menemukan (secara harfiah di mana-mana) bahwa itu tampaknya dosa yang diakui secara universal untuk mengoptimalkan permainan terlalu dini.

Saya benar-benar tidak mengerti hal ini, bukankah akan sangat sulit untuk mengubah beberapa struktur inti permainan pada akhirnya, daripada mengembangkannya pertama kali dengan kinerja dalam pikiran?

Saya mendapatkan bahwa menunggu sampai permainan selesai akan memberi tahu Anda jika Anda bahkan perlu optimisasi, tetapi sebaiknya Anda tidak melakukannya, setelah semua, itu bisa memperluas berbagai perangkat yang bisa dijalankan permainan, yang akan menambah jumlah potensi pemain.

Bisakah seseorang menjelaskan kepada saya mengapa terlalu buruk untuk mengoptimalkan terlalu dini?

Pembukaan:

Beberapa keberatan telah diajukan dalam komentar, dan saya pikir mereka sebagian besar berasal dari kesalahpahaman tentang apa yang kita maksudkan ketika kita mengatakan "optimasi prematur" - jadi saya ingin menambahkan sedikit klarifikasi tentang itu.

"Jangan mengoptimalkan sebelum waktunya" tidak berarti "menulis kode yang Anda tahu buruk, karena Knuth mengatakan Anda tidak diizinkan untuk membersihkannya sampai akhir"

Ini berarti "jangan mengorbankan waktu & keterbacaan untuk pengoptimalan sampai Anda tahu bagian mana dari program Anda yang benar-benar membutuhkan bantuan agar lebih cepat." Karena program tipikal menghabiskan sebagian besar waktunya dalam beberapa hambatan, berinvestasi dalam mengoptimalkan "semuanya" mungkin tidak memberi Anda dorongan kecepatan yang sama dengan memfokuskan investasi yang sama hanya pada kode yang mengalami kemacetan.

Ini berarti, ketika ragu , kita harus:

• Lebih suka kode yang mudah ditulis, jelas dimengerti, dan mudah dimodifikasi untuk pemula

• Periksa apakah optimasi lebih lanjut diperlukan (biasanya dengan membuat profil program yang sedang berjalan, meskipun satu komentar di bawah ini mencatat melakukan analisis matematika - satu-satunya risiko di sana adalah Anda juga perlu memeriksa apakah matematika Anda benar)

Optimalisasi prematur tidak :

• Keputusan arsitektural untuk menyusun kode Anda dengan cara yang akan disesuaikan dengan kebutuhan Anda - memilih modul / tanggung jawab / antarmuka / sistem komunikasi yang sesuai dengan cara yang dipertimbangkan.

• Efisiensi sederhana yang tidak membutuhkan waktu ekstra atau membuat kode Anda lebih sulit dibaca. Hal-hal seperti menggunakan pengetikan yang kuat dapat menjadi efisien dan membuat maksud Anda lebih jelas. Caching referensi alih-alih mencarinya berulang kali adalah contoh lain (selama kasing Anda tidak membutuhkan logika pembatalan-cache yang rumit - mungkin tunda menulisnya sampai Anda membuat profil dengan cara sederhana terlebih dahulu).

• Menggunakan algoritma yang tepat untuk pekerjaan itu. A * lebih optimal dan lebih kompleks daripada mencari grafik pathfinding secara mendalam. Ini juga merupakan standar industri. Mengulangi tema, tetap menggunakan metode yang sudah terbukti benar seperti ini sebenarnya dapat membuat kode Anda lebih mudah dipahami daripada jika Anda melakukan sesuatu yang sederhana tetapi bertentangan dengan praktik terbaik yang diketahui. Jika Anda memiliki pengalaman mengalami hambatan dalam mengimplementasikan fitur game X satu arah pada proyek sebelumnya, Anda tidak perlu menekan bottleneck yang sama lagi pada proyek ini untuk mengetahui itu nyata - Anda dapat dan harus menggunakan kembali solusi yang telah bekerja sebelumnya. pertandingan.

Semua jenis optimasi itu dibenarkan dengan baik dan umumnya tidak akan diberi label "prematur" (kecuali jika Anda pergi ke lubang kelinci menerapkan pathfinding mutakhir untuk peta papan catur 8x8 Anda ...)

Jadi sekarang dengan itu dibersihkan, mengapa kita mungkin menemukan kebijakan ini berguna dalam game khusus:

Dalam gamedev khususnya, kecepatan iterasi adalah hal yang paling berharga. Kami akan sering menerapkan dan menerapkan kembali ide-ide yang jauh lebih banyak daripada yang pada akhirnya akan dikirimkan dengan permainan yang sudah jadi, mencoba "menemukan kesenangan."

Jika Anda dapat membuat prototipe mekanik secara langsung & mungkin agak naif dan melakukan pengujian pada hari berikutnya, Anda berada dalam posisi yang jauh lebih baik daripada jika Anda menghabiskan waktu seminggu membuat versi yang paling optimal terlebih dahulu. Terutama jika ternyata menyedot dan Anda akhirnya membuang fitur itu. Melakukannya dengan cara sederhana sehingga Anda dapat menguji lebih awal dapat menghemat satu ton kode optimisasi pekerjaan yang sia-sia yang tidak Anda simpan.

Kode yang tidak dioptimalkan juga umumnya lebih mudah untuk dimodifikasi dan mencoba varian yang berbeda daripada kode yang secara halus disetel untuk melakukan satu hal yang tepat secara optimal, yang cenderung rapuh dan sulit untuk dimodifikasi tanpa memecahkannya, memperkenalkan bug, atau memperlambatnya. Jadi, menjaga kode tetap sederhana dan mudah diubah sering kali bernilai inefisiensi runtime kecil di sebagian besar pengembangan (kami biasanya mengembangkan mesin di atas spesifikasi target, sehingga kami dapat menyerap overhead dan fokus untuk mendapatkan pengalaman target terlebih dahulu) hingga kami Kami telah mengunci apa yang kami butuhkan dari fitur ini dan dapat mengoptimalkan bagian-bagian yang kami tahu lambat.

Ya, refactoring bagian dari proyek terlambat dalam pengembangan untuk mengoptimalkan titik lambat bisa sulit. Namun demikian, refactoring berulang kali sepanjang pengembangan karena optimisasi yang Anda buat bulan lalu tidak kompatibel dengan arah permainan yang telah berkembang sejak saat itu, atau memperbaiki sesuatu yang ternyata tidak menjadi hambatan nyata begitu Anda mendapatkan lebih banyak fitur & konten di.

Game itu aneh dan eksperimental - sulit untuk memprediksi bagaimana proyek game dan kebutuhan teknologinya akan berkembang dan di mana kinerjanya paling ketat. Dalam praktiknya, kita sering berakhir mengkhawatirkan hal-hal yang salah - cari melalui pertanyaan kinerja di sini dan Anda akan melihat tema umum muncul dari para dev yang teralihkan oleh hal-hal di atas kertas yang sepertinya tidak menjadi masalah sama sekali.

Untuk mengambil contoh dramatis: jika game Anda terikat GPU (bukan tidak umum) maka semua waktu yang dihabiskan untuk mengoptimalkan hiper dan threading kerja CPU mungkin tidak menghasilkan manfaat nyata sama sekali. Semua jam dev itu bisa digunakan untuk mengimplementasikan & memoles fitur gameplay sebagai gantinya, untuk pengalaman pemain yang lebih baik.

Secara keseluruhan, sebagian besar waktu yang Anda habiskan untuk mengerjakan permainan tidak akan dihabiskan untuk kode yang akhirnya menjadi hambatan. Terutama ketika Anda bekerja pada mesin yang ada, hal-hal loop dalam yang sangat mahal dalam rendering dan sistem fisika sebagian besar di luar tangan Anda. Pada saat itu, tugas Anda dalam skrip gameplay pada dasarnya adalah menghindari mesin - selama Anda tidak melempar kunci pas di sana, maka Anda mungkin akan keluar dengan cukup baik untuk build pertama.

Jadi, terlepas dari sedikit kode kebersihan dan penganggaran (mis. Jangan berulang kali mencari / membuat barang jika Anda dapat dengan mudah menggunakannya kembali, pertahankan pencarian pathfinding / fisika atau pembacaan kembali GPU yang sederhana, dll.), Biasakan untuk tidak berlebihan Mengoptimalkan sebelum kita tahu di mana masalah yang sebenarnya ternyata baik untuk produktivitas - menyelamatkan kita dari membuang waktu mengoptimalkan hal-hal yang salah, dan menjaga kode kita lebih sederhana dan lebih mudah untuk mengubah secara keseluruhan.

catatan: jawaban ini dimulai sebagai komentar pada jawaban DMGregory, dan karenanya tidak menduplikasi poin yang sangat baik yang dia buat.

"Apakah tidak akan terlalu sulit untuk mengubah beberapa struktur inti permainan pada akhirnya, daripada mengembangkannya pertama kali dengan kinerja dalam pikiran?"

Bagi saya ini adalah inti dari pertanyaan.

Saat membuat desain asli Anda, Anda harus mencoba merancang untuk efisiensi - di tingkat atas. Ini kurang optimasi, dan lebih banyak tentang struktur.

Contoh:
Anda perlu membuat sistem untuk menyeberangi sungai. Desain yang jelas adalah jembatan atau feri, jadi mana yang Anda pilih?
Jawabannya tentu saja tergantung pada ukuran persimpangan dan volume lalu lintas. Ini bukan pengoptimalan, melainkan memulai dengan desain yang cocok untuk masalah Anda.

Ketika disajikan dengan pilihan desain, Anda memilih yang paling cocok dengan apa yang ingin Anda lakukan.

Jadi, katakanlah volume lalu lintas kami cukup rendah, jadi kami memutuskan untuk membangun dua terminal dan membeli dengan feri untuk menangani lalu lintas. Implementasi sederhana yang bagus
Sayangnya, begitu kita menjalankan dan menjalankannya, kami menemukan bahwa ia melihat lebih banyak lalu lintas dari yang diharapkan. Kita perlu mengoptimalkan feri! (karena berfungsi, dan membangun jembatan sekarang bukan rencana yang baik)

Pilihan:

• Beli feri kedua (pemrosesan paralel)
• Tambahkan dek mobil lain ke feri (kompresi lalu lintas)
• Tingkatkan mesin feri untuk membuatnya lebih cepat (algoritma pemrosesan ulang tertulis)

Di sinilah Anda harus berusaha untuk membuat desain asli Anda semodel mungkin.
Semua hal di atas adalah kemungkinan optimasi, dan Anda bahkan dapat melakukan ketiganya.
Tetapi bagaimana Anda membuat perubahan ini tanpa perubahan struktural besar?

Jika Anda memiliki desain modular dengan antarmuka yang jelas, maka harus mudah untuk menerapkan perubahan ini.
Jika kode Anda tidak digabungkan secara ketat, maka perubahan pada modul tidak mempengaruhi struktur di sekitarnya.

Mari kita lihat menambahkan feri tambahan.
Program 'buruk' dapat dibangun di sekitar gagasan sebuah feri tunggal, dan biarkan negara bagian dermaga dan negara bagian feri dan posisinya semua disatukan dan berbagi keadaan. Ini akan sulit dimodifikasi untuk memungkinkan feri tambahan ditambahkan ke sistem.
Desain yang lebih baik adalah memiliki dermaga dan feri sebagai entitas yang terpisah. Tidak ada kopling ketat di antara mereka, tetapi mereka memiliki antarmuka, di mana feri bisa tiba, menurunkan penumpang, naik yang baru, dan pergi. Dock dan feri hanya berbagi antarmuka ini, dan ini membuatnya mudah untuk membuat perubahan pada sistem, dalam hal ini dengan menambahkan feri kedua. Dermaga tidak peduli tentang apa sebenarnya feri, yang perlu diperhatikan adalah bahwa sesuatu (apa saja) menggunakan antarmuka.

tl; dr:

• Coba desain untuk efisiensi sejak awal.
• Ketika disajikan dengan dua pilihan, Anda memilih yang lebih efisien.
• Tulis kode Anda semodel mungkin dengan antarmuka yang jelas.

Anda kemudian dapat mengubah mekanisme dalam setiap modul tanpa merestrukturisasi seluruh basis kode saat Anda perlu mengoptimalkan.

"Jangan mengoptimalkan awal" tidak berarti "memilih cara terburuk untuk melakukan sesuatu". Anda masih perlu mempertimbangkan implikasi kinerja (kecuali Anda hanya membuat prototipe). Intinya bukan untuk melumpuhkan hal-hal lain yang lebih penting pada saat itu dalam pengembangan - seperti fleksibilitas, keandalan dll. Pilih sederhana, optimisasi aman - pilih hal-hal yang Anda batasi, dan hal-hal yang Anda jaga tetap bebas; melacak biaya. Haruskah Anda menggunakan pengetikan kuat? Sebagian besar permainan berhasil dan bekerja dengan baik; berapa biaya yang harus Anda keluarkan untuk itu jika Anda menemukan kegunaan yang menarik dari fleksibilitas untuk gamemplay?

Jauh lebih sulit untuk memodifikasi kode yang dioptimalkan, terutama kode "pintar". Itu selalu merupakan pilihan yang membuat beberapa hal lebih baik, dan yang lain lebih buruk (misalnya, Anda mungkin memperdagangkan waktu CPU untuk penggunaan memori). Ketika membuat pilihan itu, Anda harus menyadari semua implikasinya - mereka mungkin menjadi bencana, tetapi mereka juga bisa membantu.

Misalnya, Komandan Keen, Wolfenstein dan Doom masing-masing dibangun di atas mesin rendering yang dioptimalkan. Masing-masing memiliki "trik" mereka yang memungkinkan permainan untuk ada di tempat pertama (masing-masing juga memiliki optimasi lebih lanjut dari waktu ke waktu, tetapi itu tidak penting di sini). Itu baik-baik saja . Tidak apa-apa untuk sangat mengoptimalkan inti dari permainan, pemikiran yang memungkinkan permainan; terutama jika Anda menjelajahi wilayah baru di mana fitur yang dioptimalkan khusus ini memungkinkan Anda untuk mempertimbangkan desain game yang tidak banyak dieksplorasi. Batasan yang diperkenalkan oleh optimasi dapat memberikan Anda gameplay yang menarik juga (mis. Batasan jumlah unit dalam game RTS mungkin telah dimulai sebagai cara untuk meningkatkan kinerja, tetapi mereka memiliki efek gameplay juga).

Tetapi harap dicatat bahwa dalam masing-masing contoh ini, permainan tidak akan ada tanpa optimasi. Mereka tidak memulai dengan mesin "sepenuhnya dioptimalkan" - mereka mulai dengan kebutuhan telanjang, dan berjalan naik. Mereka mengembangkan teknologi baru, dan menggunakannya untuk membuat game yang menyenangkan. Dan trik mesin dibatasi sebagai bagian kecil dari basis kode mungkin - optimasi yang lebih berat hanya diperkenalkan ketika gameplay sebagian besar dilakukan, atau di mana itu memungkinkan fitur baru yang menarik muncul.

Sekarang pertimbangkan sebuah game yang mungkin ingin Anda buat. Apakah memang ada keajaiban teknologi yang membuat atau menghancurkan game itu? Mungkin Anda membayangkan game dunia terbuka di dunia tanpa batas. Apakah itu benar - benar bagian utama dari permainan? Apakah game tidak akan berfungsi tanpanya? Mungkin Anda sedang memikirkan permainan di mana medan dapat dideformasi tanpa batas, dengan geologi realistis dan semacamnya; dapatkah Anda membuatnya bekerja dengan cakupan yang lebih kecil? Apakah ini akan bekerja dalam 2D ​​daripada 3D? Dapatkan sesuatu yang menyenangkan sesegera mungkin - bahkan jika optimasi mungkin mengharuskan Anda untuk mengolah ulang sejumlah besar kode Anda yang ada, mungkin itu layak dilakukan; dan Anda bahkan mungkin menyadari bahwa membuat sesuatu yang lebih besar tidak benar-benar membuat permainan menjadi lebih baik.

Sebagai contoh permainan baru-baru ini dengan banyak optimisasi, saya akan menunjuk ke Factorio. Salah satu bagian penting dari gim ini adalah ikat pinggang - ada ribuan di antaranya, dan mereka membawa banyak potongan material di sekitar pabrik Anda. Apakah permainan dimulai dengan mesin sabuk yang sangat dioptimalkan? Tidak! Bahkan, desain sabuk asli hampir mustahil untuk dioptimalkan - itu semacam melakukan simulasi fisik dari barang-barang di sabuk, yang menciptakan beberapa hal menarik yang bisa Anda lakukan (ini adalah cara Anda mendapatkan gameplay "emergent" - gameplay yang mengejutkan desainer), tetapi berarti Anda harus mensimulasikan setiap item pada ikat pinggang. Dengan ribuan sabuk, Anda mendapatkan puluhan ribu item yang disimulasikan secara fisik - bahkan hanya dengan melepasnya dan membiarkan sabuknya bekerja, Anda dapat menghemat waktu CPU terkait sebesar 95-99%, bahkan tanpa mempertimbangkan hal-hal seperti memori lokalitas. Tapi itu hanya berguna untuk melakukan itu ketika Anda benar-benar mencapai batas-batas itu.

Hampir semua yang ada hubungannya dengan ikat pinggang harus dibuat ulang untuk memungkinkan ikat pinggang dioptimalkan. Dan sabuk harus dioptimalkan, karena Anda membutuhkan banyak sabuk untuk pabrik besar, dan pabrik besar adalah salah satu daya tarik permainan. Lagi pula, jika Anda tidak dapat memiliki pabrik besar, mengapa memiliki dunia tanpa batas? Lucu Anda harus bertanya - versi awal tidak :) Permainan ini ulang dan dibentuk ulang berkali-kali untuk mendapatkan di mana mereka sekarang - termasuk remake 100% ground-up ketika mereka menyadari Jawa bukan cara untuk mencari game seperti ini dan beralih ke C ++. Dan itu bekerja sangat baik untuk Factorio (meskipun itu masih merupakan hal yang baik itu tidak dioptimalkan sejak awal - terutama karena ini adalah proyek hobi, yang mungkin gagal jika tidak karena kurangnya minat).

Tapi masalahnya adalah, ada yangbanyak hal yang dapat Anda lakukan dengan pabrik dengan cakupan terbatas - dan banyak game telah menunjukkan hal itu. Batas bisa lebih memberdayakan untuk bersenang-senang daripada kebebasan; Apakah Spacechem akan lebih menyenangkan jika "peta" tidak terbatas? Jika Anda mulai dengan "sabuk" yang sangat dioptimalkan, Anda akan dipaksa untuk pergi ke sana; dan Anda tidak dapat menjelajahi arah desain lainnya (seperti melihat hal-hal menarik apa yang dapat Anda lakukan dengan sabuk konveyor simulasi-fisika). Anda membatasi ruang desain potensial Anda. Mungkin tidak terlihat seperti itu karena Anda tidak melihat banyak permainan yang belum selesai, tetapi bagian yang sulit adalah mendapatkan kesenangan dengan benar - untuk setiap permainan menyenangkan yang Anda lihat, mungkin ada ratusan yang tidak bisa sampai di sana dan dibatalkan (atau lebih buruk, dirilis sebagai kekacauan mengerikan). Jika optimisasi membantu Anda melakukan itu - silakan. Jika tidak ... kemungkinan prematur. Jika Anda berpikir beberapa mekanik permainan bekerja dengan baik, tetapi perlu optimisasi untuk benar-benar bersinar - silakan. Jika Anda tidak memiliki mekanik yang menarik,jangan mengoptimalkannya . Temukan kesenangan terlebih dahulu - Anda akan menemukan sebagian besar optimisasi tidak membantu dengan itu, dan seringkali bersifat detriminal.

Akhirnya, Anda memiliki gim yang asyik dan menyenangkan. Apakah masuk akal untuk mengoptimalkan sekarang ? Ha! Masih tidak sejelas yang Anda kira. Apakah ada sesuatu yang menyenangkanAnda bisa melakukannya? Jangan lupa waktu Anda masih terbatas. Semuanya membutuhkan upaya, dan Anda ingin memfokuskan upaya itu di tempat yang paling berarti. Ya, meskipun Anda membuat game "gratis", atau "open source". Tonton bagaimana permainan dimainkan; perhatikan di mana kinerja menjadi hambatan. Apakah mengoptimalkan tempat-tempat itu membuat lebih menyenangkan (seperti membangun pabrik yang semakin besar, semakin kusut)? Apakah ini memungkinkan Anda untuk menarik lebih banyak pemain (mis. Dengan komputer yang lebih lemah, atau pada platform yang berbeda)? Anda selalu perlu memprioritaskan - mencari upaya untuk menghasilkan rasio. Anda mungkin akan menemukan banyak buah yang mudah digantung hanya dari memainkan game Anda dan menonton orang lain memainkan game. Tetapi perhatikan bagian penting - untuk sampai ke sana, Anda membutuhkan permainan . Fokuslah pada hal itu.

Sebagai ceri di atas, pertimbangkan bahwa optimasi tidak pernah berakhir. Ini bukan tugas dengan tanda centang kecil yang Anda selesaikan dan beralih ke tugas lain. Selalu ada "satu lagi optimasi" yang dapat Anda lakukan, dan sebagian besar pengembangan apa pun adalah memahami prioritas. Anda tidak melakukan optimasi demi optimisasi - Anda melakukannya untuk mencapai tujuan tertentu (mis. "200 unit di layar sekaligus pada 333 MHz Pentium" adalah tujuan yang hebat). Jangan kehilangan jejak tujuan terminal hanya karena Anda terlalu fokus pada tujuan menengah yang bahkan mungkin bukan prasyarat untuk tujuan terminal lagi.

Banyak jawaban tampaknya banyak berfokus pada aspek kinerja "optimasi" sementara saya sendiri suka melihat optimasi dan seluruh cobaan mengoptimalkan terlalu dini pada tingkat yang lebih abstrak.

Humor saya ketika saya mencoba menguraikan perspektif saya dengan bantuan polyomino.

Misalkan kita memiliki beberapa batasan tetap yang ditetapkan oleh framework atau engine yang sedang kita kerjakan.

Kami kemudian melanjutkan untuk membuat layer / modul pertama dari permainan kami seperti itu.

Selanjutnya, kita membangun lapisan / modul kedua.

Pada titik ini, kita mungkin memperhatikan bahwa ada beberapa ruang yang tersedia antara kedua modul dan kita mungkin tergoda untuk mengoptimalkannya untuk memanfaatkan sepenuhnya batas yang diberikan kepada kita.

Sempurna, sekarang aplikasi sepenuhnya memanfaatkan sumber daya yang tersedia untuk kita, aplikasi lebih baik, bagus kan?

Kami melanjutkan untuk membangun lapisan / modul ketiga dari aplikasi kami dan tiba-tiba kami menyadari (mungkin bahkan yang tidak dapat kami perkirakan selama perencanaan awal) bahwa lapisan / modul ke-3 tidak berfungsi untuk kami.

Kami mencari alternatif, kami menemukan satu, dan pada akhirnya, ini juga mengharuskan kami untuk mengubah modul ke-2 dari aplikasi kami karena tidak sesuai dengan modul ke-3 yang baru kami pilih. (Untungnya ini agak kompatibel dengan modul 1 kami sehingga kami tidak perlu menulis ulang semuanya dari awal.)

Jadi kami menggabungkan semuanya ...

Hmm, bisakah kamu melihat apa yang terjadi?

Dengan mengoptimalkan terlalu dini, kami sekarang benar-benar membuat efisiensi menjadi lebih buruk karena apa yang kami optimalkan bukanlah apa yang akhirnya kami lakukan.

Dan jika kita ingin menambahkan beberapa modul tambahan atau informasi tambahan sesudahnya, kita mungkin tidak lagi memiliki kapasitas untuk melakukannya pada saat ini.

Dan menyesuaikan tingkat terendah dari sistem kami tidak lagi layak karena telah terkubur di bawah semua lapisan lainnya.

Namun, jika kami memilih untuk menunggu dengan keinginan kami untuk segera mengoptimalkannya, kami akan berakhir dengan sesuatu seperti ini:

Dan sekarang jika kita melakukan optimasi pada titik ini kita mendapatkan sesuatu yang memuaskan untuk dilihat.

Semoga setidaknya beberapa dari Anda bersenang-senang membaca ini seperti saya bersenang-senang membuat ini :) dan jika Anda sekarang merasa seperti Anda memiliki pemahaman yang lebih baik tentang subjek - semua lebih baik.

Uang.

Turun ke itu. Uang. Karena waktu adalah uang *, semakin banyak waktu yang Anda habiskan untuk kegiatan yang tidak dijamin menghasilkan lebih banyak uang (yaitu Anda tidak dapat menganggap kegiatan ini sebagai investasi ), semakin banyak uang yang Anda sia-siakan, dan semakin sedikit uang yang Anda hasilkan dengan permainan.

Berikut adalah beberapa lebih potensial efek samping mengoptimalkan terlalu dini, dan alasan mengapa Anda harus menghindarinya:

• Rekan kerja Anda membenci Anda karena Anda bermain di kotak pasir dengan mainan sementara mereka bekerja keras untuk mendapatkan fitur.
• Penundaan itu membuat manajemen tidak senang, dan membuat tim melewatkan tanggal pengiriman, yang menyebabkan game dirilis pada musim semi alih-alih sebelum musim liburan, yang pada gilirannya menyebabkan game tidak cukup menjual. Dan karena ini, kantor pusat memutuskan untuk menutup studio, secara efektif membuat Anda menganggur. Dan tidak ada pekerjaan berarti tidak ada uang. (Dan karena tidak ada yang menyukai Anda karena Anda menghabiskan terlalu banyak waktu melakukan optimasi awal, tidak ada yang ingin menulis ulasan positif tentang pekerjaan Anda untuk Anda di LinkedIn, yang akan membuat Anda kehabisan uang untuk waktu yang lebih lama.)

^{* Jawaban lain telah menyoroti bagian 'waktu' dengan cukup baik}

Sebagai catatan tambahan, secara umum , pengalaman membantu menentukan apa yang dan apa yang bukan optimasi prematur dan apa yang memiliki nilai untuk bisnis dan apa yang tidak.

Misalnya, jika Anda telah bekerja pada game A, dan menyadari pada akhir proyek bahwa fitur XYZ sangat berat pada loop game Anda, dan Anda akhirnya mulai bekerja pada game B yang memiliki fitur yang sama persis, memutuskan untuk menulis ulang fitur dan mengoptimalkannya dari awal bukanlah optimasi yang terlalu dini, karena Anda tahu itu akan menjadi hambatan jika tidak ada yang dilakukan.

Optimalisasi, menurut definisi, adalah proses meningkatkan efisiensi suatu solusi sampai pada titik di mana ia kehilangan kemanjurannya. Proses ini kemudian menyiratkan pengurangan ruang solusi.

Pada tahap awal pengembangan perangkat lunak masih mungkin ada "persyaratan tersembunyi": jika Anda mengurangi terlalu banyak ruang solusi Anda, Anda mungkin berakhir dalam situasi di mana Anda tidak dapat memenuhi "persyaratan tersembunyi" ketika muncul pada tahap pengembangan selanjutnya, memaksa Anda untuk memodifikasi arsitektur yang menambah ketidakstabilan dengan cara ini dan sekelompok perilaku yang mungkin tidak terpikirkan.

Idenya adalah untuk membuat seluruh solusi bekerja dan hanya saat itu, ketika semua persyaratan diperbaiki dan diimplementasikan, kencangkan kode. Anda akan melihat kemudian, bahwa banyak optimasi yang akan Anda implementasikan dengan ringan sekaligus saat pengkodean, sekarang tidak lagi cocok karena interaksi dengan persyaratan yang terlambat.

Ruang nyata dari solusi selalu lebih besar dari yang kita harapkan di awal karena kita tidak dapat memiliki pengetahuan yang sempurna tentang sistem yang sangat kompleks.

Buat itu bekerja dulu. Kemudian kencangkan tali.

Singkatnya, sangat sering mengoptimalkan awal menjadi usaha yang sia-sia jika Anda ingin mengubah sesuatu nanti, dan ternyata Anda telah mengoptimalkan struktur kode yang mudah diubah menjadi tingkat yang jauh lebih rendah, dan sekarang Anda perlu mengubahnya kembali ke tingkat yang lebih tinggi. pendekatan level, dan optimalkan hasilnya sekali lagi.

Ini adalah kesalahan umum bagi pengembang pemula yang suka fokus untuk mendapatkan kesenangan dari "telah melakukan pekerjaan yang bermanfaat", seperti optimasi, tidak memikirkan apakah ini saat yang tepat untuk melakukannya. Saat Anda mendapatkan pengalaman memprogram proyek-proyek besar seperti game, Anda akan belajar kapan diperlukan untuk mengoptimalkan basis kode yang ada, dan ketika itu terlalu cepat. Jangan takut melakukan kesalahan ini, Anda hanya akan mendapat manfaat dengan belajar darinya.

Secara umum, hanya optimalkan jika Anda benar-benar tidak dapat bekerja dengan pengembangan yang dibangun saat ini. Seperti jika Anda membuat dan menghapus jutaan objek 60 kali per detik.

Jadi, saya akan mengatakan itu baik, dalam hal pengalaman belajar, untuk mengoptimalkan awal beberapa kali: hal

Optimalisasi berfokus pada membuat komputer bekerja dengan baik pada kode sementara pengembangan membutuhkan membuat programmer bekerja dengan baik pada kode.

Optimalisasi tidak memunculkan wawasan. Itu membuat komputer bekerja lebih sedikit dan programmer lebih banyak.

Tentu saja, ada kategori yang berbeda, seperti dengan mendesain mobil. Tidak ada yang salah dengan mengoptimalkan mesin sebelum Anda membuat sasis pertama, tetapi mengoptimalkan sasis sebelum Anda tidak tahu bentuk mesin mungkin berakhir dengan buang-buang waktu. Modularitas dan spesifikasi bisa mendapatkan sejumlah tempat yang layak untuk pekerjaan optimasi bahkan sebelum produk secara keseluruhan dirakit.

Saya sangat tidak setuju dengan semua pernyataan itu bahwa kode tidak boleh dioptimalkan pada tahap awal. Itu tergantung pada tahap apa Anda. Jika ini adalah prototipe MVP dan Anda hanya mencoba untuk melihat permainan yang membutuhkan waktu 1 hingga 2 minggu, Anda siap untuk menulis ulang semua yang sudah Anda tulis. Ya, pengoptimalan tidak masalah. Tetapi jika Anda sudah mengerjakan game yang Anda tahu akan dirilis, itu harus dioptimalkan kode selama ini. Kisah-kisah yang orang katakan tentang fitur-fitur baru dan hal-hal yang dapat ditambahkan adalah kesalahan konsep. Ini arsitektur kode yang dirancang dengan buruk daripada kode yang dioptimalkan. Anda tidak perlu menulis ulang apa pun untuk menambahkan elemen baru jika Anda memiliki desain kode yang bagus.

Misalnya, jika Anda memiliki algoritma pathfinding A *, bukankah lebih baik untuk menuliskannya dengan cara yang paling optimal yang Anda bisa? Daripada kemudian mengubah setengah dari kode yang Anda miliki karena Anda harus membuat beberapa perubahan dalam algoritma karena sekarang perlu panggilan metode lain dan panggilan balik? Dan jika Anda sudah memiliki kode yang dioptimalkan sejak awal, itu akan menghemat banyak waktu. Karena Anda dapat menggambar sendiri hubungan antara objek dan bagaimana mereka berinteraksi, daripada membabi buta membuat banyak skrip baru dan membuat semua koneksi segera - ini mengarah pada kode sphagetti yang tidak jelas.

Hal terakhir yang ingin saya tambahkan adalah nanti, bahkan jika Anda tidak ingin membuat game lagi, Anda memiliki algoritma A * yang dioptimalkan yang dapat Anda gunakan untuk gim berikutnya. Dapat digunakan kembali. Misalnya, banyak game memiliki inventaris, penelusuran jalan, pembuatan prosedural, interaksi antara NPC, sistem pertarungan, AI, Interaksi antarmuka, manajemen input. Sekarang Anda harus bertanya pada diri sendiri - "Berapa kali saya menulis ulang elemen-elemen itu dari awal?" Mereka adalah 70-80% dari game. Apakah Anda benar-benar perlu menulis ulang sepanjang waktu? Dan bagaimana jika mereka tidak dioptimalkan?