Bir solo geliştirici projesinde ne tür bir proje yönetimi kullanılmalıdır?

Tek başıma, gelişimi 3 bağımsız bölüme ayırabilecek bir oyun projesi üzerinde çalışıyorum (harita oluşturma, “dünya üstü dünya” motoru ve savaş motoru), ancak gelişme ilerledikçe, nasıl başa çıkmam gerektiğinden emin değilim. Bu projenin yönetimi, özellikle bu 3 nokta ile ilgili:

1. Yalnız çalıştığım için sürüm kontrol sistemi kullanmaya değer mi?

2. Planlanan özellikleri / hataları kaydetmek için resmi bir yöntem kullanmalı mıyım (Şimdilik yapılması gerekenleri hatırlıyorum)

3. En önemli soru: ilk önce neyin geliştirileceğini nasıl bilebilirim? Şimdi çok temel şeyler yapıldığı için, kodlanacak özelliklerin listesini biliyorum ama hangi sırayla yapmam gerektiğini bilmiyorum.

Kullanmak istiyorum:

1. Kod yönetimi

Kodumu yönetmek için dağıtılmış bir kaynak kod yöneticisi olan GIT (ve harika referans ) ve limitleri aşmamak için özel bir proje olarak GitHub'ta barındırın .

(Burada bir sürü seçenek var, sadece kaynak kodu yönetimi için google, GitHub'ı veya başka bir web sitesini kullanmak zorunda bile değilsiniz, Git yerel bilgisayarınızda gayet iyi çalışacak, ancak GitHub'ı kullanmak yedekleri yönetmenin acısını çekecek çok daha kolay.

İki bilgisayarınız varsa, birinde yedek makinenizi arayacağınız bir depo oluşturabilir, o zaman bu depoyu yerel ağ üzerinden klonlayabilir ve geliştirme için kullanabilir, bir özelliğe sahip olduğunuzda yedekleme makinesi ve 1: 1 yedekleme olacak!)

2. Sorun ve Özellik yönetimi

Ben kullanırım Trello'nun veya Github yerleşik konu yönetimi böcek ve yapılacak şeyler takip etmek için.

3. Tasarım Süreci Olmak

İlk önce oyunumu tasarlardım;

1. ilk aklımda,
2. sonra kağıda,
3. o zaman muhtemelen fikrimin prototipini yapmak için GameMaker veya PyGame'i kullanın ve oynamaktan hoşlandığım bir şeye sahip olana kadar 1-3 yaşını tekrarlayın.

4. Prototipimi Kılavuz Olarak Kullanın ve Oyunumu Geliştirin

Sonra prototipimi bir kenara bırakıp geliştirmek istediğim bir platform seçerdim. Ardından mevcut motorları arayın ve oyun fikrim için en uygun olanı seçin. Sonra projem için net hedefler koyardım, onları küçük görevler halinde yapılandırır ve sonra işleri bitirmek için çalışmaya başlardım. Bu duruma ulaştığınızda, büyük olasılıkla size en uygun olan kendi çalışma biçiminize sahip olduğunuzu göreceksiniz, o yüzden devam edin!

Geliştirme stiliniz, XP, Şelale, vb. Üzerine uygulayabileceğiniz birkaç farklı metodoloji / felsefe vardır. Sadece en hızlı şekilde ilerlemenizi sağladığınızı hissettiğinizle devam edin.

5. Çok fazla Oyun Test Cihazına sahip olun!

Oynanabilir bir şeyiniz olduğunda, hemen arkadaşlarınızdan denemelerini isteyin! Windows kullanıyorlarsa hızlı yükleyici paketleri ayarlayarak veya Linux / Mac kullanıyorlarsa işlemi otomatikleştirebilecek bir kabuk betiği yazarak size yardımcı olmalarını kolaylaştırın. Testçilerinizin geri bildirimlerine çok dikkat edin ve onları oyun tasarımınız ve ne tür bir oyun kurmaya çalıştığınız hakkında bilgilendirmeyi unutmayın.

6. Oyunum için bir web sitesi hazırla

İyi bir şey yaptığım andan itibaren muhtemelen oyunum için bir web sitesi hazırlarım - örneğin çalışmalarım üzerinde yoğunlaşıyorsam, oyunumun ilerleyişine uygulanamadığında yaratıcılığım ve içeriğimin akmasını sağlamak. ya da gelişimden bir molaya ihtiyacım var!

GitHub kullanırsam , oyunum için bir proje sayfası hazırlardım, aksi takdirde bir WordPress / Jekyll blogunu veya benzer bir şeyi barındırır ve yayınlarımı bununla yazarım.

Bu, potansiyel oyuncuları / testçileri yönlendirecek bir yere sahip olmanın yanı sıra kendinizi motive edecektir!

7. Yarışmaya katılın

Neredeyse her zaman devam eden birçok oyun geliştirme yarışması var. Kurallar izin verdiği takdirde bunlardan birine oyunumla katılmaya çalışırdım. Bu motivasyonu arttırır ve her şeyi daha da eğlenceli hale getirir - kim kazanmayı sevmez!

(Sıkı bir son tarih altında gelişiyorsanız, en azından bu noktayı atlayabilirsiniz.)

Yalnız çalışsanız bile sürüm kontrol sistemi kullanmanızı şiddetle tavsiye ederim. Yanlışlıkla bir şeyleri sildiğinizde veya daha büyük bir değişiklik yaptığınızda, yalnızca daha sonra bunun kötü bir fikir olduğunu ve değişiklikleri geri almanız gerektiğinden, size zaman kazandırabilir.

Düzenleme : Birçok ücretsiz kaynak kontrol çözümü vardır.

• Ben kullandım VisualSVN kurmak ve Windows altında kullanımı kolaydır Sunucusu.

• Ayrıca gibi çevrimiçi alternatifi vardır Codeplex (ile SVNya Mercurial), SourceForge veya Google Code . Sonuç olarak, bir depo oluşturmak ve sürdürmek zorunda değilsiniz ve verileriniz bulutta; İşin aslı, kapalı kaynaklı projelere özgürce ev sahipliği yapamazsınız.

Hata ve özellik izlemeye gelince: Oyununuzu beta test etmek, hataları bildirmek ve özellikleri istemekle ilgilenebilecek daha geniş bir kitleye sahipseniz, devam edin.
Bununla birlikte, bu tür insanlardan sadece bir kaçı (ya da hiç yok) varsa, bu gereksizdir.

Ve gelişim öncelikleri gelince - bu sizin karar vermeniz içindir . Bir projede ne yapılacağını tek geliştiricisinden daha iyi kim bilmeli?

Yalnız çalıştığım için sürüm kontrol sistemi kullanmaya değer mi?

Bence de. Kurulumu oldukça önemsiz ve defalarca yaşadım tadilat yaparken çılgına döndüm ya da aptalca bir şey yaptım ve yaptığım değişiklikleri geri alma yeteneği bir çok zaman kazandı. Onun ardından bir sunucuda barındırılan eğer Artı durumda bizim kod yedeğine sahip herhangi bir şey yanlış giderse .

Planlanan özellikleri / hataları kaydetmek için resmi bir yöntem kullanmalı mıyım (Şimdilik yapılması gerekenleri hatırlıyorum)

Gerekli olduğunu sanmıyorum. Sadece küçük bir hatayı unutmamaya dikkat etmek için yapmayı düşündüğünüz şeyin yazılı bir listesini tutacağım, ayrıca kodlamadan bir mola verdikten sonra tekrar başlamanıza yardımcı olacağını düşünüyorum.

En önemli soru: ilk önce neyin geliştirileceğini nasıl bilebilirim? Şimdi çok temel şeyler yapıldığı için, kodlanacak özelliklerin listesini biliyorum ama hangi sırayla yapmam gerektiğini bilmiyorum.

Yukarıdaki listeyi al, gözlerini kapat ve rastgele kurcala. Parmağınızın hangi özelliği olduğu üzerinde çalışın. Öğeler birbirlerine bağlı olmadıkça, akışı devam ettirmek, olayların belirli bir sırada olmasını sağlamaktan daha önemlidir.

Kesinlikle sürüm kontrolü kullan

Sürüm kontrolü ip cambazı için bir güvenlik ağı gibidir: çılgınca şeyler denemek için sizi serbest bırakır. Kolayca geri dönebiliyorsanız, büyük kod parçalarını silmek büyük bir refaktör değildir. Deponuzda deneysel bir dalda iseniz ve tekrar bir araya getirmeme konusunda karar verebiliyorsanız, bu daha da azdır.

Bu tür bir özgürlüğe sahip değilseniz, ihtiyaç duyabileceğiniz korkusuyla her yerde oturup yorumlanmış bir kod bırakmanız olasıdır.

Git’e oy verirdim. Sözdizimi biraz tuhaf, ama iki harika şey var:

• Düşük havai . Bir klasöre git initgeçin ve yazmayı kontrol etmeye başlamak için hazırsınız. Sürümün tamamını kontrol etmek istemediğinize karar verirseniz, rm -rf .gito klasörde ve artık Git deposu değil.

• SSH ile dağıtılır . Git dağıtılmıştır, yani deponuzun birden fazla tam kopyası (tüm tarihler, vb.) Çeşitli yerlerde olabilir ve bunları senkronize halde tutabilirsiniz. SSH erişiminizin olduğu herhangi bir makinede başka bir Git deposu kurabilir, ardından diğer repoyu uzaktan kumanda olarak ekleyebilirsiniz. Ondan sonra, istediğin zaman sadece git pusho depoya yedeklemek istersin .

  Bu, örneğin tüm deponun bir makinede yaşadığı ve bu makinenin bir Subversion sunucusu çalıştırması gerektiği Subversion'a göre büyük bir avantaj.

Mercurial aynı noktaları kendi lehine alabilir, ancak ben kullanmadım.

1. Evet! İstediğinizden beri revizyon kontrol sistemiyle iyi kabul edildiğinizi tahmin ediyorum. Bu bir zorunluluktur!

2. İkinci sorunuza ilişkin olarak, hataları kaydetmenin resmi bir yöntemi var ve bunu kullanmalısınız. Planlama özellikleri için daha az resmi bir rotaya binmenin zarar görmeyeceğini düşünüyorum (yalnız çalışırken)

3. İlk önce oyununuzu canlandıracak bu özellikleri yapın. Son oyunun nasıl olacağına dair bir fikir verin.

1) Evet, elbette. Mercurial'ı BitBucket ve TortoiseHg üzerinden öneririm. BitBucket 5 kullanıcıya kadar ücretsizdir ve bulutta barındırıldığından beri size bir parça zihin ekler (yedeklemeye gerek yoktur).

2) Yeni özellikler uygulanmadan önce hatalar giderilmelidir. Bekleyen / yapılan şeyleri izlemek için basit erişilebilir TODO listesini kullanırdım. Sadece düz bir metin dosyası kullanabilirsiniz, sadece kaynak kontrol havuzunuza eklemeyi unutmayın.

3) Son kullanıcı tarafından oynanabilir bir şey sunmanın temel bir amaç olduğunu göz önünde bulundurarak, herhangi bir gün yapmak istediğiniz şeyi yapın. Örneğin, fiziği doğru yapmaktan sıkılmıyorsanız, görüntü oluşturma üzerinde çalışıyorsanız veya bu AI için bazı eksik birim testleri ekleyin.

İş topakları birkaç gün içinde yapılacak kadar küçük olmalıdır. Kendinizi motive tutmak ve tükenmişliği önlemek çok önemlidir.

Mimari düzgün bir şekilde yapılırsa, motor / oyunun değiştirilen parçalarını diğerlerini etkilemeden kolayca ekleyebilmelisiniz (aksi halde bazı yeniden düzenleme işlemleriyle başlayın :).

1) Herkesin dediği gibi: EVET (Diyelim ki ucuza online bir tane bile kiralayacağım)

2) Basit bir liste tutun ya da projeniz büyürse ve beta test programına sahipseniz Mantis Bug Tracker programını kurun.

3) Bilmiyorum, ama size nasıl yaptığımı anlatacağım: Önce en az enteresan ve / veya en zor şeyleri geliştirin. Her şey bitene kadar tekrarlayın. Bu şekilde gelişme daha eğlenceli ve kolaylaşır (ve bu soruna çarpmazsınız, bu gerçekleşirse çok geç çözemezsiniz).

Bu soruyu sorduğun için teşekkürler. Bu tam olarak şu an ne yapıyorum.

1) Sürüm kontrolü: Bu şarttır. Şu anda manuel yedeklemeyi sürdürüyorum. Harika çalışan bir şeyin aniden hata atması (ya da beklendiği gibi işlememesi) en az yararlıdır. Sürümleri karşılaştırırım ve sıklıkla aptalca hatalar bulurum (çoğunlukla bir şeyi yorumluyorum)

2) Bir kelime dökümanı oluşturdum ve oyunumun kategorik bir düzende sahip olacağı tüm özellikleri ve alt özellikleri listeleyen çok düzeyli girintiler (ve müşteri / sunucu ile ilgili ya da uygun olanları) listeledik.

3) Aldığım listeden sonra (ki bunlar genellikle tamamlanmayacak, buna bir şeyler eklemeye devam edecek) Oyun akışımı düşünüyorum ve oyunun çalışmasını sağlamak ve onları yapmaya başlamak için gerekli olan tüm noktaları vurgularım. Devam eden sarı anlam eserini işaretliyorum. tamamlandığında yeşildir. portakalın gelişmiş olduğunu veya bilinen bazı böcekleri olduğunu belirtmek için turuncu

Bu yardımcı olur umarım

1.) Herhangi bir proje için sürüm kontrolünü kullanmaya değer. Zaten küçük olanları bile nasıl kullanacağınızı biliyorsanız. Subversion'u yıllardır TortoiseSVN ile Linux ve Windows'ta kullandım . Küçük (<500 satırlık) bir proje yaparken bile bunun için bir havuz oluşturacağım, böylece değişiklikleri geri alabilirim, projeyi bir süre bırakırsam, ne yaptığımı izleyebilirim, vb.

2.) Projenin ne kadar büyük olacağına bağlı. Bir takımla oynamayı ve dağıtmayı planlıyorsanız, muhtemelen bir hata izleme sistemine sahip olmanız gerekir. Halen 20k çizginin üzerinde bir projede solo çalışıyorum (bir sanatçının olmasına rağmen) ve yapılacaklar listemi de SVN depomda olan bir metin dosyasında tutuyorum. Tam olarak henüz henüz başkalarıyla paylaşma gereği duymama rağmen, bugüne kadar hata takibini yapmamak benim ihtiyaçlarıma uygun. Bir ihtiyaç olana kadar bu konuda endişelenmem. Olabilecek en kötü şey, önceden yazdığınız hataları girmeniz ve düzelttiklerinizi düzeltmeniz / düzeltmeniz gerekmesidir. Notlarınızın zihinsel izini kaybetmeye başladığınızda, bir hata izleyici edinin.

3.) Kağıda çizin. Oyunun bitmesini istediğin şeyle başla, bunun özünü yaz. Sonra onu yapmak için gerekenleri ayırın: çarpışma tespiti? ağ kodu oyuncu türleri ve canavarlar? sınıf hiyerarşileri? Vizyonunuzdan geriye doğru çalışın, böylece onu nasıl kurgulayacağınız konusunda net bir fikir edinebilirsiniz. Nesne yönelimli bir dil kullandığınızı varsayıyorum. Başlarken en önemli adım, bu sınıf hiyerarşilerini makul bir şekilde ayarlamaktır. Kesinlikle en fazla kalıtımsallığa sahip olmaya çalışmayın (bazen kaçınılmaz olsa da), sınıf ilişkilerini bir diyagram düzenleyicide ( Dia kullanırım , vb.) Çizin .