Kod atlamadan önce planlamaya değer mi?

Her zaman planlamanın bir oyun için önemli olduğunu düşündüm. Ama hangi noktada olduğunu bilmiyorum. Bazı planlama yerine kod yazmak için söylüyorum ama kod hala ne zaman daha kolay ne yapacağını bilecek çünkü hala önemli gibi hissediyorum. Şu anda çok sayıda içeriğe sahip olacak bir oyun üzerinde çalışıyorum, bu yüzden thoses içeriğini tanıtan bir tasarım belgesi başlatmaya karar verdim ve bir yan düzeyde yapılıp yapılamayacağını kontrol etmek için kavram kanıtları yapıyorum. Konsept kanıtlarının bölümleri daha sonra gerçek oyunda kullanılabilir.

EDIT: Bu proje üzerinde yalnız çalışıyorum.

Yani sorum şu: Kodda atlamadan önce planlamaya değer mi? Hala başkalarının bu konuda ne söyleyeceğini bilmek istiyorum. Çünkü hala düşünmek yerine kodlamam gerektiğini söyleyen bazı insanlar alıyorum .. öyleyse bu konuda ne düşünüyorsun?

Sorunuzda iki akıllı şey söylediniz:

1. "düşünmek yerine kod" - bunu açıklayan bir felsefe var: http://gettingreal.37signals.com/toc.php
2. "Kavramın yapılıp yapılamayacağını kontrol etmek için kanıtlar" - Gördüm ve neredeyse bittiğinde yapması imkansız ya da son derece zor olan birçok fikrim oldu. Bazen bunu tahmin edemezsiniz, çünkü programlama ortamınız (dil, kütüphaneler, donanım performansı) sizi sınırlar.

Bu yüzden diyorum ki:

• tasarım, ancak ortak çalışanlar veya yatırımcılar aramıyorsanız, sizin için eğlenceli değilse ve programlamadan bir mola vermedikçe büyük bir tasarım belgesi yapmayın;
• her zaman neyi başarmak istediğinizi unutmayın; her modülün tasarlanmış bir giriş ve çıkışı olmalıdır; bu şekilde modülü kolayca test edebilir ve siste gezinme hissiniz olmaz;
• kod yazma zamanınızın yalnızca% 5'ini aldığından (en azından son kodu yazarken) çoğu zaman yine de tasarladığınızı unutmayın;
• programlama teorik bir bilim değildir, bir şeyin kağıt üzerinde çalışıp çalışmayacağını kontrol etmek yerine, onu kodlayabilir ve deneyebilirsiniz; nihai ürün çoğunlukla kullanıcı girişini kusursuz yapmak, GUI güzel görünmek ve özel durumlar ile uğraşmakla ilgilidir - bir fikrin kirli bir testi hemen yapılabilir;
• fikirlerinizi unutmaktan korkuyorsanız yapılacaklar listesi oluşturun
• daha az hevesli olacakları ve bir alanda daha fazla deneyime sahip olabilecekleri için arkadaşlarınızla fikirleriniz hakkında konuşun; Bir keresinde birim parametrelerini (stratejik bir oyunda) gizli tutma fikrim vardı, ama arkadaşım bana bunun kötü bir fikir olduğunu söyledi, çünkü böyle bir oyun oynadı ve korkunç bir kullanıcı deneyimi oldu.

Evet, ama sadece biraz .

Oyun programlama, özellikle oyun programlama için, herhangi bir kod yazmadan önce iyi bir kullanım senaryosu olması önemlidir . Örneğin, oyuncunun ne yapması gerekiyor, nereye gitmesi gerekiyor ve nasıl, dünyayla nasıl etkileşime giriyor, vb. Bu kağıt üzerine çizilmiş bir hikaye tahtası olabilir veya bir akran ile bir tartışmadan çıkabilir ... oyun tasarımının bir parçasıdır ve oyunun nasıl oynanması gerektiği hakkında kaba bir fikir bile olmadan kodlamaya başlamak aptalca olacaktır.

Ancak oyunların tekrarlı olarak oluşturulması gerekir . Oyununuz için büyük bir özellik yaratamazsınız ve umarım oynamak eğlenceli olur. Neyin işe yarayıp neyin yaramadığını öğrenmek için düzenli oyun testlerine ihtiyacınız var ve yinelemeyi sürdürüyorlar. Yürütülebilir dosya ne kadar hızlı çalışırsa, oyun tasarımı o kadar hızlı test edilebilir, oyunun sonunda o kadar iyi olur. Bu yüzden, çok resmi olmayan bir oyun tasarımından ASAP kodlamaya başlamak, nelerin çıktığını görmek ve devam etmek her zaman daha iyidir.

Kesin olan bir şey var, yalnız kodladığınız için herhangi bir fantezi yazılım tasarım belgesine veya metodolojisine ihtiyacınız yok, kaynak kodu tasarım.

Bazıları düşünmek yerine kod yazmanız gerektiğini söylüyor? Peki kodlamak için ne oluşturmak istediğinizi bilmeniz gerekir, ne oluşturmak istediğinizi bilmek için önce sahip olmak istediğinizi düşünmeniz gerekir, ergo kodlamadan önce düşünmeniz gerekir;).

Ve cidden, muhtemelen başlangıçta ayrıntılı bir plana ihtiyacınız yoktur, ancak bir taslağa ve / veya kilometre taşlarına sahip olmak her zaman yararlıdır - ayrıca sizin tutumunuz için, işleri olduğu gibi geçtiğinizde, daha fazlasını yapmaya daha teşvik edileceksiniz iş.

Hem kodlama hem de planlama gereklidir. Önce planlayın, sonra kodlayın, ancak her şeyi aynı anda planlamayın. Bir çekirdek planlayın, kodlayın, planınızı gerektiği gibi güncelleyin, daha sonra oynanabilirlik, grafikler, sesler, spritelar vb. Açıkçası böyle bir döngüyü birden fazla kez yürütebilirsiniz ve ihtiyaç duyulması halinde ölçeklendirmeyi destekleyecek kararlar vermenizi tavsiye ederim.

Kod yazmadan önce nereye gittiğinizi bilmelisiniz ve yazma / çizim yapmak istediğinizi gerçekleştirmek için iyi bir yol olabilir. Ben diyorum çizim şemaları, skeçler vs. çizim de çok yardımcı olabilir çünkü. Word veya başka bir şeyle yapılmış harika bir belge yapmanıza gerek yok, sadece bir kalem ve bir parça kağıt (çok fazla kağıt?) Alın ve çizin, aklınıza gelebilecek her şeyi yazın.

Bana göre, kalem ve kağıt kullanmak iyi bir uygulamadır, fikirlerinizi hayata geçirmeye yardımcı olur ve ayrıca herhangi bir yere gitmeyi önlemek, hedefinizi düzeltmek için nereye gitmek istediğinizi ayarlamaktır. Yansıtma gerektiren her şey için çalışır. Ve birçok alanda, gerçek işi yapmadan önce bir şeyler yazmak açıktır.

Size uygun olanı yapın. Şahsen ben bir şeyleri küçük ölçüde planlıyorum, ama hiçbir şey kodlamaya başlamadan önce tasarım belgelerine son derece ayrıntılı planlar yok. Sizin için en verimli olanı yapın, özellikle de yalnız çalıştığınız için.

(Sorunun en azından bir dereceye kadar cevap her ikisi için de geçerli olsa da, sorunun oyun tasarımı değil kod-tasarım / mimari bakış açısından yapıldığını varsayıyorum.)

Daha önce de belirtildiği gibi, her ikisine de ihtiyacınız var ve onu dengelemeniz gerekiyor. Kod akışınızın / yapınızın hem aşırı tasarımı hem de az tasarımı sorunlara neden olabilir. Doğru dengenin ne olduğunu söylemek zor, ama genellikle kodun geri kalanının şu anda programladığım şeye nasıl katılacağını ve olası sorunları düşüneceğini en azından belirsiz bir fikre ihtiyacım olduğunu görüyorum, Aksi takdirde "Kendimi çıkmaz sokakta kodlama" eğilimindeyim - anladığım bir duruma geliyorum "tamam, şimdi bu sorunu nasıl çözdüğüm sayesinde, önceki tüm çözümümü (veya daha da kötüsünü en kötü durumlarda) ortaya koyan yeni bir sorun yarattım ) beyhude".

Genel olarak, benim görüşüme göre, doğru bir dengeye sahip olup olmadığınızı kabaca değerlendirerek "ne olursa olsun" senaryolarını "daha sonra ne olursa olsun (şimdi kullandığım benzer paradigmaya tamamen uygulandığında) bu A parçasının biraz farklı çalışması gerekiyor, bu da değişiklikleri bağlayan B parçasını tamamen yeniden işlemem gerektiği anlamına mı geliyor? ". Bir parçadaki mimari değişiklik, bir veya iki parçayı birden değiştirmenizi gerektirmiyorsa ve değişiklikler kademeli değilse (yani B parçasına bağlanan sonraki parçaları ve daha sonra vb.), kod nispeten iyi bir şekilde bölümlere ayrılmıştır.

Ama gerçekten, bu biraz deneyim kazandıktan sonra hissedeceğiniz bir şey. Bu kısmen herkesin başlangıç ​​gamedev'lerine önce bilinen ve kolay bir şeyi kodlama (Breakout / Tetris / Snake) ve tüm menüler, sesler, efektler, tamamen bitmiş oyunu yapmak için her şeyle tavsiyelerde bulunma tavsiyesi veriyor - daha iyi daha küçük bir projeyi mahvetmek ve (iyi ya da kötü bir şekilde) yapmak, çeşitli mimari kararların etkilerinin ne kadar yayıldığını hissetmenize yardımcı olacaktır.