Mengapa pengembang game menulis engine sendiri alih-alih menggunakan yang sudah ada?


41

Saya telah mengamati bahwa banyak pengembang game besar dan terkenal sering mengembangkan mesin mereka sendiri. Contohnya termasuk Valve, Crytek, Ubisoft, Epic Games dan Square-Enix.

Mungkinkah itu karena mereka bisa, atau apakah mesin yang ada tidak memenuhi persyaratan yang cukup, jadi kita akan mengembangkan sendiri? Saya hampir tidak bisa membayangkan permainan yang membutuhkan mesin tertentu. Orang-orang seperti Unity atau Unreal hanya cukup untuk membuat jenis permainan apa pun; bahkan jika tidak, mereka memiliki kode sumber, yang dapat dimodifikasi untuk memenuhi bahkan beberapa kebutuhan luar biasa.

Mengapa pengembang game menulis engine sendiri alih-alih menggunakan yang sudah ada?



1
Mereka tidak ingin melisensikan mesin permainan perusahaan lain dan membayar mereka.
János Turánszki

Saya kira itulah yang Anda lakukan ketika Anda memiliki 9K + karyawan yang berbaring ...
glampert

3
Ada beberapa contoh tandingan dari studio besar yang membuat judul AAA menggunakan mesin pihak ke-3 seperti Unreal atau CryEngine .
Philipp

3
Valve mulai menggunakan mesin Quake, kemudian akhirnya menulis sendiri untuk game-game selanjutnya. Ini sering merupakan masalah belajar menggunakan apa yang tersedia, kemudian pada akhirnya ingin mencapai sesuatu yang lebih dari apa yang ditawarkan mesin yang ada. Pada titik mana Anda harus membuat modifikasi berat atau roll sendiri.
Nairou

Jawaban:


53

Ada beberapa alasan studio dapat memilih untuk "membangun" daripada "membeli" teknologi mereka:

  • Teknologi warisan; sebuah studio mungkin sudah mulai membangun rantai alat mereka sendiri sebelum ada, middleware yang layak untuk itu.
  • Persyaratan khusus; studio mungkin memiliki koleksi persyaratan tertentu yang tidak cocok untuk middleware yang ada atau
  • Masalah anggaran; studio mungkin tidak mampu membayar biaya atau kewajiban kontrak dari middleware yang ada.
  • "Sindrom tidak dibangun di sini;" kepemimpinan teknis studio mungkin waspada (secara masuk akal atau tidak masuk akal) dari teknologi yang tidak mereka bangun dan karena itu tidak sepenuhnya mengerti.

Secara umum, masuk akal untuk memiliki dan mengendalikan hal-hal yang penting untuk keberhasilan bisnis Anda, dan untuk melakukan outsourcing terhadap hal-hal yang tidak.

Untuk beberapa studio, aspek desain atau cerita dari permainan mereka mungkin merupakan sumber daya kritis yang mereka harapkan dapat dimanfaatkan untuk kesuksesan. Untuk studio-studio itu, masuk akal untuk hanya membeli teknologi yang akan memungkinkan desainer mereka untuk mewujudkan visi yang sesuai.

Bagi yang lain, teknologi mungkin menjadi dasar untuk sukses. Studio yang membangun MMO, misalnya, umumnya akan perlu membangun infrastruktur itu sendiri karena sangat penting untuk keberhasilan mereka (dan middleware yang ada umumnya tidak sesuai, setidaknya untuk judul "AAA" yang lebih besar).

Perhatikan bahwa beberapa studio yang Anda daftarkan (Crytek dan Epic khususnya) pada dasarnya berhenti mencoba untuk menjadi kekuatan yang mendominasi di pasar game secara langsung, dan hampir pasti menghasilkan jauh lebih banyak sebagai vendor middleware daripada yang mereka lakukan sebagai pengembang game.


20
Saya ingin menambahkan bahwa terkadang ada keuntungan dari teknologi yang "dibangun di sini." Salah satu contoh adalah bagaimana Unity3D mengubah EULA mereka setiap versi dan menambahkan batasan aneh, seperti tidak ada "permainan judi." Ketika Anda melisensikan teknologi, Anda berada di bawah kekuasaan pemberi lisensi untuk tidak berbalik dan mencabut lisensi tanpa alasan tertentu (seperti yang terjadi pada hak IP untuk membuat game berlisensi) atau memutuskan untuk menagih Anda untuk memperbaiki bug mereka untuk mereka.
Skrylar

serius, Unity mengatakan "tidak ada permainan judi"? Mereka bahkan pernah memiliki halaman khusus tentang judi di bagian Komunitas di situs web mereka!
jhocking

Halaman Unity di sini unity3d.com/industries/gambling mengatakan Anda dapat membeli "lisensi Unity Gambling". Saya belum menemukan harga untuk itu, tetapi sepertinya mereka masih memungkinkan Anda membuat game untuk perjudian asalkan Anda membayar untuk lisensi khusus.
Alex

1
Selain itu, lebih mudah untuk memulai dengan apa yang sudah Anda ketahui dan akhirnya membangun mesin, bahkan tidak tahu apa itu mesin. Mesin tidak lain adalah sekumpulan use case; jika Anda mencoba mengurangi redundansi, Anda akhirnya menulis sebuah mesin, dan jika Anda hanya ingin membangun gim, Anda berakhir dengan sistem monolitik. Sangat sulit untuk mendapatkan mesin gim dan belajar cara menampilkannya dengan piksel, kemudian menyadari bahwa ia tidak dapat melakukan itu karena ia melihat semuanya sebagai tekstur. Anda tidak harus berurusan dengan itu ketika menulis sendiri.
Dmitry

18

seperti yang dikatakan oleh Josh Petrie :

" Sindrom tidak dibangun di sini ;"

Saya juga menulis mesin saya sendiri, dan saya kira alasannya akan berbeda untuk setiap pengembang di luar sana, tetapi pada kenyataannya - saya biasanya tidak suka bekerja di kode orang lain. Saya kompulsif dalam arti bahwa jika saya merasa saya bisa membangunnya sendiri, maka tidak ada gunanya puas dengan hal lain .

Saya menguji berbagai jenis mesin permainan, rendering API dan semacamnya, terutama Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre, dll. Banyak lagi ... Saya ingin mulai menulis game - Saya mengunduh banyak hal untuk mencari kenyamanan yang baik dan titik masuk yang didokumentasikan dengan baik ...

Masalah saya, pada saat itu saya tidak tahu apa yang terjadi di bawah mesin. Saya ingin kontrol yang baik, dan saya ingin kerangka kerja yang saya tahu seperti punggung tangan saya. Saya datang dengan ide "HEY! Saya pikir satu-satunya cara saya akan belajar bagaimana hal itu bekerja dan memahaminya adalah dengan mencoba membangun mesin saya sendiri sepenuhnya dan sepenuhnya dari awal. Sebagian besar sejarah pemrograman saya adalah dengan solusi web dan pemrosesan - Ini adalah permainan bola yang sepenuhnya baru bagi saya.

Itulah yang akhirnya saya lakukan.

Jadi saya memilih untuk mengatur XNA karena saya sudah tahu C #, dan mulai berpikir tentang bagaimana atau di mana saya harus mulai. Saya butuh ide.

Saya memutuskan bahwa, apa pun yang terjadi, saya akan langsung masuk ke 3D .

Mendapatkan dasar-dasar itu keren - hal-hal batch sprite, tetapi ketika saya berkembang saya akhirnya menemukan hambatan dan hambatan baru - yang pertama saya nyata adalah batas batch . Tujuan saya adalah untuk membangun game yang dapat membuat setidaknya 10.000 entitas dalam tampilan frustum setiap saat.

Saya memulai perjalanan baru mengimplementasikan Shader Based Instancing (dan belajar HLSL ketika saya berada di sana), saya membuang objek Model and Effect yang dibuat XNA untuk menulis pengganti saya sendiri. Saya mengalami kesulitan memahami aliran VBO pada awalnya; Saya memecahkan banyak hal - saya online bertanya tentang hal-hal yang dipasang dan terus melakukannya sampai saya akhirnya mengerti apa yang dilakukan GPU. Itu terbayar; sekarang saya memiliki lebih dari dua puluh ribu entitas uji yang diperbesar di viewport saya setelah beberapa hari debugging VBO saya dengan PIX (dxsdk).

Sekarang saya memiliki "beberapa" ide tentang bagaimana cara kerja rendering pipeline, tetapi belum selesai - saya akhirnya membuat game-state, kamera, efek posting, dan objek entitas saya sendiri, menjauh dari XNA Content Pipeline dengan membangun sendiri loader (ketidaksukaan pribadi terhadap hal XNB), menciptakan kedalaman rumit yang diurutkan dan rantai campuran geometri dipisahkan-negara dan juga telah menanamkan sprite dan teks semua diproyeksikan ke dalam adegan permainan.

Saya terus menambahkan, memperbaiki, mengubah dan bereksperimen dengan ini terus menerus selama hampir satu tahun penuh. Pada akhirnya, hasilnya cukup bagus. Saya sekarang memiliki pemahaman tentang apa yang terjadi di bawah tenda, karena saya menciptakannya - bayi saya.

Sekarang mesin saya sebagian besar stabil dan hampir selesai. Itu tidak sempurna: skripnya honky dan GUI tidak bagus sama sekali. Tapi saya masih menyukainya. Ribuan baris kode, aset, dan media - bersembunyi di repositori git 2GB pribadi, dan semua sakit kepala yang harus saya lalui ketika mencoba melakukan jenis pengembangan yang belum pernah saya lakukan sebelumnya. Setiap rintangan yang saya atasi adalah pelajaran yang dipetik - dan melegakan.

Saya melakukan hampir semua yang saya inginkan di dalamnya.

Tetapi pada akhirnya - saya memutuskan sudah waktunya untuk menurunkannya. Seperti aku puas diri menulis seperti mesin besar sendiri, dengan saran dari jaring, dan teman gamedev lain, saya memutuskan bahwa aku akan melakukannya lagi - dan melakukannya dengan lebih baik - karena sekarang kali ini aku kebanyakan tahu apa yang aku lakukan.

Proyek itu masih tersimpan di repo GIT saya.

Lulus kedua saya saat menulis mesin baru (kali ini di MonoGame), mengalami kemajuan dengan baik. Ketika sesuatu rusak, lebih mudah untuk memperbaikinya. Kurang berantakan. Saya berharap untuk memamerkan permainan saya di depan umum tahun ini, karena saya cenderung agak 'terlalu' melekat pada kode saya.

Pada akhirnya, menulis mesin saya sendiri adalah bagaimana saya belajar 'bagaimana' melakukannya, sambil dapat mengatakan bahwa saya tahu dan mengerti persis apa yang dilakukan setiap komponen, dan bagaimana mereka seharusnya bekerja. Saya sebenarnya BENCI membaca kode orang lain, terutama untuk proyek-proyek besar tanpa dokumen. Saya ingin semua yang saya gunakan dibangun oleh saya.

Ini hanya aku saja. Saya ragu saya akan pernah menggunakan mesin pre-made, mungkin karena saya pikir itu lebih menyenangkan bagi saya untuk menulis kerangka kerja saya sendiri daripada duduk dan berurusan dengan kode orang lain - kontrol penuh.


13
Ini jauh lebih mirip anekdot pribadi yang bertele-tele; Anda mungkin dapat mengedit ini untuk membuatnya lebih ringkas dan itu akan membuat jawaban yang lebih baik.
Josh

2
Ini semua pasti bagus untuk belajar dan juga untuk membuat game Anda ketika Anda memiliki waktu untuk melakukan semuanya. Saat itu memang hanya Anda. Tetapi bagaimana jika Anda ingin berkolaborasi dengan seseorang? Atau bekerja di perusahaan dengan programmer lain? Jika seseorang ingin bergabung dengan proyek Anda, bukankah agak aneh bahwa mereka seharusnya membaca kode Anda - bagi mereka kode orang lain .. hal yang paling Anda BENCI. Saya menemukan bahwa membaca kode juga merupakan keterampilan yang sangat penting. Jangan tersinggung, saya yakin Anda telah belajar banyak dan menulis mesin keren - hanya catatan bahwa tidak semua ada untuk itu.
sebelum

Saya sadar akan hal itu, setiap pekerjaan yang saya lakukan melibatkan semua jenis kode dalam bahasa apa pun, selalu solo untuk saya D;
Codie Morgan

Saya harus mengatakan, saya tahu persis untuk alasan apa seseorang mengeluarkan mesin / alatnya sendiri atau apa pun. Tetapi ada harganya (seperti semua hal) ... Saya punya perasaan bahwa semua bos dengan jelas membencinya ketika Anda tidak bisa membaca / memahami kode yang paling jelek di luar sana, jadi silakan lanjutkan dan masukkan diri Anda sebagai ** * ton kode yang dikelola dengan buruk dikelola tanpa dokumentasi, hanya merasakan untuk itu (dunia "nyata"). Tanpa bermaksud menyinggung.
Quonux

Itulah alasan kami, programmer, tidak dapat memiliki hal-hal yang baik. Karena kami selalu ingin membuat semuanya sendiri alih-alih menggunakan metode yang bekerja dan tepercaya. Saya memiliki kebutuhan kompulsif untuk menulis semuanya sendiri, tetapi saya perlahan-lahan belajar untuk memercayai orang lain dan sejauh ini saya lebih baik daripada yang buruk :)
Maurycy

15

Alasan kunci mutlak untuk menulis mesin Anda sendiri (dan ini mengejutkan saya bahwa belum ada yang memanggil ini) adalah untuk debugging .

Jika Anda telah menulis gim besar dan rumit, dan ada bug kerusakan di dalamnya, dan Anda memiliki kode sumber (dan sangat akrab dengan kode sumber karena telah menulisnya), maka Anda dapat dengan mudah melampirkan debugger ke proses dan temukan apa yang menyebabkan crash. Selesai

Jika Anda menggunakan mesin orang lain yang tersedia secara komersial, dan Anda tidak memiliki kode sumber untuk mesin itu (Anda biasanya tidak), maka debugging masalah yang muncul - bahkan di dalam kode Anda sendiri - akan terjadi menjadi lebih sulit secara monumental. Dan jika Anda menemukan bug di dalam mesin itu sendiri, Anda tidak akan bisa menyelesaikannya sendiri. Bagaimana Anda ingin keluar seminggu dari tanggal rilis dan meminta seseorang menemukan crash crash di mesin yang Anda gunakan - bug crash yang tidak dapat Anda perbaiki karena berada di dalam mesin berpemilik yang tidak Anda miliki punya kode sumber? Saya telah melihat ini terjadi - Anda tidak punya pilihan selain mengajukan panggilan dukungan mendesak kepada vendor dan berharap mereka dapat (dan tertarik) memperbaiki masalah untuk Anda, saat Anda mencari-cari,

Pengembangan game sulit, tetapi debugging adalah perintah yang jauh lebih sulit. Dalam buku saya, apa pun yang membuat pengembangan game lebih sulit tetapi lebih mudah melakukan debug adalah kemenangan besar .


3
Ini adalah salah satu keuntungan besar yang kami alami dengan menggunakan mesin open source (cocos2d-iphone). Kita dapat men-debugnya dengan cara yang persis sama dengan kode yang kita tulis. Saya benar-benar menemukan bahwa cara untuk memikirkan open source adalah bahwa itu kode Anda. Jika ada bug kita harus memperbaikinya, seperti di bagian lain dari kode kita ..
antont

1
Ini dapat dikatakan tentang middleware apa pun . Kode debug adalah 80% dari pekerjaan programmer, dan menangani middleware adalah masalah umum dengan teknologi yang kita duduki hari ini dengan lebih banyak middleware daripada yang bisa kita hitung. Belajar untuk mengatasinya hanyalah sebagian dari pekerjaan. Jika mesin tidak rusak, ada hal lain yang tidak Anda kendalikan. Lebih sedikit bagian yang bergerak adalah ide yang baik, tetapi ketika menjadi rumit seperti game dev, maka Anda harus berurusan dengan banyak dari mereka.
Tim

@Tim saya sangat tidak setuju - bahwa satu hal eksternal mungkin berperilaku tidak pantas dengan cara yang sulit untuk di-debug tidak menyiratkan bahwa kita seharusnya hanya mengangkat bahu dan mengundurkan diri untuk membiarkan segala sesuatu berperilaku tidak pantas dengan cara yang sulit untuk di-debug. Satu jelas perlu mengambil hal-hal berdasarkan kasus per kasus, tetapi mesin adalah sistem besar di mana bug rumit sering mengintai. Mengapa Anda tidak ingin itu di bawah kendali Anda, jika Anda dapat membuatnya sendiri?
Trevor Powell

@TrevorPowell Ini jelas berkaitan dengan kompleksitas proyek dan seperti yang Anda katakan, kasus per kasus, tetapi hanya menciptakan kembali roda (terutama jika itu adalah roda besar) perlu dipertimbangkan secara serius mengenai waktu yang dihemat dengan tidak melakukan saya t. Middleware membuat segalanya lebih mudah. Sebagai pengembang, kami percaya kami selalu dapat menemukan kembali solusi untuk menjadikannya lebih baik tanpa mempertimbangkan seberapa baik solusi tersebut disatukan. Beberapa gundukan> penemuan kembali> Solusi yang salah seluruhnya
Tim

2
@Tim RE: "Middleware membuat segalanya lebih mudah", saya memiliki pengalaman yang sangat berbeda dari Anda, rupanya.
Trevor Powell

9

Ada jawaban yang sangat bagus di sini tetapi mereka kehilangan satu poin tambahan penting.

Banyak mesin berlisensi saat ini dimulai sebagai mesin khusus .

Mari kita ambil Unreal sebagai contoh karena begitu ada di mana-mana.

Hari ini ketika Anda memikirkan Unreal Anda cenderung memikirkan mesin yang Anda lisensikan dan dapat digunakan alih-alih harus membuat sendiri, tetapi itu tidak selalu terjadi, dan pada suatu saat mesin Unreal bahkan tidak ada sebagai entitas yang terpisah.

Sekali waktu ada permainan yang disebut Unreal . Para pengembang itu memutuskan untuk membangun mesin mereka sendiri daripada melisensikan yang sudah ada . Maju cepat melalui beberapa iterasi dan mesin itu menjadi mesin Unreal yang kita kenal sekarang.

Intinya adalah bahwa ini adalah masalah ayam dan telur. Setiap bit middleware yang Anda dapat lisensinya dimulai di suatu tempat, dan sering tidak dimulai sebagai middleware sama sekali (kadang-kadang bahkan tidak ditulis dengan maksud menjadi middleware dan statusnya saat ini secara efektif kecelakaan ). Orang-orang menulis mesin mereka sendiri karena pada akhirnya seseorang harus menulis mesinnya, dan mesin khusus hari ini mungkin menjadi middleware yang dapat dilisensikan di masa depan.


2
Perlu dicatat, bahwa pada hari itu, ketika game seperti Unreal pertama kali dibangun, tidak ada pilihan lain selain menulis semuanya dari awal. Ini hanya beberapa tahun terakhir di mana kita memiliki pilihan mesin N ...
joltmode

3

Ada alasan lain mengapa studio dapat memilih untuk "membangun" daripada "membeli" teknologi mereka:

  • Platform baru: OS seluler baru, konsol atau pengontrol. Pikirkan tentang leapmotion, google glass, dll. Dukungan cross-plataform sulit
  • Mekanik game baru dan / atau editor dalam game : Pikirkan tentang FEZ, beberapa tahun yang lalu (2D vs 3D)
  • Kurangnya editor permainan sumber terbuka gratis yang bagus . Kurangnya dokumentasi yang bagus tentang sumber game lama yang ada
  • Evolusi alat di studio toolchain (atau tambahkan yang baru)
  • Harga mesin dan perang lisensi

Saya juga setuju dengan permintaan / kebutuhan khusus dan harga mesin serta perang lisensi memaksa beberapa studio untuk meluncurkan beberapa mesin.

Motif yang baik untuk "membeli" atau "menggunakan" mesin lain adalah:

  • Penggunaan Kembali Kode : mesin yang sudah digunakan dalam gim lain lebih teruji, lebih stabil, dan mungkin memiliki sebagian besar fitur yang diperlukan, mulai dari hari pertama.
  • Perluas : Anda dapat memperluas beberapa mesin sumber terbuka.
  • Gratis : atau hampir gratis, karena bahkan mesin open source gratis, perlu waktu pengembang untuk belajar.

2

Alasan historis (kebanyakan).
Yang terkait dengan harga.

Setiap permainan yang Anda lihat menjalankan Unreal atau CryEngine dalam beberapa tahun terakhir harus membayar sejumlah besar uang. Terutama jika Anda ingin mendapatkan kode sumber (mis .: Anda menginginkan UE, bukan UDK saja.)

Tapi ini berubah. Sekarang semua orang dapat membeli mesin yang lebih besar, ketika perlombaan harga dimulai.
Apa itu artinya...

  • Anda akan melihat lebih banyak game menggunakan UE4 dan CryEngine.
    Padahal, mereka tidak akan menjadi game AAA seperti sebelumnya.
  • Persyaratan dan kebutuhan khusus untuk setiap proyek tidak akan hilang.
    Lihat mesin Warhammer40k / COH di Relic, atau yang digunakan Jenderal pada EA.
    Jadi, bahkan jika ada yang mampu membeli mesin yang lebih besar, mereka tidak perlu menawarkan pilihan yang lebih baik.
  • Ada yang lain di pasaran. Seperti Persatuan.
    Orang-orang menyukainya karena kemudahan penggunaannya, kinerja cepat, dan toko aset yang sangat besar.
    Tentu saja, Unity dapat digunakan untuk hampir semua platform.

Jadi ya. Kebutuhan, harga di masa lalu dan semacamnya.


1
Saya tidak akan menyebut Havok "sangat dimodifikasi."
Josh

Bukankah Havok hanyalah mesin fisika?
Philipp

Ya, dan GW2 tidak melakukan banyak catatan untuk itu yang bisa saya ingat.
Josh

Bukankah maksud Anda (ie.: you want UE, not UDK only.)?
Keavon

#JoshPetrie: Maaf, jujur ​​saja, saya tidak berpengalaman di Havok / saya tidak pernah bermain dengannya. Jadi saya menemukan file LICENSE GW2 dan kemudian mengunjungi halaman wiki itu beberapa hari yang lalu dan melihat Havok. Kemudian saya memiliki beberapa memori lama tentang melihat "Havok" pada permulaan permainan, di mana saya pikir itu adalah mesinnya. Tapi kemudian saya juga melihat Havok saat itu dan saya tahu itu adalah mesin fisika. tl; dr: Saya campur aduk tentang Havok. || #Philipp: Sedikit lebih dari itu, tapi memang itu bukan mesin game, salahku. || #Keavon: Benar, sudah diperbaiki. Terima kasih!
Apache

0

Bagaimana dengan organisasi tim?

Di belakang hal-hal debug adalah dokumentasi & dukungan, tidak ada kode, karena pada akhirnya saya tidak ingin bahwa grup bangunan saya akan menyentuh kode mesin saya sendiri. Itu bisa berantakan.

Jadi, saya memerlukan kelompok pendukung untuk melakukan itu. Tapi itu menimbulkan biaya: lebih banyak orang, lebih banyak tempat, lebih banyak telepon, lebih banyak administrasi ...

Salah satu solusi untuk ini mungkin outsourcing ... ke perusahaan middleware, melepaskan sumber daya untuk bisnis saya membuat game, yaitu ke grup kreatif dan penulis.

Untuk perusahaan pemula itu bukan pilihan yang buruk untuk digunakan dan tidak membangun. Dan, setelah mendapatkan banyak pendapatan, mungkin, mungkin saja, Anda ingin membangun mesin sendiri ...


0

baik. untuk sebagian besar game yang menggunakan mesin mereka sendiri yang dibuat oleh pengembang mereka. sering. mereka tidak dapat melakukan hal-hal dengan mesin pihak ke-3. jadi mereka membuat sendiri untuk membuat pengembangan gim mereka sendiri lebih mudah dilakukan. atau paling tidak mungkin.

dan banyak game yang menggunakan mesin mereka sendiri secara umum. bekerja lebih baik. karena mereka lebih khusus dan 100% sesuai dengan tugas mereka. dan permainan itu sendiri terasa berbeda. sangat mudah untuk memainkan game dan mengatakan itu dibuat oleh. mesin tidak nyata atau apa pun. lebih banyak mesin kustom pada umumnya dan harus menghasilkan permainan yang terasa unik. terlihat unik dan bekerja secara unik dan itu harus berkinerja lebih baik daripada game yang dibuat pada mesin pre-made.


0

Jawaban saya berbeda dari yang sudah ada, jadi saya menambahkannya meskipun sudah terlambat:

Jika Anda mengambil contoh Valve dari pertanyaan, atau seri Witcher prosesnya adalah:

  • Lisensi mesin
  • Ubah / sesuaikan mesin dengan tujuan Anda
  • Lepaskan game dan hasilkan uang
  • Buat mesin sendiri untuk game berikutnya

Pendekatan yang sama diambil oleh hampir semua pengembang yang layak secara finansial yang mengembangkan mesin mereka sendiri. Dengan memodifikasi mesin mereka membangun pengetahuan bagaimana mesin bekerja, dan mengalami kendala desain yang dihasilkan dari mesin berlisensi. Pada akhirnya mereka memiliki pengetahuan internal yang diperlukan untuk membuat mesin, uang tunai untuk mendanai pembuatan mesin, dan proyek yang akan mendapat manfaat dari mesin khusus. Pada saat itu alasan untuk membangun mesin adalah: Karena itu adalah hal yang cerdas untuk dilakukan.


-2

guru pemrograman saya memberi tahu kami, hanya gunakan API / metode / kelas / fungsi yang Anda tahu cara membangun

karena jika Anda tidak tahu cara membangunnya dan menggunakan pekerjaan orang lain kemungkinan Anda tidak tahu cara kerjanya dan ketika Anda tidak tahu bagaimana sesuatu bekerja maka Anda jauh lebih rentan terhadap kesalahan dan masalah dan menabrak dinding kebingungan

mempelajari hal-hal sederhana dapat ketika diperparah menghasilkan masalah aneh, apalagi sesuatu yang rumit seperti mesin gim terutama ketika Anda seharusnya menggunakan mesin gim itu untuk menjalankan gim Anda yang dapat menyebabkan banyak hasil dan masalah yang tidak terduga

dan mesin permainan tidak mengikuti kode logis atau logika lainnya ketika dibangun, tentu ada beberapa hal yang dapat diharapkan tetapi pada kenyataannya semuanya akan dibangun berdasarkan pemahaman dan pengetahuan seseorang tentang beberapa bahasa pemrograman atau bagaimana beberapa sistem bekerja

misalnya jika saya memilih untuk menulis persamaan matematis saya dapat menulisnya dengan banyak cara saya dapat mewakilinya dengan polinomial, atau kalkulus diferensial atau geometri dasar atau aljabar atau apa pun yang cocok untuk saya tetapi kadang-kadang saya akan menulis dalam bentuk / format tertentu karena saya ingin untuk dapat memanipulasi apa yang mudah tersedia, seperti jika saya berencana untuk melakukan banyak manipulasi vertex saya mungkin menulis model matematika ini menggunakan geometri dasar, namun jika saya ingin mengubah kurva menggunakan gradien saya mungkin fokus pada diferensial kalkulus untuk dapat untuk dengan mudah memanipulasi gradien dll dan hal yang sama berlaku untuk apa pun yang saya rencanakan untuk memiliki akses yang lebih mudah

dan kadang-kadang mesin gim saat ini mungkin tidak memberi saya fleksibilitas apa yang ingin saya lakukan atau bahkan mungkin itu memberi Anda pilihan itu tetapi sangat sulit untuk melakukannya karena mesin gim berfokus pada kekuatan fisika sebagai sumber utama gerak dan manipulasi benda dalam game

Lagi pula saya harap saya menjelaskan apa yang saya coba tunjukkan


6
-1 Jika Anda bekerja pada proyek berukuran terhormat, Anda sebenarnya diharapkan untuk menggunakan fungsi / kelas yang Anda tidak tahu bagaimana itu ditulis, dan Anda mungkin tidak dapat menulis sendiri tanpa harus mempelajari jumlah buku di tema. Saya tidak berbicara tentang apa yang harus diketahui setiap programmer, tetapi mesin permainan adalah proyek besar, dan diharapkan programmer X topik khusus X tidak memiliki pengetahuan dalam topik Y dan karenanya harus menggunakan fungsinya, saya juga tidak menyiratkan bahwa Anda seharusnya tidak tahu cara menggunakan API Anda harus tetapi Anda mungkin tidak memiliki cukup pengetahuan untuk menulis satu.
concept3d

2
Apakah guru Anda tahu cara membuat mobil lengkap dari unsur-unsur kimia dari awal? Atau apakah dia mengendarainya dengan asumsi itu hanya berfungsi ;-)
Kromster mengatakan mendukung Monica

1
@ concept3d ada perbedaan antara bekerja pada proyek di mana orang lain mendesain fungsi / kelas yang Anda gunakan, karena biasanya jika Anda tidak mengerti sesuatu itu dapat dengan mudah dijelaskan, seorang programmer yang menggunakan kelas kode / fungsi / perpustakaan dia / Dia tidak tahu adalah orang yang bodoh, bahkan kelas dan API yang tersedia untuk umum hadir dengan manual dan wiki yang menjelaskan apa yang dilakukan API atau fungsi itu, hanya berharap menggunakannya tanpa mengetahui seperti apa rasanya mencoba berenang di dalamnya perairan dalam tanpa tahu cara berenang, dan benar-benar bodoh dan rawan kesalahan
thingybingytie

@ hopjoppe5 Jika Anda memeriksa jawaban yang diterima, ini adalah satu-satunya alasan orang membangun teknologi mereka sendiri. Banyak perpustakaan / kode outsourcing di dunia nyata, dan Anda harus menggunakannya. Membaca manual berbeda dari mengetahui implementasinya, untuk beberapa algoritme Anda bahkan berkecil hati untuk mengimplementasikannya sendiri dan harus diimplementasikan oleh para ahli dalam subjek, jika Anda memiliki pengalaman dunia nyata, Anda akan memahami hal ini. Mengetahui segalanya tidak mungkin.
concept3d

Salah satu alasan utama abstraksi adalah untuk menulis kode sehingga orang yang tidak tahu cara kerjanya, masih bisa menggunakannya. Saat mengerjakan gim yang berukuran lebih besar dari pong, sepertinya Anda tidak terbiasa dengan setiap keping kode. Dan dalam kebanyakan kasus itu adalah hal yang baik, karena itu berarti Anda dapat memfokuskan pikiran Anda pada apa yang sedang Anda kerjakan saat ini, daripada khawatir tentang bagaimana sistem input dapat menangani permintaan Anda untuk acara "On Action Key Down".
Aidiakapi
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.