Her oyun alanı yukarıdan aşağıya kamera göz önüne alınarak tasarlanmıştır. Kullanıcı arayüzünün boyutu, her şeyin çerçeve içine sığdırılması ve NPC’nin çok küçük görünmemesi gerekliliğiyle birlikte, her oyun alanının maksimum boyutunu sınırlıyordu. Bu, oyun alanlarının yaklaşık 4 kareye 6 kare boyutunda olması gerektiği anlamına geliyordu. Yukarıdan aşağıya kamera, ekrandaki boyutu küçük olan NPC’nin yönünü görmeyi zorlaştırdığından, NPC hareket etmeyi durdurduğunda yanında bir ok görseli belirir.
Oyun alanlarını tasarlarken unutulmaması gereken üç şey vardır:
Oyun alanını kompakt tut
Yeni unsurları tek tek ekle
Oyuncuların düşünmesini sağla
4x6 boyutundaki alan sınırlı olmasına rağmen, bu kısıtlamalar içinde çalışmak, alanların hiçbir zaman kontrolden çıkmamasını sağlıyordu ve oyuncular, oyun boyunca hızlı bir ilerleme hissi elde ediyordu. Oyuncular oyun alanına bakıp hızlıca bir çözüm bulabilmeliydi ancak komut girdisinin niteliği göz önüne alındığında, yürüt düğmesine basmadan önce adımları üzerine düşünmeleri de gerekiyordu. Bu beş oyun alanı, basitten başlamak ve nihai test olarak 5. oyun alanını tamamlayana kadar her oyun alanı için yeni bir konsept sunmak üzere tasarlandı.
Bu oyun alanı tamamen doğrusaldır ve oyuncunun “ileri” komutuyla yalnızca bir yönde gitmesini ister. Bu, oyuncuya son derece basit bir hedefin yanı sıra farklı komutlarla oynama ve ne yaptıklarını görme zamanı da verir. | |
Bu oyun alanında oyuncuya bölümü geçmek için her iki tür dönüş komutunu da kullanmasını gerektiren dönüşler tanıtılır. | |
Bu oyun alanı, oyuna bariyer biçiminde engeller ekler. Oyun alanı bir döngü biçiminde olduğu halde, bariyerlerin yerleşimi nedeniyle oyuncunun izleyebileceği yol doğrusaldır. Bu, oyuncuyu engel tetikleyiciyle etkileşime girmeye zorlayarak ona engelleri ve bunların nasıl geçileceğini öğretir. Bu oyun alanı aynı zamanda çoklu yürütme komutları gerektirir çünkü iletmesi gereken komutların sayısı, komut sırasının maksimum komut sınırından daha fazladır. | |
Bu oyun alanı, kompozisyona birden fazla bariyer ekleyerek oyuncunun her iki engel tetikleyicisine de ulaşmak için çok sayıda dönüş içeren bir yol izlemesini gerektirir. NPC’nin yol sorunları nedeniyle turuncu engel tetikleyicinin bir köşeye taşınması gerekti. | |
Bu oyun alanı, birden fazla tetikleyici içermesi ve uzun, dolambaçlı bir yol gerektirmesi bakımından büyük oranda 4. oyun alanına benzerdir. NPC’nin navigasyonuyla ilgili sorunlar bu oyun alanının tasarımını gerçekten sınırlıyordu, çünkü NPC diğer tarafa geçmek için sıklıkla oyun alanı ızgarasından ayrılacak şekilde duvarların etrafından dolaşmaya çalışacaktı. Bu tasarımın birkaç kez yeniden düzenlenmesi gerekmişti ve bu, mevcut NPC gidilebilir API’sinin bazı sınırlamalarını ortaya çıkardı. |
Bu örnekteki oyun alanları nispeten basit olduğu halde tasarım, farklı çeşitlemelere önemli oranda olanak sağlıyor. Tuzaklar ve ışınlayıcılar içeren oyun alanları, farklı kameralar içeren oyun alanları, birden fazla bölümlü oyun alanları vb. Bunların her biri, bu şablonu kendi kendine farklı yönlerde geliştirmene izin verir. Basit bir konsepti kullanarak sınırlamalar içinde çalışmaya kendini zorlamak, çoğu zaman denemeyi hiç düşünmediğin yeni fikirler üretmeni sağlayabilir.
Sınırlamalar Çerçevesinde Tasarlama
Bu şablondaki hareket kodunun büyük bölümü, Yapay Zekâ Navigasyonunun geçerli sınırlamalarına göre tasarlanmıştır. NPC’ler halihazırda doğrudan kontrol edilemez; bunun yerine navigatable arayüzü kullanılarak navigasyon hedefleri vermek gerekir. Herhangi bir konum bir navigasyon hedefi olarak belirlenebilmekle birlikte, sonuçta oraya nasıl gidileceğine ilişkin karar NPC’ye bağlıdır.
Yapay Zekâ, dünyada hareket ederken yol kararları vermesine ve nereye gidip gidemeyeceğini belirlemesine yardımcı olan Navigasyon Örgüsü’nü kullanır. Bazen bu kararlar, bir yapay zekânın engelin üzerinden atlamak yerine bir duvarı parçalamaya çalışması gibi, beklediğin oynanış deneyimine uygun olmayabilir.
Bu şablonda NPC her seferinde bir kare hareket ettiğinden, onu oyun alanıyla uyumlu şekilde tutmak çok önemliydi. Çoğu durumda bu bir soruna yol açmazken, NPC’ler her zaman hedeflerine giden en kısa yolu kullanmaya çalıştıklarından, ızgaraya bağlı kalmak yerine genellikle duvarların veya bariyer cihazlarının etrafından dolaşmaya çalışırlar. Ayrıca, bariyer cihazları duvarlardan farklı navigasyon örgüsü özelliklerine sahiptir; NPC’ler sürekli olarak bariyer cihazlarına doğru yürür ve durmayıp bunların içinden geçmeye çalışır. Bu, her bölümde navigasyon örgüsünü bloklayıp NPC’nin geçeceği “koridorlar” oluşturan çok sayıda Yapay Zekâ Gezinmesi Değişiklik Cihazının yerleştirilmesini gerektirdi. Yapay zekâ bu cihazlarla oluşturulan alanlara kesinlikle gidemediği için bu, NPC’nin ızgaraya bağlı kalmasını sağladı ve bariyerlerin içinden veya duvarların etrafından koşmaya çalışmak gibi beklenmedik navigasyon kararları vermesini engelledi.
Dönüşler de bir sorun oluşturuyordu. Şu anda, doğrudan sağlarında veya sollarında bir navigasyon hedefi verildiğinde, NPC’ler hedefle hizalanmak için hafif eğri bir yol izler ve ardından hedefe doğru hareket eder. Bu sorunlu bir durumdu çünkü NPC’nin sık sık duvarlara çarpması veya dar köşelerden geçerken zorluk yaşaması ve birkaç tur sonra oyun alanıyla hizalanmasının bozulması anlamına geliyordu. Zıplama veya tırmanma yeteneği gibi birçok hareket yeteneğinin de yapay zekâdan kaldırılması gerekiyordu çünkü bu yetenekler onun sınırların dışına çıkmasına olanak tanıyacaktı.
Sonraki Adım
Karakterin ilerleyeceği beş bölümü oluşturduk. Bir sonraki adımda genel komut verilerini ve karakter tarafından kullanılan belirli komutları tanımlayacaksın.