Özellik sürünmesini avantajım için kullanabilir miyim? [kapalı]

Özellik sürünmesini avantajım için kullanabilir miyim ?

Bir oyunun prototipini her oluşturduğumda, özellikler yanlışlıkla eklenir. Bu ya tesadüfle olur ya da mevcut içeriğe göre eklenmesi kolaydır.

Oyunun türünü bilirsem, temel mekaniği yapmaya başlayabilir ve belirgin hale geldikçe özellikler ekleyebilir miyim?

Örneğin, 6 ay boyunca 2 boyutlu bir platform yapmak istersem, koşmaya, zıplamaya, ateş etmeye vb. Yoksa önceden belirlenmiş bir planı olmayan bir zaman yatırımı için çok riskli mi?

Bunun arkasındaki mantığım, tasarımın kova için daha fazla patlama olacağı. Tasarım tercihleri, yapılması kolay (zaman açısından) etrafında daha kolay oluşturulacaktır.

Özetle, ben tasarlamadan önce bir oyun inşa etmede bir sorun var mı?

Bu ilginç bir soru. Temel olarak cevap vermek, gri tonlarını siyah-beyaz ikilemine karşı arttırır.

tasarlamadan önce bir oyun inşa etmede bir sorun var mı?

Bu soruyu evet ya da hayır türü olarak düşünüyorsanız, cevap sadece şöyle olabilir: evet, var. Cevap daha nüanslıysa, değişir. Sebep: Bazı tasarımlardan önce asla bir oyun inşa etmemelisiniz . Ancak , tasarımın bazı kısımlarını daha sonra kullanmak üzere kaydedebilirsiniz .

Bu, konuyu elinizin altında bir iş olarak görüp görmemeniz gerektiğini sanmıyorum. Aksine, derece olarak düşünmeniz gereken bir şeydir. Özellik sürünme belki de oyun geliştirme açısından tüm kötülüğün ikinci köküdür (birincisi, Donald Knuth'un bize sahip olduğu gibi, "erken optimizasyon tüm kötülüğün köküdür" ). Ancak, tecrübelerime göre, ana özelliklerden herhangi birini düşünmemek, yani en azından temel mekaniğinizle gitmek istediğiniz yerde temel bir tasarıma sahip olmak da iyi bir fikir değildir.

İlk temel neden, kaynak olarak (kaynak olarak zaman da dahil olmak üzere) size yol gösterecek bazı planlamalara sahip olmanın yararlı olmasıdır - çünkü aşırı deneme-yanılma nedeniyle her zaman çıkma noktalarına ulaşmak, öngörülemeyen özellikler içermesi gereken kaynaklar.

İkinci ana sebep, oyun-tasarım-bilge, tutarlılıktır. İyi oyun tasarımı, kavramsal tutarlılığa veya isterseniz tutarlılığa sahiptir. Bu, genel oyun oynama, tarih, uygulama, hatta grafiklerin birbirine olabildiğince düzgün bir şekilde uyması gerektiği anlamına gelir. Ana özellikler hareket halindeyken öğrenilirse, bir oyun tasarımının böyle bir şey elde etmesi pek olası değildir. Başka bir şey için değilse, hareket halindeyken çok fazla rastgelelik var: adım atacağınız şeylerin , geliştirme sürecinde ne zaman bulduğunuza bağlı olarak çok farklı etkileri olabilir .

Söylediklerini hiç yapmamalısın demek istemiyorum. Sadece bir denge bulman gerektiğini iddia ediyorum.

Örneğin, 6 ay boyunca 2 boyutlu bir platform yapmak istersem, koşmaya, zıplamaya, ateş etmeye vb. Yoksa önceden belirlenmiş bir planı olmayan bir zaman yatırımı için çok riskli mi?

Cümlenize küçük bir değişiklik getirerek başlardım. Koşma, zıplama, atış vb. Yaparak zaten çekirdek mekaniği uyguluyorsunuz. Örneğinizde hareket halindeyken ekleyeceğiniz şey, belirli oyun oynama özellikleridir.

Oyunun 2D bir platform olacağını bildiğiniz için, koşma, atlama veya çekimin oyun tasarımına bağlı olarak değişemeyeceği değil. Oyuncunuz duvarlarda koşabilir mi? Oyuncunuz zıplarken havada yüzebilir mi? Hatta, oyuncunuz koşarken ateş edebilir mi? Oyuncunuz sadece doğrusal bir yönde mi yoksa bir parabolla mı ateş ediyor? Bu kararlar oyun özelliklerine çok bağlı olabilir.

Ama şunu anlıyorum: bu mekaniğin çoğu zaman çok az değişen kısımları var. Bu nedenle, biraz oyun tasarımı yaparsanız ve koşma, atlama, çekim vb.'nin nasıl çalışacağından emin olmak kadar temel özelliklere karar verirseniz, bu bir başlangıçtır. O zaman bu mekaniğe gidip üzerine inşa etmeye devam edebilirsiniz.

Tabii ki daha sonra, ne kadar temel olursa olsun, bu mekaniği değiştirmenizi gerektiren yeni bir özellik bulabilirsiniz. Ancak buradaki anahtar olasılıktır. En azından oyun için sahip olduğunuz temel fikirler için koşma, atış, zıplama vb. Sonuçları hakkında biraz düşünürseniz, bunun çok sık olma olasılığı daha küçük olacaktır.

Son olarak, bu rotaya gitmek istiyorsanız, aşağıdakileri öneririm. Bunu yinelemeli bir süreç olarak düşünün. İlk, geniş düzey tasarım düşüncesini yaparsınız. Başarılı olmak için oyununuzda temel ve daha "evrensel" görünen şeyleri uygularsınız. Sonra biraz daha tasarım düşünürsünüz, uyguladığınızı yeniden değerlendirir ve biraz daha uygulamaya devam edersiniz.

Oyunlar gibi karmaşık projeler yaparken, genellikle istediğiniz tüm özellikleri yapamazsınız çünkü zamanınız / paranız bitiyor veya beklediğiniz kadar iyi olmadıkları için. Bu özellik sürünme olarak bilinir. Ama bunun bir ters tarafı var; ayrıca ihtiyaç duymadığınızı düşündüğünüz özellikleri de bulacaksınız, ancak proje şekillendikçe ihtiyaçları da ortaya çıkıyor.

Bu yüzden insanlar prototipler üretirler - böylece neyin işe yarayıp neyin yaramadığını öğrenebilirler, böylece çalışmayan özellikleri kesebilirler , aynı zamanda harika olacak yeni özellikler bulabilirler . Öğrenmediğiniz şeylerden hiçbirini yapmıyorsanız, yanlış yapıyorsunuz demektir.

Bu temelde Gelişmiş Prototipleme adlı bir konuşmada ifade edilen duygu Chris Hecker ve Chaim Gingold'un Spore üzerine yaptıkları çalışmalardan birçok çalışmayı içeren ve çoğu zaman işe yarayan ve olmayan şeyleri şaşırtan, bütünüyle yeniden tasarlanana kadar ilerledikleri prototip geri beslemesine dayalı sistemler.

Başka bir örnek Left 4 Dead için tasarım sürecidir ; İlk başta oyunun sadece temel zombileri vardı, ancak deneyimli oyuncularla oyun testlerinden, tasarımcılar oyuncuların etkili bir şekilde birbirine yapıştığını ve oyunun çok kolay olduğunu buldular, bu yüzden takımı parçalamak ve oyunu heyecan verici tutmak için özel zombiler eklediler.

Tabii ki, bu , önceden herhangi bir tasarım yapmadan oyununuzu inşa etmeniz gerektiği anlamına gelmez . Devam etmeden önce oyununuzun çekirdeğinin eğlenceli olduğundan emin olmalısınız, çünkü bu genellikle bir oyun yapmanın en zor kısmıdır.

Evet diyorum, devam et. Ancak her yeni bileşen arasında bir uyum sağlamak için bazı ortak özellikleri / sınıfları önceden planlayın.

Birlik, oyun geliştirmeye bileşen yaklaşımı ile bilinir ve bu gelişim biçimine kolayca izin verir. Unity kullanmıyorsanız, yarı bileşenli bir yaklaşımı çoğaltabilirsiniz. Diğer oyun motorlarına aşina değilim.

Birlik oyun nesnelerinin hepsinin bir dönüşüm bileşeni vardır. Bu, nesnenin konumunu, dönüşünü ve ölçeğini belirtir. Bu nedenle, bu değerleri tutmak için genel bir 'dönüşüm' sınıfı yapın, ayrıca gerçek oyun nesnesine bir referans yapın.

Örneğin, bir 'Atlama' bileşeni alın. Konumun manipülasyonunu yapmak için tüm mantığın bir oyun nesnesinin dönüşüm sınıfıyla çalışmasını sağlayın. (Ya da motorunuzda zaten benzer bir yerleşik sınıf olacaktır.) Bu 'Jump' sınıfını herhangi bir nesneye bağlayabilirsiniz ve bir eylem tetiklendiğinde sınıf dönüşüm konumunu canlandıracaktır (Jump.PerformJump () ya da her neyse). Jump sınıfının sahibi (veya en azından minimum bilgi) hakkında hiçbir şey bilmesine gerek yoktur.

Artık bir ton bileşen oluşturarak eğlenebilir, daha sonra bunları oyun nesnelerine ekleyebilir, bir nesne üzerinde birleştirebilirsiniz, vb. Örneğin: Çalıştır, Atla, Crouch, MovingTile, FireWeapon ('bullet' sprite ve yapılacak davranışı belirtin genel bir bileşen) vb.

Birden çok kullanıma / varyasyona izin vermek için her bileşeni mümkün olduğunca genel yapın. FireWeapon için mermi hareketli grafiğini, hızını, hasarını vb. Belirtebilirsiniz. Bu nitelikleri normalleştirmeye çalışabilirsiniz, böylece hız ve hasar 0 ile 1 arasında belirtilir. Sonra bunları oyunun maksimum değerlerine ölçeklendirin. Bu şekilde sadece silahlar arasındaki göreceli farklılıklar hakkında endişelenirsiniz. Ayrıca bu, daha yüksek bir zorluğun daha yüksek maksimum hasara sahip olduğu zorluk gibi küresel ayarlara uyum sağlar.

Bilmeden önce, takmanız gereken bir bileşen cephaneniz var ve artık herhangi bir oyun türü için hızlı bir şekilde geliştirebilirsiniz.

Özet: Çoğu zaman tek bir kodlama adımından sonra tek bir tasarım adımına sahip olamazsınız. Bunları değiştirmelisiniz. Genel bir kural olarak, önceden tasarlanmış olana (zaten kodlanmış olana değil) saygı göstermeye çalışın.

İlk tasarıma sahip olmama hakkında (sadece taslak veya zihinsel bir görüntü): bir tasarımınız yoksa bir tasarımınız yoktur. Biriyle gelmek için bir şeyler yapmalısın. Ama bir tane inşa etmeye başladığınız sürece, ona saygı duymaya çalışın, her seferinde yeni bir tane ile gelmeyin.

Deneme yapın ve rastgele özellikler alın zararlı olabilir veya olmayabilir. Hatta yararlı veya kaçınılmaz olabilir. Örneğin: zıplamayı desteklemek istediğinizi biliyorsunuz (birçok 3D / 2D RPG zıplamaya izin vermiyor). Nasıl biliyorsun? Bir engeli sıralamak için zıplamayı gerektiren bir oyun haritası düşündüğünüz için mi? Bu nedenle, atlama uygulaması, oyuncunun bu engeli sıralamasına izin verdiği veya maksimum ulaşılabilir yükseklik gibi belirli özelliklere uyması gerektiği sürece yeterince iyidir, haritadaki öğeler veya oyun nesneleri tarafından artırılabilir mi, fizik hızlanma veya sıçrama içermelidir ( Mario bir düşmana atladığında tekrar yükselmek için dürtü kazanır ve bu oyun için çok önemlidir)?

Bu soruları zaten cevaplayabiliyorsanız, tasarım belgeleriniz (hayali veya gerçek) çok eksiksizdir. Bunlara cevap veremiyorsanız, tasarımınız eksiktir. Bu durumda, tasarımda çalışmaya gitmek veya boşlukları doldurmak için deneme yapmak zorunda kalacaksınız. Fırsatlar çok açık veya çok kısıtlayıcı olabilir. Oyun seviyelerinizin bazılarında engeller varsa ve onlar için zıplamaya ihtiyacınız varsa, o zaman maksimum ulaşılabilir irtifaya veya hıza karar vermek için çok fazla özgürlük var, belki de sadece bir fizik motoru varmış gibi davranmaya karar verdiniz. atlama animasyonu görsellerini geliştirmek ama başka bir şey için buna ihtiyacınız yok. (Birçok 2D RPG oyununda istediğiniz zaman atlayamazsınız, ancak bir haritada tek bir karo deliği olduğu sürece, içine adım atmaya çalışmak, otomatik olarak delik döşemesinin yanındaki zemine atlamayı tetikler)

Zaten karar verilen şeye saygı duyduğunuz sürece tam bir tasarım olmadan koda gitmenin tamam olduğunu anlıyorum. Ayrıca, oyun evrenleri çeşitli farklı düşünme süreçlerinden inşa edilebildiğinden, bazı durumlarda kaçınılmaz olabilir. Örneğin bir kart oyunu: Kartların belirli bir zamanda saldırı ve savunma, masada belirli sayıda kart olmasını istediğimi ve sıradaki oyuncunun diğer kartın hangi kart saldırısıyla seçebileceğini biliyorum. Bazılarına zaten eksiksiz bir tasarım olarak görünebilir, ancak daha sonra oyunun dengelenmesi gelir, ancak birçok simülasyonla mümkündür. Birçok simülasyondan sonra Attack 10'lu bir kartın aşırı güçlendiğine karar verdim, sadece oyundan silebilirim ama çok sevdim, böylece farklı bir şey yapacağım, Yeni bir kural oluşturacağım, eğer bir oyuncu böyle bir kartla saldırırsa, bu tur sırasında diğer kartla saldıramaz. Şimdi oyun mekaniğini zenginleştiren yeni bir kuralım var, ancak tek bir karta uygulayabiliyorum garip görünüyor (kirli bir kesmek gibi), garip görünüyor ve sonra yüksek sayılara sahip yeni bir kart seti oluşturmaya karar verdim. yeni sınırlama kuralı onlar için geçerlidir. Şimdi daha basit bir oyun teknisyenim var, daha basit orijinal olanın üzerine inşa edilmiş, bence, daha iyi bir oyun yapmak için onu avantajım haline getirdim.

Şimdi, bu son örnekle ilgili bir şey, önerilen kart oyunu örneğinde, yeni kartlar yeni varlıklarla sonuçlanabilir (maliyet artışı, zaman artışı). Ama bence sadece kodlama yaparken gördüğünüz fırsatların tasarım kararlarınızı iyi bir şekilde etkilemesine iyi bir örnek.

Oynadığımız oyunların çoğunun kodlamadan önce tamamen tasarlandığını düşünmüyorum, eminim zaman çizelgelerine uymak için zor kararlar vermek zorunda kaldılar.

Başka biri bunun için ödeme yaptığında: açıklayın, müzakere edin.