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.
18–26 Eylül 2026
Bölüm 17 · Üretim ve veri modeli
Sürekli üretimden seçilebilir üretim partilerine
Eski sürekli üretim, kuyruk, işletme deposu ve aktiflik alanları yeni oyunun aynı anda içinde yaşamaya başlamıştı. Oyuncunun ne ürettiğini, ne zaman biteceğini ve ürünü hangi depoya alacağını daha açık bir döngüye bağladık.
Karşımıza çıkan sorunlar
- Eski kuyruk ve sürekli üretim varsayımları yeni slot ekranlarıyla uyuşmuyordu.
- İşçilik ve farklı aktiflik alanları hem maliyet hesabını hem fonksiyon bakımını zorlaştırıyordu.
Ne denedik?
- Üretim ve tamamlama fonksiyonları, eski alanlara yapılan referanslarla birlikte tarandı.
- Başlat, bekle ve şehir deposuna topla akışı üzerinden slot davranışı yeniden ele alındı.
Çözüm / alınan karar
- Üretim kuyruğu kaldırıldı; oyuncunun seçtiği süre ve ürüne bağlı parti sistemi benimsendi. Aynı ürün farklı slotlarda üretilebiliyor.
- Son ürün slotta korunuyor; araştırma, tesis seviyesi ve hammadde koşulları sunucunun üretim teklifine bağlanıyor.
- İşçilik maliyeti temizlendi; arka plan tamamlamalarının saatlik güvence ile istemcideki süre takibinden ayrı ele alınması kararlaştırıldı.
SonuçMayıs dönemindeki sürekli üretim kararı tarihsel bir aşama olarak kaldı. Güncel yön, oyuncunun üretim partisini başlatıp biten ürünü şehir deposuna topladığı sistem.
27–30 Eylül 2026
Bölüm 18 · İnşaat ve kapasite
İki inşaatçı, tek harita ve ölçülebilir depo hacmi
Kurulum ve yükseltme kuralları, harita üzerindeki gerçek bina yerleşimiyle birleşti. Başlangıcı gereksiz yere bekleten süreler ve anlaşılması güç kapasite değerleri yeniden değerlendirildi.
Karşımıza çıkan sorunlar
- Tek aktif inşaat varsayımı yeni büyüme akışını kısıtlıyordu.
- Depo miktarıyla depo hacmi karıştığında farklı ürünlerin kapladığı alan doğru anlatılamıyordu.
- Harita sürümleri ve eski kurulum parametreleri tek harita kararıyla uyuşmuyordu.
Ne denedik?
- İki inşaatçının aynı anda kullanımını ve yol/yerleşim şartlarını ortak kurallara bağladık.
- Depo başlangıç kapasitesi ve yükseltme eğrisini ürünlerin m³ hacmi üzerinden yeniden belirledik.
Çözüm / alınan karar
- Başlangıçta iki inşaatçı kullanılabiliyor; yükseltme sürerken işletmenin çalışması korunuyor.
- Genel depo 2.000 m³ ile başlıyor; kapasite miktar saymak yerine ürün hacimleriyle izleniyor.
- İlk mağaza ve ilk depo için 10 saniyelik başlangıç süresi kararı alındı; sonraki kurulumlar kendi katalog kurallarını kullanıyor.
Sonuçİlk şirketi kurma akışı hızlandı. Yol, çakışma, kapasite ve inşaatçı uygunluğu sunucu kuralları olarak korunuyor; kapsamlı kurulum kontrolleri sonraki modül denetiminde yapıldı.
30 Eylül – 1 Ekim 2026
Bölüm 19 · Ticaret ve ekonomi
Tek sepette farklı şehirler, tek araçta ortak rota
Birden fazla şehirden alışveriş için her teslimata ayrı araç seçtirmek oyuncuyu yoruyordu. Aynı dönemde ürün fiyatlarını değişken tutarken bina maliyetlerinin öngörülebilir kalması gerektiği netleşti.
Karşımıza çıkan sorunlar
- Şehir başına ayrı satın alma ve araç seçimi, tek alışverişi birçok küçük işleme bölüyordu.
- Ürün enflasyonunu bina maliyetlerine taşımak büyüme planını belirsizleştiriyordu.
- Şehir katsayıları aynı ürün için anlaşılması zor farklar yaratıyordu.
Ne denedik?
- Farklı şehirlerdeki satıcıları tek sepette birleştiren, durakları sunucunun planladığı rota modeli seçildi.
- Fiyat değişiminin sıklığı ve kapsamı ayrı ayrı değerlendirildi.
Çözüm / alınan karar
- Çok şehirli sepet ve bir aracın şehirleri sırayla ziyaret ettiği taşıma yapısı geliştirildi.
- Ürün fiyatlarının günlük en fazla %1 hareket etmesi; bina ve yükseltme nakit maliyetlerinin sabit kalması kararlaştırıldı.
- Şehirlerin fiyat/popülasyon çarpanları kaldırıldı. Mesafe, süre ve araç gideri lojistik kararının parçası olarak kaldı.
SonuçAlışverişte tek sepet ve tek teslimat planı öne çıktı. Çok duraklı ve kiralık araç senaryolarının bütün cihaz kontrolleri sonraki lojistik denetiminde ele alınacak.
1–4 Ekim 2026
Bölüm 20 · Kapsam ve çalışma biçimi
Yeni özelliklerden modül modül tamamlama dönemine
Sistemler çoğaldıkça yeni fikir eklemek, var olan akışları bitirmekten daha kolay hale gelmişti. Çalışmayı yayın öncesi eksiklerin kapatıldığı bir sıraya bağladık.
Karşımıza çıkan sorunlar
- Ekranın bulunması, arkasındaki işlemin ve hata durumlarının tamamlandığı anlamına gelmiyordu.
- Her modüle aynı anda dokunmak açık işleri ve test durumunu takip etmeyi zorlaştırıyordu.
- Görsel yenileme, veri doğruluğu ve stok/para sorunlarının önüne geçebiliyordu.
Ne denedik?
- Modüller için backend, görünür aksiyonlar, GameState bağlantısı ve doğrulama başlıkları çıkarıldı.
- Yaklaşık tamamlanma oranlarının kalan süre ya da kesin başarı göstergesi olmadığı açıkça kaydedildi.
Çözüm / alınan karar
- Mevcut kapsamı tamamlama kararı alındı; yayın ve işletim işleri sıranın sonuna taşındı.
- Para/stok kaybı, hesaplar arası veri karışması ve giriş engelleri ana sırayı beklemeden ele alınacak.
- Kozmetik tasarım düşük öncelikte; doğru veri, çalışan işlem ve erişilebilir düğmeler öncelikte kalacak.
SonuçModül kapanışı artık bütün cihaz senaryolarının tamamlandığı anlamına gelmiyor. Ertelenen kontroller kayıtta açık tutuluyor; 6 Ekim kararıyla gerçek cihaz testleri sonraya bırakıldı.
5–6 Ekim 2026
Bölüm 21 · Holding, profil ve sohbet
Şirketin değeri ile oyuncunun kimliğini ayırmak
Holding, profil, sıralama ve sohbet birbirine bağlı görünse de farklı veri ve yetki sınırları taşıyordu. Bu modüller hem gösterilen değerler hem eksik kullanıcı aksiyonları açısından incelendi.
Karşımıza çıkan sorunlar
- Şirket değeri kırılımında varlık ve borçların görünümü tutarlı değildi; ham altının değerlemeye etkisi istenmiyordu.
- Profil ile şirket pencerelerinin görevleri karışıyordu.
- Yoğun sohbette iki yenileme arasındaki mesajlar atlanabiliyordu.
Ne denedik?
- Varlık/borç kırılımı ve marka kuralları backend sonuçlarıyla karşılaştırıldı.
- İki yenileme arasında 60 yeni mesaj, aynı zaman damgası ve ara sorgu hatası senaryoları denendi.
Çözüm / alınan karar
- Ham ALTIN şirket değerlemesinden çıkarıldı; varlık ve eksi borç kırılımı genişletildi.
- Profil ve holding pencereleri ayrıldı; avatar, herkese açık oyuncu profili ve şehir/Türkiye sıralama sayfalaması tamamlandı.
- Ticaret kanalına aktif ilan paylaşımı eklendi; mesaj boşlukları ara sayfalarla kapatılıyor. Kanal veya hesap değişiminde eski cevaplar eleniyor.
SonuçAna geliştirmeler kapatıldı; cihaz doğrulaması açık. Mesaj şikâyeti arayüzü, ürün kartından güncel ilana geçiş ve özel mesaj bildirimi sonraya bırakıldı.
6 Ekim 2026
Bölüm 22 · Üretim ve mağaza fiyatı
%100 kâr neden +50 görünüyordu?
Mağaza fiyat ekranındaki yüzdeyle slot kartındaki yüzde aynı şeyi ölçmüyordu. Üretim hazırlığında da stok değişse bile eski teklif ekranda kalabiliyordu. İki sorunun ortak noktası, karar verirken gösterilen verinin güvenilirliğiydi.
Karşımıza çıkan sorunlar
- Maliyete göre kâr ile satış fiyatına göre marj aynı etiket altında gösteriliyordu.
- Bağımsız fiyat kısa yolları piyasa ve kalite/marka etkisini yeterince açıklamıyordu.
- Açık üretim teklifinin eski stok veya tesis seviyesine dayanması yanlış başlatma izni gösterebiliyordu.
Ne denedik?
- Maliyeti 100, satış fiyatı 200 olan ürünün maliyete göre %100 kâr, satışa göre %50 marj verdiği ayrıştırıldı.
- Üretim teklifi stok, tesis, kalite, marka, vergi ve hesap değişimlerine bağlandı.
Çözüm / alınan karar
- Kart, yönetim penceresi ve fiyat klavyesi maliyete göre aynı kâr yüzdesini kullanıyor; yüzde kısa yolları kaldırıldı.
- Önerilen fiyat sunucunun piyasa/kalite/marka referansından geliyor. Şehirde aynı ürün ve kalitedeki en düşük beş mağaza teklifinin fiyatı, stoğu, oyuncusu ve markası gösteriliyor; marka ayrı filtre değil.
- Hammadde ihtiyacı, dört saatlik üretim miktarı ve eksik stok sunucu teklifinden gösteriliyor. Yenileme/hata sırasında eski teklif işlem izni vermiyor.
- Madenler doğrudan ham petrol tüketiyor; önceki yakıt girdisi kararı değiştirildi. Toplama sırasında tekrar basma ve tekli/toplu toplama çakışması engellendi.
SonuçFiyat ve üretim kararı daha tutarlı hale geldi. Eski test beklentileri ve liderlik başlık taşması da düzeltildi; bu dönemin sonunda genel Flutter test paketi yeniden başarılı çalıştı.
6–7 Ekim 2026
Bölüm 23 · İnşaat ve yükseltme denetimi
Başarılı cevap yetmez: tamamlanma olayı da doğru olmalı
İnşaat ve yükseltmeler yalnız ücret ve süre açısından değil, tekrar istek ve kaybolan cevap sonrasında da incelendi. Yedi bina türü ve 34 kurulum tipi üzerinde geri alınan testler yapıldı.
Karşımıza çıkan sorunlar
- Bazı tamamlama yollarında kilit sırası ters olduğundan eşzamanlı işlemler kilit döngüsüne girebilirdi.
- İlk cevap doğru olsa bile saklanan tamamlanma olayı görev ve son durum güncellemelerini eksik taşıyabiliyordu.
- Beş slotlu mağaza son yükseltmede altıncı slot vaat edip oluşturabiliyordu.
- Ücret görünmeden hızlandırma yapmak ve dört çeşit yükseltme malzemesi istemek gereksiz belirsizlik yaratıyordu.
Ne denedik?
- Başlatma, ücretli bitirme ve otomatik tamamlama yollarının kilit sırası ortaklaştırıldı.
- Ücretli/ücretsiz bitirme, yetersiz bakiye, işlem hatası, tekrar tamamlama ve olay-cevap eşleşmesi test edildi.
Çözüm / alınan karar
- Tamamlama cevapları ve kayıtlı olaylar son canonical değişiklikleri taşıyor; tekrar çağrı ikinci para, altın veya XP hareketi yapmıyor.
- Mağaza slotları en fazla beş; eski yükseltme parametreleri de bu sınırla tamamlanıyor.
- Yükseltmeler en fazla üç malzeme çeşidi istiyor; ilk 1→2 yükseltmede malzeme gerekmiyor.
- Ücretli bitirmede bedel ve onay görünür. Google demo reklamı bağlandı; demo izlemek oyun süresini değiştirmiyor.
SonuçKurulum ve yükseltmenin ana denetimi tamamlandı. Gerçek reklam ödülü için AdMob birimi ve sunucu doğrulaması ayarı hâlâ gerekli; yoğun eşzamanlı yük ve cihaz kontrolleri tamamlanmış sayılmıyor.
7 Ekim 2026
Bölüm 24 · Ticaret merkezi
15 ilan sınırı ve eski cevapların yeni seçimi ezmesi
Ticaret ekranı çok veri gösteriyordu; ürün değişimi, sayfalama veya hesap geçişinde eski bir cevap yeni seçimin üzerine yazabiliyordu. Listeyi ve sepeti hem daha okunabilir hem daha güvenilir hale getirdik.
Karşımıza çıkan sorunlar
- Sınırsız ilan listesi kalabalıktı; satıcı şehri tek başına teslimat mesafesini anlatmıyordu.
- Geç gelen ürün, ilan veya teklif cevabı güncel seçimi bozabiliyordu.
- Hesap değişiminde önceki sepet, araç ve teklifin kalması yanlış işlem riski taşıyordu.
Ne denedik?
- Ürün/kalite/sayfa ve hesap nesli değişimlerini gecikmiş cevaplarla test ettik.
- Amaç filtreleri, kalite seçimi ve teslimat özetini mevcut sistemler üzerinden sadeleştirdik.
Çözüm / alınan karar
- Tümü, Mağaza ve Üretim filtreleri kullanılıyor; satışta veya ihtiyaç olan ürünler öncelikli. Q1–Q5 seçimi, arama ve sepette miktar düzenleme destekleniyor.
- Toptancı normal oyuncuyla aynı ilan kartında görünüyor. Aynı anda en fazla 15 ilan var: Toptancı varsa 14 oyuncu ilanı + 1 Toptancı.
- İlan mesafesi hedef depo şehrine göre sunucudan geliyor; eksik mesafe 0 km diye gösterilmiyor.
- Sayfa geçişi sepeti koruyor; hesap değişimi temizliyor. Eski cevaplar eleniyor, işlem sırasında sepet kilitleniyor; başarısız satın alma sepeti silmiyor.
SonuçKarma sepet, yerel teslimat ve yeni controller/widget kontrolleri geçti. Çok duraklı/kiralık lojistiğin ayrıntılı senaryoları ve gerçek cihaz akışı açık kalıyor.
7 Ekim 2026
Bölüm 25 · Lojistik
Teslimat tamamlandı, ürün neden görünmüyor?
Hızlandırılan sevkiyat tamamlandı mesajı verdiği halde depoda ürün görünmüyordu; oyun yeniden açılınca stok geliyordu. Önce gerçek ürün kaybı ile istemci güncelleme sorunu ayrıldı.
Karşımıza çıkan sorunlar
- Teslimat olayındaki depo güncellemesi yalnız bazı alanları taşıyordu; satırı yeniden kuran tüketici ürün ve kalite kimliğini kaybedebilirdi.
- Altın/reklam değişikliği dış cevapta bulunurken saklanan tamamlanma olayıyla eşleşmeyebiliyordu.
- Hızlandır butonu harcanacak altını ve anında teslimat sonucunu açık göstermiyordu.
Ne denedik?
- Backend stoğu ve olay-cevap içeriği karşılaştırıldı; bildirilen vakada ürünün kaybolmadığı doğrulandı.
- Altınla, sunucu doğrulaması hazırlanmış reklam fixture'ıyla ve normal tamamlamayla stok/olay/tekrar testleri yapıldı.
Çözüm / alınan karar
- Teslimat depo güncellemesi ürün, kalite, marka ve miktarı birlikte taşıyan tam slot verisini döndürüyor.
- İlk başarılı hızlandırmanın son değişiklik paketi olay kaydı ve makbuzuyla eşleştiriliyor.
- Buton altın bedelini gösteriyor; onayda anında tamamlama açıklanıyor. Sunucu onaylanan üst tutarı aşan ücreti kesmeden reddediyor.
SonuçBackend ve GameState regresyonları geçti; yeni hızlandırmayı gerçek cihazda anında görme kontrolü henüz yapılmadı. Reklam fixture testi gerçek reklam gösterimi değildir; geçmiş olaylar otomatik yeniden yazılmadı.
7 Ekim 2026
Bölüm 26 · Marka filigranları
Köşe ikonu yerine ürünün üzerine oturan çerçeve
Marka sayfasında filigran olarak ikonlar kullanılıyordu. Oysa hazırlanmış filigran görselleri ürünün kenarında duran rozet değil, görselin tamamına yerleşen çerçevelerdi.
Karşımıza çıkan sorunlar
- Filigran seçimi marka logosu ikonlarıyla karışmıştı.
- Önizleme ve ürün kartları aynı çerçeve davranışını paylaşmıyordu.
Ne denedik?
- Storage ve asset manifestindeki filigran1.webp–filigran10.webp dosyaları doğrulandı.
- Kayıt, kaldırma, geçersiz dosya adı ve ürün kartındaki yerleşim kontrolleri yapıldı.
Çözüm / alınan karar
- Filigran kataloğu logo ikonlarından ayrıldı; seçim, önizleme ve ürün kartları ortak bileşen kullanıyor.
- Çerçeve özgün renk ve şeffaflığıyla ürün alanının tamamına oturuyor; kalite/miktar rozetleri görünür ve dokunma davranışı korunuyor.
- Önbellek ve Storage erişimi ortaklaştırıldı; backend yalnız geçerli çerçeve kimliklerini kabul ediyor.
SonuçKod analizi ve testler geçti. Eski ikon seçimleri kendiliğinden yeni çerçeveye çevrilmiyor; oyuncunun yeniden seçmesi gerekiyor. Yeni APK ve cihazda görsel kontrol bekleniyor.
7 Ekim 2026
Bölüm 27 · Banka ve AR-GE
Ekranın hesapladığı değil, sunucunun teklif ettiği değer
Faiz, getiri, araştırma süresi ve ücret gibi kararı etkileyen verilerin istemcide ayrı hesaplanması tutarsızlık yaratıyordu. Banka ve AR-GE teklifleri sunucu hesaplarıyla birleştirildi.
Karşımıza çıkan sorunlar
- Kredinin son taksitinde birkaç kuruş borç kalabildiği halde kredi ödenmiş sayılabiliyordu.
- Sorgu hatasında örnek limit veya eski teklif göstermek işlemi yanlış yönlendirebiliyordu.
- Araştırma geçmişi hatası boş geçmiş gibi görünebiliyor; manuel tamamlama çağrısında eksik parametre bulunuyordu.
Ne denedik?
- Kredi/mevduat/vergi için tutar sınırları, vade, tekrar ödeme ve sahiplik test edildi.
- Araştırmanın önkoşulları, ücret/süre, ücretsiz/ücretli bitirme ve geçmiş yenilemesi denetlendi.
Çözüm / alınan karar
- Faiz, taksit, getiri, limit ve erken bozma bedeli backendden geliyor. Son taksit kalan borcun tamamını kapatıyor.
- Hatalı teklif işlem izni vermiyor; hesap değişiminde eski banka ve araştırma cevapları eleniyor.
- AR-GE üretimde kullanılan ürünleri ve hammaddelerini öne alıyor; eksik kalite önkoşuluna doğrudan geçiş var. Araştırma tamamlanınca depodaki ürün ve çalışan sipariş kalitesi kendiliğinden değişmiyor.
- Manuel tamamlama doğru RPC parametresi ve ilgili işin tamamlanma onayıyla değerlendiriliyor; hata ile boş geçmiş ayrıldı.
SonuçAna geliştirmeler ve otomatik kontroller tamamlandı. Gerçek cihaz, uzun vadeli finans senaryoları ve araştırmadan sonra üretim kalitesi seçimi kontrolleri açık tutuluyor.
7 Ekim 2026
Bölüm 28 · Ortak pencereler ve HUD
Doğru pencereyi açmak, doğru depoyu göstermek
Ortak arayüz denetiminde renklerden çok işlevi engelleyen ölçü ve yönlendirme sorunlarına odaklandık. HUD'da yanlış şehir veya hesap deposunu seçmek görsel bir kusurdan daha önemliydi.
Karşımıza çıkan sorunlar
- Açık pencereye başka sekme isteği gönderilince önceki sekme kalabiliyordu.
- Dar alanlarda ihale kontrolleri ve sepet satırları taşabiliyordu.
- Depo yüklenmeden eksik kapasite görünmesi veya uygun depo yokken başka şehrin deposuna düşülmesi mümkündü.
Ne denedik?
- Pencere ölçüleri, açık pencereye yönlendirme ve kapanış sırasında eski içeriğe dokunma kontrol edildi.
- Depo HUD'ı şehir, sahiplik, yükleme ve canonical stok değişimleriyle test edildi.
Çözüm / alınan karar
- Açık pencere doğru sekmeye yönleniyor; kapanan içerik yeni dokunuş almıyor. Ortak ölçü, güvenli alan ve kapatma erişimi düzeltildi.
- İhale kontrolleri ve sepet satırları kullanılabilir biçimde kaydırılıyor/sarılıyor.
- Depo HUD'ı yalnız oyuncunun merkez şehrindeki kendine ait aktif genel depoyu seçiyor; yükleme tamamlanmadan kapasite gösterilmiyor.
SonuçDoğrulanan işlevsel sorunlar giderildi ve depo modülüne geçildi. Özel pencerelerde dar alan/klavye, büyük yazı, çentik ve açık pencere hesap değişimi kontrollerinin tümü tamamlanmış sayılmıyor.
7 Ekim 2026
Bölüm 29 · Depo ve stok
Uzun basma menüsü, kapasite sınırı ve tekrar teslimat
Depo denetiminde yalnız ürün kartına değil, ürünün ne zaman mevcut sayıldığına ve aynı işlemin tekrarının ne yaptığına bakıldı. Ürün işlemleri uzun basma menüsünde toplandı.
Karşımıza çıkan sorunlar
- Yükleme sırasında stok yokmuş gibi görünmesi, bekleyen hacmin eksik sayılması ve eski ürün adı/görselinin yeni ürüne taşınması sorunları vardı.
- İmha işlemi onaysız veya eski stok bilgisiyle çalışmamalıydı.
- Sıfır maliyetli ürünün kayıtlı satış fiyatı yanlışlıkla Maliyet etiketi altında gösterilebiliyordu.
Ne denedik?
- İmha, sahiplik, bekleyen miktar, hesap değişimi ve canonical silme patchi test edildi.
- Tam dolu depo, tam sınırda toplama, ilk teslimat, rezervasyon dönüşümü, kalite/marka ayrımı ve ağırlıklı maliyet geri alınan transactionlarda kontrol edildi.
Çözüm / alınan karar
- Uzun basınca onaylı imha ve Sevk Et menüsü açılıyor; header'daki sevkiyat düğmesi kaldırıldı. Eski onay geçersizleşiyor, işlem sırasında tekrar gönderim engelleniyor.
- Fiziksel + bekleyen hacim ve ayrılmış kapasite doğru sayılıyor; yükleme, boş depo ve bulunamadı durumları ayrılıyor. Ürün/marka değişince eski metadata temizleniyor.
- Sıfır maliyet gerçek değeriyle gösteriliyor; satış fiyatının ondalık kısmı kesilmiyor.
- Dolu depoda üretim toplama siparişi toplanmış işaretlemiyor. İlk teslimat stok ve rezervasyonu doğru değiştiriyor; tekrar toplama/teslimat stok veya XP çoğaltmıyor.
SonuçKod analizi ve Flutter testleri geçti; SQL denemelerinin bütün geçici değişiklikleri geri alındı. Depo modülü sürüyor: depo satma/silme ve diğer stok tüketim yolları sırada. İlk teslimat testi geçici kayıtta yapıldı; gerçek araçlı çok duraklı rota ve cihaz kontrollerinin tamamlandığı iddia edilmiyor.
8–9 Ekim 2026
Bölüm 30 · Oturum ve üretim güvenilirliği
Oyuncu değişince eski işlemler geride kalmalı
Üretim, banka, depo ve lojistik ekranları hesap geçişi, gecikmiş cevap ve tekrar işlem açısından birlikte ele alındı. Amaç, ekranın doğru görünmesinden önce para ve stok değişimlerinin doğru oyuncuya uygulanmasıydı.
Karşımıza çıkan sorunlar
- Hesap değişiminden sonra dönen eski bir cevap yeni oturumun ekranını veya oyun durumunu etkileyebiliyordu.
- Başarısız üretim ve toplama işlemleri her ekranda yeterince açık gösterilmiyordu.
Ne denedik?
- Bekleyen işlemler, geç gelen cevaplar, üretim toplama ve tamamlanma olaylarının tekrarları için kontroller genişletildi.
- Üretim hazırlığında hammadde, maliyet ve sonuç bilgileri daha okunabilir bir akışta toplandı.
Çözüm / alınan karar
- Pencere ve işlem cevapları oturum kimliğiyle ilişkilendirildi; eski oturuma ait sonuçların uygulanması engellendi.
- Üretim başlatma ve toplama sonucunun doğrulanması güçlendirildi; reddedilen işlemler kullanıcıya aktarılıyor.
SonuçYeni geliştirme önceliği mevcut akışların güvenilirliği oldu. Otomatik senaryolar gerçek cihazda uzun süreli oynama testinin yerine geçmiyor.
9 Ekim 2026
Bölüm 31 · Görevler ve ilerleme
Görevleri yeniden yazmak, ödülleri dengelemek
Görev tanımları ve ödülleri yeniden ele alındı. Başlangıçta çok yüksek ödül veren adımlar, eksik açıklamalar ve birbirine karışan ilerleme hedefleri sadeleştirildi.
Karşımıza çıkan sorunlar
- Bazı erken görev ödülleri başlangıç ekonomisine göre fazla yüksekti.
- Görev açıklamaları ve önkoşullar oyuncuya yeterince açık görünmüyordu.
Ne denedik?
- Ana görevler, günlük görevler, günlük giriş ödülleri ve başarı aşamaları birlikte değerlendirildi.
- Görev ilerlemesinin doğru döneme yazılması ve ödül önkoşulları kontrol edildi.
Çözüm / alınan karar
- Haftalık görevler kaldırıldı; günlük görevler dört görevle sınırlandı.
- Günlük satış hedefi 100, üretim hedefi 200 ve tedarik hedefi 100 ürün olarak dengelendi.
- Görev açıklamaları ve önkoşul kilitleri görünür hale getirildi; giriş ödülleri ve başarı aşamaları yeniden düzenlendi.
Sonuçİlerleme sistemi daha anlaşılır bir hedef dizisine dönüştü. Ödüllerin ve hedeflerin günlük oynama temposuna etkisi cihaz testlerinde izlenecek.
9–12 Ekim 2026
Bölüm 32 · Kalite ve marka dengesi
Üç kalite seviyesi, daha ölçülü marka bonusları
Beş kalite seviyesi üçe indirildi. Ardından kalite ve markanın üretim, satış talebi ve fiyat üzerindeki etkileri ayrı ayrı dengelendi.
Karşımıza çıkan sorunlar
- Beş kalite seviyesi ürün seçimini ve fiyat karşılaştırmasını gereğinden fazla parçalı hale getiriyordu.
- Kalite ve marka bonuslarının üst üste eklenmesi ekonomide aşırı avantaj yaratabiliyordu.
Ne denedik?
- Backend, GameState, patch verileri ve kalite gösteren ekranlar birlikte güncellendi.
- Üretim miktarı, fiyat ve satış talebi için ayrı kalite çarpanları belirlendi.
Çözüm / alınan karar
- Q1/Q2/Q3 üretim ve fiyat çarpanları 1,00 / 1,20 / 1,40; satış talebi çarpanları 0,80 / 1,00 / 1,20 oldu.
- Marka seviyesi bonusu seviye başına %5 artacak şekilde düzenlendi; reklam kampanyalarının etkileri azaltıldı.
- Patent için Q3 şartı getirildi ve markalı üretim Q3 ile ilişkilendirildi. Patent ücretleri ürünün baz fiyatına göre hesaplanıyor.
SonuçKalite ve marka daha kontrollü ekonomik avantajlar sunuyor. Bu değişikliklerin uzun vadeli kârlılığa etkisi oynama testleriyle değerlendirilecek.
10 Ekim 2026
Bölüm 33 · Veritabanı bakımı
Geçmişi sınırlarken oyuncunun emeğini korumak
Oyuncu sayısı arttıkça büyüyebilecek işlem ve istatistik tabloları incelendi. Eski kayıtları temizlerken tekrar işlem güvenliği ve oyuncunun ömür boyu ilerlemesi korunmaya çalışıldı.
Karşımıza çıkan sorunlar
- Para, vergi, altın, üretim ve lojistik geçmişinin sınırsız birikmesi bakım yükünü artırıyordu.
- Geçmişi doğrudan silmek toplam satış ve üretim ilerlemesini kaybettirebilirdi.
Ne denedik?
- Kullanılmayan kayıtlarla işlem güvenliği için gerekli veriler ayrıldı.
- Temizleme öncesinde toplam ilerleme değerleri ve devam eden işlem bağlantıları kontrol edildi.
Çözüm / alınan karar
- Gereksiz işlem yanıtı önbelleği ve kullanılmayan deneyim geçmişi kaldırıldı.
- Para, vergi, altın, tamamlanmış üretim, lojistik, hata ve reklam kullanım geçmişleri için sınırlı saklama düzenleri kuruldu.
- Günlük istatistiklerde 30 günlük pencere kullanılırken ömür boyu satış ve üretim toplamları korunuyor.
- İhale teslimatını başlatırken oluşan fonksiyon erişim hatası düzeltildi.
SonuçVeri büyümesi için düzenli temizlik kuralları eklendi. Aktif işlemler ve kalıcı ilerleme, kısa süreli geçmiş kayıtlarından ayrı tutuluyor.
10–11 Ekim 2026
Bölüm 34 · Sepet ve sevkiyat
Sepete sığan ürün, rotaya uygun araç
Ticaret sepeti ve teslimat özeti sadeleştirildi. Araç seçimi tek bir şehir aralığından ziyade sepetin bütün rotası ve yükü üzerinden değerlendiriliyor.
Karşımıza çıkan sorunlar
- Sepetteki miktarın depo kapasitesi veya nakit sınırını aşması satın alma sonunda sorun yaratıyordu.
- İlk araç listesi, çok duraklı rotanın tamamına uygun seçenekleri yeterince iyi ayırmıyordu.
Ne denedik?
- Miktar onayı, canlı depo kapasitesi ve ödeme özeti birlikte ele alındı.
- Araçların kapasite, yakıt ve bakım yeterliliği bütün rota için hesaplandı.
Çözüm / alınan karar
- Miktar onayından sonra ürün sepete ekleniyor; kapasite ve bakiye sınırları seçim sırasında dikkate alınıyor.
- En fazla beş uygun araç sunuluyor; kullanılamayan kişisel araçların nedenleri ayrı bilgi olarak gösteriliyor.
- Teslimat özeti ve sevkiyat ayrıntıları rota, yük ve ödeme bilgileri etrafında sadeleştirildi.
SonuçSatın alma öncesinde görülen bilgi ile gerçek teslimat koşulları daha tutarlı hale geldi. Çok duraklı taşımanın cihazdaki kullanım deneyimi test edilmeye devam edecek.
11–12 Ekim 2026
Bölüm 35 · Mağaza tedariki ve ürün kimliği
Reyonu doğrudan doldurmak, markayı doğru göstermek
Mağaza tedarikinde gereksiz adımlar azaltıldı. Aynı şehirdeki uygun satıcılardan ürün doğrudan reyona alınabiliyor; marka çerçeveleri de sonradan genişletilebilen bir kataloğa taşındı.
Karşımıza çıkan sorunlar
- Reyon doldurmak için ticaret ve depo ekranları arasında gidip gelmek gerekiyordu.
- Tek hızlı alım teklifi oyuncunun seçenekleri karşılaştırmasını zorlaştırıyordu.
- Ürün görseli dosya adı üzerinden kimlik çözmek ortak görsel kullanan ürünleri karıştırabiliyordu.
Ne denedik?
- Hızlı alımda satıcı fiyatı, stok, ürün kalitesi ve marka eşleşmesi birlikte kontrol edildi.
- Filigran listesi ve ürün kartlarındaki marka gösterimi ortak katalog üzerinden ele alındı.
Çözüm / alınan karar
- Hızlı alımda en fazla üç uygun satıcı seçilebiliyor; aynı şehirden alınan ürün doğrudan reyona ekleniyor.
- Dolu reyona ekleme aynı ürün, kalite ve marka ile sınırlandı. Stoğu bitmiş reyon yeniden doldurulunca satış fiyatı yeni alış maliyetinin %10 üzerinde ayarlanıyor.
- Filigran çerçeveleri dinamik asset kataloğundan yükleniyor; yeni çerçeveler katalog üzerinden eklenebiliyor.
- Ürün kimliği görsel dosyasından önce çözülüyor. Sohbet şehir adları katalogdan geliyor ve Türkçe kanal başlıkları korunuyor.
SonuçMağaza tedariki daha kısa bir akışa dönüştü; ürün, marka ve görsel eşleşmeleri güçlendirildi.
12 Ekim 2026
Bölüm 36 · İlk oyuncu deneyimi
İki bina kurduktan sonra yalnızca beklemek yetmiyor
Başka bir cihazda sıfırdan başlamak, ilk depo ve mağazadan sonra oyuncunun satış beklemek dışında pek seçeneği kalmadığını gösterdi. Üretime geçiş hem para hem seviye şartıyla engelleniyordu.
Karşımıza çıkan sorunlar
- 60.000 TL başlangıç sermayesi depo, mağaza ve üretim döngüsünü birlikte karşılamıyordu.
- 1. seviyede hiçbir üretim işletmesi açılamıyordu; Manav ile uyumlu Sebze Tarlası 4. seviye ve 120.000 TL istiyordu.
- Şehir onayından sonraki piyasa yüklemesi eksik fonksiyon izni nedeniyle hata veriyordu.
Ne denedik?
- Başlangıç mağazasıyla uyumlu üretim işletmesi birlikte değerlendirildi.
- Şehir seçimi hatası sunucu loglarından izlendi ve oyuncu rolüyle yeniden denendi.
Çözüm / alınan karar
- Sebze Tarlası 1. seviyeye ve 30.000 TL kurulum bedeline indirildi.
- Büfe 2. seviyeye ve 30.000 TL kurulum bedeline çıkarıldı; ilk seviyede Manav + Sebze Tarlası yolu açıldı.
- Yeni oyuncuların başlangıç parası 150.000 TL oldu. Depo, Manav ve tarla bina bedellerinden sonra 70.000 TL işletme sermayesi kalıyor.
- Altı adımlı ilk açılış rehberi eklendi. Şehir onayının ardından piyasa yüklemesini engelleyen erişim sorunu giderildi.
SonuçYeni başlangıç üretim ve satışla birlikte ilerlemeye daha uygun. Sermaye değişikliği mevcut hesapların bakiyesini değiştirmiyor; gerçek başlangıç temposu cihazda değerlendirilecek.
12 Ekim 2026
Bölüm 37 · İhale geçmişi ve cihaz testi
Kayıt vardı, ekran geçmişi gizliyordu
İhale geçmişinin sürekli boş görünmesi araştırıldı. Backend ana test hesabında yedi geçmiş sözleşme döndürüyordu; istemci bu listeyi yalnız canlı sözleşmelerin bulunduğu GameState tablosuyla değiştiriyordu.
Karşımıza çıkan sorunlar
- Aktif sözleşme tablosunda bulunmayan geçmiş kayıtlar ekranda kayboluyordu.
- Kod ve otomatik kontroller, sıfırdan oynarken karşılaşılan bütün deneyim sorunlarını göstermiyordu.
Ne denedik?
- Backend cevabı ve istemcinin listeyi oluşturma yolu karşılaştırıldı.
- Boş canlı tablo yanında geçmişin korunması ve aynı sözleşmenin güncel durumla birleştirilmesi için regresyon testleri eklendi.
Çözüm / alınan karar
- Sunucudan alınan geçmiş korunuyor; canlı sözleşmeler aynı kimlikteki kayıtları güncelliyor ve tekrar kayıt oluşturmuyor.
- Geçmiş en yeni kayıtlar önce olacak şekilde sıralanıyor; son on sözleşme sınırı korunuyor.
- Önümüzdeki test dönemi için iki cihazda sıfırdan oynayıp hataları ve bekleme sürelerini not etme planı benimsendi.
SonuçFrontend düzeltmesi kod deposuna kaydedildi ve yeni APK gerektiriyor. Eklenen Flutter testleri bu düzeltmenin yapıldığı ortamda Flutter bulunmadığı için çalıştırılmadı; cihaz doğrulaması açık tutuluyor.
