Godot 4.7 Sürüm İncelemesi: Mimari Yenilikler, Geliştirici Ekosistemi ve Üretim Standartları
Açık kaynaklı oyun motoru ekosisteminin en önemli ve yenilikçi temsilcilerinden biri olan Godot, 18 Haziran 2026 tarihinde yayınlanan 4.7 kararlı sürümü (stable release) ile birlikte mimari esneklik, grafiksel doğruluk ve geliştirici ergonomisi bağlamında kritik bir olgunluk seviyesine ulaşmıştır 1. Önceki sürümler motorun temel sistemlerinin stabilizasyonuna ve çekirdek hataların giderilmesine odaklanırken, 4.7 sürümü doğrudan üretim aşamasındaki profesyonel stüdyoların ve bağımsız geliştiricilerin günlük iş akışlarında karşılaştıkları darboğazları çözmeyi hedefleyen "üretim ve iş akışı odaklı" bir yapı sergilemektedir 3. 18 Ağustos 2026 tarihinde yayınlanan 4.7.2 bakım güncellemesi ile birlikte PCSS gölge koordinatları, yüksek tarama hızına (polling rate) sahip farelerin Windows üzerindeki performansı ve çok oyunculu (multiplayer) replikasyon senaryolarındaki ufak pürüzler de giderilerek motorun üretim ortamındaki (production-ready) kararlılığı pekiştirilmiştir 5.
Godot 4.7, baştan aşağı yeni bir fizik motoru veya tamamen yeniden yazılmış bir render hattı sunmaktan ziyade; mevcut Forward+ ve Mobile render altyapılarını genişleten, kullanıcı arayüzü (UI) animasyonlarındaki kronik sorunları çözen, mobil geliştirme süreçlerini standartlaştıran ve Yüksek Dinamik Aralık (HDR) gibi modern donanım gereksinimlerini karşılayan derinlemesine bir iyileştirme paketidir 2. Topluluk ve endüstri profesyonelleri tarafından yapılan değerlendirmelerde, özellikle uzun yıllardır farklı kapalı kaynaklı motorları (örneğin Unity) kullanan geliştiricilerin Godot 4.7'nin render yeteneklerinden ve hızlı prototipleme imkanlarından etkilendikleri görülmektedir 2. Bu rapor, Godot 4.7'nin sunduğu teknik yenilikleri, bu yeniliklerin yazılım mimarisi üzerindeki etkilerini, topluluk geri bildirimlerini ve projelerin bu yeni sürüme geçiş süreçlerindeki stratejik değerlendirmeleri son derece kapsamlı bir analitik çerçevede incelemektedir.
Render Motoru ve 3D Grafik Altyapısındaki İnovasyonlar
Grafik işleme hattı, Godot 4.7'nin en belirgin ilerleme kaydettiği alanların başında gelmektedir. Modern oyun geliştirmede fotogerçekçilik ve performans optimizasyonu arasındaki hassas denge, render motorunun sunduğu araçların çeşitliliğine ve donanımsal ivmelendirme kapasitesine bağlıdır. Yeni sürüm, ışıklandırma hesaplamalarından materyal yönetimine kadar birçok katmanda endüstri standartlarını yakalayan analitik özellikler sunmaktadır.
Alan Işıkları (AreaLight3D) ve Işıklandırma Fiziği
Işıklandırma modelleri, 3D render motorlarının görsel inandırıcılığını belirleyen en temel unsurdur. Godot 4.7 öncesinde, geliştiriciler dikdörtgen veya geniş yüzeyli ışık kaynaklarını (örneğin; neon tabelalar, devasa endüstriyel pencereler, televizyon ekranları, florasan lambalar veya yumuşak stüdyo aydınlatmaları) simüle etmek için nokta ışıkları (point lights) kümelemek veya Küresel Işıklandırma (Global Illumination) ile desteklenmiş emisyonlu (emissive) materyaller kullanmak zorundaydı 1. Bu geçici ve dolaylı çözümler, hem performans açısından GPU üzerinde gereksiz bir maliyet yaratıyor hem de oluşturulan gölgelerin kenar yumuşaklığı (penumbra) ile fiziksel doğruluğu açısından yetersiz kalıyordu.
Godot 4.7 ile birlikte çekirdek düğüm mimarisine eklenen AreaLight3D düğümü, ışığın sonsuz küçüklükteki tek bir noktadan değil, sınırları belirlenmiş iki boyutlu dikdörtgen bir yüzey alanından yayılmasını sağlayan analitik bir gerçek zamanlı render çözümü sunmaktadır 1. Bu yapısal mimari, ışık kaynağının fiziksel boyutuna bağlı olarak doğal ve giderek yumuşayan gölge geçişleri üretirken, aynı zamanda sahnedeki pürüzsüz ve yansıtıcı yüzeylerde (specular reflections) ışık kaynağının dikdörtgen şeklinin doğru bir şekilde yansımasını garanti eder 1. Işın izleme (ray tracing) gerektirmeyen bu yaklaşım, performans bütçesini aşmadan sahnelerin aydınlatma kalitesini dramatik ölçüde artırmaktadır. Mimari görselleştirme, kapalı alan korku oyunları (indoor horror) ve sinematik atmosfer tasarımı açısından bu gelişme, sahne tasarımcılarına çok daha temiz bir iş akışı ve üstün bir görsel kalite sağlamaktadır.
Yüksek Dinamik Aralık (HDR) Görüntü Çıkışı Desteği
Görüntüleme teknolojilerindeki ilerlemelerle birlikte standart sRGB renk uzayının sınırlarını aşan donanımlar son kullanıcı pazarında standart hale gelmeye başlamıştır. Godot 4.7, motorun içsel olarak kayan nokta (floating point) formatında hesapladığı yüksek dinamik aralıklı ışıklandırma verisini, işletim sistemi seviyesindeki HDR API'leri aracılığıyla doğrudan desteklenen ekranlara aktarabilme yeteneği kazanmıştır 2. Teorik olarak 10.000 nit'e kadar parlaklık değerlerini destekleyen bu özellik, patlamalar, neon ışıkları, büyü efektleri veya doğrudan güneş ışığı gibi unsurların ekranda kör edici bir parlaklık, derin siyahlar ve çok daha geniş bir renk gamı (color gamut) ile sunulmasına olanak tanır 3.
HDR çıkışının desteklenmesi, donanım sürücüleri ve işletim sistemi pencere yöneticileriyle (window manager) son derece düşük seviyeli bir entegrasyon gerektirdiğinden platform ve render motoru bağımlılıkları spesifiktir. Bu özelliğin entegrasyonuna dair yapılandırma matrisi aşağıdaki tabloda detaylandırılmıştır:
İşletim Sistemi / PlatformHDR Destek DurumuGerekli Render MotoruMimari ve Entegrasyon NotlarıWindowsTam DestekliForward+ veya Mobileİşletim sistemi seviyesinde Windows HD Color ayarları açık olmalı ve uyumlu bir monitör kullanılmalıdır.macOSTam DestekliForward+ veya MobileApple'ın yerel HDR yönetim API'leri ve Metal arayüzü ile doğrudan entegredir.iOS & visionOSTam DestekliForward+ veya MobileMobil Apple cihazlarının yüksek parlaklık yetenekleri ve XDR ekran yapılarıyla uyumludur.Linux (Wayland)Tam DestekliForward+ veya MobileYalnızca modern Wayland kompozitörleri altında çalışır. Kapsamlı bir pencere yönetimi protokolü gerektirir.Linux (X11)DesteklenmiyorUygulanamazEski X11 mimarisindeki renk derinliği kısıtlamaları nedeniyle kapalıdır. Geliştiriciler Wayland'e geçmelidir.AndroidDesteklenmiyorUygulanamazGeniş Android donanım parçalanması (fragmentation) nedeniyle şu an için mevcut değildir.Web (HTML5)DesteklenmiyorUygulanamazWebGL ve WebGPU tarayıcı grafik API limitasyonları henüz HDR çıkışını standartlaştırmamıştır.
Tablodan da anlaşılacağı üzere, HDR kullanımı bütüncül bir zorunluluk (requirement) olmaktan ziyade, desteklenen platformlarda devreye giren opsiyonel bir görsel zenginleştirme katmanı olarak ele alınmalıdır 4. Geliştiriciler, HDR'ı tüm sanat yönetiminin (art direction) temeli yapmak yerine, standart dinamik aralık (SDR) üzerinde iyi görünen projeleri daha da zenginleştirecek bir cila olarak değerlendirmelidir 4.
Vulkan Donanımsal Işın İzleme (Ray Tracing) Altyapısı
Oyun endüstrisindeki en büyük teknolojik kırılma noktalarından biri olan donanımsal ışın izleme teknolojisi, Godot 4.7 ile birlikte motorun Vulkan mimarisine düşük seviyeli (low-level) bir tesisat (plumbing) altyapısı olarak entegre edilmiştir 2. Bu sürüm, oyuncuların veya geliştiricilerin tek bir tıkla aktif edebileceği "Işın İzlemeli Yansımalar" (Ray-traced reflections) veya "Yol İzleme" (Path tracing) gibi doğrudan son kullanıcı özelliklerini barındırmamaktadır 10. Bunun yerine, ışın izlemenin temel gereksinimleri olan ivmelendirme yapıları (acceleration structures) inşa etme ve Vulkan render hattı içerisinden doğrudan ışın fırlatma (ray dispatch) yetenekleri motora kazandırılmıştır 2.
Bu stratejik mühendislik hamlesi, büyük ölçekli stüdyoların kendi özel ışın izleme çözümlerini (örneğin özel ışıklandırma shader'ları veya ayna sistemleri) yazabilmeleri için standartlaştırılmış bir temel sunmaktadır. Geçmiş yıllarda donanımsal ışın izleme kullanmak isteyen ekipler, NVIDIA'nın veya bağımsız geliştiricilerin bakımını üstlendiği özel Godot RTX çatallarına (fork) bağımlı kalmaktaydı 2. 4.7 ile gelen bu çekirdek entegrasyon, Godot 4.8 ve 4.9 gibi gelecek sürümlerde yerleşik (built-in) ışın izleme özelliklerinin doğrudan ana motor (mainline) üzerinde çalışacağının kesin bir kanıtıdır 2.
DrawableTexture2D ve Çalışma Zamanı Doku İşleme
Oyun mekaniklerinde sıklıkla ihtiyaç duyulan "çalışma zamanında doku üzerine çizim yapma" (runtime texture drawing) işlemi, geçmiş sürümlerde ayrı bir Viewport oluşturarak sahneyi o viewport içerisine renderlamak veya karmaşık RenderingDevice API'leri üzerinden düşük seviyeli GPU komutları göndermek gibi dolaylı ve yüksek maliyetli operasyonlarla gerçekleştirilmekteydi. Godot 4.7, bu zorlukları soyutlayarak son derece erişilebilir ve performanslı bir API olan DrawableTexture2D sınıfını tanıtmıştır 2.
DrawableTexture2D, geliştiricilerin standart belit (blit) çağrıları ile doğrudan bir dokunun (texture) üzerine piksel verisi veya fırça darbeleri yazmasına olanak tanır 2. Bu özellik, rendering API'lerine derinlemesine hakim olmayan geliştiricilerin bile karmaşık efektleri kolayca oluşturabilmesini sağlar. Örneğin; strateji oyunlarındaki keşfedilebilir savaş sisi (fog of war) maskeleri, yarış oyunlarındaki dinamik tekerlek izleri, karakterlerin yüzeylere boya fırlattığı mekanikler (paint tools), oyuncuların serbestçe çizim yapabildiği araçlar, kazıma/açığa çıkarma (reveal mask) oyunları veya hasar aldıkça deforme olan zırh dokuları (scratch effects) bu API kullanılarak ana sisteme ekstra yük bindirmeden geliştirilebilir 1.
Piksel Sanatı ve 3D Görsellik: Nearest-Neighbor Ölçeklendirme
Geleneksel 3D render motorları, düşük çözünürlüklü dokuları, kaplamaları veya ekran çıktılarını ekrana yansıtırken varsayılan olarak çift doğrusal (bilinear) filtreleme kullanır. Bu yumuşatma algoritması fotogerçekçi grafiklerde mükemmel sonuç verse de, özellikle 90'lı yılların retro tarzını (PS1 estetiği) taklit eden veya düşük çözünürlüklü 3D piksel sanatı oyunlarında istenmeyen bulanıklıklara (blurring) yol açmaktadır 2 . Topluluk içindeki pek çok geliştirici, sırf bu pürüzleri ortadan kaldırmak için özel shader yazmak zorunda kalıyordu. Godot 4.7, 3D görünüm alanları (viewport) için Nearest-Neighbor (en yakın komşu) ölçeklendirme seçeneğini standart bir motor özelliği olarak entegre ederek, çözünürlük düşürüldüğünde dahi piksellerin keskinliğini ve kesik hatlarını koruyan mükemmel bir estetik kontrol aracı sunmaktadır 1 . Bu özellik, modern 3D özellikleri ile nostaljik piksel sanatı yaklaşımını birleştiren bağımsız yapımlar için vazgeçilmez bir altyapı oluşturmuştur.
Gölgelendiriciler (Shaders), Efektler ve Materyal İyileştirmeleri
Oyunun görsel dilini tanımlayan post-processing (son işlem) efektleri ve parçacık sistemleri de detaylı optimizasyonlardan geçmiştir. Kod tabanlı metin gölgelendiricileri (text shaders) üzerinde çalışan geliştiriciler için en büyük yenilik, editör içerisindeki satıriçi (inline) shader önizlemeleridir. Artık shader kodunda bir matematiksel değişiklik yapıldığında (örneğin bir dalga fonksiyonunun frekansı değiştirildiğinde), motorun yeniden derlenmesine veya farklı bir çalışma alanına geçilmesine gerek kalmadan değişiklikler gerçek zamanlı olarak doğrudan kod editörünün arka planında önizlenebilmektedir 2 . Bu, iterasyon hızını olağanüstü boyutlarda artıran bir gelişmedir.
Fizik tabanlı render (PBR) materyalleri tarafında ise, araç boyası veya ıslak zemin gibi yüzeyleri simüle etmekte kullanılan vernik (clearcoat) render algoritmaları iyileştirilmiş; ışığın bu saydam katmanlar üzerindeki kırılması daha doğru hale getirilmiştir 1 . Render geçişleri (render passes) artık kendi ayrı çevresel (environment) üniforma tamponlarını (uniform buffers) barındırabilmektedir, bu da karmaşık post-processing zincirlerinde esneklik sağlamaktadır 1 . 3D parçacık sistemlerinde ise, geliştiricilere parçacıkların ölçek (scale) ve rotasyonları (rotation) üzerinde genişletilmiş kontroller sunulmuş, parçacıkların açısal hızlarına (angular velocity) yönelik matematiksel düzeltmeler uygulanarak simülasyonların daha organik görünmesi sağlanmıştır 1 .
Kullanıcı Arayüzü (UI) Mühendisliği ve Animasyon
Sistemleri
Oyun geliştirme süreçlerinde kullanıcı arayüzü tasarımı, genellikle oyunun çekirdek mekanik kodlamasından çok daha fazla zaman alan, iterasyona açık ve son derece kırılgan bir yapıya sahip bir alandır 9 . Arayüz elemanlarının oyun ekranındaki değişen çözünürlüklere adapte olabilmesi için Godot, başından beri sağlam bir düğüm tabanlı (node-based) düzen sistemi sunmaktadır. Ancak 4.7 sürümü, arayüz elemanlarının animasyonlar ile olan etkileşimindeki köklü bir yapısal sorunu çözüme kavuşturarak sektördeki en yetenekli UI araç setlerinden birini ortaya koymuştur 9 .
Control Düğümü Ofset Dönüşümleri (Offset Transforms)
Godot'un UI düzen (layout) sistemi hiyerarşik Container (Konteyner) düğümleri üzerine kuruludur. Bir HBoxContainer (yatay kutu) veya VBoxContainer (dikey kutu) içerisine yerleştirilen Control düğümleri (butonlar, paneller, kaydırma çubukları vs.), konteynerin otomatik sıralama ve yerleşim algoritmaları tarafından katı bir şekilde yönetilir 1 . Geçmiş sürümlerde, bir tasarımcı bir butonun üzerine gelindiğinde (hover state) görsel bir geri bildirim yaratmak amacıyla butonun ölçeğini (scale), dönüş açısını (rotation) veya konumunu (position) bir Tween animasyonuyla büyüttüğünde, bu değişim ebeveyn konteyner tarafından bir "düzen bozulması" olarak algılanıyordu. Konteyner, anında yeniden hesaplama yaparak arayüz elemanlarını kendi algoritmik mantığına göre geri konumlandırmaya çalışıyordu, bu da butonların istenmeyen şekillerde sıçrama (snap back) yapmasına, menülerin titremesine ve geliştiricilerin konteyner sistemine karşı adeta savaş vermesine (fighting layout) neden oluyordu 1 .
Godot 4.7'nin UI mühendisliğine getirdiği en kritik çözüm, görsel dönüşümler ile mantıksal kutu modelini (box model) birbirinden ayıran Control ofset dönüşümleri (offset transforms) sistemidir. Yeni eklenen offset_transform_* (konum, rotasyon, ölçek) özellikleri, arayüz elemanının görsel olarak nasıl çizileceğini belirlerken, mantıksal koordinatlarını ve kapladığı alanı orijinal halinde bırakır 1 . Yani, bir buton ofset dönüşümleri kullanılarak görsel olarak %20 büyütüldüğünde veya ekranda kaydırıldığında, ebeveyn konteyner bu değişikliği bir düzen güncellemesi olarak algılamaz ve yerleşim hesaplamalarını korur 4 . Bu izolasyon, UI programcılarının ve teknik sanatçıların konteyner yapısını veya tutturma (anchoring) mantığını bozmadan pürüzsüz, dinamik ve esnek arayüz animasyonları tasarlamasına tam imkan verir 4 . Topluluk geri bildirimleri, bu özelliğin menü tasarımlarında yüzlerce satırlık geçici çözüm (workaround) kodunu ortadan kaldırdığını ve "hayat kurtarıcı" olduğunu doğrulamaktadır 9 .
Zengin Metin Etiketleri (RichTextLabel) ve Konik Degradeler
Kullanıcı arayüzlerinin veri gösterimi yetenekleri, modern oyunların dinamik font boyutlandırma gereksinimlerine yanıt verecek şekilde iyileştirilmiştir. RichTextLabel içerisine [img] etiketi kullanılarak gömülen resimler (örneğin; metin içerisinde gösterilen bir Xbox Controller "A" tuşu veya özel bir emoji simgesi), artık satır içi metin boyutuna duyarlı olarak konumlandırılabilmektedir 1 . Geliştiriciler, [img height=1em] gibi göreceli (relative) CSS benzeri tanımlamalar kullanarak, oyunun çözünürlüğü, dil çevirileri veya erişilebilirlik ayarları değiştirildiğinde metin fontu ile beraber resmin de otomatik olarak orantılı ölçeklenmesini sağlayabilirler 3 .
Ayrıca, 2D efektler ve UI tasarımı alanında renk spektrumları oluşturmak için kullanılan GradientTexture2D sınıfına FILL_CONIC (konik doldurma) modu eklenmiştir. Standart lineer veya dairesel degradelerin aksine, bu konik degrade özelliği, CSS stillerine benzer biçimde renkleri merkez etrafında süpürerek (sweep) dağıtır. Bu matematiksel ekleme, 2D shader yazımında dairesel ilerleme çubukları, mühimmat göstergeleri, radar tarama efektleri veya sahte 3D silindirik gölgelendirme (fake 3D shading) illüzyonları yaratmak için son derece pratik bir temel oluşturmaktadır 3 .
Editör Ekosistemi ve Geliştirici İş Akışı İyileştirmeleri
Oyun motorları sadece çalıştırılabilir dosyalar üreten derleyici motorlar değil; aynı zamanda tasarımcıların, sanatçıların ve programcıların binlerce saatini geçirdikleri üretkenlik ve geliştirme yazılımlarıdır (IDE). Bu bağlamda editörün kendi arayüz akıcılığı, geliştirme süresini doğrudan etkiler. Godot 4.7, editör deneyimini optimize eden, tıklama sayılarını azaltan ve büyük projelerdeki bilişsel yükü (cognitive load) hafifleten çok sayıda Yaşam Kalitesi (Quality of Life - QoL) güncellemesi içermektedir.
Asset Store'un Doğuşu (Eski Asset Library)
Uzun yıllardır Godot geliştiricilerine topluluk tarafından oluşturulan araçları indirme hizmeti veren Asset Library (Varlık Kütüphanesi), yerini sıfırdan ve modern API standartlarıyla yeniden yazılan Asset Store (Varlık Mağazası) konseptine bırakmıştır 2 . Bu sadece kozmetik bir isim değişikliği değil, altyapısal bir mimari revizyonudur. Eski sistemde, devasa varlık paketleri sunucudan çekilirken veya arama sorguları işlenirken ana editör iş parçacığı (main thread) kilitleniyor, bu da donmalara yol açıyordu. Yeni mağaza API'si, arkaplan iş parçacıklarını (background threading) aktif olarak kullanır 1 . Bu sayede, içerikler indirilirken editör arayüzü tamamen duyarlı (responsive) kalır 3 . Ayrıca, varlıkları daha yakından incelemek için önizleme görsellerine yakınlaştırma (zoom) yapabilme, topluluk tarafından verilen güncel derecelendirme (rating) gösterimleri ve çok daha temiz bir kategori ağacı (vitrin) entegre edilmiştir 3 .
Denetleyici (Inspector) Geliştirmeleri ve Animasyon İzi Daraltma
Büyük ölçekli 3D projelerde geliştiricilerin en çok zaman kaybettiği noktalardan biri, karmaşık veri yapılarının düğümler (nodes) arasında aktarılmasıdır. Godot 4.7'deki Inspector paneline eklenen yeni bir pano aracı sayesinde, birbirine benzeyen düğümler arasında değişkenleri (örneğin X, Y, Z rotasyonları veya materyal renk kodları) tek tek kopyalayıp aktarmak yerine, tüm bir özellik grubunu (property section) topluca kopyalayıp başka bir düğümdeki aynı alana tek tıkla yapıştırmak mümkün hale gelmiştir 1 . Bu mekanik, özellikle malzeme (material) parametreleri veya hiyerarşik fizik yapılandırmaları toplu halde aktarılırken manuel hata payını sıfıra indirir ve devasa zaman tasarrufu sağlar 2 .
Karmaşık sahnelerin animasyonlarını yönetmek için kullanılan AnimationPlayer ve Animasyon İzleri (Animation Tracks) paneli de ergonomik olarak elden geçirilmiştir. 40-50 farklı izin bulunduğu kompleks bir karakter iskeletini (skeleton) canlandırırken, ekranın izlerle dolup taşmasını ve kaydırma (scrolling) karmaşasını engellemek adına "kullanılmayan düğüm izlerini daraltma" (track collapsing) özelliği getirilmiştir 1 . Daraltılmış izler üzerinde yer alan anahtar kareler (keyframes), tek bir satırda "toplu bir gösterim" (aggregate representation) olarak sunulur; böylelikle animatörler, daraltılmış izlerin içindeki spesifik detayları görmeden bile genel animasyon zamanlaması (timing) hakkında görsel bir rehbere sahip olmaya devam ederler 3 .
3D Sahne Hizalama (Snapping) ve Cetvel Geliştirmeleri
Seviye tasarımı ve dünya inşası (world building) yapan 3D sanatçılar ve level designer'lar için sahne manipülasyon araçları büyük oranda güçlendirilmiştir. Godot 4.7 öncesinde varlıkları birleştirmek ve zeminlere oturtmak, çoğunlukla göz kararı veya sayısal değerler girilerek yapılmaktaydı. Yeni sürüm, endüstri standartlarını yakalayan üç temel araç seti sunar:
Köşe Noktası Hizalama (Vertex Snapping): Editörde klavyedeki atanmış kısayol tuşuna (varsayılan olarak 'B') basılı tutulduğunda, geliştirici doğrudan bir 3D ağın (mesh) spesifik bir köşe noktasını seçip, diğer nesnelerin köşe noktalarına milimetrik hassasiyetle kilitleyebilir (snap) 1 . Bu, modüler zindan tasarımları veya yapı taşları oluştururken boşluk kalmasını engeller.
Path3D ve Çarpışma Hizalaması (Collider Snapping): Sahnelerde yörüngeler çizmek için kullanılan Path3D düğüm noktaları, artık sadece vizörün kamera düzlemine (camera plane) değil, doğrudan sahnedeki fiziksel çarpıştırıcıların (colliders) yüzeylerine de hizalanabilmektedir1. Bu özellik, dağlık veya eğimli araziler üzerinde hareket eden yapay zeka devriyeleri (patrol paths) veya yarış pisti yörüngeleri çizerken hayati bir kolaylık sağlar3.
Gelişmiş Cetvel (Ruler): Shift modifikatör tuşuyla kullanılan 3D ölçüm aracı, artık sadece iki nokta arasındaki mutlak mesafeyi (örneğin 15 metre) değil, aynı zamanda üç boyutlu uzaydaki her bir koordinat ekseni (X, Y, Z) boyunca oluşan izafi uzunluk vektörlerini de (örneğin X ekseninde 10m, Y'de 5m, Z'de 10m) ayrı ayrı göstermektedir1. Blockout olarak tabir edilen ilk aşama bölüm tasarımında bu geometrik geri bildirim oldukça kritiktir. Ayrıca 3D kamera kontrolleri, motorun içindeki gömülü oyun penceresiyle (embedded game view) birleştirilmiş (unified) ve geliştiricinin klavye kısayollarını veya navigasyon düzenini iki tarafta da aynı tutması sağlanmıştır3. Uzun listelerde istenen nesneleri bulmayı kolaylaştırmak için PopupMenu pencerelerine bir arama çubuğu eklenmiş; yeni düğüm (Node) veya Kaynak (Resource) oluşturma ekranlarına (Create Dialog) ise "Yalnızca Özel Olanları Göster" (Show Custom) gibi filtreleme mekanizmaları entegre edilmiştir1. Kod editöründe çalışan bir geliştirici, komut dosyası penceresinin üstündeki dosya adına çift tıkladığında, dosyanın sol taraftaki dosya sisteminde nerede bulunduğu otomatik olarak vurgulanarak (highlighted) geniş veri ağaçlarında kaybolmanın önüne geçilmiştir3. Remote Scene Inspector (Uzaktan Sahne Denetleyicisi) ekranında ise Enum değerleri, sadece anlamsız tam sayılar (0, 1, 2) olarak değil, kod içerisindeki temsil edilen dizgi isimleriyle (string names) gösterilmeye başlanmıştır3.
Mobil Geliştirme, Sanal Gerçeklik (XR) ve Performans Optimizasyonları
Oyun endüstrisinde mobil cihazların ve sanal gerçeklik başlıklarının (platformlarının) payı giderek artarken, Godot 4.7 bu cihazların donanım kısıtlamalarına hitap eden özel yazılım kancalarını (hooks) standart çekirdek özellikler haline getirmiştir.
Yerleşik VirtualJoystick (Sanal Joystick) Entegrasyonu
Mobil platformlara aksiyon veya rol yapma oyunu geliştiren ekipler, uzun bir süredir ekrandaki sanal dokunmatik kontroller için üçüncü taraf eklentilere veya sıfırdan yazılmış, bakımı zor giriş (input) kodlarına bağımlı kalmaktaydı. Topluluk eklentileri her motor güncellemesinde kırılma riski taşır4. Godot 4.7, doğrudan motor çekirdeğine entegre edilmiş bir VirtualJoystick (Sanal Joystick) düğümü sunarak bu parçalanmayı kökten çözmektedir1.
Bu entegrasyon, mobil oyun tasarımındaki klasik kontrol şemalarına tam uyumlu üç farklı etkileşim modeli desteklemektedir:
Joystick ModuMekanizma ve Kullanıcı Davranışıİdeal Kullanım SenaryosuSabit (Fixed)Joystick'in ekrandaki pozisyonu sabittir. Oyuncu başparmağını ekranın bu spesifik alanına sürüklemelidir. Merkezinde klasik bir "ölü bölge" (dead zone) ayarı bulunur.Retro arcade portları, konsol tarzı sabit kontrolcüler1.Dinamik (Dynamic)Oyuncu ekranın belirlenen bir alanına dokunduğu anda joystick o noktada belirir. Parmak kaldırıldığında ise anında kaybolarak pozisyonunu sıfırlar.Hızlı tepki gerektiren shooter (nişancı) oyunları1.Takip Eden (Following)Dinamik modla aynı mantıkta başlar, ancak oyuncunun başparmağı hareket sınırlarını aştığında, joystick'in merkez ekseni de parmağı takip ederek kayar ve oyuncunun sürekli temasta kalmasını sağlar.Karakterin durmaksızın hareket ettiği RPG'ler veya sonsuz koşucular1.
Ayrıca kontrolcülerden (gamepad) gelen ivmeölçer (accelerometer) ve jiroskop (gyroscope) verilerinin API üzerinden okunabilmesi sağlanmış, mobil veya konsol oyun kumandalarının sunduğu eğim ve hareket (motion) kontrollerinin entegrasyonu stabil hale getirilmiştir3.
GABE (Godot Android Build Environment) ve Cihaz Üzerinde Geliştirme
Godot'un sadece Android için oyun geliştirmekle kalmayıp, felsefi bir duruş olarak "doğrudan Android işletim sistemli tablet ve mobil cihazlar üzerinde (on-device) oyun geliştirme" (Godot Editor for Android) vizyonu, 4.7 sürümünde büyük bir sıçrama yapmıştır. GABE (Godot Android Build Environment) adı verilen özel refakatçi (companion) uygulama sayesinde, Android cihazlar (örneğin bir Samsung Galaxy Tab) üzerinde çalışan Godot Editörü, APK veya AAB oluşturmak için gereken Gradle dışa aktarım desteğine doğrudan cihazın içerisinde sahip olmuştur3. Bu, geliştiricinin bilgisayara ihtiyaç duymadan cihazda yazdığı kodu doğrudan cihazda derleyip tam sürüm paketleri (APK) oluşturabilmesi anlamına gelir4.
Android üzerinde çalışan editörün ergonomik kısıtlamaları da aşılmıştır. Çalışma zamanındaki gömülü oyun penceresi (embedded game window) artık sabit kalmak yerine yeniden boyutlandırılabilir ve sürüklenebilir hale gelmiş; böylece yatay, dikey veya tablet formatı gibi farklı ekran en-boy oranları (aspect ratios) tek bir cihaz üzerinden test edilebilir bir yapıya kavuşmuştur1. Komut dosyası (script) yazım ekranı, cihazın yatay/dikey sensörlerine tepki vererek döndürülebilir (landscape coding) hale gelmiş, bu sayede klavye bağlandığında ergonomi artırılmıştır4. Ayrıca Picture-in-Picture (Resim İçinde Resim) özelliği sayesinde test süreçleri çok daha modüler hale gelmiş ve arka planda çalışırken bile oyun izlenebilir olmuştur1. Export seçenekleri genişletilerek Android projelerinin başlangıç (splash) ekranları artık özelleştirilebilir bir yapıya oturtulmuştur1.
Ancak bu noktada, geliştirici ekosisteminden gelen performans uyarılarına dikkat çekmek gerekmektedir. Godot'un 3D motoru gelişmiş özelliklere sahip olsa da, özellikle mobil cihazlarda Compatibility (GLES3/OpenGL) motoru kullanılırken, Mali G68 gibi orta segment GPU barındıran cihazlarda render kısıtlamaları yaşanabilmektedir. Sektör analizleri (örneğin Reddit test raporları), çok az arka plan nesnesi olan ve sadece 3,000 poligon barındıran basit bir sahnede çözünürlük ölçeği düşürülmedikçe kare hızlarının 38 FPS'e kadar gerileyebildiğini göstermektedir16. Bu nedenle geliştiriciler, Android platformuna yönelik 3D ürün geliştirirken çözünürlük ölçeklendirme (viewport resolution scale), materyal sadeliği ve test cihazı çeşitliliğine maksimum önem vermelidir16.
Genişletilmiş Gerçeklik (XR): Kompozisyon Katmanları ve Foveated Rendering
Sanal Gerçeklik (VR) ve Artırılmış Gerçeklik (AR) pazarında endüstri standardı haline gelen OpenXR mimarisi, Godot 4.7 ile daha üretim odaklı hale getirilmiştir2. Steam Frame ve Android XR platformlarına üretim seviyesinde (production-ready) destek sağlanırken, OpenXR aksiyon haritaları (action maps) en temel dört profile indirgenerek kontrolcü entegrasyonlarındaki karmaşa hafifletilmiştir1.
VR geliştirme süreçlerinde arayüz (UI) okunabilirliği en kritik ergonomi sorunudur. Baş üstü göstergelerini (HUD) veya metinleri standart 3D geometri gibi sahneye yerleştirmek (eye-buffer rendering), merceklerin odak uzaklığı ve piksel yoğunluğu nedeniyle titreyen, bulanık ve okunaksız metinlere yol açar. OpenXR kompozisyon katmanı (composition layer) sistemi, arayüzleri standart oyun dünyası buffer'ının dışına taşıyıp doğrudan vizörün projeksiyon katmanına (projektör üzerine) çizer3.
Godot 4.7, bu kompozisyon katmanları üzerindeki kontrolü derinleştirmiştir. Geliştiriciler artık:
Kompozisyon katmanlarını doğrudan sahnedeki XRCamera3D düğümüne bağlayıp (lock) sabitleyerek, oyuncu başını ne kadar hızlı çevirse bile görüş alanında milisaniyelik bir gecikme bile yaşamadan sabit kalan ultra-keskin (crisp) HUD ekranları tasarlayabilir3.
Kompozisyon katmanı nesnelerini dünya geometrisiyle (world geometry) eşleştirerek (pairing), metin katmanlarını uzaydaki belirli bir koordinata asılı (world-locked) bırakabilir3.
Grafik performansı bağlamında VR başlıkları (örneğin Meta Quest), çözünürlüğün devasa olduğu cihazlardır ve her bir milisaniyenin tasarrufu konfor (comfort) açısından hayati önem taşır4. Godot 4.7'deki Mobile Render motoruna Vulkan "Alt-Örneklenmiş Görüntüler" (Subsampled images) teknolojisi entegre edilmiştir1. Bu teknoloji, foveated rendering (gözün odaklandığı merkezin keskin, çevresel görüş alanının düşük çözünürlükte renderlanması) süreçlerinde işlenen pikselleri daha düşük yoğunluklu depolayarak GPU hafıza bant genişliğini (memory bandwidth) dramatik ölçüde düşürür3. Bu sayede performansta ve mobil cihaz şarj
tüketiminde büyük bir kazanım elde edilir 1 . XR projeleri için varsayılan olarak Mobile render motorunun kullanılması tavsiye edilmektedir 1 .
Fizik Felsefesi ve Gelişmiş 2D Araç Seti
Fizik sistemleri ve çarpışma algoritmaları, oyun motorlarının davranışsal kalbini oluşturur. Godot, 4.6 sürümüyle birlikte varsayılan 3D fizik motoru olarak yüksek performanslı Jolt Physics eklentisini çekirdek ekosisteme dahil etmişti. Sektördeki bazı söylentilerin aksine, 4.7 sürümü Jolt Physics'i değiştirmemiş veya iptal etmemiştir; Jolt motoru yeni 3D projelerin ve 4.7 mimarisinin varsayılan (default) fizik motoru olarak üretim ortamındaki stabilitesini sürdürmektedir 1 . Fakat 4.7 sürümü asıl fizik devrimini, 2D çarpışma mimarilerindeki köklü bir kısıtlamayı aşarak yapmıştır.
Tek Yönlü Çarpışma Yönü Serbestliği (One-way Collision)
2D platform oyunlarında (örneğin; Mario veya Hollow Knight gibi, karakterin altından zıplayıp içinden geçerek üstüne basabildiği bulut veya asma köprü platformları) tek yönlü çarpışmalar sıklıkla kullanılan bir mekaniktir. Godot 4.7 öncesinde, fizik motoru tek yönlü çarpışma vektörünün, ilgili CollisionShape2D düğümünün kendi lokal "Yukarı" (Up) yönüne doğru (0, -1 vektörü) olduğunu katı ve değiştirilemez bir şekilde varsayiyordu 3 . Oyun tasarımcıları çarpışma yönünü (örneğin karakterin sağdan geçebildiği ama soldan çarpıştığı bir duvar) değiştirmek istediklerinde, çarpıştırıcının (collider) fiziksel yapısını veya rotasyonunu görsel grafik düğümlerinden tamamen bağımsız olarak döndürmek ve bu iki yapıyı senkronize etmek gibi acı verici (painful) hilelere başvurmak zorundaydı 3 .
4.7 güncellemesiyle CollisionShape2D sınıfına one_way_collision_direction (tek yönlü çarpışma yönü) adlı yeni bir değişken eklenmiştir 3 . Bu özellik sayesinde, tek yönlü etkileşimlerin yön vektörü, çarpışma şeklinin genel geometrisi (kutu veya kapsül yapısı) asla bozulmadan 360 derecelik lokal uzayda serbestçe atanabilmektedir 3 . Bu durum, şiddetli rüzgar akımları, karakteri iten taşıma bantları, açılı yerçekimi bölgeleri veya platformlardan süzülme mekaniklerinin kodlanmasını gereksiz rotasyon hesaplamalarından kurtararak çok daha zarif ve matematiksel olarak doğru bir hale getirmiştir.
Dinamik CSG Yumuşatması (Autosmooth)
Yapıcı Katı Geometri (Constructive Solid Geometry - CSG), oyun tasarımcılarının Blender veya Maya gibi harici 3D modelleme programlarına ihtiyaç duymadan, motor içerisinde kesişen basit geometrik şekilleri (küp, küre, silindir) kullanarak (toplama, çıkarma, kesişim operasyonları ile) anında 3D seviye (level) prototiplemesi yapmasını sağlayan bir araçtır 3 . Ancak oluşturulan CSG zeminleri her zaman keskin, düşük poligonlu ve pürüzlü görünmekteydi.
Godot 4.7'deki CSG kök düğümlerine eklenen yeni Autosmooth (Otomatik Yumuşatma) özelliği, bu keskin çokgen yapılarını donanım seviyesinde procedural olarak pürüzsüzleştirir 3 . Smoothing Angle (Yumuşatma Açısı) parametresi varsayılan olarak 50 dereceye ayarlanmıştır; bu eşiğin altındaki yüzey birleşimleri otomatik olarak yumuşak yüzeyler (smooth faces) olarak işlenirken, daha yüksek açılı ve dik kesişimler köşe hatlarını (sharp faces) korumaya devam eder 3 . Değer artırıldıkça daha agresif bir yumuşatma profili uygulanır; bu özellik, sadece prototipleme yapan ekiplerin değil, low-poly (düşük poligonlu) üretim yapan stüdyoların da CSG yapılarını doğrudan nihai ürün (final asset) kalitesinde oyunlarına aktarabilmesini sağlar 3 .
API Değişiklikleri, Senaryolama (Scripting) ve
Migrasyon (Geçiş) Stratejileri Her büyük .x sürüm güncellemesi (minor release), yeni özellikler eklerken arka planda motor performansını artırmak adına bazı API (Uygulama Programlama Arayüzü) imzalarını değiştirir ve kod düzeyinde kırıcı değişiklikler (breaking changes) barındırır 3 . Godot 4.7'nin temel felsefesi geriye dönük uyumluluğu korumak olsa da, geliştiricilerin mevcut 4.6 (veya daha eski) projelerini güncellerken dikkate alması gereken katı bir geçiş hiyerarşisi vardır.
Geçiş sürecindeki en hayati metodoloji; üzerinde aktif olarak çalışılan projenin mevcut dizinini doğrudan motorun yeni 4.7 sürümüyle kesinlikle açmamak, bunun yerine projenin sürüm kontrol sistemi (VCS - örn. Git) üzerinde yeni bir test dalı (branch) açmak veya tüm klasörün tam bir kopyasını almaktır 1 . Editör, projeyi 4.7 formatında ilk kez açtığında tüm doku (texture), metin ve model içe aktarma (import pipeline) süreçlerini sıfırdan yeniden yazar; bu işlem geriye döndürülemez olduğundan, izolasyon kritik veri kayıplarını ve geri uyumluluk hasarlarını engeller 13 .
Programlama ve Senaryo Yazımı Yenilikleri
Godot'un kendi dinamik betik dili olan GDScript, 4.7 sürümünde akış kontrolü ve sistem entegrasyonu tarafında güçlenmiştir:
Java Arayüzleri (Interfaces) Uygulaması: Önceden Android cihazların özel donanımlarına (kamera API'si, özel sensörler veya ödeme sistemleri) erişmek için C++ veya Java ile ara eklentiler yazılması gerekiyordu. 4.7 ile GDScript, doğrudan Java arayüzlerini motor içerisinden entegre edebilme yeteneği kazanmış ve harici eklentilere olan ihtiyacı büyük ölçüde hafifletmiştir 1 .
Tween Duraklatma (tween_await): Kod tabanlı animasyonlar yaratmak için kullanılan Tween sistemi, artık bir tween_await() fonksiyonu çağırarak, sistem içindeki başka bir objeden gelen sinyalin (signal) tetiklenmesine kadar kendi çalışma zamanını askıya alabilir (pause). Bu özellik asenkron (asynchronous) animasyon zincirleri oluşturmak için muazzam bir kolaylıktır 1 .
C# (.NET) kullanıcıları için yapısal sistem korunmaktadır. Godot 4.7, "Standard" (GDScript ve GDExtension üzerinden C++ destekler) ve ".NET" (C# destekler ve .NET SDK gerektirir) olmak üzere iki ayrı çalıştırılabilir ikili (binary) dağıtım sunmaya devam etmektedir 1 . Geçmişteki C# tabanlı bir projenin yeni Standard motorla açılması durumunda scriptler derlenmeyecek ve bozukluklara yol açacaktır; bu nedenle doğru sürümün indirilmesi esastır 1 .
Öne Çıkan Kırıcı Değişiklikler (Breaking Changes) Tablosu
Aşağıdaki tablo, Godot 4.6'dan Godot 4.7'ye geçişte mevcut kod yapılarını, veri tiplerini ve API çağrılarını etkileyen, dolayısıyla refaktör (kod düzenlemesi) gerektiren temel değişiklikleri özetlemektedir:
Etkilenen Sınıf / Sistem ÖzelliğiDeğişen Metod / Değiştiği ve Detaylı AçıklamaMimarinin Uyumluluk Durumu (GDScript / C#)Object (Çekirdek - Core)is_class() class parametresinin türü genel String tipinden, C++ seviyesinde çok daha hızlı ve statik bellek kullanan StringName tipine dönüştürülmüştür18. Nesne sorgulamalarında performansını artırır.GDScript: Uyumlu.
C#: İkili ve Kaynak Uyumlu.ZIPPacker (Çekirdek)start_file() API'ye güvenlik için permissions (dosya izinleri) ve zaman damgası için modified_time (değiştirilme zamanı) adında iki yeni parametre eklenmiştir18.GDScript: Uyumlu.
C#: İkili ve Kaynak Uyumlu.OptimizedTranslationgenerate() Dil yerelleştirme (localization) fonksiyonunun başarı durumunu raporlayabilmesi için geri dönüş (return) değeri boşluk (void) tipinden mantıksal (bool) tipe geçirilmiştir18.GDScript: Uyumlu.
C#: İkili Uyumsuz, Kaynak Uyumlu.GPU/CPUParticles2D ve 3Drequest_particles_process() Parçacık simülasyonlarına fiziksel doğruluğu artırmak adına ince ayar için process_time_residual parametresi eklenmiştir18.Tüm diller için Uyumlu.Control (Arayüz - GUI)accessibility_live Ekran okuyucuları gibi erişilebilirlik (accessibility) özellikleri, grafik ekran sunucusundan (DisplayServer) bağımsızlaştırılarak kendi AccessibilityServer.AccessibilityLiveMode tipine taşınmıştır18.GDScript: Uyumlu.
C#: Tamamen Uyumsuz (Elle Refaktör Gerekli).RichTextLabel (Arayüz)Constant (Sabit) Enum Genişlik belirleme parametresi olan ImageUpdateMask.UPDATE_WIDTH_IN_PERCENT değişkeninin ismi, mantıksal yapıya daha uygun olan ImageUpdateMask.UPDATE_WIDTH_UNIT olarak güncellenmiştir18.GDScript: Uyumsuz.
C#: İkili Uyumsuz, Kaynak Uyumsuz.RichTextLabel (Arayüz)add_image() / update_image() Boyutlandırma esnekliği sağlamak ve 1em gibi görece ondalıklı (relative) ölçekleri desteklemek için width ve height parametreleri Tamsayı (int) tipinden Ondalıklı Sayı (float) tipine çevrilmiştir18.Tüm diller için Uyumlu.
Güncelleme Sonrası Doğrulama ve Test Prosedürleri
Proje 4.7 ortamında sürüm kontrol sistemi üzerinde başarıyla açıldıktan sonra, derleme (compile) yapılsa bile spesifik modüllerin çalışma zamanı (runtime) regresyon testlerinden geçirilmesi gerekmektedir:
Arayüz (UI) Hiyerarşisi: Yeni gelen offset_transform dinamikleri, bazı köklü iç içe geçmiş ebeveyn-çocuk (parent-child) düğüm yerleşimlerinin, kaydırma çubuklarının (scroll views) veya açılır menü (popup menus) hesaplama algoritmalarını etkileyebileceğinden, ana menü, envanter ve ayar (HUD) ekranları baştan sona test edilmelidir 1 .
Materyal İfadesi ve Render Kanalı: Standart dinamik aralığın (SDR), ortamına dahil olan HDR destekli render kanallarına geçişinden ve vernik (clearcoat) algoritmasından kaynaklanan PBR materyal görünümlerinde ton kaymaları (color shifting), ışık sızmaları veya gölge farklılıkları gözlemlenebilir; tüm aydınlatma yapıları doğrulanmalıdır 1 .
Android Ayarları ve XR Profilleri: Dışa aktarım ayarlarında (export presets) Android başlatma (splash) ekranları, OBB veri paketleme değişiklikleri ve basitleştirilmiş dört temel profile indirgenmiş OpenXR hareket haritalarının (action maps) sıfırdan doğrulanması gerekmektedir 1 .
C++ GDExtension Eklentileri: Projede kullanılan ve motorun C++ kaynak kodlarına bağlanan (bind) kütüphaneler (GDExtensions), Godot 4.7'nin yeni API imzasını destekleyecek şekilde güncellenmediyse motor çökebilir. Yükseltme öncesinde gereksiz eklentiler devre dışı bırakılmalı ve Proje Ayarları altından her eklentinin başarıyla yüklendiği teyit edilmelidir 1 .
Sonuç
Godot 4.7 sürümü, sadece bir oyun motoruna "medyatik özelliklerin eklenmesi" pazarlama felsefesinden sıyrılarak, profesyonel oyun üretim döngülerindeki kronik sancıları sistematik olarak hedefleyen olgun bir mühendislik güncellemesidir 4 . Endüstriden ve Reddit gibi bağımsız topluluk merkezlerinden gelen analizlerin net bir şekilde gösterdiği üzere, Unity gibi köklü motorlardan geçiş yapan geliştiricilerin beklentilerini karşılayacak bir stabilite ve üretim pratikliğine ulaşılmıştır 8 .
AreaLight3D ve HDR görüntü entegrasyonu, motorun mimari görselleştirme ve yüksek kaliteli 3D fotogerçekçi projelerdeki yetkinliğini kanıtlarken; donanımsal Işın İzleme (Ray Tracing) altyapısının çekirdeğe dahil edilmesi, motorun geleceğin görsel standartlarına olan stratejik hazırlığını simgeler 2 . Diğer yandan, Control düğümlerindeki ofset dönüşümleri, UI geliştiricilerin en büyük kabuslarından biri olan "düzen bozulması" problemini ortadan kaldırmış; VirtualJoystick ve GABE entegrasyonları ise mobil pazar için dışa bağımlılığı (eklentileri) sonlandırmıştır 1 . Foveated rendering'i destekleyen Vulkan alt-örneklenmiş görüntü sistemleri (subsampled images) ile de XR donanımlarında performans sınırları maksimize edilmiştir 1 .
Açık kaynak felsefesiyle ve yüzlerce katkıcının (contributor) emeğiyle şekillenen Godot Engine, 4.7 sürümü ile 4.x jenerasyonunun en kararlı, geliştirici dostu (developer-friendly) ve modern
donanım kapasitesinden en fazla faydalanan varyantını ortaya koymuştur. Mevcut projelerin detaylandırılan API değişiklikleri, uyumluluk sınırları ve test prosedürleri dikkate alınarak gerçekleştirilecek izolasyonlu bir sürüm geçişi (migration) stratejisi, geliştirici stüdyoların projelerindeki üretim hızını (iteration time), ürün bakım maliyetlerini ve oyunun son kullanıcı nezdindeki grafiksel kalitesini tartışmasız biçimde üst düzeye çıkaracaktır.
*Bilgi : Görseller, Google Gemini Tarafından Üretilmiştir.