KAM (Bitirme Projesi)

Bağlam

KAM, Türk mitolojisinde geçen izometrik, sıra tabanlı bir roguelite RPG; bitirme projemiz olarak Unity’de geliştirdik. Beş kişi, iki dönem boyunca üzerinde çalıştık. Oba’sının şamanı Göktay’ı oynuyorsunuz; Göktay, kötü ruhların aldığı bir ruhu geri almak için Spirit Realm’e giriyor.

Ekipteki tek geliştirici bendim. Aşağıdaki oynanış sistemlerinin her biri — ve arkalarındaki mimari — bana aitti; bunun yanında oyunun kendi tasarımında da ekiple ortak çalıştım.

Rolüm

Hem tasarım hem de geliştirme tarafında çalıştım ve ana döngüyü destekleyen tüm sistemler benim sorumluluğumdaydı:

• İzometrik kamera ve oyuncu hareketi
• Sandıklar, portallar, kamp ateşleri, toplanabilir eşyalar ve yetenek ağacı sunağı için etkileşim sistemi
• Envanter, hızlı slotlar, eşya toplama ve koleksiyon eşyası mantığı
• Sıra tabanlı savaş, Aksiyon Puanı sistemi ve zamanlamalı vuruş mekaniği
• Düşmanların dolaşması, algılaması, savaş davranışı ve düşman yetenekleri
• Yetenek ağacı ve kalıcı ilerleme
• Oba merkezi ve Spirit Realm run döngüsü; kamp ateşinde kayıt, ölüm ve yeniden doğma akışı
• Sandıklar, bosslar, toplanabilir eşyalar ve kısayollar için kalıcı dünya durumu
• Savaş arayüzü, HUD, tooltip’ler, hasar popup’ları ve savaş kaydı
• Ses yönetimi ve sahne geçişleri

Tasarım Sorusu

Sıra tabanlı savaşı hem taktik açıdan ilgi çekici hem de fiziksel olarak oyuncuyu içine çeken bir yapıda tutarken, bütün sistemi tek bir geliştiricinin iki dönemde geliştirip sürdürebileceği kadar küçük nasıl tutarsınız?

Sıra tabanlı savaşın bilinen bir başarısızlık biçimi var: tıklayarak geçilen bir menüye dönüşmek. Roguelite yapısı bunu daha da kötüleştiriyor, çünkü oyuncu aynı karşılaşmaları run üstüne run tekrar oynuyor. Sistemin hem düşünmeyi ödüllendirmesi hem de her an aktif kalması gerekiyordu — tek bir geliştiricinin bitirebileceği sınırı aşmadan.

Hedefler ve Kısıtlar

Hedefler

• Birbirinden kopuk mekanikler yerine eksiksiz bir döngü: keşfet, savaş, topla, kaydet, kilidi aç, öl, daha güçlü dön
• Bir turun refleks değil, karar olduğu bir savaş
• Çekirdek sistemleri yeniden yazmadan yeni eşya, düşman, yetenek ve etkileşimli nesne eklenebilen bir framework

Kısıtlar

• Tüm oynanış kodu için, iki dönem boyunca tek bir geliştirici
• Sanat, anlatı ve ses çalışmaları benim sistemlerimin hazır olmasına bağlı olan beş kişilik bir ekip
• Bir dilek listesi olarak değil, bitirme projesi olarak teslim edilmesi gereken bir kapsam

Tasarım Kararları

Bu kararların hepsinin altında tek bir ilke yatıyor: hiçbir sistem bir başkasının nasıl çalıştığını bilmek zorunda olmamalı. Oyunun, oyun testi geri bildirimlerini yeniden yazıma gerek kalmadan atlatabilmesini sağlayan da buydu.

Aksiyon Puanları ve bir aksiyon başarısız olduğunda ne olduğu. Aksiyonların bir AP maliyeti var ve arayüz, oyuncunun karşılayamayacağı aksiyonları devre dışı bırakıyor. En çok önem taşıyan karar başarısızlık durumuydu: başarısız bir aksiyon AP harcamamalı ya da turu bitirmemeli. Sistem, herhangi bir şey tüketmeden önce aksiyonun gerçekleşip gerçekleşemeyeceğini kontrol ediyor. Böylece Defend, bir sonraki turda daha güçlü bir hamle için AP biriktirmenin bir yoluna dönüştü — turların birbirini tekrar etmek yerine birbirinden farklılaşmasını sağlayan da bu.

Hasarın sahibi olmayan zamanlamalı vuruşlar. Bir saldırı sırasında yarım saniyeliğine bir rün beliriyor; doğru tuşa basmak hasarı artırıyor. Bu sistemi bilinçli olarak hasar mantığının dışında tuttum — savaş sisteminin yorumladığı bir sonuç (miss, success, perfect) döndürüyor. Girdi zamanlaması, arayüz ve hasar hesaplaması birbirinden ayrılabilir kaldı; daha sonra yetenek ağacı yükseltmelerinin savaş koduna dokunmadan zamanlamalı vuruş sonuçlarını değiştirebilmesini sağlayan da buydu.

Aynı kuralı izleyen üç karar daha:

• Ortak tek bir birim modeli. Oyuncu ve düşmanlar ortak bir CombatUnit üzerinde çalışıyor; tur sırasını ve kazanma/kaybetme çözümlemesini merkezi bir tur yöneticisi yönetiyor — böylece bir savaş sonucu tam olarak bir kez tetikleniyor; tekrarlanan arayüz güncellemeleri ya da yinelenen ses efektleri oluşmuyor.
• Yetenek etkilerini sorgula, asla sabit kodlama. Sistemler, bir bonusun aktif olup olmadığını merkezi bir etki katmanına soruyor. Bir yetenek eklemek, savaş kodunu düzenlemek anlamına gelmiyor.
• Her nesne için tek bir etkileşim akışı. Sandıklar, kamp ateşleri, portallar, toplanabilir eşyalar ve yetenek ağacı sunağı tek bir algılayıcıyı ve tek bir etkileşim istemini paylaşıyor; her nesne yalnızca kullanıldığında ne yaptığını tanımlıyor.

Sonuç, bağımlılıkların tek yönde aktığı katmanlı bir yapı:

Her sistemi tek başına test edilebilir kılan bu ayrımdı — ve aşağıdaki oyun testine yanıt vermenin, savaşı yeniden yazmak yerine sunumu ve ayar değerlerini değiştirmek anlamına gelmesinin nedeni de bu.

Oyun Testi ve Kanıtlar

19 Mayıs 2026’da 24 katılımcıyla bir oyun testi yaptık; tempo, rün mekaniği, yetenek ağacıyla build oluşturma, denge ve görsel-işitsel his hakkında sorular sorduk.

Ölçüt	Puan (5 üzerinden)
Genel keyif	3.66
Rün / zamanlamalı vuruş	3.73 — en yüksek puan
Görsel estetik	3.50
Tekrar oynanabilirlik	3.41
Yetenek ağacı	3.39
Ses tasarımı	3.37
Kontroller	3.33
Arayüz netliği	2.91 — en düşük puan

İki bulgu önceliklerimi değiştirdi.

Zamanlamalı vuruş doğru bir bahisti. Ölçtüğümüz her şeyden daha yüksek puan aldı. Oyuncuların sıra tabanlı bir sistemin içinde aktif bir an istediği varsayımı, testte geçerliliğini korudu.

Arayüz, oyuncuların aslında sevdiği sistemleri baltalıyordu. Katılımcıların yalnızca 58.3%‘ü keşiften savaşa geçişi akıcı buldu; 41.7%‘si bulmadı. Yanıtları tek tek okumak, yetenek ağacının neden vasat bir puan aldığını açıkladı: oyuncular yeteneklerin kendisini sevmediği için değil, puan harcamak için arayüzle boğuştukları için. Bir test katılımcısı rün ve yetenek ağacına tam puan verdi, grafiklere 4, sese 5 verdi ve yine de oyunu dengesiz buldu — çünkü arayüz neden öldüğünü hiçbir zaman açıklamadı. Arayüz ve kontrollere en düşük puanı veren oyuncular, savaş sistemine hiç şans tanımadı.

Verilerin bana gerçekte öğrettiği şey buydu: belirsiz geri bildirim oyuncuya “kafa karıştırıcı” olarak değil, “haksız” olarak yansıyor.

İterasyon

Oyun testi üç parçalı bir eylem planı ortaya çıkardı ve bu planı adım adım uyguladık:

1. Arayüz/UX’in elden geçirilmesi — en yüksek öncelik. Arayüzü kanıtlara göre yeniden tasarladık: savaş durumunu (HP, Aksiyon Puanları, tur sırası) anında okunabilir hale getirdik ve yetenek ağacının düzenini, içinde gezinmek engelleyici değil ödüllendirici hissettirecek şekilde yeniden ele aldık.
2. Keşiften savaşa geçiş. Geçişteki gecikmeyi azaltmak ve kamerayı yumuşatmak; böylece savaşa girmek artık sürükleyiciliği bozmasın.
3. Karşılaşma dengesi. Düşman canını düşürmek ve spirit fragment birikimini daha az cezalandırıcı hale getirmek; böylece bir run, savaştan kaçınmayı değil savaşa girmeyi ödüllendirsin.

Bunların yanı sıra build’i baştan sona yeniden gözden geçirdik ve üstüne yeni sistemler yığmak yerine var olanın kalitesini yükselttik.

Sonuç ve Değerlendirme

Son build eksiksiz bir roguelite döngüsü: bir merkez, bir run, taktiksel sıra tabanlı savaş, kalıcı ilerleme, kalıcı dünya durumu ve bir kayıt/ölüm/yeniden doğma akışı — tek bir geliştirici tarafından, iki dönemlik bir teslim süresi içinde geliştirildi.

Mimari kararlar, ölçebildiğim bir şekilde karşılığını verdi. Zamanlamalı vuruşlar, yetenek etkileri ve etkileşimler modüler tutulduğu için oyun testi geri bildirimine yanıt vermek, savaşı yeniden yazmak yerine sunumu ve ayar değerlerini değiştirmek anlamına geldi. Bana en pahalıya mal olan kararlar, problemi anlamadan önce verdiklerimdi; beni kurtaranlar ise sabit kodlamayı reddedenlerdi.

Farklı yapacağım şey, daha erken test etmek. Çalışan bir savaş sistemimiz, onu 24 kişiye oynatmamızdan çok önce vardı ve bulduğumuz en zarar verici problem — arayüz netliğinin, oyuncuların aslında keyif aldığı sistemleri aşağı çekmesi — beş kişilik bir oyun testinin aylar önce yakalayacağı türden bir problemdi. Sistemleri geliştirmek, zaten nasıl yapılacağını bildiğim kısımdı. Darboğazın mekanikler değil arayüz olduğunu öğrenmek ise yanımda götürdüğüm kısım oldu.