Oyun Geliştirme

Sprung Blast

Beta Geliştirme Aşamasında

Temizlenen çizgilerin, iten, zincirlenen ve bir sonraki hamleyi hazırlayan yaylar fırlattığı bir mobil blok bulmaca — şu an beta aşamasında.

Rol
Tek Geliştirici · Oyun Tasarımı & Geliştirme
Yıl
2026
Motor
Unity · C#
Araçlar
  • Unity 6
  • C#
  • URP 2D
  • Input System
  • NUnit
  • iOS
  • Android
Sprung Blast kapak görseli
  • Tanıdık bir 8×8 blok bulmacanın üzerine yay, itme ve zincir kurallarını tasarladım
  • Unity'den tamamen ayrı tutulan, saf C# ile deterministik bir kural çekirdeği geliştirdim
  • Bir Roguelike modu tasarlayıp geliştirdim — sekiz kat, komboya bağlı perk seçimleri ve bir perk kodeksi
  • İki modu da bot simülasyonlarıyla dengeledim, ardından oyun içi hata bildirme aracı olan bir beta çıkardım
İçindekiler

Bağlam

Sprung Blast, Unity ile geliştirdiğim, iOS ve Android için dikey ekranlı bir mobil bulmaca oyunu. Oyunu tek başıma tasarlıyor ve geliştiriyorum; şu anda kapalı beta aşamasında. Oyun çıkışa doğru ilerlerken kaynak kodu ve asset’ler herkese açık değil; bu yüzden bu sayfa tasarımı ve sistemleri kodun kendisi yerine ekran görüntüleri ve bir yazıyla anlatıyor.

Çıkış noktası herkesin zaten bildiği bir tür: parçaları 8×8’lik bir tahtaya sürükle, dolu satır ve sütunları temizle. Cevaplamak istediğim soru şuydu: tek bir ek kural, oyuncudan yepyeni bir oyun öğrenmesini istemeden bu tanıdık hamleye ikinci bir sonuç kazandırabilir mi?

Tek cümleyle: blokları yerleştir, çizgileri temizle — ve temizlenen her yay sıçrar, iter ve bir sonrakine zincirlenir.

Temel Fikir

Bazı bloklar yaydır. Her biri bir yön ve 1 ile 3 arasında bir mesafe taşır. Bir yayın bulunduğu çizgi temizlendiğinde yay, o yönde o mesafe kadar sıçrar:

  • İtme — yay, yolundakini yok saymak yerine önündeki blok sırasını iter. Böylece bir temizleme yalnızca silme olmaktan çıkar ve tahtayı yeniden düzenlemeye başlar.
  • Zincir — bir yay başka bir yayın üzerine düşerse onu tetikler, o da sırası gelince sıçrar. Tek bir iyi yerleştirme birkaç dalga hâlinde çözülebilir.
  • İki tür yay — sabit yaylar rastgele bir yönle gelir; böylece karar “bu parçayı nereye koyayım ki yayı işe yarasın?” sorusuna dönüşür. Mor yaylar daha nadirdir ve yönlerini oyuncu belirler. Bunlar her tur elde olan serbest bir seçim değil, saklanması gereken kıt bir kaynaktır.

Mesafe hem renkle (sarı, turuncu, kırmızı) hem de her yayın üzerindeki bir sayıyla gösterilir; böylece kural hiçbir zaman yalnızca renge dayanmaz.

Bir kombo sistemi gerilimi canlı tutar: üç parçalık her tepside en az bir kez temizleme yapmak komboyu sürdürür, dalga zincirleri ise onu daha da ileri taşır.

İki Mod

  • Classic — sonu olmayan bir yüksek skor run’ı. Run her hamlede kaydedilir; böylece oyun herhangi bir anda kapatılıp tam kalınan yerden devam ettirilebilir.
  • Roguelike — sekiz kattan oluşan bir run. Her katta beş tepsi içinde ulaşılması gereken bir skor hedefi vardır; kombo barını doldurmak, kuralları esneten üç perk arasından bir seçim sunar: daha uzun sıçramalar, daha fazla mor yay, kombo kalkanları, zincir bonusları. Zaten sahip olduğun bir perki almak onun seviyesini yükseltir. Bulduğun perkler oyun içi bir kodekse kaydedilir. Run’lar arasında kalıcı bir güç ilerlemesi yok — yalnızca çeşitlilik var.

Mimari

Kurallar Unity bağımlılığı olmayan saf bir C# çekirdeğinde yaşıyor. Oyuncu bir parçayı bıraktığında çekirdek turun tamamını baştan çözüyor — her temizlemeyi, sıçramayı, itmeyi ve zinciri — ve sıralı bir olay listesi döndürüyor. Sunum katmanı yalnızca bu listeyi oynatıyor.

Bu ayrım, en başından istediğim üç şeyi sağlıyor:

  1. Dürüst bir önizleme. Sürükleme önizlemesi, gerçek hamleyle birebir aynı simülasyonu çağırıyor; böylece oyuncunun bırakmadan önce gördüğü şey, gerçekten olacak olanın ta kendisi.
  2. Determinizm. Aynı seed ve aynı hamleler her zaman aynı tahtayı ve aynı skoru üretiyor; bu da hataları yeniden üretilebilir, kayıtları ise kendiliğinden geçerli kılıyor.
  3. Test edilebilirlik. Çekirdek EditMode testleriyle kapsanıyor: uzun, rastgele soak testleri boyunca kontrol edilen kural değişmezleri, kabul testleri ve orijinal prototipin kaydedilmiş çıktısına karşı parite testleri.

Ayar değerleri — yay sayıları, parça ağırlıkları, kat hedefleri, perk güçleri — kodda değil veri asset’lerinde duruyor; böylece dengeleme hiçbir zaman kurallara dokunmayı gerektirmiyor.

Tasarım Süreci

Oyun hızlı bir web prototipi olarak başladı. Kurallar orada bulundu, oynandı ve ölçüldü; sayıları da tahminden değil botlardan geldi. İki örnek:

  • Yayın ilk versiyonu yalnızca bir bloğu bir yere bırakıyordu. İtmenin eklenmesi boşa giden sıçramaları — hiçbir şey yapmayan sıçramaları — kabaca %46’dan %24’e düşürdü.
  • 37 şekillik parça kataloğunun tamamını eşit ağırlıkla kullanmak run’ları fazlasıyla kısalttı; bu yüzden parça havuzu boyut gruplarına göre ağırlıklandırıldı ve tipik bir oturum sekiz dakika civarına oturana kadar ayarlandı.

Unity sürümü bu kuralların sadık bir aktarımıydı; ezberden yeniden yazılmak yerine prototipin çıktısına karşı doğrulandı. Roguelike modu için, kat hedeflerini belirlemek ve baskın olan ya da hiçbir işe yaramayan perkleri bulmak amacıyla birkaç bot stratejisi içeren bir simülasyon düzeneği kurdum — betanın şu an gerçek oyuncularla test ettiği soru da tam olarak bu.

Şu Anki Durum

  • iPhone’da beta; Android build’leri aynı projeden çalışıyor
  • İki mod da öğreticiler, kayıt sistemi, dokunsal geri bildirim, ses ve Türkçe/İngilizce yerelleştirmeyle uçtan uca oynanabilir
  • Oyun içindeki Report a problem formu; hata, denge ve fikir bildirimlerini — ekran görüntüsü, son loglar ve build numarasıyla birlikte — doğrudan bana gönderiyor
  • Sanat ve ses hâlâ kısmen geçici, Roguelike perk kataloğu da henüz kısmen oyunda: MVP çekirdek bir perk setiyle çıkıyor; tasarlanan kataloğun geri kalanı, boss katları ve kat modifikatörleri betadan sonrası için planlanıyor

Oyun hâlâ aktif olarak geliştiriliyor. Bundan sonra neyin değişeceği beta bildirimlerinin ne söylediğine bağlı.