Bir oyun geliştiricisi neden mevcut olanları kullanmak yerine kendi motorunu yazsın?


41

Birçok büyük ve iyi bilinen oyun geliştiricinin genellikle kendi motorunu geliştirdiğini gözlemledim. Örnekler Valve, Crytek, Ubisoft, Epic Games ve Square-Enix'tir.

Bunlar olabilir mi, yoksa mevcut motorların yeterli gereksinimleri karşılamaması muhtemel olabilir mi? Belirli bir motor gerektiren bir oyun hayal bile edemiyorum. Unity ya da Unreal gibi şeyler her türlü oyunu yapmak için yeterlidir; Olmasa da, bazı olağanüstü ihtiyaçları bile karşılayacak şekilde değiştirilebilecek kaynak kodları vardır.

Bir oyun geliştiricisi neden mevcut olanları kullanmak yerine kendi motorunu yazsın?



1
Başka şirketlerin oyun motorlarını lisanslamak ve onlara ödeme yapmak istemiyorlar.
Janos Turánszki

Sanırım 9K + çalışanın etrafta dolaştığı zaman yaptığın şey bu ...
glampert

3
Unreal veya CryEngine gibi 3. taraf motorları kullanarak AAA başlıkları yaratan büyük stüdyoların birkaç karşı örneği var .
Philipp,

3
Valve, Quake motorunu kullanmaya başladı, sonra nihayetinde kendi oyunlarını yazdı. Mevcut olanı kullanmayı öğrenmek, sonra nihayetinde mevcut motorun sunduğu şeyden daha fazla bir şey elde etmek isteyen bir meseledir. Bu noktada ağır değişiklikler yapmanız ya da kendi ayarlarınızı yapmanız gerekir.
Nairou

Yanıtlar:


54

Bir stüdyonun teknolojisini “satın almak” yerine “inşa etmeyi” seçmesinin birkaç nedeni vardır:

  • Eski teknoloji; Bir stüdyo, kendi araç zincirini oluşturmaya başlamış olabilir.
  • Belirli gereksinimler; Bir stüdyo, mevcut ara katman yazılımı için uygun olmayan özel bir gereksinim koleksiyonuna sahip olabilir.
  • Bütçe kaygıları; Bir stüdyo, mevcut ara katman yazılımların gider veya sözleşmeden doğan yükümlülüklerini karşılayamayabilir.
  • "Burada inşa edilmemiş sendromu;" Stüdyoların teknik liderliği, inşa etmedikleri ve bu yüzden tam olarak anlamadıkları teknolojilere karşı (makul veya makul olmayan bir şekilde) dikkatli olabilirler.

Genel olarak, işinizin başarısı için kritik öneme sahip olan şeylere sahip olmak ve kontrol etmek ve olmayanları dışlamak için anlamlıdır.

Bazı stüdyolar için, oyunlarının tasarımı veya öykü anlatma özelliği, başarı için yararlanmaları beklenen kritik kaynak olabilir. Bu stüdyolar için, tasarımcılarının uygun vizyonu gerçekleştirmelerini sağlayacak teknolojiyi satın almak mantıklı.

Diğerleri için teknoloji başarının temeli olabilir. Örneğin, MMO'ları inşa eden stüdyoların genellikle bu altyapıyı kendileri inşa etmeleri gerekecektir, çünkü başarıları için kritik öneme sahiptir (ve mevcut ara katman yazılımı genellikle en azından daha büyük, "AAA" başlıkları için uygun değildir).

Listelenen stüdyoların bazılarının (özellikle Crytek ve Epic) temel olarak doğrudan oyun pazarında güçler yaratmaya çalışmaktan vazgeçtiğini ve neredeyse kesinlikle oyun geliştiricilerden daha fazla katman aracı üreticisi olarak yaptıklarını unutmayın.


20
“Burada inşa edilen” teknolojilerin bazen avantajlarının olduğunu da eklerdim. Bunun bir örneği Unity3D'nin EULA'larını her sürümde nasıl değiştirdiği ve "kumar oyunları" gibi garip kısıtlamalar eklediğidir. Bir teknolojiyi lisansladığınızda, lisansı iade etmemeniz ve belirli bir nedenden ötürü lisansı iptal etmemeniz (lisanslı oyunlar yapmak için IP haklarında olduğu gibi) veya onlar için hatalarını düzeltmeniz için sizden ücret almaya karar vermeniz durumundadır.
Skrylar

cidden, Unity "kumar oyunu yok" mu diyor? Hatta web sitelerinin Topluluk bölümünde kumar hakkında belirli bir sayfa bile kullanıyorlardı!
15'te

Unity'nin buradaki sayfası unity3d.com/industries/gambling , "Unity Gambling lisansı" alabileceğinizi söylüyor. Bunun için bir fiyat bulamadım, ancak özel lisans için para ödemeniz şartıyla kumar oyunları oynamanıza izin veriyor gibi görünüyor.
Alex,

1
Ayrıca, zaten bir motorun ne olduğunu bile bilmeden, zaten bildiğiniz bir şeye başlamak ve bir motor yapmak daha kolaydır. Bir motor, kullanım çantası koleksiyonundan başka bir şey değildir; fazlalığı azaltmaya çalışıyorsanız, bir motor yazıyorsunuz ve oyunu sadece kurmaya çalışıyorsanız, bir yekpare sisteme sahip olursunuz. Bir oyun motoruna sahip olmak ve onu bir piksel görüntülemeye nasıl getireceğini öğrenmek çok zor, o zaman bunu yapamayacağının farkına var çünkü her şeyi bir doku olarak görüyor. Kendi yazını yazarken bununla uğraşmak zorunda değilsin.
Dmitry

18

Josh Petrie tarafından söylendiği gibi :

" Burada inşa edilmemiş sendromu ;"

Ayrıca kendi motorumu yazıyorum ve neden her geliştirici için farklı olacağını varsayalım, ama aslında - genellikle diğer insanların kodlarında çalışmaktan hoşlanmıyorum. Ben kendim inşa edebileceğimi hissedersem, o zaman başka hiçbir şeye karar vermenin bir anlamı olmadığı konusunda mecburum .

Çeşitli oyun motorları test ettim, API ve bunun gibi Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre, vb. Gibi işlemler yaptım. ve iyi belgelenmiş bir giriş noktası ...

Ancak benim sorunum, o sırada motorun altında ne olduğu hakkında hiçbir fikrim yoktu. İyi kontrol istedim ve elimin arkası gibi bildiğim bir çerçeve istedim. "HEY! Sanırım bu şeyin nasıl çalıştığını ve anlayacağımı öğrenmenin tek yolu , kendi motorumu tamamen ve tamamen sıfırdan oluşturmayı denemek olduğunu düşünüyorum . Programlama geçmişimin çoğu web ve işleme çözümleriyle yapıldı. - Bu benim için yepyeni bir top oyunuydu.

Yaptığım şey buydu.

Bu yüzden, CNA'yı zaten bildiğimden beri nasıl ve nerede başlayacağımı düşünmeye başladım. Bir fikre ihtiyacım vardı.

Buna karar verdim, ne olursa olsun, doğrudan 3D'ye geçeceğim .

Temelleri bulmak harika bir şeydi - sprite parti işleri, ama ilerlediğimde yeni engeller ve engeller keşfettim - ilk gerçek olanı parti limiti . Amacım, istediği zaman görüş açısında en az 10000 varlık yaratabilen bir oyun inşa etmekti.

Shader Based Instancing uygulamasının yeni bir yolculuğuna çıktım (ve oradayken HLSL'yi öğrendim), yerine XNA'ları Model ve Effect nesnelerinde yerleşik olarak değiştirdim. VBO akışlarını ilk başta anlamakta sorun yaşadım; Bir şeyleri kırdım - çevrimiçi olarak instancing işleri hakkında sorular sormaya gittim ve sonunda GPU'nun ne yaptığını anlayana kadar tuttum. Bu ödendi; Şimdi VBO'umu PIX (dxsdk) ile hata ayıklamadan birkaç gün sonra bakış açımda yakınlaştırma yapan yirmi binden fazla test kuruluşu vardı.

Artık boru hatları oluşturma işleminin nasıl çalıştığı hakkında "bazı" fikrim vardı, ancak henüz bitmedi - kendi oyunumu, kameram, post efektlerim ve varlık nesnelerimi oluşturdum; yükleyiciler (XNB olayına karşı kişisel olmayanlar), karmaşık bir derinlik sıralı ve harman halli ayrılmış geometri zinciri oluşturdular ve aynı zamanda hepsi oyun sahnesine yansıtılan hareketli sprite ve yazıya sahipti.

Neredeyse bütün bir yıl boyunca sürekli olarak buna eklemeye, tamir etmeye, değiştirmeye ve denemeye devam ettim. Sonunda, oldukça iyi çıktı. Şimdi kaputun altında neler olup bittiğini anladım, çünkü yarattım - bebeğim.

Şimdi motorum çoğunlukla kararlıydı ve neredeyse bitmek üzere. Mükemmel değil: komut dosyası honky ve GUI hiç de iyi değildi. Ama ben hala onu sevdim. Binlerce kod, varlık ve medya satırı, 2GB özel bir depoda toplandı ve daha önce hiç yapmadığım bir tür gelişme yapmaya çalışırken başımdan geçen tüm sıkıntıları yaşadım. Üstesinden geldiğim her engel, öğrenilen bir ders ve rahatlama oldu.

Neredeyse istediğim her şeyi çıkardım.

Ama sonunda - onu bırakma zamanı olduğuna karar verdim. Kendi kendime bu kadar büyük bir motor yazarken, ağdan ve diğer gamedev arkadaşlarının tavsiyesiyle kendimi tatmin ettiğim sürece, her şeyi yeniden yapmaya karar verdim - ve daha iyisini yapacağım - çünkü şimdi bu sefer çoğunlukla biliyorum. ben ne yapıyorum.

Bu proje hala GIT depomda duruyor.

Yeni bir motor yazmaktaki ikinci geçişim (bu sefer MonoGame'de) iyi ilerliyor. Bir şey kırıldığında, düzeltilmesi daha kolaydır. Daha az karışıklık Umarım bu yılki oyunumu herkese açık bir şekilde göstereceğim, çünkü koduma eklenmiş bir 'fazla' olma eğilimindeyim.

Sonunda kendi motorum yazıyor, nasıl yapılacağını 'nasıl' öğrendiğimi, her bileşenin tam olarak ne yaptığını ve nasıl çalışması gerektiğini bildiğimi ve anladığımı söyleyebiliyordum. Aslında başkalarının kodunu okumaktan nefret ediyorum, özellikle büyük belgesiz projeler için. Kullandığım her şeyin benim tarafımdan yapılmasını istiyorum.

Bu sadece benim. Önceden yapılmış bir motor kullanacağımdan şüpheliyim, muhtemelen kendi çerçevelerimi yazmak benim için başkasının kodu ile tam kontrol etmekle uğraşmaktan daha eğlenceli.


13
Bu, başıboş bir kişisel anekdot gibi çok daha fazla okur; Muhtemelen bunu daha özlü hale getirmek için düzenleyebilir ve daha iyi bir cevap verebilir.
Josh

2
Her şey yapmak için zamanınız olduğunda, bu kesinlikle öğrenmek ve oyununuzu yapmak için kesinlikle harika. Ne zaman gerçekten sadece sensin. Ama ya biriyle işbirliği yapmak istersen? Veya başka programcılar ile bir şirkette çalışmak? Birisi projenize katılmak isterse, o zaman kodunuzu okumanız biraz garip değil mi - onlar için başkalarının kodu .. nefret ettiğiniz şey. Okuma kodunun da çok önemli bir beceri olduğunu düşünüyorum. Alınma, çok şey öğrendin ve havalı bir motor yazdığına eminim - sadece bir tek şey değil.
02:

Bunun farkındayım, sadece herhangi bir dilde herhangi bir kod içerdiği her iş, her zaman benim için yalnızdı. D;
Codie Morgan,

Söylemeliyim ki, bir insanın kendi motorunu / aletini ne şekilde çıkardığını hangi sebeplerden dolayı tam olarak biliyorum . Ama bunun bir bedeli var (her şey gibi) ... En patronluk kodunu okuyamadığınızda / anlayamadığınızda tüm patronların açıkça nefret ettiğini hissediyorum , bu yüzden lütfen devam edin ve kendinizi ** olarak atın * kötü yazılmış kötü yönetilen kod belgeleri olmadan, sadece bunun için bir fikir ("gerçek" dünya) olsun. Alınma
Quonux

Bunun nedeni, programcıların iyi şeyler yapamaması. Çünkü biz her zaman çalışma ve güvenilir yöntemler kullanmak yerine her şeyi kendimiz yapmak istiyoruz. Her şeyi kendim yazmaya zorluyordum, ama yavaş yavaş başkalarına güvenmeyi öğreniyorum ve şu ana kadar bana kötüden daha iyi yapıyor :)
Maurycy

15

Kendi motorunuzu yazmanın mutlak kilit nedeni (ve henüz kimsenin bunu söylemediğini şaşırttı) hata ayıklama için .

Büyük, karmaşık bir oyun yazdıysanız ve içinde bir kilitlenme hatası varsa ve kaynak kodunuz varsa (ve yazdığınızdan dolayı bu kaynak koduna yakından aşinaysanız), Süreci ve çökmeye neden olanı bulun. Bitti.

Başka birinin ticari olarak kullanılabilen motorunu kullanıyorsanız ve o motorun kaynak koduna sahip değilseniz (normalde kullanmazsınız), o zaman ortaya çıkan sorunları ayıklamak - kendi kodunuz dahilinde - devam etmek anıtsal olarak daha zor olmak. Ve motorun içinde bir hata ile karşılaşırsanız, onları kendiniz çözemezsiniz. Çıkış tarihinizden bir hafta sonra olmak ve birisinin kullandığınız motorda bir kilitlenme hatası keşfetmesini - düzeltemeyeceğiniz bir kilitlenme hatası olmasını mı istiyorsunuz? kaynak kodunuz var mı? Bunun olduğunu gördüm - satıcıya acil bir destek çağrısı yapmaktan başka seçeneğiniz yok ve etrafta gezinirken, sorunu sizin için çözebileceklerini (ve ilgileneceklerini) umuyorum.

Oyun gelişimi zordur, ancak hata ayıklama zorlu emirlerdir. Kitabımda oyun geliştirmeyi zorlaştıran, ancak hata ayıklamayı kolaylaştıran herhangi bir şey büyük bir net kazanç.


3
Bu, açık kaynaklı bir motor (cocos2d-iphone) kullanmakta karşılaştığımız büyük bir durum. Yazdığımız kodla aynı şekilde hata ayıklayabiliriz. Aslında açık kaynak düşünmenin yolunun sizin kodunuz olduğunu biliyorum. Eğer hata varsa, kodumuzun diğer bölümlerinde olduğu gibi onları düzeltmek zorunda kalacağız ..
antont

1
Bu herhangi bir katman yazılımı söylenebilir . Hata ayıklama kodu, bir programcının işinin% 80'idir ve ara katman yazılımları kullanmak, günümüzde oturduğumuz teknolojide, sayabileceğimizden daha fazla katman yazılımı ile ortak bir sorundur. Bunun üstesinden gelmeyi öğrenmek işin sadece bir parçası. Motor kırılmazsa, kontrolünüzde olmayan bir şey olacaktır. Daha az hareketli parça iyi bir fikirdir, ancak oyun devi gibi karmaşıklaştığında, yine de onlarla çok uğraşmanız gerekir.
Tim,

Kesinlikle katılmıyorum @Tim - bir harici şey gelmez zor debug şekilde yaramazlık diye değil biz sadece bizim omuz silkmek ve icar kendimizi istifa gerektiğini ima herşey zor debug yollarla yaramazlık. Birinin durumları durum bazında ele alması gerekiyor, ancak motor zor böceklerin sıklıkla gizlendiği büyük bir sistem . Neden olur değil belki kendiniz yapmak gelemez, sizin kontrolünüz altında bunu istiyorum?
Trevor Powell

@TrevorPowell Açıkçası projenin karmaşıklığına aşağıya iner ve dediğiniz gibi, bir vaka ile vaka bazında, ancak sadece bir tekerlek (bu büyük bir tekerlek var özellikle) yeniden icat ciddiye tarafından kaydedilen zaman konusunda dikkat edilmesi gereken değil yapıyor o. Middleware işleri kolaylaştırır. Bir geliştirici olarak, bu çözümün ne kadar iyi yapıldığını düşünmeden daha iyi hale getirmek için her zaman bir çözümü yeniden keşfedebileceğimize inanıyoruz. Birkaç vuruş> yeniden keşif> Tamamen yanlış çözüm
Tim

2
@Tim RE: "Middleware işleri kolaylaştırıyor", görünüşe göre senden çok farklı deneyimler yaşadım.
Trevor Powell

9

Burada çok iyi cevaplar var ama önemli bir ek noktayı kaçırıyorlar.

Günümüzün lisanslanabilir motorlarının çoğu özel motorlar olarak başladı .

Örnek olarak Unreal'ı ele alalım, çünkü çok yaygın.

Bugün Unreal'ü düşündüğünüzde, kendi aracınızı inşa etmek yerine lisansladığınız ve kullanabileceğiniz bir motor düşünmeye eğilimlisiniz, fakat bu her zaman böyle değildi ve bir zamanlar Unreal motoru bile var değildi. ayrı bir varlık.

Bir zamanlar Unreal adında bir oyun vardı . Geliştiricileri mevcut bir lisansı almak yerine kendi motorlarını kurmaya karar verdi . Birkaç yinelemeyle hızlı ileri sarılınca, bu motor bugün bildiğimiz Unreal motor haline gelir.

Mesele şu ki, bu bir tavuk ve yumurta problemi. Middleware'in lisansını alabileceğiniz her parça bir yerden başlatıldı ve genellikle katman yazılımı olarak başlamadı (bazen katman yazılımı oluşturma niyetiyle yazılmış değildi ve şu anki durumu etkin bir kazaydı ). İnsanlar kendi motorlarını yazarlar, çünkü nihayetinde birinin motoru yazması gerekir ve bugünün özel motoru yarın lisanslı ara katman yazılımı olabilir.


2
Unreal gibi oyunların ilk inşa edildiği günlerde, hepsini sıfırdan yazmaktan başka bir seçenek yoktu. N motor
seçebileceğimiz

3

Bir stüdyonun teknolojisini "satın almak" yerine "inşa etmeyi" seçmesinin başka nedenleri de var:

  • Yeni platformlar : yeni mobil işletim sistemi, konsol veya kontrolcüler. Leapmotion, google glass vb. Hakkında düşünün. Çapraz plataform desteği zordur
  • Yeni oyun mekaniği ve / veya oyun editörleri : Birkaç yıl önce FEZ'yi düşünün (2D vs 3D)
  • İyi ücretsiz açık kaynaklı oyun editörlerinin olmaması . Mevcut eski oyun kaynaklarına ilişkin iyi dokümantasyon eksikliği
  • Stüdyo araç zincirindeki aletlerin evrimi (veya yenilerini ekleyin)
  • Motor fiyatlandırması ve lisans savaşları

Ayrıca belirli isteklere / ihtiyaçlara ve motor fiyatlandırmasına ve lisans savaşlarına katılıyorum, bazı stüdyoları bazı motorları dağıtmaya zorluyorum.

Diğer motorları "satın almak" veya "kullanmak" için iyi sebepler şunlardır:

  • Kod Yeniden Kullanımı : Zaten diğer oyunlarda kullanılan bir motor daha test edildi, daha kararlı ve ilk günden itibaren gereken özelliklerin çoğuna sahip olabilir.
  • Genişlet : bazı açık kaynaklı motorları genişletebilirsiniz.
  • Ücretsiz : ya da neredeyse ücretsiz, çünkü ücretsiz açık kaynaklı motorlar bile, öğrenmek için biraz geliştirici zamana ihtiyaç duyarlar.

2

Tarihsel sebep (çoğunlukla).
Hangi fiyatlandırma ile ilgili.

Geçtiğimiz yıllarda Unreal veya CryEngine'ı çalıştırırken gördüğünüz her oyun çok fazla para ödemek zorunda kaldı. Özellikle kaynak kodunu almak istiyorsanız (örn .: UE, yalnızca UDK değil, UE istediniz.)

Ancak bu değişti. Şimdi fiyat yarışması başladığında herkes daha da büyük motorları karşılayabilir.
Bu ne demek...

  • Hem UE4 hem de CryEngine kullanarak daha fazla oyun göreceksiniz.
    Yine de, oldukları gibi AAA oyunları olmayacaklar.
  • Her proje için özel gereksinimler ve ihtiyaçlar ortadan kalkmaz.
    Relic'teki Warhammer40k / COH motorunu veya EA'da kullanılan Generallerin motorunu görün.
    Dolayısıyla, daha büyük motorları kimse karşılayabilse bile, yanlışlıkla daha iyi bir seçenek sunmuyorlar.
  • Piyasada başkaları var. Birlik gibi.
    İnsanlar kullanım kolaylığı, hızlı performans ve devasa varlık deposu için onu seviyorlar.
    Tabii ki, Unity neredeyse her platforma yerleştirebilir.

Yani evet. İhtiyaçlar, geçmişte fiyatlandırma vb.


1
Havok'u "yoğun biçimde değiştirilmiş" olarak adlandırmazdım.
Josh

Havok sadece bir fizik motoru değil mi?
Philipp,

Öyle ve GW2 hatırlayabileceğim bir şey yapmadı.
Josh

Şunu yapmayın (ie.: you want UE, not UDK only.)?
Keavon

#JoshPetrie: Üzgünüm, dürüst olmak gerekirse Havok'ta hiç tecrübem yok / hiç oynamıyorum. Bu yüzden GW2'nin LİSANS dosyasını inceledim ve birkaç gün önce wiki sayfasını ziyaret ettim ve Havok'u gördüm. Sonra bir oyunun başında "Havok" u görmekle ilgili eski bir hatıra vardı, motorun bu olduğunu düşündüm. Ama sonra yine Havok'a baktım ve bunun bir fizik motoru olduğunu biliyordum. tl; dr: Havok hakkında her şeyi karıştırdım. || #Philipp: Bundan biraz daha fazlası, ama gerçekten de bir oyun motoru değil, benim hatam. || #Keavon: Doğru, düzeltildi. Teşekkürler!
Apache

0

Peki ya takım organizasyonu?

Hata ayıklama olayının arkasında dokümantasyon ve destek var, kod yok, çünkü sonunda bina grubumun kendi motorumun koduna dokunmasını istemedim. Bu karışıklık olabilir.

Yani, bunu yapmak için bir destek grubuna ihtiyacım var. Ama bu maliyetleri yükseltir: daha fazla insan, daha fazla yer, daha fazla telefon, daha fazla yönetim ...

Bunun bir çözümü, bir orta katman şirkete ... dış kaynak olabilir, bu da oyunları benim oyunuma, yani yaratıcı gruba ve yazarlara salıyor.

Bir başlangıç ​​şirketi için kullanmak ve inşa etmek kötü bir seçenek değildir. Ve, kritik bir gelir kütlesi elde ettikten sonra olabilir, belki olabilir, kendi motorunuzu oluşturmak isteyeceksiniz ...


0

iyi. geliştiricileri tarafından yaratılan kendi motorunu kullanan çoğu oyun için. sıklıkla. 3. parti motoruyla bir şeyler yapamazlar. bu yüzden kendi oyunlarının gelişimini kolaylaştırmak için kendilerini yaparlar. veya en azından mümkün.

ve genellikle kendi motorlarını kullanan birçok oyun. daha iyi çalış. çünkü daha özel ve% 100 görevlerine uygun. ve oyunun kendisi farklı hissediyor. Bir oyun oynamak ve bunu söyleyerek yapmak gerçekten çok kolay. gerçek dışı motor veya her neyse. Genel olarak daha özel motor ve benzersiz hissettiren bir oyun ile sonuçlanmalıdır. benzersiz görünüyor ve benzersiz çalışıyor ve önceden yapılmış bir motorda oluşturulmuş bir oyundan daha iyi performans göstermeli.


0

Cevabım mevcut cevaplardan farklı, bu yüzden geç olmasına rağmen ekliyorum:

Valve örneğini sorudan veya Witcher serisinden alırsanız işlem şöyledir:

  • Motor lisansı
  • Motoru amacınıza göre değiştirin / uyarlayın
  • Oyunu bırakın ve para kazanın
  • Bir sonraki oyun için kendi motorunu yarat

Aynı yaklaşım, kendi motorunu geliştiren hemen hemen tüm finansal olarak makul geliştiriciler tarafından da uygulanmaktadır. Bir motoru değiştirerek, bir motorun nasıl çalıştığını bilmekte ve lisanslı bir motordan kaynaklanan tasarım kısıtlamaları ile karşılaşmaktadırlar. Sonunda, bir motor oluşturmak için gerekli kurum içi bilgiye, bir motorun oluşturulmasına fon sağlamak için paraya ve özel bir motordan yararlanacak bir projeye sahipler. Bu noktada bir motor inşa etmenin nedeni şudur: Çünkü yapılacak akıllıca şey.


-2

programlama öğretmenim anlattı, sadece nasıl yapılacağını bildiğiniz API'leri / metotları / sınıfları / fonksiyonları kullanın.

çünkü eğer nasıl inşa edileceğini bilmiyorsanız ve başka birinin çalışma şansını kullanıyorsanız, nasıl çalıştığını bilmiyorsunuzdur ve bir şeyin nasıl çalıştığını bilmediğinizde hataya, sorunlara ve karışıklık duvarlarına çarpmaya daha meyilli olursunuz.

basit şeyler öğrenmek, karmaşık sorunlara yol açtığında, bir oyun motoru gibi karmaşık bir şey bıraksanız bile, oyununuzu çalıştırmak için beklenmedik sonuçlara ve sorunlara yol açabilecek oyun motorunu kullanmanız gerektiğinde

ve oyun motoru, mantıksal kodu veya inşa edildiklerinde herhangi başka bir mantığı izlemiyorlar, beklenebilecek bazı şeyler olduğundan emin olun, ancak gerçekte, her şey bir programlama dilinin anlayışı ve bilgisine veya bazı sistemlerin nasıl çalıştığına dayanarak inşa edilecek.

mesela matematiksel bir denklem yazmayı seçersem, polinomlarla, diferansiyel matematikle veya temel geometriyle veya cebirle veya neye uygun olursa olsun onu temsil edebileceğim bir çok yol yazabilirim, ancak bazen belirli bir biçimde / formatta yazarım çünkü Köşe manipülasyonu yapmayı planlamam gibi kolayca ulaşılabilir olanı manipüle edebilmek için, temel geometri kullanarak bu matematiksel modeli yazabilirim, ancak eğrileri kullanarak eğriyi değiştirmek istersem diferansiyel hesaplara odaklanabilirim. gradyanları vb. kolayca manipüle etmek ve aynı şey, kolay erişime sahip olmayı planladığım her şey için geçerlidir.

ve bazen mevcut oyun motoru bana yapmak istediğim şeyin esnekliğini vermeyebilir, hatta belki de size bu seçeneği sunar ama bunu yapmak çok zor çünkü oyun motoru fizik kuvvetlerine ana hareket ve manipülasyon kaynağı olarak odaklanıyor Oyunda nesneler

Her neyse, umarım ne yapmaya çalıştığımı açıklığa kavuşturdum.


6
-1 Saygın büyüklükteki herhangi bir projede çalışıyorsanız, aslında nasıl yazıldığını bilmediğiniz bir işlevi / sınıfı kullanmanız beklenir ve bu kitapla ilgili kitap sayısı üzerinde çalışmak zorunda kalmadan kendiniz bir tane yazamayabilirsiniz. konu. Her programcının bilmesi gerekenler hakkında konuşmuyorum, ancak bir oyun motoru muazzam bir proje ve X programcısı X özel programının Y konusunda bilgisi olmaması ve bu nedenle bu işlevi kullanmak zorunda olması bekleniyor. API'yı nasıl kullanacağınızı bilmemeniz gerektiğini, ancak bir tane yazmak için yeterli bilgiye sahip olamayacağınız anlamına gelir.
concept3d

2
Öğretmeniniz sıfırdan kimyasal elementlerden nasıl eksiksiz bir araba yapılacağını biliyor mu? Yoksa sadece çalıştığını farz edince kullanıyor mu ?
Kromster

1
@ concept3d bir başkasının kullandığınız bu işlevleri / sınıfları tasarladığı bir proje üzerinde çalışmak arasında bir fark vardır, çünkü genellikle bir şeyi anlamıyorsanız kolayca açıklanabileceğini, kod sınıflarını / işlevlerini / kütüphanelerini kullanmaya çalışan bir programcı / Bilmiyor, aptal bir kişi, halka açık bir şekilde mevcut olan sınıflar ve API'ler bile bu yüzdelerin içinde yüzmeye çalışmanın nasıl bir şey olduğunu bilmeden kullanmayı umduğunu açıklayan kılavuzlar ve wiki'lerle birlikte geliyor. ve gerçekten cahil, yüzmek ve eğilimli hata nasıl bilmeden derin sular
thingybingytie

@ hopjoppe5 Kabul edilen cevabı kontrol ederseniz, insanların kendi teknolojilerini oluşturmalarının tek nedeni budur. Kütüphanelerin / kodların çoğu gerçek dünyada dış kaynaklardan sağlanmıştır ve bunu kullanmak zorundasınız. Kılavuzları okumak, uygulamayı bilmekten farklıdır, bazı algoritmalar için, kendiniz uygulamaktan bile çekinmiyorsunuz ve konunun uzmanları tarafından uygulanmalıdır, eğer gerçek bir dünya deneyiminiz varsa, bunu anlayacaksınız. Her şeyi bilmek imkansız.
concept3d

Soyutlamanın temel nedenlerinden biri, kodun çalışmasını, böylece nasıl çalıştığını bilmeyen insanların kullanmasını sağlamaktır. Pong'dan daha büyük bir oyun üzerinde çalışırken, her kod parçasına aşina olmanız olası değildir. Ve çoğu durumda bu iyi bir şeydir, çünkü giriş sisteminin bir "On Action Key Down" etkinliği için isteğinizi nasıl karşılayabileceğinden endişe etmek yerine, şu anda üzerinde çalıştığınız şeye odaklanabileceğiniz anlamına gelir.
Aidiakapi
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.