Herhangi bir oyun geliştirme projesine başlarken en felç edici duygulardan biri, ilk oyun tasarımınızı bitirdikten hemen sonra hissettiğiniz duygudur; bu ister bir oyun reçeli için peçetelere not edilmiş birkaç fikir olsun, ister geleneksel 10 sayfalık tasarım olsun. belge.
Çünkü oyununuzun bir ROGUELITE-RTS-MMORPG olacağına karar verdikten sonra onu gerçekten inşa etmeniz gerekiyor, anladınız mı?
Diyelim ki oluşturacağınız ilk şeyin RTS kısmı olduğuna karar verdiniz. Böylece kullanıcı hikayesini, görevleri veya kendinizi organize etmek için kullandığınız iş birimini not edersiniz.
O zaman o listedeki ilk öğenin “Kaydırılabilir Haritayı Uygula” olduğunu varsayalım.
Ve ah! Hiçbir zaman kaydırılabilir bir harita uygulamadınız. Ama zahmet etmeyin, Google yardıma koşuyor, değil mi?
Peki internette bulduğunuz çözüm tam olarak ihtiyacınız olanı yapmazsa ne olur? Yoksa bulduğunuz çözüm 15 yaşında mı? Veya altında bir çözümün ne kadar kötü olduğunu söyleyen bir sürü yorum var ama daha iyi bir çözüm belirten tek bir tane bile yok[^0]?
Dolayısıyla, oluşturmaya çalıştığınız her ne ise onun için bir kod referansı bulamazsınız. Bir oyun geliştiricisinin yapması gerekenler nelerdir?
Cevap Kaos Goblin moduna girmektir.
Goblinlere aşina olmayanlarınız için, onlar çeşitli fantastik eserlerde sıklıkla öne çıkan bir ırktır ve tipik olarak daha ciddi ork veya hobgoblinin daha küçük kuzeni olarak tasvir edilir. Diğer bazı özelliklerde, çok özel bir şekilde mekanik açıdan yetkin olarak tasvir ediliyorlar. Ve bu yol güvenilmezdir. Bu, goblinlerin bazen işe yaradığı anlamına geliyor; iyi tasarlanmış veya yapılmış oldukları için değil, daha çok yaratıcılık ve inatçılık nedeniyle.
Kaos Goblin'in oyun geliştirme yaklaşımının özü budur. Şimdi, seni burada biraz kaybetmeye başladığıma eminim, bu yüzden geri dönüp Kaos Goblin'in özünü özetleyeyim:
Önemli olan kullanıcının ne yaşadığıdır. Nasıl çalıştığı kimseyi ilgilendirmez.
Bu noktayı daha iyi açıklamak için size Fallout 3'ün Presidential Metro Head'inden bahsedeyim (hikayenin tamamını buradan okuyabilirsiniz). Oyunun ana fikri, oyuncunun bir metronun içinde durduğunu düşündüğü bir sahnede, oyuncunun başlığının aslında bir metro arabası modeliyle değiştirilmiş olması ve oyuncunun kendi modelinin bir metro arabası üzerinde hareket etmesidir. önceden belirlenmiş parça.
Bazı oyuncular bunu okuyabilir ve geliştiricilerin tembel olduğunu düşünebilir. Ancak gerçek şu ki geliştiriciler bu tür şeyleri her zaman yapıyor.
Ve aşağıdaki gibi Kaos Goblin modunun ilkelerini oluşturan da tam olarak bu tür uygulamalardır.
Diyelim ki oyununuzun bir bölümünde oyuncu bir kale kulesinin içinde duruyor ve dışarıda uçan bir ejderhaya ok atıyor. Ejderha ara sıra yaklaşır ve oyuncuyu ısırmaya çalışmak için başını pencereden içeri iter.
Şimdi, oyuncuya göre ejderha aslında orada uçuyor. Ancak oyun geliştiricileri olarak biz, bu yanılsamayı ortadan kaldırmak ve durumu optimize etmek için birkaç numara kullanabilirdik.
Yapılabilecek bazı şeyler şunlardır:
Ejderhanın oyuncudan ne kadar uzakta olduğuna bağlı olarak farklı modeller kullanın. Oyuncu, ejderhanın ayrıntılarını yalnızca yakındayken görebilir; o halde neden ejderhanın 3 boyutlu modelini daha az ayrıntıya sahip ama aynı zamanda hafızada daha az yer kaplayacak bir şeyle değiştirmeyelim?
Oyuncu ona bakmadığında ejderhayı kapatın. Oyuncunun nereye baktığını takip ederek, işlemeden tasarruf etmek için 3D modelleri seçici olarak açıp kapatabiliriz.
Oyuncunun tamamlanmamış işi görmesini engelleyin. Diyelim ki her ne sebeple olursa olsun kulenin dışındaki çevreye yönelik sanat yarım kaldı. Yani eğer oyuncu pencerenin kenarına adım atarsa hiçbir şey görmeyecek. Buna yardımcı olmak için oyun tasarımcıları pencerenin çıkıntısının anında ölüm noktası haline gelmesine karar verdi. Yani oyuncu çıkıntının üzerinde durduğunda, 3 saniyelik bir ejderha kükremesi sesi duyulacak ve oyuncunun ekranı kararmaya başlayacak. 3 saniyelik ses bittiğinde, oyuncuyu yiyen ejderhanın hızlı bir animasyonunu oynatıyoruz (belki de elimizdeki animasyonu yeniden kullanarak). Oyuncu açısından çıkıntı sadece ejderhanın onları alabileceği bir yerdir; bitmemiş işi görmelerini engellemek için yapıldığını bilmelerine gerek yok.
Belki de ejderha kafasını pencereden dışarı çıkardığında tam ejderha modelini daha küçük ama daha detaylı bir kafa modeliyle değiştiriyoruz. Bu, oyuncuya daha iyi bir deneyim sunmamıza izin verirken, kullanmadığımız bir modelin belleğini boşaltmamıza olanak tanır.
Uzun süredir oyun endüstrisindeyseniz, muhtemelen yukarıdakilerin standart uygulamalar olduğunu biliyorsunuzdur, ancak bir zamanlar bu tekniklerin akıllıca hileli ve oldukça yenilikçi olduğu düşünülüyordu.
Artık oyuncularınızı, gördüklerinin çok daha fazlası olduğunu düşündürecek yeni yollar bulmak size kalmış.
Pek çok oyun geliştiricisi, gelecekteki olası tüm senaryoları kapsayan çözümler bulmaya çalıştıkları için takılıp kalıyor. Bu tutum, doğru koşullar altında değerli olabilir, ancak Kaos Goblin modundayken amaç, bir şeyin mümkün olduğu kadar hızlı çalışmasını sağlamaktır.
Buna bir ek:
Yukarıdaki noktaya benzer şekilde, birçok geliştirici, bir özelliği uygulamaya çalışırken çok erken optimizasyon yapmaya çalıştıkları için donakalır.
Optimizasyon, projenin geliştiricilerin kontrolü dışındaki makinelerde çalıştırılması gerekinceye kadar bırakılmalıdır[^1].
Bu, birçok yeni başlayan oyun geliştiricisinin karşılaştığı başka bir engeldir. Bir özelliğin uygulanmasını erteleyecekler, böylece sadece bir kursa daha katılabilecekler, bir çevrimiçi eğitime daha katılabilecekler, bir video daha izleyebilecekler ve ardından oyunlarını uygulamaya hazır olacaklar.
Bu konuda özellikle suçluyum ve bunun ne kadar sinsi olabileceğini biliyorum.
Daha somut bir örnek vermek gerekirse, sıfırdan bir Pong oyunu programlamakla görevlendirildiğinizi varsayalım.
Ne bildiğinize veya bilmediğinize bağlı olarak bunun için izleyebileceğiniz farklı yaklaşımlar olabilir:
Unity'nin Fizik sistemine aşina iseniz, bu nispeten basit bir çabadır. Sadece birkaç katı cisim ve çarpıştırıcı kullanabilir, kuvvet ve hız uygulayabilir, topun zıplaması için bir fizik malzemesi kullanabilirsiniz, hepsi bu. Bir barebone Pong klonu.
Ancak diyelim ki Unity'nin çarpışma sistemine aşina değilsiniz, yalnızca Unity'nin dönüşüm bileşenlerini nasıl kullanacağınızı biliyorsunuz, dolayısıyla elde edebileceğiniz tek şey bir nesnenin konumu ve boyutudur.
Ancak! Bu, Pong'u uygulamak için yeterlidir; topun konumunu ve boyutunu takip eden ve çarpışma olup olmadığını kontrol etmek için bunu raketin konumu ve boyutuyla karşılaştıran bir komut dosyası yazabilirsiniz.
Veya belki de Unity'yi bilmiyorsunuz bile, tek bildiğiniz C++ ve konsola nasıl yazdırılacağıdır.
Ama bu da yeterli! Topu, raketleri ve oyun alanını temsil edecek sembollerin satırlarını ve sütunlarını yazdırmak için terminal hilesini kullanabilirsiniz. Bu, oyun döngüsü kavramıyla birlikte girdilere yanıt veren yenileyici bir kullanıcı arayüzü programlamak için yeterlidir.
Veya Bilgisayar Bilimleri geçmişinden bile gelmiyorsunuz veya C++ dersi almadınız ve yalnızca Javascript'i mi biliyorsunuz?
Sorun değil! Ana dili olarak JS'yi kullanan ve hem render hem de fizik bileşenleriyle birlikte gelen Phaser'ı kullanabilirsiniz.
Program bile yapamıyor musunuz? Kesinlikle sorun yok.
Bununla nereye varacağımı anladın, değil mi?
Çoğu oyun geliştiricisinin genellikle bir yerlerde bir veya iki (veya 10.000) terk edilmiş projesi vardır. Bunları boşa harcamanın anlamı yok. İçinde duraklatma Sistemi gibi bir kod varsa, onu yeniden kullanın. Aynı şeyi tekrar yazmanın anlamı yok. Nasıl yazacağınızı tam olarak hatırlasanız bile kopyalayın; Eğer uyum sağlamak zorsa, bir dahaki sefere daha kolay olması için tekrar tekrarlayın.
Belki yeniden kullanabileceğiniz birkaç kod parçası içeren bir atölye projeniz[^2] bile vardır.
Bir diyalog sistemine mi ihtiyacınız var? Açık kaynaklı bir tane bulun ve onu yeniden kullanın. Tüm ihtiyaçlarınızı karşılıyor mu? HAYIR? Yüzde 50'nin üzerinde mi karşılanıyor? Evet? O zaman sıfırdan yeni bir tane oluşturmak yerine bunu kullanmaya değer.
Envanter sistemi? Itch.io'da açık kaynaklı bir oyun bulun ve onların sistemini benimseyin.
Birinci şahıs kameraya mı ihtiyacınız var? Bunu gerçekleştirmek için önceden oluşturulmuş bir öğeden yararlanın[^3].
Dışarıda pek çok harika oyun geliştiricisi var, şüphesiz sizden ya da benden daha yetkin.
Özel bir nedeniniz olmadığı sürece her şey önceden oluşturulmuş bir sistemi kullanmaya aday olarak değerlendirilmelidir. Ancak, aşağıdakiler gibi mantıklı istisnalar mevcuttur: Yalnızca kopyalayıp yapıştırdığınız kodu oyununuzun omurgası olarak kullanmayın (en azından onu anladığınızdan, temizlediğinizden ve üzerinde yorum yaptığınızdan emin olun) ve bir kod kullanmaktan kaçının. Yazarı muhtemelen tropik bir yerde uzanıp paparazzilerin olmadığı bir cennette Elvis, Tupac ve Marilyn Monroe ile Mai Tais'i yudumlarken, on yıllık bir modül.
Bir özelliğin uygulanması konusunda emin değilseniz, istediğiniz şeye benzer bir şey yapan bir oyun bulun ve onu taklit edin.
"Kopyalama" derken sanat tarzı, hikaye veya karakterlerden ziyade kontrol kullanımı, kamera görüntüleri ve mekanikler gibi tasarım unsurlarını kastediyorum.
Örneğin, artık unutulmuş varsayımsal ROGUELIKE-RTS-MMORPG'mizde kaydırma ne kadar hızlı olmalı?
Tahmin etmek yerine başka bir RTS'nin bunu nasıl başardığını görebilirsiniz. Age Of Empires II'yi (tarihsel olarak önemli bir RTS) gözlemlediğinizi ve bunun kullanıcıların imleç hareketlerinin hızını kontrol etmesine olanak tanıdığını keşfettiğinizi varsayalım. Hatta oyununuzu AoEII ile yan yana yerleştirebilir ve imlecinizi eşdeğer hissedilene kadar ayarlayabilirsiniz. Ne kadar çok geliştiricinin hedeflerine ulaşmak için bunun gibi basit, düşük teknolojili çözümlere güvendiğini görünce şaşıracaksınız.
Peki Kaos Goblin maskaralıklarınızı tamamladıktan sonra ne yapmalısınız? O halde biraz nefes alın, kendinize bir kahve hazırlayın ve kodunuza daha sonra dönün.
Kodunuzu dinlenmeye bıraktıktan sonra (hava çok kuru ise nemli bir havlu altında), biraz çeki düzen vermeli ve paylaşmalısınız. Evet! İdeal olarak kıdemli bir geliştiriciyle, bir meslektaşınızla, bir öğrenci arkadaşınızla veya en kötü durumda çevrimiçi bir toplulukla paylaşın[^4].
Neden paylaşıyorsun? Çünkü Kaos Goblini olmak, dayanıklı veya ideal bir şey yaratmakla ilgili değildir; ÇALIŞAN bir şey inşa etmekle ilgilidir. Mükemmel çalışması veya güzel görünmesi gerekmiyor, sadece ÇALIŞMASI gerekiyor. Bu tür bir geliştirme sonuç üretir ancak sonuçlar nadiren hemen üretime hazır olur. Bu nedenle geri bildirim sağlamak için birine danışmak kritik öneme sahiptir.
Projenizin aşamasına bağlı olarak bu kişinin yorumlarını hemen uygulamaya vaktiniz olmayabilir. Durum buysa, en azından bu yorumları kodda[^5] belgelemelisiniz.
Ve bu kadar! Artık dünya çapındaki profesyonel oyun geliştiricilerinin sorunları çözmek için kullandığı 1 numaralı tekniğe sahipsiniz.
İkinci bir kahve içmenin vaktinin geldiğini düşünüyorum, öyle değil mi?
[^0] - Bu şaşırtıcı derecede yaygın bir olgudur ve "Denver Hikayesi" olarak adlandırılmıştır. Daha fazla bilgi için aşağıdaki bilimsel makaleye bakın.
[^1] - Bu biraz genellemedir ve çoğu genelleme gibi, projenizin gereksinimlerinin kapsamlı bir analizi kadar yararlı olmayabilir. Ancak optimizasyonu gerçekten ihtiyaç duyulana kadar ertelemek iyi bir kuraldır. Bugünlerde video oyunlarını optimize etmek eskisinden çok daha az göz korkutucu. Unity gibi bazı oyun motoru şirketleri size ücretsiz danışmanlık hizmeti sunmayı bile teklif edebilir. Sonuçta oyununuzu başarılı bir şekilde başlatmanız onların yararınadır.
[^2] - Atölye, Unity anlayışımı arttırmak için kullandığım katalardan veya uygulamalardan biridir. Bu konu ve diğer teknikler hakkında daha fazla bilgiyi buradan edinebilirsiniz.
[^3] - Bu makalede diğer yararlı araçların yanı sıra gerçekten iyi bir FPS kontrol cihazı paketi bulabilirsiniz.
[^4] - Bu, çevrimiçi olarak alacağınız yorumların yaklaşık %95'inin anlamsız, eksik, güncelliğini yitirmiş olabileceği veya her ne olursa olsun yazarın son derece kişisel inançlarını yansıtabileceği konusunda bir uyarı içermektedir. Bu nedenle, bu tür geri bildirimlere her zaman bir dereceye kadar şüpheyle yaklaşın. Yararlı yorumlar bulmaya çalışın, gerisini göz ardı edin veya ortadan kaldırın ve kodunuzu paylaşabileceğiniz birini bulmak için gerçek bir çaba gösterin.
[^5] - Farklı ekipler, kod belgelerini nerede muhafaza edeceklerine ilişkin farklı normları uygular ve siz de buna uymalısınız. Ancak genel olarak kod belgelerinin kodun yanında bulunmasını savunuyorum. Bu mümkün değilse, seçtiğiniz kod sürüm oluşturma sisteminde git alt modülünü veya eşdeğerini kullanmayı düşünün. Dokümantasyon ana depoda bulunamıyorsa, en azından git alt modülünde bulunmalıdır.
Burada da yayınlandı.