3 Mayıs 2026
Bölüm 01 · İlk fikir
Hard Kapitalizm doğuyor
Projenin ilk net hali üretim, depolama, ticaret ve lojistik planlamasına dayanan bir mobil ekonomi simülasyonuydu. Oyuncu 100.000 TL ile başlıyor; hazır mağaza, depo, tarla, araç veya tesis almıyordu. İlk amaç küçük bir ticaret döngüsünden kendi şirket ağını kurmaktı.
Karşımıza çıkan sorunlar
- Başlangıçta oyunun çok kolay biçimde klasik bir ‘ürün al-sat’ oyununa dönüşme riski vardı.
- Mağaza, depo, üretim ve lojistik ayrı ayrı tasarlanırsa ileride birbirleriyle tutarsız çalışan sistemler oluşabilirdi.
- Oyuncuya hazır işletmeler vermek, şirketi sıfırdan kurma hissini zayıflatıyordu.
Ne denedik?
- İlk akış depo kur → mağaza kur → ürün tedarik et → mağazaya aktar → sat şeklinde sadeleştirildi.
- Ürünler tek merkezden tanımlansın diye ortak products modeli benimsendi.
- NPC tedariki yalnızca gerçek satıcı bulunmadığında devreye girecek fallback olarak konumlandırıldı.
Çözüm / alınan karar
- Oyunun ana ilkesi ‘tek ürün ticareti’ değil ‘birbirine bağlı işletme sistemi’ olarak sabitlendi.
- Şirket büyümesi para biriktirmekten çok yeni üretim ve dağıtım halkaları eklemek üzerine kuruldu.
- Başlangıçta hiçbir işletme vermeme kararı korundu; oyuncu altyapısını kendisi kuracaktı.
SonuçBu karar, daha sonra gelen üretim zinciri, şehir, depo ve lojistik sistemlerinin ortak temelini oluşturdu.
3–4 Mayıs 2026
Bölüm 02 · Ekonomi motoru
Üretim, stok ve lojistik kuralları şekilleniyor
İlk günlerde asıl iş görünür arayüz değil, görünmeyen ekonomi motoruydu. Tarla, çiftlik, fabrika ve madenlerin farklı davranışları tek sistem altında çalıştırılmaya çalışıldı; stok, maliyet ve şehirler arası taşıma kuralları aynı anda tanımlandı.
Karşımıza çıkan sorunlar
- Sürekli üretimde hangi anda ne kadar ürün üretildiğini güvenilir biçimde hesaplamak gerekiyordu.
- Hammadde maliyeti transfer ve üretim boyunca kaybolursa kârlılık hesabı anlamsız hale geliyordu.
- Aynı şehir ile şehirler arası teslimatı aynı RPC mantığına zorlamak gereksiz karmaşa yaratıyordu.
- Input ve output aynı stok havuzunda tutulursa üretim sırasında neyin tüketildiği ve neyin üretildiği karışıyordu.
Ne denedik?
- Üretim için 10 dakikalık tick/cron modeli kuruldu; aktif birim ve yeterli input varsa geçen süre kadar üretim işlendi.
- Input ve output envanteri ayrı tutuldu; üretilen mal önce üretim biriminin output stokuna yazıldı.
- Şehirler arası satın almada araç kapasitesi alış anında rezerve edildi; aynı şehir teslimatı ise anlık bırakıldı.
- Maliyet için basit son-fiyat yerine ağırlıklı ortalama yaklaşımı denendi.
Çözüm / alınan karar
- Üretim envanteri ortak owner_kind/owner_id modeli altında birleştirildi fakat input/output ayrımı korundu.
- Ürün değişmediği sürece maliyet ağırlıklı ortalamayla taşındı; transfer ve üretimde maliyet zinciri koparılmadı.
- NPC satıcı da farklı bir özel akış yerine aynı pazar/transfer sisteminin fallback satıcısı yapıldı.
- Üretim sürekli akacak, oyuncudan her parti için ‘başlat’ onayı istenmeyecek kararı verildi.
SonuçEkonomi simülasyonunun en temel karakteri burada oluştu: oyuncu tek tek üretim emri vermek yerine çalışan bir sistem kurup darboğazları yönetiyor.
Mayıs 2026
Bölüm 03 · İlk mimari borçlar
Slotlar, inşaat ve farklı üretim birimlerini tekleştirme
Üretim birimleri çoğaldıkça her bina için ayrı tablo ve ayrı iş akışı yazmanın sürdürülemez olduğu anlaşıldı. Fabrika/maden ile tarla/çiftlik farklı davranıyor, mağazaların ise tamamen ayrı slot mantığı bulunuyordu.
Karşımıza çıkan sorunlar
- Factory, field, farm ve mine için ayrı ayrı aynı kodun çoğalması bakım maliyetini artırıyordu.
- İnşaat süresi ve tamamlanma alanlarını final bina tablolarında tutmak veri modelini şişiriyordu.
- Bazı erken şemalarda production_slots kısıtları ile RLS/owner_kind beklentileri birbiriyle uyuşmuyordu.
- Eski ve yeni transfer RPC’leri aynı işi farklı isimlerle yapmaya başlamıştı.
Ne denedik?
- Üretim slotları ve production_inventory ortaklaştırıldı.
- Bütün bina inşaatları için tek building_constructions tablosu kullanıldı.
- Araç seçimi ve transfer başlatma için farklı bina türlerine özel RPC’ler yerine merkezi fonksiyonlara geçiş başlatıldı.
Çözüm / alınan karar
- İnşaat tamamlanınca final tabloya kayıt açılıyor; inşaatla ilgili geçici alanlar final tabloda tutulmuyor.
- Production slot ve envanter yapısı owner_kind üzerinden ortaklaştırıldı; mağaza slotları ayrı kaldı çünkü satış mantığı farklıydı.
- Tek oyuncu için aynı anda tek inşaat kuralı getirildi ve yarış koşullarını azaltan ortak kontrol noktası oluşturuldu.
- Eski transfer/getter fonksiyonları zamanla temizlenecek legacy listesine alındı.
SonuçBackend, bina sayısı arttıkça kırılmak yerine yeni bina türlerini aynı çekirdek üzerinde taşıyabilecek hale geldi.
24 Mayıs 2026
Bölüm 04 · İlk büyük durum tespiti
Temel vardı, ama oyun henüz oyun değildi
Ana branch ilk kez bütün olarak değerlendirildiğinde mağaza, depo, lojistik ve pazar tarafında gerçek backend bağlantıları vardı; ancak uçtan uca ‘üret → depola → mağazaya aktar → sat’ döngüsü tam kapanmamıştı.
Karşımıza çıkan sorunlar
- Bazı ekranlarda gerçek veriler varken ana sayfa ve finansal özetlerde hardcoded değerler kalmıştı.
- Üretim modüllerinin önemli bölümü listeleme/kurulum seviyesindeydi; gerçek üretim döngüsü bütün birimlerde aynı olgunlukta değildi.
- Aktif geliştirme feature/setup-industrial-units branch’inde ilerlediği için sadece main’e bakmak projenin olduğundan daha eksik görünmesine yol açıyordu.
- Lojistik taşıma testleri ve hata yönetimi zayıftı.
Ne denedik?
- Projeyi yüzde üzerinden değerlendirmek yerine çalışan gerçek oyuncu akışları tek tek çıkarıldı.
- UI parlatmak yerine önce backend aksiyonlarını bitirme kararı verildi; arayüz bir süre test paneli gibi kullanıldı.
- Store → warehouse → factory → field → farm → mine → market/transfers sıralamasıyla backend akışları tamamlanmaya başlandı.
Çözüm / alınan karar
- Öncelik uçtan uca ekonomi döngüsüne verildi; tekil ekranların ‘çalışıyor görünmesi’ tamamlanmış özellik sayılmadı.
- Branch farkı sonraki analizlerde açıkça dikkate alınmaya başlandı.
- Üretim, satış ve transfer için ortak test senaryoları tanımlandı.
SonuçBu dönem, projenin ‘çok ekranı olan prototip’ olmaktan çıkıp çalışan ekonomi sistemine dönüşmesinin başlangıcı oldu.
Haziran 2026
Bölüm 05 · Derinlik ve dengeleme
Basit ticaretten gerçek şirket yönetimine
Çekirdek çalışmaya başladıkça yeni sorun içerik eksikliği değil, karar derinliğiydi. Marka, kalite, Ar-Ge, görevler, başarımlar, finans ve şirket değeri gibi katmanlar ekonominin çevresine eklendi.
Karşımıza çıkan sorunlar
- Bazı ürünlerde kâr marjı aşırı düşükken bazı ürünlerde yüzlerce hatta binlerce yüzdeye çıkan dengesizlikler vardı.
- Sadece satış fiyatını artırmak ya da azaltmak gerçek üretim maliyetini açıklamıyordu; üretim birimi maliyeti hesaba katılmadığında yanlış denge kararları çıkıyordu.
- Oyuncunun tek hedefi nakit büyütmek olursa lojistik, kalite ve üretim zinciri kararları anlamsızlaşabilirdi.
Ne denedik?
- Ürün maliyetleri ve baz satış fiyatları topluca tarandı; düşük marjlı ve aşırı marjlı uç değerler belirlendi.
- Örneğin Krom Saat ve Mermer Heykel gibi belirgin outlier ürünlerde fiyatlar aşağı çekildi; bazı erken tarım ürünlerinde marj artırıldı.
- Dengeleme yalnızca baz reçete maliyetine göre yapılınca ek üretim birimi maliyetinin bazı ürünleri yeniden düşük marja ittiği görüldü.
Çözüm / alınan karar
- Dengeleme tek sayı üzerinden değil toplam üretim maliyeti üzerinden ele alınmaya başlandı.
- Şirket değeri; nakit, işletme, stok, araç ve yükseltme değerlerinin toplamına bağlandı.
- Ar-Ge ve 1–5 kalite sistemi uzun vadeli yatırım kararına dönüştürüldü; kalite değişimi devam eden üretimi otomatik değiştirmedi.
SonuçOyunun hedefi ‘en yüksek para’ olmaktan çıkıp tedarik, kalite, kapasite ve finansı birlikte yöneten bir holding kurmaya doğru kaydı.
18 Temmuz 2026
Bölüm 06 · Görsel dünya tartışması
İzometrik şehir fikri ilk kez ciddi biçimde masaya geliyor
Yönetim ekranları güçlendikçe şirketin ekranda ‘yaşamadığı’ hissi belirginleşti. Bir ara ayrı bir Unity istemcisi ve daha görsel bir dünya yaklaşımı bile masaya geldi.
Karşımıza çıkan sorunlar
- Proje bilgi açısından zengindi ama oyuncunun şirketini mekânsal olarak görmesi zayıftı.
- Tamamen yeni bir motor/istemciye geçmek backend, UI, asset ve haritayı aynı anda yeniden yazma riski taşıyordu.
- İzometrik dünyayı ana oyun haline getirmek, güçlü yönetim ekranlarının değerini yok edebilirdi.
Ne denedik?
- Unity ile ayrı prototip, ortak Supabase backend ve kademeli geçiş senaryosu değerlendirildi.
- Map/building verisinin grid koordinatı, orientation, occupied cells ve level/state gibi motor bağımsız alanlarda tutulması fikri geliştirildi.
- Ürünlerin nerede olduğunu tek yerde gösteren Product Center benzeri merkez ekranlar düşünüldü.
Çözüm / alınan karar
- Backend motor bağımsız kalacak; görsel dünya yalnızca başka bir istemci katmanı olacak prensibi kabul edildi.
- Yönetim ekranları korunacak, izometrik dünya onların yerine değil üstüne eklenecekti.
- Aynı anda backend, ekonomi, UI, harita ve asset rewrite yapmama kararı alındı.
SonuçTemmuzdaki bu fikir, Eylül ayında Flutter + Flame ile gerçek 2D izometrik dönüşümün tasarım temelini hazırladı.
Ağustos 2026
Bölüm 07 · Gerçek dünya gereksinimleri
Google girişi, test hesapları ve sunucu otoritesi
Oyun büyüdükçe yalnızca mekanik değil, gerçek platform gereksinimleri de mimariye girmeye başladı. Google Sign-In, mağaza inceleme senaryoları ve sunucu taraflı satın alma güvenliği bunların başındaydı.
Karşımıza çıkan sorunlar
- Google Sign-In ile otomatik hesap açılması, inceleme ekibi için tekrar kullanılabilir sabit bir demo hesabı sağlamayı zorlaştırıyordu.
- 2FA ve yalnızca Google girişine bağlı akış, dış inceleme/test senaryolarında erişim sorunu yaratabilirdi.
- Premium para veya satın alma sonuçlarını istemciye güvenerek değiştirmek güvenli değildi.
Ne denedik?
- Geçici e-posta girişini tamamen ayrı bir auth sistemi yapmak yerine backend kontrollü flag ile açıp kapatma fikri geliştirildi.
- Satın alma doğrulamasının backend/Edge Function tarafında yapılması planlandı.
- Test akışları gerçek oyuncu hesabından ayrıştırılmaya çalışıldı.
Çözüm / alınan karar
- Ana giriş yöntemi Google olarak kaldı; inceleme erişimi gerektiğinde geçici ve kontrollü alternatif giriş açılabilecek model seçildi.
- Nakit, altın ve premium hareketlerde server-authoritative yaklaşım korunmaya başladı.
- İstemcinin ‘sonuç’ değil ‘istek’ göndermesi, gerçek sonucu backendin üretmesi temel güvenlik prensibi oldu.
SonuçPlatform gereksinimleri, oyunun backend mimarisinin yalnızca gameplay değil kimlik ve ekonomi güvenliğini de taşıması gerektiğini gösterdi.
26 Ağustos 2026
Bölüm 08 · QA envanteri
647 maddelik aksiyon listesi
Özellik sayısı arttıkça ‘oyunda tam olarak ne çalışıyor?’ sorusuna cevap vermek zorlaştı. Bu nedenle oyuncunun girişten başlayarak yapabildiği gerçek aksiyonlar uçtan uca tarandı.
Karşımıza çıkan sorunlar
- Bir ekranın var olması o özelliğin tamam olduğu anlamına gelmiyordu.
- Birbirine bağlı sistemlerde küçük bir transfer hatası mağaza, depo, üretim ve görev state’ini aynı anda bozabiliyordu.
- Sorunlar büyük başlıklar halinde tutulunca neyin test edildiği ve neyin kaldığı belirsizleşiyordu.
Ne denedik?
- Production, warehouse, logistics, market, finance, task, notification ve end-to-end akışlar tek tek kullanıcı aksiyonlarına dönüştürüldü.
- Kontrol listesi yüzlerce küçük maddeye bölündü; sonuçta 647 maddelik kapsam çıktı.
- Daha sonra çalışma biçimi de ‘tek seferde tek küçük görev’ olacak şekilde değiştirildi.
Çözüm / alınan karar
- Feature tamamlandı/tamamlanmadı yerine gerçek eylem bazlı QA kullanılmaya başlandı.
- Her hata mümkün olduğunca tek RPC, tek ekran veya tek state zincirine indirgenerek ele alındı.
- Project Book döneminde bu test yaklaşımı kalıcı checklist yapısına bağlandı.
SonuçProjenin büyüklüğü ilk kez somutlaştı ve ‘her şeyi aynı anda düzeltme’ yaklaşımından küçük, doğrulanabilir adımlara geçildi.
28 Ağustos – 9 Eylül 2026
Bölüm 09 · State mimarisi
Invalidate fırtınasından patch sistemine
Backend mutation sayısı yükseldikçe her işlemden sonra provider invalidate edip bütün veriyi yeniden çekmek hem ağ yükünü hem de UI karmaşasını büyüttü. Yeni hedef, yalnızca değişen veriyi frontende döndürmekti.
Karşımıza çıkan sorunlar
- Bir transfer sonrası depo, üretim envanteri, araç ve transfer listesi ayrı ayrı yeniden yüklenebiliyordu.
- Route refresh, timer refresh ve provider invalidate aynı anda çalışınca aynı endpoint birkaç kez çağrılabiliyordu.
- Join/enriched modeller ile ham tablo state’ini aynı patch mekanizmasına zorlamak bazı ekranlarda eksik veri oluşturuyordu.
Ne denedik?
- RPC cevaplarına backend final state ve changed paketleri eklendi.
- Mağaza, depo, production inventory, transfer ve market işlemleri parti parti patch-aware hale getirildi.
- Aynı şehir market alışında mode=instant, şehirler arası alışta mode=in_transit ayrımı yapıldı.
Çözüm / alınan karar
- Ana kural Mutation → DB final state → patch layer → app state → UI olarak sabitlendi.
- Fallback sırası patch → targeted detail refresh → feature invalidate oldu; global refresh son çare olarak bile kullanılmamaya başlandı.
- Ham patch yeterliyse invalidate kaldırıldı; yalnızca zenginleştirilmiş/joined modele gerçekten ihtiyaç olan ekranlarda hedefli refresh tutuldu.
SonuçFrontend daha az veri çekmeye, değişiklikleri daha hızlı göstermeye ve backendin gerçek final state’ini daha doğrudan yansıtmaya başladı.
30 Ağustos – 12 Eylül 2026
Bölüm 10 · Üretim ve cron sorunları
Aynı üretimi iki kez hesaplamadan çevrimdışı üretime
Üretim başlangıçta cron ile çalışıyordu. Daha sonra detay ekranı açıldığında da production processing eklenince kullanıcı beklemeden güncel üretimi görebildi; ancak iki farklı tetikleyicinin aynı state’i işlemesi yeni sorunlar yarattı.
Karşımıza çıkan sorunlar
- Cron ve detail-open aynı üretim kaydına aynı anda girince yarış koşulu ve deadlock riski oluştu.
- Bir dönemde ‘en fazla 10 tick / en fazla 60 dakika’ sınırı uzun süre çevrimdışı kalan oyuncunun gerçek geçen süre kadar üretim yapmasını engelliyordu.
- Bir gübre fabrikasının gece boyunca üretmemesi gibi vakalar elapsed-time ve last_processed_at mantığının güvenilirliğini sorgulattı.
- Tek oyuncuda günlük yaklaşık 2.300 Postgres ve 1.600 API çağrısı görülmesi gereksiz tekrarları görünür hale getirdi.
Ne denedik?
- Production detail açılışında process_player_production_entry çağrıldı; cron çevrimdışı catch-up/uyarı tarafında tutuldu.
- Tick cap kaldırılması ve geçen gerçek süreye göre üretim hesabı istendi.
- pg_stat_reset sonrası fonksiyon çağrıları yeniden ölçüldü; production, store-detail ve transfer-map çağrı adetleri karşılaştırıldı.
- Index silmek yerine önce gereksiz fetch ve çağrı hacmini azaltma kararı verildi.
Çözüm / alınan karar
- Üretim girişleri atomik işlem mantığına yaklaştırıldı; last processed state transaction içinde güncellenerek aynı sürenin iki kez tüketilmesi engellendi.
- Üretim hesabı elapsed-time tabanlı hale getirildi ve keyfi kısa süre cap’leri temizlendi.
- Background cron sıklığı zaman içinde azaltıldı; gerçek zamanlı his detail-open processing ile, offline güvence cron ile ayrıştırıldı.
- Performans snapshot’ında production cron 24 çalışmada ortalama yaklaşık 105 ms ve sıfır failure verdi; önce call-volume optimizasyonu, sonra EXPLAIN/index optimizasyonu prensibi benimsendi.
SonuçÜretim sistemi ‘cron ne zaman koşarsa o kadar üret’ modelinden, geçen süreyi güvenilir biçimde işleyen ve birden fazla tetikleyiciye dayanabilen modele yaklaştı.
3–9 Eylül 2026
Bölüm 11 · Depo ve transfer yeniden tasarımı
İşletme deposundan şehir deposuna
Eski yapıda hedef seçimi ve transfer rotaları çok fazla işletme/depo kombinasyonuna bölünüyordu. Şehir başına tek genel depo yaklaşımı bu karmaşıklığı azaltmak için getirildi.
Karşımıza çıkan sorunlar
- İstanbul’daki oto galeri gibi bazı işletmeler oluşurken beklenen bağlı depo yapısı oluşmayabiliyordu.
- start_multi_warehouse_to_production_transfer için iki overload bulunması ‘Could not choose the best candidate’ benzeri RPC belirsizliklerine yol açtı.
- Warehouse → field transferlerinde şehir, kaynak slot, hedef input ve transfer state’i birlikte doğru güncellenmediğinde yarım transferler oluşabiliyordu.
- Sebze tarlasında kalite/marka temizlendikten sonra markasız output tekrar oluşması üretim state’inin eski konfigürasyonu yeniden kullanabildiğini gösterdi.
Ne denedik?
- Depo tipleri sadeleştirilip şehirde tek genel depo yaklaşımı seçildi.
- Transfer RPC overload’ları ve eski imzalar tarandı; aynı işi yapan fonksiyonlar tekleştirilmeye başlandı.
- Warehouse → production için same-city zorunluluğu, source decrement/delete, target input increment ve transfer/item complete kriterleri açık test maddelerine dönüştürüldü.
Çözüm / alınan karar
- Yeni invariant: bir şehirde işletme kurmak için o şehirde genel depo bulunmalı.
- Transfer fonksiyonlarında backend final patch otoritesi kabul edildi; gereksiz invalidate kaldırıldı.
- Kaynak sahipliği kontrolleri ve transfer-map zinciri ayrı güvenlik/performance problemi olarak işaretlendi.
- Üretim output’u yalnızca slotun güncel product/quality/brand konfigürasyonundan üretilecek şekilde temizlenmeye başlandı.
SonuçDepo artık her işletmenin eklentisi değil, şehrin lojistik omurgası haline geldi; bu hem backend modelini hem transfer UX’ini sadeleştirdi.
6–12 Eylül 2026
Bölüm 12 · Backend temizliği
Projeyi yeniden anlaşılır hale getirmek
Aylar boyunca eklenen tablolar, RPC’ler, cronlar ve frontend getter’ları artık birbirinin eski versiyonlarını taşımaya başlamıştı. Yeni frontend/izometrik döneme geçmeden önce backendin ‘tek doğru yol’ etrafında temizlenmesi hedeflendi.
Karşımıza çıkan sorunlar
- Kullanılmayan legacy RPC’ler ve aynı işi yapan yeni/eski fonksiyonlar hata ayıklamayı zorlaştırıyordu.
- Push notification altyapısı performans ve bakım açısından karışmıştı; yeniden kurmak eski yapıyı taşımaktan daha güvenli görünüyordu.
- Bazı is_active ve işçilik maliyeti alanları artık gerçek oyun kuralını temsil etmiyordu ama fonksiyonlarda referansları kalmıştı.
- Unused-index uyarılarına bakıp hemen index silmek kısa ölçüm penceresi nedeniyle riskliydi.
Ne denedik?
- Backend frontend yokmuş gibi tarandı; eski getter’lar, kullanılmayan fonksiyonlar ve gereksiz kolonlar temizleme listesine alındı.
- Push ile ilgili cron, tablo ve tetikleyiciler kaldırılıp daha sonra sıfırdan kurma kararı verildi.
- İşçilik maliyeti ve artık kullanılmayan aktivasyon alanlarının bütün fonksiyon referansları tarandı.
- pg_stat sıfırlandı ve gerçek workload sonrası index/fonksiyon istatistiklerinin yeniden toplanması seçildi.
Çözüm / alınan karar
- Önce call-volume ve redundant fetch temizliği, sonra query-level EXPLAIN/index optimizasyonu sırası benimsendi.
- Project Book altında master plan, current status, architecture, decisions, bugs, backlog, gameplay ideas, performance ve test checklist ayrıldı.
- Backend değişiklikleri küçük, test edilebilir görevler halinde ele alınmaya başlandı.
SonuçAmaç ‘en az fonksiyon’ değil, hangi işlemin hangi kanonik RPC üzerinden yürüdüğünün net olduğu bir backend elde etmekti.
9–14 Eylül 2026
Bölüm 13 · Büyük görsel dönüşüm
Mega Kapitalizm 2D izometrik bir dünyaya dönüşüyor
Temmuzda tartışılan görsel merkez fikri Eylül’de gerçek geliştirmeye dönüştü. Flame üzerinde grid, kamera, bina yerleşimi ve runtime dünya prototipi başladı.
Karşımıza çıkan sorunlar
- ‘2:1 izometrik’ ifadesi tek başına yeterli değildi; grid, dünya koordinatı, sprite çözünürlüğü ve kamera açısı birbirine karıştırılıyordu.
- 64×32 mantıksal grid ile 1024×512 yüksek çözünürlüklü zemin asset’i aynı şeymiş gibi ele alınırsa kalite kaybı oluşuyordu.
- 3×2 gibi çok hücreli binalarda bottomCenter anchor ile footprint’in gerçek güney noktası çakışmıyor, görünür kayma oluşuyordu.
- Tiled’de yol/dekor tasarlamak kolaydı fakat oyuncu binaları ve dinamik şehir içeriği runtime olduğu için iki ayrı dünya kaynağı oluşuyordu.
Ne denedik?
- 2:1 dimetrik geometri için eksenler yaklaşık ±26.565° olarak sabitlendi.
- Tiled önce statik şablon, Supabase gerçek veri, Flame runtime birleştirici olarak düşünüldü.
- 3×2/2×3 footprint ve anchor offsetleri test edildi; prototipte bazı binaları ortak footprint standardına çekme yaklaşımı denendi.
Çözüm / alınan karar
- World/grid boyutu ile kaynak texture çözünürlüğü tamamen ayrıldı: mantıksal tile 64×32 olabilir, asset 1024×512 kalabilir.
- Haritanın çoğu katmanı dinamik olduğu için ana yön runtime Flame haritasına çevrildi; Tiled tasarım yardımcısı olarak ikincil kaldı.
- Sprite standardı alt-orta referans noktası + sabit footprint + katman/depth sırası olarak tanımlandı.
- Harita çizim sırası ground → road/decor → buildings → effects → UI şeklinde ayrıştırıldı.
SonuçBu dönüşüm oyunun yönetim derinliğini korurken, şehirde gerçekten bina kurma ve şirketi görsel olarak büyütme hissini ekledi.
11 Eylül 2026
Bölüm 14 · Yeni isim
Hard Kapitalizm → Mega Kapitalizm: İş İmparatorluğu
Proje kapsamı ilk ismi aşınca yeni marka arayışı başladı. İsim Türk oyuncuya yabancı gelmemeli ama tamamen yerel ve küçük ölçekli bir oyun hissi de vermemeliydi.
Karşımıza çıkan sorunlar
- Hard Kapitalizm tanıdık olsa da büyüyen holding/şehir/üretim kapsamını yeterince taşımıyordu.
- Tam Türkçe isimler fazla jenerik, tamamen İngilizce isimler ise hedeflenen yerel kimlikten uzak kalıyordu.
- Yeni adın logo, mağaza başlığı ve oyun içi kullanımda birlikte çalışması gerekiyordu.
Ne denedik?
- Mega Kapitalizm, Kapitalizm Inc. ve Kapitalizm Online gibi seçenekler pazar/isim açısından değerlendirildi.
- Ana marka ile açıklayıcı alt başlığı ayırma yaklaşımı denendi.
Çözüm / alınan karar
- Ana marka ‘Mega Kapitalizm’ olarak seçildi.
- Alt başlık ‘İş İmparatorluğu’ oldu ve logo, splash, mağaza metni ile web sitesinde ortak kullanılmaya başlandı.
SonuçYeni isim eski projenin ‘kapitalizm’ mirasını korurken, şehirler ve sektörler boyunca büyüyen daha büyük ölçekli oyuna uydu.
15–16 Eylül 2026
Bölüm 15 · İzometrik asset problemi
AI güzel bina çiziyor, ama tabana oturtamıyor
İzometrik dünyaya geçince en görünür üretim sorunu asset tutarlılığı oldu. Onlarca bina, her bina için birden fazla seviye ve hepsinde birebir aynı kamera/ışık/footprint gerekiyordu.
Karşımıza çıkan sorunlar
- Görsel üretim araçları detay eklerken tabanın açısını, duvar planlarını veya footprint’i küçük de olsa değiştiriyordu.
- Aynı prompt ile üretilen binalar arasında ışık yönü, perspektif ve oran farkı oluşuyordu.
- Her bina ve 5 seviye için Blender modeli bulmak/üretmek çok uzun bir pipeline’a dönüşüyordu.
- Çok hücreli binalarda sprite canvas boyutu ile footprint boyutu karıştırıldığında hizalama bozuluyordu.
Ne denedik?
- Blender’da kilitli ortografik kamera, sabit ışık ve parametrik footprint ile tam kontrollü pipeline düşünüldü.
- Ajanlara 3D model/parça buldurma fikri değerlendirildi ancak üretim zinciri gereğinden uzun kaldı.
- AI’ye doğrudan ‘bina oluştur’ demek yerine siyah/şablon tabanı verip yalnızca yüzey detayı ekletme denendi.
Çözüm / alınan karar
- Blender ana üretim yolu olmaktan çıkarıldı; gerektiğinde yardımcı araç olarak bırakıldı.
- Photopea’da footprint geometrisi önce elle doğru hazırlanıyor; Perspective/Distort ve maskeleme ile görsel yüzeylere oturtuluyor.
- AI’ye ‘geometriyi, outline’ı, roof plane’leri, base alignment’ı ve kamerayı değiştirme; yalnızca yüzey detayı ekle’ kuralı verildi.
- Tüm assetlerde 2:1 dimetrik, ortografik, nötr ışık ve alt-orta anchor standardı sabitlendi.
SonuçHedef ‘her seferinde en güzel bina’ olmaktan çıktı; bütün binaların aynı oyuna ait görünmesi daha önemli kalite kriteri haline geldi.
16–17 Eylül 2026
Bölüm 16 · Teknik testler ve web altyapısı
APK imzasından megakapitalizm.com’a
Cihaz üstü testler sürerken iki ayrı altyapı sorunu aynı döneme denk geldi: release APK’da Google Sign-In ve oyunun kendi web adresi.
Karşımıza çıkan sorunlar
- CI üzerinden üretilen APK’larda değişken debug imzası kullanıldığında Google OAuth tarafındaki SHA eşleşmesi bozuluyor ve giriş sessizce başarısız olabiliyordu.
- Domain ilk kurulumda eski FreeHosting DNS kayıtları ve önbellek nedeniyle bazen yeni siteyi, bazen eski hosting sayfasını gösterebiliyordu.
- Cloudflare Worker kodu ile GitHub repository arasında otomatik deploy kurulmadan her site değişikliği manuel kalacaktı.
Ne denedik?
- Google Cloud ve Supabase OAuth client yapılandırmaları yeniden kontrol edildi; hatanın backend değil APK signing kaynağı olduğu ayrıştırıldı.
- Sabit release upload keystore oluşturulup CI secret’larıyla build zincirine bağlandı.
- TürkTicaret.Net nameserver’ları Cloudflare’ın iki nameserver’ına geçirildi; Worker önce Hello World ile doğrulandı.
- GitHub main branch ile Cloudflare Builds bağlantısı kuruldu ve website/ root directory seçildi.
Çözüm / alınan karar
- Release build artık sabit signing kimliğiyle üretiliyor; OAuth istemcisi bu kalıcı imzaya göre çalışıyor.
- DNS tarafında eski hostingi ‘kod hatası’ sanmak yerine nameserver propagation/cache ayrıştırıldı ve kayıtlar değiştirilmeden yayılımın tamamlanması beklendi.
- GitHub → Cloudflare Worker otomatik build/deploy zinciri kuruldu; megakapitalizm.com oyunun kalıcı web evi oldu.
SonuçBu çalışmalar yayın hazırlığı anlamına gelmiyor. Oyun hâlâ yoğun geliştirme aşamasında; web sitesi şimdilik proje günlüğü, oyun tanıtımı ve ileride gerekli olacak hesap/gizlilik altyapısı için temel oluşturuyor.
