Steam Next Fest yaklaşınca herkes mağaza görseline, fragmana, sosyal medya postuna abanıyor. Normal. Ama bence asıl iş biraz daha aşağıda: demo gerçekten ilk kez oynayan birine kendini anlatıyor mu, build temiz mi, ölçüm hazır mı, oyuncu düştüğünde nerede düştüğünü görebiliyor muyuz?
Ekim 2026 Steam Next Fest 19–26 Ekim 2026 arasında. Valve etkinliği, demosu olan çıkmamış oyunların erken geri bildirim alması ve çıkış öncesi kitle oluşturması için konumluyor. Güzel fırsat. Fakat etkinliğe girmek tek başına pazarlama stratejisi değil. Biraz acı ama böyle.
Kısa cevap: demoyu küçük bir launch gibi hazırlayın
Ben olsam Next Fest demosunu “oyunun küçük hali” diye değil, “oyuncuya oyunun vaadini kanıtlayan kısa ürün” diye ele alırım. Feature freeze olur, temiz kurulum test edilir, ilk 10 dakika birkaç kez izlenir, analytics event’leri canlıda doğrulanır. Sonra mağaza sayfası.
Önce uygunluk ve kayıt durumunu kontrol edin
Valve’ın Ekim 2026 kurallarına göre oyunun henüz çıkmamış olması, mağaza sayfasının herkese açık olması ve etkinlik başladığında herkese açık oynanabilir bir demo bulunması gerekiyor. Ayrıca bir oyun yalnızca bir Next Fest’e katılabiliyor. O yüzden “bu festivale girelim, sonra bir daha gireriz” diye plan yapmayın.
Takvimi platform deadline’ına göre değil, kendi deadline’ınıza göre yapın
Resmî takvimde 8 Ekim basın ön izlemesi, 19 Ekim etkinlik başlangıcı ve 26 Ekim bitiş tarihi var. Build ve store review için daha erken teslim noktaları da bulunuyor. Yayın planını yaparken resmî Steamworks sayfasını tekrar kontrol edin; tarih/koşullar değişebilir.
Bizim yaklaşımımız basit: Steam’in son günü bizim son günümüz olmasın. Mümkünse birkaç günlük tampon bırak. Son akşam build göndermek kahramanlık gibi geliyor ama değil.
Demo ilk 10 dakikada ne göstermeli?
- Oyuncunun temel olarak ne yaptığını.
- Oyunun diğerlerinden ayrıldığı bir sistemi.
- Kontrolleri ve önemli UI durumlarını.
- Bir küçük başarı/payoff anını.
- “Devamında daha fazlası var” hissini, ama oyunu yarıda kesilmiş gibi bırakmadan.
Uzun lore girişleri, üç ekran tutorial metni, daha sonra işe yarayacak sistemler… bunları demo için tekrar düşünün. Oyuncu size sabır borçlu değil.
Steam mağaza sayfası kontrol listesi
| Alan | Kontrol |
|---|---|
| Capsule | Küçük boyutta tür/fantazi okunuyor mu? |
| Kısa açıklama | İlk cümle oyuncunun ne yaptığını söylüyor mu? |
| Fragman | Gameplay erken geliyor mu? |
| Ekran görüntüleri | Farklı sistemleri gösteriyor mu, yoksa aynı sahnenin varyasyonları mı? |
| Etiketler | Gerçek oynanışı temsil ediyor mu? |
| Demo | Oyuncu demoyu kolay fark ediyor mu? |
Demo QA listesi
Ana oyun çalışıyor diye demo çalışıyor varsaymayın. Demo ayrı App ID, ayrı release checklist ve farklı progression sınırları nedeniyle kendi başına test edilmesi gereken bir ürün gibi.
- Temiz cihaz/hesaptan kurulum.
- İlk açılış ve default grafik ayarları.
- Klavye/controller geçişleri.
- Save oluşturma ve tekrar yükleme.
- Demo sonu ve full game CTA.
- Linkler ve sosyal bağlantılar.
- Crash/error reporting.
- Alt+F4 / quit / tekrar açma.
- Düşük performanslı cihazda minimum kabul edilebilir deneyim.
Next Fest sırasında ne ölçeceğiz?
Etkinlik başladıktan sonra “hangi veriye bakalım?” demek geç. Önceden bir sheet hazırlayın. Demo oyuncu sayısı, ilk session completion, ana drop-off noktaları, session süresi, crash oranı, wishlist değişimi, gelen trafiğin kaynağı ve feedback kategorileri. En az bunlar.
Tek bir “iyi wishlist oranı” sayısına takılmayın. Steam de wishlist’ten satışları kusursuz tahmin eden bir formül olmadığını söylüyor. Kendi kanalınızı kendi baseline’ınızla karşılaştırmak daha işe yarar.
Feedback’i olduğu gibi backlog’a atmayın
“Combat yavaş” diyen de çıkacak, “combat çok hızlı” diyen de. Üç yorumla sistem değiştirmeyin. Feedback’i bug, onboarding, UX, balance, performance, expectation mismatch ve feature request diye ayırın. Sonra davranış verisiyle yan yana koyun.
Bir noktada 100 oyuncunun yarısı düşüyor ve aynı yerde 15 kişi “ne yapacağımı anlamadım” diyorsa, işte orada güçlü sinyal var.
Son 48 saat checklist
- Mağaza sayfasını gizli sekmede/logged-out kontrol et.
- Demo branch ve depot ayarlarını doğrula.
- Fresh install yap.
- Analytics event’lerinin prod ortamında geldiğini kontrol et.
- Crash dashboard’un sahibi belli olsun.
- Fragman, screenshot ve kısa açıklamayı dondur.
- Destek/Discord cevap şablonlarını hazırla.
- Blocker fix dışında riskli merge yapma.
- Go/no-go kararını kimin vereceği belli olsun.
- Etkinlik sonrası değerlendirme toplantısını şimdiden takvime koy.
Sonuç
Next Fest’te hedef sadece görünmek değil. Oyuncu oyunu anladı mı, demo doğru kitleyi çekti mi, nerede kaybettik, hangi mesaj çalıştı? Bunların cevabını almak. Bir hafta sonra elinizde sadece “kaç wishlist geldi” sayısı varsa fırsatın yarısını kaçırmış olursunuz.
Resmî koşul ve tarihleri son kez Valve’ın sayfasından kontrol edin: Steam Next Fest: October 2026 — Steamworks.
Bunu gerçek projede nasıl uygularız?
Ben bu konuyu doğrudan bir sonraki build’e bağlamayı tercih ederim. steam next fest 2026 rehberi için ayrı bir doküman yazıp unutmak yerine, tek bir feature veya oyuncu akışı seç. Önce mevcut davranışı kaydet. Sonra değişiklik yap. Sonra aynı ölçümü tekrar al. Bu kadar. Küçük deney daha az havalı görünüyor ama hangi kararın işe yaradığını gerçekten anlatıyor.
Örneğin önce bir “başlangıç durumu” kaydı açabiliriz: hangi build, hangi oyuncu grubu, hangi sistem ayarı, beklenen sonuç ne? Ardından kararın sahibini ve geri dönüş koşulunu yaz. Bir değişiklik kötü giderse “ne zaman geri alacağız?” sorusunun cevabı olay anında tartışılmamalı. Önceden belli olsun.
Mini karar günlüğü
| Alan | Ne yazacağız? |
|---|---|
| Problem | Oyuncu veya üretim tarafında ne bozuk? |
| Hipotez | Hangi değişiklik neden düzeltecek? |
| Risk | En pahalı yan etki ne? |
| Sinyal | İşe yaradığını hangi veri gösterecek? |
| Rollback | Hangi durumda eski davranışa döneceğiz? |
Yayınladıktan veya uyguladıktan sonra neye bakmalı?
İlk gün çok gürültülü olabilir. Birkaç yüksek sesli yorumla komple yön değiştirmek yerine davranış sinyalini, hata oranını ve qualitative feedback’i birlikte oku. Aynı sorun üç farklı kanalda görünüyorsa daha güçlü sinyal. Sadece tek yorum varsa backlog’a yaz, hemen mimariyi sökme.
Bir de “başarı”yı sadece pozitif metrik diye düşünmemek lazım. Bazen amaç hata oranını düşürmek, support yükünü azaltmak veya ekipte aynı işin iki kere yapılmasını önlemek. Steam Next Fest Ekim 2026 Rehberi: Demo, Mağaza Sayfası ve Görünürlük Checklist için doğru sonuç, konuya göre değişir. O yüzden başta hangi davranışı koruduğumuzu yazmıştık zaten.
Benim özellikle kaçınacağım şeyler
- Tek bir benchmark’ı evrensel doğru kabul etmek.
- Ölçmeden önce büyük refactor yapmak.
- Rollback yolu olmadan canlı değişiklik açmak.
- “Best practice böyle” deyip ürünün gerçek ihtiyacını unutmak.
- Başarısız denemeyi dokümantasyondan silmek. En faydalı not bazen o.
Kısacası, Türkçe geliştiriciler için takvim + uygulanabilir kontrol listesi. Fakat bunu gerçekten değerli yapan şey örnek, ölçüm ve karar bağlamı. Yazıyı yayınladıktan sonra kendi proje ekran görüntümüzü veya küçük bir before/after tablosunu eklemek de bu yüzden iyi fikir.