Oyun geliştirme sürüm kontrolü - Ne zaman dalmalıyım?

Son zamanlarda projelerimde Sürüm Kontrolü'nü kullanmaya başladım (yalnız üzerinde çalışsam da). Tüm gelişim sürecinin geçmişini tutmanın güzel bir yol verdiğini (konu takibi ile) ve projelerim için yedek tutmama izin verdiğini biliyorum.

Sürüm kontrolünü kullanmanın özelliklerini ve avantajlarını yavaşça keşfettiğim için, dallanma fikrine kapılıyorum. Ne zaman yapmalıyım?

Her seferinde gidip yeni bir özellik geliştirmeli miyim, yoksa belirli bir dönüm noktasına ulaştığımda arada bir mi?

Açıkçası, tek başına çalışırken dallanma oldukça işe yaramaz, ancak şimdi iyi alışkanlıklar edinmeyi ve alışmayı tercih ederim.

Mike McShaffry'nin (bu arada harika bir kitap olan) Game Coding Complete kitabını okurken, yazar üç satır tutmayı önerdiğinde tamamen kaybolmuştum:

• Ana : Düzenli değişikliklerin yapıldığı ana gelişme dalı.
• Altın : Son kilometre taşının geldiği altın kol.
• Araştırma : Ana dalı olumsuz etkileyebilecek şeyleri test etmek için şube (oyun motorunun önemli bileşenlerini değiştirmek, vb.).

Olması gereken bu mu? Büyük geliştirici ekipleriyle oyun geliştirme dünyasında gerçekten nasıl çalışıyor?

Temel olarak: Oyun geliştirmede genellikle ne zaman bir dal (ve birleştirme) olur?

Dallanma, özellik için VCS desteğine biraz bağlıdır (yani: VCS'nin bunu kolaylaştırması veya zorlaştırması).

Ancak en azından, projenizin bağımsız olarak desteklenen her bir sürümü için bir şube istiyorsunuz. Diğer bir deyişle, aynı kod tabanından oluşturulmuş ayrı ürünler olan ve aynı zamanda güncellemeleri düzeltme ve yayınlayabilmeniz gereken "Oyun 2" ve "Oyun 2 + Genişleme" seçeneğine sahipseniz, bunlardan her birine sahip olmak istersiniz. ana kod tabanından kendi dallarında var olurlar, böylece çekirdek kod tabanına yapılan düzeltmeler bu ürünlerin her birine bağımsız olarak birleştirilebilir. (Tipik olarak, bu dallar, her bir ürün piyasaya sürüldüğünde veya ilk birkaç sürümde dışarı çıkmak istemediğiniz kod temeli üzerinde çalışan kişiler varsa, belki de birkaç gün / hafta önce yaratılır)

Dalların kullanımını zor veya acı verici hale getiren bir VCS ile çalışırken (SourceSafe, svn, vb.), O zaman muhtemelen piyasaya sürülen her ürün için bir "sürüm" dalı tutmanız ve "trunk" ana gelişiminizi yapmanız en mutlu olacak, "bosluk" dan "bülten" dallarındaki değişiklikleri bu bültenler için düzeltmeler yapmanız gerektiğinde ve gerektiğinde birleştirmek

Öte yandan, dallanma ve birleşme üzerine inşa edilmiş yeni VCS sistemlerinden biriyle çalışıyorsanız (git, Bazaar, Mercurial, vb.), Gelişiminizi çok kısa sürede yapmaktan büyük mutluluk duyacaksınız. -li "özellik" dalları. Örneğin, AI yol bulma üzerinde çalışıyorsanız, bir "yol bulma" dalı oluşturabilir ve kodu orada uygulayabilirsiniz. İşiniz bittiğinde, o şubeyi ana geliştirme bagajınıza geri koyun ve (isteğe bağlı olarak) çalıştığınız şubeyi silin. Bu yaklaşımın avantajı, bir işi tamamlamak yerine eşzamanlı olarak birden fazla iş üzerinde çalışmanıza izin vermesidir. Bir sonraki başlamadan önce görev.

Şu andaki ev projemde (git kullanarak) şu anda aktif olan ve çeşitli farklı özellikler üzerinde çalışan beş farklı özellik dalım var. İkisi aynı şeyi yapmak için alternatif yaklaşımlardır (profil oluşturma için), ikisi deneysel oyun mekaniği fikirleridir ve biri AI sistemlerimin büyük bir kırıcısıdır ve aslında kodun derlenmeyeceği şekilde bozulmuştur şimdi. Ancak referans ve destek için kendi özellik dalında kararlıdır ve kırılması diğer özellikler üzerinde çalışmamı engellemez; Bu diğer özellik dalları (ve aynı zamanda ana gelişme gövdesi) hala doğru şekilde derlenip çalışır.

Büyük takım profesyonel oyun geliştirme deneyimime göre, hala daha eski (ve ticari olarak desteklenen) sürüm kontrol sistemlerinden mahrum kaldık. Performans muhtemelen en yaygın kullanılanı, ardından Subversion'dur. Çalıştığım her yerde, bir 'trunk' şubesi ve daha sonra her bir teslimat için ayrı bir 'serbest bırakma' şubemiz oldu (dönüm noktası / demo / release / etc). Bazen birileri, yaptıkları ya da test ettikleri büyük bir değişiklik için kişisel bir dal oluşturacak, ancak bu son derece nadirdir ve genellikle “bu farklı fizik kütüphanesiyle oyunu çalıştırmaya dönüştürme” gibi şeyler için geçerlidir. piyasaya sürülen ürün.

Zaten yukarıda mükemmel bir cevap ama dikkat edilmesi gereken bir şey ne zaman dallamak istediğiniz ve etiketlemek istediğiniz.

Çoğu vcs etiketlemenize izin verir (bazen etiketleme olarak adlandırılır). Her önemli yapı oluşturduğunuzda bir etiket uygulamanız gerekir (playtest veya beta testi için veya girmekte olan bir özellik için). Bir çeşit Sürekli Entegrasyon kullanıyorsanız (ve yapmanız gerekir), CI sistemi başarılı yapıları etiketlemelidir. Temel olarak, geri dönmek isteyebileceğiniz bir şeyi (dal oluşturmak veya bu sürümde bir şeyi nasıl yaptığınızı kontrol etmek için) yapmak istediğiniz her zaman bir etiket / etiket yapın. Genellikle düşük maliyetlidirler ve eklemesi kolaydır.

Çok şiddetle tavsiye edeceğim bir diğer şey de varlıklarınızı ve kodunuzu aynı versiyonlama sisteminde tutmak. Bir dalın (veya etiketin) bir kodunun olması, varlıkları eşleştiremezseniz (ve sonra dallarsa) tamamen yararsızdır. Bu, oyun şirketlerinin sevdiği başlıca nedenlerden biri Performanstır - kodunu saklarken ikili sanat dosyalarını saklamak aynı derecede mutludur ve (git'in aksine) teknik olmayan türler için anlaşılabilir!

VCS'nizde derlenmiş dosyaları kontrol etmek istediğiniz gibi hissettiğiniz herhangi bir zamanda, bunu nasıl önleyebileceğinizi düşünün. Tecrübelerime göre, neredeyse her zaman uyuşmayan verilere, eksik kaynaklara (örneğin sıkıştırılmış bir DDS dokusu kontrol ediliyor ancak kaynak png'sine bakılamıyor) yol açıyor. Dışa aktarılan dosyaların bir yerde önbelleğe alınmasıyla daha iyi hizmet veren bir varlık boru hattınız varsa (bu nedenle herkes aynı dosya kümesini yeniden oluşturmaz), VCS'nizde kaynak varlıkları oluşturma ve dışa aktarılan dosyaları bir dosyaya yerleştirme işlemine sahip olmanız gerekir. önbellek (veya paylaşılan sürücü, hatta ayrı bir VCS). Ancak dışa aktarılan dosyaları elinizle kontrol etmeyin - sizi ısırır (özellikle de bir ekibin parçası olarak çalışıyorsanız).

Bu kitabı çok sevdim ve ilgisini çeken herkese tavsiye ediyorum. Bir indie projesinde, ayrı versiyonlar yaratmanız gerekmediği ya da istemediğiniz sürece, hiçbir dallamaya ihtiyacınız yoktur; Biri Android, diğeri PC için, ya da bu satırlar boyunca bir şey gibi.

Söylediğin gibi, iyi alışkanlıklar edinmek istersen, Mike'ın yaklaşımını izlerdim. İki indie projemde kullandığım yaklaşım çok mantıklı ve yaklaşıyor.

Geri dönüp daha fazla çalışmanız için ihtiyaç duyduğunuz her şey, dallanmalıdır (ancak mutlaka dallanmamalı).

Bunun nedeni basit. Başka bir kod değil, bu kodun sabit bir sürümünü yayınlayabilmeniz gerekir, o zaman bir dal üzerinde çalışmanız gerekir.

VCS'ler farklı. Bazıları - git gibi - daha sonra herhangi bir taahhütte bulunmak çok kolaydır, diğerleri - CVS gibi - daha sonra çalışmak çok zordur.

Belki tercih ettiğiniz sürüm kontrol sistemiyle en iyi nasıl çalışacağınızı sorarak stackoverflow ile ilgili bir soru açmak istersiniz? Eğer yoksa gerçekten tarihin bir sürü henüz başlamamış, çalışırken ve sizin için en iyi sürümü kontrol sisteminin sormak için bir öneri yolu anlatan bir soru açmak isteyebilirsiniz?