"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.