“Bir indie oyun yapmak ne kadar tutar?” sorusuna tek bir rakamla cevap vermek kolaydır ama üretim açısından pek işe yaramaz. Aynı ekip, aynı motor ve aynı tür içinde bile maliyeti değiştiren şey çoğu zaman fikir değil; kapsamın hangi sistemlere, kaç içerik birimine, ne kadar QA yüzeyine ve hangi release yüküne dönüştüğüdür.
Bu rehber bir fiyat listesi sunmak yerine hesaplanabilir bir üretim modeli kurar. QUBU Production Planner ile birlikte kullanıldığında oyunun kapsamını kişi-ay, takvim süresi, bütçe ve risk açısından karşılaştırmanızı sağlar. Başlamadan önce kendi projenizi Oyun Geliştirme Maliyet, Kapsam ve Süre Hesaplayıcı içinde açabilirsiniz.
1. Fiyat yerine önce kişi-ay hesaplayın
Üretim planlamasında en kullanışlı birimlerden biri kişi-aydır. Bir kişi-ay, bir kişinin yaklaşık bir aylık tam zamanlı üretim kapasitesini temsil eder. Bu birim maaş değildir ve bir işin tam olarak kaç takvim ayı süreceğini de tek başına söylemez. Fakat farklı kapsamları karşılaştırmak için ortak bir dil sağlar.
Örneğin bir sistemin mühendislik, UI ve QA toplamında yaklaşık dört kişi-ay yük ürettiğini düşünelim. Dört kişilik ekip bunu otomatik olarak bir ayda bitiremez; çünkü disiplinler aynı anda tamamen paralel ilerlemez, bağımlılıklar vardır ve herkes yüzde yüz üretim kapasitesiyle çalışmaz. Takvim hesabı bu yüzden toplam kişi-ayın ekip kapasitesine bölünmesinden daha karmaşıktır.
2. Ekip büyüdükçe süre doğrusal azalmaz
Bir projeye ikinci geliştiriciyi eklemek çoğu zaman hızı ciddi artırır. Fakat ekip 2’den 4’e, 4’ten 8’e çıktıkça iletişim, code review, build koordinasyonu, tasarım senkronizasyonu ve entegrasyon maliyeti de büyür. Ayrıca sanat, tasarım, programlama ve QA yükleri aynı anda eşit dağılamaz. Bu nedenle sekiz kişilik ekip, tek kişinin işini teorik olarak sekizde bir sürede bitiren bir makine değildir.
Planner takvim tahmininde “kullanılabilir kapasite” ve ekip büyüklüğüne göre artan koordinasyon kaybı uygular. Buradaki amaç matematiksel kesinlik değil, planın sahte bir doğrusal ölçek varsayımına dayanmasını engellemektir.
3. Sistem seçimi gerçek scope’u belirler
“2D roguelike” veya “online strategy” tek başına üretim kapsamı değildir. Scope, oyuncunun deneyimlediği ve ekibin sahiplenmek zorunda olduğu sistemlerin birleşimidir. Combat, inventory, progression, economy, quests, procedural generation, accounts, cloud save, matchmaking, analytics, live ops, mod support ve benzeri her sistem farklı disiplinlerde farklı yük üretir.
En tehlikeli hatalardan biri sistemleri yalnızca ilk implementasyon maliyetiyle düşünmektir. Örneğin leaderboard, ilk bakışta küçük bir özellik olabilir. Fakat çevrim içi oyunda kimlik, hile, sezon reseti, eşitlik durumu, cache, veri migrasyonu ve görünür hata davranışı ek QA ve operasyon yüzeyi yaratır. Production Planner bu nedenle sistemlerin yalnızca “kod puanını” değil, tasarım, UI, QA ve operasyon yükünü de ayrı taşır.
4. Multiplayer bir çarpan değil, yeni bir üretim katmanıdır
Offline oyun ile asenkron çevrim içi oyun, co-op ve rekabetçi gerçek zamanlı oyun aynı risk sınıfında değildir. Network modelinin büyümesi; otorite, latency davranışı, disconnect/reconnect, eski client, eşzamanlı işlem, persistence, matchmaking ve telemetry gibi yeni sorular üretir. Bu soruların bir kısmı release öncesi, bir kısmı ise oyun canlıya çıktıktan sonra maliyet yaratır.
Bu yüzden yalnızca “multiplayer seçildi, bütçeye yüzde 30 ekle” yaklaşımı zayıftır. Daha iyi model, online özelliklerin hangi sistemlerle birleştiğine bakar. Matchmaking + accounts + live ops + anti-cheat + cross-play kombinasyonu, basit iki kişilik peer-to-peer co-op’tan tamamen farklı bir operasyon projesidir.
5. İçerik hacmi özellik sayısından daha hızlı büyüyebilir
İki oyun aynı sistemleri paylaşsa bile içerik yükleri farklı olabilir. Harita, bölüm, karakter, item, görev, diyalog ve sinematik sayısı arttıkça yalnızca üretim değil; entegrasyon, localization, regression QA ve dengeleme yükü de artar. Content-heavy projelerde kod erken tamamlanabilir ama oyun hâlâ aylarca çıkışa hazır olmayabilir.
Bu nedenle kapsam planında sistemler ve içerik ayrı tutulmalıdır. Bir inventory sistemi bir kez geliştirilir ama yüzlerce item’ın verisi, ikonları, açıklamaları, denge değerleri ve test yüzeyi üretim boyunca taşınır.
6. “Polish” bağımsız bir bütçe kalemidir
Prototype, küçük bir ticari indie release ve premium sunum aynı definition of done’a sahip değildir. Aynı feature listesi; animasyon geçişleri, accessibility, gamepad davranışı, hata mesajları, tutorial, save recovery, platform entegrasyonu ve edge-case testleri eklendiğinde çok farklı üretim seviyelerine dönüşür.
Planner bu farkı hedef kalite katmanıyla modeller. Bu değer yalnızca görsel kalite değildir; oyuncuya sunulan sistemin ne kadar güvenilir, okunabilir ve release-ready olması beklendiğini temsil eder.
7. Bütçe formülü: gerçek maliyet varsayımınızı siz girin
Global ekiplerde kişi-ay maliyeti aşırı değişken olduğu için aracın verdiği varsayılan değer “sektör ortalaması” değildir. Kendi tam maliyetinizi girmeniz gerekir. Bu değere maaş veya freelancer ücreti dışında şirket yükleri, ekipman, yazılım, yönetim ve sürekli dış kaynak maliyetlerinden hangilerini dahil etmek istediğinizi açıkça belirleyin.
Basit bütçe mantığı şöyledir: risk düzeltilmiş kişi-ay × kişi-ay maliyeti + sabit dış harcama. Marketing bütçesi, vergi ve finansman gideri gibi üretim dışı kalemleri ayrı modellemek daha sağlıklıdır.
8. Takvim baskısı risk skorunu neden yükseltir?
Bir projenin doğal üretim aralığı 16–22 ay görünürken 10 aylık hedef girmek, işi sihirli şekilde küçültmez. Genellikle üç şey olur: paralel çalışma artırılır, scope kesilir veya kalite/QA alanından borç alınır. İlk seçenek koordinasyon maliyeti, son seçenek release riski yaratabilir.
Planner hedef süre doğal takvimin belirgin biçimde altına düştüğünde risk skorunu yükseltir. Bu, “10 ayda yapılamaz” demek değildir; planın ekstra bir çözüm gerektirdiğini görünür kılar.
9. Stretch özellikleri baştan işaretleyin
Scope kontrolünün en etkili yöntemlerinden biri, her fikri eşit statüde tutmamaktır. Oyuncu vaadini taşıyan sistemler Core, iyi olursa eklenecek sistemler Stretch olmalıdır. Planner kontrollü senaryoda stretch kalemlerini çıkararak bir release tabanı oluşturur.
Bu ayrım feature freeze yaklaşımını da güçlendirir. Takvim kaydığında “hangi özelliği keselim?” tartışmasını sıfırdan yapmak yerine, önceden tanımlı scope sınırına geri dönersiniz.
10. Örnek proje zarfları nasıl okunmalı?
Aşağıdaki aralıklar pazar ortalaması değildir; modelin farklı kapsam tiplerini nasıl ayırdığını göstermek için hazırlanmış planlama örnekleridir. Gerçek sonuç seçilen sistemlere, içerik sayısına, ekip hızına ve kalite seviyesine göre değişir.
| Örnek proje | İllüstratif kişi-ay zarfı | Ana risk |
|---|---|---|
| Solo 2D roguelite | 12–22 | İçerik ve solo kapasite |
| 2 kişilik Steam co-op | 28–50 | Network + QA |
| 4 kişilik online survival | 60–110 | Persistence + content + live ops |
| Asenkron strateji | 30–55 | Economy + server state + UX |
| Mobile F2P | 45–85 | Economy + analytics + live ops |
Bu zarfları kopyalamak yerine kendi oyununuzu Production Planner içinde sistem sistem kurun. Aracın asıl değeri, toplam rakamdan çok hangi seçimin yükü artırdığını göstermesidir.
11. Scope keserken en pahalı özelliği değil en pahalı bağımlılığı arayın
Bir özelliği kaldırmak her zaman görünen kişi-ay kadar tasarruf sağlamaz. Bazen bir sistem başka üç sistemin varlık sebebidir. Örneğin ranked PvP kaldırıldığında anti-cheat, sezon leaderboard’u, bazı matchmaking kuralları ve support yükü de küçülebilir. En güçlü scope kesintileri bir özelliği değil bir bağımlılık zincirini ortadan kaldırır.
12. Production Planner sonucundan sonra ne yapmalı?
İlk olarak scope’u yazılı hale getirin. QUBU GDD Oluşturucu ile player promise, core loop, progression, economy ve success metrics alanlarını netleştirin. Ticari hedefinizi Steam üzerinden düşünüyorsanız Steam Gelir Hesaplayıcı ile brüt satış hedefinizi net geliştirici geliri varsayımlarına çevirin. Live-service economy varsa Ekonomi Enflasyon Hesaplayıcı ile sources/sinks baskısını modelleyin.
13. QA neden sona bırakılacak bir faz değildir?
QA’yı “oyun bittiğinde test ederiz” diye planlamak scope’u olduğundan küçük gösterir. Her yeni sistem yalnızca kendi happy path’ini değil, diğer sistemlerle kurduğu kombinasyonları da büyütür. Inventory ile crafting, cloud save ile progression, matchmaking ile party sistemi birleştiğinde hata yüzeyi özellik sayısından daha hızlı genişleyebilir.
Bu yüzden planner QA yükünü ayrı bir disiplin olarak taşır. Özellikle online, cross-platform veya yüksek içerik hacimli projelerde regression testleri, save migration, eski client davranışı, platform input farkları ve recovery senaryoları release tarihinin gerçek belirleyicisi olabilir. QA kapasitesi görünmüyorsa “feature complete” olmak, “ship-ready” olmakla karıştırılır.
14. Outsourcing bütçeyi küçültmez; kapasitenin yerini değiştirir
Art, audio, localization, trailer veya QA outsourcing’i doğru kullanıldığında iç ekipteki darboğazı çözebilir. Fakat dış kaynak “bedava paralellik” değildir. Brief hazırlama, referans, feedback turu, integration, source file yönetimi ve kalite kontrolü içeride zaman tüketir. Özellikle üretim dili net olmayan ekipler, dış kaynakla zaman kazanmak yerine rework üretebilir.
Planner’daki sabit dış harcama alanı, bu maliyeti kişi-ay hesabından ayrı tutmak içindir. Eğer dış kaynak üretim kapasitesini gerçekten değiştiriyorsa, ekip kapasitesi ve içerik varsayımlarını da buna göre güncelleyin. Sadece faturayı ekleyip takvimi aynı bırakmak veya sadece takvimi kısaltıp entegrasyon yükünü yok saymak aynı derecede yanıltıcıdır.
15. Kişi-ay maliyeti bütçeyi nasıl değiştirir?
Aşağıdaki tablo ücret benchmark’ı değildir; aynı scope’un farklı maliyet yapılarında bütçeye nasıl dönüştüğünü gösteren basit bir hassasiyet örneğidir. 30 kişi-aylık bir üretim yükünü düşünelim ve dış harcamayı şimdilik sıfır kabul edelim.
| Kişi-ay maliyeti | 30 kişi-ay üretim | Ne anlatır? |
|---|---|---|
| $3.000 | $90.000 | Düşük maliyetli ekip yapısında aynı scope |
| $6.000 | $180.000 | Aynı üretim yükünün iki kat nakit ihtiyacı |
| $10.000 | $300.000 | Scope değişmeden yüksek tam maliyet yapısı |
Bu tablo neden “bir indie oyun ortalama X dolara yapılır” cümlesinin zayıf olduğunu gösterir. Scope sabitken bile ekip ekonomisi sonucu katlayabilir. Aynı şekilde aynı bütçeyle farklı bölgelerde veya farklı outsourcing modellerinde satın alınabilen üretim kapasitesi de değişir.
16. İlk vertical slice modelinizi kalibre etsin
Bir calculator ancak gerçek üretim verisiyle karşılaştırıldığında güçlü hale gelir. Oyunun tamamını başlamadan önce kesin hesaplamaya çalışmak yerine bir vertical slice seçin: çekirdek loop’u, temel UI’ı, save akışını ve mümkünse release pipeline’ını aynı küçük dilimde çalıştırın. Sonra tahmin edilen ve gerçek harcanan kapasiteyi karşılaştırın.
Örneğin ilk slice için 2,5 kişi-ay tahmin edip 4 kişi-ay harcadıysanız, farkın nedenini ayırın. Tahmin mi düşüktü, tooling mi eksikti, ekip yeni teknoloji mi öğrendi, içerik pipeline’ı mı yavaştı, yoksa QA edge case’leri mi büyüdü? Bu cevap, bütün proje tahminine kör bir “1,6 çarpanı” eklemekten daha değerlidir. Hangi disiplinin sapma ürettiğini bilirseniz sonraki tahminleri daha doğru kalibre edebilirsiniz.
17. Scope karar matrisi: oyuncu değeri × üretim yükü
Bir feature’ın pahalı olması tek başına onu kesmek için yeterli değildir. Oyuncu vaadini taşıyan pahalı bir sistem, ürünün varlık sebebi olabilir. Daha faydalı karar matrisi her sistemi iki eksende değerlendirir: oyuncu için ayırt edici değer ve üretim/operasyon yükü.
- Yüksek değer / düşük yük: genellikle koruyun ve erken doğrulayın.
- Yüksek değer / yüksek yük: core kabul edin ama teknik riski vertical slice içinde çözün.
- Düşük değer / düşük yük: polish aşamasına kadar erteleyin.
- Düşük değer / yüksek yük: en güçlü Stretch veya kesme adayıdır.
Production Planner’daki Core/Stretch seçimi bu düşünceyi takvime bağlar. Stretch sistemler daha baştan ayrı olduğu için kontrollü senaryo gerçek bir MVP sınırı verir.
18. Bütçede unutulan kalemleri scope’tan ayırın
Üretim bütçesi ile şirketin tüm nakit ihtiyacı aynı şey değildir. Oyunun yapım kapasitesini hesaplarken ekip ve doğrudan üretim harcamalarını modelleyebilirsiniz; fakat pazarlama, şirket kuruluş/giderleri, vergiler, finansman maliyeti, etkinlik seyahati, dev kit, rating süreçleri, hukuki hizmetler ve platforma özel gereksinimler ayrı nakit planı isteyebilir.
Bunları tek bir görünmez “contingency” yüzdesine gömmek yerine isimlendirmek daha sağlıklıdır. Scope kararı başka, finansman kararı başkadır. Bir özelliği kesmek pazarlama bütçesini otomatik küçültmez; aynı şekilde yatırım almak teknik kapsamı otomatik olarak güvenli hale getirmez.
19. Tahmini ne zaman güncellemelisiniz?
Planı her hafta yeniden hesaplamak gereksiz gürültü yaratabilir. Bunun yerine modelin ana varsayımlarından biri değiştiğinde güncelleyin: platform eklendiğinde, multiplayer modeli büyüdüğünde, content target belirgin değiştiğinde, yeni bir Core sistem geldiğinde, ekip kapasitesi değiştiğinde veya vertical slice gerçek verisi ilk tahmini çürüttüğünde.
Eski tahmini silmeyin. Planned scope’un zaman içindeki değişimini saklamak, scope creep’i görünür yapar. “Başta 28 kişi-aydı, şimdi 44 kişi-ay” cümlesi tek başına problem değildir; önemli olan artışın hangi kararlardan geldiğini ve ekibin bu kararı bilinçli alıp almadığını bilmektir.
Sonuç: doğru soru “kaça yapılır?” değil, “hangi kapsamı güvenle çıkarabiliriz?”
Bir oyun projesinin maliyetini anlamanın en güçlü yolu önce özellik listesini üretim yüküne dönüştürmektir. Kişi-ay, takvim, bütçe ve risk birbirinden ayrı ama bağlı değişkenlerdir. Scope net değilse bütçe sahte kesinlik üretir; ekip kapasitesi hesaba katılmıyorsa takvim güvenilmez olur; QA ve operations görünmüyorsa release planı eksiktir.