Neden çok erken optimizasyon yapmak bu kadar kötü?

Optimizasyona biraz baktıktan sonra, bir oyunu çok erken optimize etmek için evrensel olarak kabul edilmiş bir günah gibi göründüğünü keşfettim (tam anlamıyla her yerde).

Bunu gerçekten anlamıyorum, akılda performans ile ilk kez onları geliştirmek yerine, oyunun çekirdek yapılarının bazılarını değiştirmek inanılmaz derecede zor olmaz mıydı?

Oyun bitene kadar beklememin size optimizasyona ihtiyacınız olup olmadığını söyleyeceğim, ama yine de yapmamalı mıydınız, sonuçta oyunun çalıştığı cihaz çeşitliliğini artırabilir, bu da potansiyel sayısını artırabilir oyuncular.

Birisi bana neden bu kadar erken optimizasyon yapmanın bu kadar kötü bir fikir olduğunu açıklayabilir mi?

Önsöz:

Yorumlarda bazı itirazlar gündeme geldi ve bence büyük ölçüde “erken optimizasyon” dediğimizde ne demek istediğimizin yanlış anlaşılmasından kaynaklanıyor - bu yüzden biraz açıklama yapmak istedim.

Yok "zamanından önce optimize etmeyin" değil "Knuth sonuna kadar bunu temizlemek izin yok diyor çünkü, biliyorsunuz yazma kodu kötü" demek

"Programınızın hangi bölümlerinin daha hızlı olması için gerçekten yardıma ihtiyacı olduğunu bilene kadar optimizasyon için zaman ve okunaklılıktan ödün vermeyin." Tipik bir program zamanının çoğunu birkaç darboğazda geçirdiğinden, "her şeyi" optimize etmeye yatırım yapmak, aynı darboğaza sadece bu darboğaz koduna odaklanmakla aynı hızda artış getiremez.

Bu, şüphe durumunda , biz yapmalıyız:

• Yazması kolay, anlaşılması kolay ve yeni başlayanlar için değiştirmesi kolay kodu tercih edin

• Daha fazla optimizasyonun gerekip gerekmediğini kontrol edin (genellikle çalışan programı profilleyerek, aşağıdaki yorumlardan biri matematiksel analiz yapıldığını not eder - buradaki tek risk aynı zamanda matematiğinizin doğru olup olmadığını kontrol etmenizdir)

Bir erken optimizasyon değil :

• Kodunuzu gereksinimlerinize göre ölçeklendirecek şekilde yapılandırmaya yönelik mimari kararlar - uygun modülleri / sorumlulukları / arayüzleri / iletişim sistemlerini dikkate alarak seçin.

• Ekstra zaman almayan veya kodunuzu okumayı zorlaştıran basit verimlilik. Güçlü yazmayı kullanmak gibi şeyler hem verimli olabilir hem de amacınızı daha net hale getirebilir. Bir başvuruyu art arda aramak yerine önbelleğe almak başka bir örnektir (durumunuz karmaşık önbellek geçersiz kılma mantığı gerektirmediği sürece - belki de önce basit yolu ilk seçene kadar yazmaya devam edebilirsiniz).

• İş için doğru algoritmayı kullanmak. A * ayrıntılı bir yol bulma grafiği aramaktan daha uygun ve daha karmaşıktır. Aynı zamanda bir endüstri standardı. Temayı tekrarlamak, bunun gibi denenmiş ve doğru yöntemlere bağlı kalmak, kodunuzu anlaşılması daha kolay bir şey yapmaktan ziyade bilinen en iyi uygulamalara karşı koymaktan daha kolay hale getirebilir. Önceki bir projede X oyun özelliğini uygulayan darboğazlara girme konusunda deneyiminiz varsa, bunun gerçek olduğunu bilmek için bu projede aynı tıkanıklığa tekrar basmanız gerekmez - geçmiş için çalışmış olan çözümleri tekrar kullanabilirsiniz oyunlar.

Tüm bu tür optimizasyonlar haklı çıkmıştır ve genellikle "erken" olarak etiketlenmezler (8x8 satranç tahtası haritanız için en son yol bulma özelliğini kullanan bir tavşan deliğinden aşağıya inmezseniz ...)

Öyleyse şimdi, bu politikayı neden oyunlarda özellikle yararlı bulabileceğimizi açıkladı :

Özellikle gamedevde, yineleme hızı en değerli şeydir. Genellikle "eğlenceyi bulmaya" çalışırken bitmiş oyunla birlikte gönderilenden çok daha fazla fikri uygular ve yeniden uygularız.

Bir tamirciyi basit ve belki de biraz saf bir şekilde prototip edebilir ve ertesi gün tekrar deneyimleyebilirsiniz, bir haftayı en iyi halini almak için ilk haftaya ayırdığınızdan çok daha iyi bir durumdasınız demektir. Özellikle emmek için çıkıyor ve sonunda bu özelliği atıyorsanız. Erken test edebilmeniz için basit bir şekilde yapmak, saklamadığınız bir sürü boşa harcanan iş optimizasyon kodundan tasarruf etmenizi sağlar.

Optimize edilmemiş kodun değiştirilmesi ve farklı değişkenlerin denenmesi genellikle daha kolaydır, bu özellik, en iyi şekilde kesin bir şekilde yapılması için ince ayarlanmış olan koddan farklıdır; bu, kırılmadan, hata vermeden veya yavaşlatılmadan değiştirilmesinin zor ve kırılgan olma eğilimindedir. Bu nedenle, kodu basit ve değiştirmesi kolay tutmak, çoğu geliştirme aşamasında (genellikle hedef spesifikasyonun üzerindeki makineler üzerinde çalışıyoruz, bu nedenle ek yükü absorbe edip önce hedef deneyimi edinmeye odaklanabiliyoruz), çalışma süresinin yetersiz olmasına değiyor. Bu özellikten ihtiyacımız olanı kilitledim ve artık bildiğimiz parçaları yavaşlatabiliriz.

Evet, yavaş noktaları en iyi duruma getirmek için projenin geç dönemlerinde yeniden yapılanma çalışmaları zor olabilir. Ancak bu, gelişim boyunca sürekli yenileniyor, çünkü geçen ay yaptığınız optimizasyonlar oyunun o zamandan beri gelişen yönüyle uyumlu değildi veya daha fazla özellik ve içeriğe sahip olduğunuzda gerçek darboğaz olmadığı ortaya çıkan bir şeyi düzeltti. içinde.

Oyunlar tuhaf ve deneyseldir - bir oyun projesinin ve teknik gereksinimlerinin nasıl gelişeceğini ve performansın en sıkı nerede olacağını tahmin etmek zordur. Uygulamada, çoğu zaman yanlış şeyler hakkında endişelenmeye başlıyoruz - buradaki performans sorularını araştırın ve muhtemelen bir sorun olmayan kağıttaki şeylerin dikkatinin dağılmasıyla ortaya çıkan ortak bir tema göreceksiniz.

Dramatik bir örnek almak gerekirse: Oyununuz GPU'ya bağlıysa (nadir değildir), o zaman hiper optimizasyon ve işlem yapmak için harcanan zamanın tamamı CPU çalışmasını somutlaştırır. Tüm bu dev saatler, daha iyi bir oyuncu deneyimi için oyun özelliklerini uygulamak ve parlatmak için harcanmış olabilir.

Genel olarak, bir oyunda çalışmak için harcadığınız zamanın çoğu, tıkanıklık haline gelen kod için harcanmaz. Özellikle mevcut bir motor üzerinde çalışırken, renderleme ve fizik sistemlerindeki süper pahalı iç döngü malzemesi büyük ölçüde elinizin altında. Bu noktada, oyun senaryolarındaki işiniz temelde motorun yolundan uzak durmaktır - oraya bir İngiliz anahtarı atmadığınız sürece, ilk inşa için muhtemelen oldukça iyi bir şekilde çıkacaksınız.

Bu nedenle, bir miktar kod hijyeni ve bütçelemesinin dışında (örneğin, tekrar tekrar kullanabiliyorsanız, bunları tekrar aramayın / yapmayın, yol bulma / fizik sorgularınızı veya GPU geri okumalarını mütevazı tutun), bitmemeyi alışkanlık haline getirin - gerçek sorunların nerede olduğunu bilmeden önce verimliliği arttırmak için en iyi duruma getirme - yanlış şeyleri optimize etmek için zaman kaybetmemize ve genel olarak kodumuzu daha basit ve kolay tutmamıza yardımcı olur.

not: bu cevap DMGregory'nin cevabı üzerine bir yorum olarak başladı ve bu yüzden yaptığı çok iyi noktaları kopyalamıyor.

“Oyunun temel yapılarının bazılarını, akılda tutulacak performans ile ilk kez geliştirmek yerine sonunda değiştirmek inanılmaz derecede zor olmaz mıydı?”

Bu, bana göre, sorunun özüdür.

Orijinal tasarım oluştururken, gereken verimlilik için dizayn deneyin - Üst düzeyde. Bu daha az optimizasyon ve yapı hakkında daha fazla.

Örnek:
Bir nehri geçmek için bir sistem yaratmanız gerekiyor. Açık tasarımları bir köprü veya feribottur, hangisini seçersin?
Elbette cevabı, geçişin büyüklüğüne ve trafik hacmine bağlıdır. Bu bir optimizasyon değil, bunun yerine sorununuza uygun bir tasarımla başlamak.

Tasarım seçenekleri ile sunulduğunda, yapmak istediklerinize en uygun olanı seçersiniz.

Yani, trafik hacmimizin oldukça düşük olduğunu söyleyelim, bu yüzden iki terminal inşa etmeye ve trafiği idare etmek için bir feribot satın almaya karar veriyoruz. Güzel ve basit bir uygulama
Ne yazık ki, bir kez çalıştırıp çalıştırdıktan sonra, beklenenden daha fazla trafik gördüğünü görüyoruz. Vapuru optimize etmeliyiz! (çünkü işe yarıyor ve şimdi bir köprü inşa etmek iyi bir plan değil)

Seçenekler:

• İkinci bir feribot satın al (paralel işleme)
• Feribotlara başka bir araç güvertesi ekle (trafiğin sıkıştırılması)
• Daha hızlı hale getirmek için feribotun motorunu yükseltin (yeniden işleme algoritmaları)

Orijinal tasarımınızı mümkün olduğunca modüler hale getirmeye çalışmanız gereken yer burasıdır.
Yukarıdakilerin hepsi olası optimizasyonlardır ve üçünü de yapabilirsiniz.
Peki bu değişiklikleri büyük yapısal değişiklikler olmadan nasıl yapıyorsunuz?

Açıkça tanımlanmış arayüzleri olan modüler bir tasarıma sahipseniz, bu değişiklikleri uygulamak basit olmalıdır .
Eğer kodunuz sıkı sıkıya bağlı değilse, modüllerde yapılan değişiklikler çevreleyen yapıyı etkilemez.

Ekstra feribot eklemeye bir göz atalım.
Tek bir feribot fikri etrafında 'kötü' bir program oluşturulabilir ve rıhtım devletlerine ve feribot eyaletine ve bir araya getirme ve paylaşma durumuna sahip olmaları sağlanabilir. Bu, sisteme fazladan bir feribot eklenmesini sağlamak için değiştirilmesi zor olacaktır.
Daha iyi bir tasarım, ayrı varlıklar olarak rıhtımlara ve feribotlara sahip olmak olacaktır. Aralarında sıkı bir bağlantı yoktur, ancak bir feribotun ulaşabileceği, yolcuları boşaltabileceği, yenilerini alabileceği ve gidebileceği bir ara yüzleri vardır. İskele ve feribot yalnızca bu arayüzü paylaşır ve bu, ikinci bir feribot ekleyerek sistemde değişiklik yapmayı kolaylaştırır. İskelede gerçekte var olan feribotların umrunda değil, ilgilendiği tek şey bir şeyin (herhangi bir şeyin) arayüzünü kullanmasıdır.

tl; dr:

• Her şeyden önce verimlilik için tasarım yapmaya çalışın.
• İki seçenekle sunulduğunda, daha verimli olanı seçersiniz.
• Kodunuzu, iyi tanımlanmış arayüzlerle mümkün olduğunca modüler olarak yazın.

Daha sonra, optimize etmek istediğinizde tüm kod tabanını yeniden yapılandırmadan her modülün içindeki mekanizmaları değiştirebilirsiniz.

"Erken optimizasyon yapmayın", "işleri yapmak için mümkün olan en kötü yolu seçme" anlamına gelmez. Yine de performans sonuçlarını göz önünde bulundurmanız gerekir (sadece prototip olmadıkça). Mesele şu ki gelişimdeki o noktada diğer, daha önemli şeyleri sakatlamak değil - esneklik, güvenilirlik vb. maliyetleri takip edin. Güçlü yazarak mı kullanmalısınız? Çoğu oyun iyi sonuç verdi; Oyun oynamak için esnekliğin ilginç kullanımlarını bulursanız, bunu kaldırmanız ne kadara mal olur?

Optimize edilmiş kodu, özellikle "akıllı" kodu değiştirmek çok daha zor. Her zaman bazı şeyleri daha iyi yapan, diğerleri ise daha kötü olan bir seçimdir (örneğin, bellek kullanımı için CPU zamanı değişiyor olabilirsiniz). Bu seçimi yaparken, tüm sonuçların farkında olmanız gerekir - felaket olabilirler ancak yardımcı olabilirler.

Örneğin, Komutan Keen, Wolfenstein ve Doom, optimize edilmiş bir işleme motorunun üzerine inşa edildi. Her biri, oyunun ilk etapta var olmasını sağlayan "numaralarına" sahipti (her biri zaman içinde daha da geliştirildi ancak bu önemli değil). Bu iyi . Oyunun özünü, oyunu mümkün kılan düşüncesini yoğun bir şekilde optimize etmek sorun değil; Özellikle, bu optimize edilmiş özelliğin çok fazla keşfedilmemiş oyun tasarımlarını düşünmenize izin verdiği yeni bölgeleri keşfediyorsanız. Optimizasyonun getirdiği sınırlamalar size ilginç bir oyun sunabilir (örneğin, RTS oyunlarındaki birim sayım limitleri performansı arttırmanın bir yolu olarak başlamış olabilir, fakat aynı zamanda bir oyun efekti de vardır).

Ancak bu örneklerin her birinde, oyunun optimizasyon olmadan var olamayacağına dikkat edin. “Tamamen optimize edilmiş” bir motorla başlamadılar - çıplak bir zorunlulukla başladılar ve çalışmaya başladılar. Yeni teknolojiler geliştiriyorlardı ve onları eğlenceli oyunlar yapmak için kullanıyorlardı. Motor hileleri kod tabanının mümkün olduğu kadar küçük bir kısmı ile sınırlıydı - daha ağır optimizasyonlar yalnızca oyun çoğunlukla yapıldığında ya da ilginç bir yeni özelliğin ortaya çıkmasına izin verildiğinde ortaya çıktı.

Şimdi yapmak isteyebileceğiniz bir oyun düşünün. Bu oyunu yapan ya da bozan gerçekten teknolojik bir mucize var mı? Belki de sonsuz bir dünyada açık bir dünya oyunu hayal ediyorsundur. Bu gerçekten oyunun merkezi parçası mı? Oyun sadece onsuz işe yaramaz mıydı? Belki de arazinin sınırsız, gerçekçi jeoloji ile deforme olduğu bir oyun düşünüyorsunuz; daha küçük bir kapsamla çalışmasını sağlayabilir misiniz? 3B yerine 2B olarak çalışır mı? En kısa zamanda eğlenceli bir şeyler alın - optimizasyonlar mevcut kodunuzun çok büyük bir bölümünü elden geçirmenizi gerektiriyor olsa bile, buna değer olabilir; ve işleri daha büyük yapmanın oyunu daha iyi hale getirmediğini bile fark edebilirsiniz.

Çok fazla optimizasyona sahip yeni bir oyuna örnek olarak, Factorio'ya işaret ediyorum. Oyunun kritik bir parçası da kayışlar - binlerce insan var ve fabrikanızın her yerinde birçok bireysel malzeme parçası taşıyorlar. Oyun yoğun olarak optimize edilmiş kayış motoru ile başladı mı? Hayır! Aslında, orijinal kemer tasarımını optimize etmek neredeyse imkansızdı - kemerin üzerindeki eşyaların fiziksel bir simülasyonunu yaptı, bu yapabileceğiniz bazı ilginç şeyler yarattı (bu, “ortaya çıkan” oyun şeklini aldı - oyun şaşırtıcı. Tasarımcı), ama kemerdeki her bir eşyayı simüle etmek zorunda kaldın. Binlerce kayışla, on binlerce fiziksel olarak simüle edilmiş öğe elde edersiniz - yalnızca bunu kaldırarak ve kayışların işi yapmasına izin vermek, ilişkili CPU zamanını% 95-99 oranında azaltmanıza izin verir, hafıza yeri gibi şeyleri düşünmeden bile. Ancak, yalnızca bu sınırlara ulaştığınızda bunu yapmak faydalı olacaktır.

Kemerlerle ilgisi olan her şey, kemerlerin optimize edilmesine izin vermek için yeniden yapılmak zorunda kaldı. Kemerlerin optimize edilmesi gerekiyordu, çünkü büyük bir fabrika için çok sayıda kemere ihtiyacınız vardı ve büyük fabrikalar oyunun bir cazibesi. Sonuçta, eğer büyük fabrikalara sahip olamıyorsanız, neden sonsuz bir dünyaya sahipsiniz? Komik, sormalısın - erken sürümler yoktu :) Oyun, şu anda bulundukları yeri bulmak için defalarca elden geçirildi ve yeniden şekillendirildi - Java'nın bir yolun olmadığının farkına vardığında% 100 sıfırlama dahil oyun böyle ve C ++ 'a geçti. Ve Factorio için çok işe yaradı (hala iyi bir şey olsa da başlangıçtan itibaren optimize edilmedi - özellikle de bu, ilgisizlikten dolayı başarısızlıkla sonuçlanabilecek bir hobi projesi olduğu için).

Ama olay orada olması vardırSınırlı bir fabrikada yapabileceğiniz birçok şey - ve pek çok oyun bunu göstermiştir. Sınırlar eğlence için özgürlüklerden daha da güçlendirici olabilir; "Haritalar" sonsuz olsaydı, Spacechem daha mı eğlenceli olurdu? Yoğun şekilde optimize edilmiş "kayışlarla" başlarsanız, hemen hemen o yöne gitmek zorunda kalırsınız; ve diğer tasarım yönlerini keşfedemediniz (fizikle simüle edilmiş konveyör bantlarla ne ilginç şeyler yapabileceğinizi görmek gibi). Potansiyel tasarım alanınızı sınırlandırıyorsunuz. Öyle görünmüyor çünkü pek fazla bitmemiş oyun görmüyorsunuz, ancak zor kısmı eğlenceyi doğru yapmak - gördüğünüz her eğlenceli oyun için, muhtemelen orada bulunamayan ve hurdaya çıkmış yüzlerce kişi var (veya daha da kötüsü, korkunç mesajlar olarak serbest bırakıldı). Eğer optimizasyon bunu yapmanıza yardımcı olursa - devam edin. Olmazsa ... muhtemelen erken. Eğer bir oyun teknisyeni harika çalışıyor, ancak gerçekten parlamak için optimizasyonlara ihtiyaç duyduğunu düşünüyorsanız - devam edin. Eğer ilginç mekaniğiniz yoksa,onları optimize etme . Önce eğlenceyi bulun - çoğu optimizasyonun buna yardımcı olmadığını ve çoğu zaman zarar verici olduğunu göreceksiniz.

Sonunda harika, eğlenceli bir oyunun var. Şimdi optimizasyon yapmak mantıklı mı ? Ha! Hala düşündüğün kadar net değil. Eğlenceli bir şey var mıonun yerine yapabilir misin? Unutma, zamanın hala sınırlı. Her şey bir çaba ister ve bu çabayı en çok önem verdiği noktaya odaklamak istersiniz. Evet, "ücretsiz oyun" veya "açık kaynak" bir oyun yapıyor olsanız bile. Oyunun nasıl oynandığını izleyin; performansın bir darboğaz haline geldiğine dikkat edin. Bu yerleri optimize etmek daha eğlenceli hale getiriyor mu (daha büyük, daha da karışık fabrikalar inşa etmek gibi)? Daha fazla oyuncu çekmenize izin veriyor mu (örneğin daha zayıf bilgisayarlar ile veya farklı platformlarda)? Her zaman önceliklendirmeniz gerekir - oran verme çabasını araştırın. Muhtemelen oyununu oynamaktan ve başkalarının oyunu oynamasını izlemek için bol miktarda asılı meyve bulabilirsiniz. Ancak önemli kısmı not edin - oraya ulaşmak için bir oyuna ihtiyacınız var . Buna odaklan.

Üstte bir kiraz olarak, optimizasyonun asla bitmeyeceğini düşünün. Tamamladığınız ve başka görevlere geçtiğiniz küçük bir onay işaretine sahip bir görev değildir. Her zaman yapabileceğiniz "bir tane daha optimizasyon" vardır ve herhangi bir gelişimin büyük bir kısmı öncelikleri anlamaktır. İyileştirme uğruna optimizasyon yapmazsınız - bunu belirli bir hedefe ulaşmak için yaparsınız (örneğin, "333 MHz Pentium'da bir kerede ekranda 200 ünite" harika bir amaçtır). Terminal hedefinin izini kaybetmeyin, çünkü artık terminal hedefi için ön koşul olmayabilecek ara hedeflere çok fazla odaklanıyorsunuz.

Yanıtların birçoğu, "optimizasyonun" performans yönüne çok fazla odaklanıyor gibi gözükse de ben daha çok soyut bir seviyede optimizasyona ve optimizasyonun tüm sıkıntısına bakmayı seviyorum.

Polyomino'ların yardımıyla bakış açımı geliştirmeye çalışırken, beni mizah haline getirin.

Birlikte çalıştığımız çerçeve veya motor tarafından belirlenen bazı sabit sınırlarımız olduğunu varsayalım.

Daha sonra oyunun ilk katmanını / modülünü oluşturmaya devam ediyoruz.

Devam ederek ikinci katman / modülümüzü oluşturuyoruz.

Bu noktada, iki modül arasında bir miktar boşluk olduğunu fark edebiliriz ve bize tahsis edilen sınırları tam olarak kullanabilmek için optimize etmek için cazip olabiliriz.

Mükemmel, şimdi uygulama tamamen bizim için mevcut kaynakları kullanıyor, uygulama daha iyi, iyi değil mi?

Uygulamamızın üçüncü katmanını / modülünü oluşturmaya devam ediyoruz ve aniden (ilk planlama sırasında tahmin edemediğimiz bir tane bile) 3. katmanın / modülün bizim için çalışmadığını fark ettik.

Bir alternatif ararız, birini buluruz ve sonunda, bu da yeni seçilen 3. modülümüzle uyumsuz olduğu için başvurumuzun 2. modülünü değiştirmemizi gerektirir. (Neyse ki 1. modülümüzle biraz uyumlu, bu yüzden her şeyi sıfırdan tekrar yazmak zorunda değiliz.)

Yani hepsini bir araya getirdik ...

Hmm, ne olduğunu görebiliyor musun?

Çok erken optimizasyon yaparak, işleri optimize etmeyi daha da kötüleştirdik, çünkü en iyi duruma getirdiğimiz şey, sonuçta ortaya çıkan şey değil.

Ve sonradan bazı ek modüller veya ilave çerezler eklemek isteseydik, artık bu noktada bunları yapma kapasitemiz olmayabilir.

Sistemimizin en düşük seviyesini ayarlamak, diğer tüm katmanların altına gömüldüğü için artık mümkün değildir.

Bununla birlikte, onu hemen optimize etmek için dürtü ile beklemeyi seçmiş olsaydık, şöyle bir şey olurdu:

Ve şimdi optimizasyonu bu noktada gerçekleştirirsek, bakmak için tatmin edici bir şey elde ederiz.

Umarım en azından bazılarınız bunu okurken çok eğlendi :) :) ve şimdi konuyu daha iyi anlıyormuş gibi hissediyorsanız - daha iyisi.

Para.

Bu aşağı gelir. Para. Zaman para olduğu için *, daha fazla para üretme garantisi olmayan faaliyetler için ne kadar zaman harcarsanız (yani, bu faaliyetleri yatırım olarak düşünemezsiniz ), daha fazla para harcamayı riske atarsınız ve daha az para kazanırsınız. oyun.

İyileştirmenin çok erken zamanda bazı daha olası yan etkileri ve bundan kaçınmanız için nedenler:

• Meslektaşlarınız sizden nefret ediyor, çünkü özelliklerin elde edilmesi için çok çalışırken, kum havuzunuzda oyuncaklarınızla oynuyorsunuz.
• Gecikmeler daha yüksek yönetimi engeller ve ekibin teslimat tarihlerini kaçırmasına neden olur; bu da oyunun tatil sezonundan önce ilkbaharda yayınlanmasına neden olur ve bu da oyunun yeterince satmamasına neden olur. Bu nedenle, merkez ofis sizi etkili bir şekilde işsiz hale getirecek şekilde stüdyoyu kapatmaya karar verir. Ve iş yok, para yok demektir. (Kimse sizi sevmediği için erken optimizasyon yapmak için çok fazla zaman harcadığınız için, kimse LinkedIn'deki işinizle ilgili olumlu bir inceleme yazmak istemez, bu da sizi daha uzun süre paradan uzak tutacaktır.)

^{* Diğer cevaplar, 'zaman' bölümünü yeterince iyi vurguladı.}

Genel bir not olarak , deneyim, erken optimizasyonun neyin neyin ve neyin olmadığını ve iş için neyin değerli olup olmadığını belirlemeye yardımcı olur.

Örneğin, A oyunu üzerinde çalıştıysanız ve projenin sonunda XYZ özelliğinin oyun döngünüzde özellikle ağır olduğunu fark ettiyseniz ve en sonunda aynı özelliğe sahip olan B oyunu üzerinde çalışmaya karar verdiniz. özelliği yeniden yazmak ve siz baştan optimize gerçekten erken optimizasyon değil biliyorum birşey yapılmayacak olursa bu bir darboğaz olacak.

Optimizasyon, tanımı gereği, bir çözümün etkinliğini kaybettiği noktaya kadar verimliliğini artırma sürecidir. Bu işlem daha sonra çözüm alanının azaltılmasını gerektirir.

Yazılım geliştirmenin ilk aşamalarında hala "gizli gereksinimler" olabilir: çözümünüzün alanını çok fazla azaltırsanız, ortaya çıktığında "gizli gereksinimi" karşılayamayacağınız bir durumda olabilirsiniz daha sonraki bir gelişim aşamasında, sizi daha sonra mimariyi bu şekilde kararsızlığa ve istenmeyen bir dizi istenmeyen davranış biçimine eklemeye zorlar.

Bu durumda fikir, tüm çözümü işe almak ve ancak o zaman, tüm gereklilikler yerine getirildiğinde ve uygulandığında, kodu sıkın. O zaman göreceksiniz ki, kodlama sırasında bir kerede çok fazla uygulayacağınız bir çok optimizasyon artık geç gereksinimlerle olan etkileşim nedeniyle artık mümkün değildir.

Çözümün gerçek alanı her zaman başlangıçta beklediğimizden daha büyüktür çünkü çok karmaşık bir sistem hakkında mükemmel bir bilgiye sahip olamayız.

İlk önce çalışsın. Ardından ipleri sıkın.

Kısacası, daha sonraları değiştirmek istiyorsanız, genellikle erken optimizasyon boşa harcanır ve daha sonra kolayca değiştirilebilen kod yapılarını çok daha düşük bir seviyeye dönüştürdüğünüz ortaya çıkar ve şimdi tekrar yüksek bir seviyeye getirmeniz gerekir. seviye yaklaşımı ve sonucu bir kez daha optimize edin.

Bu, "işe yarar bir iş çıkmış" olmaktan zevk almaya odaklanmak isteyen, optimizasyon gibi, bunu yapmak için doğru zaman olup olmadığını düşünmekten kaçınan, yeni başlayan geliştiriciler için yaygın bir hatadır. Oyunlar gibi büyük projelerin programlanması konusunda deneyim kazandıkça, mevcut kod tabanını ne zaman optimize edeceğinizi ve ne zaman çok erken olduğunu öğreneceksiniz. Bu hatayı yapmaktan korkma, sadece ondan öğrenerek faydalanırsın.

Genel olarak, yalnızca bu andaki geliştirme oluşturma işlemiyle gerçekten çalışamıyorsanız optimize edin. Saniyede saniyede 60 kez milyonlarca nesne oluşturup siliyorsanız.

Dolayısıyla, öğrenme deneyimi açısından, birkaç kez erken optimize etmenin iyi olacağını söyleyebilirim: p

Optimizasyon, bilgisayarın kodda en iyi şekilde çalışmasına odaklanırken, geliştirme için programcının en iyi kod üzerinde çalışmasını gerektirir.

Optimizasyon, öngörüleri ortaya çıkarmaz. Bilgisayarın daha az çalışmasını ve programcının daha fazla çalışmasını sağlar.

Elbette, bir araba tasarlamada olduğu gibi farklı kategoriler var. İlk kasanızı inşa etmeden önce motoru optimize etmenin yanlış bir tarafı yoktur, ancak motorun şeklini bilmeden kasayı optimize etmek zaman kaybına neden olabilir. Modülerlik ve teknik özellikler, ürün bir bütün olarak toplanmadan önce bile optimizasyon için uygun birçok yere sahip olabilir.

İlk aşamada kodun optimize edilmemesi gerektiği yönündeki ifadelere kesinlikle katılmıyorum. Hangi aşamada olduğunuza bağlı. Eğer bu MVP ise - prototip ve sadece 1 ila 2 hafta süren oyuna bakmaya çalışıyorsunuz, zaten yazdığınız her şeyi yeniden yazmaya hazırsınız. Evet, optimizasyon önemli değil. Ancak piyasaya sürüleceğini bildiğiniz bir oyun üzerinde çalışıyorsanız, kodun tamamını optimize etmesi gerekir. İnsanların yeni özellikler ve eklenebilecek şeyler hakkında söylediği hikayeler yanlış anlamadır. En iyi duruma getirilmiş kod yerine, kötü tasarlanmış kod mimarisi. Güzel kod tasarımınız varsa, yeni öğeler eklemek için hiçbir şeyi yeniden yazmanıza gerek yoktur.

Örneğin, bir A * yol bulma algoritmanız varsa, en uygun şekilde yazmanız daha iyi olmaz mı? Daha sonra kodunuzun yarısını değiştirmekten ziyade, algoritmada bazı değişiklikler yapmak zorunda kaldığınız için, çünkü şimdi başka bir yöntem çağrıları ve geri çağırmalar gerektiriyor. Baştan beri optimize edilmiş bir kodunuz varsa, bu size çok zaman kazandıracaktır. Çünkü kendinizi tonlarca yeni komut dosyası yapmak ve derhal tüm bağlantıları kurmak yerine, nesneler ile nasıl etkileşime girdiklerini ilişkilendirebilirsiniz - bu, net olmayan sphagetti koduna yol açar.

Eklemek istediğim son şey, daha sonra, artık oyunu yapmak istemeseniz bile, sonraki oyunlarınız için kullanabileceğiniz optimize edilmiş A * algoritmanıza sahip olmanızdır. Tekrar Kullanılabilirlik. Örneğin, birçok oyun envanter, yol bulma, prosedür oluşturma, npc, dövüş sistemi, AI, Arayüz etkileşimi, giriş yönetimi arasındaki etkileşimlere sahiptir. Şimdi kendinize sormalısınız - "Bu elemanları sıfırdan kaç kere yeniden yazdım?" Oyunun% 70-80'i. Gerçekten onları her zaman yeniden yazmaya gerek var mı? Peki ya onlar korunmuyorsa?