Holivar tentang apakah menggunakan mesin untuk membuat game dimulai segera setelah mesin game pertama kali muncul.
Posting di reddit ini bukan contoh ideal dari argumen yang berlawanan terhadap penggunaan mesin yang konstan, tetapi saya percaya bahwa keinginan yang tak tertahankan untuk menggunakannya memberikan sedikit fanatisme.
Mari beralasan dengan bijak
Saya percaya bahwa tidak ada jawaban siap pakai untuk pertanyaan apakah pengembang harus menggunakan mesin. Pengembang yang bijak, sebelum memilih teknologi, mengevaluasi semua opsi yang memungkinkan.
Tingkat keterampilan
Apakah Anda memiliki keterampilan yang cukup untuk menggunakan opsi yang dipilih secara efektif? Jika Anda tidak memiliki pengalaman dalam pemrograman, Anda harus belajar banyak sebelum Anda siap untuk membuat game dari satu set perpustakaan yang berbeda.
Jika Anda tidak memiliki keterampilan teknis atau minat untuk mempelajarinya, maka benar-benar tidak ada pilihan - Anda harus bekerja dengan mesin (atau meyakinkan seseorang untuk melakukan bagian teknis untuk Anda; semoga berhasil dengan itu!).
Ada kondisi peralihan antara kurangnya keterampilan dan tingkat profesional. Ini terutama terletak di negara bahasa scripting: Awal, Pembuat Game, Pygame, Cetak Biru Nyata, LOVE2D, dll. Semuanya untuk mereka yang ingin memperoleh tingkat pengetahuan teknis tertentu agar dapat dengan cepat mencapai hasil.
Jika Anda seorang programmer berpengalaman / profesional yang dapat dengan percaya diri menguasai perangkat lunak pihak ketiga, maka Anda dapat menggunakan keterampilan ini dan memutuskan bagaimana pendekatan Anda akan minimalis / maksimal (apakah itu SDL yang sangat minimal atau Unreal Engine yang lengkap).
Tujuan pengembangan
Apa tujuan Anda dalam proyek ini? Teknologi harus memaksimalkan pencapaian mereka:
- Ini hobi untuk Anda dan yang paling penting adalah Anda ingin berkembang sebagai pengembang? Mungkin Anda harus menjauh dari Unity dan Unreal dan melihat ke arah pengembangan game berdasarkan perpustakaan tingkat rendah.
- Apakah ini bisnis untuk Anda? Pada level ini, banyak hal menjadi lebih rumit. Opsi harus dievaluasi berdasarkan banyak faktor: dapatkah Anda mempekerjakan orang yang akrab dengan teknologi? Apakah orang-orang ini ingin menggunakan teknologi? Apakah itu sesuai dengan kerangka waktu Anda? Apakah Anda memiliki keterampilan untuk menggunakannya secara efektif? Apakah artis / desainer Anda menyukai teknologi?
Bunga
Jika Anda bekerja lebih banyak (atau berencana untuk bekerja) dengan pengembang daripada sendirian, maka Anda perlu mengevaluasi bagaimana orang lain tertarik pada teknologi. Jika Anda bekerja dengan mesin / kerangka kerja lama yang dibenci semua orang, maka Anda akan kesulitan menemukan pengembang yang termotivasi untuk proyek Anda.
Juga pertimbangkan bagaimana seniman dan desainer akan berinteraksi dengan teknologi. Apakah Anda ingin membuat alat untuk mengejar fungsionalitas Unreal? Mereka pasti akan membandingkan kemampuan mesin dan mereka sendiri. Saya mendengar bahwa bahkan studio AAA memiliki masalah dengan artis yang membutuhkan fitur Unreal yang belum diimplementasikan dalam cabang Unreal studio saat ini.
Jika Anda bekerja sendiri, maka Anda perlu mempertahankan semangat yang kuat untuk proyek. Jika Anda membenci teknologi yang Anda gunakan untuk bekerja, kemungkinan besar Anda akan menyerah. Jika Anda menyerah, maka semua usaha Anda akan menjadi debu (dengan pengecualian pengalaman yang tak ternilai).
Apa yang sebenarnya mereka berikan padamu?
Jonathan Blow memiliki video yang luar biasa bijak tentang apa yang
sebenarnya diberikan oleh mesin game . Mereka memecahkan masalah "sederhana" untuk Anda, tetapi kemudian mereka menghalangi ketika mereka mencoba memecahkan masalah yang sulit, yang merupakan permainan yang mengasyikkan.
Ya, tentu saja, Anda mendapatkan editor yang hebat, alat tingkat profesional dan mesin yang telah datang ke ribuan pengembang, tetapi Anda membayarnya dengan banyak aspek lain:
- Terkadang solusi yang digunakan di dalamnya terlalu umum: mungkin dalam gim Anda gravitasi diterapkan dengan cara yang sama sekali baru, tetapi kemudian Anda harus bertarung dengan sistem gravitasi Unreal yang didefinisikan dengan kaku. Mungkin Anda sedang membuat proyek dengan model jaringan yang kompleks, dan kemudian Anda harus benar-benar menyingkirkan arsitektur server Unreal.
- Terkadang solusi terlalu khusus: jika Anda pernah menggali isi Unreal Engine, Anda melihat bahwa seluruh mesin penuh dengan kode penembak orang pertama. Jika Anda membuat game dengan genre ini, maka baiklah. Jika tidak, itu hanya akan membingungkan.
- Terkadang ada terlalu banyak hal di dalam mesin: ini membuat otak dan komputer menjadi tegang. Melakukan simulasi lengkap fisika solid-state, pipa 3D dengan animasi kerangka dan tiga kerangka kerja merupakan hal yang mutlak untuk gim 2D. Anda harus memikirkan cara menonaktifkan semua fitur Unreal ini, semoga berhasil. Secara pribadi, saya menemukan bahwa kinerja Unreal mengecewakan bahkan di dunia uji dengan beberapa objek.
Anda perlu mengajukan pertanyaan: "Apa yang benar-benar saya butuhkan?" Singkirkan semua yang tidak perlu. Setiap sistem yang tidak perlu adalah sumber daya dan waktu yang terbuang.
Apa yang dibutuhkan untuk proyek Anda?
Teknologi harus dikelola oleh proyek Anda, kecuali jika itu adalah demo teknologi. Jika Anda membuat game, maka Anda hanya perlu bekerja dengan teknologi yang memengaruhi game - hanya dengan yang paling penting untuk menyampaikan visi Anda. Jika mesin memberi Anda cara tercepat untuk merilis game Anda, maka ini adalah pilihan yang baik. Tapi ini tidak akan selalu terjadi!
Ada game-game sukses yang akan melayani layanan buruk dari salah satu mesin yang tersedia:
- Untuk Dreams , renderer khusus ditulis yang menyederhanakan dan mempercepat pembuatan aset 3D yang intuitif.
- No Man's Sky secara aktif menggunakan metode generasi prosedural yang sepenuhnya baru. Ketika menerapkan hal-hal seperti itu di mesin, Anda harus terus-menerus menghadapinya.
- Di Minecraft , hanya beberapa fitur engine standar yang dapat digunakan.
Masa depan industri Anda (dan kami)
Saat menggunakan teknologi apa pun, ada baiknya memikirkan
penutupan . Joel Spolsky memiliki serangkaian artikel tentang strategi bisnis untuk pengembangan perangkat lunak, di mana ia merefleksikan
penutupan produk . Singkatnya, idenya adalah bahwa perusahaan tertarik menahan Anda untuk menggunakan produk mereka, karena jika Anda tidak menggunakan produk, maka mereka tidak menghasilkan uang. Master dalam menangkap seluruh industri adalah Apple, Microsoft, Adobe dan Autodesk, mereka menciptakan perasaan bahwa tidak ada alternatif lain selain perangkat lunak mereka.
Penutupan bahkan mempengaruhi pengembang hobi / solo. Saya punya teman yang terus-menerus berjuang dengan Unity (pembaruan pemecahan masalah, sistem prototyping, adware, dukungan 2D yang buruk ...). Dia ingin pergi dari Unity, tetapi sangat terkunci ke dalam mesin ini karena sebagian besar kodenya (dan data) bergantung pada Unity API.
Mengapa mesin membeli?
Unreal dan Unity didorong oleh persyaratan pasar. Klien tingkat AAA mereka, dengan bantuan kontrak multi-juta, menentukan arah pengembangan mesin lebih lanjut. Jika Anda mengerjakan game yang strukturnya tidak sesuai dengan tujuan para pemain AAA ini, maka para pengembang mesin tidak akan melayani Anda dengan setia. Misalnya, game dua dimensi, prosedural, eksperimental, voxel, dan game dengan data dalam jumlah besar hampir selalu harus mencari sesuatu sendiri.
Semakin cerah fungsinya, semakin banyak manajemen perusahaan (yang paling sering bukan teknisi) berupaya menggunakan mesin. Fitur seperti cetak biru mesin Unreal sangat populer di kalangan seniman dan desainer, tetapi mereka menimbulkan banyak masalah bagi programmer. (Ini tipikal dari bahasa scripting apa pun; jika Anda mengizinkan orang yang belum mempelajari pemrograman ke program, hasilnya akan buruk, mirip dengan seberapa buruk grafik yang dibuat oleh programmer buruk).
Apakah fitur baru benar-benar membuatnya lebih mudah untuk menyelesaikan permainan Anda? Apakah mereka benar-benar menambah nilai pada produk akhir?
Perangi Sentralisasi
Setiap kali salah satu studio beralih dari mesinnya sendiri ke perusahaan Unreal atau Unity, Epic dan Unity mendapatkan kekuatan lebih besar di industri game. Pada awalnya, sentralisasi seperti itu mungkin tampak menguntungkan (setelah semua, mereka memiliki 500 insinyur yang mengerjakan mesin, sangat baik!), Tetapi dalam beberapa dekade ini akan menjadi masalah nyata. Google muncul di benak: perusahaan ini telah menangkap sebagian besar fungsi yang digunakan orang di Internet, dan itu membuat mereka kehilangan sebagian besar privasi.
Bahkan pada tingkat hobi, meninggalkan penelitian demi Unreal atau Unity membahayakan generasi mesin masa depan. Hal ini dapat merugikan Unreal sendiri: jika semua orang menggunakan Unreal, Epic tidak akan dapat mempekerjakan orang lain untuk membuat generasi mesin baru, karena tidak ada yang akan tahu bagaimana mesin permainan ditulis!
Masa depan mungkin open source
Jika kita, sebagai industri, ingin tumbuh, menciptakan lebih banyak dan lebih banyak produk berkualitas tinggi, maka kita perlu berbagi lebih banyak, bukan lebih sedikit, untuk berbagi teknologi.
Saya pikir industri bergerak ke arah ini, meskipun sangat lambat. Ini terutama berlaku untuk studio game tingkat AAA, yang masih menyembunyikan kode mesin mereka untuk mendapatkan keunggulan kompetitif (imajiner?).
- Microsoft telah mengambil langkah besar ke arah ini. Jika bahkan mereka berubah, maka saya yakin orang lain bisa.
- Perjanjian lisensi Unreal berisi klausa yang memungkinkan Anda untuk bergantung pada kode ketika bekerja pada mesin sendiri (milik atau gratis). Saya pikir ini adalah kemajuan besar.
- Berkat keterbukaan lengkap dan akses gratisnya, Godot mendapatkan popularitas besar, dan saya harap jika dia diberi cukup waktu dan dukungan, dia akan menjadi pesaing bagi Persatuan (dan akhirnya Unreal).
- id Software (di era John Carmack) merilis kode sumber lengkap dari Doom ke Doom 3 . Carmack punya banyak alasan untuk memajukan keputusan semacam itu. Yang paling meyakinkan dari ini untuk perusahaan adalah tidak merusak penjualan. Model shareware yang digunakan oleh Doom - pengembang memberikan mesin dan menjual data - dapat menjadi strategi yang efektif saat ini. Jika bisnis Anda khawatir bahwa pesaing akan "mencuri" teknologi Anda, Anda dapat mempublikasikan kode Anda setelah game yang lebih baru dirilis setelah itu (seperti id lakukan). Setelah kepergian Carmack, id tampaknya telah kehilangan minat dalam menerbitkan kode.
Kualitas perangkat lunak
Jonathan Blow dan
Casey Muratori adalah kritikus yang gigih terhadap praktik penulisan perangkat lunak modern. Pandangan mereka adalah bahwa kami telah menciptakan add-on di atas lapisan abstraksi begitu lama sehingga kami mendapatkan lapisan besar sampah yang tidak perlu, dan ini tidak memungkinkan kami untuk menulis produk yang lebih baik.
Mungkin filosofi mereka lebih dekat dengan idealisme daripada pragmatisme (yang biasanya menyebabkan keterlambatan dalam rilis game), tetapi jika itu dekat dengan Anda, maka Anda tidak boleh mengabaikannya.
Apakah kecepatan, kualitas, dan keanggunan teknologi Anda penting bagi Anda? Banyak orang cukup senang dengan jawaban negatif, tetapi beberapa ingin membuat program dengan cara yang lebih "bersih".
Apa alternatifnya?
Alih-alih menggunakan mesin, Anda hanya menulis game.
Pemula sering berpikir bahwa mereka membutuhkan mesin untuk membuat permainan. Dengan tingkat probabilitas yang tinggi, mereka harus menolak sudut pandang ini. Para pemula akan menghabiskan waktu untuk mengimplementasikan fungsi-fungsi engine yang tidak berguna, alih-alih membiarkan game memutuskan sendiri apa yang benar-benar dibutuhkan. Hanya permainan yang harus mengendalikan apa yang dibutuhkan dari mesin (tentu saja, Unity dapat dianggap sebagai contoh tandingan, sebagai contoh pendekatan "engine first"; Unreal Engine 4 memiliki Paragon, Fortnite dan Unreal Tournament untuk mendukung konsep ini, belum lagi puluhan tahun pengalaman merilis game dalam jumlah tak terbatas di versi mesin sebelumnya).
Menggunakan perpustakaan
Mulai dari awal hanya masuk akal jika Anda memiliki keterampilan dan rencana untuk menciptakan inovasi dalam komponen tertentu (atau memiliki keterbatasan). Dalam semua kasus lain, ada banyak perpustakaan untuk integrasi. Ini sangat baik ketika Anda tahu bahwa, misalnya, sistem fisika standar benar-benar cocok untuk persyaratan proyek Anda (ini sangat penting karena untuk menerapkan fisika Anda sendiri, Anda memerlukan banyak pengetahuan di bidang ini).
Berikut adalah beberapa perpustakaan yang dapat mengisi kesenjangan antara bekerja dari awal dan menggunakan mesin yang sudah selesai:
- Gambar: SDL, SFML, Ogre
- Fisika: Bullet, PhysX (yang baru-baru ini menjadi open source - kemenangan besar!)
- Suara: SDL, SFML
Ini hanya sebagian kecil dari perpustakaan yang ada.
Nilai tambah besar dalam menggunakan perpustakaan adalah memberi Anda fleksibilitas terbesar di antara semua opsi. Jika Anda menulis semua kode dalam satu mesin, maka Anda harus melakukan upaya besar untuk port itu. Jika Anda menulis game sebagai kumpulan perpustakaan, Anda memiliki mobilitas yang hebat dan dapat mengganti seluruh subsistem. Jika perpustakaan tidak memenuhi persyaratan Anda, maka Anda dapat mencoba yang lain atau bahkan menulis pengganti Anda sendiri.
Selain itu, Unreal dan Unity mendukung impor pustaka yang terhubung secara dinamis. Ini berarti Anda dapat mulai bekerja dengan perpustakaan, dan kemudian beralih ke Unreal tanpa harus menulis ulang semua kode dasar gameplay, karena itu ada di perpustakaan. Agar kode cukup fleksibel untuk perubahan besar seperti itu, diperlukan perhatian serius, tapi saya pikir itu layak untuk proyek rata-rata atau jangka panjang.
Kesimpulannya
Saya menyajikan beberapa sudut pandang di mana teknologi dapat dipertimbangkan saat memilihnya. Habiskan beberapa minggu untuk studi terperinci, dan ini dapat menghemat beberapa bulan kerja porting atau bahkan ketidaknyamanan bertahun-tahun di masa depan.
Pada akhirnya, tugas utama Anda adalah menyelesaikan proyek. Anda harus melakukan segala upaya untuk menemukan jalan terpendek untuk menyelesaikan masalah ini. Ini mungkin sangat tidak terduga untuk Anda!