Yapay zekâ odaklı oyun motorları kullanıma sunuluyor ve Unity'ye hiç benzemiyor
Cinevva CTO'su Oleg Sidorkin tarafından
Mart ayında, mimari açıdan Unity/Unreal/Godot soyundaki her şeyden farklı üç oyun motoru ortaya çıktı. Görsel editörleri yok. Menüler arasında tıklayan bir insan için optimize edilmemişler. Baştan sona, yapay zekâ ajanlarının oyun durumunu okuyabilmesi, yazabilmesi ve kontrol edebilmesi için geliştirilmişler.
Bu, “yapay zekâ sekmesi eklenmiş Unity” değil. Bu, farklı bir motor türü.
Yapay zekâ, 3D oyun geliştirme iş akışlarını şimdiden değiştiriyor. Sırada motor katmanı var.
Üç motor
nAIVE Engine açık kaynaklıdır ve WebGPU işleme kullanan Rust ile yazılmıştır. Bir saniyeden kısa sürede çalışırken yeniden yükleme sunar: gölgelendiriciler 200 ms'den, sahneler 100 ms'den, betikler ise 50 ms'den kısa sürede yüklenir. Sahneler, işleme hatları ve malzemeler YAML ile tanımlanır; böylece LLM'ler ikili biçimleri ayrıştırmadan bunları okuyup oluşturabilir. Yapay zekâ ajanlarının motor işlevlerini JSON-RPC üzerinden kontrol etmesini sağlayan bir MCP komut arayüzü sunar. Gaussian splatting ve otomatik testler için başsız işleme, motorun birinci sınıf özellikleri arasındadır. Mimarinin tamamı, birincil kullanıcınızın fare kullanan bir insan değil, bir yapay zekâ ajanı olabileceği varsayımına dayanır.
Arcane Engine kod odaklı bir 2D motordur. Rust çekirdeği ve TypeScript betik sistemi kullanır. Hiçbir görsel editörü yoktur. Felsefesi şudur: “Kod, sahnenin kendisidir.” Oyun durumu, bir sahne ağacı yerine sorgulanabilir bir veritabanıdır. Yapay zekâ ajanlarıyla etkileşim için yerleşik bir protokol içerir. Apache 2.0 lisanslıdır.
Mirror Engine alfa aşamasındadır ve varlık-bileşen sistemiyle çok oyunculu deneyimleri önceliklendirir. İlgi çekici yanı şudur: metin istemlerinden yaklaşık 60 saniyede Gaussian splat'ler üreten, metinden 3D'ye yapay zekâ üretimi içerir. TypeScript betik sistemi ve tarayıcı tabanlı “Mirror Lite” istemcisi sunar.
Bu üç motor aynı kod tabanını veya ekibi paylaşmıyor, ancak ortak bir tasarım tezini benimsiyorlar: bir oyun motorunun birincil arayüzü GUI değil, yapılandırılmış metin olmalıdır.
Bu mimari neden önemli?
Geleneksel oyun motorları, masa başında çalışan bir insana hizmet edecek şekilde evrildi. Bir görünüm alanınız, hiyerarşi paneliniz, denetçiniz ve zaman çizelgeniz vardır. Her şey tıklama, sürükleme ve nesneleri görsel olarak yerleştirme etrafında tasarlanmıştır. Bu iş akışı güçlüdür. Ancak bir yapay zekâ ajanının bunu kullanması da imkânsızdır.
Birincil “kullanıcınız” bir LLM olduğunda farklı temel yapı taşlarına ihtiyaç duyarsınız. İkili sahne biçimleri yerine YAML. İç içe geçmiş sahne ağaçları yerine sorgulanabilir durum. Fare tıklamaları yerine protokol tabanlı komutlar. Pencerede işleme yerine başsız çalışma.
Bu, DevOps'un GUI kontrol panellerinden kod olarak altyapıya geçmesiyle altyapı alanında yaşanan dönüşümün aynısıdır. Aynı şey, yalnızca yirmi yıl sonra oyun motorlarında yaşanıyor.
nAIVE'ın MCP arayüzü bunun en net örneğidir. MCP (Model Context Protocol), yapay zekâ ajanlarının araçlarla iletişim kurmasının standart yolu hâline geliyor. Bir motor MCP'yi yerel olarak desteklediğinde, protokolü destekleyen herhangi bir yapay zekâ ajanı insan müdahalesi olmadan sahneleri değiştirebilir, parametreleri ayarlayabilir, testleri çalıştırabilir ve oynanış üzerinde yinelemeler yapabilir. Bu, geleneksel bir motora sonradan eklenmiş bir özellik değildir. Motor ile kullanıcısı arasında temelden farklı bir ilişkidir.
Oyun geliştirmede Gaussian splatting. Hem nAIVE hem de Mirror bunu birinci sınıf bir işleme temel öğesi olarak ele alıyor.
Büyük resim
Bu üç motor tek işaret değil. Meshy'nin Black Box'ı, çalışma zamanında yapay zekâyla üretilen oyun mekaniklerini sergiledi. OpenAI, GDC'de Phaser ile geliştirilmiş bir taktiksel RPG gösterdi. “Yapay zekâ bir şey üretir” ile “üretilen şey oynanabilir bir oyun olarak çalışır” arasındaki araç katmanı her ay inceliyor.
Cinevva'da biz bu köprüyü diğer yönden inşa ediyoruz. Yapay zekâ varlık üretimini üstlenirken motorumuz işleme, fizik ve gerçek zamanlı etkileşimi yönetiyor. Yaklaşım nAIVE veya Arcane'den farklı olsa da temel iddia aynı: geleceğin oyun motorunun yapay zekâyı yalnızca bir eklenti olarak sunması değil, onu ana dili olarak konuşması gerekiyor.
Geleneksel motor üreticileri de bunun farkında. Unity, GDC'de yapay zekâ destekli oyun oluşturma araçlarının ön gösterimini yaptı. Roblox, yapay zekâ destekli 4D model oluşturmayı kullanıma sundu. Ancak insanlar için tasarlanmış bir motora yapay zekâ özellikleri eklemek ile yapay zekânın birincil arayüz olduğu bir motor tasarlamak arasında önemli bir fark var.
Bundan sonra ne olacağını düşünüyorum?
Bu motorların çoğu ayakta kalamayacak. Yeni bir kategori için bu normaldir. Ancak tasarım kalıpları kalıcı olacak. YAML tabanlı sahne tanımları, ajan kontrolü için MCP protokolleri, sorgulanabilir oyun durumu ve başsız çalışma. Bu fikirler iki yıl içinde ana akım motorlara dahil edilecek.
Bu dönemin kazanan motoru muhtemelen henüz mevcut değil. Ancak mimari DNA'sı şu anda bu üç projede ve birkaç başka projede yazılıyor. Mesele, oyun motorlarının yapay zekâ odaklı hâle gelip gelmeyeceği değil. Mesele, dönüşümün mevcut büyük oyuncuların içinden mi geleceği, yoksa ilk günden itibaren ajanlar için tasarım yapan yeni girişimlerden mi doğacağı.
İlgili içerikler:
- Artık herkes yapay zekâ oyun motoru olmak istiyor — zemini hazırlayan platform yarışı
- Öncü Açık Kaynak Üretken Yapay Zekâ Modelleri — bu motorların entegre ettiği modeller
- Web Oyun Motorları Karşılaştırması — yeni motorların daha geniş ekosistemdeki yeri
- Açık kaynağın bir yapay zekâ kirliliği sorunu var — yapay zekâ tarafından üretilen katkıların maliyet tarafı